What CM.L2-3.4.9 user-installed software requires and why assessors check it
CM.L2-3.4.9 requires three things: a written policy for who may install software and what they may install, technical enforcement of that policy, and monitoring of what users actually install. If you are preparing for a Level 2 assessment, expect the assessor to ask for all three, not just the policy document. The requirement is the CMMC Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.4.9, a derived requirement in the Configuration Management family. It maps to SP 800-53 control CM-11 (User-installed Software) in Appendix D of Rev. 2, and it is worth 1 point under 32 CFR 170.24. The low point value understates the risk. Software a user installs on a CUI system, especially a browser extension, a remote access tool or an unlicensed utility, is an entry point and an unmanaged part of the attack surface that nobody reviewed.
The requirement is hard to meet for three reasons that are common in defense contractor environments. First, installation rights are often undocumented: nobody can say whether standard users, power users or help desk staff can install software, or through which route. Second, local administrator rights tend to spread across users over time, so the installation policy exists on paper while the technical ability to bypass it is widespread. Third, many organizations have no reliable software inventory across endpoints, so they cannot show what is installed, let alone whether it was approved. Each of these gaps leaves an assessor with no objective evidence for one of the three assessment objectives in NIST SP 800-171A.
Start with a scoping check. List every system in the CUI boundary and record who holds local administrator rights on each one, then compare that list with your installation policy. Confirm the approval route for a new application, who signs off, and where the decision is recorded. Then confirm that you can produce an endpoint software inventory and a monitoring record of installation events. Open-source tools such as Wazuh (its Syscollector module collects installed software from each endpoint) and osquery can supply part of that evidence, but the policy, the approval records and the reviews of exceptions must be your own documents. Confirm the specifics of your environment and tooling with your assessor and your system security plan before relying on them.
Which systems, users and tools fall under the user-installed software rule
The user-installed software requirement applies wherever CUI is stored, processed or transmitted, and the boundary is set by the system security plan, not by org charts. The cards below cover the scoping choices that most change the amount of policy, enforcement and monitoring work, and each one should be decided and written down before controls are built.
CUI-processing endpoints and servers
Every workstation, laptop and server that stores, processes or transmits CUI sits inside the 3.4.9 boundary. Confirm the SSP's system inventory lists each one, then decide whether users on those machines may install software at all, or whether installs go through an approval route. Watch for CUI copies that drift onto endpoints outside the documented boundary, such as personal laptops used for file sync.
Shared and privileged accounts
Shared service accounts, admin accounts and generic kiosk logins can install software without a named person behind the action. Decide which accounts may install, who holds the credentials, and how an install made under a shared account is traced to a requester. Monitoring that records only the account name will not show the assessor who did what.
Developer and engineering workstations
Engineers often need compilers, package managers, containers and debugging tools, which makes a blanket installation ban unworkable. If these machines hold CUI or connect to CUI systems, write a distinct policy tier for them with an approved software list, a defined route for new packages, and monitoring that covers package managers as well as installer packages.
OT and test equipment
Operational technology controllers, instrument computers and test rigs frequently run vendor software that cannot be changed without the vendor's involvement. Determine whether these assets are inside the SSP boundary and, if so, document them as specialized assets with their own install rules. Note any vendor-controlled update path, since the policy must say who may authorize it.
Third-party and managed endpoints
Devices owned by a managed service provider, a subcontractor or a contractor's staff can still reach CUI. Confirm in writing who sets and enforces the install policy on those endpoints, what the contractor can see in monitoring data, and how the external provider reports installs back to you. If the provider cannot produce that evidence, the device may need to be excluded from the boundary or handled through a documented external service relationship.
The system security plan sets the boundary
The SSP boundary determines which systems, users and tools the 3.4.9 policy covers, and an assessor will test against that boundary. Keep the policy owned by the contractor, even when a consultant drafts it or a managed provider runs the tooling. Revisit scope whenever the SSP changes, because a new tool or a new group of users can bring CUI into a population that the policy never covered.
How an assessor tests CM.L2-3.4.9 across its three objectives
The first objective asks whether the organization has established a policy governing software installation by users. The assessor starts by reading the rule set itself: who may install software, what categories are approved, how exceptions are requested, and who owns the list. The assessor then checks that the policy is current, approved by an accountable owner, and consistent with the system security plan. A policy that exists only as an unsigned draft does not satisfy the objective, because the requirement is judged on final evidence.
- Rule list: The assessor expects a documented list of rules governing user-installed software, including what is permitted, what is prohibited, and what requires approval.
- Ownership and approval: The policy should name an owner and show approval and a revision date that match the period under assessment.
- Exception route: Requests for software outside the approved set should have a defined path, such as a ticket to the security team, with the decision recorded.
- Alignment with the SSP: The policy should be referenced in the system security plan so the assessor can trace the control from the plan to the rule.
- Scope: The rules should name which systems and user groups they cover, including administrators and any remote or shared endpoints.
Before an assessment, confirm that the policy is final, dated and signed, and that every system in the boundary is covered by it.
The second objective asks whether installation is actually controlled according to the policy. Policy text alone does not meet it. The assessor tests the mechanism that enforces the rules, which in practice means reviewing how standard users are prevented from installing software and how the organization handles installs that a user performs with elevated rights. The CMMC Assessment Guide Level 2 expects that user-installable software is limited to what the organization approves, supported by both policy and technical controls. Assessors commonly sample endpoints and watch a test installation to confirm the control works.
- Technical restriction: The assessor looks for a mechanism that blocks standard users from installing software, such as operating system installation rights, endpoint management policy, or a managed software catalog.
- Privilege review: Administrative accounts used for installs should be restricted and logged, with a documented reason for each elevated installation.
- Sampled testing: Expect the assessor to choose endpoints and attempt an unapproved installation as a standard user, then check the result.
- Approved route: Show the workflow an approved request follows, from request to deployment, and the record that the deployment matched the approval.
- Configuration evidence: Exported policy settings, group policy objects, or management console configurations show how the control is set.
Before testing, ask whether each enforcement setting is documented in the baseline and whether a standard user account can, in fact, complete a blocked install on a sample machine.
The third objective asks whether the organization monitors installation activity. The assessor looks for records that show what software was installed, when, on which system, and by whom, and for evidence that someone reviews those records. SP 800-171A ties this objective to system monitoring records, audit records, and the continuous monitoring strategy. The assessor will test whether monitoring covers the full boundary and whether unauthorized installs are detected and handled, not merely logged.
- Installation records: Inventory or audit data showing software added to each endpoint, with timestamps, is the core evidence the assessor requests.
- Review cadence: The assessor looks for a documented review, its frequency, the reviewer, and records of findings and follow-up actions.
- Continuous monitoring strategy: A written strategy should state what is monitored, how often, and how unauthorized installs are escalated.
- Coverage check: The assessor may compare the monitored population against the asset inventory to find endpoints that report nothing.
- Open-source options: Tools such as osquery, Wazuh Syscollector, and GLPI inventory can supply installed-software data, though the organization must confirm each tool's output meets its own evidence needs.
Before an assessment, run a sample review yourself and confirm the review record names a reviewer, a date, and the decisions taken.
Assessor test approach, evidence requested and common findings
This table compares how an assessor tests each of the three CM.L2-3.4.9 objectives from NIST SP 800-171A, what evidence they ask to see, and where organizations most often fall short. Read each row as a chain: a policy needs an enforcement mechanism, and the enforcement needs monitoring records that someone reviews. A requirement is met only when all three objectives are satisfied with evidence in final form.
| Assessment objective | Assessor test approach | Evidence requested | Common findings |
|---|---|---|---|
| Policy for user-installed software | Read the rules governing user-installed software and check that they name who may install, what categories are allowed, and how exceptions are requested and approved. | Approved software installation policy, the list of rules, role definitions and the approval route with its owner. | Policy exists in draft or was never approved, or it does not match how the system is actually administered. |
| Control of installation per policy | Test the mechanisms that restrict installation, such as privilege settings, application control or package restrictions, and attempt a disallowed installation on a sample of endpoints. | Configuration exports or screenshots of installation restrictions, group policy or MDM settings, and test results showing blocked installs. | Policy states that users may not install software, yet local administrator rights are granted broadly with no documented request route. |
| Monitoring of installation | Review monitoring records for installed software and confirm that a person examines them and acts on unauthorized items. | Inventory or monitoring reports with dates, review sign-offs, tickets for unauthorized software and the continuous monitoring strategy that covers them. | Collection runs on schedule, but no review record, ticket or follow-up exists to show that anyone acted on the results. |
| Exception and approval records | Sample recent installation requests and exceptions and trace each one from request through approval to the installed state. | Request tickets, approver identity, decision date, justification and the matching inventory entry for each approved item. | Approvals are given verbally or in chat, so the assessor cannot trace an installed item back to a documented decision. |
| Evidence currency and form | Check that each artifact is final, dated and covers the period under assessment, not a template or work in progress. | Signed or version-controlled policy, dated monitoring exports and completed review logs within the assessment window. | Draft policies, undated screenshots or review logs that stop months before the assessment. Draft evidence does not count toward MET. |
| Scope of monitored endpoints | Compare the monitored population against the asset inventory and the system security plan boundary to confirm that in-scope endpoints are covered. | Inventory-to-monitoring reconciliation, agent deployment reports and the defined boundary of the CUI environment. | Servers and laptops that handle CUI are missing from monitoring, often because agents were never installed on newly added or remote devices. |
| Mechanism testing | Run a test installation or observe a configuration change to confirm that the monitoring tool detects new software and reports it to the reviewer. | Test case records, detection timestamps and the report that showed the test item after collection. | Monitoring tool is configured but was never tested, so no evidence shows it detects unauthorized software. |
How to implement user-installed software controls in sequence
This sequence turns CM.L2-3.4.9 from a written policy into enforced, monitored and documented practice, so an assessor can see who may install software, how that right is enforced, and how deviations are found and handled. Each step produces an artifact that the next step depends on.
Define who may install what and the approval route
Start by writing the installation policy that NIST SP 800-171A treats as the first assessment objective for 3.4.9. Name the roles that may install software, the categories of software they may install, and the route a request takes from submission to approval, including who signs off and how long the request record is kept. Assign an owner for the policy, usually the security function with input from IT operations. The output is an approved software rule set, a dated policy document that the organization's own governance process has signed. Confirm that the rule set matches the allow or deny approach chosen under CM.L2-3.4.8, so the two requirements do not contradict each other.
Build the rights matrix for local administrator access
Map each user group and system type to the installation rights it holds: standard user, privileged user, administrator, or no local install at all. The matrix should show which groups can install from an approved catalog, which can request installation, and which cannot install anything. Review the matrix with system owners for endpoints that carry CUI, because those systems are where the policy is most likely to be tested. The output is a rights matrix tied to named groups in the directory service. Confirm that it reflects what the directory actually grants, not what the policy intends.
Remove or restrict local administrator rights
Apply the rights matrix to the endpoints and servers in scope. Remove local administrator rights from users who do not need them, and restrict elevation so that installation by standard users requires an approved path. Where a business need justifies elevated rights, record the justification and scope it to specific software or time-limited sessions, as your change process allows. The output is a configuration state in which the directory and endpoint management settings match the rights matrix. Verify on a sample of machines that a standard account cannot install unapproved software, and keep the test result as evidence.
Enforce installation through technical controls
Implement the rule set with mechanisms that stop unapproved installs rather than relying on user compliance alone. Options include application control or package management policies configured as allow or deny lists, and endpoint settings that block installers from unapproved publishers. The CMMC Assessment Guide expects both policy and technical controls, so the enforcement configuration should be documented with the policy it implements. The output is an enforcement configuration record listing each control, its scope, its settings and its owner. Test it with a deliberate attempt to install a blocked package and record the outcome.
Build an inventory baseline of installed software
Collect the current set of installed software across in-scope systems before you start monitoring deviations. Endpoint inventory agents or open-source tools such as Wazuh Syscollector or GLPI native inventory can report installed software to a central store. Reconcile the results against the approved rule set, sort what is approved, unapproved, and unknown, and assign an owner to each unknown item. The output is an inventory baseline with a reconciliation list, which becomes the reference point for later monitoring. Record the collection date and the scope so an assessor can see what the baseline covers.
Monitor installations and review deviations
Set up continuous monitoring of new installations and changes to installed software, and route alerts to the team that owns the policy. Osquery can schedule queries across a fleet to check installed software and running processes against the rule set, and Wazuh can report changes in its inventory views. Review each deviation: decide whether it is removed, approved through the request route, or recorded as an exception. The output is a monitoring review record that shows dates, deviations found, the decision for each, and who made it. Keep these records as the audit records and monitoring evidence that the assessment objectives call for.
Document exceptions and feed them back into the policy
Record every approved exception with its business reason, the approver, the software and systems covered, and an expiry or review point. Update the rule set, the rights matrix and the enforcement configuration when an exception becomes a permanent approval, so the documents stay consistent. Include the exception register in the system security plan and in the periodic review of the policy. The output is an exception register linked to the policy and the monitoring records. Ask an independent assessor early whether the exception handling satisfies their reading of the objectives, since the assessor, not the organization or its implementation partner, determines the result.
How self-hosted open-source tools fit the install-control workflow
Install control for CM.L2-3.4.9 works as three layers: an inventory layer that records what is installed on each endpoint, a detection layer that finds new or changed installs across the fleet, and a case layer that routes approvals and exceptions to a person who can decide. Open-source tools can cover the first two layers in a self-hosted deployment, while the case layer is usually your existing ticketing or change system. The architecture matters because an assessor will ask you to show the policy, the enforcement and the monitoring as separate, traceable pieces, not as one dashboard.
For the inventory layer, GLPI is a candidate for the asset record. Its Assets module holds computers and software, and it can receive data pushed automatically by the GLPI Agent through native inventory. Wazuh Syscollector collects installed software from each endpoint and stores it in the Wazuh indexer, where it can be viewed and reported in the dashboard. Decide which of these is the system of record for installed software and which feeds it. Running both without a documented reconciliation rule creates two lists that disagree, which is a finding waiting to happen.
For the detection layer, osquery and Velociraptor answer different questions. osquery exposes system state as SQL tables and its osqueryd daemon can schedule queries across a fleet, so a scheduled query that compares installed software against the approved list can flag drift. Velociraptor runs hunts over artifacts across a group of systems and collects results from machines that were offline until they reconnect, which suits investigating a specific install. Confirm in your own environment which hosts each agent can reach, which operating systems you need covered, and how alerts from these tools reach the case layer. Every tool's fit should be tested against your endpoint estate before you rely on it for evidence.
Which evidence artifacts pass CM.L2-3.4.9 and how to keep them current
An assessor testing CM.L2-3.4.9 looks for a policy, proof that the policy is enforced, and records showing installations were monitored. The six artifacts below map to those three objectives, and each one goes stale unless someone refreshes it on a schedule.
User-installed software policy and approved list
The written policy states who may install software, what counts as software, and which items are approved. The approved list is the working record behind it, and it should name each product, version range, and business purpose. Check that the policy names an owner, carries a revision date, and that the list matches the baseline in the SSP. Review both on a fixed cycle and after any major change to the environment, so the assessor sees a current document rather than one written for the last assessment. Evidence must be in final form, so approved and signed versions are the ones to retain.
Installation rights matrix
The rights matrix lists each user group, the systems it covers, and whether members can install software, request installs, or cannot install at all. It is the most direct proof of the control objective for controlling installation according to the policy. Export the matrix from the directory and endpoint management tools, not from a spreadsheet typed by hand, so the evidence reflects actual settings. Reconcile it against group membership on a regular schedule, because privileged group drift is the usual gap between the documented matrix and the live system. Retain the dated export and the reconciliation notes.
Enforcement configuration exports
Exports of the technical settings that block or restrict installation show the policy is enforced, not only written. Examples include application control rules, local administrator settings, and software restriction policies, depending on the platform. Confirm with the vendor or your own configuration which export format each tool produces and whether it records the setting, the scope and the last change. Store exports with timestamps and compare each new export to the prior one, since an unexplained change between exports is an exception to investigate. Note that the exact enforcement mechanism is an environment decision, so confirm it before assuming a tool provides it.
Software inventory reports
Inventory reports list the software actually present on each endpoint, which lets you find installs the policy did not approve. Wazuh's Syscollector collects installed software from each endpoint into dashboard inventory views, and GLPI's Assets module can hold computer and software records entered manually or pushed by its agent. Reports should be generated on a fixed schedule and compared against the approved list, with each unapproved item either removed or tied to an approved exception. Keep the report, the comparison, and the disposition together so the assessor can follow one item from discovery to resolution.
Monitoring and alert records with review sign-off
Monitoring records show that the organization watches for installations, and the review sign-off shows a person looked at what the monitoring found. Scheduled queries in osquery can report on installed or newly started software across a fleet, and Velociraptor hunts can collect artifacts across many systems at once. Each review should record the period covered, the findings, who reviewed them, and the date. A sign-off with no findings still counts as evidence if the review actually happened, so keep the blank reviews. Confirm that alert routing reaches a named owner, because an alert nobody reads will not satisfy the monitoring objective.
Exception and approval tickets
When a user needs software that is not on the approved list, the request, the approval, and the install record should form a linked ticket. The ticket shows the approver applied the policy, the business reason, the time limit, and the follow-up check that the software was removed or added to the approved list. Assessors test whether exceptions are rare and documented, so review open exceptions on a fixed cycle and close the ones that have expired. Keep the ticket history in a system that preserves dates and approver identity. Tickets that remain open, or that show approval after installation, are common findings and should be fixed before the assessment window.
What meeting CM.L2-3.4.9 costs in tools, engineering time and assessment
This table breaks down the cost components of meeting CM.L2-3.4.9 User-installed software, showing who is paid for each one, whether it is one-time or recurring, and what drives it up or down. Use it to structure a request for a written scope and quote, not as a price estimate. The main takeaway is that licenses are only one line item, while policy, privilege changes, evidence upkeep and assessor effort usually decide the total.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it |
|---|---|---|---|
| Policy authoring for user-installed software | Internal policy owner, with optional outside help | One-time, then recurring at each review | Number of software categories, approval routes and CUI enclaves in scope |
| Endpoint privilege changes | Internal IT or platform engineering, or an implementation partner | One-time, plus recurring for exceptions | Fleet size, number of local administrator accounts and exception requests |
| Enforcement tooling or licenses | Commercial vendor, or no license spend with self-hosted open source | Licenses recur; open-source tooling has no license fee | Commercial seat counts, support tiers and the number of enforced endpoints |
| Engineering time to deploy inventory and monitoring | Implementation partner or internal engineers | One-time, with later upgrades and tuning | Number of endpoint operating systems, agent rollout method and integration with existing SIEM or CMDB |
| Recurring evidence upkeep and review | Internal compliance or IT staff | Recurring, typically monthly or quarterly | Frequency of inventory reports, volume of unapproved software findings and retention of monitoring records |
| External review before assessment | Independent consultant or implementation partner, who prepares evidence but does not assess | Usually one-time before an assessment | Maturity of current records and number of systems in the assessment boundary |
| Assessor effort | Certified assessor organization, paid by the contractor | One-time per assessment cycle | Number of objectives tested, quality of final-form evidence and sampling of endpoints |
| Exception handling and reapproval | Internal approvers and system owners | Recurring | Number of exceptions granted, expiry rules and changes to approved software lists |
Where contractors usually fall short on user-installed software and how to close it
Most CM.L2-3.4.9 findings come from a gap between what the written policy says and what happens on real endpoints. The cards below pair each common gap with one fix, following the three assessment objectives in NIST SP 800-171A: a policy, control of installation under that policy, and monitoring of installation.
No policy tied to the SSP
A policy on user-installed software that lives in a general IT handbook, or does not exist, gives an assessor nothing to test against. The assessor first looks for a written rule set that names who may install what, and checks that the SSP describes the same rules for the in-scope system. Fix it by writing one policy that defines permitted software categories, approval roles and exception routes, then referencing that policy from the SSP entry for the CUI environment.
Broad local administrator rights
When most users hold local administrator rights on their workstations, any control on installation depends on user restraint. Assessors commonly test whether standard users can install software without a privileged request. Fix it by removing local admin from general user accounts, granting elevation only through a logged request path, and documenting which roles keep elevated rights and why.
Enforcement that exists only on paper
A policy that prohibits installs is weak evidence if nothing blocks them. Assessors look for technical controls that match the written rule, such as application control, software restriction policies or endpoint management settings that prevent unapproved executables from running. Fix it by mapping each policy statement to a named technical setting, testing that setting on a sample endpoint, and keeping the test result with the configuration baseline.
Monitoring with no review record
Many organizations collect software inventory data but never show that anyone reviewed it. The third assessment objective asks whether installation is monitored, and the evidence has to show the review happened. Fix it by scheduling a recurring review of new or changed software, recording who reviewed it and what action followed, and keeping those records alongside the raw monitoring output.
Inventory that misses unmanaged and remote endpoints
An inventory built only from domain-joined machines leaves out laptops that roam, contractor devices and servers managed outside the main tool. Assessors often sample endpoints from the asset list and find software that was never inventoried. Fix it by reconciling the inventory against directory records, network discovery and agent check-in data, and documenting how remote endpoints report in when they are off the corporate network.
Exception handling without approval evidence
Exceptions to the installation rules are often granted by email or verbally, then never recorded. Without an approval record, an assessor cannot confirm that the exception followed the policy. Fix it by using one exception form that names the software, the requester, the business reason, the approver, the expiry date and the compensating control, and by linking each approved exception to the monitoring entry that shows it running.
Questions contractors ask about CM.L2-3.4.9 cost, effort and outsourcing
Can we meet CM.L2-3.4.9 in-house without outside help?
Yes, if you have staff who can write the software installation policy, configure the enforcement mechanisms and produce monitoring records. The requirement asks for three things: a policy governing what users may install, technical or procedural control over installation according to that policy, and monitoring of installations. Your organization owns all three. Small teams usually struggle less with the policy and more with keeping enforcement and monitoring evidence current across every endpoint. An outside implementation partner can help set up the tooling and collect evidence, but the policy must be yours and approved by your management. Confirm internally who will own the policy, the approval route for new software and the monitoring review.
How long does CM.L2-3.4.9 take and what drives the timeline?
The time depends mostly on how many endpoints you run, how many installation rights exist today, and whether a documented software policy already exists. Engineering effort usually goes into four areas: removing unnecessary local admin rights, defining an approval route, deploying an inventory or monitoring agent across the fleet, and building a review cadence that produces records. Organizations with an existing asset inventory and a clear change process generally move faster than those starting from scratch. No duration is set by the requirement itself, so ask any provider for a timeline in writing, tied to a defined scope, and check which endpoints and operating systems it covers.
What must our team supply before an engagement starts?
Expect to supply the people and decisions that only your organization can provide. These typically include:
- A current list of systems in the CUI boundary and their owners
- Your existing acceptable use policy, change process and any approved software list
- Administrator access to directory services, endpoint management and the inventory platform
- A named approver for software requests and a named reviewer for monitoring output
- Your system security plan entries that describe how user-installed software is handled
Clarify these inputs in the written scope so that gaps are not discovered mid-project.
Can a consultant prepare the evidence for CM.L2-3.4.9?
A consultant or implementation partner can prepare systems and evidence, such as enforcement configurations, monitoring reports and documented review records. The assessment objectives expect the policy, the enforcement mechanisms and the monitoring records to be in final form, not drafts, so the organization must approve and operate them. DeployOpen, for example, prepares systems, controls and evidence for compliance assessments, but it does not issue assessment reports or certifications. Ask any provider to state in writing which artifacts it will produce, which remain your responsibility, and how it will hand over documentation you can maintain after the engagement closes.
What will the assessor check for CM.L2-3.4.9, and what will they not do?
The assessor tests the three objectives in NIST SP 800-171A against your environment. They review the software installation policy, test whether the enforcement mechanisms actually block or control installs, and examine monitoring records and audit records for evidence that installations are watched over time. For Level 2 certification, a C3PAO performs the assessment. The assessor will not design your policy, configure your tools or write your evidence for you, because that would compromise independence. Plan for the assessor to ask for samples and to test the mechanisms themselves, so records must exist for the full period under review.
Can a 1-point CM.L2-3.4.9 gap go on a POA&M?
CM.L2-3.4.9 is worth 1 point, and it is not on the exclusion list in 32 CFR 170.21(a)(2)(iii), so it may be placed on a plan of action and milestones (POA&M) for Conditional Level 2 status. The condition is that your score is at least 88 of 110 (0.8), and closeout is due within 180 days. Treat this as a fallback, not a plan. Conditional status still requires honest scoring, and a POA&M entry must describe a real remediation path with an owner. Confirm the current status rules with your contracting officer and the CMMC program materials before relying on them, since the program timeline has changed.
What costs recur after the first CM.L2-3.4.9 implementation?
Most of the cost after go-live is operational. Recurring items include licenses or support for the inventory and monitoring tools, staff time to review installation requests and monitoring output, periodic policy review, and re-evidencing after OS upgrades or new endpoints join the fleet. One-time costs include the initial policy, enforcement setup, endpoint rollout and documentation. Open-source components such as osquery, Wazuh and GLPI carry no license fee, but hosting, maintenance and staff time still apply. Ask any provider for the split between one-time setup and recurring support in a written quote, and for the retainer scope if you want continuous monitoring help.
Who owns, who implements and who assesses CM.L2-3.4.9
Your organization owns CM.L2-3.4.9 in full. The requirement asks you to set a policy for software installation by users, control installation according to that policy, and monitor what gets installed. Only your leadership can decide who may install software, which products are approved, and which residual risks you accept. An outside partner can draft material, but the policy must be yours and must reflect how your System Security Plan describes the boundary.
- Policy ownership: Approve the rules on who may install software, which installation rights are granted by role, and what counts as user-installed software in your environment.
- Approval routes: Define who reviews a software request, how decisions are recorded, and how emergency requests are handled.
- Risk acceptance: Decide in writing which exceptions you accept, who signs them, and when they are reviewed.
- Monitoring review: Assign someone to read installation reports on a set schedule and act on unapproved software.
- Assessment readiness: Keep the policy, approval records and monitoring logs in final form, since assessors do not accept drafts.
Confirm with your assessor which documents they expect to see and where the policy must be reflected in the SSP.
An implementation partner prepares the technical controls and evidence that support your policy. DeployOpen, for example, plans, configures and documents self-hosted open-source platforms inside your own environment. The partner does not make the policy decisions, does not approve software on your behalf, and cannot issue an assessment result. Work is usually fixed scope, with deliverables and timelines agreed in writing before it starts.
- Inventory and detection: Configure tools that report installed software and changes across endpoints, such as osquery or the Wazuh Syscollector module, against your approved list.
- Enforcement set-up: Implement the technical restrictions that limit installation rights, documented against your policy.
- Monitoring and reporting: Build dashboards and scheduled reports that show installation events and exceptions.
- Evidence packaging: Organize configuration records, screenshots, query outputs and logs so your team can show them to an assessor.
- Testing support: Run pre-assessment checks against the 3 assessment objectives in NIST SP 800-171A.
Ask for a written statement of which deliverables are the partner's, which are yours, and who maintains the tooling after handover.
For Level 2 certification, the assessment is performed by a C3PAO authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. The C3PAO tests your implementation against the assessment objectives in NIST SP 800-171A and reports findings. Neither your team nor your implementation partner can issue the certification result. The DoW has suspended CMMC Phase II, so confirm the current requirement for your contracts before planning certification.
- Independent testing: The assessor examines the policy, interviews staff, and tests whether installation is controlled and monitored as documented.
- Evidence standard: A requirement is met only when all applicable objectives are satisfied with evidence in final form.
- Findings and scoring: The assessor records what is met or not met, which feeds the score and any POA&M decisions.
- Independence: The assessor cannot design or implement the controls it tests, so consultants and assessors must stay in separate roles.
- Self-assessment: Where only a self-assessment applies, your team performs the scoring and posts the results, and the same evidence standard still applies.
Check the current assessment requirements with your contracting officer and the official CMMC pages before scheduling.
Official sources for CM.L2-3.4.9 requirements and assessment
Start with the NIST text that the CMMC practice comes from. CM.L2-3.4.9 is the Level 2 version of requirement 3.4.9 in NIST SP 800-171 Rev. 2, Protecting CUI in Nonfederal Systems and Organizations, which is the document the CMMC Level 2 requirements are identical to. Read the 3.4.9 requirement statement, its discussion and the related configuration management requirements in the same family, since the controls on user-installed software depend on the baseline and least functionality decisions made under 3.4.1 and 3.4.6. Note that NIST withdrew Rev. 2 when it published Rev. 3, and confirm the current DoW position on which revision applies to your contract before you build your evidence set around it.
The assessment logic for 3.4.9 sits in NIST SP 800-171A, Assessing Security Requirements for CUI. This is the companion publication that breaks the requirement into assessment objectives. For 3.4.9 there are three: a policy for software installation by users must be established, installation must be controlled according to that policy, and installation must be monitored. Use these objectives as your checklist. For each one, write down the document that establishes the policy, the mechanism that enforces it, and the log or report that proves monitoring took place, then confirm that each piece exists in final form before the assessment date.
For the CMMC-specific view of what a Level 2 assessor expects, use the CMMC Assessment Guide, Level 2 published by the DoW CIO. It states that software users can install should be limited to items the organization approves, and that this limit should be enforced through both policy and technical controls. A policy with no technical enforcement, or a technical block with no written policy behind it, will leave a gap that an assessor can find. Read the guide alongside the assessment objectives in 800-171A, and confirm the version your assessor uses, since the DoW publishes updated guidance over time.
How DeployOpen scopes, implements and prepares CM.L2-3.4.9 evidence
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure so that installation rights, approval routes and monitoring produce evidence an assessor can test. We prepare systems, controls and evidence; the organization owns its controls and an independent assessor issues any assessment result.
How we scope
- Engagements are fixed-scope, with the covered endpoints, operating systems and software sources agreed in writing before work starts.
- The written scope names who may install software, which approval roles exist and where the rules of user-installed software are recorded.
- We confirm which assessment objectives for 3.4.9 the scope covers and which ones remain with your internal policy owners.
How we build
- We configure inventory and monitoring tools such as osquery, Wazuh Syscollector or GLPI to record software installed on each endpoint.
- We build technical controls that limit installation rights on managed endpoints, aligned to the policy your organization approves.
- We set up monitoring queries and alerts that flag installations outside the approved list, and test them against sample installations.
How we hand over
- You receive the configuration records, query definitions, alert rules and test results that show each control operating as designed.
- Documentation maps each installation rule and monitoring output to the 3.4.9 assessment objectives, so your assessor can trace evidence.
- Handover includes a walkthrough of how to pull monitoring records, review exceptions and keep the rules current after changes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, covering tool updates and changes to the approved software list.
- We can re-test installation controls after endpoint builds, major software changes or changes to your policy.
- Ask any provider to confirm in writing which evidence they prepare and which parts your assessor or certification body independently reviews.
