CM-10: Software Usage Restrictions

CM-10 requires you to prove that every software product and its documentation are used within the bounds of the applicable license, contract terms, and copyright law, and that you can prevent or quickly correct unauthorized use. Operationalize it by assigning ownership, keeping an authoritative license position for in-scope software, and enforcing usage limits through procurement, configuration, and monitoring. ¹

Key takeaways:

• CM-10 is a “license and contract compliance” control as much as a security control; auditors will ask for proof, not intent. ¹
• Your fastest path is to standardize how software is requested, approved, deployed, and periodically reconciled against entitlements.
• Evidence wins: maintain contracts, entitlement records, deployments, and true-up/exception workflows tied to specific products.

The cm-10: software usage restrictions requirement is easy to misunderstand because it sounds like a generic “follow the rules” statement. In practice, assessors expect you to show that your organization can (1) identify what software is installed and being used, (2) map that use to the right contract and license terms, and (3) prevent or remediate usage that violates those terms. That includes “free” tools with click-through terms, enterprise SaaS subscriptions with seat limits, developer tooling with non-production clauses, and software documentation that carries its own restrictions.

This requirement matters most in environments where federal data is handled or where you inherit NIST SP 800-53 obligations through a contract, authorization boundary, or customer requirement. CM-10 also overlaps with common software asset management (SAM) and configuration management expectations: if you cannot reconcile entitlements to deployments, you will struggle to defend compliance during an assessment.

This page gives requirement-level implementation guidance you can execute quickly: ownership, scope, workflows, technical enforcement points, and the evidence set that tends to resolve audit questions without long debates. ²

Regulatory text

Control requirement (excerpt): “Use software and associated documentation in accordance with contract agreements and copyright laws;” ¹

Operator interpretation: You must ensure that your organization’s installation, access, copying, distribution, modification, and use of software (and its documentation) matches the permissions and restrictions in the applicable agreements (licenses, subscription terms, enterprise contracts, EULAs) and copyright law. ¹

What an assessor is really testing:

• You have a consistent method to determine “are we allowed to use this, in this way, for this purpose?”
• You can detect and correct over-deployment, over-use, or prohibited use.
• You can show evidence for the above without rebuilding the story during the audit. ¹

Plain-English interpretation (what CM-10 means day to day)

CM-10 means “no unlicensed software, no out-of-scope use, and no contract drift.” The control is satisfied when you can answer, for any in-scope system and software title:

1. Who approved it and under what terms (contract, purchase record, subscription, click-through).
2. Where it is deployed and who uses it (endpoints, servers, containers, SaaS accounts).
3. What restrictions apply (seat counts, geography, data use, non-production limits, user type restrictions like “named user” vs. “concurrent”).
4. How you enforce and reconcile (technical controls, periodic checks, and an exception path). ¹

Who it applies to (entity and operational context)

CM-10 commonly applies to:

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 is contractually required or inherited via an authorization boundary. ¹

Operational contexts where CM-10 becomes “exam visible”:

• Endpoint fleets with mixed admin rights and decentralized installs.
• Engineering environments with frequent tool adoption (open-source plus commercial).
• SaaS sprawl where teams buy seats on corporate cards.
• Virtualized/elastic infrastructure where “instances” can unintentionally exceed entitlements.

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

Use this sequence to operationalize CM-10 with minimal ambiguity.

1) Name an owner and define “in-scope software”

Owner: Assign a control owner in GRC or IT Asset Management, with execution partners in Procurement, Legal, IT Ops, and Security.

Scope decisions you must document:

• Which environments are in scope (production, corporate endpoints, build systems, test).
• Which software categories are in scope (OS, commercial apps, SaaS, agents, libraries where you have a license obligation).
• How you treat open-source (CM-10 still applies because license terms exist; enforcement is typically via policy and SDLC checks rather than seat counting). ¹

Deliverable: CM-10 control statement + implementation procedure that lists systems, roles, and enforcement points.

2) Centralize “source of truth” for contracts and entitlements

You need a record that ties each software title to:

• Contract / order form / EULA reference (or procurement ticket ID)
• Entitlements (seats, devices, cores, usage metric as applicable)
• Allowed use constraints (business purpose, affiliate use, geography, data restrictions, non-transferable clauses)
• Renewal/termination dates
• Owner (business and technical)

