Computerized System Periodic Review and Retirement

Computerized systems should remain suitable for their approved GxP use throughout their operational life. Initial validation establishes that suitability before release; periodic review confirms that changes, incidents, security conditions, supplier developments, and operating experience have not undermined it.

Periodic review should produce a decision, not merely a completed checklist. The system may remain acceptable, require remediation or revalidation, need restricted use, or require replacement and retirement.

Retirement is also a controlled lifecycle activity. Deactivating an application does not eliminate responsibility for its regulated records. Data, metadata, audit trails, electronic signatures, attachments, and relationships may need to remain protected and retrievable long after routine processing ends.

Purpose of Periodic Review

Periodic review provides documented confirmation that:

• the approved intended use remains current;
• the system inventory and ownership are accurate;
• the production configuration remains controlled;
• significant changes were properly assessed;
• deviations, defects, and incidents remain acceptable;
• users and privileged accounts remain appropriate;
• audit trails and electronic records remain reliable;
• interfaces continue to operate correctly;
• backup and restoration remain effective;
• performance and capacity remain adequate;
• supplier support and cybersecurity risks are controlled;
• procedures and training remain current;
• the system remains technically supportable; and
• continued use remains justified.

The review should identify adverse trends, cumulative changes, obsolete components, overdue actions, and control weaknesses that may not be evident from a single incident or change record.

Periodic-Review Frequency

There is no single review frequency suitable for every computerized system. The organization should establish and justify the interval according to risk. Frequency should consider:

• patient-safety and product-quality impact;
• data criticality;
• system complexity;
• configuration and customization;
• rate of supplier releases;
• frequency of internal changes;
• cybersecurity exposure;
• incident history;
• number and criticality of interfaces;
• supplier capability and support status;
• technology maturity;
• system availability requirements;
• record-retention obligations; and
• results of previous reviews.

A high-impact system undergoing frequent configuration and supplier changes may require annual review. A stable, well-controlled supporting system may justify a longer interval.

The review may also be triggered before the planned date by:

• a significant incident;
• recurring deviations;
• a major upgrade;
• a cybersecurity event;
• supplier end-of-support notification;
• repeated interface failures;
• restoration failure;
• ownership change;
• intended-use expansion; or
• evidence that the validated state may have been lost.

The approved procedure should define review intervals, allowable extensions, escalation requirements, and responsibility for scheduling and completion.

Periodic-Review Scope and Planning

The review scope should reflect the system boundary and its actual operating model. It should identify:

• system and process owners;
• review period;
• production environments;
• application components;
• infrastructure dependencies;
• connected systems;
• cloud or supplier services;
• regulated processes;
• regulated records;
• previous review conclusions;
• outstanding commitments; and
• required reviewers.

The review should use evidence from the entire period rather than only the system’s condition on the review date.

A review limited to confirmation of the installed software version will not establish that access, audit trails, interfaces, recovery, procedures, supplier services, and electronic records remain controlled.

Intended Use and GxP Classification

The approved intended use should be compared with current operations. The review should determine whether:

• new business processes have been introduced;
• additional sites or departments use the system;
• new modules or workflows have been activated;
• new reports or calculations support regulated decisions;
• new record types are maintained;
• interfaces have changed;
• responsibilities have shifted between systems;
• a previously supporting system now performs a direct GxP function; or
• functions are used outside their validated scope.

Changes in intended use may require revision of requirements, GxP classification, Part 11 assessment, risk assessment, validation scope, procedures, or training.

The classification principles in Computerized System Types, Intended Use, and GxP Classification should be reapplied when use, records, processes, or system boundaries have changed.

System Inventory and Ownership

Periodic review should confirm that the system inventory remains accurate. The inventory should identify, as applicable:

• system name and identification number;
• application and component versions;
• business process;
• intended use;
• production status;
• system owner;
• process owner;
• technical owner;
• Quality oversight;
• supplier;
• hosting model;
• GxP classification;
• Part 11 applicability;
• regulated record types;
• authoritative record source;
• interfaces;
• validation status;
• support status;
• review status; and
• planned retirement date.

