Regulatory Update Jul 12, 2026 · 16:24 7 min read By Daniel Herrmann

FDA Warning Letters 2026: Seven Controls for Audit-Ready Computerised Systems

What current FDA warning letters show about user access, audit trails, raw data, vendor changes and CAPA in GxP systems.

Recent FDA warning letters do not introduce a new rulebook. They expose recurring control failures: shared credentials, excessive privileges, incomplete electronic raw data, unreviewed audit trails and changes made outside the quality system. Operators of GxP-relevant computerised systems should therefore demonstrate that technical controls, procedures and quality oversight work together in routine operation.

Why these warning letters matter to GxP organisations

A warning letter addresses a specific company and is not a substitute for law or guidance. It does, however, show how the FDA applies existing requirements during inspections. Three letters issued in March and April 2026 are particularly relevant to IT leaders, QA and system owners:

  • At Ava Inc., FDA cited a shared HPLC account, administrator privileges for analysts, deleted GC sequences, unretained trial injections and a mismatch between FTIR usage records and the electronic audit trail.
  • At Intas Pharmaceuticals, a QA employee instructed a software supplier to modify a completed electronic batch record. According to the letter, the change was captured neither in the audit trail nor in the quality system.
  • At Fareva Morton Grove, microbiological results existed across paper and electronic formats, some data were missing, and negative observations were not recorded contemporaneously as individual results.

The circumstances differ, but the control pattern is consistent. A system that has been formally validated is not automatically under control. The organisation must be able to reconstruct the complete data history and show that only authorised, appropriately separated roles can make changes.

Control 1: Individual identities instead of shared accounts

A shared login breaks attribution. If several analysts use the same username and password, an audit trail may display an event but cannot reliably identify the responsible person.

The minimum control is both technical and procedural:

  • every relevant account belongs to one person or to a clearly defined technical identity;
  • roles and privileges match the task;
  • joiner, mover and leaver events trigger an approved access process;
  • periodic reviews assess actual privileges, not only whether an account exists.

For system validation, a one-off screenshot of the user administration is therefore insufficient. Evidence should show that the access process remains effective in operation.

Control 2: Separate administration from laboratory or process execution

At Ava Inc., analysts could modify or delete data because they held administrator privileges. The design combined execution, data manipulation and control in one role.

Where the system supports segregation, operational users should not have production administrator privileges. Where a legacy system cannot enforce that separation, the organisation needs a documented risk assessment, compensating controls and a credible remediation plan. A procedure saying that deletion is prohibited does not compensate for an unrestricted delete function.

Evidence normally includes a role matrix, approved access requests, periodic access reviews and a sample that reconciles real users against their configured roles.

Control 3: Enable, protect and risk-base audit trail review

An audit trail becomes a control only when it captures critical events, is protected against unauthorised alteration and is reviewed by an appropriate role. The FDA observations show two common weaknesses: relevant events are missing, or events exist but are not considered in the quality decision.

A defensible audit trail strategy answers at least five questions:

1. Which data and metadata are GxP-critical?

2. Which events must be recorded, including creation, modification, deletion and relevant configuration changes?

3. Who reviews the trail independently of the executing role?

4. When and at what risk-based frequency is the review performed?

5. How are anomalies investigated, assessed and closed?

21 CFR 211.68(b) requires appropriate controls over computer or related systems so that only authorised personnel can make changes to master production and control records or other records. Audit trail review frequency may be risk-based, but the rationale cannot rely solely on the system name or supplier category. Intended use, data criticality and the potential effect of an undetected change belong in the assessment. The same risk logic supports risk-based Computer Software Assurance without extending the FDA CSA scope to pharmaceutical CGMP systems.

Control 4: Retain all raw data and relevant repetitions

Unretained trial injections, discarded sequences or selectively transferred results prevent full reconstruction. 21 CFR 211.194(a) requires complete laboratory data derived from all tests necessary to establish compliance. FDA’s data integrity guidance also expects CGMP data to be complete, consistent and accurate.

