What a CSV lifecycle looks like, start to finish

Every computerised system that supports a regulated process has a lifecycle, whether anyone planned one or not. This article follows that lifecycle from the first idea to the day the system is switched off, using one example system, so that system owners and people new to computer system validation (CSV) can see the whole picture. We teach it in our CSV 101 course as four phases, Concept, Project, Operation and Retirement, and everything else in CSV hangs on them.

Why the lifecycle comes first

Regulators describe validation as covering the whole life of a system, not a test just before go-live. Annex 11 of the EU GMP Guide defines the life cycle as all phases in the life of the system from initial requirements until retirement, and says risk management should be applied throughout it. The Pharmaceutical Inspection Co-operation Scheme (PIC/S) guidance PI 011-3 lists the stages: development, implementation, qualification and acceptance, operation, modification, re-qualification, maintenance and retirement. It says the regulated user, meaning the company using the system, carries the ultimate responsibility for having validation evidence available for inspectors.

21 CFR 11.10(a) (Code of Federal Regulations) requires validation of systems to ensure accuracy, reliability, consistent intended performance and the ability to discern invalid or altered records. The draft revised Annex 11 says computerised systems should be validated before use and maintained in a validated state throughout their lifecycle. It is still a draft.

For a system owner, validation is therefore not something you buy once: you are responsible for the validated state for as long as the system runs. Our four phases align with the ISPE GAMP 5 Guide, Second Edition (2022), and PI 011-3 also points readers to the GAMP Guide. The regulatory points below come from the regulators' own documents.

The example system we will follow

We follow one illustrative system through every phase. It is not a real installation. Imagine an automation system for a manufacturing process with these parts:

A PLC (programmable logic controller), the industrial computer that runs the control logic.
SCADA (supervisory control and data acquisition) software, which gives operators their screens to view and control the process.
A site-wide historian, a database that records time-stamped process data over long periods.
Login through LDAP (lightweight directory access protocol), so users are checked against a central directory.
Backup to a central server.

Our course distinguishes the computer system (hardware and software) from the controlled function (the process it controls). Together they form the computerized system, which is the scope of validation. Here the five parts are the computer system and the manufacturing step is the controlled function. Assume that step affects product quality, which makes it relevant to good manufacturing practice (GMP) and means it needs validating.

Phase 1: Concept

The concept phase starts before any contract is signed: a need is identified, a first investigation checks the idea is viable, and the project is authorised to proceed. Our course lists the key activities as setting high-level requirements, deciding whether the system has a GxP (good practice) impact, identifying the regulations that apply, choosing how to procure it and forming the team.

The European Medicines Agency (EMA) questions and answers on Annex 11 say a first risk assessment should determine the GMP criticality of the system: does it affect patient safety, product quality or data integrity? PI 011-3 says regulated users should keep an inventory recording each system's ownership, supplier, functionality, links and validation status, and Annex 11 adds that critical systems need a description of their physical and logical arrangements, data flows and interfaces. PI 011-3 also notes that firmware (software embedded in a device) is usually qualified as part of performance qualification or process validation, which applies to our PLC.

