# Regulatory evidence & audit > DORA and NIS2 incident reporting: major-incident classification, reporting clocks with overdue alerts, ITS 2025/302 drafts and a hash-chained audit log. Source: https://wahukeza.com/platform/regulatory Prove · Regulatory evidence ## Classified, on the clock, drafted and recorded. Filed by you. When an incident is declared, the platform tests it against the DORA major-incident criteria and the NIS2 significance test, starts the reporting clocks, pre-fills each notification from the case and records when you filed it. Your board gets the yearly report DORA Art. 13 asks for, in English or Montenegrin, and your auditor gets a verifiable audit trail and an evidence pack. Part of Core Threat Intelligence, in every package. Classification ## DORA and NIS2, judged by rules you can read. The analyst answers the criteria on the incident; a deterministic classifier applies the thresholds of RTS 2024/1772 and returns Major or not major for DORA, and applies the two limbs of Art. 23(3) for NIS2 and returns Significant or not. The result names the criteria that triggered it. An analyst can override the outcome in either direction, and the override needs a written reason that is stored and shown. Montenegro’s Law on Information Security (Sl. list CG 113/2024) follows NIS2, so a tenant under it uses the NIS2 test with the Agency for Cyber Security as its authority. case #2291 · DORA assessmentMajor - Critical services affectedmet - Clients, counterparts, transactionsmet - Data lossesmet - Reputational impactnot met - Duration and downtimenot met - Geographical spreadnot met - Economic impactnot met Illustrative incident. Major: critical services affected and two further criteria met. The triggering criteria go straight into the notification draft. The clocks ## Every deadline visible before it is missed. A Major or Significant outcome creates the regime’s stages, each with a due time. Admins are alerted when a stage is at risk and again if it is overdue. Each later clock starts from the submission time you record, not from a guess. | regime | stage | due | | --- | --- | --- | | DORA | Initial notification | 4 h after classification, and no later than 24 h after detection | | DORA | Intermediate report | 72 h after the initial notification is filed | | DORA | Final report | 1 month after the intermediate report is filed | | NIS2 | Early warning | 24 h after detection | | NIS2 | Incident notification | 72 h after detection | | NIS2 | Final report | 1 month after the notification is filed | Each stage reads on track, at risk, breached or met. A regrade to not major marks unfiled stages not required and keeps what was filed. Notifications ## The template’s fields, pre-filled from the case. The filing stays yours. For DORA, each stage is a document keyed to the field numbers of ITS 2025/302 Annex I; for NIS2, a closed field set drawn from Art. 23(4). Fields the case can answer are pre-filled (detection and classification times, the criteria triggered, ATT&CK techniques, indicators, the root cause from the post-incident review) and never overwrite an analyst’s edit. Render it as PDF or HTML, file it through the authority’s own portal, then record the filing: the document is hashed and frozen, the authority’s reference is kept, and the next clock starts. A significant cyber threat under DORA Art. 19(2) gets its own notice on the same pattern. DORA · initial notification · draftITS 2025/302 Annex I 2.1 Incident reference case #2291 pre-filled 2.2 Detected 2026-11-03 07:12 pre-filled 2.3 Classified 2026-11-03 09:40 pre-filled 2.4 Description Reverse-proxy phishing of the e-banking login pre-filled 2.5 Criteria triggered critical services · clients · data losses pre-filled Illustrative draft. On “record submission”: authority, its reference and the time you filed; the document’s SHA-256 is frozen. The platform never sends it. Management-body report ## The reading DORA Art. 13 asks your board for, in its own language. - incidents ### Incidents and response Incidents by severity and type, median time to contain and to recover, SLA breaches, and the on-time rate of regulatory notifications. - detection ### What was seen Detections by severity and disposition, sensor activity with top tactics and techniques, exposure findings opened and resolved, phishing reports and verdicts, lookalikes and takedowns, adversary-emulation coverage. - recommendations ### Recommendations with their number Rule-based, never invented: an SLA breach rate above 20 %, a notification filed late, a Critical finding open for more than 30 days, each a sentence with the figure that triggered it. - en · cnr ### English and Montenegrin Every section opens with a sentence a board member can act on, then the tables. The language is chosen per schedule. - quarterly · annual ### Scheduled, not remembered Quarterly and annual schedules, run now when you need it, PDF by e-mail to up to ten recipients. - report identity ### Your name on it Each tenant sets its organisation name, logo, footer and default language; reports say “Prepared with Wahukeza” and nothing more. Tamper-evident audit log ## An audit trail an auditor can verify, not just read. Every audited action is a row in a SHA-256 hash chain, written under a lock so two writers can never fork it. Each day’s chain is closed by an Ed25519-signed anchor. The verifier walks the retained rows and anchors and reports exactly what it saw, including the first break if there is one. Exports in CSV or JSON carry the hashes, and the export itself is an audited event. An audit stream to your SIEM ships the same rows. Retention deletes old rows but never rewrites a hash, and anchors are kept. GET /api/audit/verify · last 90 daysintact { "rows": 48213, "intact": true, "firstBreakId": null, "anchorsChecked": 90, "anchorsSigned": 90 } Illustrative output. Without a signing key configured, anchors are written unsigned and the verifier says so. Auditor evidence pack ## One hashed export, mapped to the frameworks you are audited against. An admin builds the pack for a date range: configuration, identity, integrations, retention, report schedules, regulatory records, audit anchors with their verification, data-subject request counts and the playbook approval ledger, plus a controls map. Secret settings appear only as set or unset; endpoints only as scheme and host; people only as display names. The build is itself an audit row. evidence-pack.zip - settings.json - identity.json - integrations.json - retention.json - report-schedules.json - regulatory.json - audit-anchors.json - audit-verify.json - dsar.json - playbook-approvals.json - controls-map.json - manifest.json · SHA256SUMS | controls map | references | | --- | --- | | DORA | Arts. 5, 8, 9, 10, 13, 17, 19, 24, 28, 45 | | ISO/IEC 27001:2022 Annex A | 5.7, 5.19-5.22, 5.24-5.28, 5.33, 5.34, 8.7, 8.8, 8.15, 8.16, 8.20, 8.23 | | NIS2 | Art. 21(2) measures | | Your own references | e.g. central-bank decision clauses, added per tenant | Each capability and pack member is mapped to the articles and controls it evidences. It is a mapping for your auditor, not a certification. Data protection ## GDPR obligations, handled in the product. - records of processing ### Records of processing A records-of-processing document ships with the platform, with entries from sensor sessions to customer scam reports and page-canary hits. - retention ### Retention you set Retention per data class, swept on schedule, with the audit chain’s integrity preserved. - DSAR ### Data-subject requests Export and erasure by identifier; the reason for an erasure is recorded, and an export is logged against a hashed identifier, never the identifier itself. Read the [records of processing](https://wahukeza.com/legal/records-of-processing). Stated plainly ## What it does not do. Regulatory software that overstates itself becomes a finding of its own. - It does not file for you. The platform never sends a notification to a regulator. It drafts, renders and records; the analyst files through the authority’s portal. - It does not make you compliant. Classification, clocks, reports and the controls map are evidence for your compliance team and auditor. Sufficiency is their call. - No TLPT or TIBER-EU pack. Coverage-gap reports from adversary emulation are useful testing evidence; a threat-led penetration test is a separate engagement. - No ICT third-party register. The controls map names DORA Art. 28 where the platform contributes evidence; it is not a register of your ICT providers. - No Montenegrin national forms. The national notification forms are not built in; the NIS2 shape is used, with the authority configurable. - English interface. The application is in English. Reports and the public pages are also available in Montenegrin. Related ## Where this fits. - [For banks DORA, the Montenegrin law and customer fraud on one platform.](https://wahukeza.com/solutions/banks) - [For regulated industries What each regime asks for, and what you can show.](https://wahukeza.com/solutions/compliance) - [Cases, incidents & playbooks The incident the classification and clocks hang on.](https://wahukeza.com/platform/workflow) - [Records of processing What the platform processes, and on what basis.](https://wahukeza.com/legal/records-of-processing) ## Walk one incident through the clocks. Declare it, classify it, watch the stages appear, draft the initial notification and render the management-body report in Montenegrin, on a reference deployment, in one session. [Book a demo](https://wahukeza.com/contact?intent=demo) [Ask for a quote](https://wahukeza.com/contact?intent=quote)