CM.L2-3.4.2 Security configuration enforcement: evidence guide

What CMMC requires for security configuration enforcement

A defense contractor under CMMC Level 2 must show that every IT product in its CUI environment starts from documented security configuration settings and stays on them. CM.L2-3.4.2 asks the organization to establish security configuration settings for information technology products, include those settings in the baseline configuration, and enforce them. The requirement is the Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.4.2, a basic security requirement in the Configuration Management family. It sits beside CM.L2-3.4.1, which covers the baseline itself. This section covers the enforcement side: the settings that matter, how they get applied, and how the organization proves they are still in place.

NIST SP 800-171A (June 2018) splits the requirement into two assessment objectives. In plain words, the first asks whether the organization has set security configuration settings for each IT product and put those settings into the baseline configuration. The second asks whether the organization actually enforces those settings on the systems in scope. An assessor will look for both. A checklist that exists only in a document, with no proof that machines match it, does not satisfy the second objective. The requirement is worth 5 points under the CMMC Scoring Methodology, so a NOT MET result removes 5 points from the maximum score of 110. Because it is worth more than 1 point, it cannot go on a POA&M under 32 CFR 170.21, so it must be fully MET before the organization can reach Conditional or Final Level 2 status.

Most of the difficulty is in the environment, not the wording. Defense contractors run many products, including operating systems, firewalls, cloud consoles, databases and collaboration tools, and each has default settings that ship weaker than the organization's target. Endpoints that are not centrally managed drift away from the baseline over time, and changes made during troubleshooting are rarely written down. Deviations from the baseline are often approved informally or not at all. Before planning work, confirm which products hold CUI or security-relevant data, who owns each baseline, and where the approved deviation records live. Ask your assessor or C3PAO how they expect to see those records in final form.

Which systems and teams fall under this requirement

CM.L2-3.4.2 applies to the IT products inside the CUI boundary described in the system security plan, not to every device a company runs. Scope decisions determine which settings must be hardened, which teams own them, and which third parties must be held to the same baseline.

Servers and hypervisors in the boundary

Every server, virtual machine host and hypervisor that stores, processes or transmits CUI needs a documented security configuration and a baseline entry. Hypervisor management planes often sit outside the boundary by habit, so check whether they can reach CUI workloads. If they can, they belong in scope. Ask the team to list each host by name and tie it to the SSP. Hardening a host that the SSP does not name does not count toward this requirement for the systems that are named.

Endpoints and user workstations

Laptops and desktops that open CUI, including remote and travel devices, are usually the largest share of in-scope products. Each device type needs its own settings baseline, and drift on endpoints is the most common finding. Confirm which device groups are covered by management tooling and which are managed by hand. Devices that never touch CUI may be out of scope, but the boundary must be drawn so an assessor can see that line clearly.

Network devices and security appliances

Firewalls, routers, switches and VPN concentrators that enforce the boundary are in scope because their settings decide what reaches CUI. Review admin interfaces, management protocols, logging and default accounts. Confirm who owns each device, since network teams often change rules without a security sign-off. Export each configuration on a schedule so changes can be compared against the approved baseline.

Cloud services and databases

Cloud tenants, managed databases and SaaS platforms that hold CUI have configuration settings even when the provider runs the hardware. The organization still owns the settings it controls, such as storage access policies, encryption options and administrative roles. Document the shared responsibility split for each service in the SSP. Ask the provider for the configuration evidence it supplies and confirm which settings the organization must set itself.

Teams and their configuration ownership

Settings are often changed by infrastructure, desktop, network and application teams, each with different tools. Assign one accountable owner per product class and record who may change each setting. Without this, the baseline describes intent but no one can prove who enforces it. Clarify where security sets the standard and where operations applies it, and keep that split consistent across the SSP and the change process.

Third parties that manage configuration

