03.04.02 Configuration settings: requirements and evidence

What 03.04.02 asks for, and why assessors check it closely

03.04.02 requires two things: the organization must establish, document and implement configuration settings that reflect the most restrictive mode consistent with operational requirements, and it must identify, document and approve any deviation from those settings. If a contract or CMMC obligation requires NIST SP 800-171, you need a written list of the settings each system type must carry, evidence that the settings are applied, and a register of approved exceptions. The requirement is the source for CM-6 in SP 800-53 Rev. 5, and the nonfederal organization owns the settings decision. Assessors will not accept a generic statement that hardening guides are followed without a record of which settings were chosen for which components. The hard part is the gap between what is documented and what runs. Vendor defaults often enable services, accounts, logging levels and protocols that operations never needed, and those defaults are rarely reviewed after installation. Settings also drift as patches, emergency fixes and vendor updates change them. Business pressure adds a further risk, because a deviation granted to keep an application working can become permanent without an approval record. Many device types, from servers and endpoints to network gear and cloud services, each need their own baseline, which multiplies the documentation.

The organization-defined parameter for this requirement is the configuration settings themselves. NIST does not supply values, so you must decide what the most restrictive mode means for your environment and write those values down. Confirm with your assessor how they expect the parameter to be evidenced, and confirm that your ODP values are the ones the contracting agency or the DoW has published, since current DFARS and CMMC guidance in the pillar context points to Revision 2 while a proposed FAR rule would tie Rev. 3 to published ODP values. The change from Rev. 2 is significant. NIST's change analysis traces 03.04.02 to Rev. 2 requirement 3.4.2 and classifies the change as significant, with more detail and foundational tasks. Under CMMC Level 2, the same practice is CM.L2-3.4.2 and carries 5 points under the scoring methodology in 32 CFR 170.24. The practice cannot be placed on a plan of action and milestones for Conditional status, so a gap here can block certification outright. Start by building baselines for your highest-risk system types and a deviation log, then ask your assessor which evidence they will sample first.

Which systems and teams 03.04.02 covers in your CUI environment

03.04.02 applies to every system that stores, processes or transmits CUI, and the hardening work lands on whoever owns each component. Decide early whether the CUI enclave or the wider enterprise carries the baseline, because that choice sets how many systems and owners you must document and assess. Whatever you decide must match the boundary in your system security plan.

CUI-processing servers and endpoints

Every server and workstation that touches CUI needs a documented configuration baseline, such as a hardened operating system build with defined services, audit settings and local security policy. Check that the baseline is applied at build time and that drift is detected afterward. Assessors will ask for the baseline document and for proof that a sample of machines matches it. Include shared engineering workstations and jump hosts, which are often missed.

Cloud workloads and images

Cloud instances, container images and infrastructure templates create configuration settings in code, so the hardened state must be defined in the image or template rather than set by hand after launch. Confirm which account, subscription or project holds CUI workloads and that its guardrails match the baseline. Record which settings the provider defaults to and which you override. Review drift on running instances as well as on new deployments.

Network and security devices

Firewalls, routers, switches and the monitoring tools that protect the CUI boundary have settings that define what traffic is permitted. Document the restrictive mode you chose for each device, including management-plane access, logging and administrative protocols. Changes to these devices also feed the change control process, so record where baseline settings and approved exceptions live. Confirm that vendor default credentials and services are removed.

Identity and collaboration platforms

Directory services, single sign-on, email, file sharing and collaboration tools decide who can reach CUI and how it moves, so their settings are part of 03.04.02 even when a cloud vendor operates them. List each tenant setting that governs CUI access, sharing and external guests, and document the restrictive value you selected. Confirm with the vendor which settings are tenant-configurable and which are fixed, since the answer changes what you can document as implemented.

Owners of each configuration

A baseline with no named owner decays quickly. Assign an accountable owner for each system class, usually the platform or infrastructure team, and a separate approver for deviations, often the information security function. Interview the people named in the plan, because assessors interview personnel with security configuration management responsibilities. Confirm that each owner can explain the settings they run and where the approved exceptions are recorded.