The operating control is therefore not “archive only the final result.” It should cover the complete decision-relevant data set: electronic raw data, relevant metadata, method and sequence information, repetitions, links to deviations or OOS investigations and the rationale for rejected or repeated work.

A system test should not stop at proving that one record can be saved. It should examine what happens during interruption, repetition, export, reprocessing, attempted deletion and system failure.

Control 5: Reconcile electronic data with operational evidence

In the Ava letter, the FTIR usage log indicated testing while the electronic audit trail showed no corresponding activity. Such discrepancies can reveal a gap in system function, procedure or recording practice.

A periodic data integrity review should therefore compare selected sources rather than assess them in isolation. Depending on the system, useful reconciliations include:

  • instrument or application logs against the audit trail;
  • batch or sample records against electronic raw data;
  • interface monitoring against received records;
  • helpdesk or supplier activity against change records;
  • backup logs against defined recovery tests.

The purpose is not indiscriminate log collection. It is to choose the few comparisons most likely to reveal an incomplete or out-of-process data history.

Control 6: Put supplier and database changes through change control

The Intas case is central to SaaS, ERP and electronic batch record operators. Even when a supplier executes the technical change, the regulated company remains responsible for a controlled process. A support ticket alone is not a quality change record.

Before a production change, the organisation should establish the purpose, affected data, approval, technical execution, audit trail impact, verification and potential product or batch impact. Direct database changes and retrospective record corrections need particularly strong segregation, logging and independent review.

This logic belongs in supplier agreements, support procedures and the validation strategy before an inspection finding occurs.

Control 7: Systemic CAPA instead of isolated retraining

Additional training can be useful, but it does not remove inappropriate privileges, missing audit trail functions or uncontrolled data modification. In the cited letters, FDA requested measures such as independent assessments, comprehensive remediation plans, root-cause analysis and effectiveness checks.

A systemic CAPA therefore combines:

  • scope determination across comparable systems and sites;
  • technical correction and procedural change;
  • assessment of potential impact on previously released data or batches;
  • clear accountability for management, QA, business and IT;
  • defined effectiveness criteria followed by independent verification.

For GxP audit readiness, this is the difference between a list of closed tickets and defensible remediation evidence.

A 30-day review for system owners and QA

The seven controls can be assessed through a focused review rather than an indiscriminate transformation programme.

Week 1: Select two or three critical laboratory, production or quality applications. Review individual accounts, privileged roles and the latest access review.

Week 2: Reconstruct one critical business process per system from the transaction to raw data, metadata and audit trail. Record discrepancies.

Week 3: Reconcile recent supplier, helpdesk and database interventions against change control and audit trail evidence.

Week 4: Prioritise findings by risk, determine systemic scope and approve CAPA with effectiveness criteria.

DHC CSV consulting connects this review with existing validation evidence instead of creating a parallel control system.

Frequently asked questions

Must every technical audit trail be reviewed before each release?

Not every technical log by default. Scope and timing depend on data criticality, intended use and process risk. For critical data, the organisation should justify which events are decision-relevant and when independent review is required.

Does a validated system prove data integrity?

No. Validation demonstrates fitness for intended use under defined conditions. Data integrity also depends on access control, operation, review, change control, training and quality oversight.

Do FDA warning letters apply directly to every European pharmaceutical company?

No. A warning letter addresses its recipient and specific facts. The underlying FDA requirements and recurring control patterns are nevertheless useful for organisations that manufacture FDA-regulated products or want to challenge their data integrity controls against real inspection findings.

Primary sources

Author

Daniel Herrmann Consulting supports Pharma, Biotech and MedTech organisations with CSV, GxP system validation, audit readiness and risk-based remediation.

Can you reconstruct access, audit trails and data changes across your critical systems?

A focused readiness review identifies and prioritises the gaps that should be closed before an inspection or go-live.

Discuss audit readiness