Audit Readiness Framework
Repeatable audit readiness across GxP systems — mock inspections, evidence-pack drills, RTM sanity, Part 11 posture.
Audit readiness is the state of being able to produce complete, consistent evidence for any regulated system on demand, without a scramble. It is tested by drill rather than assumed: can you retrieve a signed validation package, an audit trail extract and a change history for a named system within the time an inspector will actually wait, which is minutes rather than days.
- Signer’s name
- Date and time
- Meaning of the signature
- Entry in the audit trail
The retrieval drill
Audit readiness is a retrieval problem before it is a documentation problem. Most organisations have the evidence; what they lack is the ability to find it while someone watches.
- 1
Named-system evidence pack in under 15 minutes
Pick a system at random. Produce its validation package, current configuration and release approval. Time it.
- 2
Audit trail extract on demand
Produce a readable, filtered audit trail for a specific record and date range, without developer involvement.
- 3
Change history for a named system
Every change since go-live, each with its impact assessment and approval, in one place.
- 4
Current validated-state statement
For any system, a current answer to 'is this validated right now, and what proves it'.
- 5
Training records for named users
Retrieved per person per system, current as of today rather than as of the last audit.
Document integrity
Where most findings are actually written. The issue is rarely that work was not done — it is that the record of it does not hold together.
- 6
No unsigned effective documents
Nothing in use is sitting in draft. Every effective document carries its approval signatures.
- 7
No protocols approved after execution
Approval dates precede execution dates. Check this before an inspector does.
- 8
All deviations closed with documented resolution
An open deviation on a validated system is a question you will be asked. 'Accepted' needs a justification attached.
- 9
RTM reflects the current system
Requirements, tests and results match what is actually running, not what was true at go-live.
- 10
Evidence legible and attributable
Screenshots readable, timestamped, and traceable to who captured them and which step they support.
- 11
Version control intact
Superseded versions are retrievable and clearly marked as superseded.
Part 11 and Annex 11 posture
- 12
Audit trail review is happening
Not just that the audit trail exists — that someone reviews it, on a defined frequency, with a record that they did.
- 13
Segregation of duties enforced by the system
Authors cannot approve their own work, demonstrated by configuration rather than asserted by procedure.
- 14
User access periodically reviewed
Leavers removed, role changes applied, with a dated review record.
- 15
Signature manifestations correct
Name, date, time and meaning appear in the signed record and on printed copies.
- 16
Backup and restore demonstrated
A restore has actually been performed and verified within a defined period.
Lifecycle discipline
The two items that decay quietly between inspections, and the two most worth checking today.
- 17
Periodic reviews current
Performed at the defined cadence, with findings actioned. Overdue periodic review is the most common Annex 11 gap we encounter.
- 18
Change control applied consistently
Including vendor patches and infrastructure changes, which are the ones most often processed outside the system.
- 19
Supplier assessments current
Reassessed when the vendor, product or your reliance on their evidence changes.
- 20
Decommissioned systems handled
Retired systems have a documented decommissioning record and their data remains retrievable for its retention period.
The mock inspection
Run this as a rehearsal with someone playing the inspector. The value is in what you cannot answer, so record those rather than smoothing past them.
- 21
Front room and back room roles assigned
Who answers, who retrieves, who decides what is in scope. Rehearsed, not improvised.
- 22
Scope discipline practised
Answer the question asked. Volunteering adjacent systems is how a two-system audit becomes a twelve-system audit.
- 23
Gaps logged as CAPAs
Everything the drill could not answer becomes a tracked action with an owner and a date.
- 24
Re-drill after remediation
A gap is closed when the drill passes, not when the CAPA is marked complete.
Run the retrieval drill unannounced on a system nobody prepared. A rehearsed system tells you nothing; the point is to find out what normal looks like.
Keep the drill findings. An organisation that can show it audits itself, finds problems and closes them is in a materially stronger position than one presenting an unblemished record.
This is a working aid, not a regulatory document, and it does not replace your own quality system procedures.
Explore related resources, products and services: GxP Copilot, TraceDraft, validation services, AI transformation.
Sources
Primary documents referred to on this page, from their official publishers.
- 21 CFR Part 11: Electronic Records; Electronic Signatures · eCFR (US)
- EU GMP Annex 11: Computerised Systems (current version) · European Commission
Common questions
Prefer to talk first? Chat with us on WhatsApp or book a call with an expert.
What does audit readiness actually mean?
Being able to produce complete, consistent evidence for any regulated system on demand — the validation package, the audit trail, the change history, the training records — within minutes rather than days, without a scramble and without developer involvement. It is a retrieval capability, tested by drill, not a documentation state assumed to be true.
How often should we run a mock inspection?
At least annually, and before any anticipated regulatory inspection. More useful than frequency is realism: run it unannounced, on a system nobody has prepared, with someone genuinely playing the inspector. A rehearsed drill on a prepared system measures nothing.
What is the most common audit finding on validated systems?
Periodic review overdue or never performed, and audit trails that exist but are never reviewed. Both are lifecycle obligations rather than project deliverables, which is exactly why they decay quietly between inspections while the original validation package still looks immaculate.
How quickly must we produce evidence during an inspection?
There is no regulated time limit, but expectation is set by what is reasonable. An inspector asking for a system's validation package expects it in minutes. Delays are read as a sign that documentation is not controlled, and tend to broaden the scope of what gets asked for next.
Should we tell an inspector about problems we already found?
Yes, where you found them, logged them and are acting on them. Demonstrating a working self-inspection process is a strength. Concealment that later surfaces is far more damaging than the original gap, and an organisation that never finds its own problems invites a closer look.
Put this to work on your system.
Bring a URS. We show you risk-sized testing on your own requirements.
- We reply within one business day
- We run your URS live on the call
- You get a clear plan for your system