03.04.01 Baseline configuration: requirements and evidence

What NIST SP 800-171 03.04.01 baseline configuration requires

Requirement 03.04.01 asks you to develop and maintain a current baseline configuration of the system under configuration control, and to review and update it at an organization-defined frequency and whenever system components are installed or modified. If a contract or DoD clause now asks for a documented baseline, the baseline is the reference point against which every other configuration control is measured. The risk it addresses is undocumented drift: over time, servers, workstations, network devices and cloud resources accumulate changes that nobody recorded, so the environment no longer matches any known-good state. A CUI enclave that cannot say what it was supposed to look like cannot show that its security settings are still in place.

The difficulty is that the baseline has to describe the real system, not an idealized design document. In practice that means identifying the components in scope, recording their operating systems, software versions, network settings and security configurations, and tying each entry to an owner and a record of approval. The review frequency is an organization-defined parameter (ODP) with one value to set, and NIST does not assign it for you. If a federal agency has not specified a value, you must choose one, document it in your system security plan and be able to defend it to an assessor. Confirm with the contracting agency whether it has set a value before you pick your own.

For scoring, NIST's change analysis traces this requirement to Rev. 2 requirement 3.4.1 and classifies the change as minor, so existing Rev. 2 baselines carry over with limited rework. CMMC Level 2, which still uses Rev. 2, assesses the practice as CM.L2-3.4.1 and gives it 5 points under the 32 CFR 170.24 scoring methodology. Under 32 CFR 170.21, that practice cannot be placed on a plan of action and milestones to reach Conditional status, so an missing or stale baseline must be fixed before assessment rather than documented as future work. Treat the baseline as a prerequisite for the configuration settings, change control and inventory requirements that depend on it.

Which systems, teams and third parties a 03.04.01 baseline must cover

A baseline configuration only protects CUI if it describes every component that stores, processes or transmits CUI, plus the shared services those components rely on. The cards below name the scoping decisions that change the work, and the organization owns each of them. Settle them in writing before the baseline is built, because the scope determines what must be reviewed and how often.

Systems that handle CUI

Start with the systems that store, process or transmit CUI, including servers, workstations, databases, file shares and collaboration tools where CUI is used. Each one needs its own baseline entry covering operating system, installed software, services and security settings. Check that the list matches the system security plan and the CUI data flows, not only the systems the IT team manages day to day. Ask who can add a system to the list and how that change is recorded.

Dependent components and supporting assets

Many CUI systems depend on components that never see CUI directly, such as domain controllers, DNS, network firewalls, load balancers and backup servers. A change to any of them can weaken the protection of the CUI system, so decide whether each one is in the baseline or is documented as an external dependency. Record the decision and the reason. Auditors commonly ask why a dependency was left out.

Enclave boundary placement

The boundary of the CUI enclave decides which systems must be baselined at all. Document where the boundary sits, which connections cross it, and which systems on the far side are treated as outside the scope. A system that is inside the boundary for one purpose and outside for another needs a stated rule, not an informal understanding. Confirm the boundary with the contracting authority or the assessor before the baseline is finalized.

Shared identity and logging infrastructure

Identity providers, directory services, logging collectors and monitoring agents often serve both CUI and non-CUI systems. Decide whether a shared service is inside the boundary. If it is, its configuration must appear in the baseline and its changes must go through change control. If it is outside, document how its security is assured and what protections the CUI systems rely on. Confirm the decision with the team that owns the service.

Cloud and managed-service components

A shared hypervisor, a cloud tenant or a SaaS application may host CUI without the organization controlling the underlying platform. Decide whether the platform layer, the tenant configuration or only the customer-managed settings belong in the baseline. Reviewers will expect the organization to show what it configured and what the provider configures. Confirm with the provider which settings the customer can see, export and change, since that determines what the baseline can honestly claim.

Third parties with configuration control

Managed service providers, integrators and maintenance vendors may change configurations on CUI systems. Each one with the ability to alter settings is a scoping question, because their changes must be reflected in the baseline and approved under the organization's process. Write down who holds administrative access, which changes they may make, and how the organization learns of them. Review the contract terms that govern these changes, and confirm them with legal and procurement.

How an assessor tests the baseline configuration requirement

This table maps the SP 800-171A Rev. 3 assessment procedure for 03.04.01 to the examine, interview and test methods, the objects an assessor looks at, the evidence to have ready and the findings auditors commonly write. Read each row as a question the assessor will ask and the answer your records must support. The assessor issues the findings; the organization owns the baseline, the review frequency and the proof that both are followed.

