ALCOA+ Data-Integrity Principles and System Controls

Reliable pharmaceutical decisions depend on records that accurately represent the work performed. Laboratory results, manufacturing parameters, environmental-monitoring records, quality events, equipment data, calculations, approvals, and electronic signatures must retain their meaning and integrity throughout the data lifecycle.

ALCOA+ provides a practical framework for evaluating these records. Data should be:

• attributable;
• legible;
• contemporaneous;
• original;
• accurate;
• complete;
• consistent;
• enduring; and
• available.

ALCOA+ applies to paper records, electronic records, hybrid arrangements, instruments, computerized systems, interfaces, reports, spreadsheets, and manually entered data. It is not limited to deliberate falsification. Poor system configuration, weak procedures, shared accounts, uncontrolled worksheets, incomplete metadata, inadequate review, failed interfaces, and unreliable archival can also undermine data integrity.

The framework should be converted into specific technical controls, procedures, responsibilities, verification activities, and review evidence. Merely stating that a system “complies with ALCOA+” does not demonstrate that its records are reliable.

The FDA describes data integrity as the completeness, consistency, and accuracy of data and identifies attributable, legible, contemporaneously recorded, original or true-copy, and accurate records as important characteristics. FDA’s expectations are explained in its Data Integrity and Compliance With Drug CGMP guidance.

ALCOA and the Plus Principles

The original ALCOA principles are attributable, legible, contemporaneous, original, and accurate. The “plus” principles—complete, consistent, enduring, and available—emphasize expectations that are already necessary for reliable regulated records.

The MHRA GxP Data Integrity Guidance explains that there is no fundamental difference between ALCOA and ALCOA+. The additional terms emphasize the full lifecycle expectations placed on regulated data.

ALCOA+ should be applied collectively. A record can be attributable but incomplete, accurate but unavailable, or legible but lacking essential metadata. Meeting one principle does not compensate for failure to meet another.

Attributable

A record is attributable when the person, system, instrument, or interface responsible for creating or changing it can be identified.

Relevant controls

Technical controls may include:

• unique user accounts;
• authenticated access;
• role-based permissions;
• electronic signatures;
• user and system timestamps;
• secure audit trails;
• instrument identification;
• interface source identification;
• service-account controls; and
• administrator-activity logging.

Procedural controls should define account creation, modification, suspension, removal, privileged access, data entry, corrections, electronic signatures, and review responsibilities.

Human factors are equally important. Users must understand that credentials represent their individual identity and must not be shared. Supervisors should not instruct employees to use another person’s account or perform undocumented work outside the approved system.

Common failures

Typical failures include:

• shared user accounts;
• generic analyst logins;
• records created under an administrator account;
• signatures added by another person;
• service accounts used for interactive work;
• paper entries without initials or signatures;
• interfaces that overwrite the original source identity; and
• audit trails that record only a technical account rather than the responsible user.

Review and verification

Verification should confirm that accounts are unique, user identity appears on applicable records, electronic signatures are correctly manifested, interface records retain source attribution, and privileged activity can be traced.

Review evidence may include access records, audit trails, signature records, interface logs, account-management records, and periodic access reviews.

Further controls are addressed in User Access, Privileged Accounts, and Electronic Signatures.

Legible

A record is legible when it can be read, interpreted, and understood throughout its retention period. Legibility involves more than visible characters. The record must retain sufficient context to explain what was measured, calculated, changed, reviewed, and approved.

Relevant controls

Controls may include:

• readable displays and reports;
• controlled terminology and units;
• permanent entries;
• clear correction practices;
• preserved record structure;
• retained metadata;
• accessible audit trails;
• controlled report templates;
• maintained software or suitable viewers;
• migration controls; and
• retrieval testing.

For paper records, entries should be made with durable media and corrections should preserve the original entry. For electronic records, proprietary formats, discontinued software, unsupported operating environments, or missing metadata can make apparently retained data unusable.

Common failures

Failures include:

