CM-7(5): Authorized Software — Allow-by-exception

To meet the cm-7(5): authorized software — allow-by-exception requirement, you must explicitly identify the software that is permitted to run only as an exception to your default-deny/allowlist posture, and make that exception list controlled, justified, and reviewable. Operationalize it by maintaining an authoritative exception inventory tied to approvals, technical enforcement, and periodic validation. ¹

Key takeaways:

• Treat “allow-by-exception” software as a governed list with business justification and time bounds, not an informal workaround.
• Tie each exception to technical enforcement (application control rules) plus compensating controls and monitoring.
• Keep audit-ready evidence: exception register, approvals, rule configurations, and review results. ¹

CM-7(5) is one of those requirements that gets interpreted loosely (“we have an allowlist tool”) and then fails in an assessment because nobody can produce a clean, authoritative list of what is allowed by exception, who approved it, and how the exception is technically enforced. The control’s focus is not general software inventory. It is the exception layer: software that would otherwise be blocked under your authorized-software strategy, but is allowed due to a specific business need.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing CM-7(5) is to define a narrow, testable outcome: “We can produce a current exception list for each in-scope environment, and each entry maps to (1) an approval, (2) an enforcement rule, (3) monitoring/compensating controls, and (4) a review decision.” That outcome turns a vague requirement into a repeatable compliance motion you can assign to an owner, build into change management, and evidence continuously.

This page gives requirement-level implementation guidance you can hand to endpoint engineering, IT operations, and security operations without rewriting it into technical theory. ²

Regulatory text

Control statement (excerpt): “Identify {{ insert: param, cm-07.05_odp.01 }};” ¹

How an operator should read this: CM-7(5) requires you to identify the software that is authorized as an exception to your baseline authorized-software approach. Practically, you need a managed list of “allowed-by-exception” software that is:

• Explicit (named items, not categories like “admin tools”)
• Controlled (approval, ownership, constraints)
• Technically enforced (rules/policies in your application control or endpoint tooling)
• Periodically reviewed and re-justified

The outcome you should be able to demonstrate to an assessor is simple: “We know exactly what software is allowed only by exception, where it is allowed, and why.” ¹

Plain-English interpretation

CM-7(5) is the exception-handling requirement for authorized software. Your organization should operate with a baseline policy that only approved software can run (however you implement that baseline). CM-7(5) then forces discipline around the inevitable exceptions: niche business apps, legacy dependencies, specialized admin tools, and time-limited troubleshooting utilities.

“Allow-by-exception” means the default stance is restrictive. If something must run outside the standard list, it goes through a documented exception process and lands on a controlled exception register. That register is what you “identify” under CM-7(5). ¹

Who it applies to

Entity scope

• Federal information systems
• Contractor systems handling federal data ¹

Operational scope (where this becomes real)

• Endpoints (workstations, privileged admin workstations)
• Servers (especially shared admin servers and app servers)
• VDI environments
• Containers and golden images where software packaging occurs
• High-risk enclaves (systems with elevated privileges or sensitive datasets)

If you have separate enclaves or tenants, treat CM-7(5) as per-environment: exceptions allowed in a dev lab should not automatically exist in production.

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

1) Define “exception” precisely in your standard

Write a short definition that operations can apply consistently:

• Exception software = software not on the standard authorized list but permitted to execute due to approved business need.
• Specify whether this includes portable executables, scripts, browser extensions, drivers, SaaS agents, and package managers.

Deliverable: “Authorized Software Exception Standard” (1–2 pages) that states what must be captured for each exception. ²

2) Assign ownership and decision rights

Make one team accountable for the exception register and the enforcement rules (often Endpoint Security/IT Sec Engineering). Define approvers:

• Business owner (need)
• Security (risk acceptance/conditions)
• IT operations (supportability)
• Privacy or legal, if relevant to data handling

Deliverable: RACI for exception intake, approval, implementation, and review.

3) Build an exception register that is audit-testable

A spreadsheet can work early; a ticketing system or GRC workflow scales better. Your register should capture, at minimum:

Field	What “good” looks like
Software identifier	Publisher, product name, version range; hash/signing info where possible
Scope	Devices/groups/environments where allowed
Justification	Specific business requirement, not “needed”
Approval	Approver names/roles, date, ticket/change record
Control conditions	Constraints (signed-only, specific path, specific user group)
Compensating controls	Monitoring, EDR rules, logging, least privilege
Expiration/review	Review date or trigger (version change, incident, vendor patch)
Enforcement mapping	Policy/rule name in the technical tool

Deliverable: Exception register with unique IDs that tie to tickets/changes.

4) Tie each exception to technical enforcement

CM-7(5) fails in practice when the list exists but is not enforced. For each exception:

• Implement an allow rule in your application control / endpoint management tool
• Prefer “allow by publisher signature” or “allow by hash” over broad path-based allows
• Apply scoping: only the smallest necessary device group or server role
• Record the rule/policy identifier back into the register

Deliverable: Evidence that the enforcement rule exists and is scoped as documented (screenshots/export, policy JSON, or tool report).

5) Add guardrails: monitoring + constraints

Allow-by-exception software should have tighter guardrails than standard software:

• Alerts on first run, unusual parent process, or network egress
• EDR detection exceptions should be reviewed separately; do not bundle “allow-to-run” with “ignore-alerts”
• Run under least privilege where possible; require privileged access management for admin tools

Deliverable: Compensating control notes per exception entry and SOC runbooks for high-risk exceptions.

6) Operationalize review and removal

Define review triggers that force re-approval:

• New major version or unsigned binary
• Business owner change
• Incident involving the software
• Environment change (moving from test to prod)