Ownership gaps should be resolved. A production system should not remain in regulated use without accountable process, system, technical, and record owners.

Inactive systems retaining regulated records should remain in the inventory until their data obligations have been transferred or formally concluded.

Configuration Baseline

The current production configuration should be compared with the approved baseline. The baseline may include:

• application versions;
• enabled modules;
• workflows;
• business rules;
• calculations;
• reports;
• interface mappings;
• roles and permissions;
• audit-trail settings;
• electronic-signature settings;
• master data;
• custom code;
• scripts;
• database versions;
• infrastructure components;
• certificates;
• backup agents; and
• monitoring tools.

Unexplained differences may indicate incomplete change control or unauthorized modification.

The review should confirm that the baseline remains sufficiently detailed to support incident investigation, regression testing, restoration, supplier support, migration, and retirement.

Changes and Cumulative Change

The review should examine changes implemented since the previous review or initial release. It should confirm that:

• changes were approved;
• impact assessments were adequate;
• required specifications were updated;
• testing and regression testing were completed;
• deviations were resolved;
• migration was reconciled;
• procedures and training were updated;
• releases were authorized; and
• the production baseline was revised.

The process defined in Computerized System Change Control, Patching, and Revalidation should address individual changes. Periodic review should also consider their cumulative effect.

Several minor changes may collectively:

• alter intended use;
• increase configuration complexity;
• create undocumented dependencies;
• weaken traceability;
• invalidate previous assumptions;
• affect performance;
• create inconsistent controls; or
• justify broader revalidation.

Deviations, Defects, and Open Actions

The review should examine:

• validation deviations;
• production incidents;
• known defects;
• recurring user errors;
• temporary workarounds;
• corrective actions;
• preventive actions;
• supplier defects;
• overdue commitments; and
• previous periodic-review actions.

Open defects should be evaluated for:

• current business impact;
• product-quality or patient impact;
• data-integrity risk;
• affected requirements;
• frequency of occurrence;
• effectiveness of workarounds;
• detectability;
• supplier resolution status;
• accumulated operating exposure; and
• continued acceptability.

A defect accepted during release may become unacceptable if it recurs, affects more users, defeats a compensating control, or remains unresolved beyond the approved period.

User Access and Privileged Activity

Access review should confirm that:

• active accounts belong to current authorized users;
• terminated and transferred users have been removed or revised;
• roles match assigned responsibilities;
• least privilege is maintained;
• segregation of duties remains effective;
• privileged access is restricted;
• service accounts remain necessary;
• shared accounts are prohibited or formally controlled;
• emergency accounts are monitored;
• remote access is appropriate; and
• periodic access reviews were completed.

Privileged activity should receive particular attention because administrators may be able to alter configuration, security, records, audit trails, or database content.

The review should determine whether privileged actions are logged, independently reviewed, and investigated when unexpected. Detailed controls are addressed in User Access, Privileged Accounts, and Electronic Signatures.

Audit Trails and Data-Integrity Controls

The periodic review should determine whether required audit trails remain enabled, protected, retained, reviewable, and used effectively.

Evidence may include:

• audit-trail configuration;
• audit-trail review records;
• unexplained data changes;
• deleted or invalidated records;
• reprocessing;
• master-data changes;
• security changes;
• administrator activity;
• timestamp accuracy;
• review exceptions;
• investigations; and
• recurring trends.

The review should confirm that audit-trail review remains proportionate to record and process risk.

A configured audit trail does not provide effective control if it is not retained, cannot be searched, omits critical events, or is not reviewed when required. See Audit Trails, Data Changes, and Review Controls.

FDA’s Data Integrity and Compliance With Drug CGMP guidance states that firms should apply meaningful, risk-based strategies to manage data-integrity risks based on process understanding and knowledge of the technology and business model.

Incidents and Operational Performance

The review should evaluate system incidents for frequency, severity, recurrence, and trend. Relevant events include:

