QMS Nordic — Security Overview

A buyer-friendly summary of how QMS Nordic protects your data. Hand this to your InfoSec team during a vendor security assessment.

DRAFT — REVIEW BEFORE RELIANCE. The architecture below describes the platform as built. The operational commitments — on-call rotation, breach notification windows, the certification roadmap and its dates — are as first drafted in April and have not been re-confirmed by the operator.

Document ID: QMSN-LEGAL-SEC-001 Version: 2.0-draft Last updated: 2026-09-09 Issued by: Aitech International ApS, Nydamsvej 43, 8362 Hørning, Denmark, CVR 46545354 Companion documents: DPA, BAA, Sub-processors

---

TL;DR

---

Data protection

Encryption at rest

All Customer Data is encrypted at rest with AES-256 by the underlying database (Neon Postgres) and object storage providers. Key management is delegated to the cloud provider; rotation is automatic per the provider's KMS schedule.

Encryption in transit

TLS 1.2 or higher is enforced for all connections. HSTS is set with a 1-year max-age and includeSubDomains. HTTP requests are 308-redirected to HTTPS.

Tenant isolation

Postgres Row-Level Security is enabled with FORCE ROW LEVEL SECURITY on every tenant-scoped table (40+ tables). Every database transaction sets a per-transaction GUC app.tenant_id that the RLS policies use to filter rows. The application database role is non-superuser and cannot bypass RLS. Without a tenant id set, the application sees zero rows.

Audit trail

Every state-changing action emits an audit_event row containing the tenant id, actor user id, entity type, entity id, action, before/after payloads, reason, ULID, and a SHA-256 chain hash computed from the prior chain hash + tenant id + payload hash + ULID. A per-tenant advisory lock is taken before each insert to ensure the chain is unbroken under concurrency.

The audit log is append-only:

• The application database role lacks DELETE and UPDATE privileges on audit_event
• No application code path issues UPDATE or DELETE against this table
• A chain-verifier utility re-computes the chain end-to-end and flags any inconsistency

Electronic signatures (21 CFR Part 11)

Approvals, document promotions, and other signed actions require an electronic signature. The signature workflow:

1. The user is prompted with the entity hash and a free-text reason field
2. The system verifies the user's session is fresh (per a tenant- configurable inactivity threshold) and prompts for WebAuthn step-up if not
3. The signature manifestation captures: signer name, role, ISO timestamp, reason, entity id, entity version, and the SHA-256 hash of the entity payload
4. The manifestation is rendered into the audit-ready PDF export

Signatures are non-transferable: the manifestation hash binds the signature to the specific entity id and version.

---

Identity and access

Sign-in

• OIDC SSO supported with Google Workspace, Microsoft Entra ID, Okta
• Demo / fallback password sign-in available in non-production only
• Passwords (where used) are stored as bcrypt hashes with cost ≥ 10
• Failed sign-in attempts are rate-limited and audit-logged

Authorisation

• Role-based access control enforced server-side
• Roles: SUPER_ADMIN, QA_ADMIN, RA, RD, MFG, CLINICAL, AUDITOR
• Client-side gating is a UX courtesy; every action re-validates authorisation server-side
• Platform-operator access (/backend) is a separate auth realm with no shared credentials

Public API

• Bearer-token authentication
• Tokens stored as bcrypt hashes; the plaintext token is shown to the user once at creation
• Tokens are tenant-scoped; they cannot read data from another tenant
• Read-only — no POST/PUT/PATCH/DELETE paths on /api/v1
• Per-token rate limit (60 requests / minute by default)
• Revocation is immediate (within 60-second cache window)

---

Application security

Secure development lifecycle

• Code review required for every PR
• Type-checking, lint, unit tests, automated IQ + OQ subset on every PR
• Dependency vulnerability scanning (npm audit, Dependabot)
• Secret scanning enabled at the SCM layer
• Annual third-party penetration test (results summarised; full report available under NDA)

HTTP hardening

• HSTS, CSP, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin
• Cookies: Secure + HttpOnly + SameSite=Lax
• Stripe webhooks: signature-verified before processing

Input handling

• ORM-mediated queries (Prisma) — no string-concatenated SQL
• Strict input validation on every server action via Zod schemas
• HTML sanitisation on rendered Customer Data via DOMPurify

AI safeguards

• Provenance captured on every AI generation (model, prompt hash, retrieved chunk ids, output hash, latency, cost)
• AI output is labelled DRAFT and cannot auto-promote to EFFECTIVE
• Helpdesk Autopilot mode sends only when AI confidence ≥ tenant- configured threshold; both threshold and confidence are persisted
• Training-on-inputs is disabled with Anthropic and OpenAI

---

Operations

Hosting

• Application runtime: Vercel (multi-region, EU edges preferred for EU tenants)
• Database: Neon Postgres on AWS eu-central-1 (Frankfurt), confirmed in the provider console on 2026-09-09 — not a default we assume, the region the production project actually runs in
• Provider certifications: recorded per vendor in the sub-processor list, and only where they have been confirmed against the provider's own register entry or attestation. They are not uniform across our vendors, and they can depend on the plan held with each one, so this page does not state a single position for all of them

Backups and recovery

• Continuous backup with point-in-time recovery. Within the retention window below, the recovery point is under a minute
• Retention window: 7 days, read from the provider console on 2026-09-09. Stated as the figure it is rather than as a minimum: beyond seven days there is no restore point, so a problem introduced more than a week before anyone notices it cannot be rewound
• Cross-AZ redundancy at the database layer
• Annual disaster-recovery exercise (restore from PITR into a recovery instance, verify hash-chain integrity, signed by SRE Lead + QA Lead)
• Recovery Time Objective: ≤ 4 hours for primary-region failure

Monitoring

• Application errors: Sentry (with PII scrubbing)
• Uptime: external synthetic monitor + status page at qmsnordic.com/status
• Anomaly alerts to the on-call engineer

Incident response

• 24×7 on-call rotation for P0 / P1 incidents
• Documented runbook in docs/runbooks/
• Personal Data Breach: customer notification within 24 hours of awareness per the DPA
• HIPAA Breach: customer notification within 60 days per the BAA

---

Compliance posture

---

Data residency and regional posture

Data does not transit outside the customer's elected region except through the AI sub-processors (Anthropic / OpenAI), which today operate from the US. Customers concerned about US AI processing can disable AI features per tenant.

---

Vulnerability disclosure

If you believe you have found a vulnerability, email info@qmsnordic.com with details. We acknowledge within 24 hours, triage within 72 hours, and provide a remediation timeline within 7 days. We do not currently operate a paid bug-bounty program but offer responsible-disclosure recognition on https://qmsnordic.com/legal/security.

---

Customer-side responsibilities

This security model assumes Customer:

• Provisions Authorised Users with appropriate roles
• Disables accounts for terminated employees promptly
• Configures the identity provider with MFA and conditional access per Customer's own policy
• Reviews the audit log periodically
• Performs the Performance Qualification (PQ) on its tenant per the Validation Pack
• Notifies Aitech of any suspected security event affecting Customer's tenant

---

Document version