PR.PS-01 Configuration management: requirements and evidence

What PR.PS-01 configuration management asks for in NIST CSF 2.0

If a customer, regulator or internal audit asks for PR.PS-01 evidence, the short answer is this: the outcome is that configuration management practices are set up and applied. In CSF 2.0 terms, the organization must define how systems are configured, apply that configuration consistently, and be able to show it. NIST describes three Implementation Examples under this Subcategory: establishing, testing, deploying and maintaining hardened baselines that provide only essential capabilities; reviewing default settings when installing or upgrading software; and monitoring software for deviations from approved baselines. Each one produces something an assessor can examine, such as a written baseline, a record of the default-setting review, and a deviation report.

This is hard for three reasons. Baselines drift, because patches, emergency changes and vendor updates alter settings after the baseline was written. Ownership is split across platform engineering, application teams, network staff and cloud administrators, so no single person sees the full approved state. And many teams cannot say what the approved state is for a given asset, which makes deviation monitoring meaningless. A useful first step is to pick one asset class, such as Linux servers or managed laptops, and confirm who owns its baseline, where that baseline is written down, and how the last deviation was detected and closed.

CSF 2.0 is voluntary, and NIST does not certify organizations, products or service providers against it. No one can issue a PR.PS-01 certificate, so the organization owns both the outcome and the evidence that proves it. An implementation partner can help build baselines, configure monitoring and assemble records, but the organization must approve its own baselines and decide what counts as an acceptable deviation. Any independent assessment is performed by an assessor the organization selects and pays for, and that assessor's report, not a NIST document, is what the reader will ultimately rely on. Confirm with the requesting party which evidence format and assessment method they expect before you start collecting material.

Which systems and teams fall under PR.PS-01 scope

PR.PS-01 asks that configuration management is set up and applied, so the first job is deciding which assets carry baselines and who writes them. The cards below cover the scoping decisions that change the effort most, from server and endpoint estates to cloud accounts, containers, network devices and third-party managed systems.

Servers and virtual machines

Start with the server estate because it usually carries the most privileged services. Decide whether baselines apply per operating system image, per role (web, database, directory) or per environment, and record which images are golden masters. For PR.PS-01, the check is whether each server class has a documented hardened baseline that provides only the capabilities its role needs, and whether a monitored deviation from that baseline produces a ticket. Ask which hosts sit outside the inventory, since an unlisted server cannot be measured against any baseline.

Employee and fleet endpoints

Decide whether laptops and workstations get the same baseline as servers or a separate profile for user-facing settings such as local administrator rights, browser policy and disk encryption. Endpoints roam, sleep and go offline, so a scope decision must also say how a device that has not checked in is treated. Review default settings at install time, because a freshly imaged laptop is where unreviewed defaults most often survive into production.

Cloud accounts and subscriptions

Cloud configuration is set through consoles, APIs and infrastructure code, so a baseline must cover each account, subscription or project and each managed service inside it. Decide whether the security team owns guardrails at the organization level while platform teams own account-level settings. Confirm that infrastructure-as-code repositories are in scope, because a drift between code and live resources is the deviation that baseline monitoring is meant to catch.

Containers and orchestration

Container images and the clusters that run them are configured in layers: base image, runtime, orchestrator and workload manifests. Decide which layer each baseline governs and who may change it. A common scoping error is treating the image as the only asset, which leaves the cluster admission settings and namespace defaults unmeasured. Confirm whether rebuilt containers are replaced rather than patched in place, since that determines where a deviation is detected.

Network devices and security appliances

Switches, routers, firewalls and load balancers often run vendor-default services and management interfaces. Decide whether they fall under the same baseline process as hosts or under a network team's separate standard, and make sure the chosen owner signs off on each device class. Check that management planes, SNMP and remote administration are named explicitly, because these are the settings most often left at vendor defaults during installation or upgrade.

Third-party managed systems

Systems run by a managed service provider or a SaaS vendor may not expose their configuration to you. Decide whether each one is in scope, and if it is excluded, record the exclusion and the contract or assurance evidence that covers it instead. Where you do bring a provider's system in scope, write the baseline responsibilities into the contract, including who applies changes and who receives deviation reports. Ask for the provider's own configuration evidence before accepting that a managed system is covered.

How an assessor tests PR.PS-01 configuration management

