Audit Pack: Compliance Evidence Reports

The Audit Pack is an on-demand, realm-scoped evidence report generated from the Dashboard page Audit Pack (/audit-pack). It produces a localized PDF built from your realm's telemetry and configuration state, structured for NIS2/KSC/BSIG-style audits: a Requirements Coverage Matrix, evidence annexes, an organizational attestation section, and a recovery demonstration checklist.

The document is tooling evidence that supports an audit. It is not a compliance certification, legal advice, or proof of conformity - this is stated on the cover of every generated PDF.

Prerequisites and access control

• The page is gated by the realm.view_audit_logs permission. Users without it cannot load the extract or generate the PDF.
• Report generation itself is recorded in the audit log: every successful report generation writes an entry to the realm's audit trail, recording the initiating user, the report period, and the selected jurisdiction profile. Auditors can therefore verify when and by whom evidence was produced.

Configuring the report

The Report Configuration card offers three settings.

Jurisdiction Profile

The French profile is marked as pending: France has not completed NIS2 transposition, so the profile cites a non-promulgated bill and an ANSSI working document. When it is selected, a warning banner is shown on the page, a caveat is printed on the PDF cover, and every matrix row carries an asterisk noting that the legal references are provisional and subject to renumbering.

The profile selects presentation and labeling only - the requirement rows, their legal references, and the language of the legal basis list. The underlying evidence extract is identical for all profiles.

Report Language

The PDF can be rendered in English, Polish, German, or French, independently of the Dashboard UI language. The default follows the selected profile (EN for EU, PL for Poland, DE for Germany, FR for France) and can be changed freely.

Period

Presets cover the last 30, 90 (default), or 365 days; a custom date range is also available. The end date is inclusive. The backend defaults to the last 90 days when no range is given and caps any range at 400 days.

Generating the report

1. Click LOAD PREVIEW. The Dashboard fetches the evidence extract for the selected period and renders a KPI strip (backup success rate, members with MFA, active findings, scan coverage) and a live preview of the Requirements Coverage Matrix.
2. Review the matrix. Switching the Jurisdiction Profile re-evaluates the matrix client-side against the already-loaded extract - no refetch is needed, because the extract is jurisdiction-agnostic.
3. Complete the Organizational Attestations form: check the measures your organization has implemented and add optional notes. These entries are kept client-side and are not stored on the server; they exist only in the generated PDF.
4. Click GENERATE PDF. The PDF is built entirely in the browser (no server-side rendering). If the period or profile changed since the last preview, a fresh extract is fetched first so the audit trail records the correct parameters.

The downloaded file is named statewarden-audit-pack-{profile}-{from}-{to}.pdf.

What the PDF contains

• Cover: realm name, profile, report period, generation timestamp, generating user, system versions (WebAPI and per-version agent counts), the legal basis of the selected profile, and a disclaimer. The cover also carries an extract fingerprint: a SHA-256 hash over the canonicalized JSON evidence extract. The fingerprint can be recomputed against the source extract to verify integrity.
• 1. Requirements Coverage Matrix - see below.
• 2. Evidence Annexes (2.1–2.8): Backup & Disaster Recovery; Encryption; Access & Identity; Incidents & Response; Vulnerabilities & Monitoring; Infrastructure & Localization; Software Integrity; Change Audit Extract.
• 3. Organizational Attestations: the checked declarations and notes, printed as CUSTOMER DECLARATIONS with a signature block for the customer representative.
• 4. Recovery Demonstration Checklist: a final page for the live restore demonstration in front of the auditor, with fields for date, host, backup ID, method, and result. The report intentionally does not claim execution of disaster-recovery tests; performing and documenting the live demonstration remains a manual audit activity.

Long lists are capped. The server-side extract fetches one row beyond its limit and marks the section as truncated; the PDF states when a list is shown partially ("Server-side extract capped" or "List capped for print").

The Requirements Coverage Matrix

The matrix maps legal requirements to platform evidence. Twelve core requirements (R1–R12) cover the NIS2 Article 21(2)(a)–(j) measures, incident reporting readiness, and management responsibility; jurisdiction profiles add their own rows (Poland: P1–P6, Germany: D1–D4, France: F1–F3), such as physical security, registration duties, and informational supervision-regime entries. Each row shows the verbatim legal reference (never translated), an evidence summary computed from the extract, and a pointer to the annex containing the underlying data.

Every row receives one of three statuses:

• Evidenced (●): system evidence exists in the report period.
• Partial (◐): some evidence exists, but it is incomplete or must be complemented by a customer process. This is also the floor for computed rows when the period contains no relevant data - the matrix never reports "Evidenced" on absent data.
• Organizational (○): the measure cannot be evidenced by the platform (for example, training programs or physical security). These rows point to the CUSTOMER DECLARATIONS section.

The evaluation rules are deterministic and conservative. For example, the backup and disaster-recovery row (R3) reaches "Evidenced" only when at least one backup completed in the period, at least 80% of agent-capable devices are covered by an active backup policy, and more than half of the covered devices have a completed backup; the summary line reports the actual counts either way.

Backend and data provenance

The extract is produced by a single read-only backend operation that requires the realm.view_audit_logs permission; report generation itself is recorded in the audit log as described above. The extract is jurisdiction-agnostic: the selected profile does not change the underlying data; the profile is echoed in the report metadata and recorded in the audit log.

The extract aggregates these period-bounded sections: realm configuration (encryption mode, MFA policy, response policies, allowed regions), members, sessions, authentication events, change audit, device log summary, backup posture (fleet and per-device), backup policies, restore history, security posture (findings, scan coverage, scan history), infrastructure (storage nodes, regions, usage), and component versions (WebAPI and agent versions).

Data accuracy notes

Restore-outcome truthfulness depends on the agent version. Agents 1.7.0 and newer report partial restore failures accurately - a restore that failed for some disks is logged as failed, with the failed disks identified. On older agents, a partially failed restore could be logged as successful. Reports covering periods with pre-1.7.0 agents must be read with this limitation in mind; the cover lists the agent versions present in the fleet so the auditor can assess it.

Scope and limitations

The Audit Pack evidences technical controls that StateWarden operates or observes: backups, restores, encryption configuration, access control, MFA, monitoring, vulnerability handling, and the audit trail itself. Organizational measures - security policies, risk analysis documents, training programs, HR processes, physical security, vendor assessments - remain the customer's responsibility. They are represented in the report as Organizational (○) rows and are covered by the attestation checklist, which the customer signs as CUSTOMER DECLARATIONS.

The pack provides evidence to support your audit; it does not certify compliance. Your organization remains responsible for its own compliance posture, including the accuracy of the declarations made in the attestation section and the execution of the live recovery demonstration.