GxP, computer system validation, and 21 CFR Part 11
The compliance layer named explicitly in the clinical-trials vacancy. Most engineers have never met it, so being able to speak the language is disproportionately valuable — and the underlying ideas map onto practices you already have.
What GxP means
“Good x Practice” — a family of regulations covering regulated life-sciences activities:
| Covers | |
|---|---|
| GCP — Good Clinical Practice | how clinical trials are run; the relevant one for a clinical trial management system |
| GMP — Good Manufacturing Practice | drug and device manufacturing |
| GLP — Good Laboratory Practice | non-clinical safety studies |
| GDP — Good Distribution Practice | supply chain |
A system is “GxP-relevant” if it creates, modifies, stores or transmits data supporting a regulated decision — patient safety, product quality, or a regulatory submission. That classification comes first, because it determines how much validation the system needs.
ALCOA+
The data integrity principles auditors assess against. Worth being able to recite, because it is the vocabulary of every conversation in this area.
| Principle | Means |
|---|---|
| Attributable | who did it, and when |
| Legible | readable and permanent |
| Contemporaneous | recorded when it happened, not reconstructed later |
| Original | the first record, or a verified true copy |
| Accurate | correct, complete, and free of undetected error |
| plus Complete, Consistent, Enduring, Available | nothing dropped, no contradictions, survives retention periods, retrievable when asked |
Read as engineering requirements, these are: authenticated actions, immutable append-only audit trails with server-side timestamps, no silent overwrites, referential integrity, durable backups with tested restores, and retention measured in years.
21 CFR Part 11
The FDA rule on electronic records and electronic signatures. What it actually requires of a system:
- Validation — documented evidence the system does what it is specified to do
- Audit trails — computer-generated, time-stamped, independent of the operator, recording create/modify/delete with the old value retained. A soft-delete flag with no history does not satisfy this.
- Record retrieval — records must be readable and exportable throughout the retention period
- Access control — unique user accounts, no shared logins, authority checks per action
- Electronic signatures — bound to the record, showing the signer, timestamp and meaning of the signature, and unforgeable by copying
The database consequence: no destructive updates on regulated records. Either an append-only event log with the current state derived, or bitemporal tables carrying valid-time and transaction-time. UPDATE patients SET ... on a GxP record without capturing the prior value is a finding.
Computer System Validation
CSV is documented evidence that the system does what it should, consistently. Traditionally: User Requirements Specification, Functional Specification, Design Specification, then Installation/Operational/Performance Qualification (IQ/OQ/PQ), with a traceability matrix mapping every requirement to the test that proves it.
Done badly this produces binders of screenshots and blocks delivery for months.
CSA — Computer Software Assurance is the FDA’s newer, risk-based guidance and is the answer that shows you are current. It says: focus assurance effort on the features where failure affects patient safety or product quality, use unscripted and exploratory testing where risk is low, and accept automated test evidence as evidence. That is the bridge between a regulated environment and ordinary CI/CD.
Mapping validation onto normal engineering
The insight worth articulating in an interview: validation and modern software practice are the same activity documented differently.
| Regulatory artefact | Engineering equivalent |
|---|---|
| User Requirements Specification | user stories with acceptance criteria |
| Traceability matrix | requirement id referenced in the test name and the ticket |
| OQ / PQ test evidence | automated test suite output, retained per pipeline run |
| Change control | pull request with review, approval and linked ticket |
| Configuration management | infrastructure as code, pinned dependencies, tagged releases |
| Periodic review | scheduled audit of access, dependencies and open findings |
| Deviation / CAPA | incident report and postmortem with actions tracked to closure |
The engineering work is making CI produce durable, attributable evidence: test results tied to a commit, an immutable build artefact, a deployment record naming who approved it and when, and retention long enough to satisfy the auditor.
Supplier assessment is the piece engineers forget. Third-party components, cloud services and open-source dependencies used in a GxP system are assessed and documented. An SBOM plus a documented dependency policy is most of the answer.
Validated systems and continuous delivery
The common assumption is that regulated means you cannot deploy frequently. Not true, and saying so well is a strong answer:
- Classify by risk. A change to a reporting label is not a change to the randomisation engine.
- Automate the evidence rather than the paperwork — the pipeline emits the test record.
- Keep the validated boundary small: isolate the GxP-relevant service so unregulated components deploy freely.
- Use change control that is proportionate: reviewed, approved and traceable, not a committee meeting per release.
Interview angle
- “What does GxP mean for how you build software?” - a system supporting regulated decisions needs documented evidence it works, immutable audit trails with prior values retained, unique authenticated users, controlled change, and multi-year retention. In practice: no destructive updates on regulated records, and CI that produces durable evidence tied to a commit.
- “What is ALCOA+?” - attributable, legible, contemporaneous, original, accurate, plus complete, consistent, enduring and available. As engineering requirements they are authentication, append-only audit trails, server-side timestamps, no silent overwrites, and tested backups.
- “What does 21 CFR Part 11 require of a database?” - computer-generated audit trails independent of the operator, recording who changed what and when, with the previous value preserved. A soft-delete flag is not an audit trail; an append-only event log or bitemporal tables are.
- “Does validation block continuous delivery?” - no, if you apply CSA’s risk-based approach: heavy assurance on safety-critical paths, automated test evidence accepted as evidence, and a small validated boundary so unregulated services deploy normally.
- “How would you approach CSV as an engineer new to it?” - map it onto what already exists. Acceptance criteria are requirements, the automated suite is the qualification evidence, the pull request is change control, IaC is configuration management. The work is making that evidence durable and traceable, not inventing a parallel process.