QMS & PQS Implementation · 7 min read
Building a Data Integrity Programme
How to build a data integrity programme that holds: ALCOA+, governance, risk-based controls and audit trail review aligned to MHRA and EU GMP expectations.
By B. Subramanian · 9 June 2026 · Updated 15 July 2026
Most sites do not fail inspection because they set out to falsify records; they fail because a credible data integrity programme was never built, only assumed. Data integrity is not a project with an end date or a single SOP you can point an inspector to. It is a coordinated set of governance, technical and behavioural controls that keep your records attributable, complete and trustworthy across their entire lifecycle.
What a data integrity programme actually is
It helps to be precise about scope. The MHRA's GxP Data Integrity guidance and the relevant PIC/S and EU GMP expectations all converge on the same idea: integrity must be designed into the way data is generated, processed, reviewed, reported and retained, not inspected in afterwards. A programme is the structure that makes this happen consistently, rather than relying on the diligence of individual analysts.
In practice that means a documented framework with an accountable owner, a defined data lifecycle, risk-based controls proportionate to the impact of the data, and a means of demonstrating that those controls work. The unifying language is ALCOA+: data should be Attributable, Legible, Contemporaneous, Original and Accurate, and additionally Complete, Consistent, Enduring and Available. Treat ALCOA+ not as a poster on the wall but as the acceptance criteria your records are measured against.
Govern it, or it will not hold
The first failure mode is treating data integrity as a technical problem owned by IT or QC. It is a quality system attribute, governed at management level, and the EU GMP Chapter 1 and ICH Q10 expectations on management responsibility apply directly. Senior management owns the culture and the resourcing; the quality unit owns the framework; system and process owners own their controls.
An effective governance layer typically includes:
- A data integrity policy that states the organisation's expectations plainly and links to your quality manual and code of conduct.
- Clear ownership — a named programme owner, plus accountable owners for each computerised system and paper record set.
- Governance review that brings data integrity into your existing management review and quality metrics rather than running it as a parallel exercise.
- An open reporting culture in which raising a concern is rewarded, not punished. Most data integrity breaches are downstream of fear and unrealistic workload, not malice.
This governance backbone is exactly where a wider QMS implementation programme should embed data integrity, so it inherits the same change control, training and review machinery as everything else.
Risk-assess before you control
You cannot apply the same rigour to every record, and inspectors do not expect you to. ICH Q9 quality risk management is the tool for proportionality. The discipline is to map your data flows first, then assess each one for criticality and for vulnerability to amendment, deletion or loss.
Map the data lifecycle
For each significant process, document where data originates, how it is processed and transformed, who reviews it, how it is reported and where it is retained. The high-risk points are almost always the transitions: manual transcription, spreadsheet calculations, instrument outputs that are not captured electronically, and any step where a result can be repeated and the original discarded.
Prioritise by impact and detectability
Assess each data flow for its impact on product quality and patient safety, the likelihood of an integrity failure, and how readily such a failure would be detected. Hybrid systems — an electronic instrument feeding a paper record — routinely surface as high risk and deserve early attention. The output is a prioritised remediation plan, not a flat list of everything.
The controls that make data trustworthy
Controls fall into three reinforcing layers. None is sufficient alone, and over-investing in one while neglecting the others is a common and expensive mistake.
- Technical controls. Unique user accounts with no shared logins, role-based access that genuinely segregates duties, configured and protected audit trails, automatic date and time stamps from a controlled source, and validated backup and archival. Administrator rights must sit outside the population that generates and approves the data.
- Procedural controls. SOPs for audit trail review, secondary review of critical data, handling of original records and dynamic data, and the management of hybrid systems. Crucially, define what a reviewer must check and how the review is evidenced.
- Behavioural controls. Training that explains why these rules exist, supervision that does not implicitly reward shortcuts, and metrics that would not punish an honest delay.
If your audit trail is configured but never reviewed, you have the cost of the control and none of the assurance. Review is where integrity is actually demonstrated.
Computerised system validation underpins all of this. A system that has not been validated for its intended use cannot be relied upon to enforce any control you have designed, so validation and data integrity should be planned together rather than as separate workstreams. The same logic appears in our other case studies on remediation, where unvalidated spreadsheets are a recurring root cause.
Sustaining the programme
A programme earns its name by being self-maintaining. Periodic data integrity self-inspection, sampling audit trails and reconciling them against batch records, tells you whether controls work in reality rather than on paper. New systems and processes must pass through your change control with data integrity as an explicit assessment criterion, so the framework does not erode the moment something new is introduced.
Equally, treat findings as intelligence. A spike in invalidated results, recurring "testing into compliance" patterns, or audit trails showing repeated unexplained reprocessing are signals to investigate the process and the workload behind them, not merely to retrain the individual. This is where data integrity connects to your broader quality and compliance services and to genuine continual improvement.
Key takeaways
Building a credible data integrity programme is less about technology than about coherence: governance that owns it, risk assessment that prioritises it, layered controls that enforce it, and review that proves it. Anchor everything to ALCOA+, embed it in your existing PQS rather than bolting it on, and resist the temptation to treat audit trails as a box you configure once and forget.
If you are scoping a new programme, remediating inspection findings, or want an independent view of whether your controls would withstand an MHRA inspection, our QPs can help you build something that holds. Contact Double Helix Pharma UK to discuss a data integrity assessment tailored to your operation.
Regulatory sources
This guidance reflects current UK and EU GMP/GDP requirements. Primary references:
- EU GMP Annex 11 — Computerised Systems
- EU GMP Chapter 1 — Pharmaceutical Quality System
- EudraLex Volume 4 — EU GMP Guidelines
- EMA — GMP/GDP Questions & Answers
Always confirm against the latest published version of each source.
Frequently asked questions
What is the difference between data integrity and data security?+
Data security is about protecting data from unauthorised access, loss or disclosure, and is largely an IT and access-control concern. Data integrity is broader: it is the assurance that data is complete, consistent and accurate throughout its lifecycle, captured by the ALCOA+ principles. Strong security is a necessary component of integrity, but a system can be perfectly secure and still produce records that fail integrity expectations if controls such as audit trail review and validation are absent.
Does a data integrity programme apply to paper records as well as electronic systems?+
Yes. The MHRA's GxP Data Integrity guidance applies to paper, electronic and hybrid records alike, and ALCOA+ was originally framed around paper before being extended to electronic data. In fact, hybrid systems that mix an electronic instrument with a paper record are often the highest-risk area and warrant particular attention. A credible programme assesses and controls all record types, not only validated computerised systems.
How often should audit trails be reviewed under a data integrity programme?+
There is no single mandated frequency; the expectation is that review is risk-based and proportionate to the criticality of the data. For data directly supporting batch certification or release decisions, audit trail review should typically form part of the routine review of that record, before the result is relied upon. Lower-risk system audit trails may be reviewed periodically, provided the rationale is documented and defensible to an inspector.