Enclave or enterprise baseline

Scoping the CUI enclave limits the number of systems that must meet the restrictive baseline, but the enclave boundary must match the system security plan and the connections that cross it. Applying the baseline enterprise-wide raises the workload but removes the need to prove separation for configuration purposes. Make the decision in writing, then confirm that every system in the enclave and every connected system is listed. Ask your assessor how they will test the boundary before you commit.

Who sets the restrictive values and who approves a deviation

The organization-defined parameter for 03.04.02 is the configuration settings that reflect the most restrictive mode consistent with operations, and NIST does not assign those values. Unless the federal agency that holds the contract or agreement specifies them, the nonfederal organization must define the settings itself, document them in its configuration baseline and implement them on every in-scope system. Start by asking the contracting officer or prime whether values have been published. Then write the settings down per platform type (servers, endpoints, cloud accounts, network devices), name the owner of each set, and record who signed off. A missing ODP value leaves the requirement incomplete, so an unanswered question here is an assessment finding, not a paperwork gap.

The proposed FAR overhaul would require contractors handling CUI to use ODP values published by the DoW CIO, and the DFARS route currently in use names Revision 2 explicitly. Check the contract, the current class deviation and the latest rule status before you write values, because a value set now may be replaced by a published one later. Confirm which version of the standard the contract cites and whether the ODP values are final. Keep a dated record of the version you assessed against so the scope is clear at the time of assessment.

Every deviation from a documented setting needs a record that a third party can follow. Capture the setting and system affected, the business reason, the risk the deviation creates, the compensating control and how it is tested, the named owner of the system, the approver with authority to accept the risk, and a review date. Tie each record to the change ticket that introduced the deviation so the approval history can be traced. Approval should sit outside the team that runs the system, and expired or unreviewed deviations should be flagged automatically. Fleet policies and Wazuh Security Configuration Assessment results can show whether a deviation is still in effect or has drifted, which gives assessors the evidence they will ask for.

How an assessor tests 03.04.02 under SP 800-171A Rev. 3

This table maps each assessment angle in SP 800-171A Rev. 3 for 03.04.02 to the test method, what the assessor asks for, the evidence that passes and the findings assessors commonly raise. Read it as a preparation checklist: each row shows what to have ready before the assessor arrives, and the main takeaway is that the examine, interview and test angles must agree with one another.

Assessment angle	Test method	What the assessor asks for	Evidence that passes	Common findings
Determination statements on defined settings and the most restrictive mode	Examine	Documented configuration settings for each system in scope and the rationale for choosing the most restrictive mode consistent with operations	Hardening baseline per system type, mapped to the organization-defined configuration settings, with dated approval	Settings documented in general terms with no per-system values or no link to operational need
Determination statement on implementing the settings	Test	Evidence that the documented settings are applied on in-scope systems	Configuration scan or export showing actual values matching the documented baseline on sampled systems	Documented baseline differs from what runs on production hosts
Determination statement on identifying deviations	Examine	A deviation register listing each departure from the settings, its justification and who approved it	Deviation records with business reason, compensating measures, approver and review date	Deviations exist in practice but are undocumented or approved informally
Determination statement on documenting deviations	Examine	Proof that each deviation is recorded and kept current	Register entries linked to the affected system and reviewed at a defined frequency	Register is out of date or missing systems that were changed for troubleshooting
Determination statement on approving deviations	Interview	Who approves deviations and whether the approval followed the defined process	Named approvers with authority, signed or recorded approvals predating the change	Approval given after the change was already made, or by someone without authority
ODP check: configuration settings value is defined	Examine	The organization-defined value for the settings, stated in policy or the plan	Written definition of the settings standard that the organization assigned to the parameter	Parameter left as a placeholder or defined only as the vendor default
Examine objects: configuration management policy and procedures	Examine	Policy and procedures covering configuration settings and their review	Approved policy with owner, review date and a procedure that names the steps and roles	Procedure exists but does not match what teams actually do
Examine objects: procedures for system configuration settings and the configuration management plan	Examine	Procedures for setting, verifying and deviating from configuration, and the plan that governs them	Plan that names the configuration baseline, tools, owners and the deviation process	Plan is generic and reused across systems with no system-specific settings
Examine objects: system design documentation	Examine	Design records showing how the system is configured and where settings are enforced	Architecture and build records that reference the hardening baseline and enforcement points	Design documents older than the current system state
Interview objects: personnel with configuration management and information security responsibilities	Interview	Whether these staff can explain the settings, deviation approvals and how drift is detected	Consistent answers across administrators, security staff and approvers that match the written records	Staff describe different settings or cannot name who approves deviations
Test objects: processes for managing configuration settings	Test	A demonstration of how settings are created, changed, checked and reverted	Walkthrough of a real change showing baseline check, approval and post-change verification	Process runs only for some systems or depends on one person
Test objects: mechanisms that implement, monitor or control system configuration settings	Test	The tools that enforce or report settings, and proof they run on in-scope systems	Configuration management or scanning tool output, such as Wazuh Security Configuration Assessment or Fleet policy results, with alert or ticket trails	Tool is installed but not monitored, or its policies do not reflect the documented baseline