Method and objects	What the assessor examines, interviews or tests	Evidence to have ready	Common finding
Examine: configuration management policy and procedures	Whether a documented policy and procedures cover developing, maintaining and reviewing baseline configurations under configuration control	Approved configuration management policy with an owner, version and review date; procedure showing who updates the baseline	Policy exists but does not name the baseline review trigger or the owner
Examine: procedures for the baseline system configuration	Whether the procedure describes how the baseline is built, stored, approved and updated when components change	Baseline procedure, sample baseline documents, change tickets linked to baseline updates	Procedure is generic and does not match how the team actually updates the baseline
Examine: configuration management plan	Whether the plan defines the system under configuration control and the baseline scope	Configuration management plan with system boundary, component list and baseline ownership	Plan covers a different boundary than the system security plan
Examine: enterprise architecture	Whether the baseline matches the documented architecture and component relationships	Current architecture diagrams aligned with the baseline and the component inventory	Architecture diagrams are out of date and show components no longer in the baseline
Interview: personnel with configuration management responsibilities	Whether the people who maintain baselines know the current baseline, its review frequency and the trigger for updates	Named roles and responsibilities, training or onboarding records for those roles	Staff describe a review cadence that differs from the documented frequency
Interview: personnel with information security responsibilities	Whether security staff rely on the baseline for monitoring, scanning and incident work and know when it changes	Records showing security reviews of baseline changes and how scanners reference the baseline	Security team scans against an older baseline than the one in production
Test: processes for managing baseline configurations	Whether the organization runs the baseline process as documented, including review at the defined frequency and updates after installs or modifications	Review log with dates, approvals and the version of the baseline reviewed each time	Baseline review is overdue, or the baseline predates the last component change
Test: mechanisms supporting configuration control of the baseline	Whether tools enforce or detect drift from the baseline and whether the baseline is protected from unapproved edits	Tool configuration, access restrictions on baseline files, drift reports and change records	Baseline files are editable by anyone with general access and no drift check exists
Check: organization-defined parameter is defined	Whether the review frequency for the baseline is set to a specific value in the documentation	Documented review frequency in the policy or plan, with the approving authority named	Review frequency is described as periodic or as needed, with no defined interval

How to build and keep a 03.04.01 baseline in order

This sequence takes a system from an undefined boundary to a documented, approved and monitored baseline that is updated whenever components change. Each step ends with a record an assessor can examine, interview staff about and test.

Define the system boundary and configuration scope
Start by fixing which system the baseline describes and which components sit inside configuration control. Cover servers, endpoints, network devices, cloud workloads, operating systems and the applications that store, process or transmit CUI, and tie the boundary to the system security plan so the two documents agree. Assign an owner for the configuration management function. The step is complete when the boundary statement and a scoped list of in-scope components are approved and stored with the configuration management plan. Assessors commonly ask to see that list first, because every later step depends on it.
Set and document the review frequency
03.04.01 has one organization-defined parameter: how often the baseline is reviewed and updated. Your organization must assign that value, because NIST does not set it for you, and an agency that has not specified it leaves the assignment to you. Choose a frequency that you can meet, write it into the configuration management procedures, and name the role responsible for the review. Confirm the value with the contracting agency or your assessor before you rely on it. The output is a documented ODP value with an owner and an approval record, which the assessor checks as the defined-parameter statement.
Capture the baseline and approve it under change control
Record the baseline for each in-scope component: hardware, operating system and build version, installed software and versions, security-relevant configuration settings, and enabled network services and listening ports. Collect the data from authoritative sources such as configuration exports, images and asset records rather than from memory. Route the completed baseline through your change control process so a named approver accepts it. The output is an approved baseline record with a version number, capture date, approver and a link to each component it covers. Keep prior versions so you can show how the baseline changed over time.
Bring the baseline under continuous monitoring
A baseline only helps if deviations are noticed. Compare live systems against the approved baseline using a configuration assessment tool, an endpoint query platform or a host inventory feed, and decide which differences count as drift. Open-source options such as Wazuh Security Configuration Assessment can check files, registry keys and running processes against YAML policies, and Fleet policies can show which devices pass or fail a yes or no check. Confirm that a given tool can compare against your own baseline values before you commit to it. Done means drift alerts route to a named owner and each finding is closed or approved as a deviation.
Review the baseline on schedule and record the results
Run the review at the frequency you set in step two. Compare the current baseline with the approved version, check the inventory of in-scope components, and confirm that the settings still match the documented intent. Record who performed the review, the date, the findings and any updates approved. Where a review finds no change, record that outcome too, because the assessor will look for evidence that the review happened as defined. Interview the people responsible for the review to confirm they know their role.
Define the update trigger for installs and modifications
Write down the events that require an immediate baseline update, including installing a new component, removing one, upgrading an operating system or application, and changing a security-relevant setting. Link each trigger to the change control workflow so a change request cannot close until its baseline update is approved. Test the trigger with a sample change and confirm the baseline record moves to a new version. The output is a procedure that names the trigger events, the approver for each, and a change record that shows the baseline was updated when the component changed.

