Inspection readiness is a property of the artefact, not the system
A Part 11 control is ready for inspection when the artefact that demonstrates it can be produced, on request, by the person who owns it, without preparation. That excludes the vendor's compliance statement, the validation binder for a version no longer installed, and any artefact without a named owner.
The companion piece, 21 CFR Part 11: what pharma teams need to know, sets out what the rule says. This post assumes that reading and asks, control area by control area: which artefact an investigator will ask for, what "ready" looks like, the common way it is not, and who at the site hands it over.
The records inventory decides everything downstream
Part 11 applies to records in electronic form created, modified, maintained, archived, retrieved or transmitted under any records requirement in agency regulations (§11.1(b)). The first artefact is therefore a list of records, not of systems.
For each record class the inventory names the predicate clause requiring it, the system holding it, whether signatures are executed on it electronically, and whether the system is closed or open. On a finished-pharmaceutical site the clauses are §211.192 for investigation records, §211.68(b) for changes to master records, §211.25 for training, §211.180 for retention. The 2003 guidance adds one test: where a predicate-rule record is kept on paper and electronically, the electronic version is in scope if the site relies on it to do the regulated work. A tracker that became the deviation log is a §211.192 record held electronically, so it belongs on the list.
Ready is an approved, dated inventory whose systems match those in use. The usual gap is IT's application register offered instead: it lists software, not records, and misses the spreadsheet holding a Part 11 record. The quality unit owns it.
Control by control: the artefact, the owner, and the usual gap
Three rows are walked separately below.
| Control (clause) | Artefact on the table | Usually not ready because | Owner |
|---|---|---|---|
| Validation, §11.10(a) | Validation summary as configured, changes assessed since | Vendor package filed as the site's validation | Validation lead |
| Copies, §11.10(b) | Readable copy of a chosen record with its trail, live | Export needs IT or the vendor | System owner |
| Protection, retention, §11.10(c) | Retention schedule; a recorded restore | Restore never rehearsed | IT, quality unit |
| Access, §11.10(d) | User list of named people; leaver evidence; access review | Generic accounts; active leavers | System owner, HR |
| Audit trail, §11.10(e) | Trail for a chosen record: who, when, action, prior value | Prior value not recorded | System owner |
| Sequencing, §11.10(f) | Configuration enforcing workflow order | Steps skippable unrecorded | System owner |
| Authority checks, §11.10(g) | Role matrix reconciled to live configuration | Never reconciled | Quality unit |
| Device checks, §11.10(h) | Documented "as appropriate" determination | Never considered | Validation lead |
| Training, §11.10(i) | System training records, dated before access | GMP training only | Training, quality unit |
| Accountability policy, §11.10(j) | Accountability policy, with acknowledgements | Nobody has signed it | Quality unit |
| Documentation controls, §11.10(k) | System documentation under revision control | Vendor documents on a shared drive | System owner |
| Open systems, §11.30 | Closed/open determination; extra measures if open | "Closed" assumed, unwritten | Validation lead |
| Signature manifestation, §11.50 | Printed signed record showing name, date and time, meaning | Printout shows a user ID and a tick | System owner |
| Signature/record linking, §11.70 | Vendor's account of the linkage plus the site's test | Taken on trust | Validation lead |
| Signature requirements, §11.100 | Identity verification; certification letter to FDA | Letter never sent | Regulatory affairs |
| Components, passwords, §11.200, §11.300 | Two-component signing; password aging as configured | Procedure and configuration disagree | IT, system owner |
Producing the audit trail on request
§11.10(e) asks for the trail and §11.10(b) for the copy; together they are tested as one live demonstration. The investigator names a record; the system owner opens it, opens its audit trail, and shows for each entry who acted, when, what the action was and what the value was before. A copy is then produced, carrying the trail.
Ready is that sequence completed in minutes on a record the site did not choose. The gap takes three forms: the export must be requested from IT or the vendor; the trail records that a field changed but not what it held before; or the trail covers the main record and not its attachments, comments or linked actions.
Evidence that someone read the trail
§11.10(e) does not use the word review. That expectation comes from the predicate rules as FDA reads them in its 2018 data-integrity questions-and-answers: whoever reviews a record under CGMP reviews the audit trail capturing changes to its data along with the rest of the record. The MHRA's 2018 guidance makes that review risk-based. This is the artefact most often absent, because a trail that is switched on looks like a control and is treated as one.
Readiness is two documents. The procedure states which trails are reviewed, by whom, how often and on what risk basis: record-level trails with the record before release or closure; system-level trails, including administrator actions, periodically. The audit trail review record is the second: dated, attributed to a named reviewer, listing what was examined and how any exception was dispositioned.
The gap is rarely the procedure; it is the review record. A checkbox reading "audit trail reviewed" with nothing behind it is the common finding, and it cannot be repaired retrospectively. The record reviewer owns the first, the system owner the second. The audit trail review checklist lays out what a risk-based review record covers.
Access, identity and the list that proves it
§11.10(d) limits access to authorized individuals; §11.10(g) requires authority checks so that only authorized individuals can use the system, sign or alter a record; §11.100(a) makes each electronic signature unique to one individual, never reused or reassigned; §11.300 adds the password controls.
The artefacts are a user list exported from the system in which every account resolves to a named person, the role-permission matrix, leaver records with dates, the latest user access review, and the password configuration as set, not as written.
Ready is one exercise: take three recent leavers from HR's list and show the date each account was disabled; take one administrator and show the justification; take the password-aging period and show the screen enforcing it. The usual gaps are the shared "lab" account, active leavers, and administrator rights granted for convenience and never withdrawn.
Scoring the table on your own site first
The table above is meant to be scored. Each row takes a verdict of Pass, Gap or Not Applicable, a reference to the evidence behind it, and an owner who can produce that evidence. Scored honestly, most sites find the Gaps in three places: the review evidence, the certification letter, and the validation summary's currency.
The workbook for the exercise is the 21 CFR Part 11 readiness checklist: twenty-eight controls from §11.10(a) to §11.300(e), each with a Pass / Gap / N-A dropdown, an evidence column and an owner column, and totals that count themselves. This post walks its rows. Score it against one production system, again after each significant change, and keep the scored copies as a dated series.
The signature as it appears on the printed record
The signature clauses are tested on the face of the record. What the rule asks of any electronic signature system starts at §11.50(a), which requires a signed electronic record to contain the printed name of the signer, the date and time of signing, and the meaning associated with the signature, such as review, approval, responsibility or authorship; §11.50(b) requires all three to appear in any human-readable form, display or printout.
§11.70 requires signatures to be linked to their records so they cannot be excised, copied or transferred to falsify a record by ordinary means; the artefact is the vendor's written account of the linkage plus the site's own recorded test of it.
§11.100(c) requires persons using electronic signatures to certify to the agency, prior to or at the time of such use, that those signatures are intended as the legally binding equivalent of handwritten ones. The artefact is the dated letter; the gap is that it was never sent. §11.200(a) completes the set: two distinct components, both used at the first signing of a session and again after any break, shown in a walkthrough.
Validation evidence for the system as configured and in use
§11.10(a) requires validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. The artefact is the validation summary for the system as the site has configured it: intended use, the risk assessment behind the evidence, the test evidence traced to requirements, and a signed conclusion naming the version it applies to.
Two things make it ready rather than present: it names the version in use today, and every change since carries a recorded assessment of whether revalidation was required. Vendor validation evidence reduces the site's work; it does not replace the site's assessment of its own intended use. FDA's Computer Software Assurance guidance, issued 24 September 2025 and reissued February 2026 for the QMSR, permits scaling assurance to process risk; it is a device guidance under 21 CFR Part 820, and a pharmaceutical site adopting the method says so in its validation approach.
Procedural controls and the closed-system determination
§11.10(i) requires a determination that those who develop, maintain or use the system have the education, training and experience for their tasks: the artefact is system-specific training, dated before access, which §211.25 GMP training does not cover. §11.10(j) requires written policies holding individuals accountable for actions under their electronic signatures: the artefact is the policy and each user's acknowledgement. §11.10(k) requires revision and change control over systems documentation: the artefact is that documentation under document control.
The closed-system determination is also a written decision. §11.3(b)(4) defines a closed system as one where access is controlled by persons responsible for the content of its records; §11.3(b)(9) defines an open system as one where it is not. Where a system is hosted decides nothing; who controls access does. Where a system is open, §11.30 adds measures such as encryption and digital-signature standards. The usual gap is that "closed" is assumed and nothing is written.
The readiness protocol, as a checklist
In this order, each step producing a dated record:
- Approve the records inventory, with clause, system, signature use and closed/open determination per record class.
- Select three records at random and, timed, produce each live with its trail and a readable copy.
- For the same three, produce the audit-trail review record.
- Reconcile the user list to HR's leaver list and the role matrix to configuration; produce the last access review.
- Print one signed record and read name, date and time, and meaning off it; record the linkage test.
- Locate the certification letter and confirm it was sent no later than first use.
- Confirm the validation summary names the version in use and every change since carries an assessment.
- Produce system training records and signed acknowledgements for those who will speak to the investigator.
- Score the readiness checklist against the results and file it with the previous copies.
What remains is the site's judgement: which records are critical, how often each trail is reviewed, what each system is for, and who may sign what.
How Complere supports Part 11 inspection readiness
The history is on screen, not in a request queue. Every create, edit, approval and deletion on a quality record carries who acted, when, and what changed, and the history is read from the record rather than requested from IT. Immutable audit trail — database-enforced. Audit records cannot be modified or deleted, enforced by database-level constraints.
Signing events are recorded. Who signed, and when, sits in the trail with the record.
The Part 11 assessment is written before the question is asked. A per-module Part 11 checklist and the platform-level Part 11 controls checklist ship in the validation pack, clause by clause, with a separate audit trail specification.
The open items are written down too. Complere keeps a gap register against the same pack, and two signature-record items are open on it: the meaning of signing is not yet held as a fixed snapshot of the meaning text for every signature, and nothing yet detects a signed record whose content changed after it was signed. Score the two signature rows with that in front of you.
The vendor's checklist is a starting point for the site's assessment, not the assessment itself. Which records are Part 11 records, how often the trail is reviewed, and who holds which role remain the site's determinations to make and sign.
