Validation Master Plan — QMS Nordic Platform
| Document ID | QMSN-VMP-001 |
| Version | 1.5 · pack revision J |
| Applies to | QMS Nordic platform v1.5.0 |
| Date | 2026-08-26 |
| Audience | The QA lead responsible for validating this software in their own quality system |
| Supersedes | CAELUM-VMP-001 (2026-05-18) — see Document history |
1. Read this first
You have to validate this software. We cannot do it for you.
That is not a disclaimer, it is the requirement. EN ISO 13485:2016+A11:2021 §4.1.6 places the obligation on the organisation using the software, and it does not transfer to the vendor by contract, certificate or documentation. Notified bodies check this clause in every Annex IX audit, and it is among the most common non-conformities for software-forward manufacturers.
FDA states the position plainly:
The acceptance of vendor-supplied validation data in isolation of system configuration and intended use is not acceptable.
An auditor, on being shown a vendor's certificate:
"None of that was a validation of the tool as used by this company for this intended purpose."
What this pack does is remove the work that is genuinely ours: the evidence that the platform is built under control, that its functions behave as specified, and that its changes are recorded. Typical effect is to reduce your validation from a project to a review — but the review is yours, the sign-off is yours, and the record an auditor assesses is yours.
Section 5 lists exactly what you must produce. Section 6 is what we give you to produce it with.
2. What you are validating
QMS Nordic v1.5.0, a multi-tenant SaaS quality management system for medical device, IVD and pharmaceutical organisations, hosted on Vercel with a Neon PostgreSQL database in the EU (Frankfurt).
Every release is versioned and its changes classified — see the platform release record (QMSN-CL-001). Your validation report should name the version you validated. When we release a new one, that record tells you whether it requires revalidation.
In scope
The QMS modules you have enabled, the records they create, and the platform functions that protect those records: authentication and access control, tenant separation, the audit trail, electronic signature, document versioning and control, and AI-assisted drafting.
Out of scope, and why
| Not validated here | Why |
|---|---|
| Your configuration and use | §4.1.6 says this is yours. It is the part that cannot be delegated. |
| Identity providers (Google, Microsoft Entra, Okta) | Qualified under their own certifications; you configure the connection. |
| Anthropic (AI generation) | Model output is not deterministic and is not validated as such. Every AI-drafted document requires human review and approval before it becomes effective — the control is the review, not the model. |
| Browsers | Assumed evergreen; supported versions in the URS. |
| Documents you create in the platform | Your records, your validation. |
3. Method, and why this one
ISO/TR 80002-2:2017 — Validation of software for medical device quality systems — is the method. It is chosen deliberately:
- It is ISO, so it is market-neutral. It privileges neither FDA nor EU.
- It is medtech-specific, unlike general computerised-system guidance.
- It is risk-based, which is what §4.1.6 itself requires: validation "proportionate to the risk associated with the use of the software."
GAMP 5 (2nd edition) is used as supporting good practice. Under it, a configurable multi-tenant SaaS eQMS is a Category 4 (Configured Product): the software is commercially available and used as supplied, and you configure rather than modify it. This matters because it sets the expectation that you leverage vendor evidence rather than re-testing the platform yourself.
FDA's Computer Software Assurance guidance (final, 2025-09-24) reaches the same risk-based conclusions and supersedes §6 of the 2002 General Principles of Software Validation. It is referenced for US-facing customers as convergent — not as the basis, since an EU notified body does not apply FDA guidance.
A note on rigour. A risk-based approach is not a lighter one. It means depth is proportional to consequence: the audit trail, electronic signature and tenant separation are tested hardest because a failure there is a record integrity failure. Cosmetic behaviour is tested least. The traceability matrix (QMSN-TM-001) carries a risk rating for every requirement, and says plainly which ones we hold no evidence for.
4. One package, several markets
The same requirement underlies every market we serve, so this is one package with a mapping — not four packages.
| Market | Route to the requirement | Clause |
|---|---|---|
| EU — MDR 2017/745, IVDR 2017/746 | Article 10(9) → QMS → harmonised standard | EN ISO 13485:2016+A11:2021 §4.1.6 |
| USA — FDA QMSR (in force 2026-02-02) | 21 CFR 820 incorporates ISO 13485:2016 by reference | ISO 13485:2016 §4.1.6 |
| MDSAP — USA, Canada, Brazil, Japan, Australia | Audit model built on ISO 13485 + country requirements | ISO 13485:2016 §4.1.6 |
| UK — UKCA / MHRA | UK MDR 2002 (as amended), ISO 13485 route | ISO 13485:2016 §4.1.6 |
Use the designation your auditor uses. In the EU that is EN ISO 13485:2016+A11:2021 — the harmonised European version, whose Annex ZA carries the presumption of conformity with MDR. Citing plain "ISO 13485:2016" in an EU audit is the wrong designation for the same clause.
Supplementary requirements
These apply on top of §4.1.6 depending on your market and product:
| Requirement | Applies when | Where the evidence is |
|---|---|---|
| 21 CFR Part 11 §11.10(a), (e), §11.50, §11.70 | US, electronic records and signatures | Risk assessment §Audit trail, §E-signature |
| EU GMP Annex 11 | Pharmaceutical or combination products | Same evidence; mapping annex |
| ISO 13485 §4.2.5 | All — control of records | Retention, export and audit-trail evidence |
| ISO 13485 §7.5.6 / §7.6 | If you use the production or inspection modules | Module-level evidence |
Per-requirement clauses are listed in the traceability matrix (QMSN-TM-001). There is no separate mapping annex at v1.5.0 — see §6.
5. Your deliverables
Five documents. An auditor assesses these, not ours. A template for every one is provided — open it from this pack, or download the whole set as a single archive to work on in your own document system.
| # | You must produce | Template | Typical effort |
|---|---|---|---|
| 1 | Validation SOP — your documented procedure for validating QMS software | T1 — Validation SOP | Once, then reused |
| 2 | Intended use / URS — what you use this for, in your processes | T2 — Intended use / URS | Half a day |
| 3 | Risk assessment — the risk of the tool in your context | T3 — Risk assessment | Half a day |
| 4 | Test protocol and results — your own testing, with pass/fail | T4 — Test protocol | 1–2 days, scaled to risk |
| 5 | Validation report — findings and signed release for use | T5 — Validation report | Half a day |
Plus revalidation records when a release changes something you rely on. The platform release record tells you when: every release is classified, and states whether it affects your validation.
Why you still test something. Our evidence shows the platform works as specified. It cannot show that your configuration, your user roles and your processes produce the result you need. That is the gap an auditor probes, and it is why "we read the vendor pack" is not an answer. Keep the testing proportionate: exercise the workflows you actually rely on, hardest where a failure would corrupt a record.
6. What we provide
| Document | ID | What it gives you |
|---|---|---|
| This plan | QMSN-VMP-001 | Framing, method, responsibility split |
| User requirements | QMSN-URS-001 | One requirement per regulated behaviour, each with an ID |
| Traceability matrix | QMSN-TM-001 | Requirement ↔ evidence ↔ clause, generated from the code, including the requirements we have no evidence for |
| Regulatory mapping annex | QMSN-RMA-001 | The matrix inverted: clause ↔ what we claim, for the auditor holding a clause |
| Test evidence report | QMSN-TER-001 | What each automated suite establishes, and what it does not |
| Module evidence annex | QMSN-MEA-001 | For each process module you might run here — CAPA, complaints, training, suppliers and the rest — the tests we run, what they prove, and what is left to you. Generated from the suites |
| Installation qualification | QMSN-IQ-001 | Your tenant's configuration, and the environment we run that you cannot inspect |
| Operational qualification | QMSN-OQ-001 | The 26 requirements with our evidence beside each and a plain-language way to confirm it in your tenant. Generated from the register |
| Performance qualification | QMSN-PQ-001 | Organised by module: run only the sections for the modules you use, each pointing at the evidence we already hold |
| Release record | QMSN-CL-001 | What changed per release, classified, with an explicit statement of validation impact |
What we do not provide at v1.5.0
A vendor pack that lists documents it does not ship is worse than a short one: the first thing an auditor does is ask for them. Three of the four listed at v1.3.0 are now provided and are struck through below, with what changed; the fourth remains ours to explain rather than supply.
| Not provided | What you do instead |
|---|---|
| Supplier risk assessment | Risk is yours to assess in your context — that is what template T3 is for, and why it is a template rather than a document you countersign. Our per-requirement risk ratings are in the traceability matrix, and the sub-processors we engage are listed publicly. |
| ~~Per-release test evidence report~~ | Now provided (QMSN-TER-001), stating suite by suite what the automated tests establish and what they do not. It is not a signed results report for a specific run: that signature is yours to apply after executing T4. Ask us for a run at any release. |
| ~~Installation qualification protocol~~ | Now provided (QMSN-IQ-001), though not in the conventional form: there is nothing for you to install, so it qualifies your tenant configuration and states the environment we run, which you cannot inspect. |
| ~~Clause-by-clause regulatory mapping~~ | Now provided (QMSN-RMA-001), generated from the requirement register so it cannot drift from what it maps. |
What we have not done
Distinct from §6's list of documents we do not provide: these are activities a supplier assessment normally asks about, and our answer is currently no. They are stated here because you will ask, and because T3 tells you to ask — sending you to ask a question we already know we fail is worse than saying so.
| Position at v1.5.0 | What we do instead | What it means for you | |
|---|---|---|---|
| Third-party penetration test | Never executed against production. | Internal security review against the OWASP Top 10; database-enforced tenant isolation, hash-chained audit trail, and transport security are each verified on every change. | If your supplier assessment requires an independent test report, we do not have one. Ask before you commit. |
| WCAG 2.1 AA audit | Not completed. | The interface is built on accessible-by-default component primitives and uses semantic markup; keyboard and screen-reader use has been smoke-tested, not audited. | If accessibility conformance is a procurement condition for you, treat this as unevidenced. |
| Automated retention enforcement | Not implemented. | Nothing is deleted automatically. Records are retained indefinitely and can be exported at any time. | Your retention period is a decision you record and enforce; the platform will not purge for you, and will not purge early either (URS-RET-01). |
Why this section exists. A supplier who lists only what they have done invites the question of what they have not. These three are the ones an assessment reaches, and each is an open item on our side with an owner. Ask for the current position — it may have changed since this revision.
There were four until 2026-08-28, when the disaster-recovery rehearsal was executed and witnessed. That row moved to §6, How our evidence is produced.
How our evidence is produced
Not by assertion. Every claim below is checked automatically on every change, and the check fails the build if it stops being true:
- The test suite runs on every change and blocks the build. Ask us for the current count and the CI run that produced it — we publish the machine-readable results as a build artefact, so the number is checkable rather than quoted.
- The database is rebuilt from empty on every change and verified to carry the complete security configuration: 175 isolation policies, 600 grants, 3 audit-tamper triggers. Tenant isolation is then proven on the rebuilt database by inserting two tenants and confirming a scoped read returns only its own rows.
- Schema changes reach production only through reviewed, versioned migrations.
- Changes to validation evidence, database schema, and the e-signature, audit and isolation surface require code-owner review.
This is what "built under control" means here, and it is the substance behind §4.1.6 change control. Where a control is procedural rather than enforced, we say so — see Known limitations in the platform release record.
7. Revalidation
| Release class | What we do | What you should do |
|---|---|---|
| Patch | Full test suite, an entry in the release record | Nothing. Record the version. |
| Minor | As above, plus updated evidence and traceability | Review the release record for functions you rely on; test only those. |
| Major | As above, plus explicit validation-impact notes per change | Review impact notes; re-test affected workflows; re-sign your validation report. |
Every release carries its class in the platform release record. Where a change affects something you are likely to rely on, the entry says so explicitly — including when the news is unwelcome.
You will not have to notice this yourselves. When a release moves the platform past the version your most recent validation names, the platform raises a task for your QA administrators within a day, once per version. The task points at the release record; it does not decide for you whether the change matters.
8. Document history
| Version | Date | Change |
|---|---|---|
| 1.5 rev. J | 2026-09-07 | The document lifecycle is now run end to end. Until this revision URS-DOC-01 said in its own note that the general approval route was not covered by an automated test, and URS-DOC-02 said the same of version retention; both were "partial" and both leaned on your T4. A new suite walks a document through the whole process on a rebuilt database, as two people: the author creates, revises (version 2, both snapshots kept), submits; the author's own approval is refused; the reviewer's approval without a passkey assertion is refused on the production path; the reviewer signs and the signature carries signer, version, meaning and reason; the document becomes effective; a further revision returns it to draft at version 3 and needs its own signature; every version stays retrievable; the trail names the right person at each step. A rejection and the AI-draft verification route are covered in the same suite. Both requirements are now "full". The register is unchanged at 26. |
| 1.5 rev. I | 2026-09-07 | A thirteenth module, from the end-to-end review. The 2026-09-07 review of production found that a device could be set ON MARKET with no Declaration of Conformity and no record on the page of who had released it, and that two products could carry one UDI-DI. Both are now refused through the real actions — the release gate accepts an approved or effective declaration on the product or its family, or a written justification that lands on the audit trail — and the suites that prove it are collected as M-PROD (Product register and market release) in the annex, with a matching section 15 in the PQ. The register is unchanged at 26. |
| 1.5 rev. H | 2026-09-07 | The OQ and PQ are now in the pack, and the process modules have evidence. Until this revision the pack evidenced only its 26 requirements; a customer running CAPA, complaints, management review, training, suppliers, equipment, software lifecycle or submissions here had nothing from us for those modules and had to test them from scratch. Nine new suites now exercise each module's regulatory gates through the real server actions on a rebuilt database — a CAPA cannot close without a verified effectiveness check, a reportable complaint cannot close with its report outstanding, a training verifier must be a different person, and so on. They are collected in a new Module Evidence Annex (QMSN-MEA-001), generated from the suites so it cannot drift. The Operational Qualification (QMSN-OQ-001) is generated from the register — our evidence beside each requirement, with a plain-language confirmation step — and the Performance Qualification (QMSN-PQ-001) is rewritten by module so you run only the sections for what you use, each pointing at the annex. Both replace Caelum-era drafts that cited a requirement register that no longer existed and were withheld for that reason. The register itself is unchanged at 26. If you are mid-validation: nothing you have done is invalidated; the new documents reduce what remains. |
| 1.5 rev. G | 2026-09-06 | One isolation policy added; the counts this pack quotes move from 174 to 175. The built-in audit checklist templates are shared rows that every tenant should be able to read and none should be able to change. The table's policy admitted only a tenant's own rows, so the built-ins could never be installed or seen. A second, read-only policy now admits the shared rows; writes still require ownership, and a test run as the application role on the rebuilt database proves both. Nothing about your tenant's own data changes. |
| 1.5 rev. F | 2026-09-05 | Periodic review reminders are now evidenced, so your testing burden decreases. URS-DOC-05 — review dates tracked and surfaced before they lapse — was the last platform requirement in this pack with no evidence from us, and the matrix told you to test it yourself. The behaviour had existed since the data model: a daily job reminds the document owner and the QA administrators from 30 days before the review date, not more than once a week, and as urgent once the date has passed. What did not exist was proof. The rules are now tested without a database and the job is exercised end to end on the CI database; the matrix carries five tests where it carried "None". If your T3 rated RA-03 on the assumption of no vendor evidence, you may lower it. |
| 1.5 rev. E | 2026-09-04 | Revalidation is now raised as a task, not left to be noticed. When a release moves the platform past the version your most recent software validation names, a task is raised for your QA administrators within a day and once per version, pointing at the release record. The pack page already showed the drift; it could not tell anyone who was not looking. §7 gains the sentence. No requirement changes coverage. |
| 1.5 rev. D | 2026-09-04 | Type checking and linting now block the build. Since the first release both ran on every change but could not fail it, and the matrix said so: the evidence for URS-CHG-01 read "reported but not blocking", and the release record carried it as a known limitation. That was truthful and it was also the mechanism by which 151 type errors accumulated unheard, among them queries naming columns their tables do not have — the reason a CAPA effectiveness check never reached its owner and a document approval never assigned the training it should have. Every error is cleared and both checks are blocking as of this revision; the matrix entry now says so, and a test fails the build if the workflow and the matrix ever disagree about it again. No requirement changes coverage; URS-CHG-01 remains Partial because its remaining gap is code-owner review, not the type check. |
| 1.5 rev. C | 2026-09-04 | The evidence for one requirement was published as "DB: undefined". URS-RET-03 — data is backed up and restorable, rated High — carried its evidence in the wrong shape in the register the Traceability Matrix is generated from, and the generator rendered the resulting gap as a database control with no name. The evidence itself was never in doubt and is unchanged: the witnessed restore of 2026-08-28, with the measured 45-minute recovery. The matrix now names it, and the generator carries a fifth evidence kind for a witnessed exercise recorded in a dated report — distinct from a test, a CI assertion or a database control, because it evidences that something worked on a day rather than continuously. That is also why the row remains Partial rather than becoming Full. No coverage figure changes: 24 of 26 requirements carry some evidence, 2 carry none. |
| 1.5 rev. B | 2026-09-04 | Two corrections to this document, and one to the register behind it. §6 What we have not done introduced its table as "these four" while listing three; the fourth was the disaster-recovery gap, closed on 2026-08-28, whose row was removed without the count following it. The 1.4 entry below cited a disaster-recovery identifier that has never existed in the requirements register from which this pack, the Traceability Matrix and template T2 are generated; the requirement it meant is URS-RET-03, named in the same sentence. Neither error changes any position we have taken or any evidence we hold, and no deliverable you have completed is affected. Behind them, the internal deviation register was reviewed for the first time since it was opened in April: every one of its cross-references into the Traceability Matrix was broken, two of its entries described a platform that has since changed, and it recorded nothing about which gaps are disclosed to you — which is how the count above came to disagree with its own table. |
| 1.5 rev. A | 2026-09-01 | Read this if you have generated a PSUR, an MIR draft or a document bundle. A type check that had been suppressed since the first release was turned on, and eleven features proved not to be working — most of them failing silently, because the queries behind them were rejected by the database and the rejection was caught and rendered as an empty result. The three that produced regulated output are the ones to act on: an MIR draft classified a death as a trend report and stated a 15-day deadline where Article 87 allows 2 or 10; a PSUR reported zero serious incidents whatever the complaints held, with a severity breakdown carrying no information; and a document bundle's approvals.json recorded no signing time for any signature, besides the download failing outright. Regenerate any of those produced before this release — the underlying records were never wrong, only these readings of them. Also fixed: the daily digest, which no tenant had ever received; every user's inbox, which always showed nothing assigned; the management-review agenda, drafted with no device class; the iCal feed, which rejected every subscription and failed closed; servicing and installation records, which could not be saved at all; and the saved-report print page. No record was created, altered, deleted or approved incorrectly by any of this — every fault was a read. §6 and §8 unchanged in substance. |
| 1.4 rev. A | 2026-08-28 | A restore of production has now been rehearsed and witnessed, so your testing burden decreases again. Until this release we could evidence that backups existed but not that a restore worked — the honest position, and one template T3 tells you to press us on. A point-in-time copy of production was restored and verified: all 4,006 audit records rehashed to their contents and all reachable from the start of their chain, with row-level security and tenant isolation present on the copy. The application was then run against it and signed into. Measured recovery time 45 minutes, from deciding to restore to the system being usable, against our stated four-hour recovery commitment — so that figure is now witnessed rather than stated. URS-RET-03, the requirement that data is backed up and restorable, moves from no evidence to covered and deviation CAELUM-DEV-0001 is closed; requirements we hold no evidence for fall from three to two, and no platform requirement rated High is now without evidence. One finding is recorded rather than omitted: 67 places where two audit rows share a predecessor, from writes batched between 23 May and 22 June 2026. No record is altered and none is missing — every row hashes to its contents and every row is reachable — but at those points the chain alone does not prove nothing was removed. Deletion of audit rows by the application role is separately blocked at the database. If you have already completed T3, its RA-17 entry can be re-rated. |
| 1.3 rev. A | 2026-08-26 | Read this if you validated a release before v1.3.0. Making a document effective now requires that it is approved and that an approval record exists for the current version. Until this release that rule was enforced by the interface only — the button appears for approved documents, but the action behind it accepted any status — so a form post could take a draft, including an unreviewed AI draft, straight to effective. URS-DOC-03 and URS-AI-02 were published as describing platform behaviour and in fact described the interface; both now describe the platform, and both are tested. Six requirements move from no evidence to covered: URS-DOC-03, URS-DOC-04, URS-ACC-01, URS-AUD-04, URS-RET-01, URS-RET-02, plus URS-AI-02. Requirements we hold no evidence for fall from ten to three. |
| 1.2 rev. A | 2026-08-26 | A signature now records the document version it released. 21 CFR Part 11 §11.70 requires a signature to be linked to its record; that link existed but lived only in the audit trail, so establishing which version a signature approved meant joining two tables. It is now on the signature. URS-SIG-04 moves to fully covered. Signatures recorded before this release carry no version where the audit trail did not supply one — shown as absent rather than filled in. If your validation relied on reading that link from the audit event, it still works; nothing was removed. |
| 1.1 rev. B | 2026-08-26 | |
| 1.1 rev. A | 2026-08-26 | Read this if you completed a document from the 1.0 pack. Template T2's requirement identifiers changed: URS-DOC-04 and the URS-ACC-* block named different requirements here than in T2, so a confirmation recorded against those IDs maps to a different requirement now. Seven requirements T2 asks you to confirm — periodic review, audit-trail export, modification of a signed record, leaver access, and the three retention requirements — had no vendor position and now have one, all declared as having no automated evidence. §5 and §6 corrected: the pack listed eight supplied documents when four existed and named four it does not provide; §6 now states both what is not provided and what we have not done. Document-control clauses corrected from §4.2.3 (the 2003 numbering) to §4.2.4, and 21 CFR 820.40 replaced by QMSR §820.10. The change-control evidence claimed the CI type-check and lint steps were blocking; they are not, and never were. T3 no longer pre-rates the likelihood of controls we hold no evidence for, and now states how to derive a risk rating. T1 adds the Part 11 obligations that validating software does not discharge. |
| 1.0 | 2026-08-25 | Rewritten against QMS Nordic v1.0.0. |
| — | 2026-05-18 | Superseded (CAELUM-VMP-001). |
Why there is a revision letter. The platform version tells you what software this describes. The revision letter tells you which issue of the documents you hold, because a correction to a template is not a platform release and cannot borrow its number. If you have already completed a template from an earlier revision, this table says whether anything changed that affects it. Cite both in your validation report.
Why the previous version was withdrawn. It described a continuous integration pipeline, release tags and a review gate that did not exist at the time of writing, and referenced domains no longer in use. Those things exist now — but a validation document whose claims cannot be checked is worse than no document, because every other claim in it becomes suspect. This version states only what is true of v1.5.0 and can be verified, and marks the remaining gaps as gaps.
QMSN-VMP-001 · v1.5.0 · pack rev. J (2026-09-07)
Published at qmsnordic.com/legal/validation/master-plan. Cite the version above in your validation record — a pack is evidence, and evidence has to stay retrievable at the version you validated against.