Incident Reporting Navigator

Step 3 — Per-regime determination (per entity)

Work each candidate regime from its served text, for each entity holding a candidate role. Order within each regime: temporal applicability → scope → trigger test → duties.

• NIS2 (a directive — duties bind through national law): get_provision NIS2:art_2 (scope — including the size rules and the regardless-of-size inclusions it contains) with the sector annexes (search {query: "annex", frameworks: ["NIS2"]} and fetch the entries for the entity's sector) and NIS2:art_3 (essential vs important). NIS2:art_26 (jurisdiction and territoriality) decides WHICH member state's regime applies — fetch it for any multi-state or non-EU case. Then NIS2:art_23 — the significant-incident test, the staged reporting duties, the recipients (CSIRT or competent authority, per member-state choice), and the service-recipient notification duty. An implementing regulation further specifies the significant-incident test for an exact list of entity types — searchable as frameworks: ["NIS2_IR_TECHNICAL_REQUIREMENTS"]; fetch its scope article first and apply it only if the entity is one of its enumerated relevant entities, then fetch that provider type's own significant-incident provision. Applicability is completed by the national transposition (Step 4), which may be broader than the directive.
• GDPR: scope first — get_provision GDPR:art_2 (material) and GDPR:art_3 (territorial) — then GDPR:art_4 (the personal-data-breach definition; for cross-border cases also the Article 4(16) main-establishment definition and the facts it turns on). Then GDPR:art_33 (controller notification to the supervisory authority: the risk exception, the content, its clock from awareness; a processor's duty is to notify the controller) and GDPR:art_34 (communication to data subjects: the high-risk threshold, its exceptions, and its own timing standard — distinct from Article 33's). For competence fetch GDPR:art_55 AND GDPR:art_56 and apply their exceptions (local-only processing, public-authority processing) before naming a lead authority.
• DORA: get_provision DORA:art_2 — and apply its internal distinction: the incident-reporting duty in DORA:art_19 binds financial entities (the categories the article's scope list defines as such); an ICT third-party service provider is reached by parts of DORA but has no direct Article 19 duty unless it independently qualifies as a financial entity — its escalation duties to clients are contractual, report them separately. Then DORA:art_3 (definitions), DORA:art_18 (classification of incidents) plus the classification criteria in frameworks: ["DORA_RTS_INCIDENT_CLASS"] — apply those criteria, don't improvise "major". Then DORA:art_19 (staged reports and recipients) with reporting details in frameworks: ["DORA_RTS_INCIDENT_REPORTING"] and DORA:art_20 (templates). For the DORA/NIS2 relationship fetch DORA:art_1 (its sector-specific-act clause) and NIS2:art_4 (sector-specific Union acts) and apply them: displacement concerns covered financial entities and corresponding requirements — it does not erase NIS2 duties an entity has in a different capacity.
• CRA (product-side duties — they attach to economic-operator roles, not to the incident victim as such): temporal gate first — fetch CRA:art_71 (application dates; Article 14 applies from an earlier date than the main body) and the transitional provisions (CRA:art_69), and test applicability at each duty's own trigger time: Article 14's clock runs from the manufacturer's awareness, so a vulnerability exploited before the application date whose awareness comes after it is NOT excluded — only when the trigger moment itself precedes the application date is the duty reported as not yet applicable, with the served date. If applicable: scope (CRA:art_2) and the entity's capacity — CRA:art_3 (definitions, including the actively-exploited-vulnerability definition), CRA:art_21 (when importers/distributors are deemed manufacturers), CRA:art_24 (open-source stewards' distinct, lighter regime — including their limited Article 14 duties) — and state in which capacity each duty arises. Importers and distributors who are NOT deemed manufacturers still have their own information duties on identifying a vulnerability (CRA:art_19 / CRA:art_20) — report those separately. Then CRA:art_14: the staged notifications to the coordinating CSIRT and ENISA, and the user-information duty. If a CVE is involved (and the user consented to transmitting it): get_cve_details / check_kev_status, then apply the served definition explicitly — KEV presence and scores inform but never satisfy the test alone, and the KEV date is the catalog date-added, not an awareness timestamp. For full product-duty analysis use the companion skill cra-vulnerability-obligations.

Step 4 — Authority resolution, per member state

The receiving body differs per regime AND per member state. Resolve it as a chain — competence rule → designation provision → national designation → concrete name — from served law at every link, never from memory:

• National transposition rows: search {query: "CSIRT notification", sources: ["eu-cybersecurity"]} returns national implementation rows (e.g. Dutch Cyberbeveiligingswet articles annotated with the NIS2 article they transpose). Also search the member state's own corpus in its language (search {query: "meldplicht incident", jurisdictions: ["NL"]}, search {query: "Meldepflicht", jurisdictions: ["DE"]}) — national statutes name the receiving authority and any national deviations (which can be stricter than the directive floor).
• Verify the national instrument's status and dates (Ground rule 5) before relying on it — transposition corpora contain enacted-but-not- yet-in-force acts and their predecessors; check which governed the incident date, and if that cannot be established from served text, say so.
• Regime-specific chains: GDPR — Articles 55/56 with their exceptions give competence; the concrete authority name comes from national designation rows or stays unresolved. DORA — DORA:art_19 routes to the competent authority determined per DORA:art_46, which assigns each entity category to its sectoral supervisor; fetch it, follow the sectoral provision it cross-references for the entity's category, and then the national designation. CRA — the Article 14 rule (the manufacturer's main establishment, with the article's fallback hierarchy) selects the member state; the coordinating CSIRT's concrete identity comes from that state's CSIRT designation under its NIS2 transposition.
• Name the authority only from a fetched row. Otherwise report the authority class with the citation you do have, and mark the concrete name regulatory basis unresolved — never fill the gap from memory.

Step 5 — Output

Deliver:

1. The notification map — one row per entity × duty: Entity (alias) | Regime | Duty (incl. user/client communications) | In force for this incident? | Trigger test met? | Receiving body (as resolved) | Deadline as served + trigger event | Applied to this entity's timestamps | Citation (article + source URL).
2. Regimes ruled out in Step 3 — each with the fetched test it fails — and regimes not evaluated (sectoral regimes outside this skill).
3. The searches run, relaxed-match labels, and every regulatory basis unresolved / retrieval incomplete item, kept distinct.
4. A closing note that this is cited research support for professional review under time pressure, not legal advice — and that notification drafting is out of scope.

Verified call shapes

Verified against the live gateway on 2026-07-19:

{"tool": "search", "arguments": {"query": "major incident", "frameworks": ["DORA_RTS_INCIDENT_CLASS"], "limit": 5}}
{"tool": "search", "arguments": {"query": "significant incident", "frameworks": ["NIS2_IR_TECHNICAL_REQUIREMENTS"], "limit": 5}}
{"tool": "search", "arguments": {"query": "CSIRT notification", "sources": ["eu-cybersecurity"], "limit": 5}}
{"tool": "search", "arguments": {"query": "meldplicht incident", "jurisdictions": ["NL"], "limit": 5}}
{"tool": "get_provision", "arguments": {"canonical_ref": "NIS2:art_23", "jurisdiction": "EU"}}
{"tool": "check_kev_status", "arguments": {"cve_id": "CVE-2021-44228"}}

Pre-verified canonical_ref values (Ground rule 8 exception), all with jurisdiction: "EU": NIS2:art_2, NIS2:art_3, NIS2:art_4, NIS2:art_23, NIS2:art_26, GDPR:art_2, GDPR:art_3, GDPR:art_4, GDPR:art_33, GDPR:art_34, GDPR:art_55, GDPR:art_56, DORA:art_1, DORA:art_2, DORA:art_3, DORA:art_18, DORA:art_19, DORA:art_20, DORA:art_46, CRA:art_3, CRA:art_14, CRA:art_21, CRA:art_24, CRA:art_69, CRA:art_71.

Plan notes

Call get_my_capabilities once at the start to learn the connected plan and adapt. Everything this skill needs works on the Free plan (one jurisdiction-or-framework scope per search call, lower quotas — in an active incident, prioritise the regimes the screen marks as candidates). Paid plans add agency-guidance search, case-law fan-out inside search, and the compliance workflow catalog — this skill does not require them.

© Ansvar Systems AB. Skill text licensed CC BY 4.0. The legal text it fetches is served from official publishers (EUR-Lex under Commission Decision 2011/833/EU; national gazettes under their own terms) with per-row citations.