Making CMMC Risk Management Practical: RA Domain, Policies, and Change Management

Paul Netopski

Welcome back to CMMC Unlocked. I’m Paul Netopski, and today we’re going to roll up our sleeves on the Risk Assessment domain for CMMC Level 2. If you’re a defense contractor trying to get through a C3PAO assessment or a solid self-assessment, this one matters a lot.

Roz the Rulemaker

And I’m Roz the Rulemaker. We’ve talked before about configuration and change management and a few of the other NIST 800-171 domains. Today we’re going to connect those dots and show how risk assessment is supposed to sit at the center, not off in a binder somewhere.

Paul Netopski

Let’s start right from the mapping. For CMMC Level 2, the Risk Assessment domain is three practices taken straight from NIST SP 800-171: 3.11.1, 3.11.2, and 3.11.3. In CMMC shorthand those are RA.L2-3.11.1, 3.11.2, and 3.11.3.

Roz the Rulemaker

Right. And the assessment guide and 800-171A break each of those down into concrete “determination statements.” That’s assessor-speak for: what has to be true for you to get a MET. So let’s walk through them one by one and translate into something a small or mid-sized contractor can actually do.

Paul Netopski

RA.L2-3.11.1 first. The control text is: “Periodically assess the risk to organizational operations, organizational assets, and individuals, resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI.” The 800-171A assessment criteria in your spreadsheet say two big things. One, you define the frequency to assess risk. Two, you actually perform the risk assessment at that defined frequency for systems handling CUI.

Roz the Rulemaker

So from a practical standpoint, I’d phrase it like this: you can’t just say, “Yeah, we do risk assessments.” You have to write down, in policy or procedure, how often you do them—annually, semi-annually, whatever fits your risk profile but no less than once a year. Then you have to show records that you actually did them on that cadence.

Paul Netopski

Exactly. When I’m in assessor mode, I’m looking for tickets, dated reports, and sign-offs. Your attached Risk Assessment Report Template is a great starting point. It follows NIST SP 800-30: define purpose, scope, assumptions, information sources, risk model, then identify data, critical support functions, and threats.

Roz the Rulemaker

And that template already bakes in the three-tier idea—organization, mission or business process, and system level. For CMMC Level 2 you’re mostly living in Tier 2 and Tier 3. You’re asking, “How do our business processes and supporting systems create risk to CUI’s confidentiality, along with impact to operations, assets, individuals?”

Paul Netopski

Now RA.L2-3.11.2: this is the vulnerability scanning requirement. Next you see the 171A objectives spelled out: you define the frequency for vulnerability scans, you perform scans on systems and on applications at that frequency, and you also scan when new vulnerabilities are identified. That last part trips people up.

Roz the Rulemaker

Yes. “Periodically” in the CMMC world is “no more than annually,” but your attached Risk Management Policy actually tightens that. It says all CUI assets and Security Protected assets must have vulnerability scans at least monthly. And it adds a pre-production scan for new systems, software, firmware, or applications before they’re authorized to process CUI.

Paul Netopski

That’s exactly what an assessor wants to see. You’ve defined a frequency—monthly—and you’ve got a process that says: tools are updated, definitions are no more than five days old, scans are logged in a ticketing system, and results are reviewed by the folks responsible for vulnerability and patch management. That lines up cleanly with the NIST 800-171A through objectives.

Roz the Rulemaker

And then RA.L2-3.11.3 is the logical follow-on: “Remediate vulnerabilities in accordance with risk assessments.” The 171A criteria are really simple on paper—identify vulnerabilities, and remediate them per your risk assessment. But your Risk Management Policy fleshes that out with CVSS-based timelines. Critical within 30 days, High within 60, Medium and Low within 90.

Paul Netopski

Yeah, and that “in accordance with risk assessments” language is important. It doesn’t mean you ignore vendor severity, but you’re weighing that against your own impact and likelihood. For example, a High vulnerability on a disconnected lab system may not be as urgent as a Medium on an internet-facing VPN that’s in your CUI enclave. Your risk matrix and Business Impact Analysis templates help you justify those decisions.

Roz the Rulemaker

So to summarize the RA domain from the spreadsheet and your policies: you define how often you do risk assessments and scanning, you perform and record them, and you drive remediation and POA&M entries based on risk, not just on raw vulnerability lists. That’s what distinguishes a living risk program from a compliance artifact.

