NIST CSF 2.0 Respond & Recover Functions

The Respond and Recover functions are closely linked — responding to an incident flows directly into recovering from it. For small businesses, treating them as two phases of one process makes more practical sense than implementing them independently. The Respond function covers what you do when a cybersecurity incident is detected: managing the incident, analyzing what happened, reporting and communicating about it, and mitigating the damage. The Recover function covers what you do after containment: restoring affected systems and services, and communicating recovery status to stakeholders. For small businesses, the critical insight is this: the time to plan your response is before an incident happens, not during one. An incident response plan that you have practiced is worth a hundred times more than one you have never read. Businesses with a tested incident response plan experience breaches that cost 35% less and are resolved significantly faster, according to IBM's data. Most small businesses have no incident response plan at all. Among those that do, most have never practiced it. This guide gives you a practical plan you can create in a day and test in an afternoon.

An incident response plan for a small business does not need to be a 50-page document. It needs to answer six questions clearly and specifically. 1. How do we detect an incident? Define what constitutes an "incident" for your business: ransomware, data breach, phishing compromise, unauthorized access, system outage, vendor breach. List your detection sources: CDA alerts, endpoint protection alerts, employee reports, customer complaints, bank notifications. 2. Who do we call? Create a call tree with names, roles, and phone numbers (not just email — email may be compromised). Include: internal security lead, IT provider/MSP, legal counsel, insurance carrier (cyber liability), and law enforcement contact (FBI IC3, local field office). Keep printed copies accessible — they are useless if locked in an encrypted system that ransomware just encrypted. 3. How do we contain the damage? For each incident type, document containment steps: Ransomware — disconnect affected systems from the network immediately, do not pay ransom without consulting counsel and insurance, preserve evidence. BEC/phishing — reset compromised credentials, check email forwarding rules, alert financial institutions. Data breach — identify affected data and systems, preserve logs, begin notification assessment. System compromise — isolate affected systems, change all passwords, review access logs. 4. Who do we notify? Notification requirements vary by state and regulation. Document: state breach notification requirements (all 50 states have them), regulatory notification requirements (FTC, SEC, HHS depending on your industry), contractual notification obligations (client contracts, vendor agreements), and cyber insurance notification requirements (often within 24-72 hours). 5. How do we recover? Document: backup locations and restoration procedures, system rebuild priorities (email first, then practice management, then other systems), alternative operations procedures (how to continue business without affected systems), and vendor contact information for emergency support. 6. What do we learn? After every incident (and every near-miss), conduct a post-incident review: What happened? How did we detect it? How effective was our response? What should we change? Document findings and update the plan.

NIST CSF 2.0 breaks the Respond function into four categories: RS.MA — Incident Management. Execute your incident response plan. This means activating your response team, following your containment procedures, and coordinating activities. For small businesses, this is your call tree and containment steps in action. Practice this with tabletop exercises — walk through a scenario like "ransomware encrypted our file server at 2 AM on a Saturday" and verify everyone knows what to do. RS.AN — Incident Analysis. Investigate the incident to understand its scope, impact, and root cause. What was the attack vector? What systems and data were affected? Is the attacker still in the environment? For small businesses, this often means working with your IT provider or a forensic specialist. Your cyber insurance policy likely includes access to an incident response firm — know who they are and how to reach them before you need them. RS.CO — Incident Response Reporting and Communication. Communicate about the incident to appropriate stakeholders: leadership, employees, affected customers, regulators, law enforcement, and potentially media. Have template communications prepared in advance. Designate a single spokesperson. Do not speculate publicly about the cause or scope until you have facts. RS.MI — Incident Mitigation. Take actions to contain and eradicate the threat, and prevent it from spreading or recurring. This includes isolating affected systems, patching exploited vulnerabilities, resetting credentials, and implementing additional controls. After containment, verify that the threat is eliminated before restoring services. The key for small businesses: you do not need to be an incident response expert. You need a plan that connects you to experts quickly. Your IT provider, your cyber insurance carrier, and law enforcement all have resources to help. Your plan should get the right people involved fast.

The Recover function is about restoring normal operations after an incident. NIST CSF 2.0 has two Recover categories: RC.RP — Incident Recovery Plan Execution. Execute your recovery plan to restore systems and services. Priority should be based on business impact: restore the systems your customers and operations depend on first. For most small businesses, the priority order is: 1) email and communication, 2) customer-facing systems (website, portals), 3) core business applications (practice management, DMS, EHR), 4) supporting systems (CRM, marketing, reporting). RC.CO — Incident Recovery Communication. Communicate recovery status to stakeholders. Customers need to know when services will be restored. Employees need to know what they can and cannot use. Regulators may need updates on remediation progress. Insurance carriers need documentation of the recovery process. Recovery planning for small businesses should address three scenarios: Scenario 1: Partial compromise. A single system or account is compromised. Recovery involves resetting credentials, scanning for persistence mechanisms, patching the vulnerability, and monitoring for recurrence. Recovery time: hours to days. Scenario 2: Ransomware. Multiple systems are encrypted. Recovery involves restoring from backups (you do have tested backups, right?), rebuilding affected systems, investigating how the attacker got in, and implementing controls to prevent reentry. Recovery time: days to weeks. Scenario 3: Major breach. Customer data has been exfiltrated. Recovery involves all of the above plus: breach notification (legal counsel determines timing and scope), credit monitoring for affected individuals, regulatory reporting, and potentially public communication. Recovery time: weeks to months. For each scenario, document: who leads the recovery, what resources are needed, what the backup restoration process is, what the estimated recovery time is, and how you communicate with stakeholders during recovery. Cyber Defense Agent supports recovery by providing a post-incident baseline scan. After you have recovered, run a CDA scan to verify that your external posture is restored and that the incident did not leave lingering exposures (open ports, degraded encryption, DNS changes).

An untested plan is barely better than no plan. Tabletop exercises are the most practical way for small businesses to test their incident response and recovery plans without disrupting operations. A tabletop exercise is a discussion-based walkthrough of a hypothetical incident scenario. Gather your team (or just you and your IT provider), present a scenario, and talk through your response step by step. Sample scenario 1 — Ransomware: "It is Monday morning. You arrive at the office and every computer displays a ransom note demanding $50,000 in Bitcoin. Your server, all workstations, and your backup drive connected to the server are encrypted. Your cloud email still works. Walk through your response." Sample scenario 2 — Business email compromise: "Your bookkeeper received an email that appeared to be from you, requesting an urgent wire transfer of $28,000 to a new vendor. She processed the transfer. You discover it was fraudulent when the real vendor calls about an unpaid invoice. Walk through your response." Sample scenario 3 — Vendor breach: "Your practice management software vendor notifies you that they experienced a data breach. They believe attacker accessed customer data, including your clients' records. They are still investigating the scope. Walk through your response." For each scenario, evaluate: Did everyone know who to call? Were contact numbers accessible? Did containment steps make sense? Were notification requirements understood? Was the recovery plan realistic? Conduct tabletop exercises at least annually. After each exercise, update your incident response plan based on what you learned. Document the exercise and its outcomes — this is valuable compliance evidence for regulators and insurers. Small businesses that conduct regular tabletop exercises respond to real incidents faster, more calmly, and more effectively. It is a one-afternoon investment that can save your business.