CM-11 User-installed software: requirements and evidence

What CM-11 user-installed software asks an organization to govern

CM-11 requires an organization to set a defined policy for software that users install, enforce that policy through defined methods, and monitor compliance at a defined frequency. Those three elements, the policy, the enforcement and the monitoring cadence, are what an assessor will look for first. If an auditor, a contract or an internal review has asked how user-installed software is controlled, the answer must name each of them and show where the organization set the values. The control sits in the SP 800-53B low, moderate and high baselines and is not selected for the privacy baseline.

The risk is practical. An unapproved or unlicensed application can become an entry point for malware, a source of license exposure, or a driver of configuration drift that no inventory reflects. The control is hard in practice because endpoints are fragmented across offices, home networks and laptops, and many users hold local administrator rights that let them install almost anything. Before any tooling is chosen, the organization should confirm who may install software, which installation methods are allowed (for example, a managed software catalog or self-service portal), and who approves exceptions. These decisions belong to the organization, which owns the policy and the accountability for it.

DeployOpen can help prepare the systems and evidence that show CM-11 operating: self-hosted endpoint query tooling, documented enforcement settings and monitoring reports that an independent assessor can examine. DeployOpen does not write the policy on the organization's behalf, and it does not issue assessment results. The assessor, not the implementation partner, decides whether the control is met. A useful first step is to ask the assessor which artifacts they expect for the examine, interview and test methods named in SP 800-53A, so the evidence is built to match those expectations from the start.

Which systems, teams and third parties CM-11 covers

CM-11 applies only where the organization's own categorization and system boundary bring a system into a baseline that selects it. The cards below cover the decisions that set that boundary and the evidence volume that follows from it, from the systems and endpoints in scope to the teams and third parties who install software.

Systems in the low, moderate and high baselines

CM-11 is selected in the SP 800-53B low, moderate and high baselines, so a system's impact categorization decides whether the control applies at all. Confirm the categorization in the system security plan, then check which baseline it maps to. A system categorized at a level that selects CM-11 needs a documented software installation policy, defined enforcement methods and a monitoring frequency, even if the rest of the environment is out of scope.

Privacy baseline is not a trigger

CM-11 is not selected in the privacy baseline. A system whose only obligations come from the privacy baseline does not inherit CM-11 from that baseline alone. Confirm this against the privacy baseline profile in the current release, and record the reasoning in the control allocation so an assessor can see why the control was or was not applied.

Corporate laptops and managed endpoints

Corporate laptops are the population where users most often install software, so they usually drive most of the CM-11 evidence. Decide whether standard users can install software at all, whether installs go through an approved catalog, and how exceptions are requested and recorded. Endpoint inventories from osquery or Fleet can show which hosts carry software outside policy.

Servers and privileged installation

Servers are generally installed through change control rather than by end users, but a server with an interactive login can still accept user-installed software. Decide which server roles allow user installs at all, and confirm who holds administrative rights to install software. Those answers determine whether the privileged installation enhancement applies to your environment.

VDI and bring-your-own devices

Virtual desktops that users can personalize, and personal devices that access corporate systems, are often where software governance is weakest. Decide whether the organization's boundary includes them, and if so, whether the policy covers software installed inside a session or on a device the organization does not own. Each population needs its own monitoring method and its own evidence.

Policy owners and enforcement owners

The policy owner, usually security or IT governance, sets which software is allowed, while the enforcement owner, usually endpoint or platform engineering, configures the mechanisms that block or detect installs. Document both roles in the configuration management plan so that the monitoring frequency has a named owner. An implementation partner can build the enforcement and evidence, but the organization keeps the policy decisions.

Managed service providers and contractors

When a managed service provider or contractor installs software on in-scope systems, their installs fall under the same policy as employee installs unless the agreement says otherwise. Confirm in the contract whether they act as users or as administrators, and require that their installations appear in the same monitoring records. Ask for these terms before work starts, because the evidence must cover their activity too.

How an assessor tests CM-11 user-installed software

This table pairs each SP 800-53A determination statement for CM-11 with the assessment methods, the objects an assessor typically requests, the evidence that passes and common findings. Read it as a checklist for what to prepare before an assessment, since a policy alone rarely satisfies all three statements.