• system outages;
• slow performance;
• failed jobs;
• incomplete transactions;
• calculation errors;
• report failures;
• audit-trail failures;
• access-control failures;
• data corruption;
• interface errors;
• backup failures;
• restoration failures;
• cybersecurity events;
• capacity limitations; and
• repeated user-support requests.

Incident closure alone does not demonstrate continued control. Repeated low-severity incidents may indicate a design, configuration, training, supplier, infrastructure, or support weakness.

Performance evidence should be compared with approved operational requirements and service expectations.

Interfaces and Data Transfers

Interfaces should be reviewed because connected-system changes may affect an application even when the application itself has not changed. The review should consider:

• current source and destination systems;
• interface ownership;
• mappings and transformations;
• service accounts;
• certificates;
• rejected transactions;
• duplicates;
• delayed transfers;
• retransmissions;
• reconciliation results;
• technical logs;
• monitoring;
• recurring failures;
• middleware changes; and
• recovery procedures.

Changes to an authoritative source, field definition, code table, unit, precision, or status value can alter downstream records and decisions.

Interface controls are addressed further in Computerized System Interfaces and Data-Transfer Controls.

Backup, Restoration, and Business Continuity

Periodic review should assess whether backup and recovery arrangements remain suitable for the current system and data volume. The review should confirm:

• backup scope;
• backup frequency;
• retention;
• backup completion;
• failed-backup response;
• protected copies;
• encryption;
• configuration backup;
• audit-trail protection;
• restoration testing;
• restoration results;
• recovery-point objectives;
• recovery-time objectives;
• disaster-recovery testing;
• business-continuity procedures; and
• supplier responsibilities.

Successful backup jobs do not demonstrate recoverability. Restoration should be tested at a frequency and depth appropriate to system risk.

The evaluation should also consider whether new modules, databases, storage locations, cloud services, or interfaces were included in the recovery arrangements. See Backup, Restoration, Disaster Recovery, and Business Continuity.

Supplier Status and Service Performance

Supplier evidence should be reviewed for developments that can affect continued use. Relevant inputs include:

• release notices;
• known defects;
• security advisories;
• patches and hotfixes;
• supported-version information;
• end-of-support dates;
• product roadmaps;
• service changes;
• subcontractor changes;
• hosting changes;
• data-location changes;
• service-level reports;
• outage reports;
• disaster-recovery evidence;
• audit reports;
• certificate reports; and
• contract changes.

Service performance should be compared with contractual commitments for availability, support response, incident notification, backup, restoration, security, and data export.

Supplier evidence should be evaluated according to Computerized System Supplier Assessment and Evidence Leverage.

Patches, Vulnerabilities, and Cybersecurity

The review should confirm that supported versions, security patches, and vulnerability controls remain acceptable. It should evaluate:

• outstanding patches;
• patch deferrals;
• vulnerability severity;
• system exposure;
• unsupported components;
• operating-system status;
• database status;
• endpoint protection;
• firewall and segmentation controls;
• remote access;
• privileged access;
• security logs;
• malware events;
• certificate expiration;
• compensating controls; and
• documented risk acceptance.

A system should not be considered validated merely because its original configuration remains unchanged. Failure to address known vulnerabilities can jeopardize data integrity, availability, authentication, and recovery.

Procedures, Training, and Support

Periodic review should confirm that procedures reflect current system operation. Relevant procedures may address:

• routine use;
• record review;
• data correction;
• audit-trail review;
• access administration;
• master-data management;
• backup and restoration;
• interface monitoring;
• incident response;
• change control;
• business continuity;
• periodic review; and
• retirement.

Obsolete instructions, undocumented workarounds, or inconsistent site practices should be corrected.

Training should be reviewed for:

• current users;
• administrators;
• support personnel;
• reviewers;
• new or changed functions;
• revised procedures;
• recurring user errors; and
• role-specific responsibilities.

Support arrangements should remain adequate for operating hours, incident severity, supplier escalation, cybersecurity events, recovery, and inspection support.

Periodic-Review Conclusions

The review should produce one or more documented conclusions.

Continue Validated Use

