GxP Data Integrity Across the Computerised Record Lifecycle

Data integrity is not a property added during archival or checked only during an inspection. It is the continuing ability to rely on a record because its origin, meaning, history, completeness and relationship to the real activity remain defensible.

ALCOA+ is a useful mnemonic, but repeating its words does not design a controlled process. The practical task is to apply those characteristics to specific record events, systems, copies, transformations, decisions and retention states. This guide does that across the full lifecycle.

Define the regulated record

Identify the data and context needed to reconstruct the activity and support the regulated decision. A result without units, method, sample, instrument, operator or time may be numerically accurate yet not form a complete record. An approval without the approved version and decision meaning may be attributable but ambiguous.

For each process, define:

• the event or observation being recorded;
• the original or authoritative record;
• required metadata and relationships;
• the user or service identity;
• the time and sequence needed for interpretation;
• calculations and transformations;
• review, approval and correction events;
• copies, reports and interfaces used operationally;
• retention and retrieval needs;
• the decision or action the record supports.

This record definition is the basis for requirements, validation, procedures and review. Do not let system boundaries decide the record boundary automatically.

Apply ALCOA+ as design questions

The commonly used characteristics can be translated into concrete questions:

These questions interact. A contemporaneous entry made under a shared account is not attributable. An original proprietary file that can no longer be rendered is not available or legible. A correct report can be incomplete if security filters exclude records from its population.

Identify the first durable capture

Determine where data first become a durable record. Direct acquisition from an instrument or system is different from transcription from a temporary display. A paper note later entered into an application creates a hybrid record whose paper and electronic components must be governed together.

Avoid unofficial intermediate media: scraps of paper, local text files, personal spreadsheets, screenshots or messaging tools used because the controlled system is inconvenient. If temporary recording is necessary, define approved media, identity, time, transfer, verification, retention and destruction.

Where data are generated automatically, preserve raw data and metadata necessary to reconstruct processing. Do not assume the displayed final result is the entire original record. Determine whether method parameters, instrument status, integration settings or intermediate files contribute to interpretation.

Preserve attribution

Use unique identities for interactive users. Govern authentication, role assignment, delegation, service accounts and emergency access. The recorded name should remain meaningful after a user leaves or changes name; immutable identifiers and retained user history may be necessary.

Service identities require an attributable business event. Preserve originating system, transaction and—where relevant—initiating user. A generic “integration user” does not explain why a regulated value changed.

Electronic signatures should be linked to the record and convey signer identity, date and time, and meaning of the signature as applicable. Do not treat a typed name or workflow status as automatically equivalent to a controlled electronic signature.

Privileged users create a special boundary. Technical ability to alter data does not confer business authority. Restrict, log and independently review exceptional repairs or administrative changes.

Make contemporaneous recording achievable

Procedures should define when an activity is recorded and how delay is identified. System design should support capture at the point of work rather than requiring users to remember details and enter them later.

Consider shared equipment, cleanroom restrictions, offline work, mobile processes, queued interfaces and batch jobs. If exact immediate entry is impractical, define the approved temporary record and transfer window. Preserve both activity time and entry time where they differ.

Backdating should not conceal late entry. A user-entered effective date may be legitimate, but the system-generated creation and change history should remain available. Reviews should distinguish retrospective transcription from contemporaneous observation.

Time controls include synchronised clocks, time-zone handling, daylight-saving changes and event ordering across systems. Define which timestamp governs the regulated sequence.

Protect original data and true copies

Identify the original record for each data type. It may be an electronic dataset, image, spectrum, document file, database record, paper record or composite of content and metadata. The original is not always the first human-readable printout.

A true copy should preserve the content and meaning of the original, including relevant metadata. Verify the copying process and document what is included or excluded. Static PDF may be an adequate representation for some records and inadequate where dynamic data, layers, calculations or audit history are needed.