Paul Netopski

And just to connect this to prior episodes—we talked in the Configuration and Change Management episode about CM.L2-3.4.3 and 3.4.4: system change management and security impact analysis. What we’re describing here is the other half of that loop. Change management says, “Before you touch the system, analyze security impact.” The RA domain says, “Periodically, and when big things change, step back and reassess risk to operations, assets, and individuals.”

Roz the Rulemaker

Right. Think of risk assessment as the strategic view and change management as the tactical enforcement. If you only do one annual risk assessment and never revisit it when you deploy a new cloud environment or onboard a new managed security provider, you’re going to have a bad day in a CMMC assessment—and potentially an even worse day in real life.

Paul Netopski

Let’s pivot into policy, because CMMC is not just about practices; it’s about being able to show management intent. You’ve got a dedicated Risk Management Policy that maps straight to the 3.11.x controls, but it also pulls in NIST 800-171A, 800-30, and even ISO-style enterprise risk concepts.

Roz the Rulemaker

The first thing that jumps out is the definition of cybersecurity risk: risk to operations, resources, and other organizations due to unauthorized access, use, disclosure, disruption, modification, or destruction of information or IT. That’s essentially the NIST 800-30 definition tuned for a CUI environment.

Paul Netopski

Then the policy gets very concrete around 3.11.1. It says an organizational risk assessment must be completed at least annually. And—this is key—if significant changes happen to operations, assets, or individuals, you trigger another risk assessment instead of waiting for the calendar.

Roz the Rulemaker

They even enumerate what “significant changes” means. On the organizational operations side: new facilities, reorganizations, mergers and acquisitions, major contract awards, going public or private. For assets: big changes in hardware, software, cloud adoption, vendor changes for key security services. For individuals: turnover in roles like CIO, CISO, IT manager, HR director, CEO, CFO.

Paul Netopski

If you’re looking for a model for your own Level 2 environment, that list is gold. You can literally paste those bullets into your procedure for RA.L2-3.11.1 and say, “When any of these events occur, the CISO and Chief Risk Officer will initiate a targeted risk assessment using our Risk Assessment Report Template.” Then you point to the ticketing system for evidence.

Roz the Rulemaker

And because we’re talking about policy, we should touch on risk appetite. The Business Risk Management Policy you’ve got is aligned to ISO 31000 style enterprise risk management. It uses a risk matrix—impact versus likelihood—and defines consequence categories for safety, reputation, and financial impact.

Paul Netopski

Right. The risk matrix template defines “Insignificant” up through “Catastrophic” impact, and “Rare” up through “Almost Certain” likelihood. Then Exhibit A in the Business Risk Management Policy has a Risk Appetite Statement that talks about brand, reputation, regulatory compliance, performance, efficiency, IP, workplace safety, and financial reserves.

Roz the Rulemaker

For example, the policy says there’s very low tolerance for regulatory compliance breaches; only minor, non-substantive missteps are acceptable. For brand protection, it says the organization will aggressively defend its trademark even when the likelihood of legal success is low, as a signal of seriousness. For financial stability, it sets targets like nine months of operating reserves.

Paul Netopski

From a CMMC standpoint, that matters because RA.L2-3.11.3—remediate vulnerabilities in accordance with risk assessments—depends on having a defined notion of what “acceptable” risk is. If your risk matrix says a 4-by-4 “Major / Likely” risk is above appetite, then any vulnerability or scenario scoring that high either has to be treated, transferred, or the acceptance explicitly documented and approved by leadership.

Roz the Rulemaker

And that’s exactly where your Threat-and-Risk-Assessment template comes in. Each row lets you list a prioritized activity from the Business Impact Analysis; describe the risk using the threat profile and resource information; capture impact and likelihood “before controls”; then list existing controls and what the “after controls” risk score is. Finally, you choose a treatment—Terminate, Treat, Transfer, or Tolerate—and assign an owner and due date.

Paul Netopski

So a concrete example for a Level 2 contractor might be your cloud-based CUI enclave. Your Business Impact Analysis says, “Loss of access to the enclave for more than one business day is a Major impact to revenue and mission.” You then look at threats like ISP outage, misconfiguration, or cloud provider incident, and you score impact and likelihood using the matrix.

Roz the Rulemaker