Annex 11 names two roles to know: the process owner (the business process) and the system owner (the system's availability, maintenance and data security).

Phase 2: Project

Annex 11 gives this phase its own section, and our course breaks it into five steps.

Planning

A validation plan sets the scope, approach, documents and who does what; PI 011-3 expects the company's validation master plan to identify which systems are subject to validation. Our course adds three assessments: system impact, electronic records and signatures (21 CFR Part 11 and Annex 11), and vendor. Annex 11 says suppliers need formal agreements and that the need for an audit should be based on risk. Compliance responsibility stays with you, whoever the supplier.

Specification

The user requirements specification (URS) says what the system must do. Annex 11 says it should rest on a documented risk assessment and GMP impact and be traceable throughout the life cycle, and the EMA notes it forms the basis of the first formal risk assessment. In our course every requirement is numbered and mapped to its tests in a traceability matrix, so a gap in the matrix is a gap in the validation. Ours might say that the PLC keeps the process within defined limits, that only authorised, named users can log in and make changes, and that data can be recovered after a failure.

Configuration and coding

Here the PLC program is loaded, the SCADA screens built, the historian connected, the central login linked and the backup configured. Our course stresses that configuration is controlled from the moment it starts, and that audit trails and role-based access are built in now, because adding them later is harder and less reliable. Annex 11 says the application should be validated and the IT infrastructure qualified; in our example the directory service and backup server are infrastructure.

Verification and testing

Verification gathers objective evidence that the system meets its specifications. Our course uses installation qualification (correctly installed), operational qualification (works across its functional range) and performance qualification (performs reliably in real operation against the URS), with depth set by risk. Annex 11 says test scenarios should consider process parameter limits, data limits and error handling. The Medicines and Healthcare products Regulatory Agency (MHRA) says systems must be validated for their intended purpose, and that vendor validation data accepted in isolation from your configuration and intended use is not acceptable.

The MHRA also expects data transfer between computerised systems to be validated, and Annex 11 asks for checks that data keeps its value and meaning when it moves to another format or system. In our example the path from PLC to SCADA to historian is exactly that. You might test the control logic against its limits, the alarms, whether values reach the historian complete and time-stamped, whether view-only and change-settings users get different access, and whether data can be restored. In our course a system cannot be released while a critical or major deviation is open.

Reporting and release

A validation summary report pulls it together: what was tested, the outcomes, the traceability matrix, how deviations were resolved and a statement that the system is fit for its intended use. A release memo then authorises GxP use, signed by the process owner, the system owner and quality assurance, once procedures are approved, users trained and the inventory updated.

Phase 3: Operation

After go-live the aim shifts from achieving compliance to maintaining it. This is usually the longest phase, and the validated state is most at risk of eroding here.

Access comes first. The MHRA's GxP data integrity guidance says shared or generic logins should not be used for systems that generate, amend or store GxP data where individual access is possible. Controls apply at operating system and application level, and administrator access should be minimal. It also expects GMP facilities with industrial automation, such as programmable logic controllers, to be able to demonstrate working towards system upgrades with individual login and audit trails. Central login through LDAP helps with named accounts, but it moves part of the control outside the system: how accounts and groups are created, changed and removed becomes part of the validated state. Annex 11 says the creation, change and cancellation of access authorisations should be recorded, and the draft revised Annex 11 says accesses should be granted, modified and revoked in a timely way as people join, change and leave. On records, 21 CFR 11.10(e) calls for secure, time-stamped audit trails of actions that create, modify or delete electronic records, and 21 CFR 11.10(c) for protection of records so they can be retrieved throughout the retention period.

Backup must be proved, not just scheduled. The MHRA says backup and recovery processes should be validated and periodically tested, each backup verified, and that backups do not replace long-term retention. Annex 11 says the ability to restore should be checked during validation and monitored periodically, and the draft revised Annex 11 says restores should be tested and documented. A central backup server is only worth having if a restore has been shown to work.

Change control and review keep the validated state intact. PI 011-3 says change control should be in place during all life-cycle phases, and Annex 11 says any change, including configuration, should follow a defined procedure. In our example a PLC program update, a SCADA patch or a change to directory groups is each a change to assess. The EMA says systems should be reviewed periodically to confirm they remain validated, covering functionality, deviations, changes, upgrade history, performance, reliability and security, at an interval that reflects criticality. Our course says typically annual.

Phase 4: Retirement

Systems end, and a GxP system cannot simply be switched off. In our course a retirement plan approved by quality assurance defines what is being retired, how the data will be kept for its retention period and the timeline. The data is archived in a controlled, read-only repository or migrated to a successor system with the migration verified, and only then is the system decommissioned and a final report written.

The EMA points to precautions for migrating data at the end of a system's life cycle, and the MHRA says records should be archived under a documented strategy before a system that can no longer be maintained is decommissioned. Annex 11 says archived data should be checked for accessibility, readability and integrity, and that the ability to retrieve it should be tested if the system changes. Our course adds two risks: proprietary formats that outlive their vendor, and archive-reading tools that may themselves need validating. In our example, years of process data in the historian must stay retrievable long after the PLC and SCADA are gone.

Key takeaways

Validation covers the whole life of a system in four phases, Concept, Project, Operation and Retirement, not just the testing before go-live.
Decide early whether the system has a GxP impact: it sets how much validation everything else needs.
The user requirements specification is the yardstick: tests prove it, change control protects it and review checks it still holds.
Access, audit trails and backup must be shown to work, and the end of the system planned at the start so its data stays retrievable.