Implementing 03.04.02 in the order an assessor will follow it

This sequence moves from deciding what the settings should be, to proving the systems match them, to controlling exceptions over time. Each step produces an artifact that an assessor can examine, interview staff about, and test against the running system.

Define the ODP values and baseline source
The organization assigns the value for the one organization-defined parameter in 03.04.02, which is the configuration settings that reflect the most restrictive mode consistent with operational requirements. Security and platform owners choose a starting point, such as CIS-based benchmarks for each operating system and application, and record which settings are adopted, which are tightened, and which are relaxed for operations. The output is a signed baseline document approved by the people accountable for the system security plan. The step is done when every in-scope platform has a named baseline source and an owner.
Document a configuration standard per asset class
Translate the baseline into a configuration standard for each asset class, such as Windows servers, Linux hosts, network devices, cloud accounts and developer workstations. Each standard lists the setting, the required value, the reason it exists and the mechanism that enforces it. Keep the standards in version control so changes have an author and a date. The output is a set of versioned configuration standards. The step is done when an engineer could build a compliant asset from the standard alone and an assessor could trace each setting back to the signed baseline.
Apply the settings through configuration management
Implement the standards with automation such as configuration management tooling, golden images or infrastructure-as-code templates, so that settings are applied the same way every time rather than by hand. Confirm that the mechanism covers both new builds and existing systems, and that privileged accounts cannot bypass it without a logged change. The output is the configuration code, the image build records and a list of systems where each standard is applied. The step is done when a sample of systems shows the settings in place and the enforcement mechanism is documented.
Scan for configuration drift
Run scheduled compliance checks against the running systems to detect settings that have moved away from the standard. Open-source options include Wazuh Security Configuration Assessment, which uses YAML policies that can be extended with custom checks, and Fleet, which asks each device a yes or no question as an osquery policy and shows which devices pass or fail. Confirm each tool's current capabilities and supported platforms in your environment before relying on it. The output is a drift report that lists each failing system, setting and detected value. The step is done when the report runs on a defined schedule and its results are retained as evidence.
Run the deviation process with approval
When a system must run with a setting that differs from the baseline, the owner records the deviation in a deviation register with the setting, the affected systems, the operational reason, the compensating measures and an expiry or review point. An accountable approver, such as the system owner or security lead, approves or rejects it in writing before the change is made. Drift findings that are not in the register are treated as incidents to correct. The output is the deviation register and the signed approvals. The step is done when every difference found by the drift scan is either remediated or matched to an approved deviation.
Set a review cadence and record each review
Assign an owner and a review frequency to the baseline, the configuration standards, the drift scan policies and the deviation register, and make the frequency part of the system security plan. At each review, confirm that the settings still reflect the most restrictive mode consistent with current operations, retire deviations that have expired, and feed changes through the change control process. The output is a dated review record for each artifact. The step is done when an assessor can see at least one completed review cycle and the changes it produced.

