Deep Dive: NIST Risk Assessment & Prioritization Process

Eric Marquette

Alright, everyone, welcome back to CMMC Unlocked—today we're diving into one of those topics people like to wave at in PowerPoint, but hardly anyone really pins down: enterprise risk appetite and context. How much risk is too much? Where should decision-makers draw the line? Honestly, this comes up all the time, and not just in the compliance world. We’ve got Paul here who loves an ERM playbook, and Ruby, who’s seen the risk appetite conversation play out on the ground. Ruby, you once told a story about, what was it—an agency sorting out how much downtime was tolerable, and the result was...chaos?

Ruby Sturt

Total chaos, Eric! The directive was basically "limit disruptions where possible"—whatever that means. So, when our dev broke prod for three hours, we couldn't decide if it was a crisis or just an "oops." One manager said, "Ah, it's just IT life." Another wanted a war room. If you don't have clear risk appetite—like, in plain language, "we tolerate up to two hours of downtime per quarter" or "no PII lost, ever"—then everyone's flying blind. You're set up for mixed priorities and finger-pointing. That's why defining both appetite and tolerance at the outset is absolutely critical, especially when you want risk owners to actually own those decisions.

Paul Netopski

Exactly, Ruby. The NIST frameworks all hammer this—appetite is senior leadership’s broad-based guidance: what are you willing to accept, what’s the real "no-go" zone? NIST IR 8286A and the ERM Playbook both say appetite is set at the very top—your board or senior execs. But then you have to translate that into operational risk tolerance, which is way more concrete. For CMMC or any federal contract, if the risk appetite is "zero data loss," then risk tolerance might be, say, "patch critical vulns within 14 days," not 60 or "when convenient." That distinction matters for everything from patch SLAs, to disaster recovery, to onboarding a risky vendor.

Eric Marquette

Right. And the risk context is just as important as the appetite here. You can't set leadership priorities in a vacuum. You need to factor in your mission, critical assets, the threat landscape, and the constraints you’re working under. NIST IR 8286A puts a ton of emphasis on mapping assets and understanding what the business actually cares about. If you don’t, risk evaluation is all gut feelings and not actionable.

Ruby Sturt

Exactly. And—maybe this is a hot take—I think a lot of organizations just inherit their "risk appetite" from a template or whatever their last auditor told them. It's super important to customize it to your actual mission objectives, your line of business, and your regulatory environment. Otherwise, your risk register is just lip service for compliance.

Paul Netopski

Couldn't agree more. And I’ll add—as you cascade that risk appetite into risk tolerance at the org, system, and process level, you’ve got to align it with how people actually do their work. Because if your risk tolerance is disconnected from reality, you're either strangling innovation or leaving yourself wide open and kidding yourself about your risk posture.

Eric Marquette

Let’s pivot to the handoff—once you have a top-down appetite, what information do you need up front for risk framing to work? And how much formalization do you want for those asset inventories and context documents? Ruby, you’ve seen messy attempts—what actually works?

Ruby Sturt

Honestly, you need both a tech and business inventory—systems, data flows, crown jewels, but also services and people dependencies. NIST recommends using tools like CMDBs, but even spreadsheets can start the conversation. The important bit isn’t perfection but getting a clear map so you’re not guessing what's mission-critical in the middle of a breach or an audit.

Paul Netopski

Spot on. And document both internal and external context—the real-world constraints, compliance requirements, and stakeholder pressures. That way, the "risk limits" you set actually mean something. Otherwise, the rest of the risk assessment exercise is, frankly, a waste of time.

Paul Netopski

Let's get into the machinery: once you've set the context, it's time to roll up your sleeves and start identifying risks. This is where NIST SP 800-30 and IR 8286A really get into the weeds. We’re talking about systematically laying out your assets, figuring out the relevant threats—both adversarial and accidental—along with vulnerabilities and predisposing conditions. You’re not just looking for 'what could go bump in the night,' but how likely are those things to go bump, and what happens if they actually do.

Eric Marquette

And the trick isn’t just listing every possible bad day on the horizon—it's building out credible, business-aligned risk scenarios. That means connecting assets, threats, vulnerabilities, and, crucially, impacts in a way execs and front-line staff both understand. I had a hospital client who used event tree analysis, per NIST, to visualize how a ransomware infection could propagate—not just taking out the EHR, but also knocking out dependent systems like lab results and even scheduling. Being able to see those dominoes was what finally got the CFO to buy-in on segmenting backups and investing in tabletop exercises, not just more endpoint tools.

Ruby Sturt

Yeah, and when you’re modeling, don’t sleep on business impact analysis—BIA. I know it’s boring, but if you don’t have clear, up-to-date impact values—"if this system dies, the following revenue is at risk," or "these patients can’t be seen," or "these SLAs will be missed"—then your risk analysis is just hand-waving. And, please, take interdependencies seriously. Major outages or breaches nearly always have cascading effects the old risk models never catch.

Paul Netopski

