What is Cyber Incident Reporting?

Cyber incident reporting, defined

Cyber incident reporting is the legal duty to tell a regulator, and sometimes affected individuals, when a security incident crosses a defined threshold. The rules set who you must notify, what counts as reportable and how fast you must move. Miss the deadline and the late report itself can be the offence, separate from the breach.

It used to be a niche concern for banks and hospitals. It is now a board problem for almost any organisation that holds data or runs essential services. The reason is simple. The number of reporting regimes has grown, the clocks have shortened to hours rather than days and several of them can apply to the same incident at once.

For a Swedish organisation the map is wider than it looks. European rules such as NIS2, GDPR and DORA sit alongside American ones such as the SEC rule, the HIPAA breach notification rule and CIRCIA, and a single supplier, customer or listing can pull you into any of them.

How a reporting obligation works

A cyber incident reporting obligation works the same way across every regime. An incident happens, you check it against that regime’s trigger, the clock starts the moment you become aware, not when the investigation ends, and you file in stages, starting with a fast early notification rather than a finished report.

Every regime follows the same shape, even where the wording differs. An incident happens, you work out whether it is reportable, a clock starts and you file in stages. Understanding that shape matters more than memorising any single rule.

The first decision is reportability. Each regime has its own trigger, such as a risk to people, a material impact on investors or a significant disruption to an essential service. If the incident meets the trigger, the duty switches on.

The second point is when the clock starts, and this is where most organisations go wrong. Under the European rules the clock starts when you become aware of the incident, not when your investigation is complete. You are expected to send a short early notification first and add the detail later.

The third is staging. A modern report is rarely one document. It is an early warning, then a fuller notification, then a final report once you understand the root cause. The initial step is a fast alert, not a finished account, so there is no reason to wait for certainty before starting it.

The main cyber incident reporting regimes

Six regimes carry most of the weight for a Swedish company with European and American exposure. Each one turns on three things, who it covers, who you report to and how fast. The clocks are the part people most often miss, so they are spelled out for each regime.

NIS2 incident reporting: 24-72-30 to MCF and the sector authority

Significant incidents at essential and important entities, reported to the national CSIRT and sector authority. In Sweden that is MCF (formerly MSB) and the sector regulator, under Cybersäkerhetslagen (SFS 2025:1506), in force since 15 January 2026. The cascade is an early warning within 24 hours, a full notification within 72 hours and a final report within a month (Article 23). See eBuilder’s full NIS2 guide for the compliance requirements beyond reporting.

GDPR breach reporting under Article 33

Personal data breaches, reported to the supervisory authority, which in Sweden is IMY. The deadline is without undue delay and, where feasible, within 72 hours of becoming aware (Article 33). Where the breach is likely to be a high risk to people, you must also tell the affected individuals (Article 34).

DORA incident reporting: the 4-hour clock

Major ICT-related incidents at financial entities, reported to the competent authority, which in Sweden is Finansinspektionen. The clock is the tightest in Europe, with an initial notification within 4 hours of classifying the incident as major and no later than 24 hours from awareness, an intermediate report within 72 hours and a final report within a month (Article 19 and Delegated Regulation (EU) 2025/301). DORA-regulated entities with systemic importance also face periodic threat-led penetration testing requirements, separate from the incident reporting duty.

SEC cyber reporting requirements: Form 8-K Item 1.05

Material cybersecurity incidents at US-listed companies, disclosed to investors on Form 8-K Item 1.05 within four business days of deciding the incident is material. The materiality call itself must be made without unreasonable delay. Companies also describe their cyber governance each year under Regulation S-K Item 106.

HIPAA breach notification rule

Breaches of unsecured health information at covered entities, reported to affected individuals and to the US Department of Health and Human Services under the HIPAA Breach Notification Rule. The limit is 60 calendar days from discovery. Breaches of 500 or more people also go to HHS at once and to the media, and smaller breaches are logged and reported annually.

CISA reporting under CIRCIA

