MHRA Data Integrity: GxP Compliance Guide for US Teams

MHRA expects every GxP record to be complete, consistent, accurate, attributable, contemporaneous, and preserved across its entire lifecycle — the ALCOA+ standard — and controlled through a documented Data Integrity Risk Assessment (DIRA). For US pharmaceutical, biotech, and medical device teams, that expectation does not sit in isolation: it maps directly to FDA 21 CFR Part 11 regulations, PIC/S data integrity guidance, and OECD principles, meaning a gap against MHRA is almost always a gap against your US obligations too.

Three actions to take now:

• Run or refresh a DIRA for every system that generates, processes, or stores GxP data. Scope it by criticality — manufacturing, patient safety impact, and detectability of alteration.
• Enable and verify audit trails and backup/restore procedures on all high-criticality systems. Confirm that restore tests are documented and dated.
• Document and prioritize remediation for high-criticality findings. Assign owners, target dates, and link each item to a root-cause analysis.

Inspectors look for six things above all: ALCOA+ evidence in records, documented system categorization, audit-trail review records with dates and signatures, validated backup/restore test results, training records tied to data-handling SOPs, and a DIRA that is current.

Pro Tip: Start with the highest-impact, lowest-effort fixes: enforce unique user IDs, enable audit trails on critical systems, and run a documented backup restore test. These three actions reduce inspection risk immediately and cost almost nothing to implement.

Key Takeaways

MHRA data integrity compliance requires a documented DIRA, enforced ALCOA+ controls across the full data lifecycle, and audit-trail review evidence — and for US teams, every one of those requirements maps to a corresponding FDA 21 CFR Part 11 or PIC/S obligation.

Table of Contents

• What does the MHRA GxP data integrity guidance actually cover?
• How does MHRA define data integrity, and what does ALCOA+ mean in practice?
• How should you map the data lifecycle and categorize systems by risk?
• What technical and procedural controls does MHRA expect you to have?
• How do you review audit trails in a way that satisfies MHRA?
• How do you run a DIRA and build a prioritized remediation plan?
• What do MHRA inspectors actually find most often?
• How does MHRA guidance map to FDA 21 CFR Part 11 and PIC/S for US teams?
• What checklists and templates should you use to start remediation?
• What does a realistic remediation roadmap look like in terms of time and cost?
• What most remediation projects get wrong
• Qualitum cuts the manual burden of MHRA-aligned validation evidence
• Sources
• FAQ

What does the MHRA GxP data integrity guidance actually cover?

The MHRA GxP Data Integrity Guidance (published March 2018) describes minimum regulatory expectations, not an exhaustive rulebook for every scenario. It applies across all GxP sectors: GMP, GCP, GLP, GDP, and GPvP. That breadth matters for US teams operating across multiple regulated functions — the same ALCOA+ principles apply whether you are managing a clinical trial database or a manufacturing execution system.

The GOV.UK guidance page confirms that the document is intended to be used alongside international guidance, not as a standalone authority. MHRA developed it in alignment with WHO, PIC/S, and OECD, and the MHRA Inspectorate blog noted significant stakeholder engagement during development — a signal that the guidance reflects broad industry consensus, not just UK regulatory preference.

For US teams, the practical implication is clear: MHRA expectations are not a foreign compliance burden. They are a well-aligned international benchmark that, when met, substantially satisfies FDA 21 CFR Part 11 and PIC/S requirements simultaneously.

The five chapters every QA or compliance professional should review first:

• Definitions and scope — MHRA's precise language for data integrity, raw data, metadata, and audit trail
• Data lifecycle — generation through destruction, with controls mapped to each phase
• System categorization — how to classify systems by criticality and set proportionate controls
• Audit trail expectations — what must be captured, how often reviewed, and how to evidence review
• Remediation guidance — how to prioritize and document corrective actions for inspection

How does MHRA define data integrity, and what does ALCOA+ mean in practice?