Managed service providers, outsourced IT operators and implementation partners that administer in-scope products must follow the same baseline, and their changes must produce evidence the organization can review. Write these duties into service agreements and confirm how the provider reports deviations. Independent assessors examine what the organization can show, so provider-held logs and reports should be accessible to the organization, not kept only by the vendor.

How the security configuration ties to the baseline

CM.L2-3.4.2 only works when it sits on top of the baseline configuration from CM.L2-3.4.1. The security configuration settings for each IT product must be established and then included in that baseline, so the baseline becomes the record of what each system is supposed to look like. The Level 2 Assessment Guide adds a standard for what those settings should be: they must reflect the most restrictive settings appropriate for the system. Any required deviation from the baseline must be reviewed, documented and approved. In practice, the organization owns this decision for each system type, and an assessor will ask how a given setting was chosen and who signed off on any exception.

Hardening checklists are the usual way to turn that standard into documented settings. Organizations commonly start from CIS Benchmarks, vendor hardening guides or, where applicable, DISA STIG-style checklists, then remove the settings that do not fit their environment and record why. Each checklist item should name the configuration key, file or policy it governs and the value adopted, so the checklist can be compared with the running system later. Whether a given benchmark or STIG applies to a specific product is a question to confirm against the product and the contract scope, not something to assume.

NIST SP 800-171 Rev. 2 Appendix D, Table D-4, maps the basic configuration management requirements 3.4.1 and 3.4.2 together to SP 800-53 Rev. 4 controls CM-2 (Baseline Configuration), CM-6 (Configuration Settings), CM-8 (Information System Component Inventory) and CM-8(1) (Updates During Installations and Removals). For a defense contractor, this means the inventory from CM.L2-3.4.1, the settings from the checklist and the update records must agree. Before an assessment, check that every in-scope asset appears in the inventory, carries a baseline that names its settings, and has a recorded approval for each deviation. Gaps between those three records are the most common reason the configuration story does not hold together under questioning.

How an assessor tests security configuration enforcement

This table compares the two assessment objectives for CM.L2-3.4.2 against the test approach, the evidence an assessor requests and the findings that most often prevent a MET result. A requirement is MET only when every applicable objective is satisfied with evidence in final form, so drafts and undocumented settings do not count toward the score.

Assessment objective	What the assessor tests	Evidence requested	Common findings
Objective 1: Settings established and in baseline	Whether security configuration settings exist for each IT product in scope and are included in the baseline configuration (CM.L2-3.4.1)	Approved hardening checklists or benchmarks, baseline configuration records per product, and the SSP section that names them	Checklists exist but are not tied to the baseline, or products in scope have no recorded settings
Objective 1: Settings are the most restrictive appropriate	Whether the chosen settings reflect the most restrictive values appropriate for the system, as the CMMC Assessment Guide expects	Written rationale for each setting that is less restrictive than the benchmark, with the owner's sign-off	Default vendor settings retained without review or justification
Objective 2: Settings enforced	Whether the settings are actually applied on live systems, tested through the mechanisms that push, lock or monitor them (for example, group policy, configuration management or scripted checks)	Configuration scan or compliance reports from the reporting period, screenshots or exports showing applied values, and enforcement policy exports	Settings documented but not applied, enforcement limited to a sample of systems, or reports that are days or weeks old
Mechanism tests (monitor, control, identify deviations)	Whether tools that monitor settings detect drift, alert on it and record the result, and whether the organization can show they run as described	Scan policies, alert records, drift or file integrity logs, and proof that the monitoring covers in-scope assets	Monitoring tool installed but not scoped to CUI systems, or alerts sent to no one who acts on them
Approved deviations	Whether every deviation from the baseline was reviewed, documented, approved and time-limited, with compensating measures where applicable	Deviation register with the setting, reason, approver, date, compensating control and review date	Deviations made during troubleshooting and never recorded, or approvals given by the administrator who made the change
Change linkage	Whether changes to security settings pass through change control and the baseline is updated afterward	Change tickets that reference the setting, updated baseline versions, and matching scan results after the change	Settings altered directly on the system with no ticket or baseline update
Evidence form	Whether each artifact is in final form and dated within the assessment period	Approved, signed or exported records with dates and versions, not working drafts or screenshots without context	Drafts in the evidence folder or reports that cannot be tied to a specific system and date

