CM-7(4): Unauthorized Software — Deny-by-exception

CM-7(4): Unauthorized Software — Deny-by-exception requires you to identify what software is not authorized to run in your environment and technically enforce blocking by default, allowing only explicitly approved exceptions. Operationally, you need an approved software allowlist, a controlled exception workflow, and endpoint controls that prevent execution or installation outside that list. ¹

Key takeaways:

• Deny-by-exception means “block unknown software by default; allow only approved software and approved exceptions.”
• The control is assessed on technical enforcement plus governance: ownership, exception approvals, and repeatable evidence.
• Auditors look for proof that controls actually block execution and that exceptions are time-bound, reviewed, and tied to business need.

The cm-7(4): unauthorized software — deny-by-exception requirement is where policy language meets real operational friction. Business teams want tools quickly; security teams want to stop unvetted executables, scripts, browser extensions, and admin-installed apps from becoming an untracked attack path. CM-7(4) forces a default posture: software is “not allowed” unless you have explicitly approved it and can prove you enforce that decision on endpoints and servers.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing CM-7(4) is to treat it as three connected deliverables: (1) a clear definition of “unauthorized software” for your environment, (2) an allowlist and exception process that is practical enough to be followed, and (3) technical controls that make the policy real by blocking execution or installation outside the allowlist. Your assessment risk is rarely about whether you wrote a policy. It’s about whether you can demonstrate consistent deny-by-exception enforcement and show clean exception hygiene during a sample window.

This page gives requirement-level guidance you can hand to control owners and then audit against. It also calls out evidence artifacts you should standardize so CM-7(4) becomes routine, not a scramble. ²

Regulatory text

Requirement (excerpt): “Identify {{ insert: param, cm-07.04_odp.01 }};” ¹

Operator meaning: CM-7(4) is an enhancement to least functionality focused on unauthorized software under a deny-by-exception model. The regulatory excerpt is short because the “how” is left to your organization: you must define what constitutes unauthorized software in your system context and then run a program that identifies it and supports blocking it by default with controlled exceptions. ¹

Plain-English interpretation (what CM-7(4) expects)

You need to be able to answer three questions, consistently:

1. What software is allowed to run here? (approved list)
2. What happens if something else appears? (blocked or prevented from running/being installed)
3. Who can approve exceptions, and how do you control exception sprawl? (workflow, time bounds, reviews)

“Deny-by-exception” is the opposite of the common “block known-bad” approach. In practice, you treat any software not explicitly approved as unauthorized, even if it is popular or “generally safe.” The operational challenge is balancing speed (business enablement) with control (preventing unknown code paths).

Who it applies to (entity and operational context)

CM-7(4) is commonly applied in:

• Federal information systems assessed against NIST SP 800-53. ¹
• Contractor systems handling federal data, including regulated environments where NIST SP 800-53 controls are flowed down contractually (for example, security requirements in federal contracting). ¹

Operationally, it applies wherever software execution occurs:

• End-user endpoints (managed laptops/desktops)
• Servers (including build servers and shared admin hosts)
• VDI / shared workstations
• High-integrity environments (jump boxes, privileged admin workstations)
• Cloud workloads where “software” includes packages, agents, and runtime dependencies

If you are a GRC lead, you should scope CM-7(4) by system boundary first. Trying to enforce allowlisting across every asset class at once is a common way to create unmaintainable exception volume.

What you actually need to do (step-by-step)

1) Assign ownership and define “unauthorized software”

• Name a control owner (usually Endpoint Engineering, IT Security, or Platform Security).
• Define “software” for your environment: executables, installers, scripts, libraries, packages, browser extensions, unsigned binaries, portable apps, and admin tools.
• Define “unauthorized”: not on the approved list and not covered by an approved exception.

Deliverable: a one-page CM-7(4) operating standard that names who approves, who implements, and where evidence lives.

2) Build your approved software allowlist (and keep it small)

Start with categories that reduce review friction:

• “Standard corporate software” (productivity, conferencing, security agents)
• “Role-based toolsets” (engineering IDEs, finance tools, design tools)
• “Privileged admin tools” (restricted to admin workstations)

Define allowlist attributes you will recognize in enforcement tools:

• Publisher/signing certificate
• File hash (more brittle)
• Path rules (high risk if writable)
• Package signatures and repositories (for Linux/package managers)

Practical tip: prefer publisher/signing rules where feasible; it reduces operational churn compared to hash-only rules.

3) Implement technical enforcement (block by default)

Your technical approach depends on platform, but auditors will expect the policy to be enforced, not advisory.

Common enforcement patterns:

• Endpoint application control / allowlisting (Windows/macOS)
• Server allowlisting or execution control for admin hosts
• Mobile device controls for managed mobile fleets
• Container image policy controls for workloads (allowing only signed/approved images and registries)

Minimum operational expectation: when unauthorized software appears, it is blocked from running or installing, and that event is logged in a way you can retrieve for evidence.

4) Design the exception process (the “by-exception” part)

Define a workflow that can be executed quickly:

• Requester submits: software name, version, publisher, business need, systems/users impacted, requested duration.
• Security review: risk rating, validation checks (source authenticity, signature), licensing checks if applicable.
• Approval authority: named approver(s) with separation of duties where feasible.
• Implementation: endpoint team adds an allow rule scoped to the request.
• Expiration: exceptions should end automatically or be reviewed on a regular cycle you define in your standard.

Operational rule that helps: exceptions must be scoped (who/what/where) and time-bound (even if “renewable”). Time-bounding keeps you from turning “exceptions” into a second allowlist with no governance.

5) Create a detection-and-response loop for unauthorized software

CM-7(4) is stronger when it includes proof that you identify unauthorized software, not just claim you block it.