Evidence that satisfies a 03.04.01 baseline and how to keep it current

An assessor testing 03.04.01 looks for a baseline that exists, is kept under configuration control, is reviewed on the frequency you defined, and changes when components change. The organization produces each artifact below and keeps it current between assessments, and the assessor decides whether the evidence passes.

Configuration management policy and procedures

This is the written rule set that says who owns the baseline, what counts as a system component, how baselines are created and approved, and how often they are reviewed. The assessor reads it first, so the review frequency you assign to the 03.04.01 organization-defined parameter must appear here with a value, not a placeholder. Check that the document names the roles interviewed later and that its revision date and owner are current. Review it on a set cycle and record each revision.

Approved baseline records with version history

These are the baseline configuration documents themselves, with a version number, approval record, approver and effective date for each release. Store them in a controlled repository with restricted write access, and keep superseded versions rather than overwriting them. Between audits, link each baseline version to the change ticket that approved it so the history can be traced from the current baseline back to its origin. Confirm that the stored baseline matches what the system actually runs.

Configuration management plan and component scope

The plan describes how baselines fit into the wider configuration management process, which system components are under configuration control, and where the authoritative inventory lives. Assessors compare the plan's scope with the systems that handle CUI, so an omitted device class is a common finding. Keep the plan aligned with the enterprise architecture and the system security plan, and update it whenever the boundary changes. Record the date of each review and the name of the reviewer.

Review schedule and records of each review

The defined review frequency only counts if reviews happen on that schedule. Keep a calendar or ticket series for each baseline with a dated record of each review, the reviewer, the findings and whether the baseline was confirmed or updated. A review that finds no change still needs a record. Between audits, reconcile the review log against the baseline version history so any gap in the schedule is visible before an assessor finds it.

Change records showing baseline updates

Every installation, removal or modification of a system component should lead to a baseline update or a documented decision that none is needed. Assessors sample change tickets and check that each one points to a baseline version and that the baseline was updated within the timeframe the policy sets. Require the baseline reference as a mandatory field in your change workflow, and review open changes that have no matching baseline version at each cycle.

Drift and compliance scan reports against the baseline

Scan output showing actual configuration compared with the approved baseline is strong evidence that the baseline is maintained, not just written. Tools such as Wazuh Security Configuration Assessment or Fleet policies can report deviations on endpoints. Keep dated scan reports, the rule set used, and the disposition of each failing check, whether it was fixed, accepted as a documented deviation or traced to a baseline update. Confirm that the scanned rule set matches the current approved baseline version.

What meeting the baseline configuration requirement costs

This table breaks down the cost components of keeping a current baseline configuration under configuration control, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. No dollar figures are supplied for these components, so the right-hand column tells you what to ask a partner or auditor to quote. The main takeaway is that the baseline is cheap to start but expensive to let drift, because the 5-point CMMC weighting means a gap here cannot be carried on a POA&M for Conditional status.

