Fifty-eight % of security professionals have been told to keep a breach confidential when it was required to be reported. Every reporting deadline in Europe starts at a precise moment, and it is not the one you would expect. It is not in your logs. It is in a conversation that may never happen. So what would it cost somebody in your organization to tell you something you would rather not hear?
Have you ever been asked to keep an incident quiet? I am not talking about a cover-up, nothing as dramatic as that. Just handled internally, kept in the room, managed discreetly while somebody more senior decides how serious it really is. Have you ever watched an incident being logged as something smaller than it actually was, so that it would draw less attention than it deserved? Or sat in a meeting where somebody wondered aloud whether an event really met the reporting criteria, in a tone that made clear which answer was wanted?
If you have, you are in the majority.
Bitdefender’s 2025 Cybersecurity Assessment Report, based on 1,200 IT and security professionals, found that 58% had been told to keep a breach confidential even when it was required to be reported. Among C-level respondents, the figure was 69%. In the United Kingdom it was 58%, in Italy 53%, in Germany 48%. The figure is up 38% on 2023.
That was my first question. Here is the second. Without looking it up, just off the top of your head, how long do you have to report a significant incident under NIS2? Not roughly. Exactly. And from what moment does that period begin to run?
And my third question, and the one that should worry you most. If somebody on your team made a serious mistake with customer data this morning, would you know about it before lunch? Would they tell you at all? And how long could they keep that decision to themselves? A week? A month? Until the next audit?
One company already knows its answer, and it was longer than you would think.
A Year of Silence
On 4 November, 2016, Uber’s chief security officer testified under oath to a regulator about how the company protected its data. Ten days later, on 14 November, criminals emailed him to say they had taken the personal data of 57 million Uber users, including around 600,000 driver’s license numbers. Both dates are on the record in the US Department of Justice account of the case.
The chief security officer did not report it. Uber paid the criminals 100,000 dollars in bitcoin and had them sign non-disclosure agreements stating that no data had been taken. Yes, you read that right. And the breach became public a year later, on 21 November, 2017, when Uber’s new chief executive published a statement acknowledging “our failure to notify affected individuals or regulators last year.”
Then the regulators arrived. The Dutch data protection authority fined Uber 600,000 euros because “it did not report the data breach to the Dutch DPA and the data subjects within 72 hours after the discovery of the breach.” The UK Information Commissioner’s Office fined it 385,000 pounds over a breach affecting 2.7 million UK customers and 82,000 UK drivers.
The prosecutors came next. In October, 2022, a jury convicted the chief security officer of two federal crimes: obstructing a government investigation and hiding a crime he knew had been committed. The DOJ recorded what he had told a subordinate at the time. They “can’t let this get out.” The information needed to be “tightly controlled.” And outside the security group, the story was to be that “this investigation does not exist.”
If that sounds like old news, look at the dates. He appealed and lost: in March, 2025, a US federal appeals court upheld his conviction. He then asked the US Supreme Court to hear the case, and in June, 2026, it refused. The conviction is final. There is nothing left to appeal.
And before Uber, Joseph Sullivan spent eight years at the US Department of Justice. He was a prosecutor in the US Attorney’s Office for the Northern District of California and a founding member of its unit dedicated to technology crime. In December, 2001, that office named him as one of the Assistant US Attorneys prosecuting the first case ever brought under the Digital Millennium Copyright Act. More than twenty years later, the same office convicted him. Nobody understood these laws better than he did, and he broke them anyway. So if knowing the rules is not what makes somebody speak up, what is going to make the person on your team speak up tonight?
Now look at what actually failed. No sensor was missing, no control was absent, and nobody needed a better tool, a bigger budget, or a more mature framework. One person knew within hours, and the organization took a year to say so. Every euro and every pound of those fines was charged on the gap between knowing and telling.
So when should Uber have reported the breach? When did the clock start ticking exactly?
Your Deadline Does Not Start When You Think It Does
Here is the answer to my second question. Check it against whatever you had in mind.
NIS2 Article 23(4) requires an early warning “without undue delay and in any event within 24 hours of becoming aware of the significant incident,” and then a fuller notification within 72 hours. GDPR Article 33(1) requires notification “without undue delay and, where feasible, not later than 72 hours after having become aware of it.”
Look at the word “and” in both quotes. Each law asks for two things, not one. First, report as soon as you reasonably can. Second, never take longer than 24 or 72 hours, whatever your reason. Most of us know the numbers. Fewer know when they start counting. And almost nobody thinks about the first rule, which is the one that catches people. You can report at hour 70 and still be in breach, if you could have reported at hour 5.
Both clocks begin when your organization “becomes aware.” Not when the attack happens. Not when the log entry is written. Not when the SIEM correlates the alert. When your organization becomes aware.
The European Data Protection Board has been careful about what that means. In Guidelines 9/2022, a controller becomes aware when it “has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised.” You are allowed to have a short period of investigation first. But the same guidelines add a requirement that most organizations skip past: “the controller should, therefore, have internal processes in place to be able to detect and address a breach.”
In a December, 2020, decision against Twitter, the Irish Data Protection Commission put it more directly. Awareness “must be understood in the context of the broader obligation on a controller to ensure that it has appropriate measures in place to facilitate such ‘awareness’.”
Read that twice, because it is the whole argument. A regulator has told you that your awareness is your responsibility to construct. You cannot claim the clock never started because nobody told you, if the reason nobody told you is that you never built anything that would make them want to, or have to.
So your awareness is your responsibility, and your escalation procedure is written down, reviewed, and signed off. Both of those things are true at the same time. Neither of them tells you what happens at six in the evening on the Friday before a public holiday, when the person who would have escalated has already gone home. That is where the gap opens.
The Actual Gap in Your Breach Disclosure Process
Every breach disclosure process has a gap in it. The document is usually fine. The problem is the distance between what it says and what people do when nobody is watching.
The Irish Data Protection Commission measured one of those gaps and published it. It fined Twitter 450,000 euros for reporting a breach late and for failing to document it properly, and the decision itself records every step and the date each one happened.
A bug bounty report arrived on 26 December, 2018. A ticket was raised three days later. Then nothing, because “as a result of the winter holiday schedule the internal Twitter security team did not review the 29 December ticket… until 2 January, 2019.” Legal spotted the GDPR problem on 3 January. An incident ticket was opened on 4 January, and the Data Protection Officer was not added to it. The DPO finally heard about the breach on 7 January, “(orally) of the Breach during a Twitter Group weekly team meeting.”
Twelve days. That is how long it took for the news to reach the one person legally responsible for telling the regulator. He heard it in a weekly meeting, out loud.
The regulator’s explanation was one sentence. “‘5/Escalation to Legal’ was not followed as prescribed in the runbook, and resulted in a delay in notifying the Global DPO.” That “5/” is step five of Twitter’s own written procedure.
Every step in that chain was taken by somebody doing their job as they understood it. Nevertheless, a holiday schedule and one skipped step cost 450,000 euros.
Then Capita. In October, 2025, the UK’s data protection regulator (the Information Commissioner’s Office) fined the outsourcing group 14 million pounds over an incident affecting 6.6 million people, finding that “a high priority security alert was raised within ten minutes of the breach, but Capita took 58 hours to respond appropriately, against a target response time of one hour.”
Ten minutes to detect. Fifty-eight hours to act. In between lay more than two days in which Capita’s own systems had already flagged the problem and nobody had dealt with it.
That is the gap, and almost nothing measures it. We audit whether the monitoring exists. We audit whether the procedure exists. In many years of auditing management systems I have never once had to test a control that measures how long the alarm sat there before a person moved, because in the frameworks we certify against, there is not one.
Notice what Twitter and Capita have in common. Nobody was hiding anything. No career was at risk, no awkward conversation was being avoided, and nothing was at stake for any of the people in that chain. It broke anyway, on a holiday schedule and an unread alert.
Now picture the same chain on a Friday evening, with one person in it who knows that speaking up is going to cost them something.
The Friday Evening Problem
Let us put my first and third questions back together. Have you ever been asked to keep an incident quiet? And would somebody on your team tell you if they made a serious mistake with customer data?
One is silence handed down to you. The other is silence kept from you. Between them sits a position we have engineered for the security profession, and it is genuinely unreasonable. You are more likely than not to be asked at some point to stay quiet. And you have never been more personally exposed if you do.
Splunk’s CISO Report 2026, based on 650 CISOs across nine countries, found 78% concerned about being held personally liable for security incidents, up from 56% a year earlier. Under NIS2, Article 20(1) holds management bodies liable for infringements, and Article 32(5)(b) allows a competent authority to seek a temporary ban on an individual exercising managerial functions in an essential entity.
To be fair, far more people fear this than have ever been punished for it. I went looking for a European manager who has actually been banned or personally fined under NIS2. There is not one in the published record. And supervisory authorities do not have to publish their fines, so that is not proof that none exist. But there is a blunter reason the record is thin. On 8 July, 2026 the European Commission referred Ireland, Spain, France and the Netherlands to the Court of Justice for failing to transpose NIS2 into national law at all, more than twenty months after the deadline. The power exists on paper. In four member states, not even that. And none of it is comforting when you are the person holding the information on a Friday evening.
Now consider the person several levels below you, the one who clicked the thing, or used the tool they were told not to use, or copied the file somewhere convenient. They face the same calculation with none of your standing and none of your context. Research from Keeper Security found that 41% of cyber-attacks were never disclosed to internal leadership, and the reason given most often was fear of repercussion, at 43%.
And the law does nothing for them. NIS2 Article 23(1) provides that “the mere act of notification shall not subject the notifying entity to increased liability.” GDPR Article 83(2) requires supervisory authorities to weigh “the manner in which the infringement became known.” Both protect the organization in its dealings with the regulator. Neither protects an employee from their own employer, and neither stops an internal report from being used to decide who gets blamed.
So everyone in this chain is behaving rationally. The executive who keeps it contained and the analyst who says nothing are both doing the sensible thing, given what it would cost them not to. That is what makes this a design problem rather than a discipline problem. And that is the good news, because a design is something you can change.
What This Looks Like When It Works
Let me be clear about what I am not asking for. I am not asking you to go soft on genuine misconduct, or to forgive everything. The organizations that get this right are not more lenient than yours. They are better informed, and they are better informed because their people have stopped calculating.
You would notice the difference within a quarter, and not in your dashboards. You would notice it in how you find things out. Somebody comes to you on a Tuesday afternoon with something small and awkward, and they do it without rehearsing the sentence first. The alert that fires at ten minutes is answered in twenty, because the person who saw it was not wondering whose problem it was. Your Data Protection Officer learns about a breach from a ticket with their name on it, on the day it opens, rather than out loud in a weekly meeting twelve days later.
And when the notification does go to a regulator, it reads differently. It becomes a considered account of what happened and what you did about it, written by people who had time, instead of an explanation of why it took so long. Your incident log fills with things your people told you rather than things you eventually discovered. Your auditors stop asking careful questions about the gaps in it.
None of that requires anybody to be braver than they are today. It requires that telling you stops being the expensive option. Four changes will do most of the work.
Start This Week
All four of the suggestions below aim at a single moment: somebody in your organization is deciding whether to tell you something awkward. Each one makes it more likely that they will. Get that moment right and the deadlines look after themselves. Get it wrong and no framework will help you, because every framework you certify against quietly assumes that somebody spoke up.
- Write down where honest error ends and misconduct begins. Two sentences pinned to your intranet do more than a policy nobody opens: “Clicking a phishing link is not a disciplinary matter. Not telling us you clicked one is.” And be clear about which side of the line concealment sits on. The distinction that matters is not between large mistakes and small ones. It is between making a mistake and hiding one. An honest error made while doing the job is a process problem. Deciding not to mention it is not. Write down the consequences attached to each.
- Make reporting quicker than staying quiet. Capita gives you the benchmark and the warning in one line: a one-hour target response time, and 58 hours in practice. Do the same arithmetic on your own reporting route this week. Count the clicks from “I think I made a mistake” to “somebody has acknowledged it.” How many clicks does it take to say nothing? Zero. That is what you are competing with. Get it down to one channel, one step, and an acknowledgement the same day.
- Assume something has not reached you yet. Zero trust architecture begins by assuming an attacker is already inside rather than waiting for proof, and disclosure deserves the same posture. So stop asking whether anything is being withheld and go looking for it. Take your last ten incidents and write down how each one actually reached you. A colleague walked in. A tool fired. A customer complained. An outside researcher emailed. If most of them arrived from outside your organization, or through a corridor conversation rather than your official channel, then your reporting route is not what is finding your incidents, and whatever it is missing is still out there.
- Count how many incidents a person reported rather than a tool detected. At Uber a person knew within hours, and the tools never mattered. At Capita a tool knew within ten minutes, and no person acted for 58 hours. Tag last year’s incidents “human” or “tool,” and then look at how long each type took to reach somebody who could act. If your human column is nearly empty, resist reading that as proof your tools are excellent. It more likely means nobody is telling you anything.
Then hold one meeting. Invite security, HR, legal, and whoever owns incident response. Put this on the agenda. If somebody here made a serious mistake with customer data this morning, what exactly would happen to them for telling us? And would they have known that answer before they decided whether to tell us?
If the room cannot answer both questions quickly, and give the same answer, you have just found the reason your reporting deadlines are theoretical.
We secured the systems. We secured the process. We secured behavior, and then we started securing the AI agents. We never secured the ten seconds in which somebody decides whether to tell us about something we would rather not know. That is where your 24 hours begins. That is where your 72 hours begins. Not in the SIEM. Not in the runbook. In one person’s head, at the end of a long day, weighing what honesty is going to cost them.
Silence by design is still a design. Change it.