Assessment element	Assessor requests (examine, interview, test)	Evidence that passes	Common findings
Determination statement 1: policy for user-installed software is defined	Examine: configuration management plan, list of rules governing user-installed software	Approved written rules stating who may install which software categories, with owner and review date	Policy exists only in a general CM plan with no software-specific rules
Determination statement 2: enforcement through defined methods	Test: organizational processes governing user-installed software on the system; examine: list of rules governing user-installed software	Named enforcement methods (for example, endpoint policy checks or allow-listing) with a sample of hosts showing the rules applied	Rules are written but no method is named, or the method is not configured on the systems in scope
Determination statement 3: policy compliance is monitored at a defined frequency	Examine: system monitoring records, continuous monitoring strategy, system audit records; interview: personnel responsible for governing user-installed software	Scheduled compliance reports or query results showing passing and failing hosts, with the frequency stated in the strategy	Monitoring records exist but no frequency is defined, or the frequency in records differs from the strategy
Ownership and responsibility	Interview: organizational personnel with responsibilities for governing user-installed software	Named roles, their duties and evidence they act on exceptions and failed checks	Staff cannot describe who reviews failures or who approves exceptions
Exceptions and follow-up	Examine: system audit records and monitoring records for flagged installations	Recorded remediation or approved exceptions linked to each flagged installation	Flagged installations have no recorded disposition
Scope of systems covered	Test: processes applied to the system components named in the system inventory	Mapping of monitored hosts to the system boundary and the inventory	Monitoring covers a subset of hosts without a documented reason

Why CM-11 needs its own evidence trail, not a copy of CM-7

CM-11 deserves its own evidence trail because it governs something different from its neighbors. CM-7 least functionality asks what the system is configured to allow to run, and CM-14 signed components asks whether defined software and firmware carry a verified digital signature before installation. CM-11 asks a narrower question about people: what users are permitted to install on the system, how that permission is enforced, and whether anyone checks that the rules are being followed at a defined frequency. A configuration baseline can show that unneeded services are disabled and still show nothing about a user who installs a browser extension or a utility from outside the approved catalog. Reuse of CM-7 artifacts alone therefore leaves the policy, the list of rules governing user-installed software and the monitoring records unproven.

For the audit, the points that matter are the ones SP 800-53A puts under test. The assessment of CM-11 uses three determination statements and examines the configuration management plan, the list of rules governing user-installed software, system monitoring records and system audit records, interviews the personnel responsible for governing user-installed software, and tests the organizational processes that apply to it on the system. The two current enhancements, CM-11(1) and CM-11(2), are not selected in the low, moderate, high or privacy baselines in SP 800-53B Release 5.2.0, and CM-11(1) is withdrawn, so enhancement-level evidence is optional unless the organization adopts those enhancements by choice or a contract requires them. Confirm the enhancement numbering and the withdrawal status in the NIST catalog before you scope the work.

The practical decision is where the owner of the policy list sits and what the monitoring cadence is. Ask your assessor which examine objects they will sample, and confirm that the monitoring records show installation activity and policy decisions across the in-scope fleet, not only a snapshot taken for the assessment. Your implementation partner can prepare those records, but the organization owns the policy, the approvals for exceptions and the review of results, and an independent assessor decides whether the evidence meets the requirement.

How to implement CM-11 in the order an assessor expects

This sequence moves CM-11 from a written intent to a provable control: an approved policy, defined enforcement methods, a monitoring schedule, working tooling and a dated review record. Each step produces an artifact an assessor can examine, interview against and test.

Approve the user-installed software policy and name its owner
Start by drafting the policy that governs which software users may install, which requires approval, and which is prohibited. Have a named owner, usually someone in IT security or endpoint management, accountable for keeping it current, and have the authorizing official approve it in writing. The output is a signed, versioned policy that references the configuration management plan and the list of rules governing user-installed software. Confirm with your own governance team who is authorized to approve it and where the approved version is stored.
Define the enforcement methods for each software category
Translate the policy into concrete rules. Typical methods include restricting administrator rights so standard users cannot install software, application allow rules that block unapproved executables, and software deployment tooling that pushes approved packages only. Record which method applies to which device group and which software category. The output is a rules list that an assessor can compare against the policy line by line. Confirm the enforcement capabilities of your operating systems, endpoint management products and application control tools, since support varies by platform and edition.
Set the monitoring frequency and assign responsibility
CM-11 requires monitoring of policy compliance at a frequency the organization defines, so choose that frequency deliberately and document it in the continuous monitoring strategy or the policy itself. Assign who reviews the results, who handles exceptions and how an unapproved installation is escalated to the change or incident process. The output is a written monitoring schedule with named reviewers. An assessor will check that the frequency you stated is the one you actually followed, so keep it realistic for your staffing.
Deploy the monitoring and query tooling
Put tooling in place that can answer the policy question across the fleet. Open-source options include osquery for querying installed and running software across hosts, Fleet policies for yes or no compliance questions that show passing and failing devices, Velociraptor for collecting artifacts from groups of systems, and Wazuh for configuration assessment against defined policies. Test each query against a sample of known devices before relying on it. The output is a working deployment with documented queries, owners and data retention. Confirm the license terms and hosting requirements of each tool with its vendor or project before deployment in your environment.
Run and record the first compliance review
Run the first review against the approved policy and rules list, using the schedule you defined. Record the date, scope, queries used, results by device group, each unapproved installation found, and the disposition of each one, whether removed, approved as an exception through change control or accepted with a documented risk decision. Keep the raw query output with the review record so the result can be reproduced. The output is a dated review report that connects policy, enforcement, monitoring and remediation. Ask your assessor which evidence format they expect before the review, because the requirements for retained records vary by assessment.