When converting format, validate transformation, reconcile populations and retain provenance. Preserve the source where the copy cannot support all future uses. Define who certifies or verifies true copies and how the relationship to the original is recorded.

Capture metadata as part of the record

Metadata provide context: identity, time, instrument, method, unit, version, lifecycle state, relationship, source, calculation and change history. Classify which metadata are essential for interpretation, which support search and which are transient technical data.

Do not discard metadata merely because they are not visible on a standard screen. Conversely, retaining every low-level log indefinitely can obscure the meaningful record and create ungoverned stores. Use intended use and risk to define the necessary set.

Preserve code lists and configuration versions needed to interpret historical values. A stored code without its historical label or definition may cease to be legible after a taxonomy change.

Design controlled data entry

Use appropriate types, ranges, units, formats and controlled values. Validate requiredness, conditional logic and boundary handling. Make invalid or unknown values explicit rather than encouraging plausible placeholders.

Defaults require care. A default can speed entry but may record an assumption as fact. Distinguish system-generated, calculated, copied and user-entered values. Show provenance where it affects reliance.

Control copy-forward, templates, cloning and bulk updates. They can preserve correct context or rapidly reproduce obsolete data. Define which fields may copy, which must be reconfirmed and how inherited values are identified.

For free text, provide enough space and instruction for meaningful explanation without forcing regulated conclusions into unstructured notes that cannot be governed or reported.

Validate calculations and derived data

Document formula, inputs, units, rounding, precision, missing-value treatment, inclusion rules and version. Test normal, boundary, invalid and exceptional data. Preserve the relationship between derived output and source values.

Spreadsheets, reports, scripts and analytics can all become calculation engines. Determine their intended use and validation boundary. Lock or control formulas, protect inputs, version logic and verify changes.

When recalculation occurs after a source change, define whether old results are replaced, versioned or retained. A current dashboard may be unsuitable for reconstructing the value visible to a past approver unless historical snapshots or source logic are preserved.

Govern processing and transformation

Every consequential transformation needs a defined rule and evidence. Examples include unit conversion, normalisation, parsing, coding, aggregation, deduplication, imputation, summarisation and status mapping.

Record source, target, rule, version, rationale, owner, error handling and verification. Preserve raw or prior values where required. Treat automated cleaning as a change, not an invisible improvement.

Distinguish deterministic transformation from practitioner interpretation. A unit conversion can be validated mathematically; classification of a narrative may require human judgement and preserved rationale.

Monitor transformation exceptions and changes in input distributions. Logic that worked for one source format may silently mis-handle a new format.

Control review and approval

Define what the reviewer must examine, which source and history are available, how exceptions are presented and what approval means. A workflow signature does not demonstrate that the evidence was complete or visible.

Provide access to original data, metadata, audit trail, calculations and related records according to risk. Avoid review screens that show only final values while hiding repeats, invalid results or corrections.

Record reviewer identity, time, decision, meaning and record version. Prevent material change after approval without reopening, supersession or a controlled correction path. If supporting evidence changes, determine whether prior approval remains valid.

Use second-person verification where it addresses a real error mode. Do not create ritual re-entry checks when automated transfer or independent reconciliation provides stronger control.

Preserve complete data, including adverse evidence

Completeness includes failed, aborted, invalid, repeated and excluded results where they are relevant to understanding the activity. Do not retain only the chosen or passing result.

Define legitimate invalidation criteria and require reason, identity, time and review. Preserve the invalid record visibly rather than deleting it. Repeated testing should link to the original attempt and approved rationale.

Monitor patterns: repeated trials by user, instrument or method; excessive invalidation; data created outside expected hours; missing sequences; unexplained gaps; and selective reporting. Patterns can reveal process or control weakness even when individual events appear acceptable.

Control reports and exports

Reports create governed interpretations of source data. Define population, joins, filters, security, formulas, time basis, refresh, handling of blanks and cancelled records, and permitted decision use.

