The Sawtooth Problem
Why the before/during/after incident communication model is broken, and what it looks like to treat security incidents as moments in an ongoing stakeholder relationship instead.
Pro Tip: Incidents are moments within ongoing relationships.
Nearly everywhere I look, I see the same outdated structure for incident communications: before, during, and after. It shows up in tabletop exercises, playbooks, and most of the conference talks on this topic. However, this structure implies something inherently inaccurate about where communication starts and ends – and thus, where it’s most valuable.
A before, during, and after framing is defined by the incident itself. Even the preparation work is typically centered on a single event, rather than treated as ongoing relationship maintenance that anticipates incidents along the way. I dislike frameworks that treat the incident as the center of gravity with everything else orbiting around it. In my work, I’m focused on relationships because a well-managed relationship keeps generating value between and during incidents.
Teams that organize their communication work around a temporary incident lifecycle tend to produce a sawtooth pattern with intense stakeholder engagements punctuated by silence until the next one. This is a problem for both internal and external communications, from executive updates to customer communications, because critical relationships aren’t really being sustained, but resuscitated in order to process bad news.
Keep in mind that authenticity is structural rather than tonal. It requires consistency across many moments over time. A single well-executed incident response, however transparent and well-run, can't manufacture the same relicient level of trust that only comes from a historical track record.
Data backs this up directly. Burson's 2026 Pulse study, a nationally representative survey of over 1,600 Americans, asked people what they actually want from companies. Unsurprisingly, Americans aren't asking for better content, more visibility, or a stronger executive presence online, though those can be useful vehicles. They're asking for three things that can't be faked, automated, or delegated:
- Honesty when the news is bad
- Integrity when no one is watching
- Genuine care for employees
Forty percent say they trust a company because its values are visible and consistent in everything it does, not just what it says. Forty percent want honesty and transparency even when the news is bad. Thirty-six percent want integrity, meaning leaders do what they say. Thirty-five percent want genuine care for the people who work there. None of those are things you can manufacture inside a single incident window. They're things that you either have been doing or haven't.
Additionally, the before/during/after framework treats each incident as a self-contained event, which unfortunately sets teams up to overinvest in the "during" phase and underinvest in everything else. You can’t compress a trust-building timeline into the limited hours of an active incident, no matter how good your messaging is. The incident can reveal character, as we've argued in What Could Go Right, but revealing character only works when there's an established pattern for the incident to be consistent with. Without that pattern, a well-handled incident just looks like a not-totally-fumbled incident. It doesn't compound into anything more.
Security Communication Is Not an Exception State
The before/during/after model also inherits an assumption I’ve repreatedly pushed back on: that security communication is episodic, something that gets activated when an incident occurs and stands down when it's resolved. That's the same logic that leads people to reach for "crisis" when they mean "incident." Not every incident is a crisis, and treating security communication as dormant until an incident forces it awake is a self-fulfilling prophecy because stakeholders who haven't heard from you since the last incident have no reason to trust your read now.
To the contrary, stakeholders reward proactive, non-incident engagement. Burson's study also found that 84% of Americans say companies that are transparent about risks before an incident are more credible than those that only start talking once something has gone wrong. Credibility, in other words, is priced in advance of the incident, not afterward. A team that only shows up once an incident forces the conversation is already facing a deficit. In fact, security is a topic of daily interest to your most important stakeholders, whether or not there's an active incident. Vulnerability disclosures, product reviews, policy changes, and near-misses that didn't escalate are all parts of an ongoing engagement strategy for various stakeholders.
I recommend replacing the lifecycle model with a compounding relationship model, which changes a few key things:
- First, the preparation phase stops being a set of tasks specific to an incident. Instead, it consists of the work you perform between incidents, such as routine updates and maintaining relationships with people who can assist or obstruct your progress. You should map your stakeholders regularly rather than waiting for a tabletop exercise to refresh that information. This work is a baseline requirement for effective daily operations.
- Second, the after phase stops focusing on closure. A post-incident debrief that produces a lessons-learned document nobody reads outside the security team isn't nurturing any relationships. The debrief should feed forward, such as: what did this incident teach you about a specific stakeholder's current beliefs, their tolerance for ambiguity, their reaction under pressure? That's relationship data, and it should influence how you manage that stakeholder going forward.
- Finally, your metrics change. Instead of asking how satisfied stakeholders were with your handling of one incident, ask how the relationship trajectory looks across several. One good incident response is a data point, while a pattern of them, sustained through the quiet periods in between, is the actual asset. That asset is what generates the political capital security teams need, and it’s much harder to build in the immediate hours after something goes wrong.