This is also where disclosure becomes a resilience metric, not just a compliance task. Boards should ask whether the organisation can produce decision-grade customer guidance inside the first day of a major event, even before root cause is settled. If not, the weakness is often upstream: fragmented telemetry, unclear asset ownership, poor service dependency mapping, or contracts that promise more precision than incident response can realistically deliver.
A useful test for IT leaders is to run tabletop exercises around ambiguous scenarios rather than catastrophic ones. Practice the moments when indicators are suggestive but not conclusive, when legal obligations vary by region, or when customers may need to take disruptive action before the organisation is fully certain. That is where disclosure frameworks usually fail.
One practical takeaway: treat customer notification content as part of security engineering. Prebuild message templates tied to likely incident types, required customer actions, confidence levels and update cadence. That turns disclosure from an ad hoc executive debate into a repeatable response capability.
If you’ve been a CISO long enough, you’ve probably learned the same lesson I have: The hardest part of incident response often isn’t detection, containment or eradication. It’s deciding when and how to tell customers what’s going on, especially when the facts are still emerging.
Disclose a cybersecurity incident too early, and you risk being wrong, creating unnecessary disruption or boxing your legal team into a corner. Disclose too late, and you may deprive customers of the time and information they need to protect themselves and meet their own disclosure obligations.
The worst time to create your notification philosophy is during an incident, when certainty doesn’t exist. This work should be done in advance, in collaboration with key stakeholders across the leadership team.
Context shapes incident disclosure decisions
Your priorities will not be the same as mine. At Zscaler, we process roughly 500 billion transactions a day to block attacks and enforce our customers’ policies. We don’t store customers’ content as many platforms do, but we do handle sensitive data and operational signals to deliver the service. That shapes how I think about when and how to communicate during a cyber event.
Your reality is likely to be different: the data you hold, the promises you’ve made to customers and third parties, your jurisdictions, your industry, your business model, your size and maturity, and whether you’re public or private. That all shapes decisions about when you notify customers, what you can say and what you must say.
But here are three broad priority truths I think most CISOs recognize, even if we don’t always say them out loud:
-
Human safety comes first.
-
Law comes before contract.
-
Protecting customers comes before protecting shareholder value.
Five CISO principles for incident disclosure
We should move away from asking whether we notify, and instead ask what customers need to do their job. In the first 24 to 72 hours of an incident, you may have hypotheses, partial telemetry and a messy timeline, but you will rarely have a clean story.
Meanwhile, your customer is probably running their own war room, trying to answer questions like: Do we need to take action right now? Are we at risk? What can I credibly tell my CEO, board or regulators? Customers understand you can’t speak with absolute certainty, but they do need quality information they can act on.
With this context in mind, I’ll share five CISO-to-CISO principles for deciding when (and how) to tell customers:
-
Make decisions in peacetime. Agree ahead of time on triggers, decision rights, escalation paths and who can send customer communications. If you don’t, your priority order becomes whatever is loudest in the room when pressure spikes.
-
Let harm reduction — not a narrative — drive timing. Don’t wait for perfect attribution or root cause. If customers can materially reduce risk by acting, timeliness beats a polished story. That action might include patching, changing credentials, monitoring for indicators, or temporarily changing how they use your service.
-
Treat legal reality as a forcing function. This is where “law before contract” becomes practical. Regulatory and cross-border obligations can force earlier decisions than the business would naturally choose. Bring legal in from the start, not as a brakes-only function, but as a partner in accurate, defensible, useful communication.
-
Don’t make the customer’s trade-offs for them. Customers optimize for different missions. Response options can create real customer impact, including forcing resets, disabling integrations, shutting down features, or rotating keys. So, give them decision-quality information and let them choose in their own context.
-
Be disciplined and humane, and build a cadence. Overconfident sentences cause irreversible damage. Lead with tight facts, clear caveats, specific actions, and predictable updates. Always pair professionalism with empathy; it reduces confusion, escalation, and mistrust.
Why this matters beyond cybersecurity
As CISOs, incident notification is governance under time pressure. You can’t expect great outcomes if you haven’t done the alignment work early, including priorities, thresholds, decision rights, escalation paths and rehearsal.
The fog of battle is guaranteed. The only question is whether you walk into it with a shared operating model across security, legal, comms and business leaders, or try to invent a model while the incident is already unfolding.
What’s your customer notification strategy during incidents? Share it with [email protected].
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.