Traceability Matrix — QMS Nordic
| Document ID | QMSN-TM-001 |
| Applies to | QMS Nordic v1.5.0 |
| Generated | from the source of truth, not written by hand |
Generated from the platform's requirement register, not written by hand, and regenerated on every change. A build check fails if this document falls out of step with the code it describes, so it cannot quietly stop being true — which is what happens to a hand-maintained matrix within two releases.
Requirement ↔ evidence ↔ test ↔ regulatory clause.
Summary
| Count | What it means for you | |
|---|---|---|
| Fully covered by our evidence | 18 | Review our evidence; no testing needed unless your configuration differs |
| Partially covered | 7 | Our evidence covers part of it. The Coverage column in the matrix below marks these Partial, and the note under each says what is left |
| No evidence from us | 1 | Concentrate here. We hold nothing |
| Total | 26 |
Where your effort goes. The 1 uncovered requirements are yours outright — start there. The 7 partial ones each carry a remainder described in their note, so 8 of 26 requirements need something from you. Sizing the job from the uncovered count alone will understate it.
Why we publish the gaps. A matrix showing only covered requirements is marketing, not evidence. An auditor who finds an undeclared gap will reasonably doubt everything else in the pack — and the customer, not the vendor, carries that finding.
Matrix
| Requirement | Risk | Coverage | Our evidence | Your test (T4) | Clauses |
|---|---|---|---|---|---|
URS-DOC-01 Controlled documents are created, reviewed and approved through a defined lifecycle. | High | Full | Test: 1. the author creates a draft: version 1, one snapshot, on the trail Test: 4. the author submits it for review Test: 5. the author cannot approve their own document, even with re-authentication Test: 6. in production the reviewer cannot sign without a passkey assertion Test: 8. the reviewer signs: approved, and the signature names signer, version, meaning and reason Test: 9. the author makes it effective Test: a rejection returns the document to draft, and the rejection is a signature too Test: a colleague verifies every section, and the document moves to Under Review by itself Test: IVDR PerformanceEvaluation report approval gate Test: IEC 62366-1 UsabilityFile approval gate | T-DOC-02 | ISO 13485 §4.2.4; FDA QMSR §820.10 |
URS-DOC-02 Each document carries a unique identifier and version; superseded versions remain retrievable. | High | Full | Test: 2. the author revises it: version 2, both snapshots kept, still a draft Test: 10. revising an effective document returns it to draft at version 3; the old approval does not carry Test: 12. every version is still retrievable, with its own content Test: keeps every version's content after a revision Test: numbering — formatRef / parseRef round trip Test: derives a tenant prefix from a manufacturer name | T-DOC-03 | ISO 13485 §4.2.4; FDA QMSR §820.10 |
URS-DOC-03 Only approved, current versions are presented to users as effective. | High | Full | Test: accepts an approved document Test: refuses a draft Test: refuses a document still in review Test: refuses a document marked approved that carries no approval record Test: refuses when the approval on file is for an earlier version | T-DOC-01 | ISO 13485 §4.2.4(d) |
URS-DOC-04 Obsolete documents are prevented from unintended use. | High | Full | Test: cannot return an obsolete document to effective Test: retires the prior effective policy when a new one is released Test: records the retirement in the audit trail | T-DOC-01 | ISO 13485 §4.2.4(f) |
URS-DOC-05 Periodic review dates are tracked and surfaced before they lapse. | Medium | Partial | Test: opens thirty days before the due date and never closes Test: does not repeat itself within a week, and does after Test: warns before the date and is urgent after it Test: tells the owner and the QA administrator about the due and the overdue document, and nobody about the paused one Test: says nothing the second time the same week | — | ISO 13485 §4.2.4(b) |
URS-AUD-01 Every create, change and delete of a quality record is recorded with actor, timestamp and previous value. | High | Partial | Test: creates an AiGeneration row + AI_DRAFT_GENERATED audit event with matching hashes DB: audit_event table with actor, timestamp, payload and prior value | T-AUD-01 | ISO 13485 §4.2.5; 21 CFR Part 11 §11.10(e) |
URS-AUD-02 The audit trail cannot be altered or deleted, including by administrators. | High | Full | Test: blocks UPDATE and DELETE for the application role DB: audit_event_no_update and audit_event_no_delete triggers CI: Security DDL survived the rebuild — asserts 3 triggers exist Test: no email address and no live credential is written into the trail by any audit call in the application Test: the recorder itself refuses an address or a credential a moment before the row is written | T-AUD-03 | ISO 13485 §4.2.5; 21 CFR Part 11 §11.10(e) |
URS-AUD-03 Alteration of an audit record is detectable. | High | Full | Test: recomputing the hash exposes a tampered row Test: links each row to the one before it DB: audit_event_hash_chain trigger; prevHash/hash columns | T-AUD-03 | 21 CFR Part 11 §11.10(e) |
URS-AUD-04 The audit trail is readable and exportable for review. | High | Partial | Test: exports the audit trail as CSV, with the hash chain intact Test: records the export itself in the trail Test: refuses the export to a role that may not take records out | T-AUD-04 | 21 CFR Part 11 §11.10(b); §11.10(e) |
URS-SIG-01 Signing requires the signer to re-authenticate at the moment of signing. | High | Partial | Test: refuses when no challenge has been issued Test: refuses a challenge that has expired Test: refuses a challenge issued for registration, not signing Test: refuses to sign without an assertion once a passkey is enrolled Test: refuses a signature whose re-authentication does not match the signer | T-SIG-01 | 21 CFR Part 11 §11.10(g); §11.200 |
URS-SIG-02 A signature records the signer, date, time and the meaning of the signature. | High | Full | Test: records signer, time and meaning when a signature is accepted Test: cannot record a signature with no meaning Test: signs the named step and writes the signature against the document Test: refuses a signature with no reason — the meaning of the signature DB: document_approval stores signer, timestamp, meaning and credential id | T-SIG-02 | 21 CFR Part 11 §11.50 |
URS-SIG-03 A signature is bound to the record signed and cannot be replayed against another. | High | Full | Test: refuses a live challenge issued for a different document Test: refuses a credential belonging to another user DB: webauthn_challenge.documentId binds a SIGN challenge to its document | T-SIG-02 | 21 CFR Part 11 §11.70 |
URS-SIG-04 A signed record cannot be modified without invalidating the signature. | High | Full | Test: editing an effective document returns it to draft and versions the content Test: does not require a join to the audit trail to establish what was signed Test: keeps null distinguishable from a version, for signatures predating the column DB: document_approval.documentVersion records the version signed; document_snapshot retains it; appendVersion drops an EFFECTIVE document back to DRAFT | T-SIG-03 | 21 CFR Part 11 §11.70; §11.10(e) |
URS-ACC-01 Access requires authentication; permissions are assigned by role. | High | Full | Test: grants each permission to exactly the roles it is meant for Test: refuses an unknown or absent role everything Test: enforces it in the action, not only in the check Test: records the refusal, so a denied attempt is not invisible Test: lets R&D sign the first step of a design plan, and Quality release it Test: refuses Regulatory Affairs approving the last step of a route made before the rule Test: refuses a route whose last step is not Quality's Test: lets a Manufacturing engineer sign that step, and Quality release the SOP Test: refuses a change while an approval route is open | T-ACC-01 | ISO 13485 §4.1.6; 21 CFR Part 11 §11.10(d) |
URS-ACC-02 A user sees only records belonging to their own organisation. | High | Full | Test: cross-tenant retrieval — query from tenant A returns no tenant B rows Test: submitForReview cannot read tenant B's document Test: refuses to sign a document belonging to another organisation DB: row-level security enabled and forced on every table carrying tenantId CI: Tenant isolation is enforced on the rebuilt database — inserts two tenants and asserts a scoped read returns only its own row | T-ACC-02 | ISO 13485 §4.2.5; GDPR Art. 32 |
URS-ACC-03 Separation of duties can be enforced — approval requires a different person from the author. | High | Full | Test: refuses to let the author approve their own document Test: refuses the author approving their own document Test: refuses one person approving two steps of the same route Test: refuses a Super Admin signing a step assigned by name to someone else Test: refuses the same Super Admin signing a second approval Test: becomes APPROVED when three different people have signed, and records the role each holds Test: enforces segregation of duties between plan and report approver Test: approves a complete PER from a different approver | T-ACC-01 | ISO 13485 §4.2.4(a); §5.5.1 |
URS-ACC-04 Access is removed when a user leaves. | High | None | None — customer testing required | T-ACC-03 | ISO 13485 §4.1.6; 21 CFR Part 11 §11.10(d) |
URS-RET-01 Records remain legible and retrievable for the retention period the customer sets. | High | Partial | Test: keeps every version's content after a revision Test: does not delete anything when a document is retired | T-RET-01 | ISO 13485 §4.2.5; 21 CFR Part 11 §11.10(c) |
URS-RET-02 Records can be exported in a usable format without vendor assistance. | High | Partial | Test: exports documents without vendor assistance Test: exports the audit trail as CSV, with the hash chain intact Test: refuses the export to a role that may not take records out | T-RET-02 | ISO 13485 §4.2.5; 21 CFR Part 11 §11.10(b) |
URS-RET-03 Data is backed up and restorable. | High | Partial | Report: Witnessed restore of production, 2026-08-28 — 45 minutes measured | T-RET-03 | ISO 13485 §4.2.5; EU GMP Annex 11 §7.2 |
URS-AI-01 AI-generated content is identifiable as such, with model and generation recorded. | Medium | Full | Test: creates an AiGeneration row + AI_DRAFT_GENERATED audit event with matching hashes | — | ISO 13485 §4.2.5; EU AI Act Art. 50 (where applicable) |
URS-AI-02 No AI-generated document becomes effective without human review and approval. | High | Full | Test: refuses an AI draft that has not been approved Test: clears the AI badge only when a human signs the approval Test: refuses a draft | T-AI-02 | ISO 13485 §4.2.4 |
URS-AI-03 An incomplete generation is flagged rather than presented as complete. | High | Full | Test: continues when the model runs out of room, and finishes without warning Test: continues when the model stops early WITHOUT the completion marker Test: gives up after the continuation limit and says so | — | ISO 13485 §4.2.4 |
URS-AI-04 A failure of the AI provider does not produce a document. | High | Full | Test: reports a rate limit as transient and produces no document Test: reports a non-transient failure plainly, and still produces no document | — | ISO 13485 §4.2.4 |
URS-CHG-01 Changes to the platform are recorded, reviewed and traceable to a released version. | High | Full | CI: Verify — test and build on every change, blocking CI: Verify — type checking and linting on every change, blocking CI: Migration history rebuilds the database — blocking DB: schema changes applied only via reviewed migrations (prisma migrate deploy) | — | ISO 13485 §4.1.6 |
URS-CHG-02 The recorded change history reproduces the validated system. | High | Full | CI: Migration history rebuilds the database — rebuilds from empty, diffs against the shipped schema, asserts 185 policies, 636 grants and 3 triggers survive | — | ISO 13485 §4.1.6 |
Where your testing belongs
1 requirements have no automated evidence from us. In risk order:
| Requirement | Risk | Your test | Why, and what to do |
|---|---|---|---|
URS-ACC-04 Access is removed when a user leaves. | High | T-ACC-03 | This is a customer process requirement, not a platform one. The platform removes access when told to; knowing when to tell it is your joiner/leaver process. Most commonly found gap under this clause — test it. |
Partially covered — what our evidence does not reach
| Requirement | Risk | Your test | What is left to you |
|---|---|---|---|
URS-DOC-05 Periodic review dates are tracked and surfaced before they lapse. | Medium | — | A document with a review schedule is surfaced to its owner and to the QA administrators from 30 days before the review date, daily thereafter but not more than once a week, and as urgent once the date has passed. The rules are tested without a database; the daily job that applies them is exercised end to end on the CI database. Until 2026-09-05 this requirement carried no evidence — the behaviour had existed since the data model, the tests had not. |
URS-AUD-01 Every create, change and delete of a quality record is recorded with actor, timestamp and previous value. | High | T-AUD-01 | Audit writing is covered for the AI drafting path. Coverage across all modules is not automated — spot-check the modules you rely on. |
URS-AUD-04 The audit trail is readable and exportable for review. | High | T-AUD-04 | The trail exports as CSV carrying every field including hash and prevHash, so the chain can be verified outside the platform. Two limits worth knowing: the export is capped at 50,000 events, which is above any current tenant but is a ceiling rather than a guarantee of completeness under Part 11 §11.10(b); and it is a whole-trail export, not a filtered one, so producing the events for a single record means filtering the file yourself. |
URS-SIG-01 Signing requires the signer to re-authenticate at the moment of signing. | High | T-SIG-01 | Covered as a gate, on both ways of signing a document — direct approval and each step of an approval route: a signature cannot be produced without a live SIGN challenge issued to this user, and the action refuses to sign at all once a passkey is enrolled. The cryptographic verification itself is @simplewebauthn's, and we do not re-test it — forging a valid assertion to prove the happy path would only prove we can forge one. Note also that §11.200(a) sets a two-component test for non-biometric signatures and §11.200(b) a different bar for biometric ones; a passkey with user verification is not squarely either, and FDA has published no position. Decide which limb you are relying on and record the reasoning. |
URS-RET-01 Records remain legible and retrievable for the retention period the customer sets. | High | T-RET-01 | Every version's content stays retrievable, and retiring a document deletes neither its versions nor the signatures on it. What is still absent is a retention period: the platform does not delete records, but neither does it enforce or track how long you have undertaken to keep them. That undertaking, and evidence that nothing in your own configuration removes records before it expires, remains yours. |
URS-RET-02 Records can be exported in a usable format without vendor assistance. | High | T-RET-02 | Documents and the audit trail export to CSV without our involvement, and each export is itself audited. Not covered: there is no single whole-tenant export — you export per entity — and document content leaves as Word or Markdown from the document itself rather than in the CSV. Export what you would actually need in an inspection and confirm it is complete and readable outside the platform. |
URS-RET-03 Data is backed up and restorable. | High | T-RET-03 | Witnessed restore, 2026-08-28. A point-in-time copy of production was restored to a separate branch and verified: all 4,006 audit records rehashed to their contents, all reachable from the start of their chain, and row-level security and tenant isolation present on the copy — a scoped read returned 31 of 547 documents. The application was then run against the restored copy and signed into. Measured recovery time 45 minutes, from deciding to restore to the system being usable, against our stated four-hour recovery commitment. One finding is recorded in the report rather than omitted: 67 places where two audit rows share a predecessor, from batched writes between 23 May and 22 June 2026 — records unaltered and none missing, but at those points the chain alone does not prove nothing was removed. That finding stood against data which no longer exists: on 2026-09-09, before the first customer, the audit chain was restarted from empty and every tenant on the platform was demo or test data. The advisory lock that caused those shared predecessors was fixed in migration 20260427300000; the rows that predated the fix are gone, and the chain running today began after it. The rehearsal itself is unaffected — it evidenced a restore capability on a day, and that day happened. Rehearsed annually; next due 2026-08-28 + 12 months. The restore window itself was confirmed on 2026-09-09 and is 7 days: the platform moved off the provider's free tier, whose 6-hour history could not have supported the recovery the published security overview describes. Beyond seven days there is no restore point, which bounds what this requirement can claim — a fault introduced more than a week before it is noticed is not recoverable by this route. |
Evidence types
| Type | Meaning |
|---|---|
| Test | A test in the automated suite. Runs on every change and blocks the build. |
| CI | An assertion the pipeline makes about the built system — for example that the database rebuilt from empty still carries every isolation policy. |
| DB | A control enforced by the database itself, whose presence is asserted in CI. |
QMSN-TM-001 · v1.5.0 · pack rev. J (2026-09-07)
Published at qmsnordic.com/legal/validation/traceability. Cite the version above in your validation record — a pack is evidence, and evidence has to stay retrievable at the version you validated against.