How to implement security configuration enforcement step by step

This sequence moves a set of in-scope products from an agreed hardening checklist into an approved baseline, enforced settings, continuous drift detection and documented deviations, so that CM.L2-3.4.2 can be shown as met with evidence an assessor can test.

Select the IT products in scope
The organization, with its implementation partner if one is engaged, lists every IT product used in the systems that process, store or transmit CUI, including operating systems, databases, network devices, cloud services, endpoint agents and security tools. The list should match the asset inventory and system boundary in the system security plan. The step is complete when the owner of each product is named and the list has been reviewed against the boundary. Products left off the list are the most common source of later findings, so ask the assessor how they will check for omissions.
Adopt a hardening checklist for each product
For each product, select a recognized security configuration checklist, such as a published vendor or community benchmark, and record which version was chosen and why. Where the checklist is too permissive for the system, document the stricter settings the organization will apply, since the CMMC Assessment Guide expects settings to reflect the most restrictive settings appropriate for the system. The output is a signed checklist per product that states each setting, its chosen value and the approver. Confirm the checklist source and version with the vendor or benchmark publisher before adoption.
Record approved settings in the baseline
Convert each signed checklist into the baseline configuration record for its product, so the approved settings are part of the documented baseline described under CM.L2-3.4.1. The record should show the product, version, owner, approved settings and the date of approval. This is the point where the settings are included in the baseline, which is the first of the two assessment objectives for 3.4.2. The output is a baseline record per product that a reviewer can compare against the live system later.
Deploy and enforce the approved settings
Apply the baseline settings through the mechanism the organization uses, such as configuration management tooling, group policy, golden images, infrastructure-as-code or agent policies, and restrict who can change them. Test the mechanism on a non-production system first, then deploy to production in a controlled way. The step is complete when a sample of systems shows the settings in place and the enforcement mechanism reverts unapproved changes, or alerts on them. The output is a deployment record and an enforcement configuration export that the assessor can review.
Set up drift detection against the baseline
Configure ongoing checks that compare live settings with the approved baseline and report differences. Open-source options include Wazuh Security Configuration Assessment, which scans endpoints against YAML policies that can be extended with custom checks, and Fleet policies, which run osquery queries and show which devices pass or fail each policy. For changes to critical files, osquery file integrity monitoring or Bareos Verify jobs can record changes against cataloged attributes. Confirm each tool's coverage for your products and operating systems before relying on it. The output is a drift report that lists failing hosts and the setting that differs.
Run the deviation approval workflow
When a system needs a setting that differs from the baseline, the requester documents the business or technical reason, the security impact, the affected systems and the compensating measures. A designated reviewer, usually the security owner with the system owner, approves or rejects the deviation, and the approval is recorded with its scope and review date. Deviations found by drift detection without an approved record go back into this workflow or are corrected. The output is a deviation record for each approved exception, which is the evidence the standard expects for approved deviations from established settings.
Retain evidence for the assessor
Collect and retain the signed checklists, baseline records, enforcement exports, drift reports, deviation records and related change control and audit records in final form, with dates and owners. Keep the evidence current so that the period shown by the drift reports matches the period of the assessment. Ask the assessor, before the assessment, which artifacts and sample sizes they expect, since evidence in draft form does not satisfy an objective. The output is an evidence package mapped to the two assessment objectives for CM.L2-3.4.2 and kept with the system security plan.

Evidence that passes a 3.4.2 assessment

An assessor testing CM.L2-3.4.2 looks for evidence that settings were defined, that they are in the baseline, and that they are enforced and checked over time. The cards below cover the artifacts that show each of those steps, and each one must be final and current when the assessment happens.

