The initial point of a cyberattack may be a technical vulnerability, stolen credential, a compromised third-party application or a misconfigured cloud environment. However once discovered, the problem becomes technology much bigger than it first appeared.
Leaders will be confronted with several questions: What has occurred, who should be informed, what is to be reported, what can be disclosed, and what should be disclosed to customers, employees, regulators and business partners.
These decisions can impact beyond the scope of the incident.
As the breaches occur, a recent Expert Insights article published by The Hacker News has pointed out that the obligation to report a breach is growing more acknowledged than ever before, but there’s still a big disconnect between what’s happening inside organizations and what breaches can do. A total of 1,200 IT and cybersecurity experts were polled in France, Germany, Italy, Singapore, the United Kingdom and the United States. Fifty-five percent of the respondents who had been involved in a security incident or breach in the past year reported that they were told not to report the incident to the authorities when they felt that it should have been reported.
The question now before business leaders is whether the actual issue is always an attack or whether it’s often the response when an organization finds out it’s been attacked?
The answer increasingly points to both.
In addition to robust technical defenses, organizations must also have governance, leadership and communication processes to respond appropriately in the event of a defense failure.
With all of this, breach transparency is no longer just a public relations or regulatory issue. It continues to grow in significance as an organisational maturity and cyber-resilience signpost.
Why Breach Transparency Has Become a Strategic Cybersecurity Issue
For years, cybersecurity discussions have focused heavily on prevention.
Organizations have bought firewalls, endpoint security, identity protection, vulnerability management, security operations centers and threat intelligence. More recently, aspects of cloud security, zero-trust architecture, and AI-driven detection are crucial to cloud security.
These investments remain essential.
But no security strategy can assure an organization that they will never have an incident. The enterprise today is too interdependent.
Cloud platforms, SaaS applications, third-party applications, remote employees, APIs, digital ecosystems, and an even more complex technology landscape are essential for a business. If there is a weakness in that system, it can have repercussions that extend beyond the initial target.
This changes the definition of cybersecurity resilience.
A resilient organization is not a place that is able to block all the attacks. One that can help identify an incident, contain it, recover operations and communicate responsibly with those impacted by the incident.
That final component is often underestimated.
During an incident, stakeholders want answers from an organization. Consumers want to know if their info has been accessed. Staff should be aware if any protection measures are required and if passwords need to be changed. Regulators may call for notification. It may be necessary for business partners to evaluate individual exposure.
Boards and investors may also need to be aware of the operational and financial ramifications.
In other words, the incident quickly becomes a shared risk.
That is why transparency matters.
The Transparency Gap: Knowing What to Do Versus Actually Doing It
The information in the source article that is displayed shows a particularly salient tension.
Most of the cybersecurity community recognize that there are some incidents that must be reported. They are aware of regulatory needs and the need to communicate with stakeholders. However, the survey results show that a large number were told to maintain confidentiality when they felt it was the right thing to do to report the incident.
This means that it is not always a matter of not being aware of cybersecurity.
It may be a problem of organizational decision-making.
During a crisis, there can be multiple competing priorities.
Executives may worry about reputational damage. Legal teams may be concerned about liability. Security forces might want the investigation to be extended. Communications teams might wish to manage the message. Business owners could be concerned about the impact on customers and investors.
None of these concerns are inherently unreasonable.
The issue is that when you are trying to control the situation, you don’t always do it in an open and transparent way, and you don’t always make the decisions quickly enough. This is where cybersecurity governance is crucial.
A well-established organization should have a clear system in place regarding the specific information to be shared, with whom and by when. Those decisions shouldn’t be made up on the fly when a cyber incident is at its most critical stage.
Without such preparation, there is uncertainty. Uncertainty can give rise to delays.
Transparency Does Not Mean Revealing Everything
Organizations need to understand that there is a difference between breach transparency and transparency in the breach.
Transparency does not mean publishing all the technical aspects of a cyberattack.
While an investigation is underway, it may be dangerous to release information about vulnerabilities, security measures or defensive measures. It is possible that the attacker could have access to a system, the investigation could be ongoing, or the forensic team could be still working out the extent of the incident.
Sensitive information can be properly protected.
But while a “legitimate” confidentiality is not an “unnecessary” secrecy.
The goal should be to be transparent without taking any responsibility.
That’s when organisations should share information that is useful to the stakeholders and safeguard information that may pose a threat to security, investigations or law enforcement.
Customers don’t need to know exactly how a server is compromised, for instance. However, they might want to know if their personal information was impacted, when the incident happened and what they should do.
Employees may not require access to forensic reports. But they should be aware if they need to reset credentials or adhere to other security measures.
Regulators might require information that isn’t suitable for release to the public.
This implies the transparency needs to be tailored to the target audience.
The question isn’t:
Should we share all with everyone?
The real question is:
What information is needed for each stakeholder to be able to make an informed choice or protect themselves?
That is the essence of good communication with respect to breaches of responsibility.
What Organizations Often Get Wrong After a Cyber Incident
Waiting to find out everything
The biggest pitfall that many companies fall into is the desire for absolute proof before communicating. Unfortunately, cyber investigation often does not yield clarity right off the bat.
In the early hours or days of an incident, it is possible that the security team will not be able to tell how attackers got in. They might not have a complete awareness of data access. They could be trying to determine if there was any persistence by attackers.
Don’t wait for all the questions to be answered, it can cause unnecessary delay.
Instead, it is better to share what is known and make sure that what is being investigated is well understood.
For instance, an organization may claim that it has detected an incident, that it is working towards containment and that it is investigating the incident. It can communicate that the assessment is in progress and that they may have been impacted by some systems, but not by others, and that the full extent has yet to be determined.
This is not a case of compromise of credibility.
Many times, it enhances it.
In general, stakeholders are aware of the time needed for investigations. Uncertainty is not the problem; uncertainty is merely what is broken: the confidence that the information was deliberately withheld or that the organization was not being forthcoming.
Treating Cybersecurity Incidents as Purely Technical Events
One of the other common pitfalls is giving the security team too much responsibility for the whole event. A breach can start off as a technical incident and have organizational repercussions.
Security professionals delve into the attack. Legal teams determine responsibilities. Data Exposure is assessed by Privacy teams. Messaging is handled by Communications teams. Business leaders think about the effects on the business.
These functions can be disjointed if they are independent.
An incident can be referred to as a “security event” by one team.
It could also be called a “data breach”.
A third could tell customers that “no evidence of unauthorized access has been identified” even though the investigation is not over.
These variations can be insignificant but can cause confusion.
The incident response structure for a coordinated incident response provides everyone with the same verified facts.
In complex cloud services, incidents may span across several cloud service providers, platforms and third parties, making this especially relevant. Responsibility for investigating and reporting an incident may be distributed across the customer, cloud provider, managed service provider and technology vendors.
If there are unclear responsibilities, valuable time can be wasted as people struggle to identify who is responsible for communicating what.
Prioritizing Reputation Over Trust
Reputation management can be a good business problem.
Organizations often, however, fall into the trap of thinking that “the less said the better” will help preserve their reputation.
There can be risks associated with silence.
Customers aren’t automatically expecting that businesses are invulnerable when it comes to cyberattacks.
What they expect is good behavior when things go wrong.
If a company admits an incident, tells the truth about it, offers clear advice and takes action to remedy the situation, it will probably gain greater trust than one that denies the incident exists until it is brought to their attention by outside evidence.
It’s a key mindset change.
No longer a simple question:
Was there a breach at the company?
It is increasing:
“What did the company do when it found out about the breach?”
That is the focus of cybersecurity reputation.
Transparency and the Changing European Regulatory Environment
The need for transparency of breaches is especially significant for enterprises in the continent of Europe.
The regulatory landscape is increasingly moving towards cybersecurity risk management and incident reporting.
NIS2 has broadened the scope of cybersecurity obligations to a wider range of CIIs, and the EU Cyber Resilience Act adds cybersecurity obligations and vulnerability and incident reporting duties to the sectors of the manufacturers of products containing digital elements.
The EU also released common templates in May 2026 which will help to facilitate common incident reporting under NIS2.
These developments are indicative of a trend.
Cybersecurity incidents are becoming more of an organizational governance issue than a technical problem.
This is an opportunity for business leaders in Europe to take a step towards embedding incident reporting as part of their enterprise risk management.
This is especially true for organisations that are implementing digital transformation services projects. Digital transformation can bring in new cloud workloads, APIs, AI solutions, devices, and third-party integrations. These technologies offer benefits of efficiency and innovation but also impose new dependencies.
Security governance gaps can be left when a transformation program is conducted for just functionality and speed.
It is better to design in security, privacy, resilience and incident communication from the start of the transformation architecture.
What CISOs and Business Leaders Should Do Differently
The best approach to breach transparency is to be ready for a breach to happen.
The first step is to have a clear incident disclosure framework in place.
The framework should establish who is empowered to make disclosure decisions, which teams will engage and how the needs of regulation, the law, security and communications will be coordinated.
This should not be a document that lives in a compliance repository.
Should be tested.
Communication scenarios should be a part of the incident response exercises too.
The question of whether the security team can contain an attacker should not be the only one that a tabletop exercise addresses.
It should also ask:
- What happens if customers’ information has been accessed?
- Who contacts regulators?
- Who are the people who are communicating with employees?
- Who is authorized to make a public statement?
- What about if journalists find out about the incident ahead of the investigation?
- What about changing the facts post disclosure?
These scenarios highlight vulnerabilities which are not detectable during technical testing.
Additionally, there should be a simple communication discipline based on three principles, namely:
- What we know.
- What we don’t know.
- What we will be doing next.
The structure provides an opportunity for organisations to communicate openly without speculation.
It also provides an incentive for stakeholders to rely on future updates.
The Role of Cybersecurity Partners in Building Transparency
To enhance breach transparency, many organizations must work on the operating model for security more broadly.
That’s where external cybersecurity services can be helpful.
Don’t just rely on tools and threat detection. Don’t just rely on tools and threat detection. It should support organizations in setting up incident response processes, security monitoring, vulnerability management, as well as governance and regulatory readiness.
It is also important for organizations to evaluate if their technology partners can support the communication and escalation needs during an incident.
For instance, a managed security provider should have well-defined escalation processes.
The incident notification process must be clear and transparent with the Cloud partner.
In the event of a security incident impacting shared systems, the technology supplier needs to be very clear on their responsibilities.
Such relationships are especially relevant when companies are becoming more dependent on complex technology eco-systems.
Cybersecurity resiliency is not built without a single security product, the strongest organisations realize.
It is designed through a connected operating model that incorporates people, processes, technology and governance.
Conclusion: A Breach Tests Your Defenses. Transparency Tests Your Resilience.
The cybersecurity industry has spent years teaching organizations how to prevent, detect and contain attacks.
The next stage of maturity is learning how to communicate when those defenses fail.
The findings highlighted in the source article demonstrate that there can still be a significant gap between what cybersecurity professionals believe should happen after a breach and what organizations choose to do. That gap deserves attention because delayed or unnecessary secrecy can create additional risks at precisely the moment when clarity is most important.
The solution is not to disclose sensitive information recklessly.
It is to build a disciplined approach to responsible transparency.
Organizations need clear governance. They need cross-functional incident response. They need tested communication processes. They need security leaders who can escalate concerns without fear of being silenced. And they need business leaders who understand that protecting reputation does not always mean saying less.
In the years ahead, organizations will increasingly be judged not only by whether they can prevent cyberattacks, but by how they behave when prevention fails.
The strongest organizations will be those that can respond with speed, communicate with honesty and demonstrate meaningful improvement afterward.
Because ultimately, a breach tests your defenses but how you handle the truth tests your resilience.
