Getting FDA compliance wrong is expensive. A single audit observation can delay product releases, trigger warning letters, or shut down operations entirely.
A computer system validation flow chart removes that uncertainty. It gives your quality, IT, and regulatory teams a shared, documented roadmap — from system planning all the way through retirement.
This guide covers every stage of the CSV process. You will find step-by-step explanations, key documents, qualification checklists, and regulatory requirements — all in one place.
What Is Computer System Validation?
Computer System Validation (CSV) is the process of providing documented evidence that a computer-based system consistently does what it is designed to do.
CSV is a process for ensuring that computer-based systems produce data and information that meets a set of pre-defined requirements. The pharmaceutical industry relies on data integrity to ensure reliable, accurate, and consistent information throughout the product lifecycle. — PMC, National Institutes of Health
In short — it is your proof. Proof that your system works. Proof that it works correctly every single time.
CSV Is Not Optional
CSV is not merely an industry recommendation — it is a regulatory necessity that bridges the gap between technology and regulatory compliance.
At RxCloud, our expert Computer System Validation (CSV) services cover the complete lifecycle — from planning and URS through IQ, OQ, PQ, and periodic reviews — fully aligned with FDA 21 CFR Part 11, EU Annex 11, and GAMP 5.
Who Needs Computer System Validation?
CSV applies across all GxP-regulated industries. Here is a quick overview:
Our Quality Engineering Services support all of these industries — from pharma and biotech to medical devices and clinical research.
| Industry | Applicable Regulation | Systems That Need Validation |
| Pharmaceuticals | FDA 21 CFR Part 11 / EU Annex 11 | LIMS, ERP, MES, DMS |
| Medical Devices | FDA 21 CFR Part 820 / ISO 13485 | Design control, QMS software |
| Biologics / Biotech | FDA cGMP / ICH Q10 | Batch record, lab systems |
| Clinical Research | FDA 21 CFR Part 11 / GCP | EDC, CTMS, randomization systems |
| API Manufacturing | ICH Q7 / GMP | Process control, data logging |
Computerized systems that have an impact on product quality, patient health, and good practices (GxP) must be validated, in order to meet regulatory requirements, ensure the integrity and traceability of information and product quality.
What Systems Need to Be Validated?
Not every system requires full validation. The scope depends on GxP impact. A system needs validation if it:
- Creates, modifies, or stores GxP records
- Controls critical manufacturing processes
- Generates electronic signatures or audit trails
- Manages quality or safety-related data
- Interfaces with equipment that affects product quality
A system may not need full CSV if it:
- Has no GxP data impact
- Is infrastructure-level (OS, network) and low risk
- Is used purely for administrative tasks with no quality impact
GAMP 5 Software Categories — Know Your System First
Before you build a validation flow chart, you must classify your system using GAMP 5 categories. GAMP’s objective is to offer an affordable structure of standards to guarantee that computerized systems are efficient, suitable for their intended purpose, high-quality, and comply with relevant laws.
| GAMP Category | System Type | Validation Effort | Example Systems |
| Cat. 1 | Infrastructure Software | Low | OS, databases, middleware |
| Cat. 3 | Non-configured COTS | Low–Medium | Standard office tools |
| Cat. 4 | Configured COTS | Medium–High | ERP, LIMS, MES |
| Cat. 5 | Custom / Bespoke Software | High | Proprietary pharma apps |
💡 Pro Tip: Higher the GAMP category → more validation documentation required.
The Computer System Validation Flow Chart: All 10 Steps
The validation process involves several steps: planning, defining requirements, coding, testing, installation, documenting everything, running the system, keeping an eye on its performance, and making adjustments as needed. (Source: PMC, National Institutes of Health)
▶ Step 1 — Project Initiation and Validation Planning
Everything starts here. This step sets the foundation for the entire CSV project. Key deliverables include:
- Validation Plan (VP) — outlines overall strategy, scope, and responsibilities
- Project Charter — defines goals, timeline, and team structure
- GxP Impact Assessment — determines if full CSV is required
- GAMP 5 Category Assignment — classifies the software
💡 Pro Tip: Without an approved Validation Plan, no other validation activity should begin. This is a hard rule in FDA inspections.
▶ Step 2 — User Requirements Specification (URS)
The URS captures what the system must do — from the user’s perspective. It must cover:
- Business requirements — why the system is needed
- Functional requirements — what the system must do
- Data integrity requirements — ALCOA+ principles
- Security and access control requirements
- Performance, availability, and scalability needs
- Regulatory compliance requirements (21 CFR Part 11, Annex 11)
ALCOA+ Data Integrity Principles
| Letter | Principle | Meaning |
| A | Attributable | Data is linked to the person who created it |
| L | Legible | Data is readable and permanently recorded |
| C | Contemporaneous | Recorded at the time of the activity |
| O | Original | First capture — not a copy |
| A | Accurate | Free from errors and reflects what happened |
| + | Complete, Consistent, Enduring, Available | Extended ALCOA principles for full data integrity |
Every URS requirement must be traceable to a test. If it cannot be tested, it does not belong in the URS.
▶ Step 3 — Functional and Design Specification (FS / DS)
Once the URS is approved, the technical team defines how the system will meet those requirements. Two key documents are produced:
- Functional Specification (FS) — describes what the system does from a user perspective
- Design Specification (DS) — describes how the system technically achieves it
These documents must include:
- System architecture and components
- Data flow diagrams
- Interface specifications with other systems
- Error handling and alarm definitions
- Backup and recovery procedures
- Security and access control design
▶ Step 4 — Risk Assessment and Traceability Matrix
Risk assessment determines where to focus your testing effort — saving time and resources. A traceability matrix connects the requirements in the URS to the tests conducted during qualification, ensuring all operational parameters have been tested and validated.
Risk Rating Table
| Risk Level | Description | Validation Required |
| HIGH | Direct patient safety or product quality impact | Full DQ + IQ + OQ + PQ |
| MEDIUM | Indirect quality impact | IQ + OQ at minimum |
| LOW | Administrative / non-GxP | Documented risk assessment only |
Requirements Traceability Matrix (RTM) — Sample
| URS Ref | FS Ref | Test Script ID | Tested By | Result |
| URS-001 | FS-010 | IQ-001 | Validation Team | ✅ Pass |
| URS-002 | FS-011 | OQ-003 | Validation Team | ✅ Pass |
| URS-003 | DS-005 | PQ-002 | End Users | ✅ Pass |
▶ Step 5 — Design Qualification (DQ)
DQ verifies that the design of the system meets the requirements in the URS, FS, and DS — before any physical installation begins. The Design Qualification is completed with the system/equipment order. The Factory Acceptance Test (FAT) is performed at the manufacturer’s site.
DQ confirms:
- Design documentation is complete and approved
- System design meets all applicable regulatory requirements
- Vendor qualification and audit has been completed
- Technical specifications align with URS
- Factory Acceptance Testing (FAT) is planned
▶ Step 6 — Installation Qualification (IQ)
IQ is the first hands-on qualification phase. It confirms the system was installed correctly. IQ does NOT test functionality — it only verifies correct installation.
IQ asks: Was the software installed according to vendor specifications, and are all necessary components and documentation in place?
| IQ Check | What Is Confirmed |
| Hardware components | Installed per approved specifications |
| Software version | Correct version and build number confirmed |
| Operating environment | OS, database, network match requirements |
| Security configuration | Access controls are in place |
| Documentation | All installation documents approved and on file |
| Calibration records | Instruments calibrated before testing |
IQ Execution Checklist
- Hardware inventory documented
- Software version confirmed
- Network configuration verified
- User access levels set
- System clocks synchronized and accurate
- IQ Protocol approved BEFORE execution began
- IQ Report written and signed
▶ Step 7 — Operational Qualification (OQ)
OQ verifies that the system operates as designed — under normal and boundary conditions. OQ asks: Does the software operate as it is supposed to according to the specified functional requirements?
OQ tests typically cover:
- All functions defined in the Functional Specification
- Boundary testing — minimum/maximum input values, edge cases
- Error handling and alarm responses
- User access control — correct permissions per role
- Audit trail generation and completeness
- Data backup and restore functionality
- System performance under load
OQ Test Script Structure
| Field | What to Include |
| Test ID | Unique reference number (e.g. OQ-001) |
| Test Objective | What is being tested and why |
| Pre-conditions | System state before the test begins |
| Test Steps | Step-by-step instructions for the tester |
| Expected Result | What correct behaviour looks like |
| Actual Result | What was observed during execution |
| Pass / Fail | Clear, unambiguous determination |
| Tester Signature | Name, date, role |
| Reviewer Signature | QA name, date, approval |
⚠ Protocol must be approved BEFORE testing begins. Retroactive approval is a data integrity violation and will trigger FDA observations.
▶ Step 8 — Performance Qualification (PQ)
PQ confirms the system performs as intended in real-world operational conditions — with real users and real workflows. PQ asks: Does the whole process perform as it should from start to finish, at the required performance level?
PQ validates:
- End-to-end business workflows under normal operating conditions
- Concurrent user performance — does it fail under load?
- Integration with connected systems (ERP, LIMS, MES)
- Report generation accuracy
- Data integrity throughout the full process cycle
Key Difference: OQ vs PQ
| Comparison | OQ | PQ |
| Tests | Individual system functions | End-to-end business workflows |
| Users | Validation team | Actual end users |
| Conditions | Controlled test environment | Real operational environment |
| Focus | Does each function work? | Does the whole process work? |
▶ Step 9 — Validation Summary Report (VSR)
After all qualifications pass, the Validation Summary Report is prepared and approved. The Test Summary Report is a comprehensive analysis of all testing activities with conclusions about system readiness for operational use.
The VSR must contain:
- Summary of all qualification activities and outcomes
- List of all deviations — and documented resolutions
- Completed Traceability Matrix (URS → Test → Result)
- Risk assessment conclusion
- Outstanding issues and action plans
- Formal approval signatures: QA, IT, Business Owner
The VSR is your primary evidence document during an FDA inspection. It must be complete, accurate, and signed before system go-live.
▶ Step 10 — Go-Live, Change Control, and Periodic Review
The life cycle of CSV starts from the planning stage to the modification stage. Validation does not end at go-live — this is where ongoing compliance begins.
At go-live, you must have:
- Approved SOPs for system use, administration, and backup
- User training records — signed and dated
- Formal change control procedures in place
- Audit trail monitoring process established
- Periodic review schedule set — typically annual
Any change to a validated system — no matter how minor — must go through formal Change Control before implementation. This includes patches, config changes, new user roles, and hardware upgrades.
Complete CSV Flow Chart — At a Glance
| # | Phase | Key Document | Output |
| 1 | Planning | Validation Plan | Approved VP + GxP Assessment |
| 2 | User Requirements | URS | Approved URS |
| 3 | Functional / Design Spec | FS + DS | Approved FS / DS |
| 4 | Risk Assessment | RTM + Risk Register | Risk rating + Traceability Matrix |
| 5 | Design Qualification | DQ Protocol | DQ Report |
| 6 | Installation Qualification | IQ Protocol | IQ Report |
| 7 | Operational Qualification | OQ Protocol + Test Scripts | OQ Report |
| 8 | Performance Qualification | PQ Protocol | PQ Report |
| 9 | Validation Summary | VSR | Final Approved VSR |
| 10 | Go-Live + Maintenance | Change Control + Periodic Review | Ongoing compliance records |
The V-Model in Computer System Validation
The V-Model is the standard development and testing framework used in CSV. It facilitates structured testing, which is crucial for successful validation. Validation relies on a series of documented checks and tests — DQ, IQ, OQ, and PQ — to confirm that the computer system works exactly as designed.
V-Model Structure:
URS ──────────────────────────────────► PQ
FS ────────────────────────────► OQ
DS ────────────────────► IQ
Build / Configure (Base of V)
Every left-side specification document has a matching qualification test on the right side. This ensures complete test coverage and traceable compliance evidence.
Key Regulatory Guidelines for CSV in Pharma
Validating computer systems offers numerous benefits, including improved quality, reduced validation costs and time, and improved GMP compliance with 21 CFR Part 11 regulations.
Staying audit-ready across all these regulations is where RxCloud’s GMP Audit services become critical — ensuring your systems and manufacturing processes are always inspection-ready.
| Regulation / Guideline | Scope | Key Requirement |
| FDA 21 CFR Part 11 | USA | Electronic records and e-signatures must be validated |
| FDA 21 CFR Part 211 | USA | cGMP requirement for validated computer systems |
| EU GMP Annex 11 | Europe | Full lifecycle validation for computerised systems |
| GAMP 5 (2nd Ed. 2022) | Global | Risk-based approach to GxP computerised systems |
| ICH Q9 | Global | Quality risk management framework |
| ICH Q10 | Global | Pharmaceutical Quality System requirements |
| WHO TRS 937 | Global | GMP for pharmaceutical products |
Common CSV Mistakes That Trigger FDA Observations
Avoid these validation errors — each one is a known source of Form 483 observations and Warning Letters:
| Mistake | Risk Level | Impact |
| No approved Validation Plan before testing | 🔴 Critical | All test results are invalid |
| Test scripts written after testing is complete | 🔴 Critical | Data integrity violation |
| Unresolved deviations in test reports | 🔴 Critical | System cannot be released |
| No Traceability Matrix | 🔴 Critical | Cannot demonstrate requirement coverage |
| Change control bypassed post go-live | 🔴 Critical | Validated state is broken |
| Audit trail disabled or not reviewed | 🟠 High | 21 CFR Part 11 violation |
| Periodic reviews overdue | 🟠 High | Validated state becomes questionable |
| Training records missing or unsigned | 🟡 Medium | Compliance gap on inspection |
CSV Documentation Package — Complete Checklist
Use this checklist to confirm your validation package is inspection-ready:
Planning Phase
- Validation Plan (VP) — approved
- GxP Impact Assessment — signed
- GAMP Category Assignment — documented
Specification Phase
- User Requirements Specification (URS) — approved
- Functional Specification (FS) — approved
- Design Specification (DS) — approved
Risk & Traceability
- Risk Assessment — completed and reviewed
- Requirements Traceability Matrix (RTM) — complete
Qualification Phase
- DQ Protocol + Report — approved
- IQ Protocol + Report — approved
- OQ Protocol + Report — approved
- PQ Protocol + Report — approved
Summary & Closure
- Validation Summary Report (VSR) — approved
- All deviations closed — documented
- User training records — signed and dated
- SOPs in place — approved
Post Go-Live
- Change control SOP — in place
- Periodic review schedule — set
- Audit trail monitoring — active
FAQ: Computer System Validation Flow Chart
Q1. What is the purpose of a computer system validation flow chart?
It maps the entire CSV lifecycle — from planning through retirement. It keeps teams aligned, ensures no step is missed, and provides a clear audit trail for regulators.
Q2. Is IQ, OQ, PQ mandatory for all pharma systems?
Only for GxP-impacting systems. The required depth depends on risk level and GAMP category. Low-risk systems may need only IQ and OQ.
Q3. What happens if I skip the Validation Plan?
Any test results produced without an approved Validation Plan are potentially invalid. FDA inspectors check document approval dates against execution dates.
Q4. How often must a validated system be reviewed?
Typically every 12 months, or whenever a significant change, incident, or regulatory update occurs — whichever comes first.
Q5. Does a software update require re-validation?
Yes — any change to a validated system must go through formal change control and impact assessment. Depending on scope, partial or full re-qualification may be needed.
Start Your CSV Journey the Right Way
A well-built computer system validation flow chart does more than satisfy regulators. It protects patients, preserves data integrity, and gives your organisation the confidence to operate at scale.
Whether you are validating a new LIMS, ERP, MES, or custom pharma application — following a structured, risk-based CSV lifecycle is the only approach that works.
At RxCloud, our team of GxP compliance experts handles the full CSV lifecycle for you — documentation, testing, IQ/OQ/PQ execution, and regulatory reporting.
👉 Explore our CSV Validation Services | Get in Touch with Our Team