This can live in a SAM tool, CMDB, GRC system, or even a controlled spreadsheet at first. What matters is change control and auditability.

Minimum viable approach: top software by spend and top software by deployment footprint first, then expand.

3) Control how software is requested, approved, and deployed

Build a single path for introducing software:

Request intake

• Require requester to state: purpose, users, environment, and data types touched.
• Require a funding/owner field. Shadow IT often survives because nobody is accountable.

Approval

• Procurement/Legal confirms permissible terms.
• Security confirms the software is allowed for the environment and data classification.
• IT confirms deployment method and inventory coverage.

Deployment

• Enforce via managed software distribution for endpoints (MDM/endpoint management).
• For servers and containers, enforce via golden images, infrastructure-as-code modules, or artifact repositories with approvals.

Key control point: Block installs outside the approved path where feasible, or require a time-bound exception with compensating controls.

4) Maintain inventory and reconcile against entitlements (“effective license position”)

CM-10 becomes defensible when you can reconcile:

• Installed software and versions (discovery)
• Active users/seats (for SaaS)
• Entitlements owned (contracts)
• Gaps and remediation (uninstall, re-harvest seats, buy more, or document exception)

Practical reconciliation methods:

• Endpoint discovery reports from endpoint management/EDR
• SaaS admin console exports (active users, last login)
• Cloud billing and image registries for infrastructure software
• True-up events tied to renewal cycles

Write down your reconciliation cadence and triggers (new contract, renewal, major deployment wave, merger/acquisition integration).

5) Train the operators who create CM-10 risk

You do not need enterprise-wide training to start. Train the roles that cause the most license exposure:

• Desktop support and endpoint admins
• DevOps/platform engineers
• Procurement and accounts payable (to spot duplicate subscriptions)
• Engineering managers approving new tooling

Keep training content short: “what needs approval,” “what is prohibited,” and “how exceptions work.”

6) Define an exceptions and remediation workflow

Assessors expect reality: urgent installs happen. The control expectation is that you:

• Record the exception with scope and expiration
• Document compensating controls (limited access, temporary seat allocation, restricted environment)
• Close the loop (uninstall, purchase, or replace)

Tip: Tie exceptions to a ticketing system so you can show timestamps, approvals, and closure.

7) Make evidence repeatable (don’t scramble during audits)

Create a recurring evidence package for CM-10:

• Quarterly (or your chosen cadence) reconciliation report
• List of newly approved software and associated approvals
• Exception register and closure evidence
• Sample proof for a few high-risk software titles (contract → entitlement → deployments → remediation)

Daydream (as a GRC workflow hub) fits well here when you need CM-10 to be “audit-ready by default”: you map CM-10 to an owner, attach the procedure, and schedule recurring evidence tasks so the artifact set stays current rather than assembled under deadline. ¹

Required evidence and artifacts to retain

Retain artifacts that show both design (rules) and operation (proof it ran):

Governance

• CM-10 policy/control statement and implementation procedure (owner, scope, process)
• Software acquisition/approval standard (what requires review, who approves)

Contracts and licensing

• Contracts/order forms/EULAs (or references/locations) for in-scope titles
• Entitlement records (seats/devices/metrics) and renewal dates
• Records of true-ups, audits, or vendor communications where relevant

Operational proof

• Software inventory exports (endpoints/servers) with timestamps
• SaaS user/seat assignment exports
• Reconciliation worksheets or SAM reports showing entitlement vs deployment
• Tickets for approvals, deployments, and removals
• Exception register with approvals and expiration/closure

Access and change control tie-in

• Evidence that only approved admins can deploy software broadly (role assignments)
• Golden image/IaC approval records for base images/modules

Common exam/audit questions and hangups

Expect these questions and prepare answers with artifacts:

1. “Show me how you ensure software is used per license terms.”
   Provide the procedure, a sample contract summary, and a reconciliation report for that title. ¹

2. “How do you prevent unapproved software?”
   Show endpoint controls, admin rights management approach, and exception workflow.