This table compares each part of the PR.PS-01 outcome with the test an independent assessor would run, the evidence requested and the findings that commonly appear. Read it as a checklist of what to have ready before an assessment, not as a result: the assessor, not DeployOpen, decides whether the outcome is met.

Area	What the assessor tests	Evidence requested	Common findings
Approved baselines	Whether hardened baselines exist for each system type and provide only essential capabilities	Approved baseline documents with version, owner and approval date for each asset class	Baselines undocumented, or written once and never updated for current systems
Sample systems	A sample of production, staging and endpoint systems drawn from the asset inventory, checked against the baseline that applies to each	Asset inventory extract, sample list and the baseline mapped to each sampled system	Sampled systems missing from the inventory or mapped to a generic baseline that does not fit their role
Running settings	Current running configuration compared with the approved baseline, using scans or direct inspection	Scan or configuration export with timestamp, plus the exception register for any differences	Settings that differ from baseline with no recorded exception or risk acceptance
Default settings at install or upgrade	How default accounts, services and options were reviewed when software was installed or upgraded	Install and upgrade records, pre-change checklists and sign-off showing defaults were reviewed	Upgrades completed with vendor defaults left in place and no review record
Deviation detection	Whether drift from baseline is detected, how often, and whether alerts reach a responsible person	Monitoring configuration, alert rules and sample alerts with dates	Drift that occurs with no alert, or alerts sent to a mailbox nobody reviews
Deviation resolution	Whether detected deviations were corrected, accepted or escalated under a documented process	Tickets or change records linked to each deviation, with closure evidence	Deviations closed without a fix, without an approved exception, or with no link to the original alert
Change control link	Whether baseline changes go through the same approval process as other production changes	Change requests that reference the baseline, and approval records	Baseline edits made directly on systems outside any change record

How to implement PR.PS-01 step by step

This sequence turns configuration management from a policy statement into a working cycle: approved hardened baselines, default settings reviewed at every install or upgrade, deviations detected and exceptions handled through change control. Each step ends with a document or record an assessor can inspect.

Inventory system classes and their functions
Group the in-scope systems into classes that share a role, such as domain controllers, Linux application servers, employee workstations, container hosts and network devices. For each class, record the software it runs, the services it must expose and the data it touches. Pull this from the asset inventory maintained under ID.AM so that no class is missing. The output is a system class register that lists each class, its owner and its in-scope assets. It is done when every asset in the inventory maps to exactly one class.
Define hardened baselines with only essential capabilities
For each system class, the owning engineering team writes a baseline that disables every service, port, protocol, package and feature the class does not need. Use an established external benchmark as the starting point where one exists, and document every deviation from it with a reason. Security and the system owner both sign off. The output is an approved baseline document per class, with each setting stated as a value and linked to its justification.
Test baselines and approve them through change control
Apply each draft baseline to a non-production build, confirm that the required business functions still work, and record any setting that breaks an application. Resolve breaks by changing the baseline or by documenting a time-bound exception. Submit the final baseline to the change advisory process for approval. The output is a test record and an approved change ticket for each baseline version. It is done when the approved version is the only one that can be deployed.
Deploy baselines as the build standard
Build golden images, configuration scripts or policy packages from the approved baselines and make them the only source for new systems in each class. Apply them to existing systems in the scope of the rollout through your configuration management tooling. Keep the baseline files under version control so that every change has an author and a reason. The output is a deployed baseline version recorded against each system in the inventory.
Review default settings at every install or upgrade
Before a new product, package or major version enters production, a named reviewer checks its default settings against the baseline checklist. The checklist covers default accounts and passwords, sample content, open management interfaces, default logging levels, and features enabled out of the box. Each default is either brought into line with the baseline or recorded as an accepted exception. The output is a completed default-settings checklist, filed with the change record for that install or upgrade.
Monitor endpoints and servers for baseline deviations
Run continuous configuration checks against the approved baselines so that drift is detected between scheduled reviews. Open-source options include Wazuh Security Configuration Assessment, which scans endpoints against YAML policies based mostly on CIS benchmarks, and Fleet, which runs yes or no osquery policies and shows which devices pass or fail each one. Confirm in each tool's documentation which checks you can customize and how results export. The output is a deviation report listing each failing system, the failed check and the date detected.
Route deviations and exceptions through change management
Triage each deviation report entry. Either remediate the system back to baseline, or raise a change request if the deviation is intended and should become part of the baseline or an approved exception. Track each item in the ticketing system, such as GLPI Assistance or Zammad, with an owner, a decision and a closure reason. Review open exceptions on a schedule set by the organization and retire those no longer needed. The output is a closed-loop exception register and a set of tickets that show who approved each deviation and why.