Baseline configuration records

The baseline is the reference point that shows which security settings were approved for each IT product in scope, including the version and build it applies to. Assessors check that the hardened settings appear in the baseline, not only in a hardening script or an administrator's memory. Confirm that each baseline names an owner, a review date and the systems it covers, and that it matches what the system security plan describes.

Security configuration checklists

Checklists translate each baseline into item-by-item settings, such as password policy, audit policy, service state and file permissions, with the expected value for each. Use a recognized benchmark as the starting point where one exists, then record every setting you changed and why. Assessors compare the checklist against a live system, so a checklist that no longer matches the running configuration fails the test.

Compliance scan reports

Scan reports show current settings measured against the baseline on each endpoint, server or network device. Wazuh Security Configuration Assessment checks files, directories, registry keys and running processes against YAML policies, and Fleet policies show which devices pass or fail each osquery-based check. Keep dated exports for each assessment period, and confirm that the scans cover every in-scope asset, including systems that are rarely patched.

Change control records for setting changes

Each change to a security setting should trace back to a change record that shows the request, the approver, the implementation date and the baseline version it updated. Assessors sample setting changes and ask whether they went through the change process. Check that emergency changes are logged and reviewed after the fact, so that no setting moved without a record.

Approved deviation records

A deviation is a documented exception where a system must run a setting that differs from the baseline. The record should state the setting, the business or technical reason, the compensating controls, the reviewer, the approval date and an expiration or review date. The CMMC Assessment Guide expects deviations to be reviewed, documented and approved, so an undocumented exception is treated as a failed setting.

Drift detection and audit records

Drift records show when a monitored setting or file changed outside the approved process, along with the time, the path and the hash of the changed item. osquery file integrity monitoring logs changes to the file_events table, and Bareos Verify jobs compare files against previously cataloged attributes. Review drift alerts on a set schedule and keep the triage notes, since assessors look for evidence that deviations were noticed and resolved.

Handling approved deviations and configuration drift

A deviation is any setting that differs from the approved baseline, and CM.L2-3.4.2 requires that every deviation be reviewed, documented and approved before it stays in place. The CMMC Assessment Guide Level 2 expects the most restrictive settings appropriate for the system, so a deviation needs a stated reason, such as a vendor dependency or a legacy application that cannot run under the standard setting. Build a request form that names the affected IT product, the setting and its baseline value, the requested value, the business or technical justification, the compensating controls, the approver and an expiry date. The approver should be a role independent of the requester, such as the system owner with security sign-off, and the approval record should live in the same system as your change records so an assessor can trace it.

Time-bound every approved deviation. An open-ended exception is hard to defend because nothing forces anyone to revisit it, and assessors look for evidence that approved deviations are still current. Set a review date for each one and confirm the review cadence with your assessor and your written configuration management policy, since the assessment objectives do not prescribe a specific interval. Expired deviations should either trigger a new approval or revert to baseline automatically through your configuration tooling.

Drift detection is how you find settings that changed without an approved deviation. Scheduled compliance scans, such as Wazuh Security Configuration Assessment policies run against your hardening checklist, compare live endpoints to the baseline and report failed checks with remediation guidance. Fleet policies written as osquery queries show which devices pass or fail each check, which gives a current view across a fleet. For file-level changes, osquery file integrity monitoring records changes to the paths you list under file_paths in the file_events table, and Bareos Verify jobs compare files against previously cataloged attributes. Reconcile every failed check against the deviation register: a failure with an approved, unexpired deviation is documented, and a failure without one is a finding to investigate and remediate. Keep the scan results, the reconciliation and the remediation tickets as dated evidence.

What meeting 3.4.2 costs in money and effort