Love it. That segues into estimation—how do you go from “here’s a scary thing” to “here’s the probability and impact”? NIST 800-30 and IR 8286A walk through qualitative, semi-quantitative, and quantitative approaches. Most organizations start with qualitative—high, medium, low—but when it matters most, or you want to justify a spend to leadership, move to something more robust. Three-point estimation is a classic: optimistic, most likely, and pessimistic values. That can feed into beta or triangular distributions. If you need to model complex, cascading failures—think ransomware or supply chain compromise—NIST pushes event tree analysis or even Monte Carlo simulations for the true quant geeks. These techniques help you get to something closer to a dollar estimate or at least a defensible probability, not just gut feeling.

Eric Marquette

And don’t ignore the threat intel angle. Grab relevant feeds, CTI, ISAC reports—NIST specifically wants you pulling from both internal past incidents and sector-wide intelligence for a reasonable, not just hypothetical, threat model. And bias-check your team. Overconfidence, groupthink, trend-chasing… You name it, all can sneak in if you're not careful. NIST actually lists these out.

Ruby Sturt

Also, loophole alert: everyone always forgets positive risks—like new opportunities or tech that could provide advantage. Modern frameworks want you to register those too, but yeah, in practice, the main thing is aligning risk impact and likelihood to what really drives your business or agency. That way, your risk register doesn’t just become an inventory of nightmares, but a decision tool for where to invest, mitigate, or accept risk.

Paul Netopski

Exactly. And let's not sleep on documentation—your CSRR and risk detail records (RDRs) are vital. Without good records, everything gets lost in translation during aggregation or reporting. Plus, with things like attack trees, event trees, and BIA outputs all going into the register, you have a defensible trail for audits, executive conversations, and yes, your next CMMC or DoD assessment.

Eric Marquette

So, building out your threat, vulnerability, and impact analysis—using robust estimation where possible—that’s the foundation. Now let’s talk about how you use all that data to drive prioritization and action at the enterprise level.

Ruby Sturt

Alright, so let’s get practical. Once you’ve got a nicely populated risk register with real-world likelihood and impact values—not just "red, yellow, green" stickers—the real magic is in prioritization and communicating that to leadership. The NIST IR 8286 series, especially 8286B and C, get into this: it isn't always about which risk has the worst exposure value. Business priorities, resource constraints, sometimes even public perception can change what gets the top spot. That's why risk prioritization needs to be collaborative—not just handed down by the InfoSec team.

Paul Netopski

Absolutely, Ruby. The BIA and aggregation steps are so important here. Let's say three departments each report similar phishing risks—but one has sensitive customer data, and another supports a critical business line. When you aggregate in the enterprise risk register, you normalize for context, not just add numbers. NIST IR 8286C describes using standardized rating and taxonomy methods, so you’re comparing apples to apples across organizations. But sometimes, even with identical risk ratings, you have to make hard choices—what can you actually act on within budget, headcount, or compliance deadlines? That’s where governance and risk steering committees play their role.

Eric Marquette

Yeah, and the reporting component—this is where those cybersecurity risk registers (CSRRs) and the enterprise risk register (ERR) come together. What matters here isn't just aggregation, but also effective normalization and conditioning. You want leadership to see a portfolio view—here are our top strategic, operational, reporting, and compliance risks—along with clear status and owner assignments for each. NIST is big on the feedback loop—you monitor, evaluate, and adjust. If you’re seeing too many red risks sitting in "pending" forever, that’s a strong signal to leadership: are these going to be escalated, accepted, or are you adjusting your risk appetite because resources just aren’t available?

Paul Netopski

This is where good use of Key Risk Indicators (KRIs) and Key Performance Indicators (KPIs) pays off. As NIST 8286C and 800-39 lay out, your monitoring can trigger adjustment to risk priorities, resource allocation, or even your stated risk appetite. If you’re seeing repeated near-misses or residual risks that aren’t going away with the current program, governance has to step in and either provide more resources, accept higher risk, or change the mission objective. It’s not just "set it and forget it."

Ruby Sturt

And don't forget positive risks—opportunities. You have to capture and prioritize those too. Sometimes leadership is going to trade exposure for a real competitive advantage. It’s always a balancing act, and modern frameworks push organizations to document both risk AND opportunity—then track both through to action or acceptance.

Eric Marquette

Final word: this whole risk cycle—prioritization, aggregation, monitoring, and adjustment—is only as strong as your commitment to timely, accurate data and collaborative review. It's dynamic. As things change, as new threats or business drivers emerge, your risk register, appetite, and priorities should be living documents. That’s what ERM is all about.

Paul Netopski

Alright, that's a wrap for today's deep dive. Ruby, Eric, always a pleasure. Next episode, I think we’re getting hands-on with some real risk scenario modeling—and maybe even a bit of debate about qualitative vs quantitative. Should be fun!

Ruby Sturt

Can't wait! Thanks, Paul, Eric—catch you both, and thanks to all the listeners! If you’ve got stories about risk appetite confusion or the strangest risk aggregation challenge you’ve faced, send 'em in!

Eric Marquette

Thanks folks—keep those risk registers up to date, and we’ll see you in the next episode!