Validate consequential reports with representative and boundary datasets. Test security effects: a report can be logically correct but incomplete for a user lacking access to certain records. Reconcile to authoritative sources.

Exports create copies whose freshness and control may differ from the live system. Label generation time and parameters. Protect files, avoid uncontrolled local alteration and define whether the export is evidence, a working copy or merely navigation aid.

If a meeting relies on a spreadsheet derived from a validated report, the evidence path includes the export and any additional formula, sorting or manual exclusion.

Preserve integrity across interfaces

Define source and field authority, identifiers, mappings, timing, acknowledgement, retry, duplicate handling, rejection and reconciliation. Validate normal and failure paths. A successful message does not prove a complete target business state.

Preserve transaction identifiers linking source, middleware and target. Reconcile expected source populations to confirmed target outcomes independently of processing success logs. Investigate missing and unexpected records.

Control mapping and reference values. A state code can change meaning across systems. Retain versioned mapping and source provenance so the target record does not imply that a target user created information received from elsewhere.

During outages, govern queued, replayed and manually entered data. Prevent duplicates when automated service resumes and reconcile the backlog before normal reliance.

Govern migration as a data-lifecycle event

Inventory and profile source data, define dispositions, approve mappings and transformations, qualify the repeatable migration process, execute trials, reconcile populations and verify accuracy, meaning and usability.

Preserve records intentionally excluded from migration through a controlled archive. Handle audit history, attachments, relationships and electronic approvals explicitly. Do not describe transformed source history as native target history.

Use stratified verification around complex transformations, rare states, long text, attachments and known defects. Record and resolve exceptions against predefined acceptance criteria.

The dedicated migration pillar provides the complete method. The data-integrity principle is that transfer must preserve the record's value, meaning, context and availability.

Control hybrid paper and electronic records

Define the complete record when parts exist on paper and parts electronically. Identify which component is original, how they are linked, who verifies transcription, how corrections work and where review occurs.

Avoid procedures that declare the electronic entry authoritative while material annotations remain only on paper. Conversely, do not print electronic records and discard metadata needed to interpret them.

Use unique identifiers and controlled assembly. Test whether an inspector can retrieve all components. Align retention and legal holds. If paper is scanned, verify completeness, orientation, readability, page count, colour where meaningful and linkage before authorised destruction.

Temporary paper used during an outage needs controlled issuance, identity, time, reconciliation and disposition. It should not become invisible shadow data after transcription.

Make corrections transparent

Corrections should preserve original information, corrected information, identity, date and time, reason and approval where required. The current state should be clear without erasing history.

Differentiate correction of data, correction of metadata, reinterpretation, late entry and change to a business decision. Each may require different authority and downstream assessment.

Assess consequences: reports, interfaces, approvals, submissions or decisions may have used the prior value. Correcting the source does not automatically repair every derivative. Identify and reconcile affected copies and records.

For bulk correction, control selection, script or tool, transformation, testing, execution identity, exception handling and reconciliation. Retain record-level before-and-after evidence or an equivalent reconstructable dataset.

Investigate suspected integrity failures

Preserve evidence and restrict further alteration. Define the earliest potential start, affected systems, users, records, products and decisions. Use audit trails, access histories, interfaces, configuration, backups, paper records and interviews as appropriate.

Do not assume the first detected event is the first occurrence. Use population analysis to test scope. Examine similar users, fields, methods, instruments or process routes.

Assess whether records remain reliable, need correction, require retrospective review or cannot support prior decisions. Separate data restoration from restoration of justified confidence.

Root cause should consider system design, workload, incentives, procedure, training, access, review effectiveness and management controls. “Individual misconduct” should not end analysis of why the system allowed or failed to detect the behaviour.

Design exception handling

Exceptions include invalid input, missing data, failed transfer, calculation error, duplicate record, unavailable system, rejected correction, archive failure and unexpected user action. Define detection, containment, ownership, escalation, correction and closure evidence.

