Computer system validation training: the risk-based GAMP 5 approach

Starts with a self-rating of your computer system validation knowledge and the question of how you know the software behind batch release works as you use it. Three recent FDA cases follow, including an over-the-counter drug maker in August 2025 with no procedure for reviewing electronic data before release, and a drug manufacturer in the USA in April 2026, covering uncontrolled rights, unreviewed audit trails, missing backups and an update that bypassed security. You then learn that validation means documented evidence a system is fit for its intended use, with effort matched to risk. You meet LMN Biologics, a biologics manufacturer in Singapore, with bioreactor control, a manufacturing execution system, a chromatography data system and a cloud quality system. It ends with the course structure and a recap.

What you will be able to do

• Explain what computer system validation means for intended use
• Recognise the CSV failures behind recent FDA warning letters
• Describe the GxP systems at the company the course follows

Why it matters

Seeing how unvalidated systems led to warning letters shows why the vendor's word is never enough for GMP use.

Practice: Practice: Why validate computerised systems · 3 questions

Opens with LMN Biologics choosing which regulator's expectations its new laboratory system should meet, since it supplies the USA, the EU and Asia. You then learn the main rules: Part 11 validation for accuracy, reliability and detecting altered records, drug CGMP, Annex 11, PIC/S and WHO guidance, and how they shape the validation plan. The module explains what changed: FDA's computer software assurance guidance in 2026, the GAMP 5 Second Edition in 2022, the EU drafts consulted on in 2025 while the 2011 Annex 11 still applies, and a device company's procedure citing a Part 820 section removed in February 2026. It shows the record FDA still recommends, and ends with the common ground: intended use, effort matched to risk, life cycle and enough evidence.

What you will be able to do

• Explain what Part 11, Annex 11, PIC/S and WHO expect of validation
• Describe what FDA computer software assurance changed in 2026
• Identify the common ground across the CSV rulebooks

Why it matters

Seeing where the rulebooks agree lets you plan one validation that satisfies inspectors from every market you supply.

Practice: Practice: Regulatory expectations and what changed · 3 questions

Starts with two teams validating LMN Biologics' new laboratory system: one writes hundreds of tests from the vendor demonstration and gives the release calculation one quick check, the other starts from the process. You then learn the five GAMP 5 key concepts as ISPE and public summaries describe them: product and process understanding, a life cycle within the quality system, scalable activities, science-based risk management, and supplier involvement, plus Annex 11 formal agreements. The module explains the Second Edition's call for critical thinking by experienced people. A medical device maker in Boston and a contract manufacturer in Hong Kong show the concepts applied. It ends with the documents and records involved, a validation plan that gives reasons for its choices, and a recap.

What you will be able to do

• Explain the five GAMP 5 key concepts in plain words
• Apply process understanding to decide where validation effort goes
• Write a validation plan that records the reasons for each choice

Why it matters

Understanding the process before writing tests puts effort on the results that decide batch release, not on every screen.

Practice: Practice: The GAMP 5 key concepts · 3 questions

Opens on day two of an inspection at an LMN Biologics sister site, where stability results are trended in an unlisted spreadsheet that had supported two shelf-life decisions for four years. You then learn the four life cycle phases, concept, project, operation and retirement, and that validation spans them all. The module explains the inventory: every system with its GxP use, ranked by impact, including spreadsheets that calculate results and cloud services holding GxP records, with a contract research laboratory in London assessing its forty instruments. It covers the validation policy or master plan, and a plan for each system tailored to type, impact and risk and approved before testing starts. It ends with the common mistake, a practice exercise with a model answer, and a recap.

What you will be able to do

• Build a system inventory that includes spreadsheets and cloud tools
• Assess each system's GxP use and rank it by impact
• Explain why a validation plan is approved before testing starts

Why it matters

A complete inventory finds the forgotten spreadsheet before an inspector does, along with the decisions that depend on it.

Practice: Practice: The life cycle, inventory and planning · 3 questions

