What Safeguard 4.6 asks for and why administrative access paths decide the result
Safeguard 4.6 requires an organization to manage its enterprise assets and software securely: configuration is kept in version-controlled infrastructure as code, administrative interfaces are reached over secure protocols such as SSH and HTTPS, and insecure protocols such as Telnet and HTTP are avoided unless they are operationally essential. CIS places it in the Devices asset class and the Protect security function, and assigns it to all three Implementation Groups, so it is part of IG1 essential cyber hygiene and applies to every enterprise regardless of size. The Safeguard depends on three others: the enterprise asset inventory (1.1), the software inventory (2.1) and the secure configuration process (4.1), which typically produce the data needed to measure it.
The risk is easy to state. Weak administrative channels let an attacker take control of a system, and untracked changes let production drift away from its approved state, so a server that was hardened last year may be running a different configuration today. What makes this hard is rarely the protocol itself. It is the inventory that is incomplete, the management path that someone set up years ago and never documented, and the change made by hand on a live system that never reached the repository. Each of these gaps means an assessor cannot confirm that every asset is managed the way the Safeguard describes.
For a CISO or engineering lead, the practical starting point is to confirm three things before any tool is chosen. First, that the asset and software inventories cover the systems that carry administrative access, including network devices and cloud management consoles. Second, that every administrative interface is listed with the protocol it uses, and that Telnet and HTTP appear only where a documented business reason exists. Third, that configuration changes flow through version control so the repository can show who changed what and when. Ask the assessor which evidence they expect for each of these points, since the CIS Controls Assessment Specification defines what is measured, and the organization decides how to meet it.
Which assets, admin paths and teams fall under Safeguard 4.6
Safeguard 4.6 applies to every enterprise asset and piece of software the organization runs, and to every path used to administer them. The scoping choices below decide which inventories, configurations and access records an assessor will ask to see, so settle them before collecting evidence.
Servers and virtual machines
Physical servers, virtual machines and container hosts are the core of this Safeguard, because their configuration is most often managed through infrastructure as code. Confirm whether build templates, configuration management repositories and golden images are in scope, and whether each one is tracked in version control with a reviewable change history. An assessor will typically ask which hosts were built from which version of the code, so a host that was configured by hand needs its own documented exception.
Network devices and appliances
Switches, routers, firewalls, load balancers and security appliances often have management interfaces that are easy to overlook. Record each device's management protocol, and confirm whether it is reached over SSH or HTTPS and whether Telnet or plain HTTP remains enabled for any reason. Vendor appliances that cannot accept infrastructure as code usually need a documented, exported configuration baseline that is stored and reviewed like code.
Hypervisors and cloud control planes
Hypervisor management consoles and cloud control planes, such as the administrative APIs and consoles of your cloud accounts, can change every asset beneath them. Treat them as enterprise assets in their own right, and confirm that administrative access to them uses secure protocols and that their settings are defined in version-controlled templates where the platform allows it. Cloud configuration drift is a common finding, so ask how changes made outside the pipeline are detected.
End-user devices and IoT
Laptops, desktops, mobile devices and IoT equipment such as cameras, sensors and badge readers are enterprise assets that are frequently managed through different tools than servers. Decide which of these your organization manages centrally and which it does not, and document the boundary. An assessor will check that managed devices show a secure configuration and that unmanaged or unsupported devices are recorded, with the reason they cannot be managed securely.
Packaged and in-house software
Packaged products, open-source components and software your teams build all need secure management of their configuration, including default settings, enabled services and administrative interfaces. Separate the software you buy from the software you build, because the evidence differs: vendor hardening guidance and configuration exports for packaged products, and repository history and build pipeline records for in-house code. Confirm that both are present in the software inventory that Safeguard 2.1 requires.
Third-party administrators
Managed service providers and outsourced administrators often hold the most privileged paths into your assets. Include their tooling, jump hosts and remote sessions in scope, and confirm that they reach your systems over secure protocols and their activity is traceable. Contracts should state which of their administrative actions must be recorded and who approves configuration changes they make. Ask for their access logs and change records as part of the evidence set.
How an assessor tests Safeguard 4.6 coverage
This table compares what an assessor does for each part of Safeguard 4.6, what evidence they request and where organizations usually fall short. Read it as a preparation checklist: the prerequisite inventories must be reliable before the coverage metric means anything. Exact measure wording comes from the CIS Controls Assessment Specification, so confirm it there before you build tests.
| Test area | Test approach and evidence requested | Common findings |
|---|---|---|
| Prerequisite: asset inventory (1.1) | Reconcile the enterprise asset inventory against the scope the assessor is testing. Request the inventory export, its last update date and the discovery method used to build it. | Inventory lists devices that were retired, or misses cloud instances and virtual machines that were created outside the normal process. |
| Prerequisite: software inventory (2.1) | Confirm the software inventory covers the operating systems, management agents and administrative tools that manage each asset. Request the export and the process for adding new software. | Administrative tools and network appliance firmware are absent, so administrative access paths cannot be checked. |
| Prerequisite: secure configuration process (4.1) | Read the documented secure configuration process and check that it names how administrative access is set up and reviewed. Request the most recent review record. | Process exists but does not mention protocols, or the review is overdue and no one can show the last sign-off. |
| Configuration as code history | Select a sample of managed assets and trace their configuration to version-controlled infrastructure as code. Request repository access, commit history, approval records and the deployment log for each sampled asset. | Changes are made by hand on the device, so the running configuration differs from the repository. Commits lack reviewers or approvals. |
| Administrative sessions and protocols | Sample administrative sessions from logs or bastion records and confirm they use SSH or HTTPS. Request the service configuration showing which protocols are enabled on each sampled asset. | Management interfaces accept connections over unencrypted channels, or shared administrator sessions cannot be tied to a named person. |
| Telnet and HTTP exceptions | Scan a sample of assets for listening Telnet and HTTP services. For each hit, request the written operational justification, the compensating controls and the approval record. | Legacy devices keep Telnet enabled with no recorded exception, or the exception has no owner and no review date. |
| Reconciling inventory against managed assets | Compare the asset inventory with the list of assets under configuration management and with the assets that report to the management platform. Investigate every asset that appears in only one list. | Unmanaged assets are excluded from the coverage calculation, which inflates the reported result. |
| Coverage metric | Recalculate the coverage figure from the raw measure results, not from a summary slide. Confirm each of the five measures is defined in the Assessment Specification and that the combined result matches the sampled data. | Coverage is reported as a single percentage with no measure breakdown, so the assessor cannot tell which measure drives the gap. |
Evidence that shows Safeguard 4.6 is met and how to keep it current
An assessor testing Safeguard 4.6 looks for proof that administration is managed, not just described. The cards below cover the artifacts that carry that proof and the routine checks that keep each one current between assessments.
Infrastructure as code history
Repository history of infrastructure as code is the strongest evidence that asset configuration is managed deliberately. Assessors look for commits tied to reviewed pull requests, approvals from someone other than the author, and no direct changes to production that bypass the repository. Export the branch protection settings and review log at each assessment cycle, and confirm that drift between repository and running systems is detected and reconciled, not silently accepted.
Configuration baselines per asset class
Baselines show what a secure configuration looks like for each asset class: devices, software, data, users, network and documentation. Keep one baseline per class with a named owner and a review date, and map each baseline to the asset inventory from Safeguard 1.1 and the software inventory from Safeguard 2.1. Ask whether every asset in the inventory is assigned to a baseline, because unassigned assets are where measurement gaps appear.
Administrative protocol settings
Configuration exports showing that administrative interfaces use SSH or HTTPS, and that Telnet and plain HTTP are disabled, are direct proof for the protocol part of Safeguard 4.6. Schedule an export of these settings from routers, hypervisors, servers and management consoles, and compare the results against the baseline. A setting that changed after an upgrade is a common finding, so the comparison should run after each patch cycle as well as on a fixed schedule.
Documented exceptions for Telnet and HTTP
Where Telnet or HTTP is operationally essential, the exception record should name the asset, the protocol, the business justification, the compensating controls such as network segmentation, the approver and an expiry date. Assessors reject open-ended exceptions. Review every exception before its expiry, retire it where the dependency is gone, and renew it only with fresh justification and approval.
Scan and query results over time
Configuration scan results show whether assets meet their baselines, and a trend of results across assessment periods shows coverage. The CIS Controls Assessment Specification measures Safeguard 4.6 through five measures combined into one coverage metric, so keep dated results for each period rather than only the latest run. Open-source tools such as Wazuh Security Configuration Assessment and Fleet policies can produce these results. Confirm which checks each tool runs against your baselines, because default policies do not cover every custom setting.
Implementing Safeguard 4.6 in six steps
This sequence turns Safeguard 4.6 from a policy statement into measurable evidence: every managed asset is known, configured through a documented process, built from version-controlled code, reached only over secure protocols, and checked for coverage with any insecure exceptions tracked to an end.
Confirm the asset and software inventories
Before anything can be measured, the organization needs a current list of its enterprise assets and installed software. Safeguards 1.1 and 2.1 are prerequisites for Safeguard 4.6 because the coverage measurement is taken against these populations. The asset owner or IT operations lead reconciles the inventories against discovery results and cloud account listings, then records which assets are in scope for administration. The output is a signed-off inventory with a named owner for each asset class, including the Devices and Software classes that Safeguard 4.6 covers. Done means an assessor can pick any device from the network and find it in the list.
Establish the secure configuration process
Safeguard 4.1 defines the documented process that tells administrators how each asset type should be configured and how that standard is reviewed. The security function or platform engineering lead writes or confirms this process, covering end-user, server, network and cloud assets, and gets it approved by the accountable owner. Safeguard 4.6 depends on it because the secure management practices must be the ones this process names. The output is an approved, dated configuration process with a defined set of baseline configurations for each asset type, ready to be referenced by the infrastructure code in the next step.
Move configuration into version-controlled infrastructure as code
Configuration that lives only in consoles or in an administrator's memory cannot be reviewed or reproduced. The platform engineering team expresses the approved baselines as infrastructure as code, stored in a version control system with access restrictions, peer review of changes and a record of who changed what. Drift detection or a configuration scanner, such as Wazuh Security Configuration Assessment, can then compare running systems with the baselines. The output is a repository with the baselines for each asset type, a documented change path, and a first scan showing which assets match the code.
Restrict administrative access to SSH or HTTPS
Administrative interfaces are where most configuration changes happen, so their transport matters. The infrastructure team enables SSH or HTTPS for every management interface, disables plaintext alternatives where the platform allows it, and limits administrative sessions to authorized administrator accounts from approved management networks. The network and identity teams confirm these settings with the owners of the assets. The output is a list of management interfaces with their protocol, the change that enforced it, and a test showing that a plaintext connection attempt fails on each.
Document and time-limit any Telnet or HTTP exception
Some legacy equipment or vendor appliances can only be administered over Telnet or HTTP. Safeguard 4.6 allows these protocols only where they are operationally essential, so each one needs a written justification, the business owner who accepts the risk, compensating controls such as network segmentation or restricted source addresses, and a retirement date set by that owner. The security function reviews the exception register and rejects entries that do not meet the test. The output is an exception register in which every Telnet or HTTP path has an owner, a reason, a compensating control and a review date.
Measure coverage and review exceptions
The Safeguard 4.6 assessment specification measures coverage through five measures combined into one metric, so the reader should collect evidence for each of them and not rely on a single dashboard. The security operations team runs recurring checks, for example Wazuh configuration assessments or Fleet policies that ask devices yes or no questions, and records the share of in-scope assets that pass the secure management checks. Each failing asset is either remediated or added to the exception register. Done means a dated coverage report, reviewed by the accountable owner, that an independent assessor can trace back to the inventory and the code repository.
What meeting Safeguard 4.6 costs in money and effort
The table separates each cost component of meeting Safeguard 4.6 by who is paid, whether the cost is one-time or recurring, what drives it, and how to keep it down. Use it to build a written scope and to compare quotes line by line, since no fixed price or duration applies across organizations.
| Cost component | One-time or recurring | What drives it and how to keep it down |
|---|---|---|
| Tooling and licenses | Recurring (where commercial) | Commercial configuration management, endpoint or compliance scanners are priced per device or per seat, so asset counts drive spend. Self-hosted open-source options such as Wazuh (GPL-2.0-only) and Fleet (MIT) remove license fees, though hosting and staff time remain. Confirm current licensing and support terms directly with each vendor. |
| Engineering time to codify configuration | One-time, with ongoing change effort | Time goes to writing infrastructure as code for each platform, reviewing it and bringing legacy systems under version control. Keep it down by starting with the asset classes that matter most and reusing modules across similar systems. Ask any implementation partner for the hours or days assumed per platform in the written scope. |
| Migration of administrative access to SSH or HTTPS | One-time | Cost rises with the number of devices and applications still using Telnet, HTTP or shared administrator logins, and with any appliance that cannot change its management protocol. Inventory these early (Safeguards 1.1 and 2.1 produce the data), and record any exception with a documented business reason. |
| Evidence upkeep | Recurring | Each configuration change, policy result and exception needs to be retrievable for the assessor. Costs grow with the frequency of changes and the number of systems. Keep it down by generating evidence automatically from the version control history and scanner reports rather than by manual screenshots. |
| Policy and compliance scan results review | Recurring | Someone must review failing checks, decide remediation or accept risk, and track closure. Effort depends on the number of failing findings and how many false positives the policy set generates. Tune policies once to the environment, and set a fixed review cadence. |
| External testing or independent review | Periodic, when purchased | Optional third-party review of the configuration baseline or a penetration test that confirms insecure services are not reachable. Scope is set by the number of externally reachable systems and the depth requested. Ask for the scope, deliverables and retest terms in writing. |
| Auditor or assessor sampling | Periodic, per assessment | Assessors sample systems and ask for proof that the configuration process and protocol restrictions operate over the review period. Cost is driven by sample size, the number of asset classes in scope and how cleanly evidence is organized. Prepare an evidence index before fieldwork starts. |
| Internal staff time for ownership and exceptions | Recurring | Named owners must approve exceptions to Telnet or HTTP use, review baseline changes and respond to drift alerts. This is often the largest hidden cost. Reduce it by limiting exceptions to documented operational necessities and by defining clear approval paths. |
Using Wazuh and Fleet to produce configuration evidence
Safeguard 4.6 is shown by evidence that managed assets are configured and administered securely, not by a policy document alone. Wazuh and Fleet both check endpoints against defined settings, and their output can feed the coverage metric in the CIS Controls Assessment Specification. Each card below covers one part of that evidence chain and one check to make before relying on it.
Wazuh configuration assessment scope
Wazuh Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies. Its policies check files, directories, registry keys and running processes, and it recommends remediation for each failed check. For Safeguard 4.6, the scan result shows whether administrative settings on each asset match the approved baseline. Confirm that the policies in your version cover the platforms in your inventory, because coverage gaps appear as unmeasured assets.
CIS-based and custom policies
Wazuh ships its policies mostly based on CIS benchmarks and lets you extend them with custom policies. Organizations usually add checks for their own administrative standards, such as disabling Telnet listeners or requiring SSH for remote administration. Document each custom check, its owner and its rationale, because an assessor will ask why a check exists and who approved it. Treat the shipped policies as a starting point, not as proof that your configuration meets Safeguard 4.6.
Fleet policies as yes or no questions
Fleet policies ask each device a yes or no question written as an osquery query, such as whether a service is listening on an insecure port. The policies page shows which devices in each fleet pass or fail each policy. This gives a per-device view that maps well to the coverage metric. Write each policy so the answer is unambiguous, and record which policy version was in force on the date of the assessment.
Insecure protocol checks
Insecure protocol checks are the clearest Safeguard 4.6 test in both tools. A policy can ask whether Telnet or an HTTP-only administrative interface is enabled on a device, and a failing result identifies the asset to fix. Record any exception for an operationally essential insecure protocol with its owner, business reason and compensating control. An assessor will expect the exception to be approved and reviewed, not simply ignored in the results.
Licensing and data handling
Wazuh is licensed under GPL-2.0-only and Fleet under MIT, and the license terms differ in what you must do when you distribute or modify them. Review those terms with your legal team before you embed either tool in a product or redistribute changes. Also confirm where scan and query results are stored, since configuration data can reveal internal architecture. Keep this review with the evidence file so the tooling decision is traceable.
Check capabilities against the measures
Before relying on either tool, compare its current capabilities against the five measures defined for Safeguard 4.6 in the Assessment Specification. Confirm which measures the tool can produce directly, which need a custom policy or query, and which must come from a manual process or other system. Verify this against the current release and documentation, because policy libraries and query coverage change over time. Record the result in a mapping table so the gap analysis is clear to your assessor.
Who owns Safeguard 4.6 and what is worth outsourcing
Your organization owns Safeguard 4.6 in full. That means deciding which asset classes and platforms the Safeguard covers, setting the administrative access standard, approving exceptions where Telnet or HTTP is operationally essential, and accepting the residual risk when a system cannot meet the standard. Those decisions cannot be delegated to a vendor or consultant, and the Safeguard's outcome is measured against the enterprise's own environment.
- Administrative access policy: Name the approved protocols (for example SSH and HTTPS) and the conditions under which any exception applies.
- Exception decisions: Record who approved each use of an insecure protocol, why it is essential, the compensating controls and the review date.
- Infrastructure as code ownership: Assign named owners for the repositories that hold configuration, and require review before changes merge.
- Operational follow-up: Own the remediation of failed checks and the schedule for re-testing.
- Measurement: Track the coverage metric defined for the Safeguard and report it to leadership.
Confirm that each of these responsibilities has a named individual and a written record before any outside party is engaged.
An implementation partner such as DeployOpen can help prepare the systems that make Safeguard 4.6 measurable, within a written scope agreed before work starts. Typical work includes writing configuration as code, building the administrative access paths, setting up scan policies and exporting evidence. The partner prepares and documents these artifacts, but it does not decide the policy, approve exceptions or certify the result.
- Configuration as code: Build and version-control the baseline for in-scope systems so that changes leave a history.
- Secure access paths: Configure SSH and HTTPS administration and disable Telnet and HTTP where the organization has approved that.
- Scan policies: Prepare checks, for example with Wazuh Security Configuration Assessment or Fleet policies, that report pass or fail per device.
- Evidence exports: Produce repeatable reports and runbooks that show how the controls were built and how they are checked.
- Handover documentation: Leave the organization able to operate and update the tooling without the partner.
Ask for the written scope to state which systems, repositories and tools are covered, and which outputs the partner will hand over. Any work outside that scope needs a new written agreement.
The independent auditor, assessor or certification body tests whether Safeguard 4.6 is implemented and effective. It is the only party whose conclusions about the control carry external weight. To keep that weight, the auditor must stay independent of the people who designed, built and operated the control, so it should not write the policy, configure the systems or produce the evidence it will then test.
- Independent testing: The auditor samples systems, reviews configuration and checks the evidence against the measures in the CIS Controls Assessment Specification.
- Evidence review: The auditor examines whether exports, change records and scan results are complete and trustworthy, not just whether they exist.
- Reporting: Only the auditor issues the report or certificate. Neither the organization nor a partner may issue one on its behalf.
- Boundary with consultants: Pre-assessment gap reviews are useful, but a firm that later audits the same controls it helped build needs its independence assessed first.
Confirm with the auditor, before engagement, how it manages independence and what it will accept as evidence.
Where Safeguard 4.6 programs usually fall short
Safeguard 4.6 is rarely missed in a single dramatic failure. It usually erodes through small gaps: an insecure protocol left open, a change made by hand, an inventory that drifts, an exception nobody revisits, and evidence that proves a moment rather than a period. Each card below names one gap and the check that closes it.
Insecure protocols without a documented exception
Administrative interfaces often still answer over Telnet or plain HTTP because a legacy device or old appliance was never migrated. Safeguard 4.6 expects these protocols to be avoided unless they are operationally essential, so an open Telnet port with no recorded justification is a finding. Scan administrative ports across the asset inventory, then either move each service to SSH or HTTPS or record a named exception with an owner, a reason and a review date.
Configuration changed by hand
An engineer who fixes a failing server directly on the host creates a configuration that exists nowhere in the repository. The running system then passes review while the version-controlled definition describes something else, and the next deployment silently reverts the fix. Check whether production drift is detected, for example by comparing running state against the infrastructure as code, and whether emergency changes are back-ported to the repository within a defined window.
Inventories that miss assets and software
The coverage measure for Safeguard 4.6 is only as accurate as the asset and software inventories it depends on. Safeguards 1.1 and 2.1 feed the measurement, so a device that never reached the inventory, such as a network appliance, a cloud instance or a developer laptop, is invisible to the metric. Reconcile the inventory against discovery sources and agent check-ins, and confirm the denominator of the coverage figure includes everything in scope.
Exceptions that never expire
Temporary waivers for legacy systems tend to outlive the projects that justified them. A waiver recorded in a spreadsheet with no end date becomes a permanent weakness that auditors discover later. Give every exception an owner, a compensating control, an expiry date and an approver, and track open exceptions as a list that someone reviews on a fixed cycle. Expired exceptions should appear as failures in the coverage report, not disappear from it.
Point-in-time screenshots as evidence
A screenshot of a compliant console taken during preparation proves one moment only, and assessors ask whether the state held across the period under review. Screenshots also show nothing about devices outside the frame. Prefer exported, timestamped results from continuous checks, such as policy pass and fail counts per device over time, and keep the configuration files and change history that explain why the state exists.
Admin access without a secure path
Administrators sometimes reach hosts through shared accounts, password-only logins or a jump host that accepts unencrypted sessions, which weakens the secure administration Safeguard 4.6 describes. Confirm that every administrative path uses SSH with key-based authentication or HTTPS, that the management interfaces are restricted to designated administrative networks, and that session logs can be tied to a named person.
How much effort does Safeguard 4.6 take, and can we do it ourselves?
What does Safeguard 4.6 need from our team day to day?
Safeguard 4.6 needs an owner who controls how enterprise assets and software are administered, plus engineers who can keep that administration consistent. The work centers on three things: keeping configuration in version-controlled infrastructure as code, reaching administrative interfaces over SSH or HTTPS, and disabling Telnet and HTTP wherever they are not operationally essential. Expect platform engineers and system administrators to do most of the configuration work, with a security lead defining which exceptions are acceptable and who approves them. Each exception needs a documented reason, which is often the part that takes the most coordination across teams.
How long does it take to reach evidence for Safeguard 4.6?
The duration depends mostly on how far your asset and software inventories and secure configuration process already exist, because the CIS Controls Assessment Specification lists Safeguards 1.1, 2.1 and 4.1 as prerequisites for measuring Safeguard 4.6. If those are missing, that groundwork usually sets the timeline. Confirm with your implementation partner or internal team which prerequisites are in place, how many environments need remediation, and how many legacy systems depend on Telnet or HTTP. The CIS Controls Assessment Specification defines five measures for this Safeguard, combined into one coverage metric, so ask how each measure will be sourced and tracked.
Can our own team implement Safeguard 4.6 without outside help?
Often yes, if you have staff who already manage infrastructure as code and secure remote administration, and you have a clear inventory of assets and software. Outside help is most useful where the estate is mixed, where legacy devices cannot accept SSH or HTTPS, or where the team lacks time to write the exception process and evidence set. Ask yourself whether the same people who make changes can also produce independent proof of them. An external partner can prepare systems and evidence, but only an independent auditor or certification body issues assessment reports or certificates, and your organization keeps ownership of its controls.
What should we ask a partner to include in a quote for Safeguard 4.6?
Ask for a written scope that names the asset classes, environments and software in play, and the specific systems where Telnet or HTTP will be disabled or formally excepted. The quote should list deliverables, such as the infrastructure as code repository structure, administrative access standards, exception register, and evidence collection method, plus who performs each task and what you must provide. Confirm whether the work is one-time or recurring, what ongoing monitoring or retainer support is included, and how changes after go-live are handled. DeployOpen works from written, fixed scope with timelines agreed before work starts, so ask for the same clarity from any provider.
Do open-source tools satisfy Safeguard 4.6 on their own?
No tool satisfies a Safeguard by itself. Tools produce the evidence, but the organization must define the policy, the exceptions and the operating process. For configuration drift, Wazuh's Security Configuration Assessment checks endpoints against YAML policies, mostly based on CIS benchmarks and extendable with custom policies, and reports remediation steps. Fleet policies ask yes or no questions of devices as osquery queries and show which devices pass or fail each policy. Confirm with each vendor that a given check covers the specific protocol or service settings you need, and map tool output to the five CIS measures before relying on it.
What will the auditor check for Safeguard 4.6, and what will they not do?
An independent assessor will check whether the configuration is managed through version-controlled infrastructure as code, whether administrative access uses secure protocols, and whether insecure protocols are disabled or justified as operationally essential. They will look for records of exceptions, approvals and sampled evidence. They will not design your controls, write your policies, configure your systems or certify the Safeguard on your behalf. Only an independent auditor or certification body issues reports or certificates. CIS also notes that its Controls do not replace any regulatory or compliance scheme, so confirm which framework your auditor is testing against.
How DeployOpen works on this
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, so Safeguard 4.6 is met with configuration and evidence that your team owns. We prepare the systems and records an assessor will sample; the organization decides its own control design, and only an independent auditor or certification body issues reports or certificates.
How we scope
- Confirm which enterprise assets and software fall under Safeguard 4.6 and which prerequisite inventories from Safeguards 1.1, 2.1 and 4.1 exist
- Agree which infrastructure as code repositories, administrative interfaces and protocols are in scope, and which legacy Telnet or HTTP uses need documented justification
- Record the scope, deliverables and timelines in writing before work starts, since most engagements are fixed-scope
How we build
- Place device and server configuration under version control so changes to administrative settings are reviewable and traceable
- Restrict administrative access to SSH and HTTPS, and document each approved exception to insecure protocols as operationally essential
- Configure policy checks, such as Wazuh configuration assessment or Fleet policies, to report pass or fail results per device against the agreed baseline
How we hand over
- Deliver the configuration repository, baseline definitions, exception register and check results mapped to the five CAS measures for Safeguard 4.6
- Document how the evidence is produced, who reviews it and how often, so your team can repeat the measurement without us
- Confirm with your assessor which artifacts they will sample and agree the evidence format before the assessment window opens
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer if your team wants help keeping baselines and evidence current
- Review configuration drift and new exceptions against the written scope when platforms are upgraded or new assets are added
- Hand back ownership of repositories, runbooks and dashboards so the control remains operated by your own staff
