Two organizations faced the same critical service outage. One spent the day in triage mode: Slack channels on fire, leadership demanding ETAs, teams scrambling to find the runbook. The other treated it like a drill they’d practiced the month before. Their failover plan kicked in. They stayed online.
The difference wasn’t luck. It was resilience.
This gap reveals the problem many GRC leaders face: their organizations conflate “we invested in security” with “we are resilient.” These aren’t the same—and increasingly, insurers, boards, and regulators know it.
The Strain of “IR 1.0”
Most organizations still operate in what I call Incident Response 1.0—the firefighting era. It’s highly reactive, overly manual, and often driven by compliance pressure rather than business continuity strategy. IR became a document we write for the auditor, not a capability we prove to the board.
This model is failing under modern pressure. Alert volume is overwhelming, environments are hybrid, identity is the new perimeter, and attackers are faster. A purely reactive posture forces improvisation at 3 AM—and improvised response doesn’t scale, can’t be measured, and doesn’t satisfy underwriters.
The core issue is conceptual. Security tries to prevent the breach. Resilience assumes the breach will happen and ensures the business survives it. When ransomware hits or a cloud provider fails, the question isn’t “did we prevent it?” but “can we continue operating?”
For GRC leaders, this distinction is critical. You can’t govern what you can’t measure, and you can’t insure what you can’t demonstrate.
The Incident Response 2.0 Framework
IR 2.0 is a strategic, living framework that moves organizations from reactive firefighting to measured resilience. As a GRC leader, you’re uniquely positioned to drive this transformation—it requires governance, not just technology. The framework has four interdependent pillars.
Pillar 1: Governance, Strategy & Measurement
This is where GRC takes the lead. Governance clarifies business risk and sets priorities. Strategy defines what to protect and in what order. Measurement proves the program works—not to IT, but to the board and the underwriter.
Use a simple maturity model to guide investment:
Crawl: Meet baseline requirements—MFA, EDR, tested backups, documented IR plan with at least one drill completed.
Walk: Track operational metrics—drill success rate, time to detect, time to contain. Can you actually execute what you documented?
Run: Demonstrate resilience under pressure—breach simulations, chaos exercises, scenario-based planning.
This pillar transforms IR from a technical checklist into a board-reportable program. It gives you the language to talk ROI with the CFO and coverage with the insurer. As GRC leaders, this is your territory—and your leverage.
Pillar 2: Architecture & Resiliency
Resilience isn’t “we bought disaster recovery.” It’s an architectural design. For most organizations, three foundational elements deliver the highest return:
Identity-first architecture (Zero Trust principles) so compromised credentials don’t become compromised infrastructure.
Network segmentation to limit blast radius and contain lateral movement.
Immutable, isolated backups so recovery is a certainty, not a hope.
This pillar is where you work with engineering to ensure security is built in, not bolted on. As a GRC function, your role is to set the standard—then validate it’s been met.
Pillar 3: Technology & Automation
This pillar turns alert noise into action. Modern IR programs normalize on what I call the “calm loop”: detect → decide → act → document. Technology—SOAR, EDR, identity platforms—makes this loop faster and more consistent.
A practical example: Ransomware behavior is detected. The endpoint is automatically isolated. User tokens are revoked. Forensic data is captured. An incident ticket is created with full context—all before a human analyst logs in. This moves mean time to contain from hours to seconds.
The GRC imperative here is governance of automation itself. What actions require human approval? What logging is needed for compliance? Who reviews automated actions post-incident? These are policy questions, not just technical ones—and they require your input.
Critical note: Automation should accelerate human judgment, not replace it—especially in actions affecting identity, access, or data.
Pillar 4: Culture & Evolution
This is where resilience becomes sustainable. IR 2.0 treats every incident as an input to a learning system:
Blameless post-incident reviews that ask “what process failed?” instead of “who failed?”
Regular playbook updates based on new threat intelligence and lessons learned.
Forward-looking scenario planning for emerging threats—AI-generated attacks, deepfakes, supply chain compromises.
From a GRC perspective, this pillar ensures your program doesn’t become static. It builds continuous improvement into the rhythm of the business, turning IR from a reactive function into a strategic one. Your role is to ensure these feedback loops exist and that leadership sees their output.
A Practical Path Forward: Crawl, Walk, Run
For GRC leaders guiding this transformation, the framework is stackable. You don’t need to implement everything at once.
Crawl (Insurable Baseline)
Establish the non-negotiables: MFA everywhere, EDR deployed, backups tested quarterly, IR plan documented and owned by a named executive. Most importantly, complete at least one tabletop exercise.
Here’s a practical shortcut: Request a cyber insurance application even if you’re not buying. Treat it like a free gap assessment. Every question you answer “no” to becomes a prioritized item on your remediation roadmap.
Walk (Proven Resilience)
Move from “documented” to “demonstrated.” Run quarterly drills with measurable outcomes. Build 1–2 automated playbooks (endpoint isolation + credential revocation are high-impact starting points). Track and report metrics: time to detect, time to contain, drill success rate.
At this stage, you’re building the evidence base that makes your program defensible to auditors, insurers, and the board.
Run (Evolved Model)
Now you can conduct live-fire exercises, integrate sector-specific threat intelligence, and tie IR metrics directly to business impact. This is where IR becomes part of enterprise risk management—not just IT’s problem.
GRC leaders at this level use IR data to inform broader risk conversations: vendor assessment, M&A due diligence, board reporting, and premium negotiation.
Why Insurability Belongs in Every GRC Conversation
Cyber insurers have seen every failure pattern: flat networks, untested backups, and IR plans that were never drilled. Their application questions aren’t arbitrary—they’re derived from loss data. Instead of viewing them as obstacles, use them as a roadmap.
When you can demonstrate a written, tested IR plan, regular simulations, offline backups, and measured containment capabilities, you’re not just checking boxes. You’re signaling maturity. You’re reducing premium pressure. You’re proving the organization can protect revenue when systems fail.
This is the strategic shift GRC leaders need to drive: IR 2.0 transforms incident response from a technical afterthought into a business resilience function. It becomes a competitive advantage, a board-level asset, and a quantifiable risk control.
The question is no longer whether your organization will face a serious incident. The question is whether you have the governance, architecture, and culture to survive it with operations, reputation, and insurability intact. That answer is in your hands.
AUTHOR BIO
Tiago Deretti is the Founder of Deretti Cyber Labs, an applied research initiative focused on “security-by-default” resilience. He serves as Director of Infrastructure & Engineering at HaystackID and is a member of the InfraGard National Members Alliance. He recently presented his “Incident Response 2.0” framework at InfoSec World.