Incident Response Planning and Handling

What Is NIST SP 800-61 and Why Does Every Framework Reference It?

NIST SP 800-61 Revision 2 is the federal Computer Security Incident Handling Guide that defines the four-phase IR lifecycle (Preparation; Detection and Analysis; Containment, Eradication, and Recovery; Post-Incident Activity). HIPAA, CMMC, DFARS 252.204-7012, PCI DSS 4.0, SOC 2 CC7.3, and NIST CSF 2.0 all map back to this lifecycle either explicitly or by convention.

Every organization eventually has an incident. The ones that handle it well have a written plan, tested procedures, a trained team, and a relationship with their forensic responder in place before the incident happens. The ones that handle it badly are trying to figure out who to call, what to do, and what is defensible in court while the incident is in progress. Petronella Technology Group helps organizations get on the right side of that line.

NIST SP 800-61 Revision 2, "Computer Security Incident Handling Guide," is the authoritative federal publication on how to build an incident response program. Published August 2012 and available at nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf, SP 800-61 defines four lifecycle phases: Preparation; Detection and Analysis; Containment, Eradication, and Recovery; and Post-Incident Activity. Nearly every regulatory regime in the U.S. incident-response landscape maps back to this lifecycle, whether explicitly (HIPAA, CMMC, DFARS 252.204-7012, PCI DSS 4.0) or by convention (SOC 2 CC7.3, NIST CSF 2.0 Respond function, most state breach-notification laws). Learning SP 800-61 is learning the grammar of incident response.

Our incident response engagement is not a document delivery. It is a program build-out that ends with a tested, exercised, documented program your team can actually execute. The deliverables are an incident response policy, an incident response plan, a set of role-specific runbooks for the most likely incident types, a tested tabletop exercise cadence, the communication templates that counsel has pre-approved, the external-vendor rolodex already on retainer, and the training curriculum that keeps your workforce sharp. We have built programs for healthcare networks, defense contractors, law firms handling class-action discovery, cloud service providers under FedRAMP continuous monitoring, and family offices after the principal was pig-butchered for seven figures. The structure is consistent. The runbook detail varies by vertical.

The rest of this page walks through each phase in practical terms, with the artifacts you need, the traps that catch most programs, and how our team fits in before, during, and after an incident.

What Does Phase 1 Preparation Actually Require?

A staffed CSIRT with defined roles, retainer agreements with forensic responder and breach counsel in place before the incident, adequate logging and EDR tooling already collecting evidence, and incident-type runbooks that work under stress. 80 percent of real IR work happens in Preparation, and it is the phase most organizations underinvest in.

The Preparation phase is where 80 percent of the real work happens, and it is the phase most organizations underinvest in. Preparation is not just writing a plan. It is building the people, process, and technology foundation that the other three phases rely on. When we kick off a preparation engagement we work through a sequenced checklist that most clients find eye-opening.

Team composition. The NIST recommendation is a core CSIRT that pulls in extended team members for specific incident types. Core membership typically includes the CISO or senior security lead, an IT operations lead with authority to isolate systems, a legal or compliance lead, a communications lead, and an executive sponsor. Extended members are domain specialists (developers for application incidents, infrastructure engineers for network incidents, HR for insider incidents). We help you staff the team, define the roles in writing, and set the on-call rotation.

