Listen

All Episodes

NIST Incident Response

Incident Response for NIST CSF 2.0, NIST SP800-171r2 and CMMC 2.13

This show was created with Jellypod, the AI Podcast Studio. Create your own podcast with Jellypod today.

Get Started

Is this your podcast and want to remove this banner? Click here.


Chapter 1

Navigating the New NIST Incident Response Lifecycle

Eric Marquette

Welcome back to CMMC Unlocked, everyone. I'm Eric Marquette, and joining me are Paul Netopski and Roz the Rulemaker. Today, we're tackling a topic that's landed on a lot of desks lately: the new NIST Special Publication 800-61 Revision 3, and how it's transforming incident response from a narrow, IT-focused task to something way more strategic—something that goes way beyond fire drills in the server room. So, Paul, let’s set the stage. What’s the fundamental shift here?

Paul Netopski

Thanks Eric. Yeah, this is a big one. If you look at SP 800-61r3, it’s moving away from the old linear, cycle-based approach, the kind of “do-recover-repeat” thing, and instead, it’s embedding incident response right into the organization’s risk management processes. It’s not just about reacting when an alert pops up—it brings incident response into strategy discussions, risk assessments, and architecture reviews. It aligns directly with the six functions in CSF 2.0: Govern, Identify, Protect, Detect, Respond, and Recover. Basically, incident response becomes a living, breathing part of your whole cybersecurity ecosystem, not some niche operation sitting off to the side.

Roz the Rulemaker

That’s right, Paul. And from a rulemaking and compliance standpoint, if there’s one thing that stands out, it’s the call for intelligence-driven, business-wide engagement. Incident response isn’t just a technical checklist anymore—it’s about cross-functional coordination, real-time information sharing, and integrating lessons learned into future readiness. The new guidance makes it clear: incident response now involves your legal, HR, PR, and executive teams. It’s about agility and resilience, not just following a rigid playbook.

Eric Marquette

Yeah, you can feel that shift just in the language. It’s emphasizing teamwork and proactive integration. I mean, it feels like the goal is to have incident response not just respond, but, like, actually shape how organizations prepare, build, and recover from all types of cyber events—before, during, and after an incident. That’s such a change from the old cycle where you’d check the box and hope the storm passed before the next quarterly review.

Chapter 2

From Cycle to Embedded Lifecycle: Aligning with CSF 2.0

Paul Netopski

Let’s dig a little deeper into that lifecycle model. In earlier versions of SP 800-61, you had the classic five stages—Preparation, Detection & Analysis, Containment, Eradication & Recovery, and then Post-Incident Activity. This latest revision pivots and aligns with CSF 2.0’s six core functions. What that means in practice is you’re constantly cycling through governance, identification, protection, detection, responding, and recovering—not just one loop, but a flow that never really stops. It’s dynamic. For defense contractors and anyone subject to CMMC, this change means integrating incident response from governance all the way through continuous improvement.

Roz the Rulemaker

And just to emphasize, that’s a significant philosophical shift—it’s not merely an update to existing procedures. Now, the framework turns incident response into a pillar of enterprise risk management. If you’re responsible for compliance or oversight, you’re expected to demonstrate that incident response is woven into policy, daily operations, and organizational intelligence. The technical folks aren’t carrying this on their backs alone; the entire business is responsible. Regulators are, frankly, looking for a much more holistic response.

Eric Marquette

Absolutely, Roz. And that holistic approach isn’t just theory. In previous episodes, we’ve talked about how incident response lessons can drive broader risk-management processes. Now, it's like the whole organization is getting called up to the big leagues—no more “that’s IT’s job” mentality. Everyone’s got a role. I mean, the framework even calls out DevSecOps and early integration into risk reviews. Feels like if you’re not looping IR into everything, from day one, you’re behind the curve.

Chapter 3

The Intelligence-Driven Response and the Role of Cyber Threat Intelligence

Paul Netopski

Right, and if there’s a new star player in this scenario, it’s definitely cyber threat intelligence—CTI. SP 800-61r3 puts CTI at the center of every phase. Under CSF 2.0, you’ve got things like integrating CTI and contextual data into analysis, pulling threats from forums, ISACs, and sharing communities, and feeding that all back into both operations and planning. For CMMC Level 2, this is a foundational practice—it’s about making decisions that aren’t just knee-jerk reactions, but are informed by actual threat behaviors, adversary TTPs, and continuous ingestion of outside intelligence. Organizations should be automating threat intel into their SIEMs, mapping incidents to things like the MITRE ATT&CK framework, and ensuring that context is available at the speed of business.