The MHRA guidance defines data integrity as the degree to which data are complete, consistent, accurate, trustworthy, and maintained throughout the data lifecycle. That definition is deceptively simple. The word "maintained" carries most of the weight: it means integrity must be demonstrable at every point from generation to archive, not just at the moment of entry.

ALCOA+ is the organizing framework MHRA uses to make that definition inspectable. Each attribute translates into a concrete check:

• Attributable — every record identifies who created or changed it and when. Example: a unique user ID on every HPLC injection sequence.
• Legible — records are readable for the full retention period. Example: printed chromatograms stored in archival-quality format, not fading thermal paper.
• Contemporaneous — data recorded at the time of the activity. Example: batch record entries signed at the step, not reconstructed at end of shift.
• Original — the first capture of data, or a certified true copy. Example: raw instrument data file retained alongside the printed report.
• Accurate — free from errors and truthful. Example: no manual overrides of instrument results without documented justification.
• Complete — all data, including invalidated runs, retained. Example: all HPLC injections, including aborted sequences, visible in the audit trail.
• Consistent — internal dates, times, and sequences are coherent. Example: system clock synchronized to a validated time server.
• Enduring — records survive for the required retention period. Example: electronic records stored in a validated archive with migration procedures.
• Available — records can be retrieved promptly for inspection. Example: archive search capability tested and documented.

One distinction MHRA draws that teams often miss: data integrity is about the trustworthiness of records, not their scientific quality. A result can be scientifically valid but still fail an integrity check if it cannot be attributed, if the original file was deleted, or if the audit trail was disabled during the run.

"Data integrity refers to the completeness, consistency, and accuracy of data. Complete, consistent, and accurate data should be attributable, legible, contemporaneous, original, and accurate (ALCOA)."

— MHRA GxP Data Integrity Guidance, March 2018

That sentence is worth copying verbatim into your SOP header or inspection briefing slide. It is the definition inspectors will use.

How should you map the data lifecycle and categorize systems by risk?

A lifecycle approach that starts at data generation and ends at destruction simplifies prioritization: systems that prevent unauthorized alteration at the point of write reduce downstream remediation effort significantly. MHRA structures the lifecycle in five phases, each producing distinct record types that require specific controls.

System categorization follows a similar risk logic. MHRA expects organizations to classify each system as high, medium, or low criticality based on three factors: the manufacturing or study stage it supports, its direct impact on patient safety or product quality, and how detectable an unauthorized alteration would be.

A high-criticality system profile typically includes: direct impact on batch release or patient dosing, low detectability of data manipulation, and no independent verification step downstream. A laboratory chromatography data system (CDS) managing release testing fits this profile. A low-criticality system might be an internal scheduling tool with no GxP output.

When mapping a system, capture these fields:

• System owner and data steward
• Data types handled (raw data, metadata, reports)
• User roles and access levels
• Interfaces with other systems (data flows in and out)
• Audit-trail capability (present, enabled, reviewed)
• Backup schedule and last documented restore test
• ALCOA+ risk rating per data type

The APIC/CEFIC practical guide recommends a holistic, lifecycle approach and provides severity classification examples that align closely with MHRA's framework — useful as a cross-reference when building your system inventory.

What technical and procedural controls does MHRA expect you to have?

MHRA does not prescribe a single technical architecture, but it does describe a minimum control set. The distinction between technical controls (built into the system) and procedural controls (enforced through SOPs and training) is deliberate: neither alone is sufficient.

Access controls are the foundation. Every user must have a unique ID. Shared accounts are a critical finding in almost every MHRA inspection where data integrity is cited. Role-based privileges should reflect the principle of least privilege: analysts should not have administrator rights, and system administrators should not have the ability to delete audit trail entries. Segregation of duties between data entry, review, and approval is expected for high-criticality systems.

Audit trails must capture who performed an action, what was changed, when it occurred, and — for modifications — why. Both data-level audit trails (changes to individual records) and system-level audit trails (login events, configuration changes) are expected. Trails must be unmodifiable by the user who generated them. Periodic review is required; the frequency should be proportionate to system criticality.