This table breaks down the cost components of meeting CM.L2-3.4.2 security configuration enforcement, showing who is paid for each piece, whether it is one-time or recurring, and what drives it up. Use it to build a quote request and to see where open-source tooling can reduce license spend, while engineering and review effort stays with your team or your partner. No figures are given because none were supplied for this requirement; ask vendors and partners for them in writing.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it and what to ask for
Hardening checklist work	Internal engineers or an implementation partner selecting and tailoring benchmarks	One-time, then revisited on each product upgrade	Number of product types in the system. Ask for the list of checklists, the source benchmark for each, and the tailoring decisions.
Scanner and compliance tooling licenses	Commercial vendor if one is chosen; none for self-hosted open source such as Wazuh or Fleet, though hosting still costs money	Licenses usually recurring; open-source tools carry no license fee	Endpoint count and number of custom policies. Ask whether licensing is per endpoint, per policy or per module, and what hosting the tool requires.
Engineering time to set and enforce settings	Internal platform or IT staff, or a partner under a fixed-scope agreement	One-time for initial enforcement, recurring for exceptions and drift fixes	Number of systems and the mix of operating systems and applications. Ask for the enforcement method (policy push, configuration management or manual) and the acceptance test.
Drift monitoring and deviation review upkeep	Internal security or operations staff, or a retainer partner	Recurring	Change volume and number of approved deviations. Ask how alerts are triaged, who approves deviations, and how approvals are recorded.
External testing or independent review	Security testing firm or consultant, separate from the assessor	Periodic, often tied to major changes	Scope of systems in the assessment boundary. Ask whether the review covers configuration checks, and whether results are retained as evidence.
Assessor effort	Independent assessor or certification body, not the implementation partner	Recurring at each assessment cycle	Evidence readiness and number of systems in scope. Ask the assessor for its fee basis and what evidence it will request before the engagement starts.

Open-source tools that produce 3.4.2 evidence

Wazuh's Security Configuration Assessment scans monitored endpoints for misconfigurations. Its checks are written as YAML policies, most of them based on CIS benchmarks, and they examine files, directories, registry keys and running processes. Each failed check comes with a remediation recommendation, which gives the assessor a record of the gap and the fix path. This tab covers the scan output, not the baseline itself, so the team must still show that the benchmark selected matches the approved baseline configuration.

Policy source: Most shipped policies follow CIS benchmarks. Confirm which benchmark version each policy uses and map it to your documented baseline.
Custom policies: Organization-specific checks can be written in YAML for settings that the shipped policies do not cover, such as internal application settings.
Scan history: Keep dated scan results so the assessor can see enforcement over the assessment period, not a single snapshot.
Remediation trail: Link each failed check to a change record or approved deviation.
License: Wazuh is GPL-2.0-only. Confirm with counsel what that license requires if you modify and distribute the software.

Confirm with your assessor that scan output is accepted as evidence of configuration settings and that the policy set is documented in your System Security Plan.

osquery's file integrity monitoring watches the files and directories listed under file_paths in its configuration. Changes are recorded in the file_events table with the action, the time and the path. Where possible, osquery also calculates MD5, SHA1 and SHA256 hashes of changed files. This gives the team a record of when a protected configuration file changed, which is the drift detection half of 3.4.2 that baseline comparisons alone do not provide.

Watched paths: Build the file_paths list from the configuration files your hardening checklist protects, such as sshd and audit configuration.
Event records: Query file_events on a schedule and retain results so an assessor can see changes over time.
Hash values: Compare hashes against the approved baseline to show whether a changed file matches an authorized version.
Coverage gaps: Hashes are not always calculated, so confirm which events include them before relying on that field.
License: osquery is dual licensed under Apache-2.0 or GPL-2.0-only. Confirm which license your organization adopts.

Confirm with your assessor that file events tied to approved change records are accepted as drift evidence, and document the watched path list in your SSP.

Where organizations fall short on 3.4.2

