Electronic Records Lifecycle, Retention, and Archival

Electronic records must remain complete, accurate, readable, retrievable, and protected throughout their required retention period. These obligations apply from the moment information is created or captured through processing, review, approval, reporting, transfer, storage, archival, migration, and approved disposition.

Effective record control requires more than saving a report or retaining a database backup. The organization must understand what constitutes the complete record, where the aut

horitative record resides, which metadata and system functions are needed to interpret it, who owns it, and how it will remain accessible when technologies change.

Electronic-Record Lifecycle

The electronic-record lifecycle includes five connected stages:

1. creation and capture;
2. processing and review;
3. approval and reporting;
4. retention and retrieval; and
5. archival, migration, or controlled disposition.

Controls should remain continuous when a record moves between systems, changes format, enters an archive, or is retained after its originating application is retired. Each handoff should preserve the record’s content, context, meaning, authenticity, and traceability.

Record Creation and Capture

Records should be created or captured at the time the regulated activity is performed. The system should associate the record with the responsible user, date and time, relevant process or transaction, and any required identifiers. Controls may include:

• unique user identification;
• controlled system time;
• required data fields;
• input-format and range controls;
• automatic data capture from instruments or equipment;
• record and sample identifiers;
• electronic signatures;
• status controls;
• audit trails; and
• prevention of unauthorized deletion or overwriting.

Where information is transferred from paper or another electronic source, the organization should define whether the new record is a transcription, scanned copy, verified true copy, or new authoritative record. Verification should be proportionate to the possibility and consequence of transcription or transfer errors.

Temporary files, local workstation files, instrument buffers, middleware messages, and manually maintained staging records should be evaluated. They should not be excluded merely because they are not visible in the final report.

Processing and Transformation

Electronic records may be calculated, filtered, transformed, normalized, reprocessed, or combined with other data. Processing should occur through approved methods that preserve the relationship between source data, processing parameters, results, and subsequent changes.

The retained record should include, where relevant:

• original captured values;
• calculation methods;
• formulas and algorithms;
• processing parameters;
• integration or interpretation settings;
• reference and lookup data;
• software or method versions;
• excluded or invalidated values;
• reprocessing history;
• reasons for changes;
• associated audit trails; and
• the identity of the person performing or approving the processing.

A final result without the information needed to reconstruct its derivation may not constitute the complete record.

Custom calculations, scripts, reports, data transformations, and interface mappings should be specified, verified, version-controlled, and managed through Computerized System Change Control, Patching, and Revalidation.

Review and Approval

Record review should confirm both the reported result and the supporting electronic evidence. Depending on risk and intended use, review may include:

• source data;
• metadata;
• calculations;
• processing methods;
• excluded or reprocessed data;
• changes and audit trails;
• electronic signatures;
• exceptions;
• interface messages;
• attachments; and
• approval history.

The system should identify the current record status and distinguish drafts, reviewed records, approved records, superseded versions, invalidated records, and archived records.

Approval should be attributable to an authorized individual and linked to the approved record. A subsequent change should not silently alter previously approved information. The effect of changes on record status, signatures, reports, and downstream systems should be defined and tested.

Related controls are addressed in User Access, Privileged Accounts, and Electronic Signatures and Audit Trails, Data Changes, and Review Controls.

Reports, Exports, and Record Copies

Reports and exports should present accurate and complete information for their intended purpose. Their content should be verified against the authoritative electronic record, particularly when filtering, calculations, conversions, or formatting are applied.

A report may be an appropriate retained record when it preserves everything necessary to understand and verify the regulated activity. It may be insufficient when important information remains only in the originating system, such as:

• interactive processing capability;
• underlying raw data;
• relevant metadata;
• audit trails;
• calculation parameters;
• attachments;
• electronic-signature links;
• excluded results; or
• relationships between records.

FDA explains that a static printout may not preserve the complete content of a dynamic laboratory record when the electronic record allows further interaction or reprocessing. The appropriate retained format therefore depends on the record’s nature and intended regulatory use. See FDA’s Data Integrity and Compliance With Drug CGMP guidance.

Record Transfer and Interfaces

Records may move between instruments, applications, middleware, repositories, archives, and external service providers. Transfer controls should preserve completeness, accuracy, context, and traceability.

Controls should address:

• source and destination identification;
• authoritative source;
• record and field mapping;
• data formats and units;
• numerical precision;
• metadata;
• timestamps and time zones;
• electronic signatures;
• attachments and relationships;
• acknowledgments;
• rejected or duplicate messages;
• reconciliation;
• transfer logs;
• security; and
• exception handling.

