Decommissioned system: which data should be retained for audits years later?

When an application or infrastructure reaches the end of its lifecycle, IT teams often remove it from service permanently: this is decommissioning. Beyond simply stopping services, this operation raises a crucial question: which data must be archived to justify compliance with legal, regulatory, or contractual requirements several years down the line? The answer involves a careful balance between retention obligations (GDPR, LPM, PCI-DSS…), auditability requirements (access logs, configurations, decisions), and operational constraints (storage costs, security, governance). The article describes the challenges, the data to retain, and a framework for managing it after decommissioning.

1. Context: Why decommissioning is becoming an audit challenge

Organisations are modernising their IT systems at a steady pace (cloud migration, adoption of micro-services, data centre rationalisation). Each project inevitably leads to the decommissioning of a legacy platform. However, compliance requirements do not vanish when a system is shut down:

• Legal Obligations – GDPR mandates a minimum retention period for personal data necessary for the purposes for which they were collected (Article 5-1 c). In France, the LPM law (Loi de programmation militaire) requires certain security traces to be retained for 10 years.
• Contractual Requirements – SLA clauses or PCI-DSS requirements mandate the retention of transaction logs for at least one year.
• Legal Risk – In the event of a dispute, the absence of archived evidence (e.g. access logs, governance decisions) can lead to financial penalties or loss of customer trust.

Consequently, decommissioning is no longer a simple technical operation: it is a critical control point for legal resilience and continuous auditability.

2. Regulatory Framework and Applicable Standards

\*The durations indicated are the legal or sectoral minimums; internal policy may be more stringent.

These requirements often overlap: a single log file can satisfy multiple frameworks, provided it is correctly classified, integrated into a retention solution, and protected against tampering.

3. Typology of data to be archived after decommissioning

3.1 Operational data

3.2 Legal and contractual data

• Service Level Agreements (SLA) associated with the system.
• Data Processing Agreements (DPA) signed with sub-processors.
• Governance decisions (e.g., steering committee, budget approvals).
• Internal or external audit reports conducted during the model's lifecycle.

3.3 Backup and recovery data

Even if the system is decommissioned, backups containing historical data may be required to:

• Respond to a subject access request (GDPR Art. 15).
• Reconstruct the state of an incident under investigation.
• Provide evidence of business continuity during a resilience audit.

3.4 Meta-information and indexing

A detailed archive catalogue (acting as a metadata “data lake”) facilitates future retrieval:

4. Technical architecture of a post-decommissioning archiving solution

4.1 Guiding principles

• Immutability – Archives must be read-only and protected against any unauthorised modification (e.g. WORM — Write Once Read Many).
• Verifiable integrity – Use of cryptographic hashes (SHA-256) and digital signatures to guarantee non-alteration.
• Storage security – Encryption at rest (AES-256) and in transit (TLS 1.3).
• Lifecycle management – Automated policies for retention, cold storage, and subsequent purging upon expiration.
• Controlled accessibility – Access control based on the principle of least privilege (RBAC/ABAC), with logging of archive access.

4.2 Typical diagram

Read the diagram notation

flowchart LR
    A[Sources à archiver] --> B{Pré‑traitement}
    B --> C[Normalisation & métadonnées]
    C --> D[Hachage + Signature]
    D --> E["Chiffrement (AES‑256)"]
    E --> F["Stockage WORM Cloud (ex. AWS Glacier Deep Archive, Azure Immutable Blob)"]
    F --> G["Catalogue Méta‑données (ElasticSearch / OpenSearch)"]
    G --> H[Portail d’accès contrôlé]
    H --> I[Audit & Reporting]

Cloud solutions offer native 'immutable' options (e.g. Amazon S3 Object Lock, Azure Immutable Blob Storage) which simplify compliance.

4.3 Common technological choices

The choice depends on the desired level of sovereignty, archive volume, and team maturity.

5. Operational decommissioning process with audit retention

• Planning
• Identify stakeholders (CIO, CISO, DPO, legal).
• Catalogue applicable legal and contractual requirements.

• Artefact inventory
• Run an automated scan (e.g., PowerShell/CLI scripts) to list logs, databases, configurations, and contractual documents.
• Validate completeness with business teams.

• Classification & metadata
• Apply the metadata schema presented in §4.2.
• Assign a sensitivity level (public / internal / confidential).

• Pre-processing and securing
• Normalise formats (e.g., JSON for logs, YAML for IaC).
• Generate SHA-256 hash + PGP signature.
• Encrypt the stream to the archiving destination.

• Immutable storage and indexing
• Deposit artefacts into a WORM bucket configured with an appropriate retention policy.
• Populate the metadata catalogue (e.g., OpenSearch).

• Post-deployment integrity verification
• Compare hashes calculated before and after transfer.
• Document results in an archiving report.

• Communication & training
• Inform teams of archive availability (portal, access procedure).
• Train data governance officers on how to consult the archives.

• Periodic internal audit
• Verify annually that retention policies are adhered to and that archive access remains compliant.

This process can be managed by an orchestration tool (e.g., Ansible, Terraform) to ensure the reproducibility and traceability of the decommissioning.

6. Cost-benefit analysis

Return on investment is primarily measured in terms of penalty prevention (GDPR fines reaching up to 4% of annual turnover) and reputational protection, which is difficult to quantify but critical for companies operating in highly regulated sectors.

7. Key points of vigilance

Major risks

Questions to consider before decommissioning

• What are the legal retention periods applicable to the various artefacts?
• Does the system already have a usable metadata catalogue?
• What are the long-term storage costs and what cold archiving options are available?
• Who will be responsible for the archive lifecycle (CIO, DPO, CISO)?

8. Use case: decommissioning of a legacy CRM platform

Context

A large financial services company migrated its internal CRM (on-premise version, Java EE, Oracle database) to a SaaS solution in 2022. The migration project generated:

• 3 TB of application logs (access + audit).
• 1 TB of daily backups of the customer database (personal data).
• 250 GB of IaC infrastructure scripts (Ansible) and web.xml files.

Steps completed

Assessment

• Compliance ensured with GDPR (customer data retention for 7 years).
• Estimated annual storage cost of €1,200, significantly lower than the potential cost of a non-compliance fine.
• Internal audit response time: < 30 minutes to extract requested logs, thanks to the OpenSearch catalogue.

9. Decision and Governance: How to choose the right archiving strategy

The decision must be made in consultation between the CIO, DPO, CISO and the project steering committee, based on an impact/cost matrix.

10. Operational conclusion

Decommissioning does not mark the end of an organisation's responsibility: it triggers a retention cycle that must be orchestrated like any other critical IT function. By identifying essential data categories (logs, configurations, contracts, backups), classifying them according to standardised metadata and