Validating Custom Software: GAMP 5, CSA and What You Should Receive From Your Developer
Custom software in a regulated laboratory or manufacturing process has to be validated, and the regulated company, not the developer, is responsible for that validation. That does not mean the developer’s job ends at delivery. Almost everything a validation rests on (requirements, design, risk assessment, test evidence, change history) is produced during development, and a developer who does not produce it leaves the customer to reconstruct it afterward, which is slow, expensive and unconvincing to an inspector. This article explains what validation means for custom software under GAMP 5, how the FDA’s 2025 computer software assurance guidance and the draft Annex 11 have changed the expectations, what installation, operational and performance qualification are, and, most usefully, the documents you should expect to receive from whoever builds your software.
What validation means, and whose job it is
Validation is documented evidence that a system does what it is intended to do, consistently, for its intended use. 21 CFR Part 11 §11.10(a) requires validation of systems “to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records”. EU Annex 11 §4 requires validation documentation and reports to cover the relevant steps of the lifecycle, and puts the responsibility on the regulated user, while §3 requires the user to assess suppliers and allows supplier documentation to be used in support.
Three consequences follow. Validation is against intended use, so it cannot be finished by a vendor who does not know how you will use the software. It is documented, so the evidence matters as much as the testing. And it is a lifecycle activity, so it starts with requirements and continues through change control until the system is retired. The developer’s contribution is to produce the software and the evidence in a form that makes the customer’s validation possible.
GAMP 5 categories and why custom software is category 5
GAMP 5, ISPE’s guide to compliant GxP computerized systems, whose second edition was published in July 2022, classifies software into categories that scale the validation effort.
| GAMP 5 category | What it covers | Examples | Validation approach |
|---|---|---|---|
| 1: Infrastructure software | Generic foundation software not built for a GxP task | Operating systems, databases, middleware, programming languages | Record name and version, confirm installation, control change |
| 3: Non-configured products | Off-the-shelf software used as delivered | Instrument software run with default settings, commercial analysis packages | Supplier assessment, requirements, installation checks, risk-based testing |
| 4: Configured products | Commercial software adapted through configuration without changing code | LIMS, ELN, MES, QMS | Supplier assessment, specifications, full testing of the configuration |
| 5: Custom applications | Software written for the purpose, including in-house code and materially modified open source | Custom analysis tools, instrument interfaces, bespoke databases, workflow automation | Full lifecycle: requirements, design evidence, reviews, version control, verification, scaled to risk |
Custom software is category 5 because there is no supplier history and no installed base to lean on: the evidence that it works has to be created for it. GAMP 5 second edition is explicit that the activities and their rigor should be scaled to the software’s intended use, complexity, novelty, supplier evidence, GxP impact and identified risks, which is the point at which critical thinking replaces a fixed checklist.
The practical implication for a buyer is that a custom build from a developer with no lifecycle process is a category 5 system with no supplier evidence, and the whole burden falls on the customer. A build from a developer who works to a documented lifecycle is a category 5 system with supplier evidence that the customer can assess and use.
From CSV to CSA: the risk-based turn
For two decades computer system validation in pharma meant a large volume of scripted tests and screenshots, produced whether or not they told anyone anything. Two developments have changed that.
The first is GAMP 5 second edition, which added an appendix on critical thinking, supported agile and iterative development for regulated software, and moved the emphasis from documents to records and information kept in the tools where the work happens.
The second is the FDA’s guidance on Computer Software Assurance for Production and Quality System Software, finalized on 24 September 2025. It supersedes section 6 of the 2002 General Principles of Software Validation and applies a risk-based approach: identify the intended use, assess the risk to product quality and patient safety, choose assurance activities proportionate to that risk, and record them. The guidance states that “software testing alone is often insufficient to establish confidence that the software is fit for its intended use”, and it recognizes unscripted and ad hoc testing, supplier evidence and use history as legitimate assurance for lower-risk functions. Scripted testing is reserved for high-risk functions.
Scoping note: the CSA guidance is written for medical device production and quality system software under 21 CFR Part 820, but it has been adopted as a general model for computerized systems across GxP, and its logic matches GAMP 5 second edition.
The draft revision of Annex 11 published in July 2025 moves the same way. Its validation section permits use of a system in a limited scope before validation is fully complete, provided the validation report says so explicitly, and it expands supplier management, periodic review and audit trail review into detailed subsections.
| Property | Traditional CSV | Risk-based assurance (GAMP 5 second edition and FDA CSA) |
|---|---|---|
| Starting point | The software | Its intended use and the risk of failure |
| Test scope | Everything, scripted | Scaled to risk: scripted for high-risk functions, unscripted or exploratory for low |
| Evidence | Screenshots and signed scripts | Records of what was done, by whom, with what result, in the tools used |
| Supplier evidence | Rarely relied on | Assessed and used where it is credible |
| Documentation | Documents produced to a template | Information kept where it is generated, summarized in a report |
| Development method | Waterfall assumed | Agile supported if lifecycle controls are kept |
| Effort | Fixed and large | Proportionate; more on what matters, less on what does not |
The validation lifecycle for custom software
For a category 5 system the lifecycle runs roughly as follows, and the developer is involved in every stage but the last:
Planning.
A validation plan sets out the approach, the responsibilities and the deliverables. The customer owns it; the developer contributes the development lifecycle description and the supplier evidence.
Requirements.
The user requirements specification (URS) states what the software must do in the customer’s terms: the measurement, the inputs and outputs, the users, the records, the regulatory controls. It is the document everything else is traced to, and it is best written together.
Risk assessment.
Each requirement, or each function, is assessed for its impact on product quality, patient safety and data integrity. High-risk functions get design review, scripted testing and traceability; low-risk functions get lighter treatment. This is the step that makes CSA proportionate rather than arbitrary.
Specification and design.
Functional and design specifications describe how the requirements will be met: architecture, data model, algorithms, interfaces, security. For analysis software the algorithm specification and its performance evidence belong here.
Build and verification.
Code written under version control, reviewed, and tested against the specifications with recorded results. Unit and integration tests are the developer’s; the records of them are part of the evidence.
Qualification.
Installation qualification, operational qualification and performance qualification, described next.
Reporting.
A validation summary report that states what was planned, what was done, what was found and whether the system is fit for use, with any limitations.
Operation and change.
Change control, periodic review, incident management and retirement, for the life of the system.
The customer owns the validation; the developer produces most of the evidence it rests on. Traceability from requirements to results is the document inspectors open first.
IQ, OQ and PQ explained
Installation qualification (IQ) shows that the software has been installed correctly in the target environment: the right version, on the right hardware and operating system, with the right configuration, prerequisites and permissions. The developer writes the IQ protocol because the developer knows what a correct installation looks like; the customer executes it, or the developer executes it and the customer witnesses.
Operational qualification (OQ) shows that the installed software works as specified across its operating range: every function in the functional specification exercised, including the compliance controls (audit trail, signatures, access), error handling and limits. The developer writes the OQ protocol against its own specification; execution is shared.
Performance qualification (PQ) shows that the software does the customer’s job under the customer’s conditions: real samples, real users, real procedures, against the acceptance criteria in the URS. PQ belongs to the customer, because only the customer knows the intended use, but a developer who has been through customer audits will know what a convincing PQ looks like and will help design it.
The mistake to avoid is treating IQ and OQ as the whole validation. They establish that the software is installed and works as specified. PQ is what establishes that it is fit for your use, and an inspector will ask for it.
| Stage | Question it answers | Who writes it | Who executes it | Typical evidence |
|---|---|---|---|---|
| IQ | Is it installed correctly? | Developer | Customer, or developer with customer witness | Version, environment, configuration and checksum records |
| OQ | Does it work as specified? | Developer | Shared | Test results against the functional specification, including compliance controls |
| PQ | Does it do our job, in our hands? | Customer, with developer support | Customer | Results on real samples against URS acceptance criteria |
What your developer should deliver
This is the list to put in the contract. A developer who has built regulated software before will recognize every item; one who has not will ask what half of them are.
| Deliverable | What it contains | When it is produced |
|---|---|---|
| Development lifecycle description | How the developer specifies, builds, reviews, tests and releases software; the supplier evidence for your assessment | Before contract |
| User requirements specification | What the software must do, in your terms, with acceptance criteria and regulatory controls | Discovery and scoping, written together |
| Risk assessment | Impact of each function on quality, safety and data integrity; the assurance level assigned | Scoping, updated through the build |
| Functional and design specifications | How each requirement is met: architecture, data model, algorithms, interfaces, security, compliance controls | Design, maintained through the build |
| Traceability matrix | Requirements linked to specifications, to tests, to results | Maintained throughout |
| Code review and version control records | Evidence that code was reviewed and that every release is reproducible | Throughout the build |
| Test evidence | Unit, integration and system test records against the specifications, with results | Throughout the build; summarized at release |
| IQ and OQ protocols and reports | Installation and operational qualification, written against the specification | Before release |
| PQ support | Help designing PQ against the URS; sample protocols | Before and during customer PQ |
| Release notes and known issues | What is in each version, what changed, what is known not to work | Every release |
| User and administrator documentation | Operation, configuration, backup, security, audit trail review | Release |
| Validation summary input | The developer's contribution to the customer's validation report | Release |
| Change control and support process | How defects, changes and updates are handled after release, with impact assessment | Contract and release |
Two points of emphasis. The traceability matrix is the document inspectors open first, because it shows in one place whether every requirement was tested. And the timing column matters: documentation produced during the build reflects what was built; documentation written afterward to fill a checklist reflects what someone remembers.
Keeping the software validated after release
A validated system stops being validated the moment an uncontrolled change is made to it, and scientific software lives for years in an environment that changes constantly: operating system updates, security patches, new instrument firmware, new assays, staff turnover.
Change control is the discipline that keeps validation current. Every change is assessed for its impact, the affected requirements and tests are identified from the traceability matrix, the proportionate testing is repeated, and the records are updated. Under a risk-based approach a security patch to the operating system and a change to an algorithm are handled differently, which is what keeps maintenance affordable.
Periodic review confirms at intervals that the system is still fit for use, still in a validated state, and still compliant with current regulation. The draft Annex 11 makes periodic review a section of its own with twelve subsections, so expect inspectors to ask for it.
The support agreement with the developer should therefore cover impact assessment and regression testing for every release, not just the fix. A developer who ships an update without an impact statement is handing you a revalidation you did not plan for.
Validating AI and machine learning components
Machine learning changes validation in one specific way: the behavior of the component is defined by data as well as code, so the training data, the model version and the performance evidence become part of the specification. The draft Annex 22, published for consultation alongside the draft Annex 11 in July 2025, sets out expectations for AI and machine learning in GMP manufacturing, including model validation, training data quality and continuing oversight. The EU AI Act adds obligations for high-risk systems, with the application dates for those obligations deferred under the Digital Omnibus agreement of May 2026 (to 2 December 2027 for stand-alone high-risk systems and 2 August 2028 for product-embedded systems), subject to formal adoption.
For a custom tool that includes a model, ask the developer for the training and test data description, the performance metrics on held-out data that matches your samples, the model version control, the explanation of how predictions can be reviewed by a person, and the plan for detecting drift. TotalLab’s AI colony counter case study and our article on AI in 21 CFR Part 11 and GMP compliance describe how this is handled in practice.
What TotalLab delivers on a regulated project
TotalLab builds custom software for regulated laboratories and manufacturers with the compliance controls and the validation evidence designed in from the first specification.
On a regulated project the deliverables follow the table above: a user requirements specification written with the customer at scoping, a risk assessment that sets the assurance level for each function, functional and design specifications maintained through an iterative build, traceability from requirements to tests to results, IQ and OQ protocols written against the specification, support for the customer’s PQ, release notes and documentation with every version, and a change control and support process afterward. The compliance controls themselves (audit trails, electronic signatures, granular permissions, image authenticity verification) come from AuditSafe, which is already integrated into TotalLab’s own products and into other manufacturers’ instruments, so they arrive with their own evidence rather than being built and tested from scratch for each project.
TotalLab has supported customer audits by the regulatory departments of some of the world’s largest pharmaceutical companies.
Custom life science software development
Frequently asked questions
Q: What is GAMP 5 category 5 software?
A: Custom applications: software developed for a specific purpose, including in-house code and materially modified open-source software. It carries the fullest lifecycle expectations (requirements, design evidence, reviews, version control, verification), scaled to the software’s intended use, complexity, novelty, supplier evidence, GxP impact and risk.
Q: Who is responsible for validating custom software?
A: The regulated company. The developer is responsible for producing the software and the lifecycle evidence that the company’s validation relies on, and for supporting installation and operational qualification.
Q: What is the difference between CSV and CSA?
A: Computer system validation (CSV) as practiced meant extensive scripted testing regardless of risk. Computer software assurance (CSA), set out in the FDA’s September 2025 guidance, starts from intended use and risk, scales assurance activities to that risk, accepts unscripted testing and supplier evidence for lower-risk functions, and reserves scripted testing for high-risk ones.
Q: What are IQ, OQ and PQ?
A: Installation qualification shows the software is installed correctly; operational qualification shows it works as specified; performance qualification shows it does the customer’s job under the customer’s conditions. The developer writes IQ and OQ; PQ belongs to the customer.
Q: What validation documents should a software developer provide?
A: A lifecycle description, user requirements (written together), risk assessment, functional and design specifications, a traceability matrix, code review and version control records, test evidence, IQ and OQ protocols, PQ support, release notes, user and administrator documentation, and a change control process.
Q: Does agile development work for validated software?
A: Yes. GAMP 5 second edition supports agile methods for GxP software provided the lifecycle controls (requirements, risk, traceability, testing, change control) are maintained, and iterative delivery of working software is how scientific correctness is checked early.
Q: How often does validated software need revalidation?
A: Whenever a change affects it, to an extent proportionate to the change’s impact, plus a periodic review at a defined interval to confirm the validated state and regulatory currency. There is no fixed calendar rule.
Q: Do I have to validate an operating system update?
A: The update is a change to the system and needs impact assessment and proportionate testing of the affected functions, but under a risk-based approach that is usually far lighter than the original validation.
References
1. ISPE. GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition. July 2022. https://ispe.org/publications/guidance-documents/gamp-5-guide-2nd-edition
(Source for: software categories; scaling of lifecycle controls for custom components; critical thinking appendix; support for agile; shift from documents to records.)
2. U.S. Food and Drug Administration. Computer Software Assurance for Production and Quality System Software: Guidance for Industry and FDA Staff. 24 September 2025. https://www.federalregister.gov/documents/2025/09/24/2025-18468/computer-software-assurance-for-production-and-quality-system-software-guidance-for-industry-and
(Source for: the risk-based approach; supersession of section 6 of the General Principles of Software Validation; the statement that testing alone is often insufficient.)
3. U.S. Food and Drug Administration. 21 CFR Part 11, §11.10(a). eCFR. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
(Source for: the validation requirement and its wording.)
4. European Commission. EudraLex Volume 4, Annex 11: Computerised Systems. 2011. https://health.ec.europa.eu/medicinal-products/eudralex/eudralex-volume-4_en
(Source for: §3 suppliers and service providers; §4 validation; §10 change management; §11 periodic evaluation.)
5. European Commission. Stakeholders consultation on Chapter 4, Annex 11 and new Annex 22. 7 July to 7 October 2025. https://health.ec.europa.eu/consultations/stakeholders-consultation-eudralex-volume-4-good-manufacturing-practice-guidelines-chapter-4-annex_en
(Source for: the draft Annex 11 and the new Annex 22 on AI.)
6. ECA Academy. Annex 11 Draft: First Analysis. 2025. https://www.gmp-compliance.org/gmp-news/annex-11-draft-first-analysis
(Source for: limited-scope use before full validation; expanded periodic review, supplier management and audit trail review.)
7. Gibson Dunn. EU AI Act Omnibus Agreement: Postponed High-Risk Deadlines and Other Key Changes. May 2026. https://www.gibsondunn.com/eu-ai-act-omnibus-agreement-postponed-high-risk-deadlines-and-other-key-changes/
(Source for: the deferred high-risk dates of 2 December 2027 and 2 August 2028, subject to formal adoption.)
Software that arrives with its evidence
If your next tool has to pass an audit, the cheapest time to plan its validation is before a line of code is written. Book a free 30-minute discovery call and we will walk through the requirements, the risk and the document set for your project.
Book a free 30-minute discovery call