Choosing between a CIS-based baseline and a custom baseline

A benchmark-aligned baseline starts from a published hardening benchmark for common operating systems and applications, such as the CIS benchmarks that correspond to the CIS Controls. The organization adopts the benchmark's settings, documents each deviation it accepts, and tests the result against its own workloads. Wazuh's Security Configuration Assessment is shipped with policies that are mostly based on CIS benchmarks, and it can be extended with custom policies. Maintaining this model means tracking benchmark revisions, re-testing settings after operating system upgrades, and recording exceptions with owners and review dates. The evidence is a set of scan results showing which checks pass or fail on each monitored endpoint, plus the documented exceptions.

Fit: common server and workstation operating systems where a published benchmark already exists.
Maintenance: periodic review of benchmark versions and re-testing after upgrades.
Evidence: configuration assessment results per endpoint, with remediation recommendations.
Exceptions: each deviation from the benchmark needs a recorded reason and an approver.
Limitation: benchmark checks do not cover settings specific to proprietary or self-hosted applications.

Confirm with Wazuh which benchmark policies ship for your operating system versions and how custom policies are authored and version-controlled.

Evidence that passes a PR.PS-01 review

An assessor testing PR.PS-01 looks for proof that baselines exist, that they were applied at install or upgrade, and that drift gets caught and handled. The five artifacts below connect those points, and each one should be produced by a routine process rather than rebuilt before an audit.

Approved baseline documents with version history

A versioned, approved baseline for each system class is the anchor of PR.PS-01. It should state the essential capabilities enabled, the services and ports removed, and the owner who approved it. Keep baselines in version control so every change has an author, a date and a reason. Check that the baseline in the repository matches what the scanner enforces, because a mismatch undermines every other artifact. Refresh the baseline on a schedule and when a benchmark or vendor advisory changes.

Default-setting review records at install or upgrade

PR.PS-01 expects default settings to be reviewed when software is installed or upgraded. Evidence is a completed checklist per change that names the default accounts, passwords, services and debug options examined and the decision taken for each. Generate the record from the build or change pipeline so it is created each time, not reconstructed later. Confirm that upgrades touch the same record as new installs, since upgrades often reintroduce defaults.

Configuration scan results over time

Point-in-time scans show a configuration state on one day. Assessors want trend data showing that endpoints were checked on a recurring cycle and that failures were tracked to closure. Export scan results on a fixed schedule into a retained store, and keep the policy version that produced each result. Confirm the retention period with your auditor, since the assessor may sample results across the whole audit window. Pass and fail rates by policy are the most useful view.

Deviation alerts linked to remediation tickets

When a host drifts from its baseline, the evidence chain should run from alert to ticket to fix. Configure the monitoring tool to raise an alert for each failing policy, and route it into the helpdesk or change system with the host, policy and detection time attached. Ticket records should show who triaged the item, the remediation applied and the verification scan that confirmed the fix. Sample a few alerts before the audit to confirm the links are intact.

Exception approvals with compensating controls

Some systems cannot meet a baseline setting for business or technical reasons. An exception record documents the deviation, the risk owner who accepted it, the compensating controls, and a review date. Store exceptions in the same register as baselines so the assessor can see every approved departure in one place. Expired exceptions should trigger a review automatically. Ask the risk owner to confirm the acceptance criteria before approving any exception, since an undocumented exception is treated as a failure.

How configuration scanning and ticketing produce the evidence

The evidence for PR.PS-01 is a chain, not a single report: an approved hardened baseline, a scan that compares live systems against it, a recorded deviation, a remediation ticket, and a closure record showing the fix was verified. An assessor will usually ask for each link, and a gap in any one of them weakens the rest. Decide before deployment which baseline applies to each system class, who approves it, and where its approved version is stored, because every later scan result is only meaningful against that version. Wazuh's Security Configuration Assessment (SCA) module is one way to produce the scan link. It evaluates monitored endpoints against YAML policies, most of which are based on CIS benchmarks and can be extended with custom policies covering files, directories, registry keys and running processes. Each check reports a result and a remediation recommendation. Confirm with your own environment which policies your operating systems and applications are covered by, and whether your team will accept the shipped CIS-based checks as the baseline or will write custom policies that match the hardening standard you approved.

