Installation qualification — QMS Nordic platform
| Document ID | QMSN-IQ-001 |
| Applies to | QMS Nordic v1.5.0 |
| Part of | The software validation pack |
| Supersedes | CAELUM-IQ-001, which described a self-hosted installation the platform has never had |
1. Why this document is short, and why that is correct
An installation qualification traditionally confirms that software was installed correctly: the right version, on the right hardware, with the right dependencies, in the right configuration.
You do not install QMS Nordic. It is delivered as a service. There is no server you provision, no runtime you patch, no dependency you resolve, and no installation step you could perform incorrectly. A conventional IQ protocol here would be theatre — a checklist of steps nobody executes, signed to satisfy a clause rather than to establish anything.
What remains genuinely yours to qualify is that your tenant is configured the way you intend, and that you can demonstrate it was. That is what this document covers. It is executed once, when you take the service, and again whenever you change one of the settings below.
The environment itself — the runtime, the database, the regions, the transport security — is ours, and is described in §3 rather than left for you to verify. You cannot inspect it, so we state it and you decide whether to accept it.
2. What you qualify: your tenant configuration
Record each of these as you find it. Where the expected value is "your decision", the qualification is that the recorded value matches what your quality system says it should be — not that it matches ours.
| # | Item | Where to find it | Expected |
|---|---|---|---|
| IQ-01 | Organisation name and identity | Admin → Settings | Matches your legal entity |
| IQ-02 | Users, and the role held by each | Admin → Users | Every user is a person you intend to have access, at the least privilege that lets them work |
| IQ-03 | Separation of duties | Admin → Users | At least two users can approve, or you have accepted in writing that author and approver may be the same person |
| IQ-04 | Rule pack version | Shown in the top bar | Recorded in your validation record; it determines which obligations are generated |
| IQ-05 | Document types in use | Admin → Document types | The set your procedures reference, and no more |
| IQ-06 | Retention statement | Admin → Settings | Matches your retention procedure. Nothing is deleted automatically — see URS-RET-01 |
| IQ-07 | AI allowance and whether AI is used at all | Top bar meter; Admin → Billing | If your procedures forbid AI-assisted drafting, confirm nobody holds a role that can invoke it |
| IQ-08 | Single sign-on, if used | Admin → Settings | Your identity provider, with your joiner/leaver process behind it (URS-ACC-04 is yours) |
| IQ-09 | Signing method | Admin → Users | Whether signers use a passkey or a password, and that it meets your §11.200 position |
| IQ-10 | Platform version | Footer, and the release record | Recorded in T5. Evidence must stay retrievable at the version you validated |
How to evidence it. A dated screenshot of each screen, filed with your T4, is sufficient and is what most auditors expect. The audit trail also records configuration changes, so a change after qualification is visible without relying on your own notes.
3. What we qualify, and state rather than ask you to verify
You cannot inspect these, so verifying them is not a task we can hand you. They are stated here so that accepting them is a decision you make knowingly.
| Position at v1.5.0 | |
|---|---|
| Runtime | Vercel. Application and API run as managed serverless functions; there is no host you or we patch. |
| Database | Neon Postgres, eu-central-1 (Frankfurt) by default. Point-in-time recovery is enabled with a window of at least seven days. |
| Tenant isolation | Enforced in the database by row-level security, forced on 139 tables under 175 policies, not by application code alone. The application connects as a role that cannot bypass it. Verified on every change and on the restored copy during the recovery rehearsal. |
| Audit trail | Append-only at the database: update and delete are blocked by trigger for the application role. Records are hash-chained. |
| Transport | HTTPS only, with HSTS and a content security policy. Verified by test on every change. |
| Backups and recovery | Managed point-in-time recovery. A restore was rehearsed on 2026-08-28 with a measured recovery time of 45 minutes — see the restore verification report. |
| Sub-processors | Listed publicly and separately. Review that list as part of your supplier assessment; it is not reproduced here because a copy would go stale. |
4. What this does not establish
| It is not an environment audit | §3 states our position. It is not an independent attestation, and no third-party penetration test has been performed — see the Master Plan. |
| It does not cover your identity provider | If you use SSO, your provider and your joiner/leaver process are outside this platform and outside this document. |
| It is not a substitute for operational testing | Confirming configuration is not confirming behaviour. That is T4. |
| It does not freeze the platform | This is a service and it changes. The release record states what changed and whether it affects a validation you have completed. |
5. Signature
Executed by the customer as part of T4. We do not countersign it, because we cannot attest to your configuration decisions.
| Executed by | |
| Role | |
| Date | |
| Platform version | v1.5.0 |
| Rule pack version | |
| Deviations raised |
QMSN-IQ-001 · v1.5.0 · pack rev. J (2026-09-07)
Published at qmsnordic.com/legal/validation/installation-qualification. Cite the version above in your validation record — a pack is evidence, and evidence has to stay retrievable at the version you validated against.