System validation follows the established CSV lifecycle: user requirements specification (URS), functional specification, design qualification (DQ), installation qualification (IQ), operational qualification (OQ), and performance qualification (PQ). Validation documentation must be retained and updated after any significant change. GAMP 5 remains the dominant industry framework for categorizing software and scoping validation effort.

Backup, restore, and archive procedures must be documented, scheduled, and tested. A backup that has never been restored is not a backup for regulatory purposes. Restore tests should be periodic, documented with acceptance criteria, and retained as evidence. Archives must be protected from unauthorized modification and stored for the full retention period.

Change control applies to both system configuration and procedural documents. Any change that could affect data integrity — a software update, a new interface, a change to an audit-trail configuration — requires a documented impact assessment before implementation.

Procedural controls round out the picture: SOPs covering data entry, review, approval, and exception handling; training records tied to those SOPs; and documented authorization matrices showing who can approve what.

Pro Tip: Two procedural controls deliver outsized inspection value at minimal cost: require a documented "reason for change" field for any record modification, and maintain a current authorization matrix. Both are frequently absent and frequently cited.

For teams looking to verify their current state, the audit readiness checklist covers ALCOA+ control points that map directly to these MHRA expectations.

How do you review audit trails in a way that satisfies MHRA?

An audit trail that is never reviewed is, from an inspection standpoint, almost as problematic as one that is disabled. MHRA expects evidence that audit trails are actively monitored, that anomalies are investigated, and that findings are documented and closed.

What an audit trail must record: creation events (new record, user, timestamp), modification events (original value, new value, user, timestamp, reason), and deletion events (what was deleted, by whom, when, and under what authorization). System-level events — failed login attempts, privilege escalations, configuration changes — belong in a separate system audit trail that is equally subject to review.

Review frequency should be risk-based:

• High-criticality systems (CDS, MES, LIMS for release testing): review at minimum monthly, with targeted daily or weekly spot checks for anomalies flagged by automated alerts
• Medium-criticality systems: quarterly review with documented sampling rationale
• Low-criticality systems: semi-annual review, with a documented justification for the reduced frequency

Automated monitoring tools that flag unusual patterns — multiple failed logins, records modified outside business hours, bulk deletions — reduce the manual burden and provide a defensible sampling rationale. The review itself must be documented: a signed statement identifying the reviewer, the period covered, the sample size, any findings, and the corrective actions taken or rationale for no action.

Pro Tip: Store audit-trail review records in a searchable, indexed archive and link each finding directly to the corresponding CAPA or deviation record. When an inspector asks "show me your audit-trail review for Q3 on your CDS," you want to retrieve that evidence in under two minutes.

How do you run a DIRA and build a prioritized remediation plan?

A Data Integrity Risk Assessment is the documented process of identifying where data integrity vulnerabilities exist, scoring their risk, and determining proportionate controls. International bodies treat it as a mandatory best practice, and it maps directly to ICH Q9 risk management methodology.

The DIRA workflow follows six steps:

1. Scope selection — define which systems, processes, and data types are in scope, prioritizing GxP-critical systems
2. Data and process mapping — document data flows, interfaces, user roles, and the ALCOA+ risk at each step
3. Risk scoring — apply severity (impact on patient safety/product quality), occurrence (likelihood of failure), and detectability (how easily a failure would be caught) scores to each identified risk
4. Control identification — map existing controls to each risk and identify gaps
5. Residual risk estimation — score risk after controls are applied and determine whether residual risk is acceptable
6. Approval and documentation — obtain sign-off from QA, IT, and system owners; retain the DIRA as a controlled document

FMEA-style scoring gives the DIRA quantitative rigor. A simple 1–5 scale for each dimension produces a Risk Priority Number (RPN) that drives prioritization:

Critical items (RPN 76–125) require immediate remediation with a target closure within 30 days. Major items (26–75) should be addressed within 60–90 days. Minor items can follow a standard change-control timeline.