Do not route every anomaly through an administrator. Preserve business authority and independent review. Avoid direct database changes unless justified, controlled and fully reconciled.

Trend exceptions to identify systemic failure. A repeated workaround may indicate the formal process is not executable. Update requirements, configuration or staffing rather than normalising undocumented correction.

Control access and segregation

Grant access according to business authority and record population. Separate creation, review, approval, administration and deletion where risk warrants. Assess combined roles and temporary access.

Test positive and negative cases, including external users, administrators and integrations. Review access periodically with context. Reconcile identity-provider, request and application states for joiners, movers and leavers.

Monitor privileged actions, shared accounts, dormant users, direct grants and emergency access. Access controls support attribution and prevention but do not replace review of the data and process.

Use audit trails effectively

Audit trails should capture consequential record, decision, control and service events with identity, time and context. Protect them from alteration and validate all material routes.

Review based on risk using record, exception and systemic modes. Preserve review scope, population, method, findings and disposition. Join unusual events to the underlying record and process before concluding whether they are acceptable.

Retain the audit trail with the associated record and preserve configuration and identity context needed for interpretation. The dedicated audit-trail pillar provides the complete operational framework.

Design backup and restore

Backups protect recoverability, not everyday record retrieval. Define scope, frequency, retention, encryption, separation, monitoring and restoration priorities. Ensure configuration, metadata and audit trails are included where required to restore an intelligible system state.

Test restoration, not only backup completion. Verify integrity, record counts, relationships, permissions, application compatibility and the point in time recovered. Record data loss relative to the approved recovery point and reconcile transactions after that point.

Protect backups from unauthorised alteration and common-cause failure. Control access and deletion. Consider supplier-managed backup evidence and customer responsibilities.

Build a usable archive

An archive should support authorised search, retrieval and interpretation for the required period. Preserve content, metadata, history, relationships, code definitions, signatures and provenance according to the record need.

Choose native retention, migration to an archive platform or verified static/dynamic representations deliberately. Validate extraction, transformation, loading, indexing and retrieval. Demonstrate readability after source retirement.

Assign an archive owner, support model, access process, restoration test cadence and technology-refresh plan. Long retention can outlive formats, software and suppliers.

Apply retention and legal holds

Map record classes to applicable retention schedules and jurisdictions. Define the event that starts the period, handling of superseded versions, linked records and holds. Avoid using one application-level period where different records require different treatment.

Ensure related audit trails, metadata and interpretation aids remain for as long as necessary. Control disposition approval and preserve evidence of authorised destruction without retaining the destroyed content improperly.

Legal and regulatory requirements vary; records and legal counsel should determine applicable periods. This article does not prescribe retention durations.

Demonstrate availability and retrieval

Availability means more than storage. An authorised person should be able to locate the correct record, render it, understand metadata and history, and produce a suitable copy within the needed time.

Test realistic retrieval questions across current and archived data. Include old users, retired values, superseded versions, migrated identifiers and legal holds. Measure failures and correct indexing or documentation gaps.

Maintain procedures and trained roles after system retirement. A technically intact archive is not available if nobody retains access or understands the search model.

Authorise destruction

Destroy records only after retention, legal hold, investigation and business dependency checks. Use controlled methods appropriate to media and confidentiality. Include replicas, exports, temporary files and supplier copies within the disposition design.

Avoid deleting interpretation metadata before the content or leaving orphaned audit trails. Record scope, authority, method, date, exceptions and confirmation.

Where selective deletion is technically difficult, document the justified retention or migration approach. Privacy deletion and GxP retention obligations may require legal and records assessment.

Govern the full record lifecycle

Assign data owners for meaning and authorised use, system owners for service controls, process owners for execution, records managers for retention, and Quality for applicable oversight. Define hand-offs explicitly.

Maintain a record-lifecycle map linking creation, processing, review, reporting, transfer, correction, archive and destruction. Connect requirements, risks, controls, evidence and owners.