Your review should produce one of three outcomes: renew, tighten scope/conditions, or remove.

Deliverable: Review log entries, decisions, and evidence of rule removal where applicable.

7) Make it assessable: test the control yourself

Run a lightweight internal test:

• Sample exception entries
• Verify the approval exists
• Verify the rule exists in the tool and matches scope/conditions
• Verify the software actually runs only where intended (and is blocked elsewhere, if your tooling supports reporting)

Deliverable: Self-assessment worksheet and remediation tickets.

Required evidence and artifacts to retain

Keep evidence that proves identification + governance + enforcement:

1. Authorized software exception standard/procedure (what qualifies, required fields, approval path). ²
2. Exception register export (current as-of date, includes all required fields).
3. Approval artifacts (change tickets, risk acceptances, CAB minutes, security sign-off).
4. Technical enforcement evidence (policy/rule exports, configuration screenshots, MDM/app control reports).
5. Scoping evidence (device group membership, server role lists, environment boundaries).
6. Review evidence (periodic review meeting notes, recertification tickets, removal actions).

If you use Daydream to manage your control narrative and evidence mapping, keep a single CM-7(5) control record that links the owner, procedure, and recurring evidence artifacts to reduce scramble during assessments. ¹

Common exam/audit questions and hangups

Assessors tend to ask the same things because they are easy to test:

• “Show me the list of software allowed by exception for production endpoints.”
• “Pick one exception and prove it was approved, implemented, and reviewed.”
• “How do you prevent exceptions from expanding over time?”
• “How do you detect unauthorized software that is not on the exception list?” (This often crosses into CM-7 baseline expectations, but CM-7(5) will still be probed through exception discipline.)
• “What happens when the software updates?”

Common hangup: teams present a general software inventory. That does not answer CM-7(5). The question is the exception subset and its governance. ¹

Frequent implementation mistakes and how to avoid them

1. Exception list has vague entries (“Java”, “Admin tools”)
   Fix: require precise identifiers and scope. If you cannot identify it, you cannot control it.

2. Approvals exist but are not enforceable
   Fix: require an “enforcement mapping” field that references the exact policy/rule ID.

3. Path-based allows that permit easy bypass
   Fix: prefer publisher signature or hash-based rules; if path-based is unavoidable, constrain permissions on the allowed path.

4. Exceptions become permanent by default
   Fix: add review triggers and require an explicit renew decision; tie renewal to business ownership.

5. Mixing “allowed to execute” with “ignored by security tooling”
   Fix: separate application control exceptions from EDR/IDS suppression workflows; require extra scrutiny for detection suppressions.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat CM-7(5) primarily as an assessment and breach-risk issue rather than a citation-driven enforcement topic.

Operational risk is straightforward:

• Exception software is where attackers hide because it receives less scrutiny and often runs with elevated permissions.
• Poorly scoped exceptions become shadow allowlists.
• Untracked exceptions undermine incident response because you cannot quickly distinguish authorized behavior from compromise.

CM-7(5) reduces these risks by forcing identification, control, and review of the exception surface. ²

Practical 30/60/90-day execution plan

First 30 days (stabilize the requirement)

• Name a control owner and publish the definition of “allow-by-exception” software.
• Create the exception register template and intake workflow (ticket form + required fields).
• Perform a discovery sweep with endpoint/server teams to identify known exceptions already in place.
• Record the top-risk exceptions first (admin tools, scripting engines, remote access utilities), with approvals and scoping.

Next 60 days (connect governance to enforcement)

• Map each exception to an enforcement rule in your tooling; close gaps where exceptions are “tribal knowledge.”
• Add minimum constraints (scoping, signing requirements, least privilege expectations) for each exception.
• Establish a review cadence and triggers; schedule the first recertification.
• Run an internal sample test and document results like an assessor would.

By 90 days (make it repeatable and auditable)

• Integrate exception approvals into change management so exceptions cannot be implemented out-of-band.
• Create dashboards or recurring exports that show: number of exceptions, upcoming reviews, expired items, and high-risk categories.
• Tune SOC monitoring for high-risk exception executions and document response steps.
• Centralize evidence mapping (for example in Daydream) so CM-7(5) has a consistent narrative, owner, procedure, and recurring artifacts ready for audits. ¹

Frequently Asked Questions

Does CM-7(5) require a specific tool (application allowlisting software)?

The requirement is outcome-based: you must identify authorized software allowed by exception and be able to prove it is controlled. A tool makes enforcement and evidence easier, but the control is evaluated on identification, governance, and demonstrable operation. ¹

What counts as “software” for the exception list: scripts, browser extensions, drivers?

Define “software” in your procedure and apply it consistently. If a script, extension, or driver can execute code or change system behavior in-scope, treat it as software for exception purposes and capture it in the register. ²

How detailed does identification need to be?

Detailed enough that engineering can enforce it and auditors can test it. Prefer publisher + product + version bounds and add signing or hash identifiers where your tooling supports it. ¹

We have many exceptions in development. Do we need to track them all?

Track exceptions for in-scope systems and environments handling federal data, and separate dev/test from production in the register. If dev/test is in scope, keep it, but scope rules so dev exceptions do not drift into production. ¹

How do we handle emergency exceptions during outages?

Allow emergency approvals, but require a ticket, a time-bound scope, and a post-incident review that either converts the exception into a standard approved item or removes it. Capture the emergency pathway in the written procedure so it is not informal. ²

What evidence is most likely to fail an audit?

A register without approvals, approvals without enforcement proof, or enforcement rules that are broader than the documented scope. Build a one-sample “show me” packet for any exception so you can produce evidence quickly. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5