Which evidence satisfies 03.04.02 and how to keep it current

An assessor testing 03.04.02 looks for written settings, proof that those settings are implemented and monitored, and a documented trail for every deviation. The cards below name each artifact and the routine that keeps it accurate between assessments, so the evidence reflects the system as it runs today rather than as it looked at the last review.

Configuration management policy and procedures

This is the written rule set that tells administrators how configuration settings are established, documented, implemented and deviated from. An assessor will examine it first and then check that the procedures match what engineers actually do. Keep it under version control, record the review owner and approval date on each revision, and schedule a review whenever the baseline or the monitoring tool changes. Confirm that the procedure names the people responsible for security configuration decisions.

Documented baseline settings with ODP values

03.04.02 has one organization-defined parameter: the settings must reflect the most restrictive mode consistent with operational requirements. Your baseline document should list each setting, the value chosen, and the operational reason it is the most restrictive workable option. Because NIST does not assign values, the organization must define them, and an empty or vague ODP fails the determination statement that checks it is defined. Store the baseline as code where possible and export a dated copy at each approved change.

Configuration management plan

The plan describes who owns the configuration settings, which tools enforce them, how deviations are requested and how often the baseline is reviewed. Assessors use it as the bridge between the policy and the system in operation. Keep the roles current when staff change, and tie the plan to the system security plan so the two documents describe the same boundary and components. Review it on a fixed cycle and record each review in the document history.

System design documentation

Design documents show where configuration settings are applied across servers, endpoints, cloud accounts and network devices, and which mechanisms enforce them. An assessor compares these diagrams with the live environment to confirm that no component sits outside the baseline. Update the diagrams whenever a new service, subnet or image is introduced, and keep a dated diagram set alongside each baseline version so earlier states can be reconstructed.

Compliance scan reports showing current settings

Scan output is the test evidence that settings are actually in place. Wazuh Security Configuration Assessment checks monitored endpoints against YAML policies, mostly based on CIS benchmarks, and can be extended with custom policies for your own baseline. Fleet policies are yes or no osquery checks, and its policies page shows which devices pass or fail each one. Schedule exports of these results on a fixed cadence, retain them with the baseline version they tested, and investigate any failing device before the next review.

Deviation register with approvals

Every setting that departs from the baseline needs a recorded reason, a risk statement, an approver and a compensating measure. Assessors check that deviations are identified, documented and approved, and that the register matches what the scans report. Give each entry a review date and an expiry condition, and reconcile the register against scan exceptions every review cycle. An unlisted failing setting is a finding, so treat the register as the single source for exceptions.

Records of baseline reviews

Review records show that the baseline and its deviations were examined at a defined frequency and after significant changes. Keep minutes or tickets that name the reviewer, the date, the settings examined, the changes approved and the deviations closed or renewed. Link each review to the change records under the configuration change control process so an assessor can trace a setting from request to approval to scan result.

How Wazuh and Fleet produce configuration evidence

Configuration settings under 03.04.02 need two kinds of proof: that the settings were defined and approved, and that the systems actually run them. The two open-source tools below cover different parts of that proof, and each card names what the assessor will ask to see from it.

Wazuh security configuration assessment

Wazuh Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies. Most shipped policies are based on CIS benchmarks, and custom policies can be added for settings your organization defines. The checks cover files, directories, registry keys and running processes, and each failed check comes with a remediation recommendation. Before relying on it as evidence, map each policy to your own ODP value for the most restrictive settings consistent with operations, because a shipped benchmark is not the same as your documented baseline. Wazuh is licensed under GPL-2.0-only, so confirm that this license works with how you distribute or modify it.