Each remediation item in the plan should document: root cause, corrective action, validation or verification steps required, resource estimate, owner, and target date. Retain before-and-after test results, validation evidence, and training completion records as inspection evidence. The APIC/CEFIC guide includes practical FMEA examples that can accelerate your scoring calibration.

A DIRA is most effective when run by a multidisciplinary team — QA, IT, CSV, data owners, and production representatives — and updated at least annually or after any major system change.

What do MHRA inspectors actually find most often?

The pattern of MHRA data integrity findings is consistent enough that it functions as a pre-inspection checklist. The Gmp-compliance of MHRA guidance and inspection observations identifies the same failures repeatedly:

• Shared user accounts — multiple analysts using a single login, making attribution impossible
• Disabled or unreviewed audit trails — systems where audit trail functionality exists but was turned off, or where no review records exist
• Back-dated or late entries — batch record entries made hours or days after the activity, often with system timestamps that contradict the claimed entry time
• Untested backups — backup schedules documented but no restore tests performed or recorded
• Insufficient validation after changes — software updates or configuration changes implemented without a documented impact assessment or re-validation
• Incomplete training records — personnel performing GxP data activities without documented training on the relevant SOPs

These findings share a common root cause: organizations that rely on system validation as a substitute for procedural governance. A validated system with shared accounts and no audit-trail review is not compliant — validation addresses whether the system works as intended, not whether it is being used correctly.

"The expectation is that data governance systems will be designed and operated to ensure that data are complete, consistent, and accurate throughout the data lifecycle. Organisations should consider the impact of data governance failures on product quality and patient safety."

— MHRA GxP Data Integrity Guidance

Pre-inspection checks to run now:

• Pull a list of all active user accounts on high-criticality systems and verify no shared accounts exist
• Confirm audit trails are enabled and that review records exist for the past 12 months
• Check the date of the last documented backup restore test for each critical system
• Verify that all personnel with GxP data access have current SOP training records
• Confirm that the DIRA is dated within the last 12 months or after the last major system change

Case example: A site's CDS had audit trail functionality enabled, but the review SOP required only an annual check. During an inspection, the investigator pulled three months of audit trail data and found 14 instances of result files deleted and re-run without documented justification. The root cause was not the system — it was the absence of routine review that would have caught the pattern. Corrective action: monthly audit-trail review with a documented sampling protocol and a CAPA linked to each anomaly.

How does MHRA guidance map to FDA 21 CFR Part 11 and PIC/S for US teams?

US teams operating under FDA jurisdiction need to understand where MHRA expectations align with 21 CFR Part 11 and where the framing differs. The OECD advisory document on data integrity26\&doclanguage=en) stresses international harmonization, and the practical reality is that ALCOA+ compliance substantially satisfies Part 11 requirements — but the emphasis and enforcement mechanisms differ.

The electronic signature comparison is worth unpacking. MHRA treats electronic signatures as equivalent to handwritten signatures when they meet ALCOA+ criteria and are bound to the record. FDA Part 11 adds specific technical requirements: the signature must be unique to the individual, cannot be reused or reassigned, and must be linked to the record in a way that makes tampering evident. For US teams, meeting Part 11 §11.100 and §11.200 requirements will generally satisfy MHRA's electronic signature expectations — but the reverse is not always true. MHRA's principles-based approach may accept controls that Part 11's prescriptive requirements would not.

The FDA guidance index remains the primary US reference for computerized system validation and electronic records. Cross-mapping MHRA requirements to Part 11 clauses in your remediation tracker is the most efficient way to demonstrate dual compliance during a multinational inspection.

Pro Tip: Build a cross-reference column in your remediation tracker: MHRA requirement, corresponding Part 11 clause, and PIC/S/OECD reference. When a US inspector asks whether your MHRA remediation satisfies Part 11, you can answer with a document, not a verbal explanation.

What checklists and templates should you use to start remediation?