Fleet provides a complementary view. Its policies are yes or no questions written as osquery queries, such as whether a disk is encrypted or a specific setting is present, and the policies page shows which devices in each fleet are passing or failing each one. Export or capture those pass and fail counts on a dated schedule, since an assessor will want to see that deviations were monitored over the period under review, not only on the day you prepared. The ticketing system closes the loop. Each failing check should open a ticket in GLPI's Assistance module, which follows ITIL practice and records the request, the assigned owner, the change made and the closure date, or in Zammad, which keeps the same trail in one ticket system. Agree in advance who may close a configuration ticket and what verification is required, such as a re-scan showing a pass. Recurring deviations on the same asset should be treated as a problem to investigate rather than a series of separate fixes, and the ticket history is what shows that pattern to an assessor.

What meeting PR.PS-01 costs in money and effort

This table lists the cost components of establishing hardened baselines and monitoring them for PR.PS-01, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request, and note that no prices or durations are given because none have been researched for this requirement. Open-source licenses remove tooling spend, but staff time for baselines, exceptions and evidence remains.

Cost component	One-time or recurring	Who is paid or who spends effort	What drives it up or down
Tooling and licenses	Recurring if commercial	Software vendor or internal budget owner	Open-source scanners such as Wazuh Security Configuration Assessment remove license fees, but hosting and storage remain
Writing and testing hardened baselines	One-time, then revised	Internal platform engineers or the implementation partner	Number of platform types, depth of CIS-style hardening and how many default settings must be justified
Review of default settings at install or upgrade	Recurring	Platform or release engineers	Release frequency and the number of software versions in production
Deviation monitoring and triage	Recurring	Security operations staff and system owners	Fleet size, scan frequency and how many deviations are accepted as exceptions versus fixed
Baseline maintenance and change control	Recurring	Change board and ticketing administrators	Change frequency and whether tickets for baseline changes are tracked in a system such as GLPI or Zammad
Evidence upkeep	Recurring	Compliance lead and system owners	Whether scan results, approvals and exception records are exported automatically or assembled by hand
External review of the baseline	Periodic, often one-time per baseline version	Independent reviewer or consultant, if engaged	Scope of the baseline, number of custom policies and whether the organization wants an outside challenge before an assessment
Auditor sampling	Per assessment cycle	Independent auditor or assessor, not the implementation partner	Number of systems in scope, population size and how cleanly baseline records map to sampled systems

Open-source tools that produce PR.PS-01 evidence

PR.PS-01 asks for baselines, default-setting reviews and deviation monitoring to exist and to run. The three tools below each produce a different kind of record for those activities, and the ticketing option shows how changes get approved and tracked. Confirm each tool's current capabilities against its vendor documentation before relying on it for an assessment.

Wazuh configuration assessment

Wazuh's Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies, most of them based on CIS benchmarks and extendable with your own policies. It checks files, directories, registry keys and running processes, and recommends remediation. For PR.PS-01, the scan results are the strongest evidence of monitoring for deviations from a hardened baseline, provided you keep the policy files under version control with the approval record. Confirm which policy sets ship with your release and how often scans run in your deployment. Wazuh is licensed GPL-2.0-only, so review what that license requires if you modify and distribute the software.

Fleet policies for device state

Fleet policies are yes or no questions asked of devices as osquery queries, and the policies page shows which devices in each fleet pass or fail each one. This suits PR.PS-01 when your baseline can be stated as a checkable device condition, such as a setting being enabled or a service being absent. Export the pass and fail history at each review date so the record shows the baseline held over time, not just on one day. Fleet is licensed MIT, which imposes light obligations on redistribution. Confirm which osquery tables cover the settings your baseline names.

GLPI change records

GLPI's Assistance module lets teams create, follow and process tickets, problems and changes following ITIL practices, with plannings, statistics, recurrent tickets and a Kanban view. For PR.PS-01, change records show who approved a baseline change, why a default setting was altered during an install or upgrade, and when the change was made. Link each change to the scan or policy result that triggered it so an assessor can trace deviation to remediation. GLPI is licensed GPL-3.0-or-later, so confirm the terms that apply if you distribute modified versions.

Zammad as a ticketing alternative

