System Retirement Form
Frequently Asked Questions

A System Retirement Form is the controlled document that formally authorises the withdrawal of a GxP computerised system from regulated use and records how its data, records, and audit trail will be preserved after decommissioning.

It closes the validation lifecycle the same way a Validation Plan opens it — confirming what happens to the system's regulated data, who approved the withdrawal, and when GxP use formally ended. Without it, an inspector cannot confirm when a system stopped being validated or where its data now resides.

No regulation mandates a document called a "System Retirement Form" by that exact name, but EU GMP Annex 11 and FDA data integrity guidance both expect a documented, controlled decision confirming how a system's GxP records are preserved once it is withdrawn from use.

Annex 11 requires record retention to be considered as part of the computerised systems lifecycle. FDA data integrity guidance requires organisations to keep historical records accessible for their full retention period, regardless of whether the generating system is still operational. The retirement form is the industry-standard way to demonstrate this was actively planned rather than left to chance.

The System Retirement Form is typically the front-end authorisation document — the risk assessment and approval to proceed — while a Decommissioning Report is the back-end evidence document confirming the retirement activities were actually completed as planned.

Some organisations combine both into a single document with a planning section and a completion section signed at different dates. Others keep them separate, with the retirement form triggering a decommissioning protocol that is executed and reported on independently. Either structure works provided authorisation, execution, verification, and closure are all traceable.

No — for systems with direct GxP impact, the retirement form documents the decision and risk rationale, but a separate decommissioning activity should verify and evidence that data migration, archival, and access revocation were executed correctly.

Treating the retirement form as sufficient proof of a compliant retirement is a common shortfall. A system holding electronic batch records needs verified evidence — such as record counts before and after migration, or checksum comparison — that data integrity was preserved, not just a signed statement that migration "was performed."

The business system owner initiates and justifies the retirement, IT executes the technical decommissioning, and Quality Assurance approves the retirement form to confirm that data integrity, record retention, and regulatory obligations have been addressed before the system is withdrawn.

QA approval is the non-negotiable control point: it prevents a system holding unreconciled GxP data from being switched off simply because it is no longer commercially useful. IT should not decommission infrastructure until the QA-approved retirement form exists.

A System Retirement Form should be initiated whenever a GxP system is permanently withdrawn from use — including replacement by a new system, vendor discontinuation, business process changes that eliminate the need for the system, or site or contract closure.

• Replacement or migration to a new validated system covering the same function.
• Vendor end-of-life or end-of-support notification with no viable upgrade path.
• Consolidation of duplicate systems following a merger or acquisition.
• Business process change that eliminates the need for the system's function.
• Site or facility closure removing the system's operational context.

The retirement form must be drafted, risk-assessed, and approved before the system is switched off — retirement planning has to happen while the system is still accessible so that data migration and verification can actually be performed.

Completing the form retroactively after a system has already been powered down is a serious finding, because by then there is no way to verify that the data extracted matches what existed in the live system. The form should specify a target decommissioning date, not describe a shutdown that has already occurred.

No — a system must not be decommissioned until all GxP data it holds has been migrated, archived, or otherwise made accessible in a validated, readable format for the remainder of its retention period.

This includes not only the primary records but the metadata and audit trail needed to reconstruct who did what and when. If the archival format cannot preserve the audit trail relationship to its records, the retirement plan is incomplete regardless of how much of the raw data was exported.

The retirement form is drafted and provisionally approved first as a plan, data migration and archival are executed second, and the retirement form or a linked decommissioning report is then updated with verified completion evidence before the system is finally switched off.

• Draft the retirement form: scope, risk assessment, proposed archival approach, target date.
• QA and the system owner review and provisionally approve the plan.
• Execute data migration or archival and verify completeness against the source system.
• Record verification evidence and any deviations in the retirement documentation.
• Obtain final QA sign-off, then decommission infrastructure and revoke access.

Retiring a GxP system is itself a change and should be raised as a formal change control record, with the System Retirement Form serving as the supporting risk assessment and execution evidence referenced by that change.