Cost component	One-time or recurring	What drives it up	How to keep it down
Tooling or licenses	Recurring for commercial tools, one-time setup	Number of endpoints and servers in scope, and the number of commercial scanning or compliance modules purchased	Use open-source options such as Wazuh, Fleet, GLPI and Zabbix, which carry no license fee; budget only for hosting, storage and staff time
Engineering time to capture and approve the baseline	One-time, then recurring for each change	Number of distinct system types, undocumented legacy builds, and how many approvers must sign off	Start with a small set of standard images, document them in a single configuration management plan, and reuse the same baseline across similar systems
Evidence upkeep and review cycles	Recurring	The review frequency you define as the 03.04.01 organization-defined parameter, the number of baselines, and manual evidence collection	Set a frequency you can actually meet, automate exports of configuration state into the evidence store, and keep one owner per baseline
Keeping the baseline current after changes	Recurring, tied to change volume	High change rates, emergency changes made outside the change process, and component installations that are not recorded	Route every installation and modification through change control, and reconcile the inventory against the baseline on a fixed schedule
External testing or review	Recurring, usually per assessment cycle	Scope size, number of systems sampled, and whether the reviewer must rebuild the baseline from scratch	Prepare a walkthrough of baseline versus live state before the reviewer arrives, and ask the reviewer what sample they expect
Auditor or assessor sampling	Recurring, set by the assessing body	Number of systems in the CUI boundary and the number of baseline changes in the review period	Ask the assessor to confirm sampling method in writing before fieldwork, and keep change records indexed by system
Cost of a gap on a POA&M	Potential one-time rework, plus delayed contract scoring	The 5-point weighting for CM.L2-3.4.1 under 32 CFR 170.24, and the rule in 32 CFR 170.21 that bars this requirement from a POA&M for Conditional status	Close the baseline before the assessment window, since a missing baseline cannot be deferred into a plan of action and milestones

Who does what: your team, an implementation partner and the auditor

Your organization owns the requirement. Under 03.04.01, the baseline configuration is a statement of what your system is supposed to look like, and only your organization can decide that. Your security and system owners approve the baseline, choose the review frequency that you must define as the organization-defined parameter, and accept responsibility when a deviation is found. Your team also keeps the evidence current after the project ends, which is where most baselines fail.

Baseline ownership: Name an accountable owner for each system's baseline and document who approves changes to it.
Review frequency ODP: Set and record the review and update frequency. If your contracting authority specifies a value, use it. If not, you must assign one and justify it.
Trigger events: Define which component installs, removals or modifications require a baseline update before they go live.
Ongoing evidence: Retain approved baselines, review records and change tickets in a location your assessor can reach.
Interview readiness: Make sure configuration management and security staff can explain the baseline and how it is maintained, since assessors interview them.

Before engaging any outside party, confirm internally who signs the baseline and who will answer assessor questions about it.

Where organizations fall short on baseline configuration and how to close it

What review frequency should a baseline configuration use under 03.04.01?

The organization must set the review frequency itself, because 03.04.01 contains an organization-defined parameter for it and NIST does not assign a value. Many organizations leave this blank in the system security plan, which makes the requirement impossible to assess cleanly, since the assessment includes a check that the parameter is defined. Pick a frequency that matches how fast the CUI environment changes, write it into the configuration management policy and the system security plan, and tie it to a recurring calendar task with a named owner. Ask your assessor or contracting officer whether a specific value is expected in the contract, since federal agencies may specify one.

Why does a baseline captured once go stale after changes?

A baseline captured at deployment and never refreshed stops describing the system after the first patch, new service, or firewall rule change. The requirement expects the baseline to be updated when components are installed or modified, so a snapshot from the original build will fail an interview or examination of the update process. The fix is to make baseline updates a required step in the change workflow: when a change is approved and implemented, the baseline record is revised and its version increments. Automated configuration collection, scheduled comparisons, and alerts on drift reduce how much depends on people remembering to do this.

How do you stop a baseline document from drifting away from the live system?

Many baselines exist only as diagrams or spreadsheets maintained by hand, and they quietly diverge from what runs on the hosts. Assessors who sample a system will compare the documented baseline with the actual configuration, so a mismatch is a finding even when the document looks thorough. Treat the baseline as data that is generated from or checked against the running system. Agent-based tools can report installed packages, operating system details, and file or registry settings. Wazuh's Security Configuration Assessment, for example, checks files, directories, registry keys and running processes against YAML policies, which can be compared with the approved baseline. Confirm exactly which checks your platform supports before relying on them as evidence.

How should change tickets link to baseline versions?

A change ticket that says a server was patched but does not name the baseline version it changed leaves no traceable path from change to baseline. Auditors testing change control and baseline maintenance look for that path, so each approved change should record the affected system, the baseline version before the change, and the version after it. Store baseline versions in a repository or configuration management database with immutable history, and require the ticket to reference the new version before closure. Where tools allow it, GLPI can hold asset records for computers, software and network equipment that the change record can point to, which helps show what each change touched.

Does the baseline cover cloud and SaaS components inside the CUI boundary?

Baselines often list on-premises servers and workstations while omitting cloud accounts, managed databases, identity configurations, and SaaS tenants that store or process CUI. The system security plan defines the boundary, and the baseline has to cover every component inside it, including services the organization does not operate directly. Start from the boundary diagram and the data flow for CUI, then record the configuration settings that matter for each cloud resource, such as storage access policies, logging settings, and network rules. Where a provider is responsible for a setting, document that responsibility and the evidence you can obtain from the provider, such as their attestation reports, instead of leaving the component out.