Zammad is a web-based helpdesk that brings customer communication from email, chat, telephone and social media into one ticket system. It is an option where the change and deviation workflow starts with requests from users or customers rather than from an ITSM process. Its main value for PR.PS-01 is a single, time-stamped trail linking a reported configuration problem to the fix. Confirm that its ticket fields can carry the baseline identifier and approval fields your assessor will ask about. Zammad is licensed AGPL-3.0-only, and the network-use clause of that license can apply to modified versions offered to users over a network, so check it with counsel.

Who owns configuration management and who can help

Your organization owns the configuration management outcome that PR.PS-01 describes. That means deciding which baselines apply to each class of system, approving any deviation from them, and accepting the residual risk when a system cannot meet its baseline. No outside party can make those decisions on your behalf, and an auditor will ask who made them and when.

Baseline ownership: Named owners, usually in security with platform engineering, approve the hardened baseline for each operating system, container image, network device and application, and record the version they approved.
Exception approval: Requests to run a service with a default setting or a non-baseline configuration go through a documented approval, with a stated reason, an expiry date and a compensating control.
Change control: Baseline changes pass through your change process so that the record of who changed what, and why, exists before an assessor asks for it.
Operating the monitoring: Someone on your staff reviews deviation reports and decides whether each one is remediated, excepted or accepted.

Before engaging anyone, confirm that these owners are named in writing and that they have the authority to stop a deployment that fails its baseline.

Where PR.PS-01 programs usually fall short

Most PR.PS-01 weaknesses are not missing tools. They are gaps between a written baseline, the systems actually running it, and the people who fix what drifts. The cards below cover five gaps that assessors and platform teams often find, each with a closure step you can check.

Baselines that exist only as documents

A hardening standard stored in a wiki does not configure anything. PR.PS-01 expects baselines that are established, tested, deployed and maintained, so each approved baseline should map to a policy that a scanner or configuration tool evaluates on real endpoints. Check whether every production system class has a machine-readable baseline and whether someone can show when it was last tested against a running host.

Default settings never reviewed on upgrade

Installers and upgrades often reset or add defaults, such as open services, sample accounts or permissive logging. PR.PS-01 calls for default settings to be reviewed when software is installed or upgraded, yet many teams review only the initial build. Closure means adding a default-settings review step to the change template for every upgrade and keeping the signed-off result with the change record.

Drift detected but not ticketed

A failing policy on a dashboard is not remediation. When a device fails a configuration check, the failure needs an owner, a ticket and a due date, or the monitoring result has no effect on the baseline. Route failing checks from the monitoring platform into the service desk, and sample closed tickets to confirm that the fix was verified on the device rather than marked done.

Exceptions with no expiry

Teams often accept a deviation from baseline to keep a legacy application running, then forget it. An exception without an expiry date, a named risk owner and a compensating control becomes a permanent gap that auditors find during sampling. Require every exception to record its reason, approver, compensating control and review date, and reconcile the exception register against current scan results each review cycle.

Unclear ownership between platform and security

When the platform team builds images and the security team writes the baseline, changes can fall between them. PR.PS-01 outcomes depend on a clear split: one team owns the baseline content, another owns deployment and drift remediation, and both sign off changes to the baseline. Document this split in a RACI, then confirm that each deviation ticket names an owner from the team that can actually change the system.

PR.PS-01 questions buyers ask before hiring help

How much effort does it take to meet PR.PS-01 configuration management?

Effort depends mostly on how many systems need a baseline, how much of the estate is already managed by configuration tooling, and how many distinct system types (servers, endpoints, cloud accounts, network devices, containers) must be covered. PR.PS-01 asks for hardened baselines that provide only essential capabilities, a review of default settings at installation or upgrade, and monitoring for drift from approved baselines. Each of those three parts carries recurring work: someone must choose the benchmark, document exceptions, test changes before deployment and review drift reports. Ask any provider to break the effort down by system type and by the three Implementation Examples, and to state which parts are one-time (initial baseline build) and which recur (review, exception handling, drift triage).

Can an in-house team meet PR.PS-01 without outside help?

Often yes, if the team already runs infrastructure as code, has a documented change process and can name an owner for each baseline. The harder questions are whether staff have time to build baselines from benchmarks, whether they can test changes without disrupting production, and whether anyone watches for deviations after go-live. Organizations that lack one of these usually bring in outside help for a fixed scope, such as building baselines for a defined set of systems, wiring a scanner to report drift, or writing the procedure that connects them. An implementation partner can prepare the systems and evidence, but the organization must still own the baselines, approve exceptions and accept residual risk.

