What Safeguard 4.8 asks for and why unused services matter
Safeguard 4.8 asks your enterprise to remove or switch off the services that its assets and software do not need. CIS's examples include a file sharing service nobody uses, an unneeded web application module or a service function that serves no current purpose. If you have been asked to show evidence for this Safeguard, the test is not whether you hardened a server once, but whether you can show that every running service on each in-scope asset is one someone can justify, and that the rest are gone or disabled. Each unused service is an entry point an attacker can probe, and it often runs with its own patch cycle, default settings and listening ports that nobody reviews. A forgotten file share or a sample web module can expose more than its owner intended long after the project that installed it has ended. CIS places Safeguard 4.8 in the Devices asset class and the Protect security function, and assigns it to Implementation Groups 2 and 3, not IG1. That means an IG1 enterprise is not measured against it, although the habit it builds supports the Safeguards that are.
Two things usually make this Safeguard hard. The first is the absence of a current inventory of services across endpoints and servers, which is why the assessment specification lists Safeguards 1.1 (enterprise asset inventory) and 2.1 (software inventory) as prerequisites. The second is the lack of an agreed definition of "needed". Confirm with the system owners who decides that a service is required, how that decision is recorded, and how often it is revisited. CIS publishes mappings of this Safeguard to NIST SP 800-53 Rev. 5 CM-6 and CM-7, ISO/IEC 27001:2022 Annex A 8.9, SOC 2 CC6.3 and CC6.6, and PCI DSS v4.0 requirements 1.2.5, 2.2.4 and 6.4.1. Read those mappings as CIS's own cross-references, and check each framework's requirement text with your assessor before you rely on them.
Which assets, services and teams Safeguard 4.8 covers
Safeguard 4.8 applies to whatever the enterprise runs, so the scope is set by what exists, not by a fixed list. The cards below cover the asset classes, software, services and owning teams that change the amount of work, and the inventories that must come first.
Asset inventory as the starting point
CIS's Assessment Specification lists Safeguard 1.1, the enterprise asset inventory, as a prerequisite for measuring Safeguard 4.8. Without it, nobody can say which servers, workstations, network devices or cloud instances exist to be checked. Ask whether the inventory includes short-lived cloud workloads and devices that connect only through remote access, since those are the ones most often missing from scans. Confirm who maintains the inventory and how often it is reconciled against discovery results.
Software inventory and bundled modules
Safeguard 2.1, the software inventory, is the other prerequisite CIS names for this Safeguard. A service is often a component of a larger package, such as a web application module, a database feature or a management agent that ships with an operating system image. Scope should list the installed software and its bundled modules, not just the product names, so that an unused module is not overlooked. Check whether the software inventory records versions and installed components.
Servers, containers and cloud workloads
Servers and cloud workloads usually carry the largest number of listening services, often inherited from a base image. Containers and virtual machine images can carry unused daemons into every deployment built from them. Scope should cover images, templates and infrastructure as code, not only running hosts, so that a fix is applied at the source. Ask which team owns each golden image and whether a change there propagates to running instances.
End-user devices and print, file sharing and remote access
Workstations and laptops often run file sharing, print spooling, remote desktop or legacy discovery services that users enabled and forgot. These services are the examples CIS gives for Safeguard 4.8, such as an idle file sharing service. Scope should separate what IT deploys from what users enable locally, because a policy check that only reviews the build image will miss the second group. Confirm which team handles end-user device exceptions.
Network devices and management agents
Network devices, firewalls and appliances expose management interfaces and vendor services that may not be covered by the server baseline. Vendor management agents on any asset can also run services the enterprise never requested. Scope should name these platforms explicitly, with an owner for each, because they are often administered outside the team that owns servers. Ask the vendor or the network team which services are required for vendor support and which can be disabled.
Owners and the regulated data boundary
Each platform needs a named owner who can approve disabling a service and accept the risk of breaking a dependency. IG2 and IG3 scope may be wider or narrower than the boundary of regulated data, so an asset outside the regulated environment may still be in Safeguard 4.8 scope, and the reverse is also possible. Document the scope decision, the owner and the reason for each asset class so that an auditor can trace it to the inventories.
How an assessor tests Safeguard 4.8 against the CIS assessment specification
This table sets out what an assessor does, the evidence they request and the findings they commonly raise when testing Safeguard 4.8. The Assessment Specification defines six measures combined into two metrics, compliant and non-compliant services, but it does not prescribe how to produce them, so assessors focus on how the service list was built and how exceptions are governed.
| Assessor action | Evidence requested | Common finding |
|---|---|---|
| Confirm the service baseline comes from the asset inventory (Safeguard 1.1) and software inventory (Safeguard 2.1) | Current asset and software inventory exports, with the date each was last reconciled | Service list built from a one-time scan with no link to the inventories it depends on |
| Ask how the organization produced the list of running and installed services on each in-scope asset | Service enumeration output per asset class, such as Devices and Software, and the method and date used | Service list maintained by hand and missing services added by later deployments |
| Ask how each service was judged needed for its asset's function | Documented business or technical justification for each retained service, linked to an owner | Services kept by default from the build image with no stated purpose |
| Sample assets and compare their running services with the approved list | Sampled service listings, with any service outside the approved list flagged as non-compliant | Idle file sharing, print or remote services still listening after the project or pilot that needed them ended |
| Check whether unused web application modules, plug-ins and service functions are disabled, not only installed | Application module configuration and disabled-state settings for the sampled applications | Modules removed from menus but still loaded, or left enabled in the application configuration |
| Test how exceptions are approved, recorded and reviewed | Exception register showing the service, the approver, the reason, an owner and a review date | Exceptions granted verbally, with no owner, no expiry and no review date |
| Verify that removals and disablements are repeatable across rebuilds and new assets | Hardened build or configuration standard and a change record for a recent removal | Services re-enabled by a rebuild or vendor update that was never checked against the approved list |
| Calculate the compliant and non-compliant service counts for the sampled population | Metric worksheet showing compliant services and non-compliant services by asset | Counts that cannot be reproduced because the underlying listings were not retained |
How service inventory, baselines and exceptions fit together
An auditor testing Safeguard 4.8 will expect a loop, not a one-time clean-up. The loop starts with a current list of running and installed services for each enterprise asset, built from the device inventory under Safeguard 1.1 and the software inventory under Safeguard 2.1. The CIS assessment specification treats those two inventories as prerequisites because they supply the data the measurement needs. If the asset list is incomplete, a service on an unlisted host never gets compared with anything, so the inventory is the first thing to confirm before any hardening claim is made.
Next, the organization writes a baseline for each role. A baseline states which services a web server, database host, domain controller or engineering workstation actually needs, and which must be off. This is where the Safeguard's point about function matters: a service can be legitimate software and still be unnecessary on a host that does not use it. A print spooler or a web application module may be correct on one role and an unused attack surface on another. Tools such as Wazuh's Security Configuration Assessment or Fleet's policies can then compare running services against that baseline, and the result should be retained as dated evidence rather than a screenshot taken for the audit.
Every deviation needs a recorded exception path. When a business owner must keep a service that the baseline would disable, the exception should name the service, the asset, the reason, the compensating controls, the approver and a review date. Reviewing exceptions on a schedule the organization sets, and removing those that no longer have a reason to exist, is what turns the baseline into a control. Organizations should confirm with their assessor how they want exceptions documented and how long they may stay open before a formal risk acceptance is required.
How to implement Safeguard 4.8 in six steps
This sequence turns Safeguard 4.8 from a general hardening goal into a measured, owned and repeatable practice, with each step producing a record that an assessor can trace from the inventory to the exception.
Confirm the asset and software inventories
Start by checking that the enterprise asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1) are current, because the CIS Controls Assessment Specification treats both as prerequisites for measuring Safeguard 4.8. Assign an owner to each inventory and confirm that it covers the in-scope Devices, including servers, end-user devices and network-attached systems. The output is a reviewed inventory extract with a named owner and a stated scope, which becomes the population every later check runs against.
List running services by asset class and role
For each asset class and role in the inventory, record which services are listening or running, such as file sharing, print, remote administration, web application modules and service functions. Tools that query installed packages, enabled service units and open ports can produce this list, but the review must be done by someone who knows what each role is for. The output is a service register that maps each asset group to its services, so that unused functions are visible rather than assumed.
Define a needed-services baseline per role
Write a baseline for each role that names the services it requires and the reason for each one, and assign an owner accountable for keeping it current. Anything not on the baseline is a candidate for removal. The baseline document should be approved by the business and technical owners of the systems it covers. Confirm that the baseline aligns with the secure configuration process defined under Safeguard 4.1, since that process is the document that governs how the baseline is set and changed.
Disable or remove unneeded services through change control
Turn off or uninstall services that fall outside the baseline using the configuration management process established for Safeguard 4.1, not through ad hoc changes on individual hosts. Each change should be recorded with the asset, the service, the reason, the change author and the approver. Test the change where the platform allows it, and confirm the service is not required by a dependency. The output is a change record for every disabled or removed service, which provides the evidence that the Safeguard was acted on.
Run recurring checks against the baseline
Schedule recurring checks that compare the running services on each asset with the approved baseline for its role, and record the results. Configuration assessment tools can flag services that are running but not on the baseline, and vulnerability scanners can report exposed services that should have been removed. Reconcile any mismatch with the change record or open an exception. The output is a dated check result for each asset group, which is the evidence an assessor will sample to test whether the baseline is maintained.
Route exceptions through documented approval
Where a service must stay on an asset but is not in the baseline, record it in an exception register with the business justification, the compensating measures, the approver and a review date. Exceptions should be reviewed on the schedule set in the register, and expired exceptions should trigger either removal or re-approval. The output is a maintained exception register that shows every deviation from the baseline was decided by an accountable person, which closes the loop on the Safeguard.
Evidence that passes a Safeguard 4.8 review
Safeguard 4.8 is verified through records that show which services run, which ones were justified, and which were removed or disabled. The cards below cover the artifacts an assessor is likely to request and how to keep each one current between audits, so the evidence reflects the environment as it is today.
Per-asset service inventory export
A timestamped export listing every running and enabled service on each enterprise asset, pulled from the endpoint management or configuration tool. The assessor checks that the export covers the full asset inventory from Safeguard 1.1 and that the timestamps fall within the audit period. Schedule the export on a fixed cadence and retain the raw files, so a gap in the record is visible rather than hidden. Confirm that the tool reports services on servers and end-user devices alike.
Needed-services baseline with approver
A written list of the services each asset class is permitted to run, with the business or technical reason for each entry and the name of the person who approved it. Assessors compare the inventory export against this baseline to separate compliant services from non-compliant ones. Store the baseline in version control so every change has an author, a date and a reviewer. Ask who signs off when a service is added, and confirm that the approver has the authority to accept the risk.
Configuration and change records
Tickets, change requests and configuration logs that show a service was stopped, disabled, uninstalled or removed from an image. These records prove the action was taken on purpose and was not simply absent from a snapshot. The assessor looks for the link between a removed service and the baseline entry that required its removal. Keep the change identifier in both the ticket and the configuration repository, and confirm that hardened golden images are rebuilt through the same process.
Recurring compliance scan reports
Scheduled scans that test each asset against the needed-services baseline or an accepted hardening benchmark, and report services that should not be running. Open-source tools such as Wazuh Security Configuration Assessment can run policy checks on monitored endpoints, and Fleet policies can report which devices pass or fail a yes or no query about a service. The assessor checks that scan results are dated, that failures were triaged, and that the scan scope matches the inventory. Ask whether scan frequency and coverage are documented.
Exception register with owners and dates
A register of services that must remain running even though they are not in the baseline, each with a named owner, a documented justification, a compensating control and a scheduled review date. Assessors treat this register as the proof that exceptions are governed rather than tolerated. Review the register on a fixed cycle, remove entries when the service is retired, and flag any exception whose review date has passed. Confirm the review cycle with the auditor before the assessment begins.
Service-to-asset and software records
Links that tie each running service to the software record that installs it and the asset record that hosts it. This chain lets an assessor follow a single service from the inventory to its owner and its justification. It depends on Safeguard 2.1 software inventory data, so gaps in that inventory will appear here as services with no traceable owner. Maintain the links through the CMDB or inventory platform, and run a periodic check for services with no software or asset match.
What meeting Safeguard 4.8 costs in money and effort
This table compares the main cost components of meeting Safeguard 4.8, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a written quote, since the largest costs are usually staff time for the service baseline and the evidence that follows from it, not the scanner licenses. Open-source tooling can remove license spend, but the other rows still apply.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Tooling and licenses | Recurring if commercial, otherwise minimal | Commercial endpoint or configuration tools priced per device, plus support contracts; open-source options such as Wazuh, Fleet and Greenbone remove license fees but not hosting | Confirm the scanners already in use, prefer tools that cover assets you already run, and ask the implementer to state any licensing or subscription terms in writing |
| Engineering time to build the service baseline | One-time, with periodic revision | Number of asset classes, operating system and application variety, and how many services are in use before the review starts | Start from a documented asset and software inventory (Safeguards 1.1 and 2.1), use existing CIS Benchmark profiles as a starting point, and limit the first pass to in-scope assets |
| Service review and cleanup on live systems | One-time per asset group, then recurring for new services | Dependency checks with application owners, change windows, and the number of services that need a documented business reason before they stay enabled | Schedule reviews with owners in advance, record justifications once, and set a standing approval step for new services |
| Evidence upkeep | Recurring | Frequency of scans, how long results are retained, and the effort to match each measure in the CIS Assessment Specification to a report | Automate scheduled scans and exports, keep one evidence index per Safeguard, and agree the reporting format with the auditor before collection starts |
| External testing or independent review | Recurring, usually annual or after major change | Scope of the review, whether a third party checks the baseline, and whether penetration testing findings relate to unnecessary services | Limit the review to the highest-risk asset groups and reuse prior test results where the configuration has not changed |
| Auditor or assessor sampling | Recurring per assessment cycle | Number of assets and services the assessor selects, how complete the evidence is, and how many exceptions must be explained | Ask the assessor how they sample, keep the inventory current so samples can be traced, and document every approved exception before the assessment |
| Hosting for self-hosted tools | Recurring | Infrastructure size for the scanner or manager, data retention volume, and whether tools run in the client's own cloud accounts or data centers | Size the management server to the number of monitored endpoints and retention period, and confirm the hosting cost in the quote |
Open-source tools that produce Safeguard 4.8 evidence
Safeguard 4.8 asks for evidence that unneeded services are gone, which needs two things: a list of what each asset runs and a check that flags anything outside it. The four tools below cover different parts of that job, from configuration baselines to open ports and vulnerable packages. None of them decides which services the business needs, so that decision must come from the owner of each system.
Wazuh configuration assessment
Wazuh's Security Configuration Assessment scans monitored endpoints against YAML policies, largely based on CIS benchmarks, and checks files, directories, registry keys and running processes. For Safeguard 4.8, the useful checks are whether a listed service is running when the approved baseline says it should be off. Confirm each policy's rule set against your own baseline, because a policy that is not updated for your builds will report the wrong result. Wazuh is licensed GPL-2.0-only, so review the license terms with counsel if you plan to modify or redistribute it.
Fleet policies on device state
Fleet policies are yes or no osquery questions asked of each device, such as whether a given service is enabled, and the policies page shows which devices pass or fail. This gives a per-device record of disabled services that can be exported as evidence over time. Fleet is MIT licensed, which makes it straightforward to adopt, but test each query on a sample device first, since osquery results depend on the operating system and the query's table support.
Greenbone Community Edition scanning
Greenbone Community Edition runs the OpenVAS scan engine against target systems using the daily updated Community Feed. A scan shows which network services answer from outside their intended scope, such as file sharing or administrative web interfaces that should have been removed. Scan results show what is reachable, not why a service exists, so record an owner and a decision for every open service in the report. The engine is licensed AGPL-3.0-or-later, so confirm the obligations that apply if you modify it and offer it to users over a network.
Trivy vulnerability detection
Trivy detects known vulnerabilities (CVEs) in OS packages and language dependencies found in filesystems, Git repositories, virtual machine images and container images. For Safeguard 4.8, its value is in images: a web application module or package that is installed but unused still adds risk, so reviewing its findings can show components that should be removed from the build. Trivy is Apache-2.0 licensed. Confirm that the image scan reflects the final build, because a report on an older image does not show what is deployed.
Who owns Safeguard 4.8, who can prepare evidence and who issues the opinion
Your organization owns Safeguard 4.8. Someone in the business must decide which services each asset and piece of software needs, which ones are removed or switched off, and which exceptions are tolerated. Those decisions depend on operational knowledge that an outside party does not hold, such as which legacy integration still depends on a port or which web module supports a product line. The Safeguard is a Protect function requirement in the Devices asset class, so the accountable owner is usually the head of infrastructure or platform engineering, with the security team setting the standard.
- Service baseline approval: Named owners approve the list of permitted services per asset group and record who signed it and when.
- Risk acceptance of exceptions: Any service kept for business reasons needs a documented justification, a compensating control and a review date, approved by someone with authority to accept the risk.
- Change control: Services added after the baseline go through the same approval path, so the inventory and baseline stay current.
- Remediation ownership: Teams responsible for each asset fix non-compliant services and confirm the fix in the next scan.
- Annual review: Management confirms the baseline still reflects the business and the assets in scope.
Before engaging anyone, confirm that you can name an owner for each of these decisions, because a partner cannot approve an exception on your behalf.
An implementation partner such as DeployOpen can prepare the systems and evidence that let your organization measure Safeguard 4.8. That work is typically outsourced because it is technical and time-consuming: setting up the asset and software inventories that the assessment specification uses as prerequisites under Safeguards 1.1 and 2.1, configuring scanners, drafting baseline service lists for common operating systems and applications, and assembling evidence packs. The partner does not own the control, does not decide which services are needed, and cannot accept risk for you.
- Inventory setup: Building the asset and software data that the measurement depends on, in your environment.
- Tooling configuration: Deploying and tuning open-source checks such as Wazuh Security Configuration Assessment, Fleet policies and Greenbone scans, inside your own infrastructure.
- Baseline drafting: Producing draft service lists that your owners review and approve.
- Evidence assembly: Exporting scan results, policy pass and fail records, and change tickets in a form an assessor can sample.
- Documentation: Writing procedures that describe how the checks run and how exceptions move through review.
Ask any partner to state in writing which tasks it performs and which remain yours, and to confirm it will not sign off on the control.
An independent auditor, assessor or certification body tests whether Safeguard 4.8 is implemented and issues any report or certificate. Independence is the point: the assessor must not design, configure or approve the controls it tests, so an implementation partner cannot certify, attest or approve the result. CIS Controls content is used by many frameworks, and the assessor works from the framework that requires the evidence, using the CIS Controls Assessment Specification for the measurement logic where your engagement calls for it.
- Testing: The assessor samples assets, reviews the service baseline and checks scanner output against the stated measures.
- Evidence review: It evaluates whether the inventories, scans and exception records are complete and consistent.
- Opinion or report: Only the assessor issues the report, attestation or certificate that your customers or regulators receive.
- Independence limits: A partner that also performed the remediation may be restricted in what it can later assess, so confirm conflict rules with the assessor first.
- Scope agreement: Confirm the assessor's scope and sampling approach before the evidence is built.
Before hiring an assessor, ask which framework and version it will test against and what evidence format it expects.
Where organizations fall short on unnecessary services and how to close it
Most failures against Safeguard 4.8 come from process gaps rather than from a single service left running. The cards below cover the places where inventories, ownership, exceptions and checks break down, and what to put in place so the measurement holds up under assessment.
Inventory covers hosts, not services
Many teams know which servers exist but cannot list the services, ports and modules running on each one. Safeguard 4.8 is measured against the services on each asset, so a host list alone leaves the assessor with nothing to compare. Build the service view from the Safeguard 1.1 asset inventory and the Safeguard 2.1 software inventory, then record each listening service, its owner and whether the business still needs it. Confirm that the inventory includes services started by packages, not only those in the original build.
Services left after projects end
A pilot file share, a reporting service or a vendor agent often keeps running long after the project or contract that needed it has closed. Nobody is assigned to remove it, so it stays on the asset and keeps its attack surface. Add a decommissioning step to project close-out and vendor offboarding that names each service to remove or disable, and check the asset afterward. Ask the team to show the closing ticket for each service that was retired.
Default framework modules left enabled
Web frameworks, content management systems and application servers often ship with sample applications, administrative consoles and optional modules switched on. An unused module is still reachable code that an attacker can probe. Compare each installed module against the application's documented requirements, disable what the application does not call, and remove sample content from production. Record the justification for each module kept enabled so the decision can be traced during review.
Exceptions that never expire
A service kept running for a legitimate reason, such as a legacy integration, often gets an approval that has no end date. Over time the exception outlives the reason for it, and no one reviews whether it still applies. Give every exception an owner, a documented business reason, a review date and a compensating control such as network restriction. Ask for the exception register and check that each entry has been reviewed within its stated interval.
Baselines split across teams
When platform, application and database teams each maintain their own build standard, the same service may be enabled in one environment and disabled in another. No single owner can say which configuration is authoritative, so the measurement produces conflicting results. Assign one owner for each baseline, store it under version control, and map each baseline to the asset classes it covers. Confirm that the owner signs off changes to the list of permitted services.
Checks run once, not continuously
A service review done during a hardening project shows the state of the estate on one day only. Services are re-enabled by updates, reinstalls and emergency changes, and the drift goes unnoticed. Schedule recurring scans that compare running services against the approved list and alert on any unapproved service. Open-source tools such as Wazuh, Fleet and Greenbone can run these checks, but the organization must confirm which checks each one performs and keep the results as dated evidence.
Questions buyers ask about Safeguard 4.8 cost, effort and outside help
Can we disable unnecessary services in-house without an outside partner?
Yes, most organizations can do the work themselves, provided they have people who can read a service inventory, know which business owner depends on each service and can make changes safely. The control is owned internally in every case. The harder part is rarely the switch-off itself but establishing what is unnecessary. Safeguard 4.8 is measured against data from the enterprise asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1), so if those inventories are incomplete, the in-house team will spend most of its effort reconciling them before it can disable anything. Ask whether your team has capacity for that reconciliation, change approval and follow-up scanning across all asset classes in scope.
What drives the effort of disabling unnecessary services?
Effort rises with the number of assets and software packages in scope, how varied the operating systems and applications are, how many services are undocumented, and how many services have hidden dependencies on other systems. Each candidate service needs an owner to confirm it is not used, a test to confirm that disabling it does not break a dependent process, and a record of the decision. Effort falls when hardening baselines are already written, when inventories are current and when services are managed through configuration management rather than by hand. Ask a provider to show how it will group assets by type, how it will record decisions for each service and how it will verify that a change held after it was made.
What does the work need from our team?
The work needs three groups of people. Inventory owners confirm which assets and software exist and who is accountable for each one. Approvers, usually from application or service ownership and operations, confirm that a service is unnecessary before it is removed. A change process, with testing, rollback steps and a record of each change, carries the decisions into production. Security or compliance staff define the acceptance criteria and review the results. If any of these groups is missing, the work tends to stall at the approval step rather than at the technical step. Confirm in advance who signs off, how quickly they can respond and which change window your environment allows.
Can a partner build the baseline and scanning without owning the control?
Yes. An implementation partner can prepare the systems, baselines and evidence that Safeguard 4.8 relies on, while the organization keeps ownership of the control, its decisions and its risk acceptance. In practice, a partner might help define the service baseline for each asset type, configure a policy scanner or a query-based check, and set up reports that show compliant and non-compliant services over time. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, and it prepares evidence for assessments, but it does not issue audit reports or certifications. The organization still decides which services stay, and an independent assessor tests the result. Put the division of responsibilities in the written scope.
How long does this take, and why should we ask for a fixed-scope written quote?
No duration figure is supplied for this safeguard, so the reader should not expect one from this page. The timeline depends on the number of assets and software in scope, the state of the inventories, how many services need owner decisions and the change windows available. A fixed-scope written quote matters because it fixes the assets, deliverables, responsibilities and acceptance criteria before work starts, which makes it possible to compare proposals on the same basis. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing. DeployOpen does not publish a price list, so ask for a quote that states the asset classes covered, the platforms involved, what is one-time and what is a recurring retainer for ongoing scanning and support.
What happens at an assessment if an exception has no review date?
An assessor will normally treat a service that stays enabled without a documented reason as a finding, and an exception with no review date is weaker still because nothing shows that anyone will reconsider it. Expect the assessor to ask for the business justification, the named owner, the compensating measures in place, such as network restriction or monitoring, and the date on which the exception will be reviewed. Set a review date and an owner for every exception before the assessment, and keep the approval record with the scan results. Whether a particular exception is acceptable is a judgment for the independent assessor, not for the implementation partner, so confirm the expectation with your assessor early.
Which open-source tools can show whether unnecessary services are gone?
Several open-source tools can produce evidence for this safeguard, each covering a different part of it. Wazuh's Security Configuration Assessment checks monitored endpoints against YAML policies, mostly based on CIS benchmarks and extendable with custom policies, and it can recommend remediation. Fleet policies ask yes or no questions of devices as osquery queries, and its policies page shows which devices pass or fail each policy. Greenbone Community Edition runs vulnerability tests that can reveal exposed services, and Trivy detects known vulnerabilities in packages and images. Confirm that each tool covers your operating systems and the specific service checks you need, because tool capability alone does not decide whether a service is necessary.
How DeployOpen scopes and prepares Safeguard 4.8 evidence
DeployOpen works on Safeguard 4.8 as an implementation partner: we help the organization identify which services its assets and software do not need, switch them off in its own environment, and prepare the evidence an assessor will ask for. The organization owns the decision to disable each service, and only an independent auditor or assessor issues reports or certificates.
How we scope
- Agree in writing which asset classes, operating systems and platforms the Safeguard 4.8 work covers before any changes start.
- Confirm the Safeguard 1.1 asset inventory and Safeguard 2.1 software inventory exist, since they supply the data the measurement needs.
- Define which services are in scope, who approves each disablement, and which compliance frameworks the evidence must also support.
How we build
- Map running services and listening ports on each in-scope asset and record the business owner of every service that stays.
- Disable or remove unneeded services through version-controlled configuration, then test that dependent applications still work.
- Set up configuration checks, such as Wazuh policies or Fleet queries, that report compliant and non-compliant services over time.
How we hand over
- Deliver a documented service baseline per asset class, with the reason each retained service is needed and its owner.
- Provide scan and configuration check results that show the measures for compliant and non-compliant services.
- Document the change process and review cadence so the evidence stays current for the auditor or assessor.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
- Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
- Ask for a quote built from the written scope, covering asset count, platform variety and the number of checks to be automated.