The fastest way to move from DIRA findings to documented remediation is to have template structures ready before the assessment begins. These outlines are starting points — adapt them to your system inventory and SOP framework.

DIRA starter checklist

• System name, owner, and data steward
• GxP classification (GMP/GCP/GLP/GDP/GPvP)
• Criticality rating (high/medium/low) with documented rationale
• Data types handled and lifecycle phase coverage
• ALCOA+ risk per data type (attribute-level)
• Existing controls (technical and procedural)
• Audit-trail status (present/enabled/reviewed — Y/N with date of last review)
• Backup schedule and last restore test date
• Interface inventory (upstream and downstream systems)
• Initial RPN score and prioritization bucket

Audit-trail review template

• System name and version
• Review period (start and end date)
• Reviewer name and signature
• Sample size and sampling rationale
• Findings (anomaly type, record ID, date, user)
• Disposition (no action required / CAPA raised / escalated)
• CAPA reference number if applicable
• Next scheduled review date

Backup/restore test script

• System name and backup type (full/incremental/differential)
• Backup date and file identifier
• Restore environment (production/test)
• Acceptance criteria (data completeness, record count, timestamp integrity)
• Test result (pass/fail)
• Tester name, date, and signature
• Reviewer sign-off

Training and SOP update log

• SOP number and version
• Change description and reason
• Affected roles
• Training completion date per individual
• Trainer name and method (classroom/eLearning/read-and-sign)
• QA sign-off date

For a more detailed verification framework, the data integrity testing guide covers test plans for confirming ALCOA+ compliance across system types.

30/60/90-day remediation task list

Days 1–30 (critical items): Enable audit trails on all high-criticality systems; enforce unique user IDs; run and document a backup restore test for each critical system; complete DIRA for top-priority systems.

Days 31–60 (major items): Implement audit-trail review SOPs and complete first formal reviews; address shared account findings; update training records for all GxP data handlers; complete DIRA for remaining systems.

Days 61–90 (governance and verification): Finalize remediation tracker with cross-references to Part 11/PIC/S; conduct a mock inspection review of evidence packages; verify all CAPA items from the DIRA have documented closure evidence.

What does a realistic remediation roadmap look like in terms of time and cost?

Remediation timelines vary significantly by portfolio size, but the phase structure is consistent across organizations. Understanding where effort concentrates helps leaders set realistic expectations and secure appropriate resources.

Phase 1: Discovery and DIRA (weeks 1–8)

Scope the system inventory, complete data mapping, run FMEA-style scoring, and produce a prioritized finding list. For a small portfolio (under 20 GxP systems), this phase typically runs four to six weeks with a team of three to five. Larger portfolios with 50+ systems may require eight to twelve weeks and a dedicated multidisciplinary team.

Phase 2: Remediation planning (weeks 6–10, overlapping)

Assign owners, set target dates, estimate resource requirements, and obtain management approval. This phase should produce a controlled remediation tracker that is updated weekly.

Phase 3: Remediation execution (weeks 8–26+)

System-level changes (enabling audit trails, reconfiguring access controls, updating backup procedures) are typically the fastest to close. Validation-heavy items — re-validation after software changes, new system implementations — take longer and drive most of the cost.

Phase 4: Verification and inspection readiness (weeks 20–30+)

Independent verification of remediation evidence, mock inspection review, and final sign-off. This phase is often underestimated; allow at least four to six weeks.

Major cost drivers, in rough order of magnitude:

• IT and integration work — reconfiguring systems, enabling audit trails, implementing access controls
• CSV/validation effort — re-validation after changes, new IQ/OQ/PQ protocols
• External consultancy — DIRA facilitation, gap assessment, inspection readiness support
• Training and change control — SOP updates, training delivery, and documentation
• Ongoing monitoring infrastructure — automated audit-trail alerting, archive management

For small portfolios, a focused remediation program can be completed in three to six months. Medium portfolios (20–50 systems) typically require six to twelve months. Large, complex portfolios with legacy systems and multiple sites should plan for twelve to eighteen months, with phased inspection readiness milestones.

