Cyber Defense Matrix 2.0 · Function · RS
RESPOND(RS)
Incident management, analysis, mitigation, and communication. The column whose value shows up only during incidents.
RESPOND is the NIST CSF 2.0 function that covers the work done after a confirmed incident: incident management (RS.MA), incident analysis (RS.AN), mitigation (RS.MI), and incident communication (RS.CO). It is the column whose value is easiest to misestimate — it looks underused on calm quarters and irreplaceable during an actual incident.
The line between DETECT and RESPOND
Most practitioners draw the line at 'confirmed incident.' Up to that point the work is detection and triage — is this real? — and it belongs in DETECT. Once the answer is yes, the work moves into RESPOND: scoping the blast radius, coordinating the response team, executing containment, documenting the timeline, notifying stakeholders. Tools and processes that span the transition (SOAR, most notably) legitimately sit in both columns.
The distinction matters because the skills, tools, and metrics are different. DETECT metrics are about signal quality: MTTD, precision, recall, alert-to-investigation ratio. RESPOND metrics are about execution: MTTR, containment time, analyst hours per incident, post-incident action-item completion rate. Organizations that lump them together tend to starve the weaker side.
Tools that live in RESPOND
SOAR platforms (Palo Alto XSOAR, Splunk SOAR, Tines, Torq, Swimlane) — the canonical RESPOND tool category, automating the repetitive parts of incident handling and enforcing runbook consistency. Case management and ticketing (ServiceNow SecOps, Jira, TheHive). Endpoint isolation (EDR live response), network containment (firewall APIs, NAC), identity containment (session revocation, credential rotation). Communication tooling for incident coordination (Slack/Teams plus purpose-built tools like FireHydrant, Kintaba, Rootly).
Commercial incident-response retainers (Mandiant, Unit 42, CrowdStrike Services, Arctic Wolf) and cyber-insurance DFIR firms also sit in RESPOND, usually as surge capacity rather than daily tools. Retainers are worth the spend if and only if the internal team can hand off cleanly when activated — a poorly prepared internal team often loses time re-explaining the environment to the retained firm.
Common coverage gaps in RESPOND
The most common gap is written-but-never-tested runbooks. Organizations produce incident-response plans that read well and have never been exercised against a real scenario. The test is specific: pick one attack pattern, walk through the runbook in a tabletop, and count how many steps fail or require improvisation. Above 30% improvisation, the plan is theatrical.
The second gap is communication. Security-adjacent teams (legal, HR, communications, executive leadership) often learn their role in incident response during the first real incident. A mature program runs at least one tabletop per year that includes non-security stakeholders. The matrix will show RESPOND coverage based on tool deployment; the program's actual readiness requires cross-functional muscle memory the matrix cannot capture.
The third gap is post-incident review. Incidents that do not generate documented action items with owners and due dates produce no durable improvement. The action-item close rate is the honest measure of program maturity — declared-closed is a lower bar than it sounds and should be tracked with evidence.
RESPOND × asset-row considerations
RESPOND × Devices is the most mature cell in most programs — EDR tooling gives analysts the isolation and forensic capabilities to move quickly. RESPOND × Users is equally mature given modern IdP capabilities. RESPOND × Networks depends heavily on whether network containment is scripted or requires vendor tickets. RESPOND × Data is usually weak: recovering from data-exposure incidents often depends on backup infrastructure that is owned outside the security team.
In the extension rows: RESPOND × Cloud is strong where cloud-native tooling is present (AWS Detective, Azure Sentinel playbooks). RESPOND × OT/IoT is usually absent — the operational constraints of industrial environments make conventional containment unsafe. RESPOND × Supply Chain is inherently partial; you cannot isolate a third party's environment, only revoke your integrations with it.
Frequently asked
Do we need a SOAR platform?
Above ~25 incidents per week, yes — the automation ROI exceeds the operational overhead. Below that volume, the ROI is weaker and simpler automation (scripts, ChatOps bots) often wins. The wrong move is deploying SOAR before an incident-management process exists; the platform amplifies whatever process it automates, including the broken parts.
Is a retainer worth the cost?
Yes, under two conditions: (1) you do not have a mature internal DFIR team, and (2) you have practiced the activation process with the retained firm at least once. Retainers without activation rehearsal are expensive insurance that loses hours at the moment they matter.
Where does ransomware response fit?
RESPOND is the immediate work: isolation, forensics, stakeholder comms, ransom negotiation (or not). RECOVER is the restoration work: recovering from backup, validating data integrity, resuming operations. A ransomware event typically consumes both columns sequentially.
Should we involve law enforcement during an incident?
Usually yes for sophisticated attacks, but with legal guidance. The FBI/Secret Service (US) and equivalents elsewhere often have threat-actor intelligence that reduces investigation time. The decision belongs to legal counsel and executive leadership, not the security team alone. Include the decision in your runbook so it does not get made under incident pressure.