Roz the Rulemaker

Paul, those CTI tie-ins are absolutely essential from a regulatory reporting standpoint, too. If guidance is calling for “continuous gathering” and integration of external and internal threat information, you can expect assessors will ask to see clear documentation that this process is active, not just aspirational. In other words, your policies, playbooks, and after-action reports need to show you’re mapping and evolving your response based on real intelligence. If you’re a compliance or legal lead, you better know how your teams consume and respond to threat intelligence in practice, not just on paper.

Eric Marquette

And I love how you mentioned playbooks, Roz. The new guidance is pretty explicit about modernizing those runbooks—linking them with actual CTI, updating regularly to reflect adversary tactics. Automation is the key, right? Whether you’re big or small, you’ve got to connect these dots automatically—not after it’s too late and the attacker’s already left town. There’s a real emphasis here on making sure your response is as real-time and context-aware as possible.

Chapter 4

Operationalizing the New Lifecycle: Cross-Team Collaboration, POA&M, and Modern Playbooks

Paul Netopski

So, let's get practical. For organizations that want to actually live this new model, it means you don’t wait until red lights are flashing. Incident response gets pulled into risk assessments, DevSecOps, and architectural decisions—basically, “shift left” as much as possible. You embed IR into every process upstream. This is especially important for contractors in the DIB, who often face scrutiny during CMMC assessments. And don't forget, POA&Ms—Plan of Action and Milestones—should now include IR findings and lessons learned. Every incident, near-miss, or after-action report gets mapped to a remediation, assigned an owner, and tracked for continuous improvement. That's a notable tie-in to CSF 2.0’s spirit of resilience and progress over time.

Eric Marquette

I mean, honestly, that sounds like a ton of moving parts, but it’s the only way to avoid repeating the same mistakes. And the playbook piece is huge—modern IR playbooks aren’t those dusty, ten-page Word docs you update once a year. They’re dynamic, they adapt to new threat actor techniques, they plug in real-time threat intelligence feeds, and they’re linked to your automation and orchestration tools. Kind of like a, uh, living organism for your security program. That analogy’s a little weird, but you get what I mean. It's alive!

Roz the Rulemaker

That works for me, Eric. The important thing is that, across the organization, everyone needs clarity: what’s my role, how do I communicate, and how are these lessons captured and distributed after incidents? In early regulatory reviews, I’m seeing more emphasis on role clarity and communication protocols—not just post-breach clean-up. You’ll be expected to demonstrate not only technical improvements but also cultural change reflecting this cross-team engagement.

Chapter 5

Sector-Specific Guidance: SMBs, Healthcare, Law, Government, Finance, Non-profits

Paul Netopski

Let’s make this real for particular audiences. The updated SP 800-61 gives special attention to how its lifecycle applies across different industries—including small and mid-sized businesses, healthcare, law, city governments, investment firms, and even non-profits. For SMBs, these changes are a huge win. You don’t need a twenty-person SOC to start; the streamlined guidance helps embed IR into your existing business risk processes. Even basic steps like joining your industry ISAC and pulling in threat feeds can make a measurable difference. And continuous improvement is now expected, even if you’re small—so don't underplay those lessons-learned sessions.

Eric Marquette

For healthcare, the stakes couldn’t be higher—patient safety, HIPAA compliance, and sensitive IoT medical devices all come into play. The lifecycle approach aligns nicely with the HIPAA Security Rule around risk assessment and incident handling, and having CTI tied to attacking ransomware or IoT threats really helps minimize disruption. We’ve talked before about how clinical, IT, and compliance teams can sometimes feel like they speak different languages—now, they all have to come together, or risk running afoul not just of the hackers, but the regulators too.

Roz the Rulemaker

The legal sector’s another interesting one, Eric. Law firms manage highly sensitive client data, and they’re increasingly targeted by BEC scams and espionage. The CSF 2.0 approach supports alignment with statutory disclosure obligations, especially under things like California’s CCPA and CPRA. And CTI helps firms track attacker groups and phishing campaigns using legal themes. It also clarifies how privilege, breach notification, and PR work fit into the response equation—something regulators are actively watching.

Paul Netopski

Don’t forget city governments—they’re getting hit left and right with ransomware, and so many public services depend on stable systems. This guidance encourages local governments to team up with state agencies and tap into things like MS-ISAC for threat sharing. And critically, incident response is framed as supporting continuity of government operations, not just an IT function managed out of a basement server closet.