Covered cyber incidents (within 72 hours) and ransomware payments (within 24 hours) at US critical-infrastructure entities, reported to CISA under CIRCIA, the Cyber Incident Reporting for Critical Infrastructure Act of 2022. These duties are set but not yet mandatory. CISA published a proposed rule in April 2024 and, after missing an earlier September 2026 target, submitted the final rule for White House (OMB) review on 1 October 2026, so reporting stays voluntary until the final rule takes effect.

Cyber incident reporting deadlines at a glance

The table below compares the initial, intermediate and final deadlines across all six regimes.

What getting it wrong costs

Getting cyber incident reporting wrong costs money, authority and trust. Expect administrative fines of up to €10 million or 2 percent of turnover under NIS2 and GDPR, personal liability for board members under NIS2 Article 20, a separate penalty for the late report itself, and reputational damage from a disclosure that lands late or reads as misleading.

The cost of a reporting failure is not one number. It lands in four separate ways, and a fine for the late report can arrive even when the security itself was reasonable.

Administrative fines are the headline. Under GDPR a notification failure sits in the lower tier, up to €10 million or 2 percent of global turnover, whichever is higher. NIS2 raises the stakes for essential entities to up to €10 million or 2 percent, and for important entities to up to €7 million or 1.4 percent.

Personal liability is the newer pressure. NIS2 makes the management body responsible for overseeing security measures, and supervisory authorities can hold board members personally accountable under Article 20, which is why board-level CISO advisory support on reporting ownership has become part of good governance. In the United States an Uber executive was criminally convicted for concealing a breach, so the risk is no longer only corporate.

The late report is its own offence. Regulators treat a missed deadline as a breach in itself, separate from the underlying incident, which is why a well-handled attack can still end in a fine. On top of that sits the investor and reputational damage when a public disclosure lands late or reads as misleading.

Real-world reporting failures

The clearest lessons come from organisations that had the incident under control and still paid, because they handled the reporting badly. Four cases, across three regimes, show the common failure points.

Uber: concealing a breach from the regulator

In 2016 attackers stole data on roughly 57 million Uber users and drivers, including about 600,000 US driver’s licence numbers. Uber’s then security chief learned of it ten days after testifying to the Federal Trade Commission about the company’s data practices.

Rather than report it, Uber paid the attackers $100,000 and recorded the payment as a bug bounty, with non-disclosure agreements. New management disclosed the breach to the regulator and the public a year later, in 2017.

The executive was convicted in 2022 of obstructing the FTC and concealing a felony, then sentenced the following year to probation and a fine, in what is thought to be the first criminal case against an executive over a breach. A defined duty to report, owned by someone who cannot be overruled into silence, is what this came down to. The payment was not the crime. The cover-up was.

Booking.com: twenty-two days too late

In December 2018 criminals used social engineering against staff at 40 hotels in the United Arab Emirates to reach the personal data of about 4,109 Booking.com customers. The company became aware on 13 January 2019.

It did not notify the Dutch regulator until 7 February, 22 days later and well outside the 72-hour window. The Dutch Data Protection Authority fined it €475,000, one of the largest fine issued for a late notification alone, and made clear the penalty was about the delay and not the security.

The lesson is where the clock starts. A credible signal of a breach is awareness, and the right move is to open a phased notification within 72 hours and fill in the detail as the investigation runs, rather than wait for a complete picture.

Presence Health: missing the sixty-day window

Paper schedules holding the health information of 836 people went missing from a US health provider. The breach was discovered on 22 October 2013, which started the 60-day HIPAA clock.

The provider did not notify the Office for Civil Rights until 31 January 2014, past the deadline. The $475,000 settlement in 2017 was the regulator’s first specifically for reporting late, and it came with a corrective action plan.

Treating the 60 days as a ceiling rather than a target is the fix here. The clock runs from discovery, not from the day the investigation ends, so a named owner has to be watching it from the moment the breach is found.

Unisys: calling a real breach hypothetical

After the 2020 SolarWinds compromise, the IT services firm Unisys described its cybersecurity risk to investors as hypothetical, even though it knew a threat actor had been in its systems and taken gigabytes of data.

