Why Your Incident Response Should Be Unique

The best incident response emerges from honest conversations about who you are, not from templates that assume all companies are the same.

A few weeks ago, we ran a new Discernible Experience on open-source supply chain incidents with teams in our subscriber community. We based it on real npm compromises from the past few months. We asked participants to analyze what went wrong with a hypothetical company’s communication and how it could build better communications infrastructure to prevent similar mistakes in the future. 

We didn't give anyone templates to fill out.

Instead, we asked them to map who owns which channels, identify which relationships need building, and sketch decision frameworks that align with how this company actually works.

Here's what surprised us: Even though we gave everyone the same fictional company to work with, three different teams produced three wildly different – and all completely valid – approaches to fixing its incident communications.

Why? Because they interpreted the company's culture, values, and priorities differently. Let me show you why that matters.

The Same Company, Three Different Interpretations

Everyone was working with DevFlow Technologies, an imaginary developer tools company powered by open source npm packages, serving enterprise customers and a community of 450,000+ developers. The company had just failed spectacularly at communicating about a supply chain compromise, including a 6-hour disclosure delay, a vague and unhelpful advisory, the wrong communication channels, the exclusion of volunteer maintainers, and angry customers.

The imaginary company profile included key details to help participants imagine themselves in the position of the Security Communications Lead:

• 850 employees
• $240M revenue
• “Trusted developer platform known for ease of use and security”
• Company values like “Developer Trust First” and “Security as a Feature”
• Serving both the open source community and enterprise customers
• Mix of volunteer maintainers and internal teams

We also gave them the same hypothetical feedback from key internal stakeholders to illustrate where communications broke down: 

CISO: “We treated this like an internal enterprise incident where we control information flow, but open source is fundamentally public. We can't control what the community discovers or discusses. We needed a decision framework that accepts this reality and optimizes for trust and usefulness, not information control. The 6-hour delay was trying to achieve certainty that was impossible in this context.”

Director of Open Source: “Open source community norms are: acknowledge fast, update frequently, be transparent about uncertainty, and show your work. We did the opposite: delayed acknowledgment, infrequent updates, hid uncertainty, and provided conclusions without analysis. We needed a decision framework based on open source norms, not enterprise security norms. We also should have treated maintainers as insider partners, not external parties.”

VP of Engineering: “My engineers were in an impossible position. They're active open source community members who saw friends and colleagues affected by our packages, but they had no guidance about what they could say. Some stayed silent and looked unresponsive; others shared information they probably shouldn't have. We needed clear, fast guidelines so they could be helpful within boundaries.”

VP of Customer Success: “Enterprise customers have contracts with security provisions, and we violated those by not proactively notifying them before public disclosure. They expect premium service and insider information, not learning from Hacker News. We needed to be integrated into incident response from minute one with authority to contact customers immediately, even if that means disclosing before a full public announcement.”

General Counsel: “I understand I slowed things down with legal review, but every public statement creates legal exposure. That said, I now realize that in open source incidents, delayed communication creates reputational and business risks that outweigh the incremental legal risk reduction. We also need a better understanding of what legal risks are actually material versus theoretical in open source contexts.”

VP of Product/Developer Relations: “We should have been monitoring community discussions and engaging in real-time, but we weren't integrated into incident response. By the time we realized misinformation was spreading, we didn't have approved messaging to correct it. We needed authority to engage with the community using pre-approved guidance, not wait for corporate communications clearance on every response.”

But despite having identical facts and context, when participants outlined what DevFlow should build before the next incident, their answers looked completely different because they brought different mental models about how companies like this actually work – here’s what we observed: 

Version 1: The Security-Focused Startup Interpretation

How this team saw DevFlow:

Reading the same company profile, this team interpreted DevFlow as operating more like a security-focused startup. They saw the “850 employees” and thought “mid-size, still growing, needs to move fast.” They read “Developer Trust First” and concluded speed and transparency were competitive advantages.

Their incident communication approach:

• When mapping channel ownership, they wrote things like: “Developer Relations team needs admin access NOW. Currently, only the CISO has it, and they were in back-to-back meetings during the incident.”
• For decision authority: “Security Communications Lead has authority to publish initial acknowledgment within 1 hour. Can escalate to CISO if needed, but the default is to disclose fast.”
• Their legal framework: “Schedule meeting to define what categories of technical info are pre-approved... We can't afford lengthy legal reviews on every communication.”

What their interpretation reveals:

• Several participants on this team have worked at startups or fast-moving companies where speed is a competitive advantage and bureaucracy is the enemy. When they saw DevFlow's values emphasizing “Developer Trust” and “Security as a Feature,” they interpreted that as “we need to move fast and be transparent to maintain trust.”
• Their infrastructure recommendations reflect startup realities: lean processes, clear empowerment, and minimal gatekeeping.