• illegible handwriting;
• unexplained abbreviations;
• overwritten paper entries;
• truncated reports;
• missing units;
• unreadable scanned records;
• exported files without field definitions;
• archived data that cannot be opened;
• reports that omit required metadata; and
• electronic records retained without a compatible viewer.

Review and verification

Verification should demonstrate that records can be retrieved and understood by an independent reviewer. Testing should include representative records, reports, attachments, metadata, audit trails, and archived formats.

Contemporaneous

A record is contemporaneous when it is created at the time the activity is performed or when the observation is made.

Where immediate recording is not technically possible, the approved process should define how information is temporarily captured, transferred, verified, and reconciled without creating an undocumented period.

Relevant controls

Technical controls may include:

• automatic data capture;
• secure system timestamps;
• synchronized clocks;
• time-zone controls;
• sequence enforcement;
• electronic worksheets;
• mobile data capture;
• interface timestamps; and
• controls preventing backdating.

Procedures should define when records must be entered and how delayed entries are documented. Personnel should have practical access to the required forms, terminals, devices, or applications where work occurs.

Common failures

Failures include:

• recording results from memory;
• completing records at the end of a shift;
• using unofficial notes for later transcription;
• entering actual values on a blank preapproved form after the activity;
• backdating entries;
• unsynchronized instrument clocks;
• pre-signing records; and
• delayed data transfer without reconciliation.

Review and verification

Review should compare event time, entry time, system time, audit-trail time, interface time, and approval time. Significant delays or unexpected sequences should be investigated.

Verification should challenge time synchronization, prohibited date changes, delayed-entry controls, and sequence restrictions.

Original

Original data is the first capture of information or the source record that preserves the content and meaning of the activity. An approved true copy may replace or supplement the original when it preserves the applicable data, metadata, context, and record relationships.

Original data is not always the first visible printout. For an analytical system, the complete original record may include native electronic data, metadata, processing methods, audit trails, result sets, and electronic signatures.

Relevant controls

Controls may include:

• direct instrument capture;
• controlled source-data designation;
• restricted deletion;
• protected raw-data storage;
• verified true-copy procedures;
• validated export functions;
• complete data migration;
• interface reconciliation; and
• documented authoritative-record ownership.

Common failures

Failures include:

• treating a summary report as the original record;
• deleting source files after printing;
• retaining only selected results;
• scanning paper records without verifying completeness;
• exporting values without metadata;
• replacing dynamic records with static PDFs;
• retaining processed results but not source data; and
• failing to identify the authoritative record in a hybrid process.

Review and verification

The assessment should identify where data originates, where it may be changed, where metadata and audit trails reside, and which record is relied upon for regulated decisions.

True-copy verification should confirm content, meaning, metadata, attachments, relationships, signatures, and readability—not merely visual similarity.

Accurate

A record is accurate when it correctly represents the observation, activity, calculation, transformation, or result. Accuracy depends on both the source data and every subsequent operation applied to it.

Relevant controls

Controls may include:

• calibrated instruments;
• validated software;
• input restrictions;
• range and format checks;
• controlled formulas;
• approved calculation methods;
• verified interfaces;
• master-data control;
• independent calculation checks;
• exception handling; and
• controlled rounding and unit conversion.

Procedures should define data entry, verification, calculation review, correction, exception handling, and approval.

Common failures

Failures include:

• transcription errors;
• incorrect formulas;
• unapproved calculations;
• wrong units;
• improper rounding;
• incorrect master data;
• failed interface mappings;
• uncontrolled spreadsheet formulas;
• inappropriate processing parameters; and
• results associated with the wrong batch, sample, or product.

Review and verification

Testing should challenge representative calculations, boundary values, decimal precision, unit conversion, data mapping, manual entries, error conditions, and unauthorized changes.

Review evidence may include source-data comparisons, calculation verification, interface reconciliation, method approval, calibration status, and investigation records.

Complete

Complete records include all information required to reconstruct and evaluate the activity. This may include accepted and rejected results, repeated tests, invalidated data, metadata, audit trails, calculations, attachments, review records, and reasons for changes.