Review the map after system, process, supplier, organisation or regulatory change. Monitor data-quality and integrity signals rather than waiting for inspection preparation.

A lifecycle assurance table

This table is a Navata Library synthesis. It is intended to make lifecycle controls inspectable, not to replace the applicable quality system.

Worked example: an approved report is exported and recalculated

A validated application report lists overdue quality actions. A coordinator exports it to a spreadsheet, removes records believed to be duplicates, adds a severity weighting and presents the total to management. The meeting decision is recorded in minutes.

The regulated evidence path now includes the application data, report logic, user's security population, export time, spreadsheet formulas, manual exclusions, severity mapping and meeting record. Validation of the application report does not establish integrity of the transformed meeting pack.

The control should define permitted transformation, version the spreadsheet or eliminate it, preserve excluded records and rationale, verify formulas, reconcile to the source and retain the exact pack used for the decision. The question is not whether Excel is inherently GxP. It is whether the process relies on the resulting record.

Worked example: paper capture during an outage

A laboratory system is unavailable for six hours. Analysts record observations on controlled paper forms, then transcribe them after recovery. Some calculations are performed manually and some instrument files remain queued.

The continuity record must identify issued forms, analysts, activity time, sample and instrument; distinguish manual from automated calculations; link queued files; verify transcription; reconcile all work performed during the outage; resolve duplicate messages after interfaces resume; review calculations and exceptions; and retain or authorise destruction of paper according to the defined record model.

Simply entering values later and marking the system restored would leave contemporaneity, completeness and source provenance unresolved.

Regulatory boundaries

MHRA data-integrity guidance describes data integrity across the lifecycle and explains ALCOA-related expectations. FDA's Data Integrity and Compliance With Drug CGMP guidance addresses questions within drug CGMP scope. EU GMP Annex 11 contains computerised-system expectations including accuracy checks, storage, audit trails, security, business continuity and archiving.

These sources must be applied according to jurisdiction and scope. They do not prescribe the Navata lifecycle table, one universal technology architecture or a single review frequency. ICH Q9(R1) supports proportionate, science-based quality-risk management but is not an audit-trail or data-retention checklist.

Translate the record lifecycle into requirements

Create requirements for each lifecycle stage and boundary. A generic requirement that data shall be accurate and complete is not testable enough. State the record, event, user or service, required metadata, processing rule, protection, review, retrieval and retention.

For example: “When a result is received from the approved instrument interface, the laboratory system shall retain the instrument and sample identifiers, original result and unit, acquisition and receipt times, interface transaction, transformation version and any rejection; authorised users shall not overwrite the original value; corrections shall preserve prior and corrected states and reason.”

Trace requirements to architecture, configuration, procedures, tests, monitoring and retention. Include manual and degraded paths. Reassess when new fields, reports, integrations, suppliers or record uses enter the process.

Classify records by reliance and consequence

Not every stored datum needs identical control. Classify according to how the process relies on it and what an error could change. Useful categories may include source observation, critical process parameter, identity or authority record, calculation input, derived decision output, supporting context and administrative data.

Document classification rationale and controls. A small metadata field can be critical if it controls sample identity or report inclusion. A large attachment can be supporting context rather than the primary regulated record.

Use classification to set entry validation, review, audit-trail attention, backup, retention and retrieval priorities. Do not let it become a label with no effect on control design.

Define source data and authoritative records

Source data are the original records or certified copies needed to reconstruct and evaluate an activity. The authoritative operational record may reside in another system after controlled transfer. Define both and their relationship.

For each field or document decide who may originate, correct and approve it; which system stores the authoritative current value; where original evidence remains; and how discrepancies are resolved. Preserve identifiers across systems.

Avoid declaring an entire application the system of record without field and process nuance. A laboratory system may own the result while a quality system owns disposition and an archive owns long-term retrieval.

Control data acquisition from instruments and devices

