Insight Brief · CSV · GAMP 5

Five questions before validation begins.
What vague answers predict.

If these questions are unclear before testing starts, the scope will drift, the documentation will be weak, and the validation will not be defensible under inspection conditions.

Five questions. Clear answers
before a single protocol is drafted.

Vague answers to these questions before validation begins are the most reliable predictor of scope drift, weak documentation, and indefensible evidence packages. The paperwork always follows from the questions. The questions always come first.

01
What is this system actually used for, and is that use GxP-relevant?Not system capability. Actual intended use, in which processes, generating or managing which regulated data. Validation scope follows intended use. A system used beyond its validated scope needs scope reassessment, not assumption.
02
What are the user requirements, and are they written before testing starts?Testing without user requirements is testing without criteria. Requirements must exist before protocols are drafted. Writing them retrospectively produces requirements shaped by what the system does rather than what it needs to do.
03
What is the risk if this system fails or produces incorrect data?The answer determines validation depth: how many test scenarios, what acceptance criteria, whether enhanced controls are warranted. Applying identical depth to every system regardless of risk obscures the systems that genuinely need more attention.

Ownership and what
"validated" means in BAU.

Questions four and five address the governance structure that must be in place before go-live, not designed retrospectively as an afterthought. A validated system without a named owner and a defined ongoing governance model is already drifting from the moment it goes live.

04
Who owns this system, and do they understand their QA responsibilities?System ownership is one of the most consistently unresolved questions in CSV programmes. Without a named, accountable owner, change control is inconsistent, periodic review is deferred, and user access accumulates without review. The validation evidence disconnects from the live system.
05
What does "validated" look like when we're done, and how will we know if it stops being true?The validation summary report marks the end of the initial lifecycle phase. The question of what governance is needed to maintain the validated state (change control, periodic review, access management) must be answered before go-live, not after the first audit query.

Frequently asked.

Who should answer these questions before validation starts?
System owner, QA and the validation lead, together
These questions require input from the people who will use the system (intended use), the people responsible for compliance (QA), and the person leading the validation (testing rationale). A validation plan written by one person without this input is a plan written around assumptions.
What if the answers change during the project?
Document the change and rebaseline
Scope changes happen. What matters is that changes to intended use, risk profile or system boundaries are formally documented and that the validation approach is adjusted accordingly, not quietly accommodated in the background while the original plan remains unchanged.
Is this applicable to SaaS and cloud-hosted systems?
More so, not less
For SaaS systems, intended use is often less clearly defined upfront, ownership is contested between IT and business, and the boundary of "validated" is complicated by supplier-managed changes. The five questions are more critical for SaaS deployments, not less, and the shared responsibility dimension adds a sixth: what does the supplier control, and what do we control?

Facing a similar challenge?
Let's talk directly.

A focused 30-minute call, no sales process, no commitment. A direct conversation about your environment and where the risk actually sits.

Book a Call Now Prefer to write first? Send a question →