Key takeaways
- Validation shows a computerised system is fit for its intended use, and the evidence has to stand up to an inspection years later.
- Current thinking — the second edition of GAMP 5 and FDA’s computer software assurance guidance — puts risk first: test hardest where a failure could affect patients, product quality or data integrity.
- Traceability from requirement to risk, test, result and approval is the backbone of the record.
- Data integrity expectations, summarised as ALCOA+, apply to the system’s own records: audit trails, access and retention.
- Agile delivery and validation fit together when change control and evidence are produced inside the sprint, not assembled at the end.
What validation is for
Software that supports regulated work in life sciences — manufacturing, quality, clinical and laboratory activities — has to be shown fit for its intended use. In the US, 21 CFR Part 11 sets requirements for electronic records and signatures, including validation, audit trails and access controls. In the EU, Annex 11 of the GMP guidelines covers computerised systems. Both expect the evidence to exist, to be controlled, and to make sense to an inspector.
Risk first, not paper first
ISPE’s GAMP 5, the industry’s practical guide, published its second edition in 2022 with more weight on critical thinking, risk-based assurance and support for iterative development. FDA’s guidance on computer software assurance for production and quality system software makes a similar point: concentrate effort where a failure could affect patient safety or product quality, and use lighter, less scripted testing where the risk is low.
In practice that means classifying each function by the harm a failure could cause, and matching the depth of testing — and of documentation — to that class.
| Risk | Example function | Assurance |
|---|---|---|
| High | A calculation used to release a batch | Scripted tests with recorded results and independent review |
| Medium | A workflow that routes a deviation for approval | Scenario tests against the requirement, with results recorded |
| Low | Report layout and dashboards | Unscripted or exploratory testing, summarised |
Traceability is the backbone
An inspector will ask how you know a requirement is met. The answer is a chain: the requirement, the risk assessed against it, the test that verifies it, the result and the approval, each linked and versioned. Kept as the work happens, that chain is the validation record. Rebuilt at the end, it becomes a project of its own.
Data integrity applies to the system itself
Regulators summarise data integrity as ALCOA+: records should be attributable, legible, contemporaneous, original and accurate, as well as complete, consistent, enduring and available. For the software, that means audit trails that cannot be quietly switched off, access tied to named people, and retention that outlives the project.
Agile and validated, together
- Change control inside the sprint: each change carries its impact assessment and approval, recorded when it is made.
- Tests drafted with the requirement, so traceability is built as you go rather than reconstructed.
- Protected approved versions: a change to an approved test or document creates a new version.
- A release decision on evidence, with the approver and any open risks recorded.