DORA · Binding since 17 January 2025 · NIS2 transposing

Operational-resilience evidence, without exposing the data.

zkRune is the cryptographic evidence layer for financial entities and ICT third-party providers under DORA Regulation (EU) 2022/2554, with parallel coverage for NIS2 (Directive (EU) 2022/2555). Each incident, attestation, and continuity-test record becomes a tamper-evident proof — re-verifiable by an ESA, a national CSIRT, or your internal audit, without exposing the underlying operational or customer data.

Book a 30-minute session See the DORA mapping

Outside DORA / NIS2 scope? See the full regulations matrix (AI Act, MiCA, eIDAS 2.0, DSA, UK OSA, GDPR).

The opportunity

DORA wants detailed reporting. GDPR demands data minimisation. Supervisors want re-verifiable evidence. The three pull against each other — until you ship the evidence as a proof.

Most financial entities address DORA by retaining detailed incident logs, vendor records, and TLPT findings — creating both a GDPR proportionality liability and a security exposure. zkRune lets you commit the salient facts as cryptographic proofs, retain the underlying operational data only as long as you need it, and still hand a supervisor a re-verifiable chain.

What DORA + NIS2 demand

• Structured incident reporting to ESAs / national authorities
• Registers of ICT third-party providers with attestations
• Threat-led penetration testing every 3 years (TLPT)
• Resilience-testing programme with periodicity evidence
• Supervisor-grade auditability for at least 5 years

What zkRune contributes underneath

• Tamper-evident incident proofs (hash-preimage)
• On-chain anchored vendor registers (membership-proof)
• Attestation chains for TLPT findings (signature-verification)
• Cryptographic wait-period enforcement (patience-proof)
• Compact 5-year archive (~1 MB per entity)

We are not a GRC platform. ServiceNow, Archer, and OneTrust handle workflow and policy orchestration. zkRune is the cryptographic primitive underneath — the bit that lets you commit evidence today and re-verify it five years from now without retaining the underlying personal or operational data.

Who we serve

Three categories with overlapping but distinct evidence obligations.

In-scope financial entities

Banks, payment institutions, e-money issuers, investment firms, AIFMs, UCITS managers, insurance and reinsurance undertakings, CCPs, CSDs, trade repositories, credit rating agencies

DORA Art. 17 incident reporting requires evidence that an event happened, was contained, and was disclosed — across a supervisory chain that includes the entity, its CSIRT, and the European Supervisory Authorities. zkRune binds each step to a tamper-evident proof so the supervisor can independently re-verify the timeline without touching the underlying operational data.

ICT third-party service providers

Cloud providers (AWS, Azure, GCP financial-services regions), SaaS vendors, managed-detection-and-response (MDR) firms, banking-as-a-service platforms, payment-tech providers

DORA Art. 28–30 makes you a registered ICT third-party provider with structured attestation obligations toward your in-scope customers. zkRune lets you issue signed attestations of compliance state (patch cadence, access reviews, sub-contractor screening) that customers and their supervisors verify cryptographically — without you exposing your internal infrastructure detail.

NIS2-adjacent critical infrastructure

Operators of essential services in energy, transport, banking, financial market infrastructure, health, drinking water, digital infrastructure, public administration, space

NIS2 (Directive (EU) 2022/2555) creates parallel obligations to DORA for non-financial critical entities. Same cryptographic evidence pattern applies: incident proofs, vendor attestations, and continuity-test records that supervisory authorities verify against on-chain commitments rather than retained personal data.

DORA mapping

Five DORA and NIS2 evidence flows, mapped to circuits you can integrate today.

References are to Regulation (EU) 2022/2554 and Directive (EU) 2022/2555. Mapping is informational; consult your CISO and competent authority for certification-grade claims.

Article

Art. 17 — ICT-related incident management

Financial entities must classify, manage, and report major ICT-related incidents to competent authorities through a structured initial / intermediate / final reporting flow.

zkRune circuit

hash-preimage · patience-proof · signature-verification

Notes

Each report step is committed as a cryptographic proof: detection timestamp, classification, mitigation milestone, final disclosure. Patience-proof binds wait-period requirements (e.g. continuous monitoring duration). Supervisors re-verify the chain without seeing raw operational data.

Article

Art. 18 — Threat-led penetration testing (TLPT)