Evidence that passes CM-11 and how to keep it current

An assessor testing CM-11 looks for a policy, the mechanisms that enforce it, and proof that compliance was checked on the schedule the organization defined. The cards below cover six artifacts that connect those three things, with a practical way to keep each one current between assessments. The organization owns these records; an implementation partner can prepare the tooling and exports, but an independent assessor decides whether they satisfy the control.

Approved installation policy with version history

This is the document that defines which software users may install, which requires approval, and who owns the list. CM-11 requires defined policies, so the assessor will first ask for the policy itself and then for proof that it was approved by an accountable owner. Keep each revision in version control or a document system with change dates and approver names. Check that the policy states the review frequency the organization set, because an assessor will compare actual reviews against that stated cadence. Confirm the approval date falls before the monitoring period under test.

Enforcement method configuration

The policy must be enforced through defined methods, so the assessor will want the configuration that makes enforcement happen, such as application control rules, endpoint management profiles, or privilege settings that block local installs. Export these settings with timestamps and keep copies outside the managed endpoints. Record which method applies to which device group. A written description alone is weak evidence; a configuration export that matches the policy is much stronger. Recheck exports after each platform upgrade, since defaults can change.

Rules list governing user-installed software

The rules list is the operational form of the policy: the allowed, prohibited and conditionally permitted software, often expressed as publisher, package name or hash. SP 800-53A lists this as a required examine object, so it must exist as a concrete artifact and match what the enforcement layer actually applies. Reconcile the list against enforcement exports each quarter or at whatever interval the organization defines. Keep a dated copy so the assessor can see what rules were in force on any given day, not only the current version.

Compliance monitoring output at the defined frequency

This is proof that someone checked whether installed software matched the rules, at the frequency the organization committed to. Scheduled queries against endpoints can list installed applications and flag those outside the rules, and their results show the check actually ran. Export each run's output with its timestamp, device count and failure count, and file it under the monitoring period. Gaps matter: an assessor will look for missing runs, so alert on any schedule that failed to execute. A monitoring record with no dates is not evidence of frequency.

Exception requests and approvals

Exceptions are where many programs fail an assessment, because a user-installed tool exists outside the rules without a recorded decision. Keep a log of each exception request, the business reason, the risk review, the approver, the expiration date and the compensating measures. Link each exception to the device or user it covers so the monitoring output can show it was expected. Review open exceptions at the same frequency as the policy review and close expired ones. Blank or unapproved exceptions showing up in monitoring output are the finding to avoid.

Continuous monitoring strategy entry for the checks

The continuous monitoring strategy ties the software checks to a schedule and to an owner, which is why the assessor will look for this entry alongside the monitoring output. Confirm the strategy names the user-installed software check, its frequency, the responsible role and the reporting path for failures. Update the entry when the schedule or tooling changes, and keep dated versions. Pair it with a sign-off record showing someone reviewed the results and acted on failures. An entry that describes checks no one reviews will not support the control in practice.

Which self-hosted open-source tools can support CM-11 evidence

CM-11 asks the organization to set rules for user-installed software, enforce them and monitor compliance. The four tools below can collect the monitoring evidence, each from a different angle: scheduled queries, pass or fail policy results, configuration checks and forensic collection. None of them writes the policy or enforces it on its own.

osquery for software inventory queries

