Checklist: CSV/CSA Program Self-Audit

This is a ready-to-use pass/fail checklist for a computer system validation (CSV) and computer software assurance (CSA) program self-audit.

Mark each item Pass, Fail, or N/A, record the evidence, and route every Fail through your finding-classification and, where warranted, deviation process.

A filled specimen follows. Work through this with someone who can open the actual systems, change logs, and audit trails, not only the SOPs describing what should happen.

How to use

Set the audit scope first using the sampling section below; do not start checking boxes before you know which systems are in scope this cycle.
For each item, capture the actual evidence (a screenshot, a document reference, a date), not just a checkbox.
A Fail on traceability, audit trail review, or supplier reliance with no assessment is high priority; these break the defensibility of the whole validated state.

Section 0: Audit scope and sampling

#	Item	Evidence / answer
0.1	The systems in scope this audit cycle are documented, with the sampling rationale (criticality tier, recent change, prior finding, overdue review) recorded before starting	`<<FILL>>`
0.2	Every high-criticality system is in scope this cycle; no high-criticality system was skipped	`<<FILL>>`
0.3	The medium and low-tier sample is risk-weighted, not a flat random pull, and a documented rotation ensures every system is covered within a defined number of cycles	`<<FILL>>`

Section 1: System inventory and classification

#	Item	Evidence / answer
1.1	A current, complete inventory of all GxP computerized systems exists, including standalone instruments, cloud/SaaS applications, and departmental spreadsheets	`<<FILL>>`
1.2	Every inventory entry names a system owner and a documented GxP-impact basis	`<<FILL>>`
1.3	The inventory was updated within the last twelve months	`<<FILL>>`
1.4	Walking the floor/labs and asking staff what they use to record or calculate GxP data turns up nothing missing from the inventory	`<<FILL>>`
1.5	Every system has a documented GAMP 5 category with rationale, and multi-component systems are decomposed by component	`<<FILL>>`
1.6	The validation deliverable set on file matches what the assigned category demands (no Category 5 component covered only by Category 3 evidence)	`<<FILL>>`

Section 2: Validation documentation

#	Item	Evidence / answer
2.1	An approved validation plan exists for each sampled system, approved before testing began	`<<FILL>>`
2.2	The plan documents a risk-based rationale for testing scope, not “test everything” or “test nothing” as a default	`<<FILL>>`
2.3	Every sampled system has an approved URS with GxP-critical requirements identified and testable	`<<FILL>>`
2.4	Scripted test records carry predefined steps, expected results, actual results, and a pass/fail with attribution	`<<FILL>>`
2.5	Unscripted/exploratory test records state what was explored, why that method was chosen for that function, and the outcome, approved by QA	`<<FILL>>`
2.6	Test failures are documented on the record, not corrected and re-run silently	`<<FILL>>`
2.7	Every completed validation has a summary report with an explicit fit-for-intended-use conclusion, approved by QA before production use	`<<FILL>>`

Section 3: Requirements traceability

#	Item	Evidence / answer
3.1	A requirements traceability matrix exists for each sampled system	`<<FILL>>`
3.2	Pick one GxP-critical requirement at random; trace it from URS to evidence (scripted, unscripted, or supplier) to result in under ten minutes	`<<FILL>>`
3.3	No orphan tests (tests with no parent requirement) and no untested requirements without documented rationale	`<<FILL>>`

Section 4: Supplier assessment and reliance

#	Item	Evidence / answer
4.1	A documented supplier assessment exists for each sampled system relying on vendor evidence	`<<FILL>>`
4.2	The assessment states a conclusion: what site-level testing is reduced or eliminated because of it, not just “documentation reviewed”	`<<FILL>>`
4.3	For cloud/SaaS systems, the assessment covers data security, backup/recovery, and audit trail capability	`<<FILL>>`

Section 5: Change control

