Agile Incident Response: A Love Story Between Me, the Business, and Chaos

I worked in incident response, which means I lived at the intersection of “we need to be Agile” and “we are actively on fire.”

 

The business loves Agile. Loves it. Everything is a sprint. Everything is a ceremony. Everything needs a plan. I nod politely while wondering how to explain that attackers do not respect sprint planning, backlog grooming, or the fact that we already committed to other stories this sprint.

 

When an incident hits, I don’t say, “We’re breached.”

 

I say, “We have an unplanned work item with a very aggressive deadline.”

 

The business asks, “Can we schedule this for next sprint?”

 

The attacker already merged to production.

 

We try to be Agile about it. We really do. We create incident “stories.” We define acceptance criteria like “systems no longer compromised” and “no one is yelling on the bridge call.” We assign owners. We assign points. We pretend any of this is predictable.

 

Meanwhile, I’m arguing that incident response is inherently empirical. We don’t know what we don’t know until we know it. And by then, the scope has changed, the blast radius has doubled, and someone is asking for a timeline while the timeline is still happening.

 

The business wants certainty.

 

Security wants flexibility.

 

Agile is supposed to meet us in the middle, but most days it just hands me a sticky note and wishes me luck.

 

Here’s the part I’ve learned the hard way: Agile does work for incident response—but only if we stop pretending it’s about control. It’s about fast decisions, tight feedback loops, and trusting the people closest to the problem to act without asking for permission during a crisis.

 

So yes, let’s plan. Let’s retrospect. Let’s continuously improve.

 

Just don’t ask me to estimate chaos or commit to a breach-free sprint.

 

I’ll be Agile.

 

The incident won’t be. 

 

-3SC CISO