Application Execution Policy

Pick a policy, name it in writing, and the choice itself is objective [a].

The requirement accepts either deny-by-exception or deny-all, permit-by-exception. Objective [a] wants the written policy naming which one you run, [b] wants the list of software it governs, and [c] wants the mechanism enforcing it as specified.

Deny-by-exception is compliant under this requirement as written.

The requirement text offers it as an option, and a written deny list enforced by your endpoint tooling satisfies all three objectives. Populate the list deliberately: end-of-life software, unapproved remote access and VPN clients, keyloggers, games, alternatives to tools you have standardized, and products prohibited in federal contracting. Then use the CM.L2-3.4.1 software inventory to confirm nothing on the list is installed.

Allowlisting is the stronger policy, and the operating system already ships the tooling.

AppLocker and App Control for Business enforce permit-by-exception on Windows. Start by allowing digitally signed software from your approved publishers. Run in audit mode until you understand the noise. Then enforce, and extend the policy to scripts and libraries as you mature.

The installed-software inventory is not an allowlist.

When the list of allowed software is whatever is currently installed, anything anyone installs becomes authorized the moment it lands. The list under [b] is decided in advance. The inventory is what you reconcile against it.

This requirement governs execution. CM.L2-3.4.9 governs installation.

Blocking a program from running and controlling who installs software are separate requirements with separate evidence. An execution policy covers the first. Installation rights and monitoring cover the second, and the software inventory from CM.L2-3.4.1 feeds both.