This is one of the harder CM practices because implementation varies dramatically depending on your environment. Application whitelisting ranges from simple to complex. But the principle is non-negotiable: on systems handling CUI, you should control what software can run. CM.L2-3.4.8 requires a deny-by-exception approach. That means starting with nothing allowed, and explicitly adding applications that are authorized. Application whitelisting works hand-in-hand with CM.L2-3.4.9, which prevents users from installing unauthorized software in the first place.
What the assessor is actually evaluating
The assessor is checking whether you have real application execution controls in place. This is one of those practices where your approach depends heavily on your environment.
Do you have a policy that limits what can run? Not “we don’t allow malware” in some vague sense. Is there an actual policy that says applications need to be approved before they run? Is there an approval process? Can you show it?
Is the policy enforceable on your systems? Whitelisting on Windows requires Applocker, Defender Application Guard, or a third-party whitelisting tool. On servers, it might mean removing execute permissions from directories where unsigned code could run. On managed Linux systems, you might control what packages can be installed. The mechanism depends on your OS and environment.
Do you have an approved application list? You should know what’s supposed to be running. Operating system binaries, line-of-business applications, system utilities. The list doesn’t have to be exhaustive, but it should be documented.
Is the policy actually working? Can someone still install random software despite the policy? The assessor will ask questions designed to test whether the control is real or just theoretical.
What a realistic SSP definition looks like
[Organization Name] implements a deny-by-exception application execution policy on all systems. Workstations are configured with [Applocker / application whitelisting tool] to restrict application execution to a pre-approved list of software. Users may not install applications without explicit approval from the IT Director. Unauthorized installation attempts are logged and reviewed.
The approved application list includes the operating system, authorized utilities, industry-standard productivity software, and line-of-business applications required for business function. The list is maintained by the IT Director and reviewed quarterly. Any application outside the approved list is blocked from execution.
Servers are configured to run only essential services and applications required for their function. No user-facing applications are installed on servers. Administrative tools are restricted to administrators only.
Key details:
It names the technology. Not “whitelisting is enabled.” Applocker or another specific tool. The assessor will want to verify the configuration and needs to know what to look for.
It defines who approves applications. The IT Director. Not “management” or “whoever asks.” A specific role responsible for the decision.
It includes a list of approved applications. Not every app under the sun. The list includes legitimate operating system, utilities, and business applications. The list is maintained and reviewed.
It addresses both workstations and servers. Different strategies for different system types. Servers have even stricter restrictions than workstations.
It mentions what happens when something is blocked. Unauthorized installations are logged. That provides evidence that the control is working.
How to present your evidence
- Application execution policy document
- Approved application list with business justification for each application
- Configuration screenshots showing whitelisting enabled (Applocker, etc.)
- Logs showing blocked or unauthorized application execution attempts
- Process documentation for approving new applications
- Quarterly reviews of the approved application list
When the assessor reaches CM.L2-3.4.8:
Your application execution policy. One page explaining your approach. For workstations, it should describe the whitelisting mechanism. For servers, it should describe how you restrict what can run. The policy should define the approval process and who maintains the approved list.
Your approved application list. The applications that are allowed to run. Operating system binaries and updates. Productivity software like Office. Business applications. IT management tools. Security software. For each, you should be able to explain why it’s on the list. The list shouldn’t be incredibly long. If you have hundreds of approved applications, the assessor will question whether you have real controls or just a token list.
Configuration evidence. Screenshots of your whitelisting tool showing it’s enabled and enforcing the policy. Applocker rules on a Windows system. A blacklist of installation directories on a server. The specific mechanism depends on your environment, but you need to show it’s configured.
Blocked execution logs. Evidence that the control is actually working. Screenshots or log excerpts showing attempts to run unauthorized applications and the enforcement action taken. This proves the policy isn’t just theoretical.
Application approval request and approval records. When someone needs a new application, what’s the process? Are there records showing the request, the evaluation, and the approval or denial? Walk through a recent example.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
No application control at all.** The assessor asks about your whitelisting policy and you don't have one. Users can install whatever they want. Systems are wide open.
Blacklisting instead of whitelisting.** You have a list of bad applications that are blocked, but anything else can run. That's the wrong direction. The standard requires deny-by-exception, which means whitelist.
Whitelisting that's not actually enforced.** The policy exists, but the control isn't configured. Applocker isn't actually enabled. Or it's in audit mode, not enforce mode. The policy is theoretical.
An approved list that's too large or poorly justified.** If you have 200 approved applications with no explanation for why they're there, the assessor will question whether you're actually controlling applications or just documenting the current state.
No mechanism for approving new applications.** When someone needs new software, there's no process. It just gets installed. There's no request, no evaluation, no approval record.
A real whitelisting tool that's enabled and enforcing. An approved application list that's reasonable and justified. Evidence that unauthorized software is blocked. A clear approval process for new applications. When the assessor can ask a user "what happens if you try to run something not on the approved list" and the user can demonstrate that it's blocked, they check the box and move on.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP/MSSP
If your MSP manages systems and application whitelisting, you need to understand the controls they’ve implemented.
Ask your MSP for:
The whitelisting policy and approved application list. You should have a copy. You’re the one responsible for compliance. You need to know what applications are approved and why.
Configuration documentation. How is whitelisting enforced on each system type? What tool is being used? Is it in enforce mode? Screenshots of the actual configuration are helpful.
Logs of blocked executions. Evidence that the control is working. Your MSP should be able to provide these, at least in summary form.
The approval process for new applications. When someone in your organization needs software, what’s the workflow? Do they request it? Does your organization approve it? Does the MSP add it to the whitelist? You should have documentation of how this works.
Periodic reviews of the approved list. The list shouldn’t be static. Your MSP should be removing applications that are no longer needed and flagging applications that might be redundant.
Windows updates can create challenges with whitelisting. When Microsoft releases an update, new binaries might be added to the system. If your whitelisting is too strict, it might block components of a legitimate update. The best MSSPs have a process for updating the whitelist with Windows updates. Ask if they have that process. If they're just doing manual updates, understand the lag time and document it in your SSP.
This page covers CM.L2-3.4.8 from NIST SP 800-171 Rev 2 (3.4.8). The guidance here is based on experience in real CMMC assessments and is intended to help you prepare. It is not legal or compliance advice. Your organization’s situation is unique, and you should work with qualified professionals for formal assessment preparation.