Software validation pack

Everything you need to validate QMS Nordic inside your own quality system under EN ISO 13485:2016+A11:2021 §4.1.6. The same evidence maps to FDA QMSR, MDSAP and UKCA.

v1.5.0 · pack rev. J (2026-09-07)

You have to validate this software — we cannot do it for you. §4.1.6 places the obligation on the organisation using the software. It does not transfer by contract, certificate or documentation, and notified bodies check this clause in every audit.

What this pack removes is the work that is genuinely ours. Start with the Validation Master Plan: it states the method, what we evidence, and what remains yours.

Your deliverables

An auditor assesses these five, not ours. Work through them in order — the risk assessment in step 3 decides how much of step 4 you need to execute, and step 5 concludes on both.

• 1. Template — Validation SOP — Once, then reused
  Your documented procedure for validating QMS software. Covers your whole toolset, not just this platform. Adopt once, reuse.
• 2. Template — Intended use and user requirements — Half a day
  Pre-written requirements to confirm, amend or mark unused. Anything you rely on that is not covered becomes your own deliverable.
• 3. Template — Risk assessment — Half a day
  ISO/TR 80002-2 method. We state what can fail and what controls exist; you supply the impact in your context.
• 4. Template — Test protocol and results — 1–2 days, scaled to risk
  Pre-written scripts for you to execute, directed by your risk assessment rather than testing everything.
• 5. Template — Validation report — Half a day
  The signed conclusion releasing the software for use. The document an auditor asks for by name.

What we provide as evidence

• Validation Master Plan
  Start here. Scope, method, the market mapping, and exactly which parts of validation are ours and which are yours.
• User Requirements Specification
  The platform behaviours we specify, using the same identifiers as template T2 so your confirmations map straight onto our evidence.
• Traceability Matrix
  Requirement to evidence to clause — generated from the code, and explicit about the requirements we have no evidence for.
• Regulatory Mapping Annex
  The traceability matrix inverted: what we claim against each clause, for the auditor who arrives holding one rather than a requirement id.
• Test Evidence Report
  What the automated suite actually establishes, suite by suite — and, at more length, what it does not.
• Module Evidence Annex
  For each process module — CAPA, complaints, training, suppliers and the rest — the tests we run, what they prove, and what is left to you. Generated from the suites.
• Operational Qualification
  The 26 requirements, each with our automated evidence and a plain-language way to confirm it in your own tenant. Generated from the register.
• Performance Qualification
  Run only the sections for the modules you use. Each names the evidence we hold, so your steps stop where ours end.
• Installation Qualification
  There is nothing to install, so this qualifies your tenant configuration instead — and states the environment we run, which you cannot inspect.
• Platform release record
  Every release, classified, with an explicit statement of whether it affects your validation. This is what to check before deciding a new version needs revalidation.

What we do not provide

The Master Plan §6 names four documents this pack does not include — a supplier risk assessment, an environment-qualification statement, a regulatory mapping annex, and a per-release test evidence report — and says what to do instead of each. They are named there rather than omitted quietly, so you can price the work before committing to it.

Questions, or something here that does not match what you find in the product: support@qmsnordic.com.