Eric Marquette

For investment advisors, documented, testable IR plans are directly tied to requirements from the SEC— you can’t just claim you did something, you need logs and continuous risk identification to actually prove it. And for non-profits, there’s a welcome focus here on lightweight, repeatable processes—these organizations don’t always have the budget for a big tech stack, but they handle lots of sensitive donor information. CSF 2.0 is giving them a way to formalize incident response without busting their budget. It really is, like, a democratization of resilience, not just a set of hoops for big players.

Chapter 6

DoD Contractor Requirements: Incident Reporting, DCISE, and CMMC Mapping

Paul Netopski

All right, let’s turn to the bread and butter for our listeners—defense contractors and folks on the CMMC journey. Under DFARS 252.204-7012 and related clauses, you’re on the hook for prompt, detailed incident reporting. If you discover a cyber incident involving covered defense information, you’ve got 72 hours to file a report with the DoD, usually via DCISE—the Defense Industrial Base Collaborative Information Sharing Environment. You’ll need a DoD-Approved Medium Assurance Certificate to do this. The info you report is comprehensive—contract numbers, POCs, description of the event, TTPs, indicators of compromise, and so on. Malicious files need to be submitted for analysis too, but not by email—use their prescribed portals. These requirements are mandatory, not optional, if your contract involves covered defense info or cloud services.

Roz the Rulemaker

And remember, there’s also voluntary reporting avenues for sharing threat activity or suspicious behavior, even if it doesn’t meet the threshold for a mandatory report. DoD and the DIB benefit greatly when contractors share what they’re seeing, especially for new threat infrastructure or active phishing campaigns. Also, from a compliance and readiness perspective, it’s wise to stay familiar with all the reporting formats—incident collection forms, malware submissions, you name it. The closer your documentation matches the NIST and CMMC assessment criteria, the smoother your next audit will go.

Eric Marquette

Yeah, and just to tie it back to CMMC Level 2—which most defense contractors have to hit now—you’re tested on three practices: having an operational incident-handling capability (including the six integrated steps we’ve been talking about), tracking and documenting incidents while reporting to appropriate authorities, and regularly testing your IR capability. It all sprawls from the NIST controls—SP 800-171 specifically, and eventually Rev 3 when DoD transitions over. So, if you’re listening and prepping for a CMMC assessment, this model of continuous, intelligence-driven, cross-functional IR should be what you’re building toward—not just for compliance, but for real resilience.

Chapter 7

Moving Forward: Practical Steps and Resources

Paul Netopski

So, where does all this leave organizations looking to up their game? First, revisit your incident response plans and playbooks. Update them to reflect not just the technical steps, but the organizational roles, CTI integration, and continuous improvement elements. Be sure you’ve built a process for cross-team communications. Second, if you’re in the Defense Industrial Base, get familiar—really familiar—with your DCISE contacts and mandatory reporting procedures. Don’t wait until you’re in the middle of an incident to figure out how to file a report or submit malware. Proactive review and tabletop exercises, involving more than just IT, are critical.

Roz the Rulemaker

Take advantage of the tools and resources out there. NIST’s own incident response resource page is a great place to start for templates and best practices. There’s also the Cyber Resilience Analysis (CRA) tool from DC3, which aligns with CSF, NIST 800-171, and CMMC guidance. Just remember, CRA is a self-assessment—it’s great for identifying gaps, but isn’t a substitute for compliance activity. And as we keep stressing, keep your documentation and reporting up to date and mapped to current requirements.

Eric Marquette

And don’t forget, a lot of these frameworks are getting more accessible with every update. Whether you’re a five-person shop or a big prime contractor, modern incident response is about engaging the whole business, not just a handful of tech experts. Start pulling those teams together now and practice before you need to—don’t learn this stuff the hard way during a crisis. All right, that’s about all we’ve got time for today. Roz, Paul, any last words before we call it?

Roz the Rulemaker

Just that this mindset shift in incident response is overdue—and it’s absolutely necessary. Regulators, assessors, and your own risk managers are going to be looking for evidence that you’ve operationalized this model, not just written it down. So, take it seriously.

Paul Netopski

Couldn’t agree more. Get started early, iterate often, and remember: compliance is the baseline, actual resilience is the goal. Good luck out there.

Eric Marquette

Thanks, Paul and Roz. Thanks to everyone for tuning in to CMMC Unlocked. We’ll see you next time—don’t forget to subscribe and join us for more explorations into the ever-evolving world of cybersecurity and compliance. Take care, everyone.