Fleet policy pass and fail results

Fleet policies are yes or no questions asked of devices as osquery queries, such as whether disk encryption is on or a prohibited service is absent. The policies page shows which devices in each fleet pass or fail each policy, which gives you a dated, device-level view of whether approved settings are in place. Use it to show the deviation process in action: a failing device should either be remediated or appear in your approved deviation record. Fleet is MIT licensed. Confirm that the osquery tables you need exist on each operating system in your estate before you promise coverage.

Self-hosting and coverage checks

Both tools can run inside your own cloud accounts, data centers or air-gapped networks, so the configuration data stays under your control. Coverage is the open question. Confirm which operating systems, server images, network devices and cloud services each tool can assess before you claim that a setting is monitored. Where a platform is outside coverage, record that gap in the assessment and the plan of action. DeployOpen can help configure and document these checks, but the organization owns its settings, and an independent assessor decides whether the evidence is sufficient.

What meeting 03.04.02 costs in money and effort

This table breaks the cost of meeting 03.04.02 into its components, showing who is paid for each, whether it is one-time or recurring, what pushes it up and how to contain it. No figures are given because none are supplied for this requirement, so use the columns to build the questions you put to a quote. The main takeaway is that open-source tooling mainly removes license spend, while the engineering, deviation and evidence work stays with your organization and any partner you engage.

Cost component	One-time or recurring	What drives it up and how to keep it down
Tooling and licenses	Recurring for commercial tools, one-time setup for self-hosted	Self-hosted open-source tools such as Wazuh (GPL-2.0-only) and Fleet (MIT) remove license fees, but you still pay for hosting, storage, administration and upgrades. Ask the quote to separate license lines from infrastructure and staff time.
Engineering time to write baselines and build policies	One-time, then revised with each platform change	Effort rises with the number of distinct system types and the number of ODP values you must set yourself. Start with a small set of hardened baselines for the most common endpoints and servers, then extend them.
Deviation process time	Recurring, driven by change volume	Each deviation from a setting needs identification, documentation and approval. Set a standard deviation request form, a named approver and a review date so exceptions do not accumulate without records.
Policy and procedure upkeep	Recurring, usually annual or on change	Procedures for configuration settings must match what runs in production. Tie reviews to change control (03.04.03) so updates happen when the baseline changes, not at audit time.
Evidence collection and upkeep	Recurring	Assessors examine policy, procedures, the configuration management plan and design documentation, then test the mechanisms that enforce settings. Automated compliance scans with exported results cut manual collection, but someone must review and archive them on a schedule.
Scanning and drift monitoring	Recurring	Continuous checks against the baseline produce the most convincing evidence but generate alerts that need triage. Scope the checks to the in-scope systems first, then widen. Confirm with the vendor which checks each tool performs in your environment.
External testing or review	Optional, usually recurring	An independent review of baseline configurations or a security test of the hardened build adds cost but can find gaps before an assessment. Ask for a fixed scope with named systems and a written deliverable.
Assessor or auditor time	Recurring per assessment cycle	Assessment effort grows with the number of in-scope systems, the number of deviations and how well the evidence is organized. Ask the assessor to state the methods and sample sizes they expect for 03.04.02 before work starts.
Implementation partner effort	One-time for build, optional retainer for upkeep	A partner prepares baselines, scanning, deviation workflows and evidence packs under a written scope. Ask the quote to list each deliverable, the systems covered and what the organization must supply, because internal review time is often the largest unplanned cost.

Who owns 03.04.02, what partners prepare, and what the assessor decides

Your organization owns the requirement. Under 03.04.02, the configuration settings must be established, documented, implemented and kept under the most restrictive mode consistent with operations, and any deviation must be identified and approved. The organization decides what the most restrictive mode means for its own environment, so it must assign the organization-defined parameter (ODP) values for this requirement. No partner can make those business decisions for you.

