Safeguard 4.1 secure configuration process: requirements and evidence

What Safeguard 4.1 requires and why the CIS assessment fails so many organizations

Safeguard 4.1 asks for a written process for configuring enterprise assets and software securely, covering end-user devices (mobile included), IoT devices, servers, operating systems and applications. The process must be reviewed once a year or after significant enterprise changes. If you need to show a CIS assessor that this exists, you need a current, approved document that someone can point to, not a collection of well-configured hosts. The Safeguard sits in the Documentation asset class and the Govern security function in v8.1, and all three Implementation Groups carry it, so it is part of the essential cyber hygiene baseline that every enterprise is expected to meet.

That placement explains why it fails so often. The Assessment Specification scores Safeguard 4.1 as failing in two cases: no secure configuration process exists, or the process was last reviewed and updated more than 12 months ago. The measure is standard configuration coverage, so the assessor is checking whether a documented standard exists and is being kept current, not only whether a sample of servers matches it. Because 43 other Safeguards list 4.1 as a prerequisite, a stale document also weakens the evidence behind many other results.

Illustrative case: an organization runs strong hardening through automated tooling, but the only written standard is a benchmark export last approved two years earlier. The hosts may pass every check, yet the Safeguard fails on the date. Before any assessment, confirm the document's approval date, its owner, the review trigger for significant changes such as a new cloud account or OS release, and whether the review record is kept in a system that shows who changed what and when. Open-source platforms such as XWiki can keep that version history, but the organization still has to own the content and the review.

Which assets, teams and third parties Safeguard 4.1 covers

Safeguard 4.1 applies to end-user devices, mobile devices, IoT devices, servers, operating systems and applications. The scoping choices below decide who writes the process, who runs it and whose configurations it has to reach, so settle them before drafting the document.

End-user and mobile devices

The Safeguard names end-user devices, mobile included, so laptops, desktops, tablets and phones all fall inside the written process. Check whether personal devices enrolled for work access are covered, because a process that stops at company-owned laptops leaves the phones that reach email and files outside its reach. Ask who approves a baseline for each device class and whether one document can describe all of them without becoming vague.

Servers and cloud images

Servers and virtual machines need their own baselines, and cloud instances built from golden images are a separate case. A process that covers the image pipeline and the running instances means a fix in the template reaches every new build, while one that only covers live hosts drifts as soon as a new image launches. Confirm who owns image build definitions and how changes to them are reviewed.

IoT and operational devices

IoT devices, printers, cameras and building or industrial controllers often run vendor firmware that cannot take the same agents as a workstation. The Safeguard still asks for a documented configuration process for them, so the document should state how default settings are changed, which settings are fixed by the vendor and who accepts that residual risk. Confirm vendor support terms before promising a baseline.

Managed service providers and contractor devices

When a managed service provider administers servers or endpoints, or a contractor uses a personal laptop to reach enterprise systems, the enterprise still needs to know which configuration standard applies. Write the process so it names the party that applies each baseline, and put the configuration requirements into the service contract. Ask providers for evidence of their own configuration checks, not only a general statement of compliance.

Software inventory as the input

Safeguard 2.1 requires a software inventory, and the CIS assessment specification lists it as a prerequisite for measuring 4.1 because it typically supplies the data the measurement needs. Without it, you cannot show which operating systems and applications the baselines cover. Check that the inventory names the versions in use, since configuration baselines are version-specific.

Safeguards that depend on this process

Forty-three other Safeguards list Safeguard 4.1 as a prerequisite, including Safeguards 1.3, 2.5, 2.7 and 3.3. That makes the configuration process a dependency for many controls, so an outdated or incomplete document weakens evidence across several areas at once. Map the owners of those dependent Safeguards before the first review, so the document cannot be updated without them knowing.

How the process ties to the rest of Control 4 and other Safeguards

Safeguard 4.1 requires a written process for configuring servers and other enterprise assets securely, and that process becomes the reference for every server image, virtual machine template and cloud build. Downstream, Safeguard 4.4 asks for host firewalls on servers where supported, and Safeguard 4.8 asks for unnecessary services to be removed or disabled. Both are easier to verify when the build standard names the expected firewall profile and the approved service list.

Firewall baseline: the standard names the host firewall expected on each server role, which Safeguard 4.4 then checks.
Service list: approved services per role give Safeguard 4.8 a fixed comparison point.
Build pipeline: Safeguard 4.6 covers version-controlled infrastructure as code, so the standard can point to the repository that builds the image.
Measurement: configuration coverage across servers is the metric the assessment specification uses for Safeguard 4.1, so the same benchmark results can be reused.
Review trigger: a cloud region, base image or hypervisor change counts as a significant enterprise change and should prompt a review.