Document instrument identity, software and configuration, method version, sample link, acquisition time, operator, raw data, calculated output and transfer. Restrict changes to acquisition parameters and record them.

Validate connectivity, file and message formats, units, precision, rejected results, duplicate transfer, time-outs and recovery. Determine what happens when network or target system is unavailable. Preserve local data until confirmed receipt and reconciliation.

Avoid manual transcription where a validated direct transfer is practicable, but do not assume automation is error-free. Reconcile populations and monitor failed or unexpected transfers. Control service identities and supplier support.

Where instruments create proprietary dynamic data, plan long-term rendering, metadata and migration before obsolescence.

Control manually entered data

Design forms and screens to reduce ambiguity and error. Present units, expected formats and context. Use controlled values and ranges where appropriate, while permitting justified exceptions.

Critical transcription may require independent verification against the source. Define what the verifier checks and retain identity and time. Avoid asking the second person to repeat the same interpretation without access to the original.

Support immediate correction before final submission without hiding the sequence where that sequence is material. After submission, use transparent correction with reason and review.

Monitor copy-paste, repeated defaults, implausibly rapid entry and patterns of later correction. These signals require context, not automatic allegation.

Govern scanned and imaged records

Define scanning resolution, colour, orientation, completeness, page order, identifiers and indexing. Verify that every page is readable and linked to the right record. Include annotations, reverse sides, envelopes or context where material.

Determine whether the scan is a convenience copy or a verified true copy. If original paper will be destroyed, define verification, approval and destruction conditions. Preserve metadata and a record of the conversion.

Test representative handwriting, faint marks, stamps, colour-coded information, large formats and multi-page documents. Monitor scanner and optical-recognition changes. Do not rely on OCR text without preserving the image where visual evidence matters.

Govern email, messages and collaboration records

Regulated decisions and evidence can move through email or collaboration tools even when the formal system exists. Define which communications form part of the regulated record and how they are captured, linked and retained.

Discourage approval by informal message where a controlled workflow is required. If emergency communication is necessary, preserve identity, time, content, attachments and later reconciliation.

Control shared links and attachment versions. A message saying “approved” may point to content that later changes. Retain the exact version and approval meaning.

Apply privacy and retention rules; not every conversation should become a permanent GxP record. Train users on the boundary and provide an executable capture process.

Control spreadsheets and local tools

Inventory spreadsheets, scripts, databases and low-code tools that create, transform or report GxP data. Classify intended use and risk. Assign owner, version, access, storage and review.

Protect formulas and code, distinguish input from calculated cells, validate consequential logic, control templates and retain executed versions. Record data sources and refresh. Test boundary, blank and invalid values.

Prevent uncontrolled copies from diverging. Where a spreadsheet is temporary, define migration and retirement. Where it becomes a sustained process, govern it as a computerised system proportionately.

The decision is based on reliance, not file extension. A simple lookup may determine release while a complex analysis remains exploratory.

Govern data used in statistical and analytical work

Preserve dataset definition, inclusion and exclusion criteria, extraction query, source snapshot, cleaning, transformations, code, software version, analyst and outputs. Separate exploratory analysis from a result used in a regulated decision.

Reproducibility requires access to the exact data and logic, not only the final chart. Protect against silent refresh or package-version change. Review manual exclusions and outlier treatment.

Where randomisation or stochastic methods are used, preserve seeds or sufficient method evidence where reproducibility is required and possible. State uncertainty and limitations.

Link analytical findings to source records while respecting blinding, privacy and access controls.

Govern AI-assisted processing as a separate intended use

If AI retrieves, extracts, classifies, summarises or drafts from regulated data, define authorised sources, task, output, permitted reliance, human review, provenance, model and service version, monitoring and prohibited actions.

Do not treat a human click as automatic data-integrity protection. Determine what evidence the reviewer sees and whether error is detectable. Preserve sources and output context needed for reconstruction.

Assess supplier data use, retention and change. Validate the configured end-to-end use with representative and challenging data. Monitor source-citation failure, overrides and drift.

