Lesson 2 of 6
Risk-based validation
13 min
The oldest failure in regulated testing is to test everything the same way: every function gets a long, pre-approved script with a screenshot for every step. It produces mountains of paper, consumes months, and spreads effort so thin that the high-risk functions get no more attention than the trivial ones. Modern guidance from both auditors and regulators points the other way: scale assurance to risk.
Computer software assurance
The US FDA formalized this thinking in its guidance on computer software assurance (CSA) for production and quality system software, finalized in September 2025 and reissued in February 2026 under the title "Computer Software Assurance for Production and Quality Management System Software." It applies to medical device manufacturers, but its ideas have influenced validation practice across life sciences. In outline:
- Identify intended useWhat is this software feature, function or operation used for?
- Assess riskWould its failure compromise product quality or safety (high process risk) or not?
- Choose assurance activitiesScale rigor to risk: scripted testing for high risk; unscripted or less formal testing where risk is lower
- Keep appropriate recordsEnough objective evidence to show the activity was done and what it found
GAMP 5's second edition takes a similar view, emphasizing critical thinking, leveraging supplier activities where justified, and using the right test approach for the risk rather than defaulting to heavy scripted testing everywhere.
Risk in SOX terms
Financial auditors think in terms of the risk of material misstatement. A control that prevents or detects a material error in revenue or inventory gets more testing than one with a remote link to the financial statements. Automated application controls can often be tested with a smaller sample than manual controls, because a configured control behaves consistently, provided the ITGCs around it (access and change management) are effective. Auditing standards also describe benchmarking: once an automated control has been tested, reliance can continue in later periods if effective change controls show it has not been changed. Your external auditor decides how this applies, so agree the approach with them.
Who decides the risk
The test lead facilitates the risk assessment but does not own it. For GxP functions, the process owner and quality assurance agree the risk rating and the assurance approach; for SOX controls, the control owner and internal audit do, ideally with the external auditor's view on key controls. Record who took part, the date and the reasoning. A risk rating set by the test team alone, under schedule pressure, will be questioned, and it should be.
A worked risk assessment
| Function | Context | Risk | Assurance approach |
|---|---|---|---|
| Three-way match tolerance | Contoso, procure to pay, company code 1710 | High: wrong tolerance lets incorrect invoices post | Scripted tests at, inside and outside the tolerance; configuration evidence; change control reliance |
| Customer credit limit check | Contoso, sales to Great Lakes Fleet Services | Medium: affects receivables risk | Scripted positive and negative tests |
| Batch usage decision | Pharma manufacturer, quality management | High process risk: releases product | Scripted tests incl. negative cases; signature and audit trail checks |
| Shelf-life date on batch | Pharma manufacturer | High: expired product could ship | Scripted tests of calculation and blocking |
| Report layout for internal planning | Either | Low | Unscripted review; brief record |
Risk drives the assurance approach. Your quality or audit function confirms the classification.
What would you do?
A validation lead proposes fully scripted, screenshot-every-step testing for all 900 configured functions in the pharma manufacturer's S/4HANA system. Go-live is in five months. What should the test lead recommend?
- Scale assurance to risk: rigor where failure would affect quality, safety or financial reporting.
- FDA's computer software assurance guidance and GAMP 5 second edition both support a risk-based approach.
- In SOX, automated controls plus effective ITGCs can reduce testing; agree benchmarking with the auditor.
- Document the risk rationale; risk-based never means weaker evidence for high-risk functions.
Check your understanding · not graded
Lesson check
1. Risk-based validation means:
2. What is the first step in the computer software assurance pattern?
3. Why can automated application controls often be tested with smaller samples?
4. What must you record when testing a function lightly?