regulatory-incident-reporting-clock

Use this as soon as triage flags any clock as yes or unknown, and re-run it each time the facts change. You get, in a new folder ./regulatory-incident-reporting-clock/, a running record of every reporting deadline, recipient and owner (<incident-id>-clock.md), and one draft notice per recipient, for a person to check and send (drafts/). This skill drafts for a human to review and sign; this skill never marks a control effective. Nothing is sent by the agent; the decision to notify and every submission belong to the named owners.

Inputs to gather

Read the triage record, the timeline, the processing records for affected systems, regulatory status notes, contracts with notification clauses and the insurance policy. Ask the reader, in one message: the awareness time and how it was established, what data and services are affected and for how many people or customers, in which countries, whether the company is controller or processor for that data, and whether it is an entity in NIS 2 scope, a financial entity under DORA, or a HIPAA covered entity or business associate.

Step 1: fix the facts that drive every clock

Write in UTC: detection time, awareness time with the reasoning, what is known and unknown, data categories and approximate counts, services and countries affected, whether the incident is ongoing. Deadlines run from awareness, not from the end of the investigation. Record also when anyone in the workforce first knew or, with reasonable diligence, would have known: HIPAA treats that as discovery (164.404(a)(2)), which can start the clock before the incident team's own awareness. Most regimes accept an initial notice with gaps filled later.

Step 2: test each regime that may apply

For each, record: applies, does not apply, or unclear, with the deciding fact.

• GDPR: a controller notifies the competent supervisory authority without undue delay and where feasible within 72 hours of awareness, unless the breach is unlikely to result in a risk to people (Art. 33); information may be given in phases (Art. 33(4)). Affected people are told without undue delay when the risk to them is high (Art. 34), unless an Art. 34(3) exception holds, such as data made unintelligible by encryption. A processor tells the controller without undue delay (Art. 33(2)). Every breach is documented internally, notified or not (Art. 33(5)).
• NIS 2: for a significant incident, an early warning within 24 hours of awareness, an incident notification within 72 hours, and a final report within one month of the notification, with intermediate reports on request (Art. 23); if the incident is still ongoing then, a progress report is due and the final report follows within one month of its handling ending. Service recipients may need to be told. Thresholds and the receiving body come from national transposition and, for some digital providers, an implementing regulation; check the member state law.
• DORA: a financial entity classifies ICT-related incidents against the criteria in Art. 18 and reports major ones to its competent authority (Art. 19), with initial, intermediate and final reports; clients are informed when their financial interests are affected. Content and time limits sit in the technical standards adopted under Art. 20; read the current text.
• HIPAA: for a breach of unsecured protected health information, individuals are notified without unreasonable delay and no later than 60 calendar days after discovery (45 CFR 164.404); HHS at the same time for 500 or more people, or in the annual log for fewer (164.408); media when more than 500 residents of a state or jurisdiction are affected (164.406); a business associate notifies the covered entity no later than 60 days after discovery (164.410). Encrypted data meeting HHS guidance is secured and not notifiable, and law enforcement may request a delay (164.412). A documented risk assessment can show a low probability of compromise (164.402).
• Contracts and others: customer processing agreements (often 24 to 72 hours, and stricter than the law for a processor: build that draft to the contract), insurance notice conditions, payment partners, sector regulators, and US state breach laws where residents are affected.

Step 3: build the clock table

In the clock record, one row per recipient, named exactly with its portal or address (the lead supervisory authority for cross-border processing, the CSIRT or authority named in national law): regime or contract, trigger met (yes, no, unclear), deadline in UTC and local time, owner, draft status, sent by (left blank for the human). Sort by deadline, earliest first. Treat unclear as yes for planning: prepare the draft, and let the owner decide not to send it.

Step 4: draft each notification

In drafts/, draft only facts: what happened, when, what data and services, approximate numbers, likely consequences, measures taken and planned, contact point. Separate known from not yet known. Leave out speculation, admissions of fault and promises; legal decides those. Draft a fixed form field by field. Add a plain-language notice for affected people if needed.

Step 5: record decisions not to notify

For every regime marked no, write the reasoning and the facts it rests on, with the decision maker's role and time. Re-run the whole table when facts change: a contained incident that turns out to involve personal data restarts the analysis.

What good looks like

• The clock record opens with the awareness time, the earliest deadline and its owner.
• A strong practitioner starts the GDPR and NIS 2 clocks in parallel and drafts an initial notice early, not after forensics.
• The common mistake is testing only one regime, usually privacy, and missing the contract clause or the sector regime with the shorter deadline.
• The tell: no awareness time, "not notifiable" without written reasoning, and drafts that guess at the attacker.

Framework lookups

If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-regulatory-incident-reporting-clock

Rules

• MUST record every time in UTC and state how the awareness time was established.
• MUST write the reasoning behind every decision not to notify.
• MUST write outputs only inside ./regulatory-incident-reporting-clock/ and ask before overwriting.
• NEVER submit, send or file any notification, or contact any authority, customer or person.
• NEVER present the analysis as legal advice; unclear results go to the person accountable for legal decisions.
• NEVER include personal data of affected individuals in drafts; use categories and counts.