\1**\1**\1.
A validation protocol defines the approved test or activity that will produce specific evidence. They are related, but they are not interchangeable.
What belongs in a validation plan
The plan answers the management question: how will this system be brought into and kept in a controlled state? It should identify the system, intended use, process boundaries, quality risks, responsibilities, deliverables, approvals, deviations, and release decision.
A useful plan also states the governing procedures and the approach to supplier records, configuration, data migration, training, change control, and periodic review. It need not repeat every test step. It should make the programme understandable before execution begins.
What belongs in a validation protocol
A protocol answers the execution question: what will be done, under which conditions, and what result will be accepted? For a test protocol, that normally includes the objective, prerequisites, environment, test data, step sequence, expected results, actual results, evidence references, and deviation handling.
The protocol should be specific enough that an independent reviewer can see why the activity addresses a requirement or risk. A vague instruction such as 'test the workflow' is not a strong acceptance criterion. A better criterion names the input, the expected system behaviour, the record created, and the evidence retained.
How the documents connect
The plan provides the map. The protocol provides one controlled journey on that map. Requirements and risk controls should trace to protocols, and protocol outcomes should feed the validation summary report and release decision.
Keep ownership clear. The plan may be revised when scope or strategy changes. An approved protocol should be version-controlled, reviewed before execution, and protected from silent changes after evidence has been generated.
A practical document set
A small system may need one plan, a risk assessment, a requirements specification, configuration or design records, a traceability matrix, test protocols, a deviation log, training evidence, and a final report. The exact document names can vary. The control objectives cannot be skipped simply because the set is small.
Use the validation traceability matrix guide to connect requirements, risks, tests, and results without making the matrix a decorative spreadsheet.
Common mistakes to avoid
Do not use the plan as a generic template that says little about the actual process. Do not write a protocol before the requirements and risks are stable. Do not approve a protocol after testing has already started. Finally, do not treat a signed document as proof that the underlying activity was performed correctly.
| Document | Primary question | Typical evidence |
|---|---|---|
| Validation plan | How will the lifecycle be controlled? | Scope, roles, strategy, deliverables, approvals |
| Validation protocol | What controlled activity will be executed? | Steps, expected results, actual results, evidence |
| Validation report | What was learned and decided? | Outcome, deviations, residual risk, release decision |
FAQ
Can a validation plan and protocol be one document?
For a very small, low-risk application, one controlled document may cover both functions if it is clear, approved, and complete. The document name matters less than the evidence and decision logic.
Does every software change need a new validation plan?
No. Change control should determine the required assessment and evidence. A major change may require a revised plan; a minor change may need focused testing and an impact record.
Who approves a validation protocol?
The organisation should define approval roles in its quality system. They generally include the process owner and appropriate quality or validation reviewers before execution.
What if a test step fails?
Record the result as a deviation or issue, assess its impact, investigate it, and document the disposition. Do not erase or rewrite the original result.
Decision rule: choose evidence from the consequence of failure, the control being relied on, and the ability to detect a problem. A larger document set is not automatically stronger. Clear scope, reproducible evidence, and an approved conclusion are what make the decision defensible.
Keep the rationale with the controlled record. Future reviewers should be able to see what was considered, what was tested or reviewed, what remains uncertain, and who accepted the residual risk.
For related work, read our validation traceability matrix guide.
Primary sources
Bring validation work under control
VLMS Software helps healthcare teams organise validation, evidence, and audit readiness around the work that matters.
Talk to VLMS Software