Engineering teams meeting Part 11 for the first time usually expect an exotic set of requirements. Most of it is ordinary good practice, applied rigorously and — crucially — made provable years after the fact.
The core idea: evidence, not just correctness
Ordinary business software has to do the right thing. Regulated software has to do the right thing and be able to demonstrate that it did, to someone hostile, long afterwards. That single shift drives most of the design.
Unique, attributable identity
Every action must be attributable to one identified individual. Shared accounts are disqualifying, and this is the most common practical failure — a workstation everyone logs into with the same credentials makes every downstream record unattributable.
Audit trails that cannot be edited
The audit trail is the primary artefact the system exists to produce. Design the record lifecycle around generating it, rather than adding logging near the end of the project.
- Append-only. Records are never updated or deleted, only superseded.
- Captures who, what, when, and — where relevant — why.
- Uses secure, computer-generated timestamps, not client-supplied ones.
- Retained at least as long as the records it describes.
- Available for review and export in a human-readable form.
Authority checks
The system must enforce that only authorised individuals can perform a given action. Enforced, not merely presented — hiding a button in the interface while leaving the endpoint open is a failure, and it is a failure we find regularly in systems built without this in mind.
Electronic signatures
Where a signature is applied, the record must show the signer's printed name, the date and time, and the meaning of the signature — approval, review, responsibility. The signature must be bound to its record so it cannot be transplanted or excised.
Operational sequencing
Systems must enforce permitted step order where sequencing matters. A workflow that lets someone approve before the required review has happened does not meet this, regardless of whether anyone actually does it.
What this means for architecture
- 1Model records as immutable with explicit supersession, rather than mutable rows.
- 2Put authorisation checks in the service layer where every path passes through them.
- 3Make approval workflows configurable but versioned, so historical records stay tied to the rules that applied at the time.
- 4Plan retention and export from the start — reconstructing an audit trail later is not possible.
The practical advice
Involve your quality function during design, not at validation. Nearly every expensive Part 11 remediation we have seen came from a system built to a functional specification with compliance treated as a review step at the end.