If the “before controls” score is, say, 4 for impact and 3 for likelihood, that’s squarely in the orange or red zone depending on your color scheme. You’d then document controls: multi-region design by the provider, your own backup connectivity options, offline export of critical artifacts, incident response runbooks. If those reduce likelihood to 2, maybe the “after controls” score is 4-by-2. Management can then decide: is that within our appetite for operational risk, or do we need additional redundancy?

Paul Netopski

From the assessor’s chair, what I’m looking for is that there’s a clear line from policy to implementation. So I’d expect to see: the Risk Management Policy stating annual plus change-driven risk assessments; the Risk Appetite Statement and matrix defining your thresholds; the Threat Profile and Risk Assessment sheets showing actual scored risks; and the Risk Assessment Report Template filled out at least once a year and after big changes.

Roz the Rulemaker

And the roles section in the Risk Management Policy is also important evidence. It assigns sponsorship to the COO and CFO, operational ownership to the CISO, IT Systems Manager, and Network & Security Engineer, and oversight to a Chief Risk Officer. For CMMC, that maps nicely to the expectation that risk isn’t just an IT hobby; it’s an executive function with accountable owners.

Paul Netopski

One more very practical point: your policy explicitly allows leveraging third-party risk identifications—like insurance underwriter information or carrier questionnaires—as part of your risk assessment. That’s smart. If your cyber insurer says, “We see elevated ransomware risk on RDP and unpatched VPNs,” that should feed right into RA.L2-3.11.1 and 3.11.3, and into your vulnerability management and POA&M.

Roz the Rulemaker

So, to wrap this chapter: a CMMC-savvy Risk Management Policy does three things. It sets clear expectations and triggers for risk assessments, it defines risk appetite with a matrix so you can compare risks consistently, and it describes who owns the work. Your templates—Business Impact Analysis, Threat Profile, Risk Matrix, and Risk Assessment—are the tools that turn that policy into repeatable, auditable practice.

Paul Netopski

Now let’s make this really concrete with threats, third-party risk, and how all of this plugs into change management. Your Threat Profile template is basically a catalog of potential bad things organized by category: foreign risk, human capital risk, financial, environmental, operational, technology, regulatory, and so on.

Roz the Rulemaker

And the Risk Assessment Report Template complements that by walking through NIST SP 800-30’s steps: identify critical business processes, identify critical IT components, understand the impact of downtime, and then identify threats along multiple axes—adversarial, accidental, structural, and environmental. It even references NIST’s taxonomy of threat sources.

Paul Netopski

So if you’re a Level 2 contractor with a remote workforce and a cloud CUI enclave—pretty common scenario—you’d start by listing key processes: proposal development, engineering, contract performance, billing. Then you look at which of those are inside the CUI boundary: maybe engineering and some contract performance tasks live entirely in the enclave, billing lives in a separate system, and proposals are partly in and partly out.

Roz the Rulemaker

From there, you talk impact of loss and downtime. Your template prompts: “How many hours or days would there be a minor or major impact if infrastructure was down?” For CUI-related work, you might say, “Minor impact if the enclave is down for less than eight business hours; Major impact beyond one business day.” That gives you a way to anchor the impact axis in your risk matrix.

Paul Netopski

Then you walk through threat sources. Adversarial: individual attackers, organized crime, nation-state APTs. Accidental: user mistakes, admin misconfigurations. Structural: hardware failure, software bugs, environmental control problems. Environmental: regional power outage, hurricane, major ISP failure.

Roz the Rulemaker

Take ransomware as a concrete example. On your Threat Profile, you’d describe historical examples—maybe smaller peers in the DIB who were hit, or advisories from CISA about ransomware families targeting defense contractors. You’d list consequences: loss of availability of the enclave, potential data exfiltration, contractual reporting obligations, reputational damage. Then you’d list controls: EDR, offline backups, immutable storage, tested recovery procedures, user phishing training.

Paul Netopski

You’d then score impact, likely at the high end because losing your enclave for a week would be Major or Catastrophic. Likelihood might be Possible or Likely depending on your current control strength. Multiply those, map them to your matrix, and you’ve got a risk score that clearly lands above appetite. That drives specific actions: tightening backup RPO/RTO, hardening remote access, maybe adding 24/7 monitoring or threat hunting.

Roz the Rulemaker

