Home
Our Approach Advanced Services Expertise Why EUCALEX
AI‑LEX Self-Assessment Confluence Contact us Blog & News Careers All articles
Data Integrity

Data integrity findings are rarely a software problem

Written Jan 2023published 9 Feb 20254 min read

Read enough inspection reports and warning letters and a pattern jumps out. The findings are not about algorithms or exotic failures. They are about accounts shared between analysts, audit trails that were never switched on, failing results deleted before review, records signed before the work was done. FDA said as much in its 2018 guidance on the subject: in recent years it has increasingly observed CGMP violations involving data integrity during inspections. The categories have barely changed since.

The same five observations

From one letter to the next, the recurring findings look remarkably alike.

  • Shared logins. Several analysts work under one account, so no result can be attributed to a person.
  • Disabled audit trails. The system is configured to leave no trace of a change or a deletion.
  • Deleted data. Failing injections disappear before review, sometimes while the inspector is on site.
  • Backdated records. The test was performed after the record says it was complete.
  • Falsification. Results deliberately made up.

Only the last one is misconduct in the ordinary sense. In our experience the first four nearly always come from a system that was installed to run a process and never configured to prove it.

Why it happens on good sites

A chromatograph arrives with a default account. Commissioning is late. The audit trail costs storage and slows the workstation, so it stays off “for now”. Three analysts have to cover a night shift and there is one licence. None of these decisions feels like a compliance decision at the moment it is taken, and that is the whole problem. Data integrity is decided during installation and configuration, years before an inspector reads the record.

Anyone who has commissioned a lab system will recognise the scene: the supplier’s engineer leaves on Friday, the admin password is on a sticky note inside the cabinet door, and the person who knows which settings were changed is gone by Monday. Nobody did anything wrong that week. The finding arrives three years later.

If a record cannot say who did what, when, and what it looked like before, the process may still be right, but you can no longer demonstrate it.

What actually closes the gap

The remediation list has nothing exotic in it. Nine plain controls, and the ones that slip are almost always the last three:

  • unique named accounts, no shared credentials, ever;
  • separated privileges, so that an analyst cannot delete data or change the system clock;
  • audit trails enabled and reviewed as part of routine data review;
  • complete capture, with every injection, repeat and failure retained;
  • validation that covers security, audit trail and retention, and not only the calculation;
  • backups that have actually been restored in a test;
  • a data governance policy that names an owner for each data lifecycle;
  • training that explains the consequences, not just the procedure;
  • risk assessments reviewed on a defined schedule.

The first six are technical, and they get done. The last three are organisational, and they get postponed. That is how a site passes a technical gap assessment and still collects a finding.

Audit trail review deserves a word of its own, because it is where good intentions stall. Switching the audit trail on is a configuration setting. Reviewing it means someone, with time allocated and a procedure that says what to look for, reads entries that are often cryptic and badly filtered. When that review is not built into the routine data review, it becomes a quarterly exercise nobody owns, and the audit trail turns into a recording nobody listens to.

ALCOA+ is a design brief, not a checklist

Attributable, Legible, Contemporaneous, Original, Accurate, plus Complete, Consistent, Enduring and Available. Read as an audit checklist, it is a chore. Read while you configure a system, it is a specification. Whom will this record name? How long will it survive, and what happens to it when the server is replaced? How will anyone see that it was changed?

That is the shift we push on every validation engagement. The cheapest data integrity work is done before the system goes live. Everything after that is remediation.

References

EUCALEXNotes from field experiencesTalk to us about this

EUCALEX

Have a project or a technical challenge?

Contact us: we will be pleased to discuss it with you, with no commitment.

Discuss your project with us

Stay informed

Receive new EUCALEX articles and technical insights by email.