Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

When do we…

When do we have to notify a regulator, and under which regime?

8 decision pointsThe pack behind this answer: Security Incident Management

Add to board memo

The short answer

Recommendation
Screen every declared incident against NIS2, DORA and the GDPR within 4 hours of declaration, the pack's default, starting from an applicability profile made before any incident. Record one outcome for each regime, and treat a decision still unsettled at the doubt point as reportable.
Reasoning
Each regime has its own test and its own clock, and every clock that runs from awareness starts before anyone decides. NIS2 needs an essential or important entity and a significant incident. DORA needs a financial entity and a major incident. The GDPR needs a personal data breach that is not unlikely to result in a risk to individuals. A report made on incomplete facts can be updated or withdrawn; a missed deadline cannot be undone, so doubt resolves towards reporting.
Considerations
  • The first deadlines differ: the NIS2 early warning within 24 hours of awareness, and the GDPR notification without undue delay and, where feasible, within 72 hours of awareness.
  • The DORA initial notification is due within 4 hours of classifying the incident as major and no later than 24 hours after awareness. Classified as major more than 24 hours after awareness, it is due within 4 hours of that classification.
  • The 4-hour screen and the 6-hour doubt point are the pack's defaults. National law may shorten a clock or add a report, and contracts, your cyber insurer and the police can need notices on their own terms.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back