Continued use may be approved when:

• intended use remains current;
• significant changes were controlled;
• open defects remain acceptable;
• access and data-integrity controls remain effective;
• backup and recovery remain suitable;
• supplier support remains adequate;
• cybersecurity risks are controlled;
• procedures and training remain current; and
• no unacceptable trend has been identified.

Approval should identify the next review date and any routine follow-up actions.

Remediation or Revalidation

Remediation may be required when the system remains usable but control weaknesses need correction. Actions may include:

• resolving defects;
• updating specifications;
• correcting configuration;
• revising procedures;
• retraining users;
• removing access;
• applying patches;
• improving monitoring;
• testing restoration;
• correcting interfaces;
• updating traceability; or
• performing targeted or broader revalidation.

Actions should have assigned owners, due dates, priority, interim controls, and escalation criteria.

Restricted or Conditional Continued Use

Continued use may require temporary restrictions when immediate retirement is impractical but identified risks can be controlled. Restrictions may limit:

• functions;
• modules;
• interfaces;
• user groups;
• transaction types;
• products;
• sites;
• data entry; or
• operating periods.

The justification should define compensating controls, monitoring, ownership, duration, and withdrawal criteria.

Replacement or Retirement Planning

Replacement or retirement should be considered when:

• the supplier ends support;
• security vulnerabilities cannot be controlled;
• infrastructure is obsolete;
• recovery is unreliable;
• recurring failures affect operations or records;
• required functionality cannot be maintained;
• the system no longer supports intended use;
• cumulative customization prevents sustainable support;
• records cannot be retained or retrieved reliably; or
• remediation is disproportionate to remaining business value.

The decision should consider both the risk of continued use and the risk introduced by replacement, migration, or retirement.

Continued-Use Justification

An obsolete or unsupported system may sometimes need to remain operational temporarily. The justification should document:

• business need;
• affected GxP processes;
• remaining life expectancy;
• known defects and vulnerabilities;
• supplier limitations;
• infrastructure risks;
• data-retention obligations;
• available compensating controls;
• enhanced monitoring;
• backup and recovery status;
• access restrictions;
• replacement plan;
• responsible owner;
• target retirement date; and
• authorized risk acceptance.

Continued use should not be justified only by cost, schedule, or the statement that no incidents have occurred.

Retirement Planning

Retirement planning should begin before technical shutdown. The retirement plan should identify:

• system and process owners;
• retirement reason;
• approved retirement date;
• affected business processes;
• replacement system;
• regulated records;
• retention requirements;
• authoritative record sources;
• interfaces;
• data migration or archival;
• user access;
• supplier responsibilities;
• infrastructure dependencies;
• licenses and contracts;
• procedures;
• business continuity;
• verification activities;
• approval responsibilities; and
• post-retirement ownership.

The system should remain under change control until retirement is approved and completed.

Record and Data Assessment

Before retirement, the organization should determine what information must remain available. The assessment should identify:

• original records;
• metadata;
• audit trails;
• electronic signatures;
• attachments;
• record relationships;
• calculations;
• processing methods;
• configuration;
• master data;
• reports;
• raw data;
• retention periods;
• legal holds;
• inspection needs; and
• record owners.

A final report or PDF may not be an adequate replacement for a dynamic electronic record if metadata, audit trails, processing history, or relationships are required to reconstruct the regulated activity.

Record-lifecycle controls are addressed in Electronic Records Lifecycle, Retention, and Archival.

Archival, Export, or Migration

Retirement data may be:

• retained in the original system;
• archived in a controlled repository;
• exported in readable and structured formats;
• migrated to a replacement system; or
• managed through a combination of approaches.

The selected approach should preserve record meaning, integrity, context, and accessibility.

Where migration is required, the controls in Computerized System Data Migration Validation should be applied.

The retirement plan should define:

• included and excluded records;
• data mappings;
• transformations;
• metadata handling;
• audit-trail handling;
• electronic-signature treatment;
• attachments;
• relationships;
• file formats;
• indexes;
• search capability;
• exception handling;
• reconciliation;
• sampling;
• content comparison;
• acceptance criteria; and
• rollback.