The transfer process should be verified end to end. Confirmation that a file was sent does not establish that every record was received, interpreted correctly, associated with the correct object, and made available to authorized users.

See Computerized System Interfaces and Data-Transfer Controls for a detailed interface-control framework.

Storage and Protection

Electronic records should be protected against unauthorized access, alteration, deletion, corruption, and loss. Controls should remain effective throughout active use and long-term retention. Storage controls may include:

• role-based access;
• segregation of administrative responsibilities;
• protected repositories;
• encryption where appropriate;
• file-integrity monitoring;
• database controls;
• audit trails;
• replication;
• operational backup;
• restoration testing;
• environmental monitoring;
• retention locks;
• write-once controls where justified; and
• monitoring of storage capacity and failures.

Record protection should not prevent authorized retrieval or migration. An archive that is secure but no longer readable does not satisfy its retention objective.

Under 21 CFR 11.10, closed systems must include controls for the protection of records to enable their accurate and ready retrieval throughout the record-retention period.

Metadata

Metadata provides the context needed to interpret an electronic record. Relevant metadata may include:

• user identity;
• date and time;
• time zone;
• instrument or system identifier;
• record status;
• units;
• method or specification version;
• processing parameters;
• file relationships;
• electronic signatures;
• audit-trail entries;
• approval history;
• data origin;
• transfer history; and
• version information.

Metadata should remain linked to the corresponding record. Exporting only visible values may remove the information needed to establish who performed an action, how a result was produced, whether it changed, and which approved method applied.

The necessary metadata should be identified through intended-use and data-risk assessment rather than by retaining every technical log indefinitely.

Dynamic and Static Records

A dynamic record retains functionality that allows interaction with the data. Examples may include the ability to:

• search and filter;
• change the displayed scale;
• review embedded metadata;
• inspect audit trails;
• recalculate;
• reprocess;
• expand underlying results; or
• examine relationships between data objects.

A static record is a fixed representation, such as an approved PDF or printed report. It presents information in a fixed format and normally does not preserve interactive or reprocessing capability.

Static retention can be appropriate when the fixed representation contains the complete information and context needed for the applicable record. It is not appropriate when dynamic functionality is necessary to reconstruct, evaluate, or verify the regulated activity.

The format decision should be documented and based on record content, intended use, risk, metadata, processing capability, inspection needs, and the possibility of future investigation.

Original Electronic Records

The original electronic record is the first capture of information in the form in which it was generated or received, together with the metadata necessary to understand it. The original may reside in:

• an analytical instrument;
• a manufacturing-control system;
• a laboratory application;
• a quality-management system;
• an enterprise application;
• a database;
• a controlled file repository; or
• another validated record system.

The authoritative original should be identified. Uncontrolled local copies or exported reports should not create uncertainty about which version is official.

When the original system cannot retain records for the required period, the organization may transfer records to a controlled repository or archive. The transfer must preserve required content, metadata, relationships, authenticity, and readability.

Verified True Copies

A true copy is an accurate and complete copy of an original record that retains the record’s content, meaning, and required context. It may be retained in the same format as the original or in a different format when the conversion does not remove required information or functionality.

A controlled true-copy process should define:

• the original record;
• the copying or conversion method;
• required content and metadata;
• verification responsibilities;
• acceptance criteria;
• traceability to the original;
• exception handling;
• approval;
• protection of the verified copy; and
• disposition of the original, where permitted.

If dynamic functionality is necessary to evaluate the record, a static copy may not be a complete true copy. The organization may need to retain native data, a validated viewer, relevant software functionality, or a controlled equivalent.

The UK MHRA’s GxP data-integrity guidance discusses original records, true copies, metadata, and the importance of preserving dynamic record functionality.

Record Ownership

Each regulated record type should have an assigned owner. Record ownership should not be left solely to Information Technology or the application supplier.

The record owner should ensure that:

• the record type is defined;
• the authoritative source is identified;
• the complete-record content is understood;
• retention requirements are assigned;
• access is appropriate;
• legal holds can be applied;
• retrieval remains possible;
• migrations are approved;
• archival controls remain effective; and
• destruction is authorized.

The process owner normally determines the record’s business and regulatory significance. The system owner maintains the controlled system and its technical capabilities. Information Technology supports storage, security, backup, recovery, and infrastructure. The Quality unit provides appropriate oversight of regulated retention, migration, and disposition decisions.

Supplier or cloud-provider responsibilities should be defined contractually without transferring the regulated organization’s accountability for its records.

Retention Schedules

A controlled retention schedule should identify:

• record category;
• applicable process;
• responsible owner;
• authoritative system or repository;
• regulatory and business basis;
• retention period;
• event that starts the retention period;
• required format;
• required metadata;
• retrieval expectations;
• legal-hold applicability;
• archival method; and
• approved disposition method.

Retention periods may be based on manufacture, release, expiry, study completion, equipment retirement, employee qualification, submission status, complaint closure, or another defined event.

The schedule should address records in active systems, archives, legacy applications, external services, migrated repositories, and approved true-copy arrangements.

Under 21 CFR 211.180, specified GMP records must be retained for defined periods and remain readily available for authorized inspection.

Legal Holds

A legal hold suspends normal destruction when records may be relevant to litigation, investigation, regulatory action, inspection commitment, product-quality issue, or another formal preservation requirement.

The legal-hold process should identify:

• the affected records and systems;
• applicable date ranges;
• record owners;
• custodians;
• repositories and archives;
• copies held by suppliers;
• backup limitations;
• access restrictions;
• hold notification;
• confirmation of implementation;
• monitoring; and
• authorized release of the hold.

Applying a hold only to visible reports may be inadequate when relevant metadata, audit trails, attachments, messages, or source data remain elsewhere.

Disposition should remain blocked until the responsible legal or authorized function formally releases the hold.

Controlled Archival

Archival is the controlled preservation of records for long-term retention after they are no longer needed for routine processing. An archive should provide:

• complete record transfer;
• verified ingestion;
• preservation of required metadata;
• record-level indexing;
• ownership;
• access control;
• tamper protection;
• retention rules;
• legal-hold capability;
• readable retrieval;
• auditability;
• periodic retrieval testing;
• migration capability; and
• controlled disposition.

Archival does not necessarily require a separate application. An operational system may serve as the retained-record environment if it remains supported, secure, readable, controlled, and capable of meeting retention requirements.

The archival decision should consider future investigations, inspections, product complaints, stability evaluation, trend analysis, and the need to reconstruct historical decisions.

Indexing and Search

Archived records should be indexed sufficiently to support accurate and timely retrieval. Index fields may include:

• record type;
• record identifier;
• product;
• material;
• batch or lot;
• sample;
• study;
• equipment;
• facility;
• process;
• owner;
• creation date;
• approval date;
• retention category;
• disposition date; and
• legal-hold status.

Indexes should be verified during transfer and migration. Incorrect indexing can make an intact record functionally unavailable.

Search results should distinguish authoritative records from convenience copies, drafts, obsolete versions, and superseded reports.

Readable Archival

Records must remain human-readable and interpretable throughout their required retention period. This includes the ability to understand values, units, dates, signatures, status, relationships, metadata, and processing history.

Long-term readability may require:

• retained native applications;
• validated viewers;
• documented file specifications;
• controlled conversion to sustainable formats;
• database extracts with data dictionaries;
• retained code tables;
• emulation or virtualization;
• migrated archives; or
• supplier-supported export tools.

A readable PDF may preserve a static report but may not preserve a dynamic record’s underlying structure, metadata, audit history, or reprocessing capability.

The archival strategy should be established before software or storage technology becomes obsolete.

Retrieval and Retrieval Testing

The organization should define how quickly different record types must be retrieved and in what form they must be provided.

Retrieval testing should confirm that authorized personnel can:

• locate the correct record;
• retrieve it within the expected time;
• open and read it;
• access required metadata;
• display signatures and audit history;
• understand coded values;
• verify attachments and relationships;
• produce an accurate and complete copy; and
• demonstrate the record’s authenticity and integrity.

Testing should use representative records of different ages, formats, systems, and retention categories. Successful technical restoration of files does not demonstrate that individual regulated records can be found and interpreted.

Failures should be investigated and may require remediation, migration, additional indexing, viewer replacement, or restoration of missing metadata.

Proprietary Formats

Proprietary record formats create dependency on specific software, versions, licenses, suppliers, and technical environments. The retention strategy should consider:

• availability of the native application;
• backward compatibility;
• supported viewers;
• required licenses;
• operating-system dependencies;
• database dependencies;
• encryption keys;
• documentation of the format;
• export capabilities;
• supplier viability; and
• conversion options.

A proprietary format may be acceptable when the organization can demonstrate continued access and readability. Risk increases when only the supplier can interpret or export the record.

Supplier contracts should address data ownership, complete export, metadata, audit trails, readable formats, termination support, and access following supplier failure.

Legacy Applications and Technology Obsolescence

A retired or unsupported application may remain GxP-relevant when it holds records that have not completed their required retention period. The organization should decide whether to:

• maintain the legacy application;
• isolate and secure it;
• virtualize the required environment;
• retain a validated viewer;
• migrate records;
• create verified true copies;
• or maintain a controlled combination of these measures.

Continued use should address:

• cybersecurity risk;
• unsupported operating systems;
• hardware failure;
• unavailable expertise;
• expired licenses;
• obsolete databases;
• inaccessible encryption keys;
• supplier failure;
• deteriorating media; and
• inability to restore the environment.

Legacy arrangements should be periodically reviewed. A decision to retain a legacy system should include documented justification, ownership, access controls, retrieval testing, backup or recovery arrangements, and an exit strategy.

Record Migration

Migration may be required when replacing an application, changing suppliers, consolidating archives, or responding to technology obsolescence. Migration controls should address:

• record scope;
• inclusion and exclusion rules;
• source assessment;
• field and object mapping;
• metadata;
• attachments;
• signatures;
• audit trails;
• relationships;
• transformations;
• legacy codes;
• migration tools;
• dry runs;
• counts and control totals;
• content comparison;
• exceptions;
• reconciliation;
• acceptance;
• rollback; and
• disposition of the source system.

Migration should preserve meaning, not merely values. A code such as “A,” “03,” or “REL” is not meaningful unless its historical definition and context remain available.

Detailed controls are addressed in Computerized System Data Migration Validation.

Boundary Between Operational Backup and Archival

Operational backup and regulated archival serve different purposes.

Backup supports restoration after data loss, system failure, corruption, or disaster. Backup sets are commonly organized around systems, databases, storage volumes, or recovery points. They may be overwritten according to a rotational schedule and may require restoration into a compatible technical environment.

Archival preserves identifiable regulated records throughout their required retention period. An archive should support record ownership, indexing, search, legal holds, controlled access, readable retrieval, migration, and approved disposition.

A backup is therefore not automatically an archive. Backup media may lack:

• record-level indexing;
• ready retrieval;
• complete application context;
• readable presentation;
• legal-hold controls;
• long-term format support;
• record-specific retention rules; and
• controlled destruction approval.

Backup may support an archival solution, but it should not be presented as the sole retention control unless the organization demonstrates that it satisfies every applicable record-retention and retrieval requirement.

Operational backup, restoration, disaster recovery, and continuity controls should be addressed separately through Backup, Restoration, Disaster Recovery, and Business Continuity.

Controlled Disposition and Destruction

Electronic records should not be destroyed merely because a system is being replaced, storage is full, a supplier contract is ending, or information appears to have been copied elsewhere.

Before disposition, the organization should confirm that:

• the required retention period has expired;
• no legal hold applies;
• no investigation or regulatory commitment requires continued retention;
• the correct records have been identified;
• related records and metadata have been considered;
• migration or true-copy acceptance is complete;
• the authoritative source is clear;
• destruction is technically feasible;
• supplier-held copies are addressed; and
• authorized approval has been obtained.

Approval responsibilities should be defined by record type and may include the record owner, process owner, Quality unit, legal function, records-management function, and system owner.

Destruction should be secure, documented, and verifiable. The disposition record should identify what was destroyed, its retention category, the applicable date range, the authorization, the method, the date, and any exceptions.

Where destruction cannot be selective because records share a database or backup set, the limitation and compensating controls should be documented.

Lifecycle Review

Periodic review should confirm that electronic-record controls remain effective. Review inputs should include:

• record ownership;
• retention schedules;
• archival inventory;
• legal holds;
• access controls;
• retrieval-test results;
• failed retrievals;
• format and viewer support;
• supplier status;
• storage capacity;
• cybersecurity vulnerabilities;
• legacy-system risks;
• migrations;
• destruction records; and
• regulatory or business changes.

Issues should be assessed for their effect on record integrity, readability, availability, and the validated state. Remediation may include reindexing, access correction, viewer replacement, migration, additional verification, procedural changes, or revalidation.

These activities should be coordinated with Computerized System Periodic Review and Retirement.

Maintaining Trustworthy Electronic Records

An effective electronic-record strategy ensures that regulated information remains trustworthy for as long as it is required—not merely while the originating system remains in production.

The organization should be able to demonstrate:

• what constitutes the complete record;
• where the authoritative record resides;
• which metadata and functionality must be preserved;
• who owns the record;
• how long it must be retained;
• how legal holds are applied;
• how the record is protected;
• how it can be retrieved and interpreted;
• how technology changes are managed;
• how migrations are verified; and
• how final disposition is approved.

These controls support the ALCOA+ data-integrity principles of completeness, consistency, endurance, and availability while remaining grounded in the risks and requirements of each computerized system.