Can an organization build its own baseline, or does it need outside help?

An organization can maintain its own baseline if it has staff who understand the platforms, a configuration management tool, and time to keep records current. Outside help is most often used to set up the collection and comparison tooling, write the baseline and its review procedure, and prepare evidence for the assessment. DeployOpen, as an implementation partner, can plan and implement these pieces in your own cloud accounts or data centers, but the organization owns the configuration decisions and the policy. Only an independent assessor can judge whether the baseline meets the requirement. Ask any partner for a written scope that lists the platforms, the deliverables, and what remains with your team after handover.

What does it cost to build and maintain a baseline configuration program?

The main cost components are staff time to define the baseline, tooling to collect and compare configurations, and the ongoing effort of reviewing and updating records after every change. One-time costs include the initial baseline build and the setup of collection and drift checks. Recurring costs include scheduled reviews, change-record upkeep, and assessment preparation. Costs rise with the number of platforms, the number of components in the CUI boundary, and how often the environment changes. Open-source tooling can reduce license spend, but integration and maintenance still take people. When requesting a quote, ask for the platforms in scope, the number of components, the review frequency your policy will set, and who maintains the tooling after delivery. No price is given here because the effort depends on the environment.

Open-source tools that produce baseline evidence and how to use them

A baseline configuration is only as good as the evidence that the live systems match it and that the inventory of those systems is current. The four tools below each cover a different part of that evidence: configuration checks on endpoints, device-level policy results, the hardware and software record, and host inventory fields. Each needs to be confirmed against your own environment and against what your assessor expects.

Wazuh configuration assessment

Wazuh's Security Configuration Assessment (GPL-2.0-only) scans monitored endpoints against YAML policies. Most policies are based on CIS benchmarks, and you can add custom policies for settings your approved baseline requires. Checks cover files, directories, registry keys and running processes, and each failed check includes a remediation recommendation. Use the scan results as evidence that endpoints match the documented baseline, and confirm that your custom policies are traced to the baseline document, since the scans only test what the policies define.

Fleet policy pass and fail records

Fleet (MIT) expresses each check as a yes or no osquery policy asked of enrolled devices. Its policies page shows which devices in each fleet pass or fail each policy, which gives a per-device view of baseline drift. Write policies that map one-to-one to baseline settings so a failing result points to a specific configuration item. Export or retain the pass and fail history on a schedule that matches your review frequency, and confirm that the stored history meets your assessor's expectations.

GLPI component inventory

GLPI's Assets module (GPL-3.0-or-later) records computers, software, network equipment and other components, either entered by hand or pushed automatically by the GLPI Agent through native inventory, which has been built into GLPI since version 10. The inventory answers which components the baseline must cover. Check that the agent reports from every segment in scope, that manual entries are reviewed, and that removed items are retired from the record. The inventory supports the baseline review because a baseline that omits a component is incomplete.

Zabbix host inventory fields

Zabbix host inventory (AGPL-3.0-only) stores fields such as device type, serial number, location and responsible person. Fields can be entered manually or filled automatically from agent items covering hardware, operating system and installed packages. Assign a responsible person to every host so that baseline reviews and change approvals have a named owner. Populate the location and serial number fields for each host in scope, and confirm that automatically filled fields are refreshed after hardware or software changes.

Common questions about 03.04.01 baseline configuration

How much effort does a baseline configuration take for a typical enclave?

The effort depends on how many distinct component types sit inside the boundary, not on the requirement text itself. A baseline must describe every operating system build, server role, endpoint image, network device and cloud service that stores, processes or transmits CUI, so each added platform type adds a documented baseline to write and keep current. Drivers include the number of images in use, how much configuration is inherited from a cloud provider, how many vendors supply components, and how often the environment changes. A small, uniform enclave with one endpoint image and a few servers needs far less work than a mixed estate with legacy systems. Ask any provider for a scope that lists the component classes covered and the baseline artifacts each one produces before you accept a quote.

Can we build the baseline configuration ourselves?

Yes. Nothing in SP 800-171 requires an outside firm to write baselines, and many organizations maintain them with internal staff. The organization owns the baseline, its approval and its review cycle. The harder questions are whether your team has time to document each component, whether anyone holds the authority to approve baseline changes, and whether the baseline stays current as systems change. A common split is for internal staff to own the policy and approval workflow while an implementation partner builds the baseline documents, automates the checks and produces the evidence. DeployOpen prepares systems and evidence for assessments, but it does not issue assessment results. Decide the split in the written scope so each deliverable has a named owner.

