A new industry survey has surfaced an uncomfortable pattern. It is not about weak passwords or missed patches. It is about what happens after a breach is already discovered, and who decides whether anyone outside the organisation gets told.
Bitdefender’s 2026 Cybersecurity Assessment surveyed 1,200 IT and cyber security professionals across six countries and found that more than half of respondents who experienced a breach in the past twelve months were instructed to keep it confidential, even though they believed it should have been reported. In the United States, that figure rose to nearly seven in ten. Rather than a failure of technology, this represents a breakdown in corporate governance that persists within organisations regardless of their scale.
More than half of breached organisations were told to stay quiet
The finding is specific and repeated across multiple independent write-ups of the same report. Of the professionals who had personally experienced a breach, 55.2% said they were told to keep it confidential despite believing it met the threshold for notifying authorities or affected parties.
The report suggests this is far from an isolated incident. Instead, it highlights a systematic trend of internal pressure that overrides technical protocols, typically exerted once an incident has already been flagged and its implications are known.
Why this happens more often than businesses admit
Reporting a breach carries real short-term costs: reputational risk, client questions, regulatory scrutiny, and sometimes contractual exposure. Those pressures are real, and they explain why the instinct to stay quiet exists. But they do not remove the legal obligation.
Under UK GDPR, notifiable personal data breaches must be reported to the ICO within 72 hours of the organisation becoming aware of them, regardless of how uncomfortable that conversation is internally. A decision to delay or suppress that reporting does not sit with an individual IT professional. It becomes an organisational liability the moment it happens.
Dr Logic’s perspective
In Dr Logic’s experience, the businesses least prepared for this moment are not the ones without incident response plans on paper. They are the ones where the plan exists but was never tested against the pressure to keep things quiet. A response plan that only covers the technical steps, backups, isolation, and patching, without naming who has authority to decide on disclosure, leaves that decision to whoever is in the room when the pressure lands.
The Dr Logic team recommends building disclosure decision-making into the incident response plan itself, with named responsibility, before an incident happens rather than during one. That single addition removes the ambiguity that this survey suggests is being exploited, whether deliberately or through simple lack of clarity.
What this means for your business
If your incident response plan does not explicitly state who has the authority to decide on breach disclosure, and against what criteria, that is a gap worth closing now. It costs nothing to define, and it removes the single point of pressure this report suggests is being applied across the industry.
This is also a conversation worth having at leadership level, not just within IT. A breach disclosure decision made under pressure, without a documented process behind it, is far harder to defend later, both to regulators and to clients.