StartAn incident has been declaredStepStart from your applicability profileStepScreen every reporting duty within 4 hoursDecisionNIS2: are we in scope, and is the incident significant?StepNIS2: early warning within 24 hours of awarenessDecisionDORA: are we a financial entity, and is the incident major?StepDORA: initial notification within 4 hours of classifyingDecisionGDPR: is personal data affected?DecisionAre we the controller of this data?StepTell the controller without undue delayDecisionWhat is the risk to the people concerned?StepRecord it in the breach record; no notificationStepNotify the supervisory authority within 72 hoursStepCheck contracts, the insurer and a crime reportStepRecord one of four outcomes for each regimeDecisionIs any decision Not settled?StepSettle it before the doubt point, or treat it as ReportableDecisionIs any decision Reportable, or treated as Reportable?DecisionHas a fact changed, or has an update fallen due?OutcomeReport on time, with what is knownOutcomeNo report due: keep the decisions and their reasons

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 21 steps.

  1. Start

    An incident has been declared

    Every legal clock in the pack runs from awareness: the time the incident is declared, as recorded in the case log, unless the record shows reasonable certainty earlier, in which case the earlier time. A team leader told on Friday and a declaration on Monday means the clock started on Friday. Record the declaration time at once. The clocks do not wait for the reportability decision.

    In the pack

  2. Step

    Start from your applicability profile

    Make the profile before any incident, so the screen does not start by asking whether NIS2 applies to you at all. For NIS2, DORA and GDPR it records whether each can apply, in which role, which authority receives each report and through which channel, and any shorter clock or extra report national law sets. In the pack, executive management approves it, and it is reviewed at least once a year and whenever your status, services or authorities change. A regime it rules out is recorded as Not applicable, with the profile as the reason.

    In the pack

  3. Step

    Screen every reporting duty within 4 hours

    Ask all three legal questions every time, then the contract, insurance and law-enforcement questions. Keep asking them even if you think you are out of scope: the pack notes that a wrong assumption about status is how deadlines are missed. The 4 hours is the pack's default, and the pack warns never to set a screen time that leaves too little of a legal clock. Record what is known and mark each unknown with who is finding it out. Decide on what is known; do not wait for the investigation.

    In the pack

  4. Decision

    NIS2: are we in scope, and is the incident significant?

    In scope means an essential or important entity. Significant means it has caused, or could cause, severe operational disruption or financial loss to you, or considerable damage to others. The pack turns that into indicators: a service stopped or able to stop beyond your threshold, a loss above your severe threshold, considerable damage to others, an attacker with admin access or spreading malware, or recurrence. Any one met is enough. If unclear, take the yes branch. A financial entity that is also in NIS2 scope answers the DORA question instead.

    In the pack

  5. Step

    NIS2: early warning within 24 hours of awareness

    Send the early warning to the CSIRT or competent authority within 24 hours of awareness, then the incident notification within 72 hours. An intermediate report follows if the authority asks, and a final report within one month of the notification. Where appropriate, also tell the recipients of your services whose service is likely to be adversely affected, without undue delay.

    In the pack

  6. Decision

    DORA: are we a financial entity, and is the incident major?

    DORA applies to financial entities only. Major needs both: critical services affected, and either a successful, malicious and unauthorised access that may result in data losses, or two or more of the other thresholds (clients and transactions, reputation, duration and downtime, geographical spread, data losses, economic impact). Without critical services affected nothing is major. Record the time you classify it as major, because a clock starts there. If you are a financial entity and have not yet classified it, take the yes branch and classify it now.

    In the pack

  7. Step

    DORA: initial notification within 4 hours of classifying

    Notify the financial competent authority within 4 hours of classifying the incident as major, and no later than 24 hours after awareness: the earlier wins. If you classify it as major more than 24 hours after awareness, it is due within 4 hours of that classification. The intermediate report is due within 72 hours of the initial notification, and again when regular activities are recovered. The final report is due no later than one month after the latest intermediate report. Tell clients whose financial interests are affected without undue delay.

    In the pack

  8. Decision

    GDPR: is personal data affected?

    Affected means its confidentiality, integrity or availability: data disclosed or reached, altered, or lost or made unavailable, even for a time. It needs no attacker. If no personal data was at stake, record Not applicable. If it was at stake and the logs prove nothing was read, altered or lost, record Not reportable with that evidence. If you cannot yet rule it out, take the yes branch and bring in the Data Protection Officer.

    In the pack

    See also

  9. Decision

    Are we the controller of this data?

    The controller decides why and how the data is processed and carries the duty to notify. A processor handles data for another organisation. Your applicability profile says which role you hold for which data. If a processor of yours had the breach, you are still the controller, and your clock starts when you become aware, usually when it tells you. If you are not sure of your role, take the controller branch: it is the more cautious reading.

    In the pack

  10. Step

    Tell the controller without undue delay

    As the processor, tell the controller what the notification needs, as far as known, without first assessing the risk, and keep it updated. The pack's default limit is 24 hours. The controller decides whether to notify. Do not notify the authority or the people concerned on its behalf unless the contract says so. Your own other duties, such as NIS2 or a contract notice, still run.

    In the pack

  11. Decision

    What is the risk to the people concerned?

    The risk is to the people whose data it is, not to the organisation. The Data Protection Officer weighs the data's sensitivity, volume, how easily people can be identified, the consequences, vulnerable people, protection and whether containment worked. It is a judgement, not a score. When in doubt between two levels, the pack chooses the higher and records why.

    In the pack

  12. Step

    Record it in the breach record; no notification

    A breach unlikely to result in a risk to individuals is not notified, but it still goes in the breach record with the facts, effects, assessment and the reason. The decision not to notify is made and recorded inside the 72 hours. The authority may ask to see the record for breaches that were not notified.

    In the pack

  13. Step

    Notify the supervisory authority within 72 hours

    Notify the lead supervisory authority without undue delay and, where feasible, within 72 hours of awareness; the 72 hours is the outer limit, not a target, and a later notification still goes, with reasons for the delay. Where not everything is known in time, notify with what is known and add the rest later. For a high risk, also tell the people concerned without undue delay, unless one of the conditions the playbook lists applies.

    In the pack

  14. Step

    Check contracts, the insurer and a crime report

    These have no legal clock: the contract, the policy or the police sets it. Customers with a notification clause get notice as each contract requires. The cyber insurer is told as the policy requires; the pack's placeholder notes this is often within 48 hours. Suspected crime, including ransomware and fraud, is reported as soon as practical. In the pack neither the insurer's notice nor the crime report waits for the investigation to finish.

    In the pack

  15. Step

    Record one of four outcomes for each regime

    Reportable: the test is met and the clocks run. Not reportable: the regime applies and the test is not met. Not applicable: the regime cannot apply to you, or not to this incident. Not settled: a fact the test needs is still unknown. Each line names the indicators or thresholds met or not, the facts relied on, who decided and when, within the 4 hours, whether or not a report is made. In the pack every decision to report is the executive incident lead's, as is a decision not to report a Severity 1 or 2 incident.

    In the pack

  16. Decision

    Is any decision Not settled?

    A test that turns on an unknown fact is Not settled, for example whether data was taken in a ransomware attack. Do not wait for the investigation to decide. Record it as Not settled with the time it will be revisited. Seek legal advice where a test is unclear, but never wait for it past the doubt point.

    In the pack

  17. Step

    Settle it before the doubt point, or treat it as Reportable

    Set the revisit before the doubt point: 6 hours before that regime's first deadline, the pack's default. If it is still not settled then, it is treated as Reportable: make the report by the deadline on the facts known, saying the assessment is continuing. A report can be updated or withdrawn; a missed deadline cannot be undone. For an incident declared at 09:00, the NIS2 doubt point falls at 03:00 the next day and the GDPR one 66 hours after awareness.

    In the pack

    See also

  18. Decision

    Is any decision Reportable, or treated as Reportable?

    The screen can find several reports due at once, each to its own recipient on its own clock. Enter every due time in your log and in the calendars of whoever drafts and submits each report. In a Severity 1 incident the crisis team asks at every meeting which reports are due, to whom and by when.

    In the pack

  19. Decision

    Has a fact changed, or has an update fallen due?

    Every decision short of Reportable is revisited at each update and at once when a fact changes, with the result recorded even when unchanged. Record a revisit as a new line that replaces the old; the first line stays. If a new fact meets a test, that regime's clocks start when the record shows the fact was known, and the decision is made at once. Severity is also reviewed at every update.

    In the pack

  20. Outcome

    Report on time, with what is known

    The executive incident lead decides on reports to authorities, on the incident manager's screen; the Data Protection Officer advises on GDPR reports. A report is never held back to avoid a deadline. Send what is known on time and follow up: the early warning and the initial notification are meant to be incomplete. Keep revisiting any regime not yet Reportable. An exception to your policy never moves a legal deadline.

    In the pack

    See also

  21. Outcome

    No report due: keep the decisions and their reasons

    A recorded decision for every regime, with its reasons, is the evidence that each duty was considered, including every decision not to report. Write reasons that can be tested: name the indicator, threshold or factor and the fact that met it or did not. Keep the breach record for any personal data breach, notified or not. The post-incident review lists every duty screened out, with its reason.

    In the pack

