Archiving is a data integrity commitment, not a storage decision

Every regulated organization has a plan for going live. Almost none of them have an equally rigorous plan for going dark.

That asymmetry comes from how validated systems get funded and staffed. Go-live work has a deadline, a budget line, and an executive sponsor watching the calendar. Retirement work has none of those things until an audit finding, a migration dependency, or a records request forces the question, years after the system in question stopped being anyone's priority.

Retirement, decommissioning, and archiving get managed as three separate compliance tasks, each with its own checklist and its own owner. In practice, they are a single governance decision, and organizations that sequence them independently pay for it later. A system gets decommissioned before anyone has confirmed which of its records still carry a regulatory retention obligation. An archive gets built without a migration plan for the day its storage format goes obsolete. The gaps do not surface at decommissioning. They surface at the next inspection, when someone asks for a record the organization can no longer produce, or can produce but can no longer prove is authentic.

Archiving in a regulated environment is a data integrity commitment. Every record retained from a decommissioned system has to remain accessible, legible, and attributable for its full retention period, a period that can span decades and will very likely outlast the system that generated the record, the platform storing it, and the personnel who created it. GAMP 5 has treated retirement as a defined phase of the validated system lifecycle for years, not an afterthought once operational use ends. ALCOA+ sets the same bar for archived records that it sets for live ones: attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, and available. An archive that cannot meet that bar functions as a liability with a retention schedule attached, regardless of what it was originally built to do.

A defensible retirement strategy has a few consistent features regardless of industry vertical or system type. It starts with a written policy for each stage: retirement, decommissioning, archiving, and migration, so that the decision criteria exist before a specific system needs them, rather than getting improvised system by system. It involves the people who will be asked to defend the decision later: IT, security, quality, and the end users who know how the system was used in practice, not just how it was originally specified. It builds in a review cadence, because a policy written for an on-premises environment in 2019 does not automatically hold for a cloud migration in 2026. And it treats training as part of the control, not a courtesy, because a decommissioning procedure that only one person understands functions as a single point of failure with a document attached to it.

The regulatory expectations here are also moving, and it is worth being precise about where things stand today. The European Commission and PIC/S published a draft revision of EU GMP Annex 11 in July 2025, expanding the guidance from roughly five pages to nineteen and embedding risk management, data integrity, and cybersecurity requirements across the full system lifecycle, including retirement and archiving [1]. Public consultation on that draft closed in October 2025. The final version is expected in mid-2026 and has not yet been published as of this writing, so organizations building their archiving strategy around the current draft should treat it as directional, not yet binding, while still preparing for it. On the U.S. side, the FDA finalized its Computer Software Assurance guidance for production and quality system software in September 2025, replacing the relevant section of the 2002 validation guidance and reinforcing a risk-based approach to system validation and, by extension, to how that risk-based thinking should carry through to retirement decisions [2].

None of this changes the underlying argument. Whether the final Annex 11 language lands exactly as drafted or changes before publication, the core expectation is the same one GAMP 5 and ALCOA+ already establish: data integrity is a lifecycle property, not a phase that ends when a system goes dark. A validated system's most vulnerable moment for a data integrity failure comes the year after everyone stopped watching it, not at go-live.

This is also where migration decisions get entangled with retirement decisions, and where most organizations lose track of which decision governs which. A migration project decides what moves to a new environment. A retirement decision decides what stops running. An archiving decision decides what gets preserved and how. Treated as three independent projects, each with its own timeline and its own owner, the documentation proving that a data integrity requirement was satisfied across all three is exactly what goes missing. Treated as one governance decision, with a single framework connecting retention requirements, validated state continuity, and lifecycle documentation, that proof is what gets built by design instead of reconstructed under audit pressure.

The organizations that get this right decided, deliberately and in advance, what "defensible" looks like for a system that no longer exists, documented that decision before they needed it, and let the checklist follow from that decision rather than substitute for it.

What would your organization's records show if an auditor asked about a system you decommissioned two years ago?

References

[1] Annex 11 revision status, draft timeline and scope — MFLRC, "EU GMP Annex 11 Revision: Computerised Systems, Data Integrity and AI Rules Arriving in 2026" — https://mflrc.com/article/eu-gmp-annex-11-revision-2026
[2] FDA Computer Software Assurance guidance finalization, September 2025 — MFLRC, same article as above — https://mflrc.com/article/eu-gmp-annex-11-revision-2026