Error Simulator

The QA approval of a three-year-old SOP doesn't make the underlying practice compliant. FDA and MHRA guidance is unambiguous: audit trail review must cover all GxP entries, including deleted runs, invalidated results, and test injections. Selective review of passing results only is one of the most common DI findings in analytical labs, it appeared in multiple FDA Warning Letters between 2015 and 2023. The fact that it "hasn't been challenged" means it hasn't been inspected properly, not that it's acceptable. This reasoning is the same reasoning companies use when they receive a Warning Letter for something they've done for a decade.

Retraining is part of the CAPA, but retraining without stopping the wrong practice, correcting the SOP, and performing a retrospective review misses the point. More importantly, this is not an analyst knowledge gap. The analyst followed an approved SOP. The system failure is organizational: QA approved the wrong procedure. Retraining the analyst without fixing the SOP and addressing three years of incomplete audit trail review leaves the organization exposed. An inspector who sees "retraining completed" as the only CAPA response to a selective audit trail review finding will not accept it.

Continuing a non-compliant practice during SOP revision is not acceptable when the practice is a data integrity violation. You cannot document that you know a control is wrong and then continue using it while paperwork processes. The SOP update and immediate cessation of the wrong practice must happen at the same time. "Continue current practice until the SOP is approved" would itself become an inspection finding, you identified a DI gap and kept operating with it. The deviation must be opened now, and the practice must change now.

Backup logs confirm that the backup process completed. They do not confirm that the backup contains complete and usable data, that the restore procedure works, that the restored system functions correctly, or that all data is recoverable within an acceptable timeframe. FDA and EMA guidance both require periodic restore testing, not just backup monitoring. An inspector will ask: "Show me your backup restore test records." Logs showing backups ran will not satisfy this. This is a predictable inspection finding for any site that has only monitored backups without testing restores.

Knowing about a validation gap and not documenting it, not correcting it, and hoping an inspector doesn't find it is a strategy that fails in two ways. First, experienced FDA investigators systematically check backup and restore records, this is a standard inspection element for GxP computerized systems. Second, if the gap is found and you have no deviation, no CAPA, and no evidence that you identified it yourself, the finding escalates from a validation gap to a data integrity finding because it suggests inadequate internal quality oversight. The rule: find it yourself, document it, fix it, verify the fix. That is always the better position than an inspector finding it first.

A vendor certificate confirms the vendor's product is designed to support backup and restore. It does not confirm that your specific implementation, configuration, and data are recoverable. GxP requirements put the restore verification obligation on the system owner, the regulated company, not the vendor. You need to test restore in your environment, with your data, under your procedures, with documented results. Vendor support documentation is useful as supplementary evidence but cannot replace site-level testing.

A vendor saying "your validation is still valid" is not a regulated activity. The vendor does not own your validation. You own your validation. What the vendor says about their product doesn't satisfy your regulatory obligation to assess changes under change control and maintain validation documentation current with the system state. The two workflow configuration changes you already observed indicate that something beyond UI did change. Accepting the vendor's assurance without investigation, when you can already see functional differences, is not a defensible position.

"Security updates don't affect validation" is a common misunderstanding. Security patches can change system behavior, database structures, API responses, access control mechanisms, and configurations. The fact that two workflow configurations already changed is direct evidence that this update was not limited to security patches. More broadly, the category of update (security vs. feature) doesn't determine validation impact, the actual changes do. You must assess impact by reviewing what changed, not by accepting the update category label.

Stopping use entirely and requiring full revalidation before resuming is a risk management decision that should be proportionate to the actual impact. An impact assessment determines the scope of re-testing needed. Depending on what changed, you might need targeted re-testing of affected functions, not a complete rebuild of the validation package. Proportionality is a core GAMP 5 principle. "Void and restart" is not the default response to every change, it is the response when the impact assessment determines that the change affects foundational system behavior or that the extent of change is too large to scope with targeted testing.

The audit trail in the CDS shows every action taken under "qcanalyst", with no way to know which of four analysts made each entry. Manual initials in a separate notebook don't link to the electronic audit trail entries. They can be added after the fact. They can't be verified against the system log. And they rely on people being honest in a system with no technical enforcement. The ALCOA principle "Attributable" applies to the electronic record itself. FDA and MHRA guidance are explicit: shared accounts are not acceptable for GxP computerized systems because they eliminate the ability to reconstruct who did what. Phase 3 clinical testing data with unattributable electronic records is a serious finding with potential implications for the regulatory submission.

Minor findings are things like a single signature missing from a form, a training record filed in the wrong folder, or a label print slightly misaligned. Shared accounts on a CDS used for Phase 3 clinical release testing is a systemic data integrity failure affecting all data generated in that lab under that account. If FDA finds this first, it will not be written as a minor observation. Flagging for "next budget cycle" with Phase 3 data at risk is not acceptable quality oversight. This needs escalation today.

Contacting the vendor to request an upgrade is part of the long-term fix, but it does nothing about the data already generated under a shared account, and it does nothing about ongoing risk. The deviation, risk assessment, and impact evaluation on existing data must happen regardless of whether an upgrade is coming. Additionally, waiting for a vendor upgrade timeline (potentially months) while continuing to generate GxP data with shared accounts extends the problem. Interim compensating controls may be needed immediately.

Legal teams often want to minimize commitments to preserve flexibility, a reasonable instinct in litigation, but counterproductive in FDA 483 responses. FDA reads narrow responses as insufficient understanding of the finding or unwillingness to address systemic issues. An investigator who cited eight systems affected by the same gap will notice if your response only addresses "the system reviewed during the inspection." A 12-month timeline for a procedure update that takes one to two weeks to write and approve signals either organizational dysfunction or deliberate delay. Both are bad. Narrow, legally hedged responses increase the probability of escalation to Warning Letter.

Manual audit trail entry review and verification that the audit trail is still enabled are different things. Reviewing entries tells you what was recorded; it doesn't tell you whether the audit trail was disabled and re-enabled between review periods, hiding a gap. FDA's observation is technically accurate: periodic review procedures did not include an explicit check that audit trail configuration had not changed. You can choose to disagree with a 483 observation if you have a well-supported technical basis, but this observation doesn't have a strong disagreement case, and disagreement without a substantive technical argument escalates the relationship with FDA rather than resolving it.

This option gets the verification right and including current audit trail status in the response is good evidence. The gap is that framing currently-enabled audit trails as "evidence of low risk" to justify a shorter-than-necessary fix timeline is incomplete. The finding is about the absence of a control, the periodic review procedure doesn't require the check. The fact that audit trails are currently enabled is good news, but it doesn't resolve the finding: the procedural gap still exists and will exist again until the SOP is updated. Include the verification results as evidence of current status, but the response must also commit to the SOP updates with specific timelines, regardless of current status.