Starts with two pieces of laboratory software at LMN Biologics: an off-the-shelf balance software used as supplied, and the new configured laboratory system. You then learn the software categories as public sources describe them, infrastructure, non-configured, configured and custom, with firmware absorbed into the others. The module explains that category is one factor, and ISPE says to scale on GxP impact, complexity and novelty, with categories three to five as a continuum, looking inside the system function by function as FDA suggests. A vaccine maker in Mumbai with a mature manufacturing execution system and a medical device maker in Boston with a small label script show scaling at work. It covers PIC/S records, tools that become infrastructure, and ends with records and a recap.

What you will be able to do

• Explain the GAMP 5 software categories and how they changed
• Scale validation effort by GxP impact, complexity and novelty
• Identify when an infrastructure tool becomes a regulated record

Why it matters

Scaling by impact and use, not category alone, avoids both over-testing simple tools and under-testing critical ones.

Practice: Practice: Software categories and scaling effort · 3 questions

Opens with a team charmed by a supplier's demonstration that signs a contract within a month, without asking about unique logins, audit trails on result changes or data migration. You then learn to write user requirements based on risk and GMP impact, numbered, testable and traceable, with critical data controls such as attributable data and no shared logins, record retention and accurate copies. The module covers assessing suppliers in proportion to risk with questionnaires, the supplier's documents, independent reports or audits, as LMN Biologics did. A generic tablet maker in Toronto buying a chromatography data system and a clinical trial supplies firm in Dubai adding a hosted label tool show different depths. It ends with life cycle agreements, including subcontractors, and a recap.

What you will be able to do

• Write numbered, testable user requirements for critical data
• Assess a supplier in a depth matched to the system's risk
• Check that agreements set roles for the whole life cycle

Why it matters

Writing your needs first means you judge the product against your GMP work, not against the supplier's demonstration.

Practice: Practice: User requirements and supplier assessment · 3 questions

Starts with a team that rates every function high risk, writes hundreds of test scripts and gives the few critical functions the same tired attention as screen layouts. You then learn to assess risk function by function using FDA, EU, PIC/S and WHO guidance, looking for reasonably foreseeable failures. The module explains rating each function through patient safety, product quality and data integrity, and asking whether a person would notice a failure, with a resource planning system and a study data system at a contract research laboratory in London. A contract manufacturer in Hong Kong rates its weight display lower because an independent second check is in a written procedure. It covers the procedure, function list and reasons, a practice exercise with a model answer, and a recap.

What you will be able to do

• Rate each function for patient safety, product quality and data integrity
• Explain how a written independent check can lower a risk rating
• Link each risk rating to its requirement and its testing

Why it matters

Separating the few risky functions from the many safe ones puts testing effort where a failure could hurt a patient.

Practice: Practice: Functional risk assessment · 3 questions

Opens with two testers on one project: one follows a three hundred step script with a screenshot at every click, the other explores risky functions with odd values and wrong orders and finds the defects. You then learn scripted testing, robust or limited, recorded in advance in a test tool or spreadsheet, for checks that must be repeatable and traceable. The module explains unscripted testing, scenario testing, error guessing and exploratory testing, which depend on the tester's skill, and using a supplier's work as a starting point. A vaccine maker in Mumbai tests a training records module. It covers recording and re-testing defects, FDA's preference for digital records such as logs, audit trails and automated results over screenshots, and ends with a recap.

What you will be able to do

• Choose scripted or unscripted testing according to risk
• Apply exploratory testing and error guessing to risky functions
• Write a lean test record with a conclusion, tester and date

Why it matters

Choosing the test that finds the failure you fear finds more defects with less paper than scripting every click.

Practice: Practice: Scripted and unscripted testing · 3 questions

Starts with a release meeting where nobody can say which test covers the audit trail requirement, and two days later it turns out that requirement was never tested. You then learn to trace each requirement to its risk, test and result, in both directions and ideally in a tool. The module explains the validation report: referring to the protocol, including change control records and deviations, and stating a clear conclusion, with the links PIC/S tells inspectors to look for in a validation summary report. A medical device maker in Boston and a generic tablet maker in Toronto show release decisions, with the head of quality approving and every reason written down. It ends with release only when procedures, training and support are ready, open issues controlled, and a recap.

