Risk Assessment — QMS Nordic
Template — QMS Nordic T3. Method: ISO/TR 80002-2:2017.
This is the document that justifies everything else. §4.1.6 requires validation "proportionate to the risk" — this is where you show the proportion. Under a risk-based approach an auditor does not ask "did you test everything?"; they ask "how did you decide what to test, and does the reasoning hold?" A thin risk assessment makes light testing look like laziness. A sound one makes it look like judgement.
Pre-filled with the platform side. We have stated, for each function, what can fail and what control exists. You supply the impact, because the same failure means different things in different companies — an audit trail gap matters more if these are your authoritative records than if they are a copy of a paper system.
Effort: half a day. The Impact and Acceptance columns are yours.
| Document | [DOC-XXX] Risk assessment — QMS Nordic |
| Software | QMS Nordic v1.5.0 |
| Register ID | [SW-001] |
| Method | ISO/TR 80002-2:2017 |
| Date | [date] |
1. Scoring
Use your existing risk scale if you have one — consistency across your QMS beats a bespoke scale here. Otherwise:
Impact — what happens if this function fails and nobody notices?
| High | A nonconforming product could be released, a record could be corrupted or lost undetectably, or a regulatory commitment could be missed. |
| Medium | A process fails visibly and is corrected before product or records are affected. |
| Low | Inconvenience only. |
Likelihood — accounting for the controls in place, not in their absence.
| High | Known to happen, or dependent on a person remembering something. |
| Medium | Plausible under load or unusual conditions. |
| Low | Requires multiple independent failures. |
Risk — Impact × Likelihood. The document asked you for this column and never said how to derive it, which left the one judgement call in the whole sequence to be invented per customer:
| Impact ↓ / Likelihood → | High | Medium | Low |
|---|---|---|---|
| High | High | High | Medium |
| Medium | High | Medium | Low |
| Low | Medium | Low | Low |
Override it where your own scale says otherwise — but record the reason. An auditor's question here is how did you decide, and "our corporate risk scale rates it differently" is a good answer where "it felt right" is not.
Two different risk scales are in play, deliberately. T1 §5.2 rates the tool — one category for QMS Nordic as a whole, which is what T2 and T5 ask for in their headers. This document rates each function. The tool category is the highest function risk you arrive at below.
Assurance — the effort that follows, and the point of the exercise.
| Risk | Assurance |
|---|---|
| High | Scripted testing of the function, with recorded evidence. Test it yourself. |
| Medium | Exercise it in normal use and record the outcome. Vendor evidence may cover the rest. |
| Low | Record the rationale for not testing. That rationale is the deliverable. |
2. Assessment
Impact and Acceptance are yours. The rest is pre-filled and can be adopted as written unless your configuration differs.
A dash in the Likelihood column is deliberate. Those are the rows where we hold no automated evidence, and a vendor who supplies the likelihood rating that justifies not testing the very thing the vendor did not test is not giving you an assessment. Rate them yourself. The control named in each row is real — it is implemented — but nothing in our test suite exercises it, and the traceability matrix (QMSN-TM-001) says so row by row.
2.1 Document control
| Ref | What could fail | Existing controls | Likelihood | Impact | Risk | Assurance you will apply |
|---|---|---|---|---|---|---|
| RA-01 | A superseded document is presented as current | Lifecycle states; only approved versions shown as effective; version history retained · No evidence from us (URS-DOC-03, URS-DOC-04) | — | ☐H ☐M ☐L | ||
| RA-02 | An approved document is altered without a new version | Versioning on every change; snapshots immutable; audit trail · Partly evidenced (URS-DOC-02); that a signed record cannot be altered is not (URS-SIG-04) | — | ☐H ☐M ☐L | ||
| RA-03 | A periodic review lapses unnoticed | Review dates tracked and surfaced · reminders to owner and QA from 30 days before, urgent once overdue — tested (URS-DOC-05) | — | ☐H ☐M ☐L |
2.2 Record integrity
| Ref | What could fail | Existing controls | Likelihood | Impact | Risk | Assurance |
|---|---|---|---|---|---|---|
| RA-04 | A quality record is changed with no trace | Audit trail on every create/change/delete with actor, timestamp and prior value | Low | ☐H ☐M ☐L | ||
| RA-05 | The audit trail itself is altered or deleted | Database triggers block update and delete on audit records; entries are hash-chained so alteration is detectable | Low | ☐H ☐M ☐L | ||
| RA-06 | Records become unretrievable within the retention period | Export without vendor assistance; managed backups · No evidence from us (URS-RET-01, URS-RET-02) | — | ☐H ☐M ☐L |
RA-05 is the one to test yourself if these are your authoritative records. Ask us to demonstrate it, or try to edit an audit entry and confirm you cannot. It is quick, and "we verified the audit trail could not be altered" is a strong line in a validation report.
2.3 Electronic signature (➖ if not used)
| Ref | What could fail | Existing controls | Likelihood | Impact | Risk | Assurance |
|---|---|---|---|---|---|---|
| RA-07 | A signature is applied without the signer present | Re-authentication required at the moment of signing · No evidence from us (URS-SIG-01) | — | ☐H ☐M ☐L | ||
| RA-08 | A signature is transferred to a different record | Signature bound to the specific document | Low | ☐H ☐M ☐L | ||
| RA-09 | A signed record is altered afterwards | Versioning; alteration produces a new version requiring re-approval · No evidence from us (URS-SIG-04) | — | ☐H ☐M ☐L |
2.4 Access and separation
| Ref | What could fail | Existing controls | Likelihood | Impact | Risk | Assurance |
|---|---|---|---|---|---|---|
| RA-10 | A user sees another organisation's records | Enforced by the database itself, not application code: every table carrying customer data has row-level security with per-organisation policies, and the application connects with a role that cannot bypass them | Low | ☐H ☐M ☐L | ||
| RA-11 | A user has permissions beyond their role | Role-based permissions · No evidence from us (URS-ACC-01) | — | ☐H ☐M ☐L | ||
| RA-12 | A leaver retains access | Your joiner/leaver process — the platform can only remove access when you tell it to | Medium–High | ☐H ☐M ☐L |
RA-12 is yours, and it is the one most often found. Every other row here is a platform control. This one depends on your offboarding process, and no vendor evidence covers it. Test it: remove a test user and confirm access is gone.
2.5 AI-assisted drafting (➖ if not used)
| Ref | What could fail | Existing controls | Likelihood | Impact | Risk | Assurance |
|---|---|---|---|---|---|---|
| RA-13 | AI content is inaccurate or fabricated | Human review and approval before any document becomes effective. Provenance recorded · The control is your review — no evidence from us (URS-AI-02) | — | ☐H ☐M ☐L | ||
| RA-14 | An incomplete draft is mistaken for a finished document | Completion marker; incomplete drafts flagged and recorded as such | Low | ☐H ☐M ☐L | ||
| RA-15 | A generation failure silently yields a template | A failed generation produces no document and reports an error | Low | ☐H ☐M ☐L |
RA-13 deserves an honest impact rating. AI output is not validated and is not deterministic — the same prompt may produce different text. Nothing in our evidence changes that. The control is entirely your review before approval. If your process permits an AI draft to become effective without a human approving it, this row is High and no amount of vendor documentation reduces it.
RA-14 and RA-15 were real defects, fixed in v1.0.0. Documents drafted before that release may be incomplete — see the platform release record. If you have pre-v1.0.0 AI drafts, checking them is a genuine action for you.
2.6 Availability
| Ref | What could fail | Existing controls | Likelihood | Impact | Risk | Assurance |
|---|---|---|---|---|---|---|
| RA-16 | The service is unavailable when needed | Managed hosting; status page · No evidence from us; no third-party penetration test has been run against production | — | ☐H ☐M ☐L | ||
| RA-17 | Data is lost | Managed backups · No evidence from us; no restore of production has ever been rehearsed, so we cannot evidence a recovery time | — | ☐H ☐M ☐L |
RA-17: ask for evidence of a demonstrated restore, not a backup policy. Auditors increasingly distinguish the two, and so should you. If we cannot yet show you one, record that as an open risk with your accepted mitigation rather than assuming it.
2.7 Your additions
| Ref | What could fail | Controls | Likelihood | Impact | Risk | Assurance |
|---|---|---|---|---|---|---|
| RA-18 |
3. Residual risk and acceptance
| Functions assessed | [—] |
| High risk requiring scripted testing | [—] |
| Medium | [—] |
| Low, rationale recorded | [—] |
| Open risks accepted | [—] |
Statement: Following the assurance activities above, residual risk associated with the use of QMS Nordic v1.0.0 in [COMPANY]'s quality system is [acceptable / acceptable with the following conditions].
Conditions: [—]
| Role | Name | Signature | Date |
|---|---|---|---|
| Prepared by | |||
| Approved by ([Quality Manager]) |
QMSN-T3 · v1.5.0 · pack rev. J (2026-09-07)
Published at qmsnordic.com/legal/validation/t3-risk-assessment. Cite the version above in your validation record — a pack is evidence, and evidence has to stay retrievable at the version you validated against.