The US Securities and Exchange Commission found the disclosures materially misleading and tied them in part to weak disclosure controls. Unisys settled in October 2024 for a $4 million penalty, without admitting or denying the findings.

What failed was the link between the people who knew the technical facts and the people writing the filing. A process that routes what the security team actually knows into the disclosure decision is what keeps a report accurate under pressure.

How the regimes overlap

The hardest part of reporting is not any single rule. It is that one incident can trigger several at once, each with its own authority, threshold and clock. Fragmentation, not any one deadline, is what catches organisations out.

Take a ransomware attack on a Swedish financial entity that also exposes customer data. It can be a major ICT incident under DORA, a personal data breach under GDPR and a significant incident under NIS2 at the same time, so three authorities expect three separate reports on three different clocks, the fastest running in hours.

The scale of this is easy to underestimate. In a 2023 report to Congress, the US Department of Homeland Security counted 52 cyber incident reporting requirements in effect or proposed across the federal government, 45 of them active across 22 agencies. That is one country’s federal layer alone, before any European or state rules are added.

The European Commission’s Digital Omnibus proposal, published in 2026, would ease exactly this problem with a single incident-reporting entry point across NIS2, DORA and GDPR, plus a proposed change to the GDPR notification deadline from 72 hours to 96 hours. Both are still proposals, not law, so the deadlines in the table above remain what you must meet today.

The practical answer is to map your obligations before an incident, not during one. Work out which regimes apply to your sector, data and markets, and keep that map current as the rules change. The European hubs are the place to begin, with pages for NIS2 compliance, GDPR compliance, DORA compliance and ISO 27001.

How to tell if an incident is reportable

An incident is reportable when it crosses the specific trigger your regime sets: a risk to people under GDPR, a major impact on a financial entity’s services under DORA, a significant incident under NIS2, or a material effect on investors under the SEC rule. When in doubt, treat a credible signal as the start of the clock.

Deciding whether an incident must be reported is genuinely hard, and the clock is usually already running while you decide. Each regime asks a different question, so the first job is to know which questions apply to you.

The thresholds do not line up. GDPR asks whether the breach is likely to be a risk to people. NIS2 asks whether the incident is significant for an essential or important service. DORA asks whether the ICT incident is major. The SEC asks whether the incident is material to investors. HIPAA asks whether unsecured health information was breached.

Because the triggers differ, the same incident can be reportable under one regime and not another, and a quick technical fix does not settle the question. A contained attack can still be material or still be a risk to people.

The honest caveat is that you will rarely have full certainty inside the deadline, and you are not meant to. A fast, documented and defensible decision beats a perfect one that arrives late. Record what you knew, when you knew it and why you judged it reportable or not, because that record is what a regulator will ask to see.

How to build a reporting-ready response

Reporting on time is a process you build before the incident, not a scramble during it. It runs on three things working together, people who know the duty, a process that starts the clock early and managed detection and response technology that gives you the facts fast.

Put the following in place now, in plain order of priority.

• Map your obligations in advance. List which regimes apply to your sector, data and markets, which authority each one points to and how long each clock is.
• Name an accountable owner for the reporting decision and the clock, with a deputy. Reporting fails when everyone assumes someone else is watching the time.
• Start the clock at awareness. Treat the first credible signal as the trigger and write down the date and time it started.
• Decide reportability with a documented method. Agree in advance how you judge risk, significance, materiality and major status, so the call is fast and defensible.
• Prepare notification templates for each authority, so you are filling in facts under pressure rather than drafting from scratch.
• Keep an incident log and preserve evidence from the first hour, as part of a rehearsed incident response plan. A clear record supports both the report and any later question about the delay.
• Rehearse against the tightest clock. Run a tabletop exercise on a 24-hour deadline, because if you can meet that you can meet the rest.
• Line up legal and communications before you need them, so disclosure, regulatory notice and customer messaging move together.

Do all of this and reporting on time becomes routine rather than a scramble. When an incident hits, you will already know who to tell, by when and how.