#	Item	Evidence / answer
5.1	Every change, including vendor patches and configuration changes, goes through a documented impact assessment before implementation	`<<FILL>>`
5.2	Compare the current configuration of one sampled system against its documented validated configuration; every difference has a change record	`<<FILL>>`
5.3	Vendor security patches follow a documented expedited pathway, not production application with no change record	`<<FILL>>`

Section 6: Periodic review

#	Item	Evidence / answer
6.1	Every sampled system’s periodic review is current against its defined frequency	`<<FILL>>`
6.2	The most recent review actually sampled the audit trail and reconciled the running version against the validated version, not only “no changes noted”	`<<FILL>>`
6.3	User access was reconciled against current personnel in the most recent review	`<<FILL>>`

Section 7: Retirement and data migration

#	Item	Evidence / answer
7.1	Retired systems have a documented retirement plan addressing data retention and access	`<<FILL>>`
7.2	Any migrated data was verified complete and accurate, with the audit trail preserved	`<<FILL>>`
7.3	Archived records from a retired system are retrievable in human-readable form within the retention period	`<<FILL>>`

Section 8: Program governance

#	Item	Evidence / answer
8.1	Validation SOPs are aligned with GAMP 5 Second Edition and the current FDA CSA guidance, and reflect actual practice	`<<FILL>>`
8.2	QA has a documented record of sending at least one weak validation package back in the audit period	`<<FILL>>`
8.3	Practitioners validating unusual technologies (cloud, AI/ML, custom APIs) can demonstrate the specific competence those technologies require	`<<FILL>>`

Signoff

Field	Entry
Program / site audited	`<<FILL>>`
Systems sampled (count / tier breakdown)	`<<FILL>>`
Audit period	`<<FILL>>`
Findings raised (count, by priority)	`<<FILL>>`
Lead auditor (name, signature, date)	`<<FILL>>`
QA reviewer (name, signature, date)	`<<FILL>>`

References

GAMP 5 Second Edition, ISPE, 2022. FDA Guidance, Computer Software Assurance for Production and Quality Management System Software, current version. EU GMP Annex 11 (Computerised Systems) and Annex 15 (Qualification and Validation). 21 CFR Part 11 (Electronic Records; Electronic Signatures). ICH Q9(R1), Quality Risk Management.

Confirm current versions before relying on this checklist.

Filled specimen

Section 3 and the signoff completed for an example annual self-audit. Illustrative only.

#	Item	Pass / Fail / N/A	Evidence / answer
3.1	RTM exists for each sampled system	Pass	RTM-LIMS-04, RTM-CDS-07 on file, reviewed
3.2	Trace a GxP-critical requirement URS to evidence to result in under ten minutes	Pass	URS-101 (self-approval prevention) traced to TS-12 to Pass result in 4 minutes
3.3	No orphan tests, no untested requirements without rationale	Fail	3 test scripts in the CDS package have no parent requirement listed in the RTM

Field	Entry
Program / site audited	Manufacturing site 2, CSV program
Systems sampled	17 of 40 (6 high, 6 medium, 5 low)
Audit period	Q3 2026
Findings raised	4: one major (3.3 orphan tests), three minor
Lead auditor	S. Weber, signed, 04 Sep 2026
QA reviewer	R. Gomez, signed, 05 Sep 2026

The orphan-test finding (3.3) was raised as major because it means the CDS validation package cannot demonstrate complete traceability; the RTM was corrected and the three tests mapped to their actual requirements before the audit closed.

Common inspection findings this checklist surfaces

A system in production GxP use with no entry in the inventory.
A validation summary report with no stated fit-for-intended-use conclusion.
Traceability that cannot be demonstrated live, in minutes, for a random requirement.
A supplier assessment that never states what site testing it justifies reducing.
Periodic reviews that are current on the schedule but shallow in substance.

How to adapt this checklist

Set your sampling tiers and thresholds in Section 0 to match your actual system population and criticality model.
Tie the finding-priority scheme to your audit finding classification procedure and the triage logic in the parent article.
Add site- or technology-specific rows (AI/ML systems, custom APIs, decentralized clinical technology) where your portfolio warrants deeper questioning.