Validation Report — QMS Nordic

Template — QMS Nordic T5. The document that releases the software for use in your quality system, and the one an auditor asks for by name.

It has to be signed. An unsigned validation report is not a validation record. It is also the document that makes the other four count — they are evidence; this is the decision.

Name the version. Your auditor's next question after "did you validate it?" is "is that what you are running now?" A report that names v1.0.0 while you run something later has a visible gap.

Effort: half a day, mostly assembling what you already produced.

---

1. Conclusion

Write this first. If you cannot state it plainly, the validation is not finished.

QMS Nordic v1.0.0 [is / is not] fit for its intended use in [COMPANY]'s quality management system as described in [DOC-XXX, intended use and user requirements], and [is / is not] released for use with live quality records from [date].

Conditions or restrictions on use: [none / as listed in §6]

2. Scope

3. Method

Validation followed [SOP-XXX], applying ISO/TR 80002-2:2017 with depth proportionate to risk as required by [EN ISO 13485:2016+A11:2021 / ISO 13485:2016] §4.1.6.

Use the designation your auditor uses: EN ISO 13485:2016+A11:2021 in the EU, plain ISO 13485:2016 elsewhere. Same clause; the harmonised version is what carries presumption of conformity with MDR.

4. Supplier evidence relied upon

Only sign for what you were given. These four are the whole of the supplier evidence at v1.0.0. If you are working from a later pack, check its Master Plan §6 — do not carry this list forward unchecked.

Supplier evidence not available, and how we covered it. The supplier's Master Plan §6 states what it does not provide: a supplier risk assessment, a per-release test evidence report, an installation qualification protocol, and a clause-by-clause regulatory mapping. Record here how your own work covers each gap — this is the paragraph an auditor reads first.

Basis for relying on it: the supplier operates a controlled development process — automated testing blocking on every change, reviewed and versioned database migrations, code-owner review over the record-integrity surface, and an automated check that the recorded change history rebuilds the system.

State the limits too. Supplier evidence reduced our testing; it did not replace our validation. It cannot demonstrate that the software as we have configured and use it meets our intended use — that is what §5 covers.

Known supplier limitations at v1.0.0, as disclosed: branch protection not yet enforced (change-control rules are procedural); documents beyond ~32,000 tokens cannot be generated in one request; type-checking and linting run without blocking. We assessed these as [acceptable / …] because [—].

5. Our own testing

Deviations

If there were no deviations, say so explicitly — "no deviations were raised" reads better than an empty table, which looks like an unfinished document.

6. Residual risk

Residual risk following validation is [acceptable / acceptable with conditions].

7. Revalidation

Record the assessment even when the answer is "no action". A file showing that each release was assessed and most needed nothing is evidence of a working process. A file with nothing in it since initial validation reads as a process that stopped.

8. Approval

By signing, the approver states that the validation described above was carried out, the evidence supports the conclusion in §1, and the software is released for the stated intended use.

---

Appendix — records