Larger financial entities must perform threat-led penetration tests at least every three years, with detailed findings shared with competent authorities.

zkRune circuit

credential-proof · signature-verification

Notes

TLPT findings can be committed as a hashed report with attestations from the testing provider, the entity's CISO, and an external attester. The supervisor verifies the chain of attestations without requiring distribution of the sensitive findings themselves.

Article

Art. 28–30 — ICT third-party risk

Financial entities must maintain a register of ICT third-party providers, contractually require operational-resilience standards, and demonstrate active monitoring of critical providers.

zkRune circuit

membership-proof · signature-verification

Notes

Vendors join a Merkle-anchored register; each contractual milestone (sub-contractor change, patch attestation, BCP rehearsal) becomes an on-chain proof. The 'register of ICT providers' becomes cryptographically inspectable by supervisors without requiring vendor-by-vendor disclosure to other customers.

Article

Art. 24 — Operational resilience testing programme

Entities must maintain a comprehensive testing programme covering vulnerability assessments, network security testing, gap analyses, and end-to-end testing of ICT systems.

zkRune circuit

patience-proof · hash-preimage

Notes

Periodicity and completion of each test type committed cryptographically. Patience-proof enforces minimum intervals between tests; hash-preimage commits findings so post-hoc tampering is detectable.

Article

NIS2 Art. 23 — Incident reporting (adjacent)

Essential and important entities must report significant incidents to national CSIRTs through early-warning / incident notification / final report stages.

zkRune circuit

hash-preimage · patience-proof · signature-verification

Notes

Same pattern as DORA Art. 17, applied to NIS2's three-stage reporting flow. Member-state CSIRTs can re-verify proofs against the same on-chain anchors used by financial supervisors.

Readiness

Production cryptography. Audit roadmap honestly disclosed.

Audited circuits

14 production Groth16 circuits

Hash-preimage, patience-proof, signature-verification, and membership-proof together cover the cryptographic primitives DORA reporting flows depend on.

Proof generation

0.4–5 seconds

Suitable for per-event commitment at scale. Incident-class proofs typically run sub-second; full TLPT-grade attestation chains complete in seconds.

Proof size

~200 bytes

Compact enough to retain a five-year supervisory archive of incident-reporting proofs in under 1 MB per entity. Storage cost is not the constraint; trustworthy retention is.

Mainnet anchors

Solana · Base · Sui

ESAs, national CSIRTs, and your own internal audit can independently re-verify any proof against the on-chain key — no dependency on the entity or zkRune as a vendor.

Licence

MIT / Apache-2.0

Open source by default. Compatible with internal procurement reviews and the supervisor's preference for auditable supply chains. No vendor lock-in.

Audit

Q3–Q4 2026 (planned)

Third-party security audit scheduled. Honest disclosure of current posture at /trust — including what we have not yet proved.

What zkRune deliberately does not do

The list below is what your existing GRC, SIEM, and red-team vendors already handle. zkRune slots underneath as the cryptographic-evidence primitive — not as a replacement for the orchestration layer you already trust.

×GRC platforms or workflow tooling (ServiceNow, Archer, OneTrust handle that)
×SIEM / detection engineering (Splunk, Sentinel, Elastic, Datadog)
×Threat-led penetration testing services (you keep your existing red team)
×Continuity-of-operations or business-continuity planning
×Supervisory reporting submission UIs (national authority portals)

Mainnet anchors

Verification keys on three independent chains.

European Supervisory Authorities, national CSIRTs, and your internal audit can independently re-verify any proof against the on-chain key — no dependency on the entity or zkRune as a vendor.

Base

0xa03A353d890033aC9b3044776440C2a4c9E849EA

View on explorer ↗

Solana

9apA5U8YywgTHXQqpbvUMHJej7yorHcN56cewKfkX7ad

View on explorer ↗

Sui

0x278301424c954dcfdb6e46407728964271fbfff3dc1d4fae5b799c7e977bd4c5

View on explorer ↗

Evaluating zkRune for a DORA or NIS2 evidence flow?

We work directly with CISOs, operational-resilience leads, and third-party-risk teams at in-scope financial entities and their ICT providers. The fastest path is a 30-minute technical session with the OpenAPI spec and trust documentation ready to forward to your security team.

Email resilience@Download OpenAPI spec

zkruneprotocol@gmail.com · @rune_zk on X · github.com/louisstein94/zkrune