External relationships. The worst time to identify your forensic responder is at 11 PM on a Friday during an active incident. Preparation includes putting retainer agreements in place with your forensic partner, cyber insurance carrier, breach counsel, and regulatory liaison (FBI, Secret Service, state attorney general's office where applicable) before the incident. Petronella Technology Group offers an incident response retainer as part of our Preparation engagement so the relationship is in place and pre-authorized before anything goes wrong.

Tooling. Evidence preservation starts before the incident. We help you deploy and configure logging, EDR with historical memory, network flow capture, cloud audit trails, identity and authentication logs, and centralized log aggregation with appropriate retention. If the logs are not there, the forensic investigation cannot answer the questions that insurance, counsel, and regulators will ask. The most common cause of an investigation that cannot make attribution is insufficient logging configured long before the incident.

Runbooks. A plan document describes the program. Runbooks are the step-by-step procedures for specific incident types. Ransomware, business email compromise, lost or stolen device, insider exfiltration, vendor-side breach, crypto theft, pig-butchering romance scam, third-party SaaS compromise, DDoS, web application incident. Each runbook identifies the early indicators, the containment steps, the eradication steps, the recovery steps, and the post-incident tasks. Our runbooks are written for the people who will actually execute them, not for an auditor. They assume stress, incomplete information, and time pressure. The artifact that works under stress is not a 200-page plan. It is a 2-page decision tree that fits on a laminated card on the wall.

How Do You Detect a Real Incident Before External Notification?

By engineering actionable detections in your SIEM against the MITRE ATT&CK tactics relevant to your threat model, using endpoint, DNS, proxy, firewall, cloud, SaaS, and identity telemetry you already collect. Verizon's 2024 DBIR found that organizations relying on external notification had a median breach-detection time of over 100 days.

Detection is where programs succeed or fail. You cannot respond to what you do not detect, and the majority of breaches investigated by mainstream incident response firms show dwell times (time from initial compromise to detection) measured in months, not hours. Verizon's 2024 Data Breach Investigations Report noted that the median time to detect a breach for organizations relying on external notification was over 100 days. That means most organizations find out they are breached because a customer, a bank, or a government agency tells them.

Our detection engineering engagement starts with an inventory of the telemetry you already have. Endpoint logs, DNS logs, proxy logs, firewall logs, cloud audit logs, SaaS activity logs, identity provider logs. We map telemetry against the MITRE ATT&CK tactics most relevant to your threat model, and we look for gaps where an attacker could move through a tactic without leaving a signal in your logs. We then build detection content (queries, rules, correlations) in your SIEM or log platform that produces actionable alerts. The key word is actionable. Alert volume is a separate failure mode: a SOC that sees 50,000 alerts a day and triages 50 of them is probably missing the important ones.

Analysis is the tradecraft of deciding whether an alert is a real incident, what the scope is, and what the impact is. Our analysts triage alerts against a set of questions: what system, what user, what action, what time, what baseline does this deviate from, what correlated activity shows up in other telemetry, what is the plausible attack chain that would produce this signal. The answers determine whether we escalate to containment or close as false positive. Every escalation is documented to preserve a timeline that later becomes forensic evidence.

Part of analysis is impact assessment. What data was accessed? How many records? What regulations apply? What notification obligations are triggered? The answers shape Phase 3 Containment in real time. A breach involving regulated health data under HIPAA triggers different containment choices than a breach of public-facing marketing data. We make those determinations with our breach counsel partners so the decisions made under pressure hold up in front of regulators.

Phase 3: Containment, Eradication, and Recovery

Containment is where speed matters. You are trying to stop the damage without destroying the evidence or tipping off the attacker prematurely. The choices here are not obvious. Isolate the compromised endpoint immediately, or observe the attacker to understand their full scope? Pull credentials, or leave them active long enough to see where the attacker pivots? Shut down the affected service, or accept continued impact while forensics are acquired? Every answer is a tradeoff between containment speed, evidence preservation, and business impact.

Our forensic team handles containment with evidence preservation as a non-negotiable. We acquire disk images, memory captures, and log extractions using procedures that meet legal chain-of-custody standards. Craig Petronella holds Digital Forensic Examiner license number 604180 and is listed on the North Carolina forensic examiner registry at forensicresources.org. That credential means the evidence we collect is admissible if the matter goes to court, and the defense counsel cannot challenge our handling of it.

Eradication removes the attacker from the environment. That means identifying every compromised identity, every persistence mechanism, every lateral-movement pivot, and every data-exfiltration path. In most cases we see, the indicators of compromise extend beyond the initial alert. Attackers establish redundant access through multiple paths, and an eradication that only addresses the visible one leaves the attacker in the environment. Our eradication methodology is explicitly designed to find and close the secondary paths. We have been called in to re-investigate breaches where the initial responder missed backdoor persistence, and we have found it every time.

Recovery is restoration to production with confidence that the attacker is out. That confidence is not built by hope. It is built by reconstruction from known-clean baselines, credential rotation across every account that could have been exposed, enhanced monitoring during the return-to-service window, and validation testing. Recovery also includes media sanitization where appropriate, which maps to NIST SP 800-88 and is covered in our separate media sanitization guide. Recovery is the phase where hasty decisions cause re-compromise, and we slow clients down specifically to get this right.

Phase 4: Post-Incident Activity (Where Lessons Actually Get Captured)

Post-incident activity gets cut short in most organizations because the pressure is off and the team is exhausted. That is a mistake. The most valuable forensic output of an incident is the lessons-learned document that captures what happened, what the team did well, what the team did poorly, and what controls and procedures need to change so the same failure does not recur. We facilitate this review within 14 days of incident closure while the details are still fresh.

Post-incident also includes regulatory notification. HIPAA requires notification of affected individuals, HHS, and in some cases the media within 60 days of breach discovery. DFARS 252.204-7012 requires defense contractors to report to the DoD within 72 hours. Several states (California, New York, Texas, and others) have their own breach notification statutes with their own clocks. GDPR requires notification within 72 hours for breaches of EU personal data. The SEC adopted incident disclosure rules for public companies with four-business-day reporting for material incidents. Every jurisdiction your data touches has a potential obligation. Our breach counsel partners handle the legal determination; we handle the forensic support that counsel needs to make the determination correctly.

The final post-incident artifact is the control change list. Every incident reveals a failure in prevention, detection, or response. Our lessons-learned process closes out each finding with a specific control or procedural change, an owner, and a target completion date. Three months later we audit closure. Incident response that does not feed back into improved controls is an expensive treadmill, and we will not run a retainer that is not producing measurable control improvement over time.

Tabletop Exercises: The Cheapest Insurance You Will Ever Buy

Every written plan degrades the moment it is printed. The only way to find out whether your IR program actually works is to exercise it. NIST SP 800-84, "Guide to Test, Training, and Exercise Programs for IT Plans and Capabilities," defines a spectrum of exercises from tabletop to full-scale functional. Tabletop exercises are the entry point: a facilitated discussion where the team walks through a realistic scenario and works through the decisions they would make. A two-hour tabletop will find more weaknesses in your program than any amount of plan review. We facilitate tabletops on a cadence that matches your risk and your compliance obligations.

Scenario design matters. A generic "ransomware attack" scenario teaches generic lessons. A scenario designed around your specific systems, your specific vendors, and your specific threat profile teaches lessons you can actually act on. We design custom scenarios drawing from recent incident patterns in your industry and from the threat intelligence we collect across our own engagements. A scenario for a healthcare client might center on a compromised EHR vendor with PHI exfiltration. A scenario for a defense contractor might center on a spear-phishing email that leads to credential theft in the CUI enclave. A scenario for a family office might center on a wire-transfer fraud originating from a compromised email thread with the CPA.

After every tabletop we produce an after-action report that documents the scenario, the decisions the team made, the strengths the exercise surfaced, and the gaps we identified. The after-action report becomes input into the next plan revision. A tabletop is not training unless it produces changes in the plan and the runbooks. Otherwise it is theater.

Incident Response Retainer: What It Actually Includes

An incident response retainer with Petronella Technology Group is not a prepaid block of hours. It is a pre-authorized engagement framework with defined response-time SLAs, a named incident commander on our side, and a pre-negotiated scope of work that lets us start responding within hours rather than days. When an incident hits, you call a dedicated number, we engage immediately, and the contracting formalities are already handled. Most active-response engagements we have run that resolved within hours did so because we were on retainer and did not have to negotiate scope while the attacker was still in the environment.

The retainer also covers proactive work: quarterly program review, annual tabletop, runbook updates when controls change, and the detection-engineering cadence that keeps your SIEM content current as threat tactics evolve. Retainer clients get priority triage and reduced rates on active response. For organizations in regulated verticals, the retainer often satisfies a specific compliance requirement around designated incident response capability, which is how several of our clients originally funded the engagement.

We also handle specialized incident types that generalist responders do not. Our forensic team has handled pig-butchering and romance-scam crypto recoveries. We have worked business email compromise investigations where wire transfers were reversed through bank coordination. We have done network forensics on ransomware attacks that led to litigation. See network forensics, crypto forensics, and business email compromise recovery for the specific service lines that plug into the SP 800-61 framework. For principals and family offices concerned about personal cyber incidents, see VIP security.

If you sign government contracts, process health data, accept card payments, or carry cyber insurance, you almost certainly have a contractual or regulatory obligation to maintain an incident response capability aligned to NIST SP 800-61 or an equivalent. Our engagements translate that obligation into a working program that survives an audit and, more importantly, survives a real incident.

Why Petronella for Incident Response

Petronella Technology Group was founded in 2002 at 5540 Centerview Drive, Raleigh, North Carolina. We hold BBB A-plus accreditation continuously since 2003, CMMC Registered Practitioner Organization status (RPO number 1449, verifiable at cyberab.org/Member/RPO-1449-Petronella-Cybersecurity-And-Digital-Forensics), and our consulting team includes multiple CMMC-RP practitioners. Craig Petronella, the founder, holds CMMC-RP, CCNA, CWNE, and Licensed Digital Forensic Examiner (DFE number 604180) credentials, and is listed in the North Carolina digital forensic examiner registry at forensicresources.org.

The combination that matters for incident response is rare in the market: a program-build capability that produces a real SP 800-61 program, a detection-engineering capability that reduces dwell time, and a forensic investigation capability with licensed credentials that produces evidence admissible in court. Most firms have one of those capabilities. Very few have all three, and almost none deliver them under a single retainer with a single point of contact. That continuity is the reason our clients call us at 2 AM rather than rotating through a rolodex.

Pricing is custom per engagement, driven by the size of your organization, the complexity of your environment, and whether you want a one-time program build, a program build plus retainer, or active incident response for an ongoing situation. For a scoped quote, call (919) 348-4912 or use the contact form and we will schedule a 30-minute intake before we propose.