Completeness does not mean retaining unrelated temporary system information. The organization should determine which data and metadata are necessary to reconstruct the regulated activity and support the associated decision.

Relevant controls

Controls may include:

• prevention of unauthorized deletion;
• retention of all relevant runs and injections;
• audit trails for changes and invalidation;
• sequence controls;
• exception reports;
• attachment controls;
• interface reconciliation;
• backup monitoring;
• migration reconciliation; and
• complete record export.

Common failures

Failures include:

• selective reporting;
• deleted failed runs;
• omitted aborted sequences;
• missing attachments;
• unrecorded repeat testing;
• incomplete audit trails;
• excluded metadata;
• missing interface transactions;
• undocumented data cleansing; and
• reports limited to final accepted results.

Review and verification

Reviewers should be able to identify the full sequence of activity, including unsuccessful attempts, changes, reprocessing, exclusions, and invalidations.

Verification should include negative testing, deletion restrictions, repeated processing, failed interfaces, incomplete transfers, and reconciliation.

Consistent

Consistent records maintain a coherent sequence, structure, terminology, and relationship across time and systems. Consistency does not require every system to use identical formats. It requires records to follow controlled conventions and maintain logical relationships.

Relevant controls

Controls may include:

• synchronized time services;
• controlled sequence numbers;
• standardized formats;
• master-data governance;
• status-transition rules;
• referential integrity;
• version control;
• interface mapping;
• controlled date and time formats; and
• chronological audit trails.

Common failures

Failures include:

• events recorded out of sequence;
• conflicting timestamps;
• different units across connected systems;
• duplicate identifiers;
• inconsistent product or material codes;
• uncontrolled template versions;
• status changes that bypass required workflow; and
• records that cannot be matched across interfaces.

Review and verification

Review should confirm logical chronology and relationships between source records, interfaces, calculations, reports, approvals, and audit trails.

Testing should address time synchronization, workflow sequence, master-data consistency, status transitions, duplicate prevention, and cross-system reconciliation.

Enduring

Enduring records remain protected and usable throughout the required retention period. A file is not enduring merely because it exists on storage media. It must remain secure, intact, readable, retrievable, and associated with the metadata needed to interpret it.

Relevant controls

Controls may include:

• protected storage;
• backup and restoration;
• resilient infrastructure;
• monitored storage capacity;
• controlled archival;
• supported formats;
• integrity verification;
• disaster recovery;
• migration planning;
• media management; and
• change control.

Common failures

Failures include:

• records stored only on local computers;
• removable media without control;
• unavailable backup copies;
• untested restoration;
• corrupt archives;
• unsupported proprietary formats;
• expired encryption certificates;
• retired systems without data disposition;
• storage capacity failures; and
• loss of audit trails during migration.

Review and verification

Verification should include restoration testing, archive retrieval, readable-format confirmation, metadata comparison, record-count reconciliation, and recovery from representative failure conditions.

Available

Available records can be retrieved promptly in a readable and understandable form for routine operations, investigations, product review, inspection, and regulatory submission. Availability must be maintained throughout the retention period, not only while the original system remains operational.

Relevant controls

Controls may include:

• indexed storage;
• defined retrieval methods;
• access authorization;
• suitable viewing tools;
• performance and capacity monitoring;
• backup and disaster recovery;
• service-level controls;
• archival procedures;
• legacy-system support; and
• tested data export.

Common failures

Failures include:

• records that exist but cannot be located;
• inactive user accounts blocking retrieval;
• unavailable legacy applications;
• incomplete exports;
• excessively slow archive searches;
• proprietary files without viewers;
• unavailable encryption keys;
• cloud termination without data export; and
• recovery procedures that have never been tested.

Review and verification

Periodic review should verify that representative records can be located, opened, interpreted, printed or exported where required, and associated with their metadata and audit trails.

Metadata and Record Context

Metadata provides the context required to understand data. It may identify:

• the user or system that created the record;
• date and time;
• instrument or device;
• method;
• units;
• calculation parameters;
• sample, batch, or material;
• status;
• version;
• relationships to other records;
• review and approval;
• and change history.