Existing Navata AI pages provide the detailed intended-use and risk-classification methods; this section only identifies the record-lifecycle boundary.

Design data review by exception and population

Record-by-record review is necessary for some decisions but insufficient for systemic patterns. Combine source review, automated rules, exception reports and periodic population analysis.

Define what each review is entitled to establish. Validate report populations and rules. Preserve filters, version, reviewer, date, findings and disposition. Sample unflagged records where automated selection might miss issues.

Review repeated corrections, missing sequences, late entry, invalidated results, privileged changes, interface rejects and unusual data distributions. Connect signals to process context.

Avoid asking reviewers to certify “ALCOA+ compliant”. Give them specific data and decision criteria.

Control data through organisational hand-offs

When responsibility moves between teams, sites or suppliers, define record state, completeness, open issues, ownership, access and acknowledgement. A hand-off should not create an unowned interval.

Use checklists for pending records, exceptions, queued interfaces, manual work, retention and system changes. Preserve who transferred and accepted responsibility and under what conditions.

For outsourced activities, contract for timely data, metadata, original or verified copies, audit history, correction support, retention and exit. Verify transfers and maintain customer access.

Assess whether supplier summaries are sufficient or whether underlying source data are required for the customer's decision.

Manage data integrity during system change

Assess changes to configuration, fields, calculations, reports, roles, integrations, storage, archive and procedures. Identify records and decisions that could be affected.

Test new and historical data. Preserve the old logic or enough evidence to interpret prior results. Determine whether backfill or recalculation is intended and how it is distinguished from original processing.

Use supplier release information as an input, not a customer impact conclusion. Document evidence added, reused or judged unaffected.

Monitor after release for unexpected blanks, mapping failures, report changes and access differences.

Govern database and administrator interventions

Direct data repair may be necessary when supported tools cannot correct a defect. Define approved scope, authorised script, test evidence, backup, executing identity, timing, before-and-after values, reconciliation and independent review.

Separate technical execution from business approval. Preserve why each record was included. Test selection against a representative copy and define rollback.

Prevent unlogged ad hoc updates. Monitor privileged access and reconcile interventions with incident or change records. Assess downstream copies and decisions.

The correction should remain visible enough to reconstruct without exposing sensitive operational details unnecessarily.

Design data integrity into vendor selection

Ask whether the service supports unique identities, appropriate audit trails, export, retention, versioning, backup, restoration, data segregation, configuration control, incident support and controlled exit.

Evaluate how the supplier handles support access, subprocessors, data location, deletion, model or software change and end-of-service. Review evidence scope and date.

Test customer-specific configuration and integrations. Contract for relevant change and incident information and timely access to records. Avoid dependence on proprietary evidence that cannot be exported or retained.

Supplier certification can inform assessment but does not establish fitness for the customer's intended use.

Preserve context through archive technology refresh

Long retention may outlive media, file formats, applications, encryption algorithms and suppliers. Maintain a technology-refresh plan. Inventory formats and dependencies, monitor obsolescence and migrate before access becomes uncertain.

Validate each archive migration. Reconcile records, metadata, relationships, signatures and audit history. Preserve provenance and transformation. Test rendering and search.

Do not wait until the original application will no longer start. Maintain documentation and skills. Record how old codes, states and identities are interpreted.

Manage privacy and confidentiality with integrity

Access restriction, minimisation and authorised deletion may coexist with GxP retention. Classify data and apply role-based access, masking or pseudonymisation where appropriate.

Do not remove context required for regulated interpretation without an approved alternative. Assess legal bases, retention and holds with privacy and legal specialists.

Logs and evidence can contain personal data. Limit collection to necessary context, protect exports and define access. Redaction should be controlled and should not alter the authoritative record silently.

When responding to access or deletion requests, preserve decision and execution evidence without retaining unnecessary content.

Prepare inspection evidence