A multidisciplinary DIRA team should include QA lead, IT/systems administrator, CSV specialist, data owners from each major function, and a regulatory affairs representative. Piloting the DIRA methodology on two or three high-criticality systems before rolling out to the full portfolio validates the scoring approach and reduces rework.

What most remediation projects get wrong

The conventional wisdom on data integrity remediation is that it is primarily a technology problem: upgrade the systems, enable the audit trails, and the compliance gap closes. That framing is wrong, and it is expensive to discover mid-project.

The most common failure mode is not a missing technical control. It is the gap between what the CSV documentation says the system does and what operators actually do with it. A validated LIMS with a documented audit-trail SOP is not compliant if analysts have been sharing a generic login for two years because the individual account setup was never completed after go-live. The system passed validation. The practice never matched the design.

What actually accelerates inspection readiness is leadership sponsorship that makes data integrity a visible operational priority, not a QA project running in the background. When a site director asks weekly for the DIRA remediation tracker update, the pace of closure changes. When that same director signs off on the audit-trail review summary, the governance signal is clear to every operator on the floor.

Quick wins matter, but only when they are genuine. Enabling an audit trail that no one reviews is a compliance theater move that will make an inspection worse, not better, because it creates a record of anomalies that have never been investigated. The sequence matters: enable the trail, establish the review SOP, complete the first review, document findings, and close them. That sequence, done for the top five high-criticality systems, is more inspection-ready than a half-finished remediation across twenty systems.

The other underestimated factor is data migration. Organizations that have moved data between systems — from legacy to modern platforms, from paper to electronic — often discover that the migration itself created integrity gaps: missing metadata, broken audit trails, records that exist in the new system but cannot be traced to their original source. A DIRA that does not explicitly scope historical data migrations will miss these vulnerabilities.

The teams that close remediation fastest share one structural feature: a central tracker, owned by a named individual, updated weekly, with escalation criteria that are actually used. Not a spreadsheet buried in a shared drive — a controlled document with version history, reviewed in a standing meeting with QA, IT, and operations.

Qualitum cuts the manual burden of MHRA-aligned validation evidence

Assembling inspection-ready ALCOA+ evidence manually is one of the most time-consuming parts of any data integrity remediation program. Validation protocols, audit-trail summaries, traceability matrices, and CAPA records each require authoring, review, and cross-referencing — work that compounds across every system in your portfolio.

Qualitum's automated validation platform enforces ALCOA+ at both write-time and review-time, so every record the system generates is already compliant before it reaches a reviewer. The platform covers the full validation lifecycle — URS through PQ, CSV/CSA, cleaning and sterilization validation, risk assessments, and audit-trail reconciliation — with a live traceability matrix that links every deliverable to its source requirement. Teams using Qualitum report over 70% reduction in authoring time and significantly faster CSV cycles, which means remediation programs that would otherwise take twelve months can close materially faster.

For US teams managing dual compliance against MHRA and FDA 21 CFR Part 11, Qualitum's cross-jurisdiction compliance architecture means your validation evidence satisfies both frameworks without duplicate documentation effort. The Validate·AI module handles protocol authoring and evidence generation; the Investigate·AI module supports root-cause analysis and CAPA documentation for remediation items.

Book a working session to see how Qualitum maps to your current DIRA findings and where it can close gaps in your inspection-readiness timeline.

Sources

The documents below are the primary references for any MHRA data integrity program. Download and store them in your remediation tracker as controlled reference documents, with the version date noted.

• ‘GXP’ Data Integrity Guidance and Definitions (MHRA)
• Guidance on GxP data integrity
• DIRA Data Integrity Risk Assessment: Introductory Guide – GuideGxP
• OECD advisory document on data integrity
• MHRA’s GXP data integrity guide published – MHRA Inspectorate
• MHRA GMP Data Integrity Definitions and Guidance for Industry (GMP‑Compliance.org)

Store each document with its download date and version. When an inspector asks for the basis of your DIRA methodology or your ALCOA+ definition, point to the specific page and clause in these documents.

