21 CFR Part 11 is one of those regulations that’s referenced ten times in every pharma RFP and explained well in approximately none of them. Strip away the legal language and it’s actually a short, sensible set of rules about what “electronic records” need to be worth, well, anything.
Here’s what it means in practice, what the FDA actually checks during an inspection, and the five pillars every regulated software system needs to get right.
The one-sentence version
If a piece of software in your lab produces records that the FDA might ever care about, those records have to be as trustworthy as paper signed in ink — attributable to a person, tamper-evident, time-stamped, complete, and readable years from now.
That’s it. Everything in Part 11 derives from that idea.
Five pillars to actually pass an inspection
1. Audit trail
Every change to a regulated record — created, modified, deleted — gets logged with who, what, when, and why. Computer-generated, secure, immune to user override. An auditor will sit at a sample record and ask “show me the history.” If you can’t show it in two clicks, you’re explaining for the next four hours.
Common failure: “Track Changes” in Excel. That’s not an audit trail — it’s a checkbox a user can untick.
2. Electronic signatures
Tied to a specific person, applied with the same legal weight as a wet-ink signature. The system needs to know:
- Who signed (username + unique identifier)
- What was signed (the exact record state at sign time)
- When (server-side timestamp, not client clock)
- Why (the meaning of the signature — reviewed, approved, released)
Re-signing requires re-authentication. No “remember me” on the signature prompt.
3. Access control
Role-based, regularly reviewed, with periodic password rotation and a documented process for adding/removing users. The auditor wants:
- A current user list with their assigned roles
- The procedure for granting access
- The log of who got access when, who approved it, and who removed it
4. Data integrity (ALCOA+)
ALCOA+ is the FDA’s shorthand for what good data looks like:
- Attributable — traceable to a specific person
- Legible — readable and permanent
- Contemporaneous — recorded at the time of the activity
- Original — the source record, not a hand-typed copy
- Accurate — matches what actually happened
- Plus complete, consistent, enduring, and available.
5. System validation (IQ / OQ / PQ)
You need documented proof that the software was installed correctly (Installation Qualification), that it operates as designed (Operational Qualification), and that it does what your specific business needs in your specific environment (Performance Qualification). The validation package is a folder of evidence: test scripts, signed-off results, traceability matrices, change controls.
The mistakes auditors find first
- Shared accounts.“lab_admin” used by three people kills attributability instantly.
- Editable timestamps. The system clock should not be user-settable on machines that produce regulated records.
- Backups without restore drills.If you’ve never proven you can read a year-old backup, you can’t claim “Enduring.”
- Audit trail with gaps.If certain field changes are tracked and others aren’t — even legitimately — document why. Otherwise it’s a finding.
How modern software handles this
Done right, none of this should feel heavy day-to-day. The lab analyst signs records with their normal credentials; the audit trail accrues silently; backups run on schedule and get restore-tested quarterly. Inspection day is paperwork, not panic.
Our products LIMS Pulse, Calibration, Stability and Inventory are built around these five pillars from the schema up. Part 11 isn’t a feature we add; it’s the shape of every record in the database.
Takeaways
- Part 11 = “electronic records as trustworthy as paper.” That’s the whole rule.
- Five pillars: audit trail, e-signature, access control, data integrity, validation.
- The audit trail isn’t a feature — it’s the database design.
- Validation is a folder of evidence. If it doesn’t exist, the software isn’t validated.