Third-party risk fits in naturally here as well. Your templates already envision vendor and technology risk: there are categories for technology risk, third-party risk, and regulatory risk. For a CUI enclave in a commercial cloud, your threats include: misconfiguration by the provider, loss of service, or compromise of the SaaS that handles your ticketing, document management, or vulnerability scanning.

Paul Netopski

You can pull in data from SOC 2 reports, FedRAMP packages, CSP shared responsibility matrices, and insurer questionnaires as “threat intelligence” and as input to your RA.L2-3.11.1 process. If your CSP discloses a control exception or a major incident, that should trigger an out-of-cycle risk assessment and might change your risk score for “Cloud outage or compromise.”

Roz the Rulemaker

And don’t forget about more subtle third-party risks. A managed service provider who has remote admin access into your CUI enclave is a significant threat vector if their own security is weak. That becomes a specific line item in your Threat Profile: “Compromise of MSP leading to unauthorized access to CUI systems,” with capacity and likelihood scored accordingly.

Paul Netopski

Now, how does all of this tie back into change management? In our earlier episode on the Configuration Management domain, we talked about CM.L2-3.4.3 and 3.4.4—formal change control and security impact analysis. What we’re suggesting here is: treat significant changes to people, places, and technology as automatic triggers for a focused risk assessment using your templates.

Roz the Rulemaker

Let’s walk through those three categories. People first. Suppose your IT manager or CISO leaves. Your Risk Management Policy already lists “major changes to individuals responsible for operations, maintenance, or security of CUI assets” as a trigger for risk assessment. So you’d open a ticket, run a quick assessment of insider threat risk, key-man risk, and any gaps in knowledge transfer, then update your Risk Register and POA&M if needed.

Paul Netopski

Places: if you move offices, add a new facility, or shift to a different co-location or data center, that’s not just a physical protection story; it’s a risk assessment event. You may need to look at new environmental threats—floodplain, power quality, regional disasters—and reassess your Business Impact Analysis. That’s exactly what the Threat-and-Risk-Assessment and Threat Profile templates are for.

Roz the Rulemaker

Then technology. This is where change management and RA are joined at the hip. Moving CUI from one cloud environment to another, adding a new EDR, introducing an AI-based tool that touches CUI, or even “just” adding a new collaboration platform for engineers—those are all changes that should carry a little RA mini-checklist inside the change ticket.

Paul Netopski

In practical terms, what I recommend to clients is: your change advisory board form or Jira change ticket has a required section called “Security and Risk Impact.” It asks: does this change affect CUI scope? Does it introduce a new external dependency? Does it alter authentication, network boundaries, or logging? If yes, link to a short risk assessment entry using your Risk Assessment template and update the risk matrix if the profile shifts.

Roz the Rulemaker

And that’s also where risk appetite comes back in. If the “after controls” risk score for the proposed change ends up above your defined appetite—say a 5-by-3 critical risk—that change shouldn’t be rubber stamped. Management either needs to beef up controls, alter the change design, transfer the risk through contract or insurance, or explicitly accept and document that acceptance.

Paul Netopski

Done well, this doesn’t have to be bureaucratic. You’re leveraging the tools you already built: Business Impact Analyses, Threat Profiles, Risk Matrix, Risk Register, and your RA/L2-3.11.1 process. You’re just wiring them into the day-to-day workflow of change management so nobody has to remember, “Oh yeah, we were supposed to do a risk assessment for that migration six months ago.”

Roz the Rulemaker

And from the CMMC assessor’s perspective, that’s exactly the story they want to see: risk assessment that is periodic, triggered by meaningful change, tied to vulnerability scanning and remediation, and governed by a clear policy and risk appetite. Not a one-time spreadsheet that gets dusted off for the audit.

Paul Netopski

All right, we’ll leave it there for today. If you’re listening and thinking, “I’ve got pieces of this but not the whole picture,” the good news is you already have a strong foundation in your policies and templates. The next step is making them part of your normal operating rhythm.

Roz the Rulemaker

And as always, remember that CMMC’s risk requirements are not about pleasing auditors. They’re about making sure your organization understands where it’s vulnerable, what it can tolerate, and what it needs to fix before an adversary makes the decision for you.

Paul Netopski

Thanks for joining us on CMMC Unlocked. I’m Paul Netopski—

Roz the Rulemaker

And I’m Roz the Rulemaker—

Paul Netopski

We’ll catch you on the next episode.