GxP / Guide 3
Validation: GAMP 5 and computer software assurance
The validation life cycle, GAMP software categories, how FDA's CSA guidance changes testing, and a lean set of deliverables for a cloud-hosted GxP system.
Validation means documented evidence that a system does what it's meant to, consistently, for its intended use. For years it also meant thick binders of screenshots. Current thinking, in GAMP 5 second edition (2022) and FDA's Computer Software Assurance guidance (final September 2025), is the opposite: think first about risk, test hardest where failure would hurt a patient or the data, and keep the records you need, not every record you can produce.
The life cycle
Every validated system goes through the same phases, whatever the method (waterfall, agile or SaaS configuration):
- Concept and planning: intended use, GxP assessment, risk level, validation plan.
- Requirements: user requirements (URS) written as testable statements, each with a risk rating.
- Specification and build: functional and configuration specifications, or the vendor's equivalent; design reviews.
- Verification: installation, operational and performance qualification (IQ, OQ, PQ) or the equivalent risk-based testing.
- Release: traceability complete, deviations closed, validation summary report approved, procedures and training in place.
- Operation: change control, incident and problem management, access reviews, backup, periodic review.
- Retirement: data migrated or archived, access removed, records kept for their retention period.
IT owns most of phase 6. That's where systems drift out of their validated state, and where inspectors find most of their findings.
GAMP software categories
| Category | Type | Examples | Typical effort |
|---|---|---|---|
| 1 | Infrastructure software | Operating systems, databases, hypervisors, cloud platform services, backup and monitoring tools | Record version and configuration; qualify the infrastructure; no functional testing of the software itself |
| 3 | Standard, not configured | Instrument firmware, simple off-the-shelf tools used as supplied | Verify it meets requirements in your use |
| 4 | Configured | LIMS, QMS, ERP, EDC, most SaaS | Test your configuration and business process; rely on the vendor for the core product |
| 5 | Custom | In-house applications, custom code, complex spreadsheets and scripts | Full life cycle including code review and unit testing |
(There's no category 2: it was dropped in GAMP 5's first edition.) Most cloud building blocks are category 1. Your own automation that touches GxP data, including PowerShell that changes records, can be category 5, so treat it that way. The scripts on this site are read-only reports, which keeps them out of that trap.
Computer software assurance in practice
CSA was written for production and quality system software used by device manufacturers, but the approach is now widely used for pharma systems too, and GAMP 5 second edition is aligned with it. The core idea:
- Decide intended use: what the software does in your process.
- Decide risk: would a failure foreseeably compromise safety (high process risk) or not? You can use more levels if you like.
- Pick assurance activities to match: for high process risk, scripted, traceable testing. For lower risk, unscripted testing: scenario testing, error guessing, exploratory testing. Vendor testing and your own monitoring count too.
- Record enough: intended use, risk decision, what was tested, by whom, when, and the result, with issues found and how they were resolved. Screenshots of every step are not required.
The guidance explicitly covers cloud services (IaaS, PaaS and SaaS) used in production or quality systems: assess the provider's capabilities and practices, and use their certifications and documentation as part of your evidence.
Requirements that test well
Good requirements make validation short. Each one should be a single testable statement with a risk rating and a link to the predicate rule or business need:
URS-012 High Only members of grp-gxp-lims-reviewers can approve a result. 11.10(g)
URS-013 High Every change to a result records user, time, old value, new value
and reason, and cannot be edited or deleted. 11.10(e)
URS-031 Medium Result data is backed up daily and kept 10 years; a restore is
tested at least every 6 months. 11.10(c)
URS-032 Medium Platform logs for the LIMS resource group are kept at least 1 year. A11 ยง9
URS-040 Low The results list can be exported to CSV.
Requirements like URS-031 and URS-032 are infrastructure requirements. Write them down, because they're what the evidence scripts check later: Get-AzGxPBackupEvidence.ps1 and Get-AzGxPAuditLogCoverage.ps1 give you the same proof every time, on demand.
IQ, OQ and PQ in the cloud
| Stage | Question | Cloud evidence |
|---|---|---|
| IQ: installation | Was it built as specified? | The infrastructure-as-code template and its version, the pipeline run that deployed it, and an automated comparison of deployed settings against the specification |
| OQ: operational | Does each function work across its range? | Functional tests, ideally automated and kept as test results; failover, backup and restore tests for infrastructure |
| PQ: performance | Does it work in the real process, with real users? | Business process tests, usually run by the business in the validation environment |
Infrastructure as code turns IQ from a screenshot exercise into a repeatable check: the template is the specification, and a script can prove the running environment still matches it.
Environments
Keep at least development, validation (or test) and production separate, ideally as separate Azure subscriptions or AWS accounts, built from the same templates. Validation testing only counts if the validation environment is equivalent to production: same templates, same versions, same network rules. Record any differences and why they don't matter.
A lean deliverable set
For a configured (category 4) system on a qualified cloud platform, this is usually enough:
- GxP and risk assessment, validation plan (can be one document for smaller systems)
- User requirements with risk ratings
- Supplier assessment and quality agreement (vendor and cloud provider)
- Configuration specification, or the IaC repository at a tagged version
- Test evidence: scripted for high risk, unscripted records for the rest
- Traceability matrix: requirement to test to result
- Validation summary report
- Operating procedures: access management, backup and restore, change control, incident handling, periodic review
Agile works too: validate in increments, with automated tests in the pipeline and a release-level summary. What inspectors want is a clear link from intended use to risk to evidence, not a particular document template.