Data Integrity Training: What MHRA GxP Guidance Expects From People, Not Just Systems

Data integrity findings are among the most common and most damaging outcomes of a GxP inspection, and the instinctive response is to buy better software. The MHRA’s guidance points somewhere else. Read it closely and it is a document about people: what they understand, what pressures they are under, who signs the policy, and whether anyone has been trained to read an audit trail.

The MHRA’s GxP Data Integrity Guidance and Definitions (March 2018) applies across good practice disciplines rather than to manufacturing alone, which is why it is a useful single reference for any organisation handling regulated data.

ALCOA, and the deliberate choice not to say ALCOA+

Section 6.1 sets out the attributes that regulated data must have:

• A — attributable to the person generating the data
• L — legible and permanent
• C — contemporaneous
• O — original record, or a certified true copy
• A — accurate

The same section adds that governance should also ensure data is complete, consistent, enduring and available throughout its lifecycle. Section 3.10 then makes a point that saves a lot of pointless argument: the guidance uses ALCOA rather than ALCOA+, and states that there is no difference in expectations between the two. Teams that have spent time debating which acronym their SOPs should cite can stop.

Section 6.4 defines data integrity itself as the degree to which data is complete, consistent, accurate and trustworthy, with those characteristics maintained across the whole lifecycle.

The risk assessment is not about the software

This is the provision most often missed. Section 4.5 requires that the risk assessment cover people, guidance, training and quality systems — not just the computerised system. A validated system operated by untrained staff under time pressure is a data integrity risk that no amount of system qualification addresses, and the guidance says so by requiring the assessment to look at the human factors directly.

Section 3.4 expects a documented system based on a data integrity risk assessment, commonly abbreviated to DIRA. Section 3.6 adds proportionality: the effort should match the risk and the impact. Section 3.5 is reassuring in one direction and demanding in another — routine forensic checking of records is not expected, but periodic audits are expected to detect failures, which puts the weight on whether your audit programme is capable of finding anything.

Training, and who it has to reach

Section 5.1 lists sufficient training as an enabler of data integrity, and is specific about the audience: it must be provided to all appropriate staff, including senior management. That parenthesis is doing real work. Data integrity training aimed only at laboratory analysts and production operators misses the layer whose behaviour the guidance identifies as a root cause.

Section 6.5 says governance should include staff training on data integrity principles and should encourage the reporting of errors and omissions. Training that teaches the rules without creating a safe route to admit a mistake produces exactly the concealment the guidance is trying to prevent.

Two further expectations set a competence bar rather than an attendance one. Section 6.7 expects an appropriate level of process understanding together with technical knowledge of the data systems in use. And section 6.13 states that reviewers should have sufficient knowledge and system access to review relevant audit trails. In practice that single sentence invalidates a great deal of real-world review: a reviewer who cannot open the audit trail, or who can open it but cannot interpret it, is not performing the review the record claims.

The guidance has no dedicated competence section, which is why these requirements are easy to miss. They are distributed across the document rather than collected into one place.

Culture is named as a cause

Section 3.3 is unusually direct for a regulatory document. It says the influence of culture, performance indicators, objectives and senior management behaviour should not be underestimated, and it requires the data governance policy to be endorsed at the highest levels of the organisation. Section 3.1 places responsibility for systems and data on the organisation and expects a culture that keeps data complete, consistent and accurate. Section 3.2 asks for the right environment across people, systems and facilities.

Section 5.1 turns that into concrete conditions: adequate time, space and working equipment, records that are accessible at the point of work so that staff are not driven to informal recording on scrap paper, and controlled blank forms. Most data integrity breaches in practice are not fraud. They are someone writing a reading on a glove and transcribing it later because the logbook was in another room.

Section 5.2 handles the honest case where a second person must write for the operator: scribes are permitted where justified, provided the recording is contemporaneous and both people are identified.

Access control, stated plainly

Section 6.16 is brief and unusually unambiguous. Access controls are required, there must be no shared logins for GXP data, and system administrator rights must not be held by people with a direct interest in the data. That last restriction is a segregation-of-duties rule, and it is the one small organisations most often breach, because the analyst who generates the data is also the person who knows the system well enough to administer it.

Where failures are found, section 3.8 requires corrective and preventive action across all relevant systems rather than the one where the problem surfaced, and section 4.6 requires documented prioritisation of remediation that is communicated to management. Section 3.9 expects regulators to be notified of significant data integrity incidents.

The same requirement, in a fourth regime

What makes this guidance worth reading outside its own sector is that its training expectation is the same one now appearing everywhere in regulated industry: the question is not whether training happened but whether the person can do the work.

EU GMP Chapter 2 requires continuing training with its effectiveness periodically assessed and the assessment approved at a defined level of seniority, which our guide to GMP training requirements covers. The FDA’s Quality Management System Regulation, effective February 2026, deleted its old personnel rule and adopted ISO 13485 clause 6.2, which requires effectiveness checks proportionate to the risk of the work — see the QMSR and ISO 13485 competence requirements. Pharmacovigilance expects processes that verify training produced the required understanding and performance, as set out in our guide to the QPPV role and its records. Data integrity asks whether reviewers can actually read an audit trail.

Four regimes, independently drafted, converging on assessed competence rather than recorded attendance. That convergence is the strongest available argument for treating training records as evidence rather than administration.

What an inspector can ask for

The practical test is narrow enough to self-audit. Is there a documented data integrity risk assessment that covers people and training, not only systems? Has data integrity training reached senior management as well as operators? Can the named reviewers demonstrate both the access and the knowledge to review the audit trails they sign off? Are there any shared logins? Does anyone with a direct interest in the data hold administrator rights? And is there a route by which someone can report their own error without it costing them?

The pattern is the same one that runs through every regulated appointment, from the PRRC under MDR Article 15 to CORU’s CPD requirements for medical scientists: the obligation is held by a named person or organisation, the competence behind it has to be demonstrable, and the records are the only thing that proves either.