Version 2: The Enterprise Developer Tools Interpretation

How this team saw DevFlow:

Reading the same profile, this team saw “12,500+ companies” and “$240M revenue” and interpreted DevFlow as a maturing enterprise company with significant operational complexity. They read “trusted developer platform” and thought about contractual SLAs and customer expectations.

Their incident communication approach:

• When mapping channel ownership, they identified sophisticated needs such as “Need API integration with internal security tools for auto-publish capability” and “Need TweetDeck configured with security incident lists.” (Note: TweetDeck is now called “X Pro”)
• They created a three-tier customer system: “T1 customers (50) get immediate calls; T2 (200) get priority email; T3 get standard email.”
• Their coordination: “War room: Physical room + Zoom + #incident-war-room Slack for first 8 hours” with “90-minute sync cycles: Assess → Decide → Communicate → Monitor.”

What their interpretation reveals:

• This team has experience at larger companies where processes enable scale, and complexity requires structure. When they saw DevFlow had 12,500+ customers, they immediately thought about segmentation, SLAs, and different customer tiers with different expectations.
• Their infrastructure recommendations reflect enterprise realities: formal processes, clear SLAs, sophisticated systems that require resources to build and maintain.

Version 3: The Open Source-Native Interpretation

How this team saw DevFlow:

Reading the same profile, this team saw “community of 450,000+ developers” and interpreted DevFlow as fundamentally a community-first company that happens to have an enterprise business, not the other way around. They read “Developer Trust First” and thought about authentic community relationships.

Their incident communication approach:

• Primary communication channels: “Discord (12K members, highly engaged)... CRITICAL: This is the primary channel for initial disclosure to our community.”
• Employee communication: “Engineers and maintainers are empowered to engage authentically. Security Comms Lead provides core facts and technical accuracy, but individuals can use their own voice. We trust our people.”
• Decision authority: “Open Source team lead makes call, can disclose within 30 min without waiting for legal review... This is OUR community - we get to make this call.”
• Pre-incident agreements: “Company-wide acknowledgment that OSS = different rules... Document that this is our strategy and we accept the trade-offs.”

What their interpretation reveals:

• Individuals on this team worked at open source-native companies or were deeply involved in OSS communities. When they saw DevFlow's emphasis on developer trust and community, they interpreted the enterprise business as secondary to community relationships.
• Their infrastructure recommendations reflect OSS realities: radical transparency, individual empowerment, trust over control, and community channels over corporate communications.

Why Three Different Answers All Make Sense

All three interpretations are defensible given the company's profile.

DevFlow could legitimately operate as:

• A security-focused startup that moves fast and competes on transparency
• An enterprise developer tools company that balances community and customer obligations
• An open source-native company that prioritizes community relationships above all

The first team had seen startups fail because they moved too slowly and were too corporate. They brought that mental model to DevFlow.

The second team has seen companies struggle with complexity and customer segmentation. They brought that mental model to DevFlow.

The third team saw companies damage community trust by being too corporate. They brought that mental model to DevFlow.

None of them is wrong. They're just seeing different versions of what DevFlow could be – and the difference in values, priorities, and aspirations led each team to adopt a different approach to incident communications. 

This Is Why Templates Fail

Templates try to paper over these differences by giving everyone the same script:

• Step 1: Notify legal
• Step 2: Assess scope
• Step 3: Draft disclosure
• Step 4: Notify customers

But these steps assume everyone agrees on things like:

• How long should a legal review take, and how far beyond “legal advice” is this feedback helpful 
• What “assess scope” means operationally
• Who drafts and who approves disclosures, especially when disclosures to different stakeholders require different information
• Whether customers get notified before or after public disclosure

In reality, the startup-minded person thinks legal review should take no more than 15 minutes. The enterprise-minded person thinks it needs 2 hours. The OSS-minded person typically thinks legal shouldn't have veto power at all.

A template doesn't resolve this tension. It hides it until you're in the middle of an incident, when people are fighting over “step 2.”

What You Actually Need: Shared Values & Identity

After running this Discernible Experience, the most valuable outcome wasn't the specific infrastructure people identified. It was the realization that their day-to-day organizations probably have the same unspoken disagreements about:

• Who are we as a company?
• What do we optimize for?
• What are we willing to accept?

Templates can’t answer these questions. These are strategic choices about organizational values and identity.

Join Discernible Experiences, where we talk about the messy reality of coordinating incident response across people with different backgrounds, assumptions, and ideas about how companies should work.