Most 3.4.2 findings come from the same few gaps: settings with no baseline to measure against, changes nobody recorded, and exceptions with no paper trail. The cards below cover what assessors look for and the step that closes each gap. Each gap is a separate failure point, so check all six against your own environment.

No documented baseline to compare against

Teams often harden systems but never write down the approved target state. Without a baseline configuration, there is nothing to measure drift against, and the assessor cannot tell whether a setting is correct or merely present. Under 3.4.2, the settings must be included in the baseline configuration, so the baseline is the reference point for every later check. Check that each product class has a written baseline with a named owner and a version date.

Settings applied but not recorded

Hardening scripts and manual changes often leave no record of which values were set, on which hosts, and when. An assessor testing whether settings were established will ask for the configuration state itself, not a description of intent. Keep exported configuration files or checklist results that show each setting's value per system. Confirm that a new host gets the same record on its first build.

Deviations approved verbally

A deviation from a baseline setting is acceptable only when it is reviewed, documented and approved. Verbal approvals in a hallway or chat thread leave no evidence that the review happened, who approved it, or why the risk was accepted. Each deviation needs a written record that names the setting, the affected system, the business reason, the approver, and an end date or review trigger. Confirm that every deviation in production has a matching approved record.

Drift not monitored

A system can match its baseline at build time and then drift after patches, emergency fixes or local administrator changes. Assessors look for mechanisms that identify deviations, not just a one-time snapshot. Scheduled compliance scans or file integrity checks on configuration files can show when a setting changed and where. Ask who receives drift alerts and what happens to each one.

Checklists kept as drafts

Hardening checklists that sit in a shared drive as drafts, with no version, approver or date, weaken the evidence. The assessment method treats evidence in draft form as not final, so a requirement backed only by draft checklists may not be met. Move each checklist to a controlled, approved version that maps to the baseline and records who signed it off. Keep the superseded versions so the history is traceable.

Products outside the scan scope

Scanners and compliance policies only test the systems they are pointed at. Network devices, hypervisors, container hosts, cloud services and specialized assets are often left out, so their settings are never checked against the baseline. Build an inventory of every IT product in the assessment boundary and confirm each one has a checklist and a monitoring path. Document the exclusions that remain and the reasons for them.

Questions about CM.L2-3.4.2 cost, effort and evidence

What drives the cost of meeting CM.L2-3.4.2?

The main cost driver is how many IT products sit in scope and how many of them already have a documented hardening baseline. Each product type (operating systems, databases, network devices, cloud services, endpoint agents) needs its settings chosen, documented against a checklist, applied, and monitored. Costs fall into three groups: internal staff time to decide settings and approve deviations, labor to build and apply hardening to each product, and tooling to detect drift. Tooling can be open source, so the recurring cost is mostly people time. Ask any provider for a quote that lists the in-scope product types, the number of systems per type, and whether the work includes writing checklists or only applying them.

How long does a CM.L2-3.4.2 implementation take?

No fixed duration applies to every environment, and no duration figure is supplied for this requirement. Timing depends on the number of product types, how far existing builds already match a recognized benchmark, and whether change control and approved deviation records already exist. Plan for an initial pass to set and document settings, a period of enforcement and drift checks, and then a steady recurring cycle of reviewing deviations. Your team needs an owner who approves settings, administrators who apply them, and someone who reviews drift reports. Confirm the schedule with any partner in writing before work begins.

Can we meet CM.L2-3.4.2 ourselves without an outside partner?

Yes, an organization can own this requirement with internal staff, because the assessment looks for evidence that settings are established, enforced and documented, not for a particular vendor. The work requires a person who understands each product's security options, a written approval path for deviations, and enough time to keep evidence current. Open-source tools such as Wazuh, Fleet and osquery can produce configuration and drift evidence, but staff still need to configure and read them. Many teams hire outside help for the first build or for specialized products, then keep the program in-house. Assess your team's skills honestly before deciding.

