CM.2.008 — Apply Deny-by-Exception Policy to Prevent Use of Unauthorized Software

What CM.2.008 means in plain English

This is the formal policy underpinning CM.2.007. You need a written policy that explicitly states your approach: either (a) block specific known bad software and allow everything else (blacklisting—easier to start with), or (b) only allow specifically approved software and block everything else (whitelisting—more secure, recommended by DoD). Most small shops start with blacklisting and then move to whitelisting. Document which approach you use, why, and how it is enforced. Assessors want to see the policy document, not just the technical control.

The assessment question

“Is there a written software use policy that explicitly adopts either a deny-by-exception (blacklist) or deny-all-permit-by-exception (whitelist) approach, and is this policy enforced by technical controls with evidence of both?”

How to implement CM.2.008

1. Write a one-page "Software Use Policy" that states: (a) the approach taken (blacklist or whitelist), (b) the list of prohibited software categories (peer-to-peer file sharing, torrent clients, unapproved remote access tools, cryptocurrency mining software, games), (c) the list of approved software (if whitelist approach), and (d) the consequences of violating the policy.
2. For a blacklist approach: use Windows Defender Application Control (WDAC) or Group Policy > Software Restriction Policies to block specific known-bad applications by hash, certificate, or path. Maintain a "Prohibited Software List" updated when new threats are identified (reference CISA Known Exploited Vulnerabilities catalog at cisa.gov/known-exploited-vulnerabilities-catalog).
3. For a whitelist approach (recommended): use AppLocker or WDAC configured in "deny-all, permit-by-exception" mode as described in CM.2.007. The approved software inventory from CM.2.007 becomes your permit list.
4. Align the written policy with your technical enforcement: if your Group Policy enforces a whitelist, your written policy should say "deny-all, permit-by-exception." Assessors will verify that the policy and technical controls are consistent.
5. Review and update the software use policy annually or when new contract requirements are received. Document the review with a date and signature.

Evidence your assessor will ask for

• Written Software Use Policy specifying blacklist or whitelist approach, prohibited software categories, and enforcement mechanism
• Technical control configuration (WDAC, AppLocker, or SRP policy export) consistent with the written policy
• Evidence of policy review date and approver signature
• Prohibited software list (if blacklist approach) or approved software list (if whitelist approach)
• Evidence that the policy has been communicated to all users (e.g., included in annual awareness training)

More Configuration Management controls