\1**\1**.
The release note alone is not a validation assessment.
Describe the release
Record the version, date, supplier or developer, changed components, configuration, dependencies, and reason for release. Distinguish code, configuration, infrastructure, data, and documentation changes.
A release that appears small can alter an interface, calculation, permission, or audit trail. Review the actual impact rather than judging by the number of changed files.
Assess impact before testing
Identify affected processes, records, controls, integrations, reports, roles, and procedures. Link the assessment to the system risk and requirements. Define what is unchanged and why it does not need retesting.
Use the change-control and revalidation guide when deciding how much evidence the release needs.
Choose focused regression
Regression testing should cover changed behaviour and connected controls that could be affected. Include positive, negative, boundary, access, interface, and data checks where relevant.
Do not rerun every test by reflex when a focused, justified set answers the risk. Do not shrink the set merely because the release deadline is uncomfortable.
Control deployment
Use approved packages, environments, access, backup or rollback, and release instructions. Record who deployed, what was deployed, and how the production version was confirmed. Separate development and approval responsibilities according to procedure.
Review after release
Confirm the system is operating as intended, monitor incidents and key controls, and close any deviations. Update configuration, validation status, training, and support records as required.
| Release step | Evidence |
|---|---|
| Description | Version and change scope |
| Impact | Affected process, risk, and requirements |
| Testing | Approved regression protocol and results |
| Deployment | Package, approver, executor, and environment |
| Post-release | Smoke check, monitoring, deviations, and closure |
FAQ
Does every vendor update require testing?
Every update needs a documented impact assessment. The result may be review, focused testing, or broader evidence depending on risk.
Can release notes be the impact assessment?
They are input. They rarely describe your configuration, intended use, and process controls well enough on their own.
Should a rollback be tested?
If rollback is part of the recovery strategy and the risk justifies it, test or otherwise verify the procedure and dependencies.
When is a release validated?
When the approved evidence supports the intended use and authorised quality decision, not merely when installation completes.
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.
During review, compare the approved requirement with observed use, current configuration, and retained evidence. That simple comparison often finds drift before an auditor does.
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