What you will be able to do

• Build traceability from each requirement to its test and result
• Write a validation report that explains every deviation
• Check that procedures, training and support are ready before release

Why it matters

Traceability lets you show an inspector the test behind any requirement within a minute, and stops untested gaps reaching release.

Practice: Practice: Traceability, reporting and release · 3 questions

Opens with an FDA warning letter from April 2026 to a drug manufacturer in the USA, where a software update let users bypass security access restrictions on a laboratory system. You then learn that any change, including configuration and supplier updates, is made only under a defined procedure, assessed, approved, tested to its risk and recorded, with change control linked to configuration management. A clinical trial supplies firm in Dubai tests labels before a hosted tool's date format update takes effect. The module explains incidents, logged, assessed and restored, and repeat events investigated as problems, with a contract research laboratory in London logging slow screens. It covers CAPA that fixes the root cause and checks similar systems, linked incident and change logs, a practice exercise and a recap.

What you will be able to do

• Apply change control to supplier updates and configuration changes
• Tell an incident from a problem and investigate repeat events
• Link incident and change logs so fixes can be traced both ways

Why it matters

Controlling every change keeps a validated system in its validated state, even when the supplier pushes updates.

Practice: Practice: Change, incidents and CAPA · 3 questions

Starts with an FDA warning letter from April 2025 to a drug manufacturer in the Netherlands that did not adequately back up laboratory data and gave staff rights to delete or modify files. You then learn periodic review: looking at use, problems, controls and status, and concluding whether the system is still valid, with a vaccine maker in Mumbai reviewing its chromatography data system. The module covers backups that are restored and checked, as a contract manufacturer in Hong Kong does yearly, and written, tested continuity plans. It explains data migration under a formal plan and change control, checking data are not altered in value or meaning, and archives that keep metadata and signatures. It ends with a retirement plan, operation records and a recap.

What you will be able to do

• Run a periodic review that concludes whether a system is still valid
• Test that backups can be restored with complete data
• Plan data migration and retirement that keep meaning and audit trails

Why it matters

Restored backups and verified migrations keep records findable to the end, instead of trusting a backup nobody has tested.

Practice: Practice: Periodic review, backup, retirement · 3 questions

Opens with a cloud supplier saying its product is validated and GMP compliant, and the questions that follow about whose use, which configuration and who controls updates, backups and access. You then learn that regulatory responsibility stays with the regulated company, with responsibilities and data access agreed in writing and a way to restore the validated state. The module covers agile work in two-week cycles at a medical device maker in Boston, allowed with adequate documentation. It explains FDA's description of spreadsheets as dynamic records, with a generic tablet maker in Toronto finding sixty laboratory spreadsheets and locking the dozen used for release as validated templates. It ends with how PIC/S says inspectors work, starting from the validation summary report, and a recap.

What you will be able to do

• Agree cloud responsibilities and data access with a supplier in writing
• Validate spreadsheet templates used for GxP calculations
• Prepare validation evidence the way inspectors review it

Why it matters

Applying the same principles to cloud, agile and spreadsheets keeps modern tools under control and evidence ready to show.

Practice: Practice: Cloud, agile, spreadsheets and inspections · 3 questions

Starts with a question: in ten minutes, how would you show an inspector that your most critical system can be trusted? You then follow LMN Biologics' own story, from an ageing laboratory system, unlisted spreadsheets and every function rated high risk, through each life cycle phase drawn from a course module. You see planning, the supplier assessed with a questionnaire, independent reports and a remote audit that revealed a hosting subcontractor, risk assessed before tests, and limits and wrong entries tested. The module shows a change record with its review and regression results, tested restores, a rehearsed continuity plan and yearly periodic review. It gives a road map, list, specify, assess, verify, release and maintain, the key sources, and the final exam with its 60% mark.

What you will be able to do

• Trace one system through every phase of the validation life cycle
• Apply the road map starting with your most critical system
• Explain the evidence that shows a critical system can be trusted

Why it matters

Seeing one full case end to end gives you a road map to start validating your own most critical system.

Practice: Practice: Putting it together at LMN Biologics · 3 questions