The evidence bundle: what an auditor gets
One hash-stamped JSON object covering NIS2, DORA, GDPR and the EU AI Act. What is in each section, how the integrity hash is verified, and what it does not claim.
An external auditor does not want a guided tour of fifteen REST endpoints, and a customer's security team does not want screenshots. Both want one document that answers a specific question: what did your platform look like during the window I am reviewing, and can I prove the document has not been edited since you gave it to me.
The evidence bundle is that document. It is a single JSON object, assembled on demand, covering four regulatory frameworks plus the audit chain, and stamped with a hash that can be verified independently of the service that produced it.
The shape of the bundle
One object, with a fixed set of top-level fields. The framework sections are present or absent depending on what you asked for and what loaded.
organization_id the tenant the bundle describes
generated_at when assembly ran (UTC)
window_from start of the review window
window_to end of the review window
nis2 control conformity report for the window
dora vendor register and concentration view
gdpr records of processing activities, and DPIA entries
ai_act registered AI systems and their risk class
audit_chain per-framework hash-chain verification result
frameworks which sections were requested, sorted
integrity_hash sha256 over the canonical form of everything above| Section | Contents | The question it answers |
|---|---|---|
| NIS2 | The ten-control conformity report over the window: per control, the evidence count, a status of compliant, partial or missing, and a checked-at timestamp. | Which of the Article 21(2) measures can you evidence, and how much evidence sits behind each one? |
| DORA | The ICT third-party vendor register, plus a concentration view over it. | Who are your ICT providers, and where is your dependency concentrated? |
| GDPR | Records of processing activities and data protection impact assessment entries as they stood at report time. | What personal data do you process, on what basis, and which processing did you assess as high risk? |
| EU AI Act | Registered AI systems with their risk class, capabilities, oversight facts and data-handling statements. | What AI is in use, what class did you assign it, and what human control sits over it? |
| Audit chain | Whether each framework's hash chain verifies, as a boolean per framework. | Has anything in the compliance record been altered since it was written? |
The default review window is 30 days, which is the window the incident-style sections are computed over. A longer window is a parameter, not a different product; if a regulator is reviewing a quarter, set the window to the quarter.
The integrity hash, and what stamping adds
The integrity_hash is a SHA-256 over the canonical form of the payload, computed with the hash field itself excluded. It covers exactly what the reviewer sees. Editing a single character of the JSON after issue produces a hash that no longer matches.
On its own a hash inside a document proves nothing, because whoever edited the document could recompute it. Stamping is the step that closes that gap. Stamping writes the hash into the compliance audit chain as an entry under the framework evidence_bundle with the action evidence.bundle.generated, carrying the frameworks included and the window, and returns a receipt with the stamp identifier, the hash, the frameworks and the generation timestamp.
The consequence is the one that matters to an auditor. A reviewer holding a bundle they received off-platform — by email, on a memory stick, attached to a procurement questionnaire — can have the chain re-walked and confirm that a row exists with that hash and the expected linkage, recorded at issue time. The verification does not depend on the bundle they were sent, and it does not depend on the live service being reachable at the moment they ask.
The same hash-chaining mechanism protects the underlying record. Every privileged action produces a hash-chained audit row, and chain verification does not merely report that something is wrong: it locates the exact broken sequence number, so a dispute about tampering has a specific row to argue about rather than a general suspicion.
Framework selection is opt-in
Frameworks are requested as a set, and an empty set means all of them. A NIS2-only bundle, or a NIS2 and DORA bundle, can be produced for one regulator's review window without exporting the sections they did not ask about.
Use that. A bundle contains the AI Act risk class and the names of tables holding personal data, and handing a supervisory authority four frameworks when they asked about one is oversharing you cannot retract. Select the sections that match the request. The frameworks field then tells the reviewer precisely which sections were in scope at issue time, so a deliberately narrow bundle does not look like a bundle with something missing.
Why gaps are emitted rather than hidden
There is a limitation in the current version that you should be able to state accurately if asked. Section-level load errors are tolerated so that a transient outage in one framework's data store does not block the whole export. The effect is that a section which is empty and a section whose query failed are not currently distinguishable from each other. Per-section status fields are the right answer to that and are not in this version. If a reviewer needs certainty about a specific empty section, regenerate the bundle and see whether it stays empty.
The AI system card, and the claim we do not make
The AI Act section carries the system card. Every statement in it is derived from configuration rather than asserted in text, so that the card cannot drift away from what the running system does. The system is named Qorionix Security Copilot. Its risk class is limited, and the card reports that class with the status "self-assessed; pending legal review against Annex III" — because Annex III has no cybersecurity carve-out, and a system that recommends and executes security actions plausibly falls within it. That status is published rather than quietly omitted.
The oversight facts are: a human in the loop; a described audit trail covering both the conversational path and agentic triage decisions with their evidence citations and verification outcomes; that any action step marked as high blast radius requires human approval before execution; and that grant-class privileged actions are not exposed to the model at all, so they cannot be requested however the model is prompted.
The data-handling statements are the ones a customer questionnaire asks about. No tenant data is used for training. Message retention follows your organisation's configured retention period. And the third one is the reason this section exists in an honest form:
Region of the configured model endpoint. Cloud providers may route inference outside the endpoint's region; where the provider does not offer a regional inference guarantee this is reported as unverified.
Producing a bundle
Choose the frameworks and the window
Framework toggles select the sections. Set the window to the period the reviewer actually asked about rather than accepting the 30-day default out of habit.
Generate
Assembly is synchronous and produces a summary card: the window, the integrity hash, a presence badge per framework, and the hash-chain verification status. Read the presence badges before you send anything — an unexpectedly absent section is a question you want to answer before the auditor asks it.
Stamp the integrity hash
This writes the hash into the compliance audit chain and returns the receipt inline. Do this before the bundle leaves your organisation; a bundle that was never stamped can be verified against nothing.
Download the JSON and send it with the receipt
Two clicks produce a hash-stamped JSON. Auditors want the raw JSON rather than a rendered PDF, because they ingest it into their own tooling. Keep the receipt alongside your copy so you can demonstrate which bundle you issued and when.
What the bundle is not
- It is not a certificate, and it does not make your organisation compliant. No product can. It produces the evidence your NIS2 audit asks for, in the shape an auditor expects, with a verifiable chain of custody. The conclusion remains the auditor's and the obligation remains your management body's.
- A
compliantstatus on a control is a statement about evidence, not about adequacy. It means the control's evidence query returned at least the minimum number of rows. Whether that evidence is sufficient for your risk profile is a judgement no query makes. - A thin DORA section is not necessarily a gap. DORA applies to EU financial-sector entities and their ICT providers. If you are neither, that section being sparse is the correct outcome — see How findings map to DORA and ISO 27001.
- It does not redact. Select frameworks deliberately, because there is no per-export redaction layer in this version.
- It is a live snapshot, not a historical archive. The control evaluation reflects the state at the moment you generated it. If you need a point-in-time record, the stamped bundle you issued is that record — keep it.
What to read next
- NIS2: what your management is personally responsible for — the control catalogue, the reporting clock and the Article 20 duty.
- GDPR: subject requests, export and erasure — what the export contains and what erasure removes.
- How findings map to DORA and ISO 27001 — for answering a questionnaire that speaks Annex A.