Be able to show the data lifecycle for a representative record: origin, identities, metadata, processing, review, reports, transfers, corrections and retention. Demonstrate system and procedural controls and their operation.

Provide current diagrams, record definitions, validation, audit-trail review, access, change, backup, archive and issue records. Retrieve archived and migrated examples.

Avoid preparing a special inspection-only dataset disconnected from live controls. Use the same retrieval paths that operations maintain. Explain known limitations and corrective actions accurately.

Train presenters to distinguish requirement, implementation, observed evidence and practitioner interpretation.

Common failure patterns across the lifecycle

Look for:

• unofficial initial capture followed by clean transcription;
• shared or generic identities;
• entry time presented as activity time;
• default values mistaken for observations;
• calculations without versioned inputs and logic;
• excluded or invalid data disappearing from review;
• report populations changing with user security;
• exports altered without controlled record of changes;
• interfaces with success logs but no source-target reconciliation;
• migration counts matching while relationships or meaning fail;
• corrections that do not assess derivative records;
• backups never restored;
• archives without metadata or search;
• retention that removes audit history before the record;
• supplier exit that leaves proprietary evidence inaccessible.

Each pattern indicates a specific lifecycle boundary to investigate. Do not respond with a generic data-integrity training programme alone.

Implement a data-integrity control programme

Sequence implementation:

1. inventory processes, systems and record classes;
2. define authoritative records and lifecycle maps;
3. assess risks at creation, processing, review, transfer, correction and retention;
4. identify technical, procedural and ownership gaps;
5. contain high-consequence vulnerabilities;
6. improve requirements, configuration, interfaces and procedures;
7. validate corrections and review historical exposure;
8. establish monitoring, issue management and periodic review;
9. test backup, archive and inspection retrieval;
10. maintain the programme through change.

Prioritise controls that preserve original evidence, prevent unauthorised alteration and reveal decisions made from incomplete or changed data. Avoid measuring success by document count.

Assign decision rights

Data owners define meaning, authorised use and quality expectations. Process owners ensure operational capture and review. System owners maintain application controls. Validation establishes evidence. Records managers manage retention. Security manages access and privileged monitoring. Quality provides applicable oversight and acceptance.

Define who can classify a record, approve a correction, invalidate a result, change a calculation, accept a migration exception, authorise destruction and determine affected decisions.

Keep decision rights available during absence, outage and supplier incident. Record delegation. Review whether roles remain exercisable, not merely named.

Judge whether integrity is demonstrable

For a selected record, the organisation should be able to answer:

• where and when it originated;
• who or what created and changed it;
• which metadata and source context make it intelligible;
• which processing and versions affected it;
• what the reviewer saw and approved;
• where it travelled and how transfer was reconciled;
• what was corrected and which decisions were reassessed;
• how it is protected, retained and retrieved;
• what will happen at authorised destruction.

If the answers require unsupported inference, missing supplier data or current configuration used to explain historical processing, the lifecycle contains a material evidence gap.

Preserve the boundary of every data-integrity claim

State which records, processes, systems, periods and lifecycle stages the evidence covers. Successful testing of entry controls does not establish report completeness; a reconciled migration does not prove that later corrections reach every copy; a restored backup does not establish archive availability.

Record exclusions and residual uncertainty. This prevents ALCOA+ language from becoming a blanket declaration and keeps each conclusion proportionate to observed evidence.

The same discipline should be applied whenever a record acquires a new use.

Sources

• MHRA, GxP Data Integrity Guidance and Definitions — lifecycle data-integrity concepts and regulatory interpretation.
• European Commission, EU GMP Annex 11: Computerised Systems — accuracy checks, storage, audit trails, security, continuity and archiving.
• FDA, Data Integrity and Compliance With Drug CGMP: Questions and Answers — FDA guidance within drug CGMP scope.
• EMA, ICH Q9 Quality Risk Management — official guideline page for science-based quality-risk decisions and proportionality.