Check that each server role in your inventory maps to a documented baseline, and confirm which scanner results you will keep as evidence for the annual review.

How an assessor tests Safeguard 4.1 under the CIS Assessment Specification

The table walks through the steps an assessor takes to test Safeguard 4.1, the evidence each step expects and the findings that most often fail the test. Read it as a checklist for your own readiness review before an outside party looks at your documented process.

Assessor step	What the assessor checks	Common finding
Request the written process	A documented secure configuration process that exists as a controlled document, not only as practice	Configuration guidance spread across wiki pages, tickets and chat threads with no single owner
Check the scope	The process covers end-user devices including mobile, IoT devices, servers, operating systems and applications	Mobile or IoT assets are missing from scope, or the process names only servers
Confirm the review date	The document was reviewed and updated within the last 12 months, as the assessment specification requires	Documents with no version history or review date, or a last review older than 12 months
Check review triggers	The process is reviewed after significant enterprise changes, such as a new platform, cloud region or device type	No record linking a major change, such as a migration, to a review of the process
Sample configuration coverage	A sample of assets matches the documented standard configurations, and the measured coverage is recorded	Baselines exist only in engineers' heads, or the sampled assets drift from the documented standard
Trace the prerequisite inventory	The software and asset inventories that feed the measurement are current enough to show which assets the process covers	Inventory gaps mean the assessor cannot tell which assets the process applies to
Record the result	Pass when the process exists, is in scope and is current, with coverage evidence to support it	Fail when no process exists or the last review is more than 12 months old

Steps to establish and maintain the secure configuration process

The sequence starts from an asset and software inventory, moves through baseline selection and a written, approved process, and ends with measured coverage and a recurring review cycle, so the document reflects what actually runs in the environment.

Confirm the asset and software inventory
Before writing anything, the configuration owner confirms which end-user devices, mobile devices, IoT devices, servers, operating systems and applications are in scope. This work draws on the asset inventory (Control 1) and software inventory (Control 2) already maintained by IT operations and security. Safeguard 2.1 is a prerequisite for measuring Safeguard 4.1, so gaps here carry forward into every later step. The output is a scoped list of asset classes and software platforms, with a named owner for each, that the process document can reference directly.
Select baseline sources for each platform
For each asset class and software platform, the team chooses the configuration baseline it will follow. Common sources are CIS Benchmarks where one exists, vendor hardening guidance, and internal standards that reflect the organization's own risk decisions and regulatory obligations. Where sources conflict, the choice and its reason are recorded. The output is a baseline register that lists each platform, its chosen source, the version of that source, and the person accountable for keeping it current. Confirm licensing terms for any benchmark content before reusing it in internal documents.
Write the secure configuration process
The security function drafts the written process, covering how baselines are adopted, how builds are configured and verified, how deviations are requested and approved, and how exceptions expire. The document names owners for each platform and for the review itself, and it states how it applies to end-user devices, mobile devices, IoT devices and servers. Exception handling needs an approver, a justification, a compensating measure and an end date or review trigger. The output is a draft process document with a roles section and an exception procedure that an assessor can trace step by step.
Approve the process at the right level
Someone with authority over the affected systems formally approves the document, typically the CISO or the IT leader who owns infrastructure, with input from operations and any application owners. Approval should be recorded with a name, a date and the version approved. Reviewers check that the owners named in the process exist and have the access and time to perform their roles. The output is an approved, dated version of the process and a short record of the approval, which together show that the document is management-endorsed rather than a working draft.
Publish the process under version control
The approved process and its baseline register are published to the location staff actually use, such as an internal wiki or documentation platform, with access rights matched to the audience. Every change is kept as a version with a record of what changed, when and by whom, and older versions remain retrievable. This history is the evidence an assessor uses to confirm the review cadence in Safeguard 4.1. The output is a published, versioned document with a visible last-reviewed date and a change log that shows the revision history from the first approval onward.
Deploy baselines and measure coverage
Engineering applies the baselines to enterprise assets using the organization's build and management tooling, then measures how many assets and applications match their assigned baseline. Automated checks, such as configuration assessment scanning or endpoint policy queries, produce pass and fail results that feed a coverage figure. The CIS Controls Assessment Specification uses standard configuration coverage as its metric for Safeguard 4.1, so this measurement is the core evidence. The output is a coverage report by asset class with a list of non-compliant devices, each linked to an approved exception or a remediation ticket.
Remediate gaps and reconcile exceptions
Owners work through the non-compliant items from the coverage report, either correcting the configuration or raising an exception through the defined procedure. Exceptions that have passed their end date or review trigger are escalated to the approver. Recurring deviations are treated as a signal to update the baseline or the process itself. The output is a reconciled register in which every failing asset has either a closed remediation or an approved, time-bound exception, which keeps the coverage metric meaningful when the next measurement runs.
Set the annual and change-triggered review
The process sets two review triggers: an annual review and an earlier review after significant enterprise changes, such as a new platform, a major acquisition or a new cloud region. The assessment specification fails Safeguard 4.1 when the process has not been reviewed and updated within 12 months, so the calendar entry, a named reviewer and the change-management hook all matter. Each review produces a dated revision, updated baselines where sources have changed, and a record of the review decision. Confirm with your assessor which evidence they accept for the change-triggered review. The output is a recurring review record that keeps the process current and demonstrable.

