The golden path: scope to signed audit export

Run the onboarding wizard (/onboarding, permission onboarding:manage): choose which frameworks apply — NIS2, ISO/IEC 27001:2022, GDPR (at least one, all optional) — and enter your organization profile. If NIS2 is selected, answer the sector/size/ special-provider scoping questions for a decision-support result (in-scope yes/no, entity type, confidence, reasoning) — explicitly labelled as decision support, not a legal determination. Finishing the wizard initializes control assessments for every control in your chosen frameworks.

Requirements stay browsable afterward at /requirements: each Article 21(2) measure card opens a detail panel listing its mapped controls, which link straight into the assurance vertical below.

The Control Matrix (/controls) lists your enabled frameworks' controls — NIS2 (Article 21), ISO/IEC 27001:2022 (93 Annex A controls) and GDPR (Article 32) — with bidirectional cross-mappings (assess once, progress all three) plus NIST CSF / CIS references. Open a control to read its objective, guidance and required evidence, then set status, maturity and owner (control:assess). A failing control flagged critical auto-creates a remediation task.

Upload a file or record metadata-only evidence at /evidence (evidence:write) — it is hashed (SHA-256) and gets a freshness status (fresh / soon-expiring / expired / unverified). Link it to a control; an evidence:approve holder reviews and approves it, which is what makes it count toward readiness — weak or old evidence is never hidden behind a green score. Evidence can be superseded by a newer version (POST /evidence/{id}/supersede): the prior version is kept immutably, marked superseded (who/when/why), and the new version restarts at pending for re-review. The detail page (/evidence/{id}) shows the full version history and flags a self-approval.

The guided assurance vertical (/assurance) walks one requirement through its full chain: scope → requirement → mapped control → evidence requirement → evidence submission → independent review → assurance state → an auditor-facing trace. Every stage shows a plain-language explanation and its data source. The assurance state itself is a shared, derived vocabulary — not a separate database status — computed from the existing assessment and evidence count:

"Independent" is enforced, not just a label: the approver of evidence or an assessment must differ from the person who submitted it (403 self_review_forbidden otherwise) — this is called segregation of duties (OD-5) in the codebase. A single-approver organization gets an audited break-glass self-approval instead of being blocked entirely, and every audit-trail row (both here and on the main Audit Trail page) expands to an object deep-link, the reviewer's comment and a before/after diff.

A gap becomes a formal nonconformity at /nonconformities (nonconformity:write) — either raised directly, or from an open finding via the shared triage drawer's "Raise nonconformity" action (Alerts / Exposure), which pre-fills title, description and the finding's linked control. The lifecycle is guarded: open → root_cause_analysis → corrective_action_in_progress → awaiting_effectiveness_review → closed (plus reopened / risk_accepted). Record the root cause, raise and track corrective actions, then sign off effectiveness — an honest, human-attested step: the product never auto-confirms a corrective action worked. Effectiveness sign-off enforces the same segregation-of-duties pattern as evidence/control review (the owner/closer cannot sign off their own fix), evaluated against an immutable snapshot of who owned and closed the action, not the live, editable fields.

GET /controls/{id}/assurance reports each control's linked nonconformity count (open and total) directly in the assurance vertical (stage 8), closing the loop from a control back to its open findings.

Record an ISO/IEC 27001 Clause 9.3 management review at /management-reviews (management_review:write — deliberately Security Manager / Admin only, not IT Manager: chairing a management review is a governance activity, not remediation execution). Free-text fields capture the Clause 9.3.2 inputs (status of prior actions, internal/external changes, ISMS performance, nonconformity/CAPA status, audit results, monitoring results, interested-party feedback, improvement opportunities) and the 9.3.3 outputs (improvement decisions, ISMS change decisions, resource needs). This is an honest, human-authored record — the product never generates, summarizes or judges the content for you. Finalizing a review is one-way; a mistaken finalize is corrected with a new review, not an edit.

The capstone of the golden path: /audit-room freezes your entire current assurance state — controls, an evidence index (by hash, never raw bytes), findings, nonconformities/CAPA and metrics — into one sealed, versioned snapshot (audit_snapshot:create). The freeze timestamp is always the true server wall-clock time; it is never a value the caller can set. From a sealed snapshot:

• Export a signed package — a self-contained bundle, signed with a per-deployment minisign (Ed25519) key.
• Verify offline — a standalone verifier checks the package's integrity and signature with no network calls (Python stdlib plus shelling out to the minisign CLI, since Python has no built-in Ed25519).

Auditors get audit_snapshot:read (they can inspect and verify a sealed snapshot) but not audit_snapshot:create — an auditor verifies the record, they do not produce the thing they audit. The signing mechanism itself (minisign, key management, verification) is documented under supply chain & release integrity.

Alongside the golden path, day-to-day work also happens in: Risks (treatment and management acceptance), Tasks (remediation with SLAs), Assets & Exposure (inventory, explainable exposure scoring), Alerts (triage queue, CISA KEV "patch now" panel), Suppliers (third-party risk questionnaires), Incidents (the NIS2 Article 23 reporting clock), Reports (board-ready Executive Readiness PDF, Statement of Applicability), AURA (the evidence- grounded AI assistant — every answer sourced and confidence-labelled), and the Audit Trail (the hash-chained ledger itself, independent of a sealed snapshot). The install guide's GRC-loop walkthrough demonstrates several of these end to end with screenshots.