ODP values: Your security and system owners set the approved configuration settings for each system in the CUI boundary and record the reasoning behind them.
Deviation approval: Named approvers accept or reject each deviation, with a documented justification, compensating measures and a review date.
Policy sign-off: Leadership signs the configuration management policy and the procedures that describe how settings are applied and checked.
Operational follow-up: Your staff review scan results, decide on exceptions and keep the record current as systems change.
Assessor access: Your team answers interview questions and shows examine objects, such as the configuration management plan and system design documentation.

Before accepting a quote, confirm which of these decisions you will keep in-house and who holds signing authority for them.

Where 03.04.02 implementations usually fall short

Most 03.04.02 findings are not missing settings. They are settings that were never chosen deliberately, documented, checked or kept current. The six gaps below show where assessors usually find the distance between a written baseline and the systems that actually run.

Vendor defaults left in place

Operating systems, databases, network devices and SaaS admin consoles often ship with settings chosen for ease of setup, such as open management ports, permissive logging or unchanged default credentials. Under 03.04.02, the organization must choose settings that reflect the most restrictive mode consistent with operations. To close this gap, compare each component's shipped configuration against your documented settings and record the reason for every value you keep at its default.

Organization-defined values never written down

03.04.02 carries one organization-defined parameter, the configuration settings that reflect the most restrictive mode consistent with operations. NIST does not assign that value for you, so an assessor will look for the specific settings your organization chose, not a general statement that hardening is performed. Write each setting, its value, the system it applies to and the operational reason for it, then have the owner approve the document. Ask your implementation partner or assessor to confirm the wording meets the parameter definition before you rely on it.

Baselines not tied to scans

Many organizations have a hardening document that no tool reads. The baseline exists on paper while systems drift without anyone seeing it. Connect the written baseline to automated checks that run on a schedule and report pass or fail per device, so the document and the running state can be compared. Open-source options such as Wazuh Security Configuration Assessment use YAML policies, which can be extended with your own checks. Confirm which benchmarks and custom checks your platform version supports before you commit to a design.

Deviations approved verbally or without expiry

Some systems cannot run a setting because a legacy application or an operational need requires something else. The gap appears when that exception is agreed in a meeting, recorded nowhere, or approved indefinitely. 03.04.02 requires the organization to identify, document and approve each deviation. For every exception, record the affected system, the setting, the business reason, the compensating measure, the approver and a review date. Review deviations on a set cycle and remove those that no longer have a reason to exist.

Cloud and container images drifting from baseline

A hardened virtual machine image can be replaced by an unhardened one through a new launch, a rebuilt container or an infrastructure template that was never updated. Each new instance then starts outside the baseline, even though the original build passed review. Build golden images and container base images from the documented baseline, store them in a controlled registry, and scan running instances against the same settings. Ask your team which pipelines can create production instances and whether each one pulls from the approved image source.

Evidence that is a one-time export

A screenshot or a configuration export captured before an assessment shows the state on one day and nothing after it. Assessors testing 03.04.02 examine the procedures and test the mechanisms that control settings, so they expect evidence that the process runs continuously. Keep scan results, change records and deviation approvals as dated, retained records that cover the whole assessment period. Schedule a recurring export or report, and confirm with your assessor which evidence formats and time spans they will accept.

Questions buyers ask about 03.04.02 before hiring help

How much effort does 03.04.02 configuration settings take?

The effort depends less on the requirement's wording than on how many system types you run and how far your current settings are from a documented hardening baseline. The requirement asks you to establish, document and implement configuration settings that reflect the most restrictive mode consistent with operations, and to identify, document and approve every deviation. Effort rises with the number of distinct platforms (operating systems, cloud services, network devices, databases), the number of exceptions already in use, and whether settings are enforced by tooling or set by hand. Ask any partner to break a quote into baseline selection, per-platform hardening, deviation review, and evidence collection, so you can see which parts are fixed and which depend on what the assessment finds.

Can our own team meet 03.04.02 without outside help?