Reconciliation and Retrieval Verification

Retirement should not proceed solely because an export or migration process completed successfully. Verification should demonstrate that:

• expected records were transferred;
• record counts reconcile;
• control totals agree;
• sampled content is accurate;
• metadata remain associated;
• attachments open correctly;
• relationships remain intact;
• audit trails are available where required;
• electronic signatures remain meaningful;
• records remain readable;
• search and retrieval operate;
• inspection copies can be produced; and
• retention protections are effective.

Retrieval should be tested using representative record types and realistic requests.

Access Removal and Interface Shutdown

After required data and processes are accepted in their new state, system access and connections should be removed in a controlled sequence. Activities may include:

• disabling user accounts;
• removing privileged access;
• disabling service accounts;
• revoking certificates;
• terminating remote access;
• stopping scheduled jobs;
• disabling inbound interfaces;
• draining message queues;
• reconciling final transactions;
• disabling outbound interfaces;
• updating monitoring;
• removing automated reports; and
• notifying connected-system owners.

Interfaces should not be disabled before pending transactions and reconciliation requirements are resolved.

Infrastructure Decommissioning

Infrastructure should be decommissioned only after the organization confirms that required records, configuration, and recovery evidence have been preserved. Decommissioning may include:

• application removal;
• database shutdown;
• server or virtual-machine removal;
• cloud-resource termination;
• storage release;
• network-rule removal;
• certificate revocation;
• license termination;
• backup-job removal;
• monitoring removal;
• equipment disposition; and
• secure media sanitization.

Shared infrastructure should not be removed until the impact on every dependent system has been assessed.

Backup copies should be handled according to approved retention and disposition requirements. Retirement of the production application does not automatically authorize deletion of retained backup or archival records.

Retention and Long-Term Accessibility

Regulated records should remain accurate, complete, protected, and retrievable throughout their required retention period.

Under 21 CFR 11.10, closed-system controls include protection of records for accurate and ready retrieval, accurate and complete copies, access limitation, audit trails, and controls over system documentation.

For drug-manufacturing records, 21 CFR 211.180 establishes record-retention and availability requirements. Applicable retention periods depend on the record and governing predicate rule.

Long-term access should consider:

• proprietary formats;
• database dependencies;
• encryption keys;
• authentication services;
• viewer applications;
• operating-system compatibility;
• storage-media life;
• index integrity;
• migration needs;
• retrieval testing;
• record ownership; and
• technical support.

Keeping an obsolete application available indefinitely is not necessarily an effective archival strategy. Its dependencies may become unsupported, insecure, or impossible to recover.

Retirement Approval and Closure

Retirement closure should confirm that:

• retirement activities were completed;
• required records were retained, archived, exported, or migrated;
• reconciliation and retrieval testing were accepted;
• open exceptions were resolved;
• access was removed;
• interfaces were disabled and reconciled;
• infrastructure was decommissioned appropriately;
• contracts and licenses were addressed;
• procedures were revised;
• users were notified;
• the system inventory was updated;
• record ownership was assigned;
• residual obligations were documented; and
• required Quality and business approvals were obtained.

The closure record should identify where records now reside, who owns them, how they are retrieved, how long they must be retained, and how future technology changes will be managed.

Practical Lifecycle Outcome

Periodic review and retirement should operate as connected lifecycle controls. Periodic review establishes whether the system remains:

• suitable for intended use;
• appropriately validated;
• secure and supportable;
• capable of protecting regulated records;
• operationally reliable; and
• justified for continued use.

When continued use is no longer acceptable or sustainable, retirement should preserve the records and evidence required to reconstruct regulated activities while removing obsolete technology and access in a controlled manner.

The final outcome should establish:

• the current status of the system;
• accepted risks and required actions;
• whether remediation or revalidation is required;
• whether continued use is justified;
• when replacement or retirement will occur;
• where regulated records will reside;
• how records will remain retrievable; and
• who owns the remaining lifecycle obligations.