Without metadata, a value may be ambiguous or meaningless. The number “10,” for example, cannot be interpreted reliably without context such as the parameter measured, unit, method, time, and applicable object.

Metadata should be protected to the same extent as the data it explains. It should not be discarded merely because it does not appear on the final report.

Dynamic Records

A dynamic record allows interaction with the underlying data or retains functionality required to reconstruct the activity. Examples include:

• chromatographic data that can be reprocessed;
• spreadsheet records containing formulas;
• images that can be adjusted or measured;
• database records with linked metadata;
• electronic batch records with workflow history;
• and multidimensional analytical files.

A static PDF or printout may not constitute a complete copy when it omits functionality, metadata, audit trails, processing parameters, or relationships needed to understand the record.

The organization should determine whether a static representation is sufficient or whether the native dynamic record must be retained. The decision should be based on intended use, regulatory requirements, data criticality, record meaning, and the ability to reconstruct the regulated activity.

True Copies

A true copy is a copy that preserves the content and meaning of the original record. Depending on the record, this may require preservation of:

• data;
• metadata;
• date and time information;
• audit trails;
• electronic signatures;
• attachments;
• processing parameters;
• relationships;
• formatting;
• and dynamic functionality.

The true-copy process should be defined, controlled, and verified. Verification may use content comparison, record counts, checksums, metadata comparison, sampling, or validated transfer mechanisms.

A scanned paper record can be a true copy when the complete original is captured, the image remains readable, the copy is verified, and the process is controlled. A screenshot or incomplete report should not automatically be accepted as a true copy.

Original Data and the Authoritative Record

The authoritative record source should be defined for each critical record or data element. This determination should identify:

• where the record is created;
• where it can be modified;
• where metadata resides;
• where the audit trail resides;
• which system controls status;
• where review and approval occur;
• which version is retained;
• and which record is relied upon during an investigation or inspection.

Hybrid arrangements require particular care. Paper and electronic components should not compete as separate uncontrolled originals. Their relationship and combined record requirements should be documented.

Processing and Reprocessing

Processing converts source data into a result through approved methods, formulas, algorithms, parameters, or business rules. Reprocessing repeats or modifies that operation. Examples include:

• chromatographic integration;
• statistical processing;
• calculation of potency or yield;
• unit conversion;
• application of calibration factors;
• image analysis;
• report generation;
• and data transformation during transfer.

The system should preserve the source data, processing method, parameters, version, user, date and time, resulting output, and applicable reason for change.

Reprocessing should be:

• authorized;
• scientifically justified;
• traceable;
• performed using approved methods;
• included in the complete record;
• and subject to appropriate review.

Controls should prevent analysts from repeatedly changing processing parameters until a desirable result is obtained without visibility or justification.

Audit Trails and Data Changes

Audit trails support attribution, chronology, completeness, and review of electronic records. They should capture applicable creation, modification, deletion, invalidation, reprocessing, configuration, and master-data events.

An effective audit-trail entry may include:

• user identity;
• date and time;
• affected record;
• event performed;
• previous value;
• new value;
• and reason for change.

Audit trails do not create data integrity by themselves. They must be enabled, protected, retained, available, and reviewed where their information is relevant to the regulated decision.

Routine review should focus on meaningful events rather than indiscriminate review of every technical log entry. The scope and frequency should reflect data criticality, process risk, system capability, and the likelihood that another control would detect the failure.

Further requirements are addressed in Audit Trails, Data Changes, and Review Controls.

Review of Data and Records

Record review should evaluate more than the final reported result. Depending on risk and intended use, review may include:

• source data;
• critical metadata;
• calculations;
• methods and versions;
• processing and reprocessing;
• audit trails;
• invalidated or excluded data;
• sequence completeness;
• interface exceptions;
• electronic signatures;
• attachments;
• and deviations.

The reviewer should have sufficient independence, competence, information, and system access to detect relevant errors or inappropriate activity.

A review is not effective when the reviewer sees only a summary that conceals failed runs, changes, exceptions, or omitted metadata.

Retention, Archival, and Availability

