Computer system validation and 21 CFR Part 11 for new software

The situation

Your quality team wants to replace paper logbooks with an electronic system, or your plant needs a new LIMS, QMS or batch record tool. The first question from QA is always the same: how will we validate it? If the answer is vague, the project stalls for months.

Computer system validation, or CSV, is how you show that a system used in regulated work does what it is meant to do, every time, and that the records it holds can be trusted. If you export to the US, 21 CFR Part 11 sets the FDA's rules for electronic records and electronic signatures. For Europe, EU GMP Annex 11 covers computerised systems. In India, the revised Schedule M under the Drugs and Cosmetics Rules also expects computerised systems to be validated and controlled.

Quick answer

• Decide early whether the system is GxP relevant. If it creates, changes or stores records used for GMP, GLP or GCP decisions, it is.
• Use a risk based approach, such as GAMP 5, so testing effort goes where the risk is.
• Build Part 11 controls into the design: unique user accounts, role based access, secure audit trails, and electronic signatures that record who signed, when and what the signature meant.
• Produce the core documents: user requirements, risk assessment, specifications, test evidence, a traceability matrix and a validation summary report.
• Keep the system in a validated state through change control after go live.

What Part 11 actually asks for

People treat Part 11 as a long list. In practice, most of it comes down to a few controls.

1. Validation. Show the system is accurate, reliable and performs as intended.
2. Audit trails. Secure, computer generated, time stamped records of who created, changed or deleted a record, with the old and new values. Users must not be able to switch them off or edit them.
3. Access control. Only authorised people can use the system, and what they can do depends on their role.
4. Electronic signatures. Each signature is unique to one person, linked to its record, and shows the name, date and time and meaning, such as "reviewed" or "approved". Non biometric signatures use at least two components, typically a user ID and password.
5. Record retention and retrieval. Records can be read and copied accurately for inspection for their full retention period.

Data integrity principles, often summarised as ALCOA+ (attributable, legible, contemporaneous, original, accurate, plus complete, consistent, enduring and available), sit behind all of this.

Design it in, do not test it in

The expensive mistakes happen when a team builds or configures a system and then asks QA to validate it. By then, the audit trail stores only the latest value, shared logins are baked into the shop floor process, and signatures are a checkbox.

If you are building software, agree these points before development starts:

• Which records are GxP records, and which fields within them need an audit trail.
• How time is set and synchronised across servers, since timestamps must be trustworthy.
• Which actions need a signature, and what meaning each signature carries.
• How users are created, changed and removed, and who reviews access periodically.
• How backups, restores and archives are done and tested.
• Where the data is hosted and how your cloud provider's responsibilities are documented.

The validation documents, in order

A proportionate package for a mid sized system usually looks like this:

1. Validation plan. Scope, approach, roles and acceptance criteria.
2. User requirements specification (URS). What the business needs, written so each item can be tested.
3. Risk assessment. Which functions affect patient safety, product quality or data integrity, and how much testing each needs.
4. Functional and design specifications. How the system meets the URS. For a configured product, a configuration specification.
5. Testing. Installation qualification (IQ), operational qualification (OQ) and performance qualification (PQ), or the equivalent in your procedures. Test high risk functions with scripted tests and lower risk ones with lighter, unscripted testing.
6. Traceability matrix. Each requirement linked to its risk, design and test.
7. Validation summary report. What was done, deviations and their resolution, and the decision to release.

The FDA's Computer Software Assurance guidance encourages this kind of risk based, less paper heavy approach. It does not remove the need for evidence. It asks you to spend effort on critical thinking and the testing that matters.

Working with suppliers

If you buy a product or hire a developer, their quality system matters.

• Audit or assess the supplier, proportionate to risk.
• Ask for their development and testing records and use them where they are good enough. GAMP 5 supports this.
• For cloud and SaaS products, get a clear quality agreement covering changes, upgrades, backups, incidents and access to data at contract end.
• Remember that you, as the regulated company, still own the validated state of the system in your process.

Timelines and what slows them down

For a focused system such as an electronic logbook or a deviation and CAPA tool, validation alongside development often adds three to five weeks. A LIMS or MES with many interfaces can take several months.

The usual delays are requirements that change during testing, QA reviewers who join late, and test scripts written before the system is stable. Bring QA into the requirement workshops, freeze scope for each release, and plan validation as part of the project from day one.