Pharmaceutical manufacturing runs on the principle that you cannot inspect quality into a product — you build it in through validated processes, and you prove the processes are under control. When those processes are run or recorded by computerized systems, the same principle applies to the software: a system that touches product quality, patient safety, or data integrity is not trusted until it has been validated. This is Computer System Validation (CSV), and the framework the industry uses to do it proportionately is GAMP 5, the Good Automated Manufacturing Practice guide published by ISPE.
The regulatory backdrop is FDA 21 CFR Part 211 (current Good Manufacturing Practice for finished pharmaceuticals) and 21 CFR Part 11 (electronic records and electronic signatures), along with EU Annex 11 for the European market. Part 11 is the one that most directly shapes software: it requires that electronic records be trustworthy and reliable, that systems enforcing them be validated, that audit trails capture who did what and when, and that electronic signatures be attributable and secure. A system generating GMP records that has not been validated is, from a regulator's standpoint, generating records no one has demonstrated can be trusted — and in a data-integrity-focused inspection climate, that is a serious finding.
The central insight of GAMP 5 — reinforced in its Second Edition — is that validation effort should scale with risk and with the nature of the software, not be applied as a uniform maximum to everything. The guide is subtitled "A Risk-Based Approach to Compliant GxP Computerized Systems," and the risk-based part is the whole point. Validating a configured commercial LIMS to the same depth as bespoke custom code that controls a sterilization cycle wastes effort on the former and may under-serve the latter. GAMP 5 gives you a structured way to decide how much rigor each system actually warrants.
The mechanism for that is the software category system. GAMP 5 sorts software into categories that imply different validation approaches. Category 1 is infrastructure software — operating systems, databases, middleware — which is qualified as part of the platform rather than validated as an application. Category 3 is non-configured products used as supplied, off-the-shelf software with no meaningful configuration. Category 4 is configured products, where the software is a standard package but its behavior is defined through configuration to fit the process — the large majority of pharma business systems. Category 5 is custom or bespoke software written for the specific application, which carries the highest inherent risk because none of it has been exercised by any other user. The category shifts the balance of what you rely on: supplier evidence and configuration testing for Category 4, full lifecycle rigor including code-level design and testing for Category 5.
The lifecycle GAMP 5 describes is a V-model, and it will look familiar to anyone from a safety-critical background. The left arm descends through specification: user requirements (the URS — what the business needs the system to do), then functional specification (what the system does to meet those needs), then design specification (how it is built or configured). The right arm ascends through corresponding verification: installation qualification (IQ — the system is installed correctly), operational qualification (OQ — it functions as specified), and performance qualification (PQ — it performs in the real process with real data and users). Each specification on the left has a matching verification on the right, and the horizontal correspondence is the discipline that keeps the two arms honest.
The URS-IQ-OQ-PQ vocabulary is worth translating for engineers arriving from aerospace or defense, because the ideas map cleanly onto general systems engineering even though the words differ. The URS is the stakeholder requirements specification. IQ is installation verification. OQ is system-level functional verification against the specification — the analog of running your verification methods against each requirement. PQ is validation in the operational environment — the analog of demonstrating the system performs its intended use with representative users and data. What pharma calls "qualification" is what the broader discipline calls verification and validation, applied with the documentation rigor a regulated GMP environment demands.
Traceability is the connective tissue and, as in every regulated domain, it gets audited. GAMP 5 expects a requirements traceability matrix that links each user requirement to the functional and design specifications that address it, and forward to the qualification tests that verify it. The point of the RTM in a CSV context is to demonstrate coverage: every URS line traces to a test that proves it, and no test exists that does not trace to a requirement. When an FDA or notified-body inspector samples a user requirement and asks to see the evidence it was met, the traceability matrix is how you walk from the requirement to the OQ or PQ test result without a scramble. A CSV package with a broken or hand-maintained trace is a package with an audit exposure.
Data integrity has become the sharpened edge of pharma CSV, captured in the ALCOA+ principles: data must be Attributable, Legible, Contemporaneous, Original, and Accurate, with the "plus" adding Complete, Consistent, Enduring, and Available. Part 11 audit trails, access controls, and electronic-signature requirements all serve ALCOA+. For CSV this means the validation must specifically demonstrate that the system enforces these properties — that the audit trail cannot be disabled or altered, that records cannot be changed without a tracked reason, that access is controlled and attributable. A validation that proves the system does its functional job but never demonstrates data-integrity controls has missed the concern regulators care about most right now.
The supplier relationship is where GAMP 5 lets you avoid duplicating work, if you do it properly. For Category 3 and 4 systems, you are entitled to leverage the supplier's own development and testing evidence rather than re-verifying everything yourself — but only after a supplier assessment establishes that their quality system is adequate and their evidence is trustworthy. A documented supplier assessment can legitimately reduce your validation burden by letting you test the configuration and the intended use rather than the underlying package. Skipping the assessment and blindly trusting the supplier, or ignoring the supplier's evidence and re-testing everything from scratch, are the two ways teams get the leverage wrong.
The failure modes in pharma CSV rhyme with those in every regulated industry. Validating everything to Category 5 depth regardless of what the software actually is, burning months on OQ scripts for a configured system that a supplier assessment plus configuration testing would have covered. Writing a URS so vague that the qualification tests cannot trace to it, then improvising the trace after the fact. Treating validation as a one-time event and letting the validated state decay as the system is patched and reconfigured without change control. And producing beautiful IQ/OQ/PQ binders while never actually demonstrating the data-integrity controls that a modern inspection targets first.
Periodic review and the maintenance of the validated state deserve emphasis because CSV does not end at go-live. GMP systems live for years, accumulating patches, configuration changes, and new interfaces. Each change must go through change control, and its impact on the validated state must be assessed — the pharma version of suspect-link management. Periodic reviews confirm the system is still operating in its validated state and that the accumulated changes have not eroded it. A system that was validated in 2022 and has been changed a dozen times since, with no impact assessment on those changes, is validated on paper and unvalidated in practice.
Hitt Hosting SE's Pharma pack is organized around the GAMP 5 lifecycle rather than bolted onto a generic requirements tool. User requirements, functional and design specifications, and the IQ/OQ/PQ qualification activities live in one connected model, with each system carrying its GAMP software category so the expected depth of validation is explicit from the start. The URS-to-qualification traceability matrix an inspector asks for is generated from the live data, not assembled by hand before an audit, and data-integrity requirements trace to the tests that demonstrate the Part 11 controls. When a change is proposed to a validated system, the requirements and qualification evidence it touches are flagged, giving the change-impact assessment a complete picture and keeping the validated state honest through the years a GMP system actually operates.