1What computer system validation is.
WHO defines computerised systems validation as “confirmation by examination and provision of objective and documented evidence that a computerized system’s predetermined specifications conform to user needs and intended use and that all requirements can be consistently fulfilled”.¹ FDA’s 2002 software validation guidance, written for medical devices, uses almost the same words for software.²
The system is more than the software. EU GMP Annex 11 calls a computerised system “a set of software and hardware components which together fulfill certain functionalities”, and asks for the application to be validated and the IT infrastructure qualified.³ FDA says “computer or related systems” in 21 CFR 211.68 can refer to hardware, software, peripheral devices, networks, cloud infrastructure, personnel and associated documents such as user manuals and SOPs.⁴
2What the rules require.
| Source | Status | What it asks for |
|---|---|---|
| 21 CFR 211.68 | US regulation, drug CGMP | Computers used in manufacture are routinely checked under a written programme; only authorised people change master production and control records; input and output are checked for accuracy; backups are kept; where calculations are automated, “a written record of the program shall be maintained along with appropriate validation data”.⁵ |
| 21 CFR 11.10(a) | US regulation, electronic records | “Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records.”⁶ |
| FDA data integrity Q&A, December 2018 | FDA guidance | Each CGMP workflow on a computer system is an intended use to be validated, with the extent of validation “commensurate with the risk posed by the automated system”.⁴ |
| EU GMP Annex 11, revision 1 | EU GMP guideline, in operation since 30 June 2011 | Risk management through the lifecycle, validation documentation covering the relevant lifecycle steps, a system inventory, traceable user requirements, supplier assessment, data migration checks and periodic evaluation.³ |
| WHO TRS 1019, Annex 3, Appendix 5 (2019) | WHO guideline | A full lifecycle from protocol and requirements through qualification, user acceptance testing, operation and retirement.¹ |
FDA’s data integrity guidance gives an example of why intended use matters. Qualifying a manufacturing execution system platform shows it meets its own requirements, but “it does not demonstrate that a given MPCR generated by the MES contains the correct calculations”; validating the workflow does.⁴
In the EU, a revised Annex 11, a revised Chapter 4 and a new Annex 22 on artificial intelligence went to public consultation from 7 July to 7 October 2025.⁷ The European Commission still lists the January 2011 revision of Annex 11 as the version in EudraLex Volume 4.⁸
3The steps and their deliverables.
WHO’s appendix sets out the lifecycle step by step, and Annex 11 asks for most of the same elements.¹³
| Step | Typical deliverable | What it should show |
|---|---|---|
| Plan | System inventory; validation plan or protocol | The protocol covers at least scope, risk management approach, specification, acceptance criteria, testing, review, training and release for GMP use.¹ Annex 11 asks for an up-to-date inventory and, for critical systems, a system description with data flows and interfaces.³ |
| Assess risk | Risk assessment | Decisions on the extent of validation and data integrity controls rest on “a justified and documented risk assessment”.³ |
| Specify | User requirements specification (URS); functional specification | The URS describes the required functions, is based on risk and GMP impact, and stays traceable through the lifecycle.³ Functional specifications describe functions, performance and interfaces and link back to user requirements.¹ |
| Assess the supplier | Supplier assessment; formal agreement | Competence and reliability of the supplier, an audit where risk calls for one, and agreements that state the third party’s responsibilities.³ |
| Design | Design and configuration specifications; design qualification | A documented review that the proposed design and configuration meet the user and functional specifications, with requirements traceable to them.¹ |
| Install | Installation qualification (IQ) | Evidence that the system is installed and configured in the test and production environments according to written specifications.¹ |
| Test function | Operational qualification (OQ) | Evidence that software and hardware work as intended over anticipated operating ranges, including alarms, error messages, and boundary, range, limit and nonsense-entry tests.¹ Annex 11 asks for parameter limits, data limits and error handling to be considered.³ |
| Prepare for use | SOPs and training | Procedures for system use, data and audit trail review, electronic signatures, access, backup, change and incident management, in place before PQ and release.¹ |
| Test in use | Performance qualification (PQ) and user acceptance testing (UAT) | Users verify intended use and administration in the live environment, or an equivalent one, including review of electronic data and audit trails.¹ |
| Release | Validation report | Results compared with acceptance criteria, deviations investigated and justified, and a conclusion on whether validation succeeded before release for routine GMP use.¹ |
| Operate | Change control, incident and periodic review records | Changes made only under a defined procedure; periodic evaluation that the system remains in a valid state.³ |
| Retire | Retirement and archiving records | A planned, risk-based retirement with records archived in a readable form.¹ |
The names vary. FDA’s software validation guidance calls IQ, OQ and PQ “one of many legitimate ways” to organise user-site software validation.² WHO lists the documentation that should be accessible on site, including the validation approach, approved requirements, acceptance criteria, supplier assessment, change control procedures, backup and recovery, business continuity and data security.¹
4How much validation a system needs.
Every source ties effort to risk. Annex 11 asks for risk management throughout the lifecycle, “taking into account patient safety, data integrity and product quality”.³ WHO says the level of validation should be “commensurate with the identified risks, complexity and intended use”.¹ For commercial off-the-shelf products, Annex 11 asks regulated users to review the supplier’s documentation against their user requirements.³
ISPE’s GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems, Second Edition, published in July 2022, is an industry guide to scaling this work. ISPE says it emphasises supplier involvement, iterative and incremental development, software tools and automation, and “critical thinking” by experienced subject matter experts.⁹ FDA’s Computer Software Assurance guidance, first finalised on 24 September 2025 and replaced by the current version on 3 February 2026, describes a risk-based approach for computers and automated data processing systems used as part of medical device production or the quality management system.¹⁰
5How it runs in Seal.
In Seal, the URS, functional, design and configuration specifications can be kept as controlled records linked to the configuration, its risks and its tests, as the validation and AI assurance guide describes. When a change is prepared for review, its selected user acceptance tests run and their results join the release review. Your team reviews Seal’s verification and release evidence for the version in scope, and owns the intended use, process requirements, risk acceptance and production approval.
For other systems, computer system assurance keeps intended use, function-level risk, supplier evidence, the configuration baseline, test runs, anomalies and release together, so each change is assessed from what moved. Where a site needs the IQ, OQ and PQ stages that EU GMP Annex 15 names, validation in Seal maps its evidence onto them.
References
- 1WHO Technical Report Series No. 1019, Annex 3, Good manufacturing practices: guidelines on validation, Appendix 5, Validation of computerized systems, World Health Organization, 2019. https:/
/ www. who. int/ docs/ default- source/ medicines/ norms- and- standards/ guidelines/ production/ trs1019- annex3- gmp- validation. pdf (read 6 November 2026) - 2General Principles of Software Validation; Final Guidance for Industry and FDA Staff, FDA, 11 January 2002. https:/
/ www. fda. gov/ media/ 73141/ download (read 6 November 2026) - 3EudraLex Volume 4, Annex 11: Computerised Systems, European Commission, revision 1, in operation from 30 June 2011. https:/
/ health. ec. europa. eu/ system/ files/ 2016- 11/ annex11_ 01- 2011_ en_ 0. pdf (read 6 November 2026) - 4Data Integrity and Compliance With Drug CGMP: Questions and Answers, Guidance for Industry, FDA, December 2018. https:/
/ www. fda. gov/ media/ 119267/ download (read 6 November 2026) - 521 CFR 211.68, Automatic, mechanical, and electronic equipment, eCFR. https:/
/ www. ecfr. gov/ current/ title- 21/ section- 211. 68 (read 6 November 2026) - 621 CFR 11.10, Controls for closed systems, eCFR. https:/
/ www. ecfr. gov/ current/ title- 21/ chapter- I/ subchapter- A/ part- 11/ subpart- B/ section- 11. 10 (read 6 November 2026) - 7Stakeholders’ Consultation on EudraLex Volume 4, Chapter 4, Annex 11 and New Annex 22, European Commission, July 2025. https:/
/ health. ec. europa. eu/ consultations/ stakeholders- consultation- eudralex- volume- 4- good- manufacturing- practice- guidelines- chapter- 4- annex_ en (read 6 November 2026) - 8EudraLex Volume 4, Good Manufacturing Practice guidelines, European Commission. https:/
/ health. ec. europa. eu/ medicinal- products/ eudralex/ eudralex- volume- 4_ en (read 6 November 2026) - 9GAMP 5 Guide, 2nd Edition, ISPE, July 2022. https:/
/ ispe. org/ publications/ guidance- documents/ gamp- 5- guide- 2nd- edition (read 6 November 2026) - 10Computer Software Assurance for Production and Quality Management System Software, Guidance for Industry and FDA Staff, FDA, 3 February 2026. https:/
/ www. fda. gov/ regulatory- information/ search- fda- guidance- documents/ computer- software- assurance- production- and- quality- management- system- software (read 6 November 2026)
AQuestions and answers
Is computer system validation a legal requirement?
In the US, yes for regulated records and drug manufacturing: 21 CFR 211.68 sets controls for computers used in drug manufacture, and 21 CFR 11.10(a) requires validation of closed systems that hold required electronic records. In the EU, Annex 11 is part of the EU GMP guidelines, which give guidance on interpreting the legal principles of GMP.
Do you have to validate commercial off-the-shelf software?
Yes, for its GxP intended use. Annex 11 asks you to assess the supplier, base the need for an audit on a risk assessment, and review the documentation supplied with the product to check that your user requirements are fulfilled. The extent of validation rests on a justified and documented risk assessment.
What is the difference between validating a system and validating a workflow?
Qualifying a platform shows the software meets its own requirements. FDA’s example is an MES: qualifying it does not show that a particular electronic master production record built in it has the right calculations. Each GMP workflow you configure is an intended use that needs its own verification.
How often should a validated system be reviewed?
Annex 11 asks for computerised systems to be evaluated periodically to confirm they remain in a valid state and compliant with GMP. WHO lists what a review should cover, including performance, security, maintenance, changes and upgrades, deviations, incidents and audit trail review, documentation, procedures, training and CAPA effectiveness.