Evidence that satisfies Safeguard 4.1 and how to keep it current

Safeguard 4.1 is judged on documents and records more than on any single setting. The cards below cover the artifacts an assessor expects to see, and the routine that keeps each one accurate between assessments. Treat them as a set: the process document sets the rules, the baselines apply them, and the review records and coverage reports prove they are followed.

Approved process document with version history

This is the written secure configuration process itself, covering end-user devices including mobile, IoT devices, servers, operating systems and applications. Keep a named owner, an approval record, and a version history that shows each revision and who approved it. The assessment specification fails Safeguard 4.1 when the process was last reviewed and updated more than 12 months ago, so the review date printed on the document must match the date in the version history. Confirm which review trigger your organization has adopted for significant enterprise changes.

Per-platform configuration baselines

Baselines translate the process into settings for each operating system, server image, browser, mobile platform and application in scope. Each baseline should name its platform version, the source it was derived from, and the exceptions approved for it. Store baselines in version control so every change has an author and a reason. Confirm that the baselines cover the platforms listed in your software inventory, since Safeguard 2.1 supplies the data that tells you what needs a baseline.

Review records and change tickets

Assessors look for evidence that the process was reviewed on schedule and after significant changes such as a new platform, a major upgrade or a change in regulated scope. Keep meeting minutes or review sign-offs with attendees, the decisions taken and the updated document version. Link each significant change to the ticket that triggered the review. A review that exists only as an annual calendar entry, with no record of what was decided, is weak evidence.

Configuration coverage reports

Coverage reports show what share of in-scope assets run the approved baseline, which is the metric the assessment specification uses for Safeguard 4.1. Generate them on a fixed schedule and retain the exported report with its date and query. Fleet policies can show which devices in each fleet pass or fail a given check, and Wazuh can report misconfigurations against its policies. Confirm that the asset population in the report matches the asset inventory, or the coverage figure will not be credible.

Exception and deviation register

Every host that departs from its baseline needs a recorded exception, with the business reason, the compensating control, an owner and an expiry date. Without this register, coverage reports will show failures that look like neglect rather than managed risk. Review open exceptions at each process review and remove those that have expired. Ask your auditor which exception format they accept before you build the register.

Access to the documents themselves

Assessors also check who can change the process and baselines. Restrict edit rights to the configuration owners and give read access to the teams that apply the standards. Role-based permissions in a wiki such as BookStack let you set this per shelf, book or page. Review those roles at each process review, and remove access for people who have changed teams, so that the approved version is the only version anyone can apply.

What meeting Safeguard 4.1 costs in money and effort

This table breaks down the cost components of establishing and keeping a secure configuration process under Safeguard 4.1, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to shape a scope before requesting a fixed-scope written quote, since no price or duration for this work is published here.