Electronic records should remain protected, readable, and retrievable for the required retention period. Retention planning should address:

• native and readable formats;
• metadata;
• audit trails;
• electronic signatures;
• attachments;
• encryption keys;
• indexing;
• storage capacity;
• backup;
• restoration;
• technology obsolescence;
• legacy-system access;
• migration;
• and controlled disposition.

Backup supports recovery from loss or damage. It does not automatically provide compliant archival. Archival should preserve the record in a controlled form and support retrieval throughout the required period.

These distinctions are addressed further in Electronic Records Lifecycle, Retention, and Archival and Backup, Restoration, Disaster Recovery, and Business Continuity.

Technical Controls, Procedures, and Human Factors

Data integrity depends on the combined effectiveness of technology, procedures, and behavior.

Technical controls may prevent unauthorized access, preserve audit trails, enforce workflows, restrict configuration, automate calculations, and protect records. However, technical controls can be bypassed or undermined by poor configuration, excessive privileges, inadequate review, or unofficial work practices. Procedures should define:

• data creation;
• review and approval;
• corrections;
• invalidation;
• repeat testing;
• reprocessing;
• audit-trail review;
• access management;
• backup and recovery;
• retention;
• migration;
• change control;
• incident investigation;
• and escalation.

Human factors include workload, system usability, training, supervision, performance incentives, management expectations, and the ability to report errors without inappropriate pressure.

A technically capable system can still fail when personnel lack practical access to it, procedures are unrealistic, or management rewards desired results rather than accurate reporting.

Verification of ALCOA+ Controls

ALCOA+ verification should be requirements-based and risk-based. Testing may include:

• creation and attribution of records;
• unauthorized-access challenges;
• correction and change history;
• audit-trail generation;
• electronic signatures;
• date and time controls;
• calculation verification;
• metadata retention;
• record copying and export;
• reprocessing;
• deletion restrictions;
• interface reconciliation;
• backup restoration;
• archive retrieval;
• and migration reconciliation.

Verification should confirm the configured system and operating process, not merely the supplier’s standard product.

Supplier documentation may support assurance, but it does not replace site-specific verification of intended use, configuration, interfaces, data flows, procedures, roles, and records.

ALCOA+ and System-Specific Risk Assessment

ALCOA+ is a set of data-quality and integrity principles. It is not a complete risk-assessment method and should not determine validation scope by itself.

System-specific risk assessment should consider:

• intended use;
• regulated process;
• critical data and metadata;
• product-quality impact;
• patient impact;
• regulatory impact;
• failure scenarios;
• detectability;
• user access;
• system complexity;
• configuration;
• interfaces;
• supplier controls;
• record retention;
• and available independent controls.

A simple spreadsheet may present significant risk when it performs a critical release calculation. A complex enterprise system may contain many functions unrelated to regulated decisions. Control depth and verification should therefore reflect the specific function, data, and failure consequence.

The relationship between risk and verification is addressed in Computerized System Risk Assessment and Test Strategy.

Maintaining Data Integrity

ALCOA+ controls should remain effective after initial system release.

Lifecycle activities should include:

• access review;
• privileged-activity review;
• audit-trail review;
• incident investigation;
• change control;
• patch assessment;
• backup monitoring;
• restoration testing;
• performance and capacity review;
• supplier notices;
• periodic review;
• record retrieval testing;
• migration control;
• and retirement planning.

Periodic review should determine whether the system remains suitable for its intended use and whether changes, workarounds, incidents, defects, or organizational practices have weakened data-integrity controls.

Conclusion

ALCOA+ translates the expectation for trustworthy regulated records into nine connected principles: attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring, and available.

Effective implementation requires more than definitions. Each principle should be supported by appropriate technical controls, procedures, trained personnel, review evidence, verification, and lifecycle oversight.

ALCOA+ supports consistent control design and review, but it does not replace system-specific risk assessment. The final control strategy should reflect the intended use, critical data, credible failure scenarios, system configuration, supplier capability, and consequences for product quality, patient safety, and regulatory decisions.