Computer software assurance (CSA) vs CSV: what changes for pharma

From documentation to critical thinking

Traditional CSV often treated every requirement the same way. CSA starts by asking what the software is intended to do and what would happen if a feature failed. Features with high process risk — for example, a calculation that determines whether a batch passes, or an electronic signature that releases product — get rigorous, scripted testing. Features with low risk — a report layout, a search filter — may need little more than unscripted or exploratory testing.

More testing methods are acceptable

CSA explicitly recognises unscripted testing alongside scripted testing:

• Scripted testing: step-by-step test cases with expected results — still right for high-risk features.
• Exploratory testing: an experienced tester exercises the feature against test objectives without a fixed script, recording what was tested and the outcome.
• Ad hoc testing: informal checks for low-risk features where a brief record of the result is enough.

Less evidence for evidence’s sake

Screenshots of every step rarely add assurance. CSA encourages a concise record: the intended use, the risk determination, the assurance activities performed, any issues found, a conclusion and who performed the work, and when. The record must still be sufficient for an inspector to understand what was done and why.

Leveraging the supplier

Where a supplier has a mature quality system and documented testing, you can use that work rather than repeat it — after assessing the supplier. GAMP 5 has long encouraged this; CSA makes it central.

Misreading CSA as “less validation” is the fastest route to an inspection finding. Several things stay exactly as they were:

• Validation is still required. Annex 11 and Part 11 still expect computerised systems to be validated for their intended use; CSA is one way of meeting that expectation.
• Part 11 controls still apply: audit trails, electronic signatures (21 CFR 11.50 and 11.200), access controls and record protection are not risk-assessed away.
• Data integrity expectations — ALCOA+ — are unchanged.
• Change control, periodic review, incident management, backup and restore, and business continuity remain part of the system life cycle.
• Traceability is still expected: an inspector should be able to follow a requirement through its risk assessment to the evidence that it works.
• The regulated company remains accountable. A supplier can provide evidence; it cannot take on your responsibility for validation.

1. Define intended use. Describe what the system does in your processes, which records it creates and which GMP decisions depend on it.
2. Identify features and requirements. Break the system into features and record the requirements that matter for your use.
3. Assess risk per feature. Ask whether a failure could directly compromise product quality, patient safety or data integrity (high process risk), or only indirectly (lower risk). Record the reasoning.
4. Select assurance activities. Match the method to the risk: scripted testing for high risk, exploratory or ad hoc for lower risk, supplier evidence where it is adequate.
5. Execute and record. Capture what was tested, the result, any defects and their resolution, and who did the work.
6. Check coverage. Confirm every approved requirement is linked to a verified test or a documented rationale, and resolve any gaps.
7. Conclude and release. Approve the validation summary, then keep the system in a validated state through change control and periodic review.

Steps 3, 4 and 6 are where CSA either succeeds or fails. A defensible risk assessment and a clean traceability view are what let a reduced testing effort survive an inspector’s questions.

• Rating everything low risk. If nearly every feature is assessed as low risk, the assessment will not be believed. Be honest about calculations, status changes, release decisions and signatures.
• Unscripted testing with no record. Exploratory testing still needs a record of objectives, scope, results and the tester.
• Skipping supplier assessment. Supplier documentation can only be leveraged after you have assessed the supplier’s quality system.
• Forgetting the procedures. Your validation SOPs and templates must be updated to permit CSA methods, otherwise inspectors will compare your work against your own outdated procedures.
• Losing traceability. Lean documentation is fine; broken links between requirements, risks and evidence are not.

Regulators outside the medical device world have not adopted the CSA guidance as such, but EU, UK and PIC/S inspectors have long expected a risk-based approach under Annex 11 and GAMP 5. Frame your approach in those terms: explain your risk methodology, show how it set the depth of testing, and demonstrate traceability from requirement to evidence. The vocabulary matters less than the reasoning — a clear, documented rationale is what inspectors are looking for.

Swat iQua Suite follows a GAMP 5 risk-based validation approach and includes a CSA requirement and traceability register as a platform module that cannot be switched off:

• A controlled register of system requirements, each with a risk level of low, medium or high.
• Trace links from requirement through risk assessment, test case and execution to defects, each moving from planned to linked to verified or failed.
• A coverage report showing which approved requirements have a verified test execution — and where the gaps are.
• Approval with an electronic signature and segregation of duties: the approver cannot be the requirement owner.
• Approved items cannot be edited; a controlled correction creates a new version and keeps the original.

The platform’s Part 11 controls — complete audit trail with a reason for every change, electronic signatures at three levels, segregation of duties in 25 modules, multi-factor login and trusted time — are the features your risk assessment will rate highest, and they are designed to comply with 21 CFR Part 11 and EU GMP Annex 11. Our team also supports your validation of your installation as part of implementation. Validation itself remains your responsibility as the regulated company; Swat iQua Suite gives you the traceability and evidence to carry it out efficiently.