What CM.L2-3.4.8 asks for and why whitelisting is the stronger choice
CM.L2-3.4.8 asks you to choose one of two software execution policies and then enforce it. You either apply a deny-by-exception policy, which blocks named unauthorized software and lets everything else run, or a deny-all, permit-by-exception policy, which blocks everything except software you have authorized. The requirement does not let you leave the choice open or mix the two without a documented decision. For a compliance lead, the practical question is which policy you can actually enforce across your Level 2 system boundary and then prove with records.
The risk behind the requirement is simple: any executable that runs on a system in scope can read CUI, move data or open a path for an attacker, and a deny list only stops the programs someone already thought to name. The CMMC Assessment Guide Level 2 describes whitelisting as the stronger of the two policies, and the reason is visible in the assessment objectives of NIST SP 800-171A. Under those objectives, you must specify the policy, specify the software allowed or denied, and implement the approach as specified. A whitelist makes the second objective a closed set, so an unknown executable is blocked by default. A blacklist leaves the set open and depends on your list staying ahead of new software. Illustrative example: a contractor blacklists a known remote access tool but not a renamed copy of it, and the assessor asks which list covers that copy.
The score matters because CM.L2-3.4.8 is a 5-point requirement under the CMMC Scoring Methodology in 32 CFR 170.24. If it is NOT MET, 5 points come off the maximum of 110. Because it carries more than 1 point, 32 CFR 170.21(a)(2) does not allow it on a plan of action and milestones, so it must be fully MET to reach Conditional or Final Level 2 status. Before you commit to whitelisting, confirm with your assessor or C3PAO how they expect the authorized software list to be evidenced, including the review and update records for that list. The requirement also relies on the software inventories built under CM.L2-3.4.1 and extends CM.L2-3.4.9. If your baseline inventory of installed software is incomplete, your whitelist will be incomplete too, so treat CM.L2-3.4.1 as the prerequisite for this decision.
Which systems, software and teams fall inside the application execution policy
CM.L2-3.4.8 applies wherever software can run against CUI, so the scope is set by the assessment boundary rather than by the policy text alone. The cards below cover the asset classes, software sources and approvers that decide how much work the policy creates, and how the blacklist or whitelist choice changes that work. Confirm every boundary decision against your System Security Plan before you set enforcement.
CUI assets inside the boundary
Start with the systems your System Security Plan places inside the CUI assessment boundary, including enclaves, identity systems and any supporting tools that touch CUI. Every endpoint, server and virtual machine in that boundary is a candidate for execution control. Systems outside the boundary can stay on a lighter policy, but the SSP must show where the line sits and why. Confirm that boundary with your assessor's expectations before you write rules for it.
Endpoints and servers running CUI workloads
Workstations, build servers, file servers and virtual desktops that open CUI are where unauthorized execution is most likely to matter. Classify each asset class separately, since a laptop that browses and a server that runs batch jobs need different allow or deny sets. Shared administrative jump hosts often carry the widest execution rights, so check them first. Record the asset classes and their owners in the inventory that CM.L2-3.4.1 requires.
Software catalog and vendor executables
Your authorized software list must name each executable, not just each product, because vendor suites often ship helper binaries, updaters and command-line tools. Include signed vendor updates and their install paths, or routine patching will trip the policy. Decide how scripts, macros and interpreters are treated before you enforce anything. Review this catalog whenever a product or version changes.
Teams that approve software
Assign named owners who can approve, deny and remove software, and document the request path from a user to a decision. Security, IT operations and the business owner of the CUI system usually share this responsibility, so write down who holds the final call. Approval records are part of the evidence the assessor reviews for the list. Confirm that the approvers match the roles in your SSP and your change control process.
Blacklist versus whitelist effort
A deny-by-exception policy blocks a known list of unauthorized software, so it is quicker to start but leaves unknown software running. A permit-by-exception policy allows only approved software, which the CMMC Assessment Guide treats as the stronger option, and it requires a complete and current inventory before enforcement. Whitelisting usually means more upfront effort and more approval traffic, but less ongoing exception handling. Your choice should match the asset classes you decide to enforce.
Enforcement scope and exceptions
Decide which asset classes the enforced policy covers in the first pass and which get monitoring only. Each narrower scope lowers near-term effort but must still be explained in the SSP, because the requirement applies to the systems inside the boundary. Document exceptions with an owner, a reason and an expiry, and reflect them in the lists so the assessor can trace each one. Revisit scope whenever the boundary changes.
Choosing deny-by-exception or permit-by-exception for your environment
Deny-by-exception, the blacklisting option, lets software run unless it appears on a list of prohibited programs. The requirement names it as a way to prevent unauthorized software from executing. NIST SP 800-171 Rev. 2 Appendix D maps 3.4.8 to SP 800-53 Rev. 4 control CM-7(4), titled Unauthorized Software (Blacklisting). Under this model, the list is the control, so its accuracy determines what gets through.
- What it blocks: Only the named programs, hashes, publishers or paths. Unlisted software still runs, so new or unfamiliar tools are not stopped by default.
- List maintenance: Your team must identify and add each unauthorized item, and revisit the list when threats or business tools change.
- Operational friction: Low day to day, since users rarely hit a block, but the residual risk is higher because anything not yet listed executes.
- Evidence: The prohibited software list, its review and update records, and tests showing the enforcement mechanism blocks listed items.
- Fit: Environments with a stable, well-known software set where the main concern is specific prohibited tools.
Before committing, confirm with your assessor how they will test the blocklist's completeness and what review frequency your own documentation must state.
Permit-by-exception, the whitelisting option, denies all software by default and allows only what is on an authorized list. The CMMC Assessment Guide Level 2 describes whitelisting as the stronger of the two policies. The related control, CM-7(5) in NIST SP 800-171 Rev. 2 Appendix D (Table D-4), is titled Authorized Software (Whitelisting). Here the authorized list defines the boundary of what can run at all.
- What it blocks: Everything not on the authorized list, including software nobody has yet reviewed.
- List maintenance: Requires a complete, current inventory of approved software, which depends on the software inventories covered by CM.L2-3.4.1 and extends the user-installed software controls in CM.L2-3.4.9.
- Operational friction: Higher. Each new tool, update or patch that changes an executable may need an approval step before users can run it.
- Evidence: The authorized software list, records of additions and removals, the enforcement configuration, and tests showing unapproved programs are blocked.
- Fit: Environments with defined user populations, fixed application sets and a change process that can absorb approval turnaround.
Before committing, ask your team how long an approval for a routine update takes and whether that delay is acceptable to the business.
Both policies depend on lists, so the real cost is ongoing maintenance rather than the initial setup. Assessors test whether the lists exist, reflect the environment and are kept current. The effort differs in where it falls: blocklists need threat-driven updates, while allowlists need steady approval traffic tied to change control. Neither option removes the need for records that show who approved what and when.
- Who does the work: Security staff usually own the policy, platform engineers run the enforcement, and application owners request additions.
- Recurring work: Reviewing list entries, processing requests, reconciling the list against the software inventory and recording changes.
- What drives effort up: Many endpoint types, frequent software updates, multiple operating systems, and loosely defined ownership of software.
- What drives effort down: A small, standard software set, automated inventory collection, and a documented approval path linked to change control.
- What to ask for in a quote: An estimate of list maintenance hours per month, a description of how inventories feed the lists, and the approval workflow to be delivered.
Before committing, confirm who in your organization signs off on list changes and how often that person must do so.
The requirement lets you specify one approach for each system, and assessors check that the chosen approach is specified and implemented as written. Many organizations split their environment: a permit-by-exception policy on sensitive systems that handle CUI, and a deny-by-exception policy on lower-risk or specialized assets where a full allowlist would be impractical. Document the split clearly in the system security plan so the assessor can see which policy applies where.
- Clear boundaries: Each system or enclave states one policy, with its scope written down.
- Consistent specification: The same policy applies within each defined scope, with no undocumented exceptions.
- Specialized assets: Engineering workstations or test equipment may need separate handling, which should be explained in your plan.
- Shared components: Where one tool crosses both scopes, agree which policy governs it and record the decision.
- Change control: Moving a system between policies counts as a change and should go through the same approval record.
Before committing, confirm with your assessor that the split is acceptable for your system boundary and that the documentation explains every scope.
How to implement the application execution policy step by step
This sequence takes an organization from a documented choice between deny-by-exception and permit-by-exception to a tested enforcement mechanism and a review cadence that keeps the software lists current for assessors.
Document the policy decision and scope
Decide whether the system will use a deny-by-exception (blacklisting) policy, a permit-by-exception (whitelisting) policy, or a combination, and record the reasoning in the system security plan. Define which systems, user groups and software types the policy covers, including servers, endpoints and specialized assets. Assessors look for an explicit decision, so the output is an approved policy statement with a named owner and a change control reference. The step is done when the policy names the approach and its boundaries.
Build the authorized or unauthorized software lists
Start from the software inventory produced under CM.L2-3.4.1 and classify each item as authorized, unauthorized or pending review for the scoped systems. Record the business justification, version or hash where practical, and the approver for every entry. For a whitelisting policy the authorized list is the control; for blacklisting the unauthorized list is. The output is a versioned list with approval records, and the step is done when every inventoried item has a disposition.
Configure the enforcement mechanism
Select the application control, endpoint protection or configuration tooling that will enforce the chosen policy, and configure it to allow or deny execution as the policy specifies. Confirm with the vendor or your own environment which enforcement modes, rule types and logging the tool supports before committing to a design. Store the configuration as a security configuration checklist under change control. The output is a documented enforcement baseline, and the step is done when the configuration matches the approved lists.
Test blocked and allowed software behavior
Test the enforcement against both sides of the policy: confirm that unauthorized software is prevented from running and that authorized software still executes on representative systems. Run the tests on each system class in scope and record the expected result, actual result and tester for each case. Exceptions found during testing should go through the change process rather than being quietly added to the list. The output is test records, and the step is done when every test case matches the specified behavior.
Monitor compliance against the lists
Schedule continuous or periodic checks that compare running and installed software against the approved lists, using endpoint query or scanning tools where they fit the environment. Open-source options such as osquery, Fleet policies and Wazuh configuration assessment can report on process and file state, but confirm that each fits your platforms and log retention needs. Route deviations to an incident or change record. The output is monitoring evidence showing the policy is operating, and the step is done when results are retained and reviewed.
Record policy changes through change control
Treat every addition, removal or modification to the software lists and the enforcement rules as a change. Raise a change request, perform a security impact analysis, obtain approval from the change control board and log the outcome with the date, approver and affected systems. Update the system security plan and the baseline when the policy changes. The output is a change control record for each policy change, and the step is done when no list entry exists without an approval trail.
Set the review and update cadence
Define how often the authorized or unauthorized lists are reviewed, who performs the review, and what triggers an out-of-cycle review, such as a new system, a significant vulnerability or a change in mission. Ask your assessor or the assessment guidance which cadence they expect you to justify, and document your chosen interval in the policy. Keep review minutes and updated list versions as evidence. The output is a published review schedule with completed review records, and the step is done when the first review cycle is closed and filed.
How an assessor tests CM.L2-3.4.8 against the three objectives
This table takes each of the three SP 800-171A assessment objectives for CM.L2-3.4.8 and shows what the assessor checks, what evidence they ask for and where organizations usually fall short. The requirement is MET only when every applicable objective is satisfied with final evidence, so a gap in any one row keeps the whole requirement from passing.
| Assessment objective | What the assessor tests | Evidence requested | Common findings |
|---|---|---|---|
| Policy choice | Whether the organization has specified deny-by-exception (blacklisting), permit-by-exception (whitelisting), or both where documented | Signed software execution policy naming the chosen approach and the systems it covers | Policy says blacklisting but the mechanism enforces allow-listing, or the choice is never written down |
| Software lists specified | Whether the authorized or unauthorized software lists exist, name specific software, and match the policy chosen | Current allow or deny lists, owner, approval records and the inventory they derive from | Lists are generic categories, omit versions, or do not cover servers and admin tools |
| Lists reviewed and updated | Whether the lists are reviewed on a defined cycle and changes are recorded | Review records, dated revisions and change control tickets that added or removed entries | Lists were written once and never revisited, or drafts are presented as final |
| Mechanism implemented as specified | Whether the execution control actually blocks or permits software as the policy and lists state | Configuration of the enforcement mechanism, test results showing blocked or allowed execution, and security configuration checklists | Enforcement set to audit mode only, exceptions outside the lists, or no test of the control |
| Requirement result | Whether all applicable objectives are satisfied with evidence in final form | Final versions of policy, lists, review records and test output dated before the assessment | Any unmet objective makes the requirement NOT MET, and a 5-point requirement cannot go on a POA&M |
Evidence that passes CM.L2-3.4.8 and how to keep it current
Assessors test CM.L2-3.4.8 by reading the software lists, the records behind them, and proof that the enforcement mechanism works as specified. The cards below cover each artifact named in the assessment guidance and the habits that keep it current between assessments.
Authorized or unauthorized software list
This is the core artifact: the explicit list of software allowed to execute (permit-by-exception) or denied (deny-by-exception), depending on the policy your organization chose. Each entry should name the product, version or version range, publisher, and the approving owner. Check that the list matches the policy statement in your system security plan. Confirm which policy applies to which asset class, because a single list covering servers, engineering workstations and laptops often hides gaps.
Records of list review and update
An assessor will look for dated evidence that the list was reviewed, changed and approved, not just a current copy. Keep a revision history with the reviewer, the reason for each addition or removal, and the approval reference. Set a review cadence in your procedures and record each review even when nothing changed. A list with no revision history, or one last touched before a major software refresh, reads as stale.
Software inventory feeding the list
CM.L2-3.4.8 relies on the software inventory maintained under CM.L2-3.4.1, so the authorized list is only as current as that inventory. Reconcile the two regularly: any executable observed on an endpoint that appears in neither the allow list nor the deny list is an exception that needs a disposition. Osquery can report running processes and file hashes across hosts, which gives you a current observed set to compare against the list.
Security configuration checklists
Checklists show how the enforcement mechanism is set up on each system class, such as the application control policy, its mode (audit or enforce), and the exception process. Keep them versioned with the system baseline and update them whenever the enforcement tool changes. Verify that the checklist still matches what runs on the endpoint, since drift between documented and actual settings is a common finding.
Change control records for list updates
Every addition, removal or exception to the software list should pass through the same change process used for other system changes. Link each list change to a change ticket, the security impact review, and the approval from the change authority. Changes made outside the process, such as a developer adding a tool to a deny exception, are the records assessors ask about first.
Test results of the enforcement mechanism
Assessors test whether the mechanism actually blocks or permits software as the policy states. Keep dated test results showing that an unlisted executable is prevented on a sample of each system class, and that a listed one runs. Repeat the tests after major OS or agent updates and record the failures and fixes. Compliance scans from tools such as Wazuh Security Configuration Assessment can support this evidence but do not replace a direct test of the enforcement.
What meeting CM.L2-3.4.8 costs in money and effort
This table breaks down the cost and effort components of meeting CM.L2-3.4.8, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to shape the questions you put to a partner or vendor before you accept a quote. No prices or durations are estimated here because none were supplied.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it |
|---|---|---|---|
| Enforcement tooling or licenses | Tool vendor or open-source project (license spend), plus your internal or partner team for deployment | Licenses recur if commercial; open-source tools have no license fee but still need hosting and staff | Number of endpoints, server count, and whether you need central reporting or only local blocking |
| Engineering time to build allow or deny lists | Your engineers or an implementation partner under a fixed-scope agreement | One-time for the initial list, then recurring as software changes | Number of approved software packages, how many business applications run on each device class, and how much vendor documentation exists |
| Testing that blocking works as specified | Your engineers or partner, often across a test group of representative devices | One-time per policy version, repeated after major changes | Number of distinct device builds, number of user roles, and how many exceptions must be proven |
| Ongoing list upkeep and exception handling | Your IT or security operations staff, or a retainer partner | Recurring | Change rate of software, frequency of patches, and how quickly new requests are approved or rejected |
| Change control for list updates | Your change advisory process and the staff who approve each list change | Recurring | Volume of list changes and whether list edits must pass the same review as other configuration changes |
| External review of the policy and evidence | Independent assessor or consultant, paid by you; the assessor's fee is set separately | Usually one-time per assessment cycle | Scope of systems in the assessment boundary and how complete the list records are on assessment day |
| Assessor sampling | Assessor fee, which depends on the assessment plan and sampling approach | Recurring at each assessment | Number of devices sampled and the number of software lists and exception records the assessor reviews |
| Self-hosted open-source platform support | Internal team or partner for setup, hardening, and upgrades; no software license fee for the tools themselves | One-time setup, then recurring upgrades and monitoring | Fleet size, query frequency, data retention, and the skill of your team in the chosen tools |
Self-hosted open-source tools that support application execution evidence
The tools below can show what is running, what is installed and where a given process or file hash appears across a fleet. They produce evidence that supports an allow or deny policy, but the enforcement mechanism itself is a separate decision. Confirm each product's capabilities in your own environment before writing it into the SSP.
Wazuh Security Configuration Assessment
Wazuh SCA (GPL-2.0-only) scans monitored endpoints against YAML policies, mostly based on CIS benchmarks, and checks files, directories, registry keys and running processes. For CM.L2-3.4.8, it can show whether a prohibited process or component is present and where a check fails. Confirm whether you need custom policies that name your own authorized or unauthorized software, and document which checks you rely on as evidence. Review the GPL-2.0-only license terms with counsel before distributing modified agents.
Fleet policies for installed software
Fleet (MIT) policies are yes or no questions asked of devices as osquery queries. A policy such as whether a named application is absent from a device can be written against your authorized or unauthorized list. The policies page shows which devices in each fleet pass or fail, which gives assessors a current, per-device view. Fleet reports status but does not block execution on its own unless you confirm a separate enforcement feature for your version.
osquery process and file queries
osquery (Apache-2.0 OR GPL-2.0-only) exposes running processes, loaded kernel modules, browser plugins and file hashes as SQL tables. Its osqueryd daemon schedules these queries across a fleet of hosts, so you can compare running software against an approved list and hash approved binaries against the baseline. Document each query as a test of the mechanism that implements your policy, and confirm the table names and scheduling options for your deployed version. Dual licensing lets you choose the Apache-2.0 option where it suits your distribution model.
Velociraptor hunts across hosts
Velociraptor (AGPL-3.0-only) collects forensic artifacts defined in VQL from endpoints. Hunts run one or more artifacts across a group of systems, schedule offline machines to collect when they reconnect, and create a notebook per hunt for analyzing combined results. For CM.L2-3.4.8, a hunt can locate a specific unauthorized binary or hash across the estate and record where it was found. Because AGPL-3.0-only applies network-use obligations to modified versions, have counsel review your deployment model before you customize it.
Who owns the policy, who implements it and who assesses it
Your organization owns the decision the requirement actually asks for: whether software execution is governed by deny-by-exception (blacklisting) or permit-by-exception (whitelisting), and which software falls on each side of that line. The assessment objectives for 3.4.8 expect the policy to specify the chosen approach and the software allowed or denied. Those decisions belong to the people accountable for the system security plan, not to a vendor.
- Policy choice: Record whether the system uses whitelisting or blacklisting, and the reasoning. The CMMC Assessment Guide treats whitelisting as the stronger policy, so a blacklist needs a clear justification.
- Authorized or unauthorized lists: Own the lists, define who may approve an addition, and keep review and update records for each change.
- Scope of the policy: Name the systems, user groups and execution paths covered, including servers, engineering workstations and administrative tools.
- Exception handling: Decide who can approve a temporary exception and how long it lasts.
- Policy sign-off: Keep the approved, dated policy in final form, since assessors do not accept drafts.
Before engaging anyone, confirm that you can produce these decisions as signed records your assessor can read.
An implementation partner can prepare the technical side of the policy: configuring enforcement, building the inventories the lists depend on, testing the mechanisms and assembling the evidence. DeployOpen works this way for self-hosted open-source platforms inside your own infrastructure. The partner prepares systems and evidence. It does not decide the policy for you, and it does not issue reports or certificates.
- Inventory build-out: Collect the software inventory that CM.L2-3.4.1 relies on so the authorized and unauthorized lists match what runs on the endpoints.
- Enforcement and testing: Configure the execution controls, then test that the mechanisms block or allow software as the policy states.
- Monitoring checks: Set up scheduled queries or policy checks that show which devices pass or fail the chosen rules.
- Evidence packaging: Produce list versions, configuration exports, test results and change records in a form your assessor can trace.
- Documentation: Update the system security plan and runbooks so they describe the enforced state accurately.
Ask any partner to state in the written scope which of these items it delivers and which remain with your staff.
Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. Self-assessments are conducted against the NIST SP 800-171A objectives. In either case, the assessor tests the implemented policy and the evidence, and the organization does not grade its own homework through a consultant. The line is drawn where the party that prepared the evidence cannot also judge it.
- Independent testing: The assessor selects systems and checks whether the enforced state matches the documented policy.
- Consultant limits: A consultant may prepare the evidence and mock-test it, but should not perform the certification assessment.
- Evidence standard: Each objective is met only when evidence is in final form, so the assessor will reject drafts of lists or change records.
- Scoring effect: Because 3.4.8 is worth more than one point, it cannot go on a POA&M and must be MET for Conditional or Final status.
- Assessment scope: Confirm with the assessor which systems and endpoints fall in scope before preparing evidence.
DeployOpen prepares systems, controls and evidence for assessments. It does not issue audit reports, attestations or certifications.
Where CM.L2-3.4.8 implementations usually fall short
Most failed or delayed CM.L2-3.4.8 reviews trace back to a small set of gaps: lists that drift from the real inventory, reviews nobody can prove happened, and enforcement that only works on paper. Each card below names one gap, why an assessor will catch it, and the action that closes it before the assessment.
Lists that do not match the inventory
The authorized or unauthorized software list is only as good as the inventory it is checked against. If a package appears on endpoints but not on the list, or a listed application has no matching install record, the assessor sees a gap in the 3.4.8 approach itself. Because CM.L2-3.4.8 relies on the software inventories of CM.L2-3.4.1, reconcile the two sources and keep a dated record of each reconciliation.
No evidence of list review
SP 800-171A names review and update records for the software lists as potential evidence. A list that was written once and never revisited suggests the policy is not maintained. Schedule a recurring review, assign an owner, and keep the signed review record along with the list version it covered, so the assessor can see both the cadence and the decisions made.
Enforcement tested on a sample only
Assessors expect the mechanism that implements whitelisting or blacklisting to work on the systems in scope, not just on a demo host. A policy verified on one reference machine while the fleet drifts leaves objectives unproven. Query the running state across the fleet, record which hosts pass or fail, and document how failing hosts are handled. Confirm the query scope with your own environment before relying on any result.
Exceptions without approval records
Every software exception, whether an allowed install outside the list or a denied tool kept for a business need, needs a decision trail. Undocumented exceptions make the list meaningless because the assessor cannot tell approved software from software that simply escaped control. Record the requester, the business reason, the approver, the expiry, and the change record that added it to the list.
Drafts presented as final
Under the CMMC rules, a requirement is MET only when evidence is in final form, not in draft. A software list marked draft, a policy awaiting sign-off, or a review record without an approval date will not satisfy the assessment objectives. Before the assessment, freeze each artifact with a version number, an approver, and an effective date, and confirm that the system security plan references the final versions.
Policy choice never recorded
Assessment objective one asks the organization to specify whether whitelisting or blacklisting applies. Many teams implement a mix of controls without stating which policy governs which systems. Write down the chosen policy per system boundary, the reason for it, and who approved it. Whitelisting is the stronger approach, so a documented justification matters most when blacklisting is chosen.
Questions buyers ask about CM.L2-3.4.8 cost, effort and outside help
How much effort does CM.L2-3.4.8 take to meet?
The effort depends on how many software products the system runs and how many of them already have a software inventory. CM.L2-3.4.8 builds on the software inventory required by CM.L2-3.4.1, so an organization with a current, accurate inventory has the hardest part done. The work then falls into three pieces: deciding whether the policy is deny-by-exception or permit-by-exception, building the authorized or unauthorized software list, and configuring endpoints to enforce it. A small, well-documented environment with a single approved software catalog needs far less effort than a mixed fleet with many business units and no inventory. No effort figure is supplied for this requirement, so ask any consultant or internal team to estimate hours from your own inventory and endpoint count.
Can an in-house team meet CM.L2-3.4.8 without outside help?
Often yes, if the team already runs endpoint management, keeps a software inventory and has someone who can write and review change records. The requirement is not exotic. It asks the organization to choose a policy, specify the software on each list, and implement the chosen approach as specified. The harder part is the evidence: lists must be kept current, review and update records must exist, and the mechanism that enforces the policy must be testable. Teams without a security engineer or compliance lead often find this evidence work slower than the technical configuration. An outside partner can help with either part, but the organization still owns the policy, the lists and the decision to accept any residual risk.
What does the organization need to provide for an outside engagement?
The organization needs to supply access, decisions and people. Access means administrative rights or a monitored service account on the endpoints and servers in scope, plus read access to the existing software inventory and change records. Decisions include which policy model applies, who approves software for the authorized list, and who signs off on exceptions. People means a named owner who can answer questions about business applications and a change board or approver who reviews the lists. Without these, an implementation partner can build tooling, but the lists will not reflect how the business actually runs software, and the evidence will not be accepted as final.
What does a fixed-scope engagement for CM.L2-3.4.8 cover?
A fixed-scope engagement is agreed in writing before work starts, so the scope, deliverables and timeline are defined up front. For this requirement, a typical written scope would name the systems in scope, the policy model chosen, the authorized or unauthorized software lists, the enforcement mechanism, the review and update procedure for the lists, and the evidence package to be handed over. It would also say what is not included, such as the assessment itself. DeployOpen plans, implements, configures and documents self-hosted open-source platforms in the client's own infrastructure, and prepares systems and evidence for assessment. It does not issue assessment results or certifications. Ask for the deliverables list in writing and check that each one maps to an assessment objective.
How long does it take to put an application execution policy in place?
No supplied fact gives a duration for this work, so the timeline should come from a written scope tied to your environment. The main variables are the number of endpoints, whether an accurate software inventory already exists, how many business owners must approve software, and whether enforcement tooling is already deployed. Organizations with a mature endpoint management program and a current inventory typically move faster than those starting both from scratch. Also confirm the current timing of the CMMC program itself. The Department of War suspended CMMC Phase II on 13 July 2026, so check the DoW CIO About CMMC page and the suspension notice before building a schedule around any assessment date.
What drives the cost of meeting CM.L2-3.4.8?
Cost is driven by a handful of factors, and each one is a question to put to any quote. The first is the size of the estate, meaning how many endpoints and servers must enforce the policy. The second is the state of the software inventory, since building one from nothing costs more than refining one. The third is the number of exceptions and approval routes, because each one adds review work and records to keep. The fourth is whether enforcement tooling already exists or must be installed, configured and tested. Recurring costs include keeping lists current, reviewing exceptions and maintaining the tools. Ask for the one-time and recurring split in any quote, and ask which items the organization must staff internally.
Does the Phase II suspension change the work needed for CM.L2-3.4.8?
The suspension changes timing more than the technical work. The Department of War suspended CMMC Phase II on 13 July 2026, and it said Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The requirement itself is still part of NIST SP 800-171 Revision 2 as incorporated by the CMMC rule, and the DoW said it will enforce Revision 2 in the interim. Because the status is changing, confirm with the contracting officer or prime contractor which assessment applies to your contracts before committing budget to certification. Building a correct policy and evidence set is useful under either timeline.
Who issues the CMMC assessment result for CM.L2-3.4.8?
An independent assessor issues the result, not the organization or the partner that helped build the controls. For Level 2 certification, that is a C3PAO authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB. A self-assessment is performed and affirmed by the organization itself. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications. Keep the implementation partner and the assessor separate, since an assessor must remain independent of the work it reviews. Ask any partner to confirm in writing that it will not perform the assessment on the same scope.
How DeployOpen prepares application execution evidence
DeployOpen starts by agreeing the execution policy in writing before any tooling changes. The first decision is which model the organization will run for each system boundary: a deny-by-exception (blacklisting) policy that blocks named unauthorized software, or a permit-by-exception (whitelisting) policy that allows only authorized software. DeployOpen can help the client document that choice, the reasons for it and the systems it covers, since CM.L2-3.4.8 requires the policy to be specified before anything else is tested. The engagement scope then names the authorized or unauthorized software lists, the owners who approve changes to them, the review cadence, and the endpoint, server and cloud populations in scope. Scope, deliverables and timelines are fixed in a written agreement first. DeployOpen plans and implements the work inside the client's own cloud accounts, data centers or air-gapped networks, and it does not issue assessment reports or certifications. Those come only from an independent assessor.
On the technical side, DeployOpen works with the client's existing platforms and can configure open-source tools such as osquery, which exposes running processes and file hashes as SQL tables, and Fleet, which turns those queries into yes or no policies showing which devices pass or fail. Wazuh's Security Configuration Assessment can check files, directories, registry keys and running processes against YAML policies, and Velociraptor hunts can collect artifacts across groups of systems. Each tool should be confirmed against the client's environment, operating systems and license terms before it is chosen. The engagement also covers the enforcement mechanism itself, such as application control or allow-list features already present in the client's operating systems or endpoint platform, which DeployOpen would need to verify on each platform.
For evidence, the assessment objectives in NIST SP 800-171A point to lists of authorized or unauthorized software, review and update records for those lists, security configuration checklists, change control records and tests of the mechanism that enforces the policy. DeployOpen prepares these artifacts in final form, with dated approvals and records of who reviewed each change, because drafts do not count toward a MET result. The scoring rules matter here: CM.L2-3.4.8 is worth more than one point, so it cannot sit on a plan of action and milestones and must be fully MET. Clients should ask their assessor, before work starts, which test samples and export formats they expect, and should plan for ongoing list maintenance after the assessment, which is the recurring cost most often underestimated.