osquery exposes running processes, loaded kernel modules, browser plugins and file hashes as SQL tables. The osqueryd daemon schedules these queries across a fleet of hosts, so the organization can record what is actually installed and running on each device. Check that the query set matches the written list of permitted and prohibited software, and that each host reports on the schedule the policy defines. Its license is Apache-2.0 OR GPL-2.0-only.

Fleet policies as yes or no checks

Fleet policies ask yes or no questions of devices, written as osquery queries, such as whether a prohibited application is present. The policies page shows which devices on each fleet pass or fail each policy, which gives a per-device record of compliance with the rule list. Confirm that each policy's wording matches the approved rule in the written policy, and record how failing devices are handled. Fleet is licensed under MIT.

Wazuh configuration assessment checks

Wazuh Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies, mostly based on CIS benchmarks and extendable with custom policies. It checks files, directories, registry keys and running processes, and recommends remediation. For CM-11, custom policies can test for installed software that the rule list prohibits, but the team must confirm that its checks cover the organization's own rules rather than only the benchmark content. Wazuh is licensed under GPL-2.0-only.

Velociraptor hunts across endpoints

Velociraptor collects forensic artifacts defined in VQL from endpoints, and its hunts gather one or more artifacts across a group of systems. Machines that are offline are scheduled to collect when they reconnect, and each hunt gets a notebook for analyzing the combined results. This suits one-time or periodic sweeps for unapproved software during an investigation. Confirm that artifact definitions match the rule list and that hunt results are kept as monitoring records. Velociraptor is licensed under AGPL-3.0-only.

What meeting CM-11 user-installed software costs

This table breaks the cost of governing user-installed software into its components, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to structure a request for a written scope and quote, since most of the cost is labor rather than licenses.

Cost component	One-time or recurring, and who is paid	What drives it up or down
Tooling and licenses	Mostly recurring if commercial. Self-hosted open-source options such as osquery, Wazuh and Fleet remove license spend, but hosting and operations remain.	Number of platforms, endpoint count and whether a vendor support tier is required. Confirm license terms for each tool before deployment.
Policy and rule engineering	One-time to build, recurring to revise. Paid to internal staff or an implementation partner.	Number of approved and prohibited software categories, and how many exceptions the policy defines.
Query and check authoring	One-time for initial queries and checks, recurring as software changes. Paid to engineers who write osquery or Fleet policy queries.	Operating system mix, number of software packages on the approved list and frequency of policy changes.
Endpoint enforcement work	One-time setup, recurring operation. Paid to platform or endpoint teams for agents, alerts and removal workflows.	Fleet size, remote or offline device share and whether removal is automated or manual.
Exception handling and review	Recurring. Paid to security, IT and the business owners who approve or reject installs.	Number of exceptions, number of user-installed requests and the review cadence the organization defines for monitoring.
Evidence upkeep	Recurring. Paid to staff who retain query results, alert records and monitoring reports for assessors.	Retention period, audit frequency and how many systems must show compliance over the same period.
External testing or review	Usually one-time or periodic. Paid to an independent tester or assessor, separate from any implementation partner.	Scope of testing, number of systems in the assessment boundary and whether control testing is included in the engagement.
Auditor sampling	Recurring with each assessment cycle. Paid to the independent assessor, who issues findings.	Number of endpoints sampled, depth of evidence requested and the number of assessment cycles per year.

Who owns, who implements and who assesses CM-11

Your organization owns CM-11. The policy governing which software users may install is an organizational decision, and so are the exceptions to it and the review of whether monitoring results are acted on. An assessor will look for a named owner, a documented policy and proof that someone reviewed compliance at the frequency you defined. Those responsibilities cannot be handed to a vendor or consultant.

Policy ownership: Approve the installation policy, define which software categories are permitted, restricted or prohibited, and assign an accountable owner.
Exception approval: Decide on requests for software outside the policy and record the justification, approver and expiry date.
Monitoring review: Review compliance results at the frequency your policy sets and document what was found and what was done about it.
Interview readiness: Make sure the people named in the policy can explain their responsibilities, since assessors interview them.
Frequency and records: Keep the review schedule and signed-off review records where an assessor can retrieve them.

Check that the policy names a role, not just a team, and that every monitoring review leaves a dated record.

Common questions about CM-11 cost, effort and outsourcing

How much effort does CM-11 take to implement and maintain?