3. “How do you cover SaaS subscriptions bought outside Procurement?”
   Show SSO/IdP app discovery, finance review triggers, and a process to bring subscriptions under management.

4. “What about open-source and documentation?”
   Show OSS intake rules (approved sources, license review where required) and documentation handling rules (no improper redistribution).

5. “Prove it’s operational, not a policy.”
   Provide time-stamped exports, closed tickets, and the last reconciliation’s remediation outcomes.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Fix
Treating CM-10 as a one-time policy publish	Auditors test operating effectiveness, not existence	Schedule recurring reconciliations and retain outputs
Relying only on purchase records	Purchases don’t prove actual installs/users	Combine entitlement data with discovery and SaaS admin exports
Ignoring engineering tooling and build agents	Licenses often restrict CI/build use	Inventory build environments and map tools to terms
No exception path	Teams bypass controls under deadlines	Provide time-bound exceptions with approvals and closure
Decentralized contract storage	You can’t prove terms quickly	Centralize references and ownership per software title

Risk implications (what can go wrong)

CM-10 gaps create two primary exposures:

• Contract and copyright noncompliance risk: over-deployment, unauthorized copying, prohibited use cases, or improper redistribution of documentation. ¹
• Security and operational risk: unmanaged software increases attack surface and reduces your ability to patch, standardize configurations, or respond to incidents.

In assessments, the most common failure mode is simple: you cannot produce credible evidence that your software usage matches your entitlements and terms.

Practical 30/60/90-day execution plan

You asked for speed. Use this plan as an operator, not a theorist.

First 30 days (stabilize and prove ownership)

• Assign CM-10 owner, backups, and RACI across Procurement, Legal, IT, Security.
• Write the CM-10 procedure: scope, approval path, reconciliation approach, exception workflow. ¹
• Stand up a central register for software titles, contracts, and entitlements (start with highest-risk titles).
• Pick evidence sources: endpoint inventory export, SaaS admin exports, contract repository.

Days 31–60 (implement control points and first reconciliation)

• Implement or tighten the software request/approval workflow (ticket required).
• Reduce uncontrolled installs: review admin rights; route installs through managed deployment where feasible.
• Run your first entitlement vs deployment reconciliation for a defined set of software.
• Open remediation tickets for variances; document decisions (remove, buy, exception).

Days 61–90 (make it repeatable and assessment-ready)

• Expand coverage to additional titles and environments (servers, build systems, privileged tools).
• Formalize recurring evidence tasks and a standard audit packet (procedure + last reconciliation + sample approvals + exception register).
• Test retrieval: can you produce proof for a software title in one working session without heroics?
• If you use Daydream, map CM-10 to the owner, attach the procedure, and automate evidence requests and reminders so the artifact set stays current between audits. ¹

Frequently Asked Questions

Does CM-10 apply to SaaS, or only installed software?

It applies to software broadly, including SaaS, because subscription terms and documentation still create usage restrictions you must follow. Your evidence should include seat/user assignment exports and the applicable subscription terms. ¹

How do we handle click-through licenses when there’s no negotiated contract?

Treat the click-through terms as the governing agreement, record where the terms are stored, and tie the software title to an approval record. If the terms are unacceptable for your environment, block the software or require an approved alternative.

What’s the minimum evidence set to pass an assessment for CM-10?

Keep (1) the CM-10 procedure, (2) contract/terms for sampled software, (3) an inventory/deployment report, and (4) a reconciliation or true-up record showing how you addressed variances. Assessors usually accept “show me for these sampled titles” if the artifacts are consistent. ¹

We can’t technically block all unapproved installs. Can we still meet CM-10?

Yes, if you can detect unauthorized installs quickly, remediate them, and show evidence of that process. Document the constraint, implement compensating controls (inventory + admin rights governance), and track exceptions.

Does CM-10 require a dedicated SAM tool?

No. CM-10 requires control and evidence. Many teams start with controlled spreadsheets plus endpoint/SaaS exports, then move to a SAM tool when scale and complexity demand it.

How should we treat open-source software under CM-10?

Open-source still has license terms. Operationalize it with an intake process for new dependencies, a method to record applicable licenses, and SDLC checks where they fit your environment and risk tolerance. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5