• Monitor for execution/install attempts blocked by application control.
• Monitor software inventory for newly installed packages.
• Triage: false positive, required business tool (route to exception), or policy violation (remove and investigate).

6) Operationalize review cadence and metrics (qualitative, audit-friendly)

Avoid vanity metrics. Track what you can defend in an audit:

• Number of exception requests opened/approved/denied
• Average time to approve a legitimate tool
• Top sources of unauthorized software attempts (by team or asset group)
• Exception renewals and expirations

If you use Daydream, treat it as the system of record for the CM-7(4) control mapping: owner, procedure, and recurring evidence artifacts. That mapping becomes your audit binder backbone and helps you avoid “missing implementation evidence,” which is a common assessment failure mode. ¹

Required evidence and artifacts to retain

Use an evidence set you can produce on request, without custom work:

Governance artifacts

• CM-7(4) control narrative: scope, definition of unauthorized software, deny-by-exception statement, roles.
• Approved software standard (allowlist policy) and change history.
• Exception procedure (including approvers and SLAs you set internally).

Operational artifacts

• Current allowlist export (tool output) showing approved rules and scope.
• Application control policy configuration screenshots or exported config.
• Sample blocked execution logs showing denial events.
• Exception tickets: request, risk review notes, approval, implementation confirmation, expiry/renewal decision.
• Periodic review evidence: meeting notes, exception review report, or attestations by control owner.

Testing artifacts

• A simple test script or procedure demonstrating that an unauthorized binary is blocked on a representative endpoint group, with log capture.

Common exam/audit questions and hangups

Expect these and pre-build answers:

• “Show me how unauthorized software is defined.” If the definition is vague (“unapproved software”), you still need boundaries: what counts as software, and where the control applies.
• “Prove it’s deny-by-exception, not detect-only.” Auditors will ask for policy enforcement outputs, not just inventory.
• “How do exceptions expire?” If exceptions never expire, they become de facto approvals without governance.
• “How do you prevent local admin users from bypassing controls?” If admins can disable enforcement, auditors will treat CM-7(4) as weak unless compensating controls exist.
• “What is your evidence for ongoing operation?” A single screenshot from last year reads like shelfware.

Frequent implementation mistakes (and how to avoid them)

1. Allowlist defined only in a spreadsheet. Fix: enforce the allowlist in the endpoint/server control plane and export it for evidence.
2. Hash-based allowlisting everywhere. Fix: use publisher/signature rules where possible; reserve hashes for niche cases.
3. Exceptions with no scope. Fix: require user group, device group, and justification fields; deny “global exception” requests by default.
4. No expiry on exceptions. Fix: enforce expiry or scheduled review in the ticketing workflow.
5. Engineering environments ignored. Fix: explicitly define how you handle developer tooling (signed packages, approved repositories, controlled endpoints).
6. No log retention plan. Fix: align blocked event logs to your broader security logging retention standard so you can produce audit samples.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat CM-7(4) as an assessment-driven control: your risk is failing an authorization, customer security review, or contractual requirement because you cannot demonstrate deny-by-exception operation and evidence. ¹

Practically, unauthorized software controls reduce the likelihood that unapproved remote access tools, credential dumpers, or “helpful utilities” become persistent footholds. From a GRC standpoint, CM-7(4) also strengthens your change management story: software introduction becomes a controlled change, not an end-user event.

Practical execution plan (30/60/90-day)

First 30 days (foundation)

• Confirm in-scope system boundary and asset classes.
• Appoint control owner and backup owner.
• Write the CM-7(4) operating standard: definitions, roles, exception workflow, evidence list.
• Inventory current software and identify top “shadow IT” tools to plan allowlisting.

Days 31–60 (enforcement pilot)

• Choose enforcement tooling per platform and configure deny-by-exception for a pilot group.
• Build initial allowlist for standard corporate apps plus a limited set of role-based tools.
• Stand up exception ticket fields and approval routing.
• Run a tabletop test: request an exception, approve it, implement it, and confirm enforcement logs.

Days 61–90 (scale and evidence hardening)

• Expand enforcement scope to additional device groups and at least one server/admin segment.
• Establish recurring exception review and clean up stale approvals.
• Standardize evidence exports (monthly or per assessment cycle) and store them centrally.
• In Daydream, map CM-7(4) to the named owner, implementation procedure, and recurring evidence artifacts so audits do not depend on tribal knowledge. ¹

Frequently Asked Questions

Does CM-7(4) require a specific tool (AppLocker, WDAC, etc.)?

No tool is named in the requirement text. Auditors will still expect technical enforcement that achieves deny-by-exception and produces logs you can retain. ¹

What counts as “unauthorized software” in practice?

Start with “not explicitly approved for this system boundary” and then list included types like executables, scripts, and extensions in your operating standard. Consistency matters more than perfection because the control is assessed against your documented and implemented approach. ¹

Can we meet CM-7(4) with software inventory plus manual removal?

Inventory helps identify unauthorized software, but deny-by-exception implies prevention by default with controlled exceptions. If you rely on manual cleanup, document compensating controls and expect tougher audit scrutiny on effectiveness evidence. ¹

How do we handle developer tools without creating constant exceptions?

Create role-based allowlists for engineering endpoints and approve repositories and signed packages, not individual binaries where possible. Put guardrails around high-risk tools (remote admin, unsigned interpreters) and require stronger justification.

What evidence is the fastest to produce during an audit?

An allowlist export, a sample of blocked execution logs, and a small set of exception tickets showing approval and expiry give auditors a complete story quickly. Pair those with a short control narrative that ties them together. ¹

Who should approve exceptions: Security, IT, or the business?

Put Security or a delegated security approver in the approval chain because CM-7(4) is a security control. The business should provide justification and scope, but you want a consistent risk gate before adding allow rules.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5