FAQ

What does MHRA mean by data integrity?

MHRA defines data integrity as the degree to which data are complete, consistent, accurate, trustworthy, and maintained throughout the data lifecycle. The ALCOA+ framework — Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring, Available — is the practical standard inspectors use to assess compliance.

What is ALCOA+ and how many attributes does it have?

ALCOA+ has nine attributes: the original five (Attributable, Legible, Contemporaneous, Original, Accurate) plus four additions (Complete, Consistent, Enduring, Available). All nine must be demonstrable for every GxP record across its full lifecycle, from generation through archive or destruction.

What is the MHRA's role in regulatory affairs?

The MHRA (Medicines and Healthcare products Regulatory Agency) is the UK regulator responsible for medicines, medical devices, and blood components. In regulatory affairs, MHRA sets GxP standards, conducts inspections, and issues guidance that influences international frameworks including PIC/S and WHO — making its data integrity expectations relevant to US organizations operating across multiple jurisdictions.

How does MHRA data integrity guidance relate to FDA 21 CFR Part 11?

MHRA's ALCOA+ framework and FDA 21 CFR Part 11 address overlapping requirements: both mandate unique user identification, audit trails, and controlled electronic records. The key difference is that Part 11 is prescriptive about technical controls for electronic signatures and closed systems, while MHRA takes a principles-based, risk-proportionate approach. US teams should cross-map each MHRA requirement to the corresponding Part 11 clause in their remediation tracker.

What is a DIRA and why do regulators expect one?

A Data Integrity Risk Assessment (DIRA) is a documented process for identifying, scoring, and prioritizing data integrity vulnerabilities across GxP systems. Regulators including MHRA, OECD, and PIC/S treat it as a mandatory best practice because it provides documented evidence that an organization has systematically assessed its data integrity risks and applied proportionate controls — the foundation of any defensible remediation program.

Recommended

• Platform · Qualitum
• How to Test Data Integrity: A Practitioner's Guide · Qualitum blog
• Validate·AI · Qualitum
• Qualitum · The agentic validation platform for life sciences

FAQ

What does MHRA mean by data integrity?

MHRA defines data integrity as the degree to which data are complete, consistent, accurate, trustworthy, and maintained throughout the data lifecycle. The ALCOA+ framework — Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring, Available — is the practical standard inspectors use to assess compliance.

What is ALCOA+ and how many attributes does it have?

ALCOA+ has nine attributes: the original five (Attributable, Legible, Contemporaneous, Original, Accurate) plus four additions (Complete, Consistent, Enduring, Available). All nine must be demonstrable for every GxP record across its full lifecycle, from generation through archive or destruction.

What is the MHRA's role in regulatory affairs?

The MHRA (Medicines and Healthcare products Regulatory Agency) is the UK regulator responsible for medicines, medical devices, and blood components. In regulatory affairs, MHRA sets GxP standards, conducts inspections, and issues guidance that influences international frameworks including PIC/S and WHO — making its data integrity expectations relevant to US organizations operating across multiple jurisdictions.

How does MHRA data integrity guidance relate to FDA 21 CFR Part 11?

MHRA's ALCOA+ framework and FDA 21 CFR Part 11 address overlapping requirements: both mandate unique user identification, audit trails, and controlled electronic records. The key difference is that Part 11 is prescriptive about technical controls for electronic signatures and closed systems, while MHRA takes a principles-based, risk-proportionate approach. US teams should cross-map each MHRA requirement to the corresponding Part 11 clause in their remediation tracker.

What is a DIRA and why do regulators expect one?

A Data Integrity Risk Assessment (DIRA) is a documented process for identifying, scoring, and prioritizing data integrity vulnerabilities across GxP systems. Regulators including MHRA, OECD, and PIC/S treat it as a mandatory best practice because it provides documented evidence that an organization has systematically assessed its data integrity risks and applied proportionate controls — the foundation of any defensible remediation program.