Computerized Systems • Inspection Readiness • Data Integrity
CSV Inspection Findings and Common Compliance Gaps
Computerized system validation inspections examine more than protocols and signatures. Inspectors look for evidence that GxP systems are fit for intended use, records remain trustworthy, access is controlled, changes are assessed, and quality oversight works in day-to-day operations.
Quick answer
Common CSV inspection findings involve weak validation evidence, unclear system intended use, incomplete risk assessment, uncontrolled changes, poor access management, inadequate audit-trail review, incomplete electronic records, insufficient supplier oversight, and ineffective CAPA. These gaps matter when a firm cannot show that its computerized systems consistently protect product quality, patient safety, and reliable records. Inspection readiness comes from accurate system inventories, risk-based validation, controlled operations, traceable evidence, and effective follow-up—not from document volume alone.
What do inspectors assess during a CSV inspection?
Inspectors assess whether computerized systems used in regulated activities are controlled throughout their lifecycle. The review may cover system selection, intended use, requirements, validation, security, data handling, audit trails, supplier controls, change management, backup and recovery, periodic evaluation, and the quality unit’s oversight.
The focus is not simply whether a validation package exists. Inspectors may compare procedures and protocols with actual system use, observe user practices, review data and audit trails, examine access rights, inspect change history, and trace a record from creation through review, approval, retention, and retrieval.
A system can have a signed validation report and still present compliance risks if production configuration differs from the approved baseline, privileged accounts are not controlled, or staff routinely use unapproved workarounds. Effective Computerized System Validation demonstrates that systems remain fit for their intended use during operation, not only at go-live.
Regulatory context for computerized system compliance
Applicable requirements depend on product type, system use, jurisdiction, and predicate rules. The following sources are useful starting points for pharmaceutical firms:
- EU GMP Annex 11: Covers computerized systems used as part of GMP activities. It addresses risk-based validation and data-integrity controls, supplier and service-provider considerations, audit trails, security, change management, periodic evaluation, and business continuity.
- 21 CFR Part 211: Includes requirements for electronic equipment and systems, accurate input/output checks, backup data, written procedures, record review, and quality-unit responsibilities, depending on the system and process.
- 21 CFR Part 11: Applies where electronic records or electronic signatures fall within its scope. Part 11 should be evaluated together with applicable predicate-rule requirements.
- FDA Data Integrity guidance: FDA’s questions and answers explain expectations for reliable and accurate CGMP data and risk-based controls to prevent and detect data-integrity issues.
Regulatory sources set outcomes and controls; they do not require every firm to use identical templates or test scripts. A risk-based system should show why the selected controls are appropriate for the system’s intended use and potential effect on product quality and records. Explore the site’s cGMP guide and 21 CFR overview for related context.
Common CSV inspection findings and compliance gaps
The following themes are useful for internal audits and readiness reviews. A finding’s significance depends on its scope, recurrence, record or process impact, and the firm’s response.
| Finding theme | Typical gap | Why it matters | Practical prevention |
|---|---|---|---|
| System inventory and intended use | GxP applications, spreadsheets, interfaces, or infrastructure are missing from the inventory; system purpose and accountable owner are unclear. | Unidentified systems can escape risk assessment, validation, access control, and periodic review. | Maintain a reconciled inventory with intended use, data/process links, criticality, owners, suppliers, and lifecycle status. |
| Risk assessment and validation scope | Risk decisions are generic, unsupported, or disconnected from requirements and testing. | Testing may miss critical functions or create excessive low-value documentation without addressing actual risk. | Document hazards, GxP impact, controls, rationale, residual risk, and the link to validation evidence. |
| Requirements and traceability | Critical requirements are missing, ambiguous, or not traced to tests and results. | The firm cannot show that intended functions were tested or that changes preserve them. | Maintain approved requirements and traceability from intended use through verification and release. |
| Validation and testing evidence | Protocols lack objective acceptance criteria; testing omits negative cases, interfaces, roles, calculations, or regression impact. | Successful normal-path testing may not demonstrate that failures, boundaries, or unauthorized actions are controlled. | Use risk-based protocols, representative data, expected results, deviations, retests, and independent review as appropriate. |
| Uncontrolled changes | Software, configuration, reports, methods, or infrastructure changes are performed outside change control or without impact assessment. | Production behavior can diverge from the validated baseline and records may be altered without traceable review. | Require approved change records, impact assessment, appropriate testing, version history, and release approval. |
| Access and privileged accounts | Shared accounts, excessive administrator access, inactive users, or undocumented role assignments remain active. | Actions may not be attributable, and unauthorized changes or record manipulation may go undetected. | Use unique identities, least privilege, periodic access reviews, controlled emergency access, and monitored service accounts. |
| Audit trails and record review | Audit trails are disabled, incomplete, not reviewed, or reviewed without a defined risk-based procedure. | Changes, deletions, reprocessing, or unusual activity may not be detected or investigated. | Assess audit-trail applicability, enable relevant functionality, define review triggers and frequency, and document review outcomes. |
| Raw data and metadata | Only printouts or summary reports are retained, while source data, metadata, processing methods, or contextual information are unavailable. | Reviewers may be unable to reconstruct how results were generated or identify altered, repeated, or invalidated data. | Define complete record content and retention; verify retrieval, readability, relationships, audit trail, and metadata. |
| Supplier and service-provider oversight | Vendor qualification relies on a certificate or questionnaire without evaluating relevant controls, change notices, support, or records access. | Supplier activities may affect a GxP system without adequate customer visibility or oversight. | Assess supplier capability, responsibilities, evidence access, change notification, incident handling, and exit/data retrieval arrangements. |
| Backup, recovery and retention | Backup success is assumed to prove recovery; restores are not tested, or backup copies are confused with long-term archives. | Records or systems may be unrecoverable, incomplete, or unreadable during an outage or inspection. | Define scope, schedule, security, recovery objectives, restore tests, and separate archive/retention controls. |
| Periodic evaluation | Reviews are overdue, checklist-only, or fail to consider deviations, incidents, changes, security, access, performance, and validation status. | Drift and unresolved risks can persist after initial qualification. | Set review scope and frequency based on risk; document evidence, issues, owners, due dates, and closure checks. |
| Deviation and CAPA effectiveness | Recurring system issues are closed with training or procedure reminders alone; root cause and effectiveness are not demonstrated. | Underlying technical or governance weaknesses remain and similar failures may recur. | Assess systemic causes, impact, extent, and recurrence; implement measurable actions and verify effectiveness. |
Public FDA warning letters illustrate why these areas deserve attention. For example, an April 2026 letter discussed assessment of computer-system vulnerabilities including configuration, administrative rights, passwords, audit trails, validation status, backup, data completeness, and change management. A March 2026 letter described electronic batch-record software changes that were not captured in audit trails or managed through the quality system. These cases are examples, not a universal inspection checklist.
What evidence may inspectors request?
Be prepared to retrieve clear, current records for selected systems and explain how those records connect. The exact request varies, but common evidence includes:
System lifecycle
Inventory, intended-use statement, URS, risk assessment, validation plan/report, requirements traceability, and current approved baseline.
Operation and security
User access lists, role definitions, privileged-account controls, audit-trail settings and review records, incident logs, and training evidence.
Change and configuration
Change requests, impact assessments, approvals, test protocols/results, vendor release notes, configuration histories, and post-change review.
Records and continuity
Representative raw records and metadata, retention/retrieval evidence, backup logs, restore-test reports, downtime forms, and reconciliation records.
An inspector may select a real transaction, result, or batch record and ask staff to retrieve the original electronic record, related metadata, audit trail, approval details, and applicable procedure. Practice this “record walk-through” across production, laboratory, quality, and infrastructure systems.
Validation and qualification documentation can be linked to system requirements and relevant DQ, IQ, OQ, and PQ evidence where those deliverables apply.
How to prepare for a CSV inspection
- Reconcile the system inventory. Confirm that GxP applications, spreadsheets, interfaces, cloud services, infrastructure, and supporting tools are identified and owned.
- Choose systems by risk. Start with systems that generate or control critical records, testing, manufacturing steps, release decisions, or product-quality data.
- Review the lifecycle file. Check that intended use, requirements, risk assessment, test evidence, deviations, approval, and current production configuration agree.
- Walk through real records. Demonstrate retrieval of source data, metadata, audit trails, signatures, reports, and supporting procedures for representative examples.
- Review user and administrator access. Reconcile active accounts to personnel and roles; confirm privileged access, service accounts, and emergency access are controlled.
- Sample recent changes. Verify that changes were assessed before implementation, tests match the risk, approvals are complete, and the baseline is current.
- Assess audit-trail governance. Confirm which records require audit trails, how reviews are performed, how exceptions are escalated, and how review evidence is retained.
- Check suppliers and cloud services. Confirm responsibilities, evidence access, support, change notices, incident communications, data export, and recovery arrangements.
- Inspect open issues. Review overdue deviations, incidents, CAPAs, periodic-review actions, and recurring technical issues for product and data-integrity impact.
- Prepare staff to explain the process. Train system users and owners to describe their real tasks accurately. Do not coach them to recite scripted answers or conceal problems.
Use controlled SOPs and consistent ALCOA+ data-integrity practices so that inspection answers match actual system behavior and records.
How to respond to an inspection observation
When an inspector identifies a potential gap, establish the facts before deciding the extent of the issue. Keep responses factual, timely, and consistent with the evidence. Do not speculate, modify records retrospectively, or make unsupported assurances.
- Understand the observation. Clarify the system, record, process, time period, and control involved. Preserve relevant data, audit trails, logs, and versions.
- Contain immediate risk. Where justified, restrict access, pause an affected workflow, use an approved alternate process, or increase review while the issue is assessed.
- Assess scope and impact. Determine whether other systems, users, sites, products, batches, records, or time periods may be affected. Evaluate patient, product, data, and compliance consequences.
- Identify root cause. Investigate technical design, configuration, procedures, training, oversight, supplier controls, and management systems rather than stopping at operator error.
- Build a specific action plan. Define corrections, systemic corrective actions, owners, milestones, deliverables, and objective success measures.
- Verify effectiveness. Establish how the firm will confirm that the actions worked and that the underlying weakness has not recurred.
Some observations may require deviation handling, regulatory assessment, or CAPA. A strong response links each proposed action to the actual cause and impact. Generic promises such as “retrain staff” are usually insufficient when system design or governance contributed to the issue.
CSV inspection readiness checklist
- Is every GxP computerized system identified, classified, and assigned an accountable owner?
- Does documented intended use match current production use and configured functions?
- Are risk assessments specific to system functions, data flows, and product-quality decisions?
- Can critical requirements be traced to objective test evidence and approved results?
- Are production versions and configurations consistent with the approved baseline?
- Are changes assessed, approved, tested, and documented through a controlled process?
- Are user, administrator, service, and emergency accounts attributable and appropriately limited?
- Are audit trails enabled where needed and reviewed using a defined procedure?
- Are raw data, metadata, signatures, and related records complete, readable, and retrievable?
- Are backup and restore processes tested and supported by documented evidence?
- Are supplier responsibilities, release information, incidents, and access to evidence controlled?
- Are periodic reviews current and do they assess deviations, changes, security, performance, and validation status?
- Are deviations and CAPAs supported by root-cause analysis, impact assessment, and effectiveness checks?
- Can users and system owners demonstrate routine activities accurately and consistently?
Common mistakes during inspection preparation
| Preparation mistake | Why it can make the situation worse | Better approach |
|---|---|---|
| Creating documents solely for the inspection | New documents may conflict with actual practice or production configuration. | Correct the underlying control and document genuine work through the quality system. |
| Assuming the vendor owns compliance | The regulated company remains accountable for system use, data, and oversight. | Define supplier roles but retain local impact assessment, verification, and approval. |
| Showing only a summary report | It may not reveal original data, metadata, processing, audit trail, or record context. | Demonstrate the complete record lifecycle and retrieval path. |
| Closing findings with training alone | Training does not repair defective access, software, audit-trail, or change controls. | Address root cause and add technical or governance controls as needed. |
| Using a generic risk score without rationale | A number alone does not show what can fail or why the selected validation scope is adequate. | Explain hazards, impacts, safeguards, test decisions, and residual risk. |
| Hiding or minimizing a known issue | Inconsistent explanations and missing records undermine confidence in the quality system. | Escalate promptly, preserve evidence, investigate scope, and communicate factual status. |
Frequently asked questions
1. What are common CSV inspection findings in pharmaceutical companies?
Common themes include incomplete validation evidence, weak risk assessments, uncontrolled changes, excessive user access, inadequate audit-trail review, incomplete electronic records, insufficient supplier oversight, overdue periodic reviews, and ineffective CAPA.
2. Does FDA publish an official ranked list of CSV findings?
No single official ranking covers all computerized-system findings across inspections. Public warning letters and guidance illustrate issues, but their examples should not be treated as a frequency ranking or complete checklist.
3. What CSV records should be ready during an inspection?
Keep the system inventory, intended use, risk assessment, requirements, validation plan and report, traceability, change records, access reviews, audit-trail evidence, incidents, supplier records, periodic reviews, backup tests, and CAPA readily retrievable.
4. What is the most important data-integrity risk in computerized systems?
There is no single risk for every system. Firms should assess whether records can be changed, deleted, obscured, or disconnected from their context without detection, and whether access, audit trails, review, and retention controls address those risks.
5. Are printouts enough to demonstrate control of electronic records?
Not necessarily. If the electronic source record, metadata, processing history, or audit trail is needed to reconstruct or review the activity, the firm should preserve and make those electronic records accessible as required.
6. How should audit trails be reviewed?
Define which records and events are relevant, who reviews them, when reviews occur, what exceptions require investigation, and how the review is documented. The scope should reflect system and process risk.
7. Does a vendor certificate prove that a system is validated?
No. Supplier documentation can support the firm's evidence, but the company must assess the system’s configured use, risks, requirements, and controls and retain enough evidence to support its own quality decisions.
8. What should a firm do after finding a CSV compliance gap?
Contain immediate risk, preserve evidence, assess data and product impact, investigate root cause and scope, define corrective actions, and verify that the actions are effective.
9. How often should computerized systems receive periodic review?
Set the interval and depth through the applicable regulatory framework and a documented risk-based procedure. Consider system criticality, changes, incidents, access, security, supplier status, performance, and validation state.
10. How can a company improve CSV inspection readiness?
Maintain an accurate inventory, keep the validated baseline current, use risk-based lifecycle controls, review data and access, test recovery, oversee suppliers, and close issues with effective CAPA.
Conclusion
CSV inspection readiness depends on whether a pharmaceutical company can show that its computerized systems are controlled in real operation. Strong validation, access, audit-trail, change, supplier, and record-retention controls work together. When gaps are found, a timely impact assessment and effective corrective action are more persuasive than a large set of documents that does not match how the system is actually used.
This article is an educational overview. It does not replace applicable regulations, current agency guidance, approved site procedures, or a system-specific quality risk assessment.
Authoritative references
- European Commission, EudraLex Volume 4 — published EU GMP Annex 11 listing.
- European Commission, EU GMP Annex 11: Computerised Systems.
- FDA, Data Integrity and Compliance With Drug CGMP: Questions and Answers.
- Electronic Code of Federal Regulations, 21 CFR 211.68 — Automatic, mechanical, and electronic equipment.
- FDA, Computerized Systems in Drug Establishments — Inspection Guide. This is investigator reference material and should be read with current regulations and guidance.
- FDA, Ava Inc. Warning Letter, April 14, 2026.
- FDA, Intas Pharmaceuticals Limited Warning Letter, March 30, 2026.
.webp)