Practical checklist

  1. Start from the applicability profile, and record any regime it rules out as Not applicable.
  2. Record the time of awareness: the declaration, or earlier where the record shows reasonable certainty earlier.
  3. Ask the NIS2, DORA and GDPR questions on the facts known, then the contract, insurer and crime-report questions.
  4. Record one outcome per regime within 4 hours of declaration, with the facts relied on, who decided and when.
  5. Give each Not settled decision a revisit time before the doubt point, and treat it as Reportable if it is still unsettled then.
  6. Enter every due time in the log and in the calendars of whoever drafts and submits each report.
  7. Revisit every decision short of Reportable at each update and at once when a fact changes.

Evidence to have ready

  • The applicability profile in force on the day, with the role and authority for each regime.
  • One decision line per regime: outcome, indicators or thresholds met or not, facts relied on, who decided and when.
  • The case log showing the screen completed within 4 hours of declaration.
  • Every revisit of each decision, including those that changed nothing.
  • The breach record for every personal data breach, notified or not.

Assumptions

  • You operate in the EU and have named your authorities: the CSIRT or competent authority, the lead supervisory authority and, for a financial entity, the financial competent authority. The pack leaves them as placeholders because national law decides them. Confirm them, and their forms, with counsel.
  • The 4-hour screen and the 6-hour doubt point are the pack's defaults, and your own policy may set others, as long as they leave enough of the legal clocks. The legal deadlines shown are the ones the pack's matrix states. This is not legal advice.
  • The pack's NIS2 indicators are calibrated by you with counsel and your national authority's guidance. Where the law or an authority sets a threshold, the law or the authority wins.
  • Sector rules can add their own breach duties, for example for electronic communications, health or payment services. The pack does not list them.

Not covered here