Routing retirement through change control captures downstream impacts — interfaces with other GxP systems that need to be disabled or rerouted, SOP updates that reference the retired system, and training impacts for current users. Retiring a system outside change control risks leaving dependent systems or procedures pointing at a decommissioned resource.

An inspection-ready retirement form must let a reviewer with no prior knowledge of the system understand exactly what was retired, why, what happened to its data, and who authorised the decision.

• System name, version, GxP impact classification, and validation history reference.
• Reason for retirement and the replacement system, if applicable.
• Data disposition plan: what is archived, migrated, or destroyed, and in what format.
• Risk assessment of the retirement, including any residual risk accepted.
• Confirmation of access revocation and infrastructure decommissioning steps.
• Signature blocks for the system owner, IT, and QA approver with dates.

The retirement form should specify the exact archival format, the tool or platform used to access archived records, and how that format preserves both the raw data and its associated audit trail and metadata.

A common deficiency is archiving data as a flat export — such as a PDF or spreadsheet — that loses the dynamic, queryable relationship between a record and its audit trail. Where the archival format is static, the form should explain why static preservation is adequate for the record type and how the audit trail relationship is retained.

The retirement form must specify how archived data can still be retrieved, read, and reproduced in a usable format on request throughout its retention period, including who is authorised to access it and how access is requested.

Archiving data in a proprietary format tied to software that is no longer licensed or supported creates a de facto data loss even if the file technically still exists. The form should identify the viewing tool, confirm its ongoing availability, and note any planned migration if that tool has a limited support horizon.

Yes — retirement carries risks distinct from the system's original operational use, and the form should include a targeted risk assessment covering data loss, loss of audit trail integrity, and disruption to interfacing GxP systems during decommissioning.

The original validation risk assessment addressed operational risk while the system was in use; it does not address the risk of the migration or shutdown event itself. ICH Q9(R1) principles apply directly here — the retirement risk assessment should be proportionate to the system's GxP impact classification and the complexity of its data disposition.

At minimum, the system owner and Quality Assurance must sign the retirement form; IT or infrastructure should also sign to confirm technical decommissioning steps were completed, and Regulatory Affairs should be consulted for systems connected to active submissions.

The retirement form and its supporting archival evidence must be retained for at least as long as the retention period applicable to the data the system produced — commonly a minimum of five years after retirement under FDA cGMP and EU GMP frameworks, but longer where product shelf-life or clinical data obligations extend it.

The retirement form itself becomes part of the permanent record trail for the retired system: it is the document an inspector uses years later to understand where the system's historical data now lives and to confirm decommissioning was itself a controlled, GxP-compliant activity.

Once the retirement form is approved and decommissioning is complete, the system's GxP Inventory entry should be updated to a "Retired" status with the retirement date, a reference to the retirement form document ID, and a link to where its archived data now resides.

An inventory that still lists a decommissioned system as "Validated," or omits it entirely once it is switched off, creates the same problem: the inventory no longer reflects reality, and an inspector cross-checking the inventory against the actual IT environment will find a discrepancy.

The original Validation Summary Report and System Release Certificate are not deleted or invalidated — they remain in the validation archive as evidence of the period during which the system was properly validated and authorised for GxP use, while the retirement form documents the formal end of that period.

The retirement form should explicitly reference the VSR and SRC document IDs it is superseding for operational purposes, creating a complete, traceable lifecycle: validated and released, operated, then formally retired with data disposition confirmed.

Inspectors verify that a retired system's data is still accessible and readable, that the retirement was formally approved before decommissioning rather than after the fact, and that the GxP Inventory and other validation documents consistently reflect the retired status.

A frequent finding is requesting a historical record from a retired system and discovering the organisation can no longer open the archival format, or that the person who could operate the legacy viewing tool has left the company. Inspectors also check whether retirement approval dates precede the actual system shutdown date.

The biggest risk is data becoming technically preserved but practically unreadable — archived in a format, or dependent on software, that the organisation can no longer access when a regulatory inspection or product complaint investigation requires it years later.

This risk is rarely visible at the time of retirement because the data still exists on a server or backup. It becomes visible only when someone actually needs to retrieve and reproduce a specific historical record and discovers the archival plan did not account for long-term readability, audit trail preservation, or viewing-tool availability.