Yes, the organization owns its controls, and many teams with mature configuration management do this internally. The harder question is whether your staff have the time and the independence to produce the documentation and deviation records an assessor will examine. Outside help is most useful for preparing hardening baselines, setting up enforcement and scanning, and assembling evidence that matches the examine, interview and test methods in SP 800-171A Rev. 3. An implementation partner prepares these systems and records, but the organization remains accountable for the settings and the approvals.

What does our staff need to provide during the engagement?

Three groups of internal people usually determine how smoothly the work goes. System owners must confirm which settings are required for operations, because the most restrictive mode is defined relative to those needs. Approvers must have a named process for signing off deviations, and that process must exist before work begins. Engineers need administrative access to the systems in scope, plus read access to existing policies, the system security plan and any current configuration documentation. Ask the quote to list these roles and hours so that delays are visible early rather than discovered during testing.

How long does configuration settings work take?

No fixed duration applies to every environment, so treat any single number you see as unverified until a written scope confirms it. The pace is set by the number of systems in the boundary, how many platforms need their own baseline, how many legacy exceptions must be reviewed, and how quickly approvers respond. Change freezes, maintenance windows and the need to test hardening against production applications also add time. A fixed-scope agreement fixes deliverables and dates in writing before work starts, which lets you compare timelines across proposals on the same boundary.

Can open-source tools meet the 03.04.02 requirement?

Open-source tools can support the requirement, but they do not satisfy it on their own, because the requirement is about the organization's decisions and records as well as the settings. Wazuh's Security Configuration Assessment, licensed under GPL-2.0-only, scans monitored endpoints for misconfigurations using YAML policies that are mostly based on CIS benchmarks and can be extended with custom policies. Fleet, licensed under MIT, runs osquery-based yes or no policy checks across devices and shows which devices pass or fail each policy. Confirm with each vendor which platforms and checks your environment needs, and map each tool's output to your documented baseline and deviation register.

Can a partner issue our 03.04.02 assessment or SPRS score?

No. A partner can prepare the systems, baselines, deviation process and evidence, but it cannot issue an assessment, a score or a certificate. Scores and assessment results come from the assessing body that the contract or program requires, such as the government assessor for Basic, Medium or High assessments, and the organization is responsible for reporting its own score accurately. Before you engage anyone, confirm with your contracting officer which assessment applies, since the applicable revision and assessment type are set by the contract and current DoD guidance, not by your consultant.

How DeployOpen prepares configuration evidence for 03.04.02

DeployOpen implements and documents the configuration settings that 03.04.02 Configuration settings asks for, inside the client's own infrastructure. We prepare the settings, the deviation records and the evidence an assessor will examine, while the organization keeps ownership of its controls and any independent assessment is performed by an external assessor.

How we scope

Agree in writing which systems, operating systems and device types fall under the 03.04.02 baseline
Confirm which organization-defined configuration settings the client will adopt as its most restrictive operational values
List the deviation approval roles and the review frequency the client expects to document
Engagements are fixed-scope, with deliverables and timelines agreed before any hardening work starts

How we build

Translate agreed settings into hardening baselines and record the operational reason for each setting
Configure monitoring of settings with Wazuh Security Configuration Assessment, using YAML policies extended to the client's standards
Use Fleet policies written as osquery questions to show which devices pass or fail each setting
Test that the configuration mechanisms actually enforce the documented settings on representative systems

How we hand over

Deliver the configuration management documentation, baseline records and settings inventory for assessor examination
Provide a deviation register showing each exception, its justification, its approver and its review date
Walk the client's staff through interview-ready explanations of how settings are set, monitored and changed
Confirm the client, not DeployOpen, holds the final responsibility for attesting to the control

How we support

Ongoing support, upgrades and continuous testing of the configuration controls are available as a retainer
Re-verify settings after platform upgrades and after changes recorded under configuration change control
Refresh the deviation register and evidence set when the scope or the assessment requirements change
Ask for the retainer scope in writing so frequencies and responsibilities are clear before work starts