How long does it take to establish a baseline configuration?

No general duration applies, because the timeline follows from the components in scope, the state of current documentation and how many approvals the organization requires. The fastest way to get a reliable answer is a written scope that lists the systems, the deliverables for each and the responsible person for approval and review. Ask the provider to show which items depend on your staff, such as access to change records, system owners' availability and sign-off meetings, since those dependencies often set the pace more than the technical work does. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and a quote follows from that written scope.

What skills and access does the team need for this work?

The work needs people who understand the systems, people who can approve changes, and people who can collect evidence. In practice that means system administrators who know each platform's configuration, a security lead who can judge which settings are the most restrictive consistent with operations, and a change manager who owns the record of approved baselines. The implementer also needs read access to configuration state, administrative access to build or test environments, and a way to record deviations. Before engagement starts, confirm who will sign off on each baseline and who will answer questions during the review. Missing approvers are a frequent cause of delay.

Does our organization have to set the ODP value for baseline review frequency?

Yes, in most cases. 03.04.01 has one organization-defined parameter, the frequency at which the baseline is reviewed and updated. NIST does not assign that value, and if the federal agency that holds your contract does not specify it, the nonfederal organization must set it to complete the requirement. Choose a frequency you can actually meet, document it in the system security plan or configuration management plan, and make sure the assessor can see that the value is defined. A rule that is defined but never followed will not satisfy an assessment, so set the interval after you have confirmed the review workload and the staff who will perform it. Ask your contracting officer whether a value has been specified for your contract.

Does the baseline requirement still apply under Rev. 2 for CMMC contracts?

Yes. NIST withdrew SP 800-171 Rev. 2 on 14 May 2024, but 32 CFR 170.14(c)(3) makes the CMMC Level 2 requirements identical to Rev. 2, so contractors in CMMC scope are assessed against the 110 Rev. 2 requirements. The Rev. 2 counterpart of 03.04.01 is 3.4.1, which CMMC Level 2 assesses as CM.L2-3.4.1. Under the 32 CFR 170.24 scoring methodology it carries 5 points, and 32 CFR 170.21 does not allow it on a plan of action and milestones for Conditional status. Because contract language and DoD class deviations change, confirm the version named in your contract and any current DoD guidance before you plan the work.

Who issues the assessment result for the baseline requirement?

Only an independent assessor or the government body that runs the assessment issues the result. For DoD contracts, that means a DCMA DIBCAC assessment or a CMMC third-party assessor, depending on the program phase and contract. The organization owns its controls, and an implementation partner can prepare the baseline, the change records and the evidence, but it cannot certify compliance or publish an assessment report. Ask any provider to name the evidence it will deliver and to confirm that the final determination belongs to the assessing body. Confirm the assessment path with your contracting officer because the rules for which body assesses which contract are still changing.

How DeployOpen works on this

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, including the baseline configuration records that 03.04.01 asks for. We prepare systems and evidence for your assessment, while your organization owns the control and an independent assessor or auditor reaches any conclusion about it.

How we scope

Confirm which system components fall under configuration control and which hold or process CUI.
Agree in writing who sets the review frequency, the organization-defined parameter for 03.04.01.
Identify the configuration management policy, plan and enterprise architecture documents that already exist.
List the interviewees responsible for configuration management and information security before work starts.

How we build

Document a baseline configuration for each in-scope platform, covering operating system, services and installed software.
Set up configuration checks with tools such as Wazuh Security Configuration Assessment or Fleet policies.
Connect inventory data from GLPI or Zabbix so baselines match the components actually deployed.
Test that baseline changes are triggered when components are installed or modified, and record the results.

How we hand over

Deliver the baseline documents, configuration check definitions and review records in a format your assessor can examine.
Provide a short walkthrough of how each baseline is updated and who approves changes to it.
Map each determination statement for 03.04.01 to the artifact that supports it, so gaps are visible to your team.
Transfer administrative ownership of the tools and documentation to your staff at the end of the agreed scope.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work closes.
Review baselines again when the defined review frequency comes due or a component changes.
Update check definitions when your platforms are upgraded or when the assessment guidance changes.
Confirm with your assessor which evidence they expect before the next assessment cycle begins.

03.04.01 Baseline configuration