Cost component	One-time or recurring	Who is paid or who spends effort	What drives it up or down
Writing and approving the process	One-time, then revised	Internal security and IT staff, with an implementation partner if engaged	Number of asset types covered (end-user, mobile, IoT, servers) and the number of approval layers
Baseline definition for each platform	One-time per platform	Platform engineers, often with an external partner	Count of operating systems and applications, and whether a published CIS Benchmark already fits
Software inventory prerequisite	One-time setup, ongoing upkeep	Internal asset owners or tooling administrators	Whether Safeguard 2.1 data already exists, since the CAS treats it as a prerequisite for measuring 4.1
Tooling for checking configurations	Licensing or none, plus recurring operation	Tool vendor or open-source operators; internal staff for hosting	Open-source tools such as Wazuh or Fleet remove license spend but need hosting, updates and tuning
Annual review	Recurring, at least yearly	Process owner, system owners and reviewers	CAS fails the Safeguard if review is more than 12 months old, so the calendar must be enforced
Review after significant change	Recurring, event-driven	Change managers and platform teams	Rate of infrastructure change, cloud migrations and new device classes
Evidence upkeep	Recurring	Process owner and document controllers	Version history, approvals and scan results that must be kept current for each review cycle
External review and auditor sampling	Recurring when an assessment is scheduled	Independent auditor or assessor, selected by the organization	Number of frameworks mapped to 4.1 and the sample sizes the assessor chooses

Which open-source tools produce evidence for Safeguard 4.1

Which open-source tool checks configurations against CIS benchmarks?

Wazuh's Security Configuration Assessment is the most direct fit for the configuration side of Safeguard 4.1. It scans monitored endpoints for misconfigurations using YAML policies, most of which are based on CIS benchmarks, and it checks files, directories, registry keys and running processes, then recommends remediation. Because Wazuh is licensed under GPL-2.0-only, confirm with your legal team what that license requires when you modify or distribute the software, and whether your internal use or hosting model triggers those obligations. Custom policies let you encode your own standard configurations, which is useful when your documented process sets baselines beyond the benchmarks. The scan results show drift from the baseline, but they do not show that a written process exists.

How does Fleet show which devices meet a configuration policy?

Fleet policies ask yes or no questions of devices as osquery queries, such as whether a disk is encrypted or a particular setting is enabled. The policies page shows which devices on each fleet are passing or failing each policy, which gives you a current coverage view that maps to the standard configuration coverage measure in the assessment specification. Fleet is licensed under MIT, which is a permissive license, but confirm the terms that apply to the version and edition you deploy. Policies only answer the questions you write, so the queries should come from the configuration standards in your documented process. Ask the engineers who will maintain the queries how they plan to version and review them.

Can XWiki prove that the secure configuration process was reviewed annually?

XWiki can hold the written process and keep its history. Every change to a page is kept under version control, recording what changed, when and by whom, and you can compare any two versions or roll back to an earlier one. That history is useful evidence for the review date that the assessment specification checks, since it shows when the document was last updated. XWiki is licensed under LGPL-2.1-or-later, so confirm with counsel how the license applies to your deployment and any modifications. The history proves edits happened, not that the content is adequate, so the review itself still needs a named owner, a recorded approval and a rationale for changes.

How does BookStack control who can edit the secure configuration documents?

BookStack gives users abilities through the roles assigned to them, and permissions can be overridden per role at the shelf, book, chapter or page level. You can therefore let platform engineering edit the configuration standards while security reviewers can only view them, and restrict a sensitive chapter to a smaller group. This access model supports the ownership and approval evidence that auditors look for. BookStack is licensed under MIT. Confirm the role design with your document owners before deployment, and test it, because layered overrides can produce results that differ from what the admin intended. Access settings do not replace the review record itself.

Does using these open-source tools make us compliant with Safeguard 4.1?

No. Safeguard 4.1 asks for a documented, maintained process for secure configuration, covering end-user, mobile, IoT and server assets as well as operating systems and applications, reviewed annually or after significant changes. Tools can produce evidence that supports parts of that process, such as scan results, policy coverage and document history, but the organization still owns the decision of what the secure configuration standard is, who approves it and when it is reviewed. Assessors will also expect a software inventory from Safeguard 2.1 because the assessment specification treats it as a prerequisite for measuring 4.1.

Which evidence should we keep from each tool for an assessment?

Keep dated exports or screenshots that show what the tool checked and what it found, along with the policy or query version in use. For Wazuh, this means the policy files and scan reports for each reporting period. For Fleet, it means the policy definitions and pass or fail summaries by fleet. For XWiki and BookStack, keep the page history and the approval record for each version of the standard. Ask your assessor, or the auditor or certification body you engage, which format they accept, because the exact evidence requirements depend on the framework and engagement.

What does it cost to run these tools, and who pays for setup?