How long does it take to produce evidence for PR.PS-01?

The time to produce evidence depends on the state of the estate, not on a fixed period. The main drivers are how many systems are unmanaged today, whether baselines already exist in version control, how many exceptions need documented approval, how long the change process takes to run a full cycle, and whether drift monitoring is already producing reports. Evidence usually comes in two forms: the baseline documents and their approval records, and the results of scans or queries that show systems passing against those baselines over time. An assessor is more likely to ask for consistent results across a sample period than for a single clean scan, so plan for the monitoring to run before the assessment. Ask any provider for a schedule tied to named milestones in a written scope rather than a generic duration.

What does the work need from our side?

The work needs named owners more than it needs tools. Expect to supply access to the systems in scope, the current build standards or vendor benchmarks your teams already follow, a list of approved software and services, and the change approval path. You also need a decision-maker who signs off on baseline settings, especially where a hardened setting might break a business application. Engineers should be available to test changes in non-production environments, and a ticketing owner should be ready to route drift findings. Ask the provider to list these client inputs in the written scope, because gaps in access or approvals are the most common cause of late evidence.

Does NIST certify organizations or products against CSF 2.0?

No. NIST states that it does not offer certifications or endorsements of CSF-related products, implementations or services, and it has no plans to develop a conformity assessment program for the CSF. Any firm that claims to certify a CSF 2.0 implementation, or that sells a NIST certificate, is making a claim NIST does not support. You can use the CSF to describe your program and measure gaps against it, but the outcome is your own self-assessment unless an independent assessor reviews it. Check the NIST Cybersecurity Framework FAQs before accepting any certificate offer.

Who issues the assessment outcome for PR.PS-01?

The organization issues its own assessment outcome, and an independent assessor issues any external opinion. Under NIST's approach, the organization decides its Current and Target Profiles and its Tier, so the first assessment is internal. When a customer, regulator or contract requires independent evidence, an outside assessor or auditor reviews the controls and the evidence and reports on what they found. DeployOpen prepares systems, configuration baselines and evidence for those reviews, but it does not issue audit reports, attestations or certifications. Confirm with any provider, and with the body that will rely on the result, who the independent reviewer will be before work starts.

What is included in a fixed-scope PR.PS-01 engagement?

A fixed-scope engagement lists the systems covered, the baselines to be built or reviewed, the monitoring to be deployed, the evidence to be delivered and the client inputs required, all agreed in writing before work starts. For PR.PS-01 it would normally cover the three parts of the Subcategory: building hardened baselines for named system types, reviewing default settings at install and upgrade, and configuring drift monitoring with a defined triage process. Open-source tooling such as Wazuh Security Configuration Assessment can check endpoints against YAML policies, and Fleet policies can ask yes or no questions of devices through osquery queries. Confirm with the provider which tools are in scope, which are already in your environment, and what happens to exceptions and ongoing monitoring once the engagement closes. Ongoing support and upgrades are available as retainers.

How DeployOpen scopes and prepares PR.PS-01 evidence

DeployOpen works on PR.PS-01 by preparing the self-hosted platforms in your own infrastructure so that hardened baselines, default-setting reviews and deviation monitoring can be shown to exist and operate. Your organization owns the baselines and the decisions behind them, and an independent assessor decides whether the outcome is met.

How we scope

Agree in writing which systems, cloud accounts and endpoints fall under the PR.PS-01 configuration baselines.
Confirm which baseline sources your organization approves, such as CIS benchmarks or internal standards, before any build work starts.
Record who owns each baseline, who approves deviations and which evidence the assessor will request.

How we build

Configure a hardened baseline for each in-scope platform that enables only the capabilities the business needs.
Set up Wazuh Security Configuration Assessment policies or Fleet policies to check endpoints against the approved baseline.
Test that deviations are detected and routed to a ticket, using GLPI or Zammad as the change record where your organization already uses them.

How we hand over

Deliver baseline documents, the review record for default settings at install and upgrade, and the monitoring configuration.
Provide a dated evidence set with scan results, pass and fail history, and linked change tickets for your assessor.
Walk your technical and compliance staff through how to maintain the baselines and read the monitoring output.

How we support

Support baseline updates when vendors release new hardened configurations or your approved standards change.
Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work is complete.
Ask your assessor early which evidence format they accept, so the handover matches what they will test.