Data integrity findings in MHRA and FDA inspections — and how to avoid them

• Shared logins on instruments or lab software, so actions cannot be attributed to an individual.
• Analysts with administrator rights who can delete data, change methods, alter system settings or disable audit trails.
• System clocks that users can change, undermining every timestamp.
• No periodic review of who has access, so leavers and role-changers keep privileges.

Why it matters: without attribution and segregation, nobody can show who did what, and the people generating results can also alter them. The fix is structural — individual accounts, administrator roles held by people independent of the work, locked clocks and periodic access reviews.

• Electronic data deleted or overwritten, sometimes found only by comparing instrument folders with reported results.
• Trial or “unofficial” injections of samples before the reportable sequence, with only passing results reported.
• Aborted or failing runs not retained or not investigated.
• Results recorded on uncontrolled paper and transcribed later, or not at all.
• Uncontrolled blank forms, making it possible to rewrite a record and discard the original.

Why it matters: complete data is a CGMP requirement, and selective reporting is the most serious form of data integrity failure. Prevention means systems that cannot delete GMP data, audit trails that record every change with a reason, issuance and reconciliation of numbered forms, and a written definition of complete data for each test type.

• Audit trail functionality disabled, or never configured on systems that support it.
• Audit trails enabled but never reviewed as part of result approval.
• Reviewers checking printed reports and summaries only, never the underlying electronic data.
• No periodic, risk-based review across systems to spot patterns.

Why it matters: an audit trail nobody reads deters nothing. Regulators expect audit trail review to be part of the routine review of GMP data, with frequency and depth based on risk. The most valuable signals are deletions, privileged and configuration changes, unusual-hours activity and — above all — changes made after a record was approved.

Review also needs to be designed, not just mandated. Reviewers need training on what to look for, a defined scope for each system, a way to record that the review happened and what it found, and a route for findings into deviations or CAPAs. A signature on a printout saying “audit trail reviewed” with no indication of what was examined carries little weight.

• OOS results invalidated as “analyst error” or “instrument malfunction” without scientific evidence.
• Retesting until a passing result is obtained, then reporting the pass.
• Repeated chromatogram re-integration with no documented justification.
• Investigations that stop at the laboratory and never assess manufacturing or other batches.

Why it matters: 21 CFR 211.192 requires thorough investigations of unexplained discrepancies and failures, extending to other batches that may be affected. An invalidated OOS result without a defensible root cause is treated as a data integrity issue, not just a lab issue. Staged OOS investigations with independent review and approval at each level, and CAPAs that follow through, are the remedy.

• Hybrid systems where the electronic original is discarded and only a printout or PDF is kept.
• Spreadsheets used for GMP calculations without validation, locking or version control.
• Data stored on local drives or removable media with no backup.
• Backups that have never been test-restored.

Why it matters: MHRA guidance is clear that where data is dynamic, a static printout may not be a complete copy of the original. Keep the electronic original, control spreadsheet calculations or move them into validated systems, and prove that backups can be restored.

Culture and governance underneath it all

Regulators also look beyond the technical controls. Data integrity guidance places clear responsibility on senior management to create an environment where people can report errors without fear, where unrealistic targets do not encourage shortcuts, and where data governance — ownership, risk assessment of data flows, periodic review — is part of the quality system. Inspectors may interview analysts and operators directly; what they say about pressure and reporting can matter as much as the SOPs.

FDA warning letters citing data integrity typically ask the company to respond with three things, and MHRA expectations are similar in substance:

1. A comprehensive investigation into the extent of the inaccuracies in data records and reporting — across systems, sites and time periods, not just the example cited.
2. A current risk assessment of the potential effects of the failures on the quality of drugs already distributed.
3. A management strategy with a global corrective and preventive action plan, covering procedures, systems, training and governance — and evidence that it is working.

FDA letters often recommend engaging a qualified independent consultant to help. The lesson for everyone else is that remediation after a finding is slow, expensive and public; prevention is cheaper.

A useful exercise: pick one released batch and try to reconstruct, from records alone, who did every test, when, on which instrument, with which method version — and whether anything was changed afterwards. Gaps you find are the gaps an inspector will find.

Swat iQua Suite is designed to comply with 21 CFR Part 11 and EU GMP Annex 11, following ALCOA+ principles. Its controls map directly to the themes above:

• Access and attribution: individual accounts, multi-factor login, a per-site password policy, time-limited lockout after failed attempts, and role-based permissions where every change to the permission matrix is logged.
• No silent changes: every write is saved together with its audit trail entry — old value, new value, user, time and a mandatory reason — and in-house QC corrections supersede rather than overwrite the original.
• Original data kept: results enter through approved Excel/CSV import profiles or the REST API, and the source file is stored unaltered with a SHA-256 checksum.
• Audit trail review: periodic, risk-based reviews flag deletions and voids, privileged changes, configuration changes, after-hours activity and changes after approval; findings can raise a CAPA, and QA approves the review with an e-signature.
• Independent review: results need a reviewer and approver who are not the analyst, and second-person raw data review findings raise a deviation.
• Investigations: OOS investigations run in up to three levels, each with its own review and approval, segregation of duties and an optional e-signature.
• Trusted time: entries are time-stamped centrally and shown in the local time of each site.

None of this replaces a data integrity culture — but it removes the most common opportunities for failure and gives inspectors records they can trust.