Each tool is open source, so there is no license fee for the software itself, but the costs are in deployment, hosting, configuration, policy authoring, maintenance and staff time. Hosting depends on your endpoint count and infrastructure, and policy writing depends on how many configuration standards you maintain. Setup can be done by your own team or by an implementation partner under a fixed-scope written agreement. Ask any partner for a written scope listing the tools, the number of platforms, the policies to be authored and the evidence to be delivered, then compare quotes on that basis. DeployOpen does not publish prices and quotes follow from the written scope.

Who issues the evidence assessment, and does DeployOpen certify us?

The organization owns its controls. An implementation partner such as DeployOpen can plan, deploy and document these open-source platforms inside your own infrastructure, and prepare the configuration standards and evidence that assessors will review. Only an independent auditor, assessor or certification body issues reports or certificates. DeployOpen does not issue audit reports, attestations or certifications, so any assessment of Safeguard 4.1 must be carried out by a party independent of the team that built the tooling.

Who owns the process, who implements it and who assesses it

Your organization owns the Safeguard. The written secure configuration process is an internal governance document, so it needs an accountable owner, usually in security or IT operations, and approval from the people who answer for risk. Your team decides which asset types the process covers (end-user devices, mobile, IoT, servers, operating systems and applications), sets the standards each asset type must meet, and records who approved the document and when.

The work that stays with your team is continuous:

Ownership and approval: a named owner, a sign-off record and a decision on which standard (such as a CIS Benchmark profile or an internal baseline) applies to each asset class.
Annual and change-driven review: the process must be reviewed at least once a year or after significant enterprise changes, and your team keeps the review record.
Exception handling: deviations from the standard are approved, time-limited and documented by the owner.
Operational follow-through: someone responds when configuration checks fail and tracks remediation.
Dependency on the software inventory: the process depends on knowing which assets and software exist, so inventory work under Safeguard 2.1 must be current.

Before an assessment, confirm that the document, approval history and review records all exist and match what staff actually do.

Where organizations fall short on Safeguard 4.1

Most organizations have some configuration guidance somewhere, but Safeguard 4.1 is measured on a documented, approved and current process. The gaps below are the ones that most often cause an assessor to fail the measurement even when the underlying hardening work is real. Each one has a closing action you can check before an assessment.

Process exists but is unapproved

Engineers often follow a wiki page or a set of scripts that nobody with authority has signed off. The assessment looks for a written process that the enterprise maintains, so an unowned document is weak evidence. Check that a named owner has approved the current version and that the approval is recorded with a date. Action: attach an approval record and owner name to the process document.

Review date older than 12 months

The CIS assessment specification scores Safeguard 4.1 as failing when the process was last reviewed and updated more than 12 months ago. Teams often approve a process once and forget the annual cycle, so the failure appears quietly at the next audit. Track the last review date in the document header and in your calendar. Action: schedule the annual review and record the date of the last completed review.

Mobile and IoT omitted

Many processes cover servers and laptops but say nothing about phones, tablets, kiosks, sensors or other IoT devices. Safeguard 4.1 expects the process to address end-user devices including mobile, IoT devices and servers, so a server-only document leaves real assets out of scope. Compare the process scope against your device inventory from Control 1. Action: list each asset class in the process and name the baseline that applies to it.

Baselines not linked to the process

A process that describes hardening in general terms gives an assessor nothing to verify. Measurement depends on whether the configurations actually deployed match a standard configuration, so the process should point to the specific baselines in use, such as CIS Benchmarks or internal standards. Without that link, coverage cannot be counted. Action: reference each baseline by name and version in the process document.

Changes do not trigger review

Significant enterprise changes, such as a new operating system version, a new cloud region or a new application, should prompt a review of the process. When the process only changes on the annual calendar, configurations drift between reviews without anyone deciding whether the process still fits. Add a review trigger to change management tickets for infrastructure and software changes. Action: add a change category that asks whether the secure configuration process needs updating.

Exceptions are undocumented

Every enterprise has systems that cannot meet a baseline, such as legacy applications or vendor appliances. When those deviations are handled informally, the process appears to describe a state the environment never reached, and the evidence contradicts the document. Record each exception with its reason, the compensating measure and an expiry or review date. Action: maintain an exception register linked from the process and reviewed with it.

Safeguard 4.1 cost, effort and outsourcing questions

How much effort does a first secure configuration process take?

The effort depends mostly on how many asset types the process must cover and how much configuration knowledge already exists in writing. Safeguard 4.1 asks for one documented process that covers end-user devices, mobile devices, IoT devices, servers, operating systems and applications. A team that already has build standards for servers and laptops can usually consolidate them into one document. A team starting from nothing must first agree on baselines, owners and exception handling. No fixed duration is supplied for this work, so ask the partner to state the effort in the written scope, broken into discovery, drafting, approval and first review.