CM-11 is a single control with three determination statements, so the initial build is modest, but the recurring monitoring is what takes sustained effort. The main drivers are the number of endpoints and servers in the boundary, the number of software types users can install, whether users hold administrator rights, and whether existing tools already report installed software. Cost usually falls into staff time for writing the policy and rules, tool deployment, and periodic compliance reviews. Ask any quote to itemize these pieces, list the systems in scope, and name the monitoring frequency the organization will commit to.

Can a small team implement CM-11 without an implementation partner?

Yes, a small team can implement CM-11 without a partner if it has the time and skills. The organization owns the control, so someone must be accountable for the installation policy, the list of permitted software, and the monitoring routine. Teams without experience deploying query-based endpoint tools often find it hardest to collect reliable data from every host and to keep evidence organized for an assessor. A partner can cover that gap within a fixed scope while internal staff keep ownership. Before deciding, check whether the team can run monitoring at the defined frequency and retain the records.

How long does CM-11 work take, and what does timing depend on?

Timing depends on the size of the boundary, how mature the existing software and change processes are, and how many approval cycles the organization needs before it accepts a policy. Deployment speed depends on how quickly monitoring reaches every host, including machines that stay offline for long periods. Teams that have not settled their related change and software processes usually take longer, because CM-11 draws on those records during assessment. Timelines are set in the written scope before work starts. Ask for milestones tied to specific systems and to the evidence each milestone produces.

What does the CM-11 work need from our own staff?

The work mostly needs decisions and reviews from people who already run the environment. Plan for these roles:

A named policy owner who can approve the installation rules and the list of permitted software.
System administrators who can confirm endpoint and server inventories and approve agent deployment.
Security operations staff who review compliance results at the defined frequency.
Change control members who handle exception requests.
Personnel who can explain their responsibilities in an assessor interview.

Block their time before work starts, because the assessment methods depend on them being available and responsive.

Does CM-11 apply to the privacy baseline?

No. In SP 800-53B Release 5.2.0, CM-11 is selected for the low, moderate and high baselines but not for the privacy baseline. That does not remove software governance from a privacy program, because other controls and the organization's own privacy requirements may still address installed software. Confirm the scope with the privacy officer and the baseline profile. A system that also falls under a low, moderate or high baseline must meet CM-11 through that baseline, so document which baseline drives the requirement and why.

Are CM-11 enhancements required?

The baselines do not require them. CM-11 has three numbered enhancements in Release 5.2.0, one of which is withdrawn, leaving two current enhancements. None of the two current enhancements is selected in the low, moderate, high or privacy baseline, so a baseline-driven assessment does not test them. A contract, agency or internal risk decision can still add them, so ask the authorizing official or contract owner whether tailoring or a specific requirement applies. Document the decision either way so the assessor can follow the reasoning.

What can an implementation partner provide to an auditor, and what can it not provide?

A partner can prepare systems and evidence, such as a draft installation policy, the permitted software list, monitoring configurations, query results and exception records, arranged so an assessor can trace each determination statement. It cannot issue an assessment report, an attestation or a certification, and it cannot decide that the control is satisfied. The organization owns the control, and an independent assessor tests it against the procedures in SP 800-53A. Confirm the assessor's independence and scope before engagement.

How DeployOpen scopes and prepares CM-11 evidence

DeployOpen works on CM-11 User-installed software as an implementation partner: we scope the user software policy, build the enforcement and monitoring on self-hosted open-source tools inside your environment, and hand over the evidence. Your organization owns the policy and the control, and an independent assessor decides whether it is met.

How we scope

Agree in writing which systems, endpoints and user populations fall under the user-installed software policy.
Confirm with your policy owner the defined installation rules and the monitoring frequency your organization sets for CM-11.
Record which enforcement methods apply to each platform and which exceptions are approved, before any build work starts.

How we build

Deploy osquery or Fleet policies that ask yes or no questions about installed software on enrolled devices.
Configure scheduled queries and dashboards that show passing and failing devices per policy, mapped to your stated rules.
Test the enforcement path on a representative device group and document how unauthorized installations are detected and reported.

How we hand over

Deliver the written configuration, query definitions and policy mappings so your team can reproduce the monitoring.
Provide sample compliance reports and audit records that show monitoring ran at the defined frequency.
Document operating procedures, owners and known gaps so an assessor can trace each examine, interview and test item to evidence.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
Ongoing support, upgrades and continuous testing of the monitoring stack are available as a retainer.
Confirm with your auditor which evidence formats and retention periods they will accept before handover is finalized.

CM-11 User-installed software