Does the Phase II suspension remove the need for CM.L2-3.4.2?

No. The suspension changes when certification assessments may be required, not what the requirement asks for. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The DoW says it will enforce NIST SP 800-171 Rev. 2 in the interim, and CM.L2-3.4.2 is part of that baseline. Confirm your current obligations with your contracting officer and the official CMMC pages, because the schedule is under review.

Can CM.L2-3.4.2 be placed on a POA&M?

No. CM.L2-3.4.2 is a 5-point requirement, and under 32 CFR 170.21(a)(2) requirements worth more than 1 point cannot go on a plan of action and milestones. It must be MET to reach Conditional or Final Level 2 status. Under the CMMC Scoring Methodology in 32 CFR 170.24, a NOT MET result subtracts 5 points from the maximum score of 110. Because the requirement cannot be deferred, work on it early. Plan the settings, deviation approvals and evidence before any assessment window, and confirm the scoring rules against the current eCFR text.

What evidence will an assessor expect for CM.L2-3.4.2?

Assessors look for a documented baseline, the security configuration checklists used, and records showing settings were applied and enforced. SP 800-171A lists the baseline configuration, security configuration checklists, evidence supporting approved deviations, change control records and audit records as potential evidence. Assessors also test the mechanisms that implement, monitor or control settings and identify deviations. Evidence must be in final form, not drafts. Keep dated checklists, scan outputs showing passing and failing hosts, and signed deviation approvals. Confirm specific evidence formats with your assessor, since they make the final call.

What can a partner do for CM.L2-3.4.2, and what can it not do?

A partner can plan the scope, write or adapt hardening checklists, implement settings in your systems, configure drift detection with open-source tools, and prepare the evidence an assessor will review. DeployOpen works this way inside the client's own infrastructure, under a fixed scope agreed in writing. A partner cannot own your controls, approve your deviations on your behalf, or issue an assessment result. Only an independent assessor or certification body can issue reports or certificates. Your organization remains accountable for its settings and the approvals behind them.

What does drift detection cost to run after go-live?

Drift detection carries recurring costs in staff time and in the infrastructure that runs the monitoring. Open-source tools such as Wazuh Security Configuration Assessment, Fleet policies and osquery file integrity monitoring carry no license fee under their stated licenses, so the ongoing cost is operating them, reviewing failing results and maintaining the policies. Ask any provider which parts are one-time (building checklists and initial hardening) and which recur (monitoring, updates, reviews, retainers). A retainer for ongoing support is available from DeployOpen, priced only through a written scope.

How DeployOpen prepares 3.4.2 evidence

DeployOpen plans, builds and documents the configuration enforcement layer for CM.L2-3.4.2 inside your own infrastructure, so your team can show an assessor that approved settings are in the baseline and actually enforced. DeployOpen prepares systems and evidence; your organization owns the controls and an independent assessor makes the determination.

How we scope

Engagements are fixed-scope, with the in-scope systems, products and deliverables for 3.4.2 agreed in writing before work starts.
We confirm which IT products fall under the security configuration requirement and which baseline configuration each one must match.
The written scope names who approves deviations and where drift reports and approval records are stored.

How we build

We set up hardening checklists for each product class and map each setting to the baseline configuration record.
We deploy open-source drift detection, such as Wazuh configuration assessment policies and Fleet yes or no policies, against those settings.
We configure osquery file integrity monitoring on the files and directories that carry security settings, so changes are logged with time and path.

How we hand over

We document the configuration baseline, checklists, deviation approvals and test results in a form your assessor can trace to the objectives in SP 800-171A.
We deliver runbooks showing how a deviation is requested, reviewed, approved and closed, with the matching audit records.
We walk your team through how to export drift reports and file integrity records as evidence in final form.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
A retainer can cover updating checklists when products change, reviewing drift reports, and refreshing deviation records.
Your organization keeps ownership of its approvals, and any formal assessment remains with an independent assessor.