Can our in-house team write the secure configuration process ourselves?

Yes, an in-house team can write the process, and it is the party that must own it. The document needs a named owner, approval by management and an annual review, which the organization performs itself. What is harder to do alone is the technical grounding: mapping each asset class to a baseline, such as a CIS Benchmark or a vendor hardening guide, and deciding what counts as a deviation. Many teams write the process internally and bring in outside help only for the technical baselines or for a gap check against the assessment specification.

What does a partner need from our organization to start?

A partner needs access to the people and records that describe how systems are built today. Expect to provide a current software and asset inventory, because Safeguard 2.1 is a prerequisite that the assessment specification uses when measuring Safeguard 4.1. Also provide existing build and change procedures, any hardening standards, the list of operating systems and applications in use, mobile device management details, cloud account structure and the names of the people who approve configuration changes. Agree on access to test environments before work starts, and confirm this list in the written scope.

How long will the whole secure configuration work take?

No timeline for this work is supplied in our researched facts, so we cannot give a duration here. The timeline depends on the number of asset classes, the maturity of existing documentation and how many approvals the process needs. Most engagements are fixed-scope, meaning scope, deliverables and timelines are agreed in writing before work starts. Ask for the duration and milestones in the quote, and check that the plan includes the first annual review and the 12-month review cycle the assessment specification applies.

Do the CIS Controls policy templates cover Safeguard 4.1?

The CIS Controls policy templates are free written policies built around the IG1 Safeguards, and they can give a team a starting structure for the documented process. They do not replace the organization's own configuration standards, because the process must describe how your assets are actually configured and reviewed. Read the template against the assessment specification for Safeguard 4.1 and confirm that it names the asset types, the review cycle and the owner. Adapt the wording to your environment before approval, since an assessor will test the process you run, not the template.

Can a partner issue a CIS Controls certificate for our secure configuration process?

No. DeployOpen prepares systems, controls and evidence, but it does not issue audit reports, attestations or certifications. The CIS Controls do not replace any regulatory or certification scheme, and CIS does not offer a certificate for implementing the Controls through a partner. If a customer, contract or regulator asks for independent verification, the organization must engage an independent assessor or certification body that meets the requirement. Confirm the scope of any assessment with that party before the process is finalized.

What ongoing costs come after the first process is approved?

The recurring costs are the annual review, updates after significant enterprise changes, and the effort to keep the evidence current. The assessment specification fails the Safeguard when the process was last reviewed more than 12 months ago, so the review must be scheduled and recorded every year. Ongoing support, upgrades and continuous testing are available as retainers, but whether you need one depends on how often your environment changes. Ask the partner which parts are one-time and which recur, and what each recurring part costs under the quote.

How DeployOpen prepares Safeguard 4.1 evidence

DeployOpen's part of Safeguard 4.1 starts with a written scope agreed before any work begins. The scope names the asset classes the secure configuration process must cover (end-user devices including mobile, IoT devices, servers, operating systems and applications), the platforms in the client's own cloud accounts, data centers or air-gapped networks, and the owners who must approve the process. The organization owns the control. It decides who signs the process, how often it is reviewed (the assessment specification scores a process failing if it was last reviewed and updated more than 12 months ago) and what counts as a significant enterprise change that triggers an earlier review. DeployOpen does not issue audit reports or certifications. Independent auditors and certification bodies issue those, and they will test the process as the client actually runs it.

DeployOpen then implements the configuration baselines inside the client's environment and configures the evidence tooling against them. For the measurement to work, the software inventory from Safeguard 2.1 must exist first, so the work confirms that inventory covers every asset type the process names. Wazuh Security Configuration Assessment can be loaded with CIS-based YAML policies and custom policies, and Fleet policies can ask yes or no osquery questions of devices, with per-device pass and fail results. Confirm with the client which policies are in scope, who reviews failing results, and how exceptions are approved and recorded. Those decisions are the ones an assessor will ask to see.

DeployOpen prepares the documentation the assessor will read: the written process, its revision history and the approval record for each review. XWiki keeps every page change under version control with who changed what and when, and BookStack roles can restrict who may edit or approve the process pages. Before the assessment, ask the independent assessor which evidence format and sampling method they expect, and whether they will test the process against the CIS Controls Assessment Specification. The organization should keep the process, the scan results and the review records current after handover, because the evidence has to show the process is operating, not only that it was written.