What Safeguard 13.7 host-based intrusion prevention requires in practice
Safeguard 13.7 asks an enterprise to deploy a host-based intrusion prevention solution on its enterprise assets where appropriate or supported, with an Endpoint Detection and Response (EDR) client or a host-based IPS agent given as examples. The point is that the endpoint agent must be able to block malicious activity on the host, not only record it. If your team is preparing for a CIS assessment or a customer questionnaire at Implementation Group 3, the first question an assessor will ask is which assets run the agent, and the second is whether the agent is configured to prevent rather than merely alert. The distinction from Safeguard 13.2 matters. 13.2 is the detect-only host safeguard, where a host-based intrusion detection tool logs and alerts on suspicious behavior. 13.7 raises the bar to prevention, so a sensor that reports an unauthorized process but lets it run does not satisfy the newer safeguard. Confirm with each vendor whether its agent can run in prevention or blocking mode for the specific detections you rely on, and document any detection categories kept in alert-only mode with a reason. The phrase "where appropriate or supported" makes scoping the hard part. Some assets, such as certain embedded devices, legacy operating systems or appliances, cannot run an agent, and the assessment specification measures coverage as the share of assets capable of supporting host-based intrusion prevention that have the software installed. That means you must first know which assets exist through the detailed asset inventory in Safeguard 1.1 and which software runs on them through the software inventory in Safeguard 2.1, then decide, asset class by asset class, what is capable of support. Record each exclusion with its justification so the denominator in your coverage figure can be defended.
Which assets, teams and tools fall inside Safeguard 13.7
Safeguard 13.7 is an IG3 control that sits on top of a known asset and software baseline. The cards below cover the scoping choices that change the work most: which device classes count, which endpoints can actually run a prevention agent, and who manages the systems that fall in scope. Settle these decisions in writing before anyone prices an EDR rollout.
Devices asset class scope
Safeguard 13.7 is assigned to the Devices asset class, so the first decision is which devices count as enterprise assets. Laptops, desktops, servers and virtual machines are the obvious members. Decide explicitly on kiosks, lab machines, point-of-sale terminals and shared workstations, and record the reasoning. An assessor will test coverage against the inventory you define, so an undocumented boundary becomes a finding.
Prerequisite asset and software inventories
The assessment specification lists Safeguards 1.1 (detailed enterprise asset inventory) and 2.1 (software inventory) as prerequisites for measuring 13.7. Without them you cannot compute the coverage share, because the denominator is unknown. Reconcile the asset inventory against endpoint management and directory records before scoping, and confirm that every device has a named owner.
Endpoints capable of running an agent
The Safeguard applies only where appropriate or supported, so separate endpoints that can host a prevention agent from those that cannot. Check vendor compatibility for each operating system build, kernel version and processor architecture, and record the endpoints that fail. Coverage is measured against assets capable of supporting the software, so the exclusion list must be justified, not convenient.
Servers and cloud workloads
Servers, container hosts and cloud virtual machines are enterprise assets too, and they often run prevention agents differently from user devices. Confirm whether the agent suits server workloads, whether it needs kernel-level access, and how it behaves on autoscaling groups that create and destroy instances. Treat ephemeral workloads as a separate scoping question, and document how new instances enroll before they receive production traffic.
Unsupported systems and appliances
End-of-life operating systems, embedded devices and network appliances frequently cannot run an EDR client or host IPS agent. These gaps do not disappear when excluded, so list each one with its compensating control, such as network segmentation or the detection safeguards in 13.2 and 13.3. Ask the vendor to confirm supported platforms in writing, because marketing lists and release notes can differ.
Contractor and third-party managed endpoints
Devices owned or administered by contractors, managed service providers or business partners raise two questions: who installs and maintains the agent, and who receives its alerts. Write these responsibilities into service agreements and check that the provider's agent meets the same coverage expectations. Control 15 covers provider oversight, and the evidence for 13.7 must include provider-managed endpoints when they connect to your network.
How an assessor tests 13.7 and what evidence passes
This table walks through how an assessor applies the CIS Controls Assessment Specification to Safeguard 13.7, from the inventories needed first to the sampling and tracing of prevention-capable assets. Read each row as a step in the assessment, the evidence the assessor will ask for, and the gap that most often causes a finding.
| Assessor step | Evidence requested | Common finding |
|---|---|---|
| Confirm prerequisite inventories exist | Current asset inventory from Safeguard 1.1 and software inventory from Safeguard 2.1, with dates and owners | Inventories are stale, incomplete or maintained separately from the asset population being tested |
| Establish the denominator of prevention-capable assets | Documented criteria for which enterprise assets can support host-based intrusion prevention, with the list of assets meeting them | Criteria are undocumented, so servers or endpoints are silently excluded or included without justification |
| Measure the Coverage metric | Agent deployment report showing installed host-based prevention software divided by prevention-capable assets | Report counts agents that have checked in once but not recently, or counts assets outside the inventory |
| Sample assets and trace each to agent records | For sampled hosts, the agent registration, installation timestamp and management console entry | Sampled host has no agent record, or the agent is registered to a different host name or image |
| Verify prevention mode, not only installation | Policy export showing block or prevent actions enabled, with exceptions listed and approved | Agents installed but running in detect-only or alert-only mode, which does not meet the prevention intent of 13.7 |
| Check exceptions and unsupported assets | Written justification for assets where prevention is not supported or not appropriate, and compensating controls | Exceptions are broad, unreviewed or cover systems that could have supported an agent |
| Review coverage over time | Deployment and remediation records showing how new and reimaged assets receive the agent | Cloud instances, containers or rebuilt images join the environment without the agent |
How to implement 13.7 in the order an assessor will check it
This sequence moves from the asset and software inventories that 13.7 depends on, through agent selection and a staged move from detection to prevention, to a documented exception process. Each step closes with an artifact an assessor can sample.
Confirm the asset and software inventories
Before measuring 13.7, confirm that the detailed enterprise asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1) are current, because the CIS Controls Assessment Specification lists both as prerequisites. The IT operations team owns the inventories, and security reviews them. Done means you can export a device list with operating system, owner and last-seen date, and a software list tied to those devices. Ask your auditor which inventory extract they will sample first.
Define which assets can support prevention
Classify each enterprise asset as capable or not capable of supporting a host-based intrusion prevention system. Capability depends on operating system version, hardware resources, vendor support for the agent and whether the device is a managed endpoint at all. Record the reason for each exclusion. The output is a capability baseline, the denominator for the Coverage metric the assessment specification uses for 13.7. Confirm the criteria with your security and infrastructure leads before you start deploying.
Select a prevention agent per platform
Choose an EDR client or host-based IPS agent for each operating system family in the capable population. Evaluate vendor support for each platform, the prevention actions the product can take, how it reports to a central console and where the telemetry is stored. If you run open-source components for monitoring, confirm with each vendor whether their agent can feed them. The output is an approved tool list per platform with the decision record, so an assessor can see why each product was chosen.
Set policy from detect to prevent
Deploy the agent in detection mode first, review what it would have blocked, and tune rules to remove false positives. Then move rule groups to prevention in stages, starting with the rules that have the lowest business impact. Record each policy change with the date, approver and reason. The output is a policy export from the console showing the current mode for each rule group, plus the change log. Ask vendors to confirm which actions their prevention mode can take on each platform.
Define and approve exceptions
Some assets will run software that conflicts with the agent, or will be unable to run it at all. For each case, write an exception with the affected asset, the reason, the compensating control, an owner and a review date. Route exceptions through the risk owner for approval. The output is an approved exception register. Assessors often test this register for stale entries, so schedule reviews and keep the approval trail.
Deploy the agent and verify coverage
Deploy the approved agent through your software distribution or configuration management tooling, then compare the console's list of reporting hosts against the capability baseline. Investigate every capable asset that is missing an agent, every agent that reports as stale or unhealthy, and every asset that lacks a matching exception. Osquery can run scheduled queries across the fleet to confirm that the agent process is running on each host, which gives you an independent check on the vendor console. The output is a coverage report that shows the Coverage metric against the baseline.
Document the exceptions process and evidence
Write the procedure that governs how the agent is deployed, how policy changes are approved, how exceptions are requested and reviewed, and how coverage is reported. Include the owner for each step and the frequency of coverage review. Keep the procedure, the coverage reports, the policy exports and the exception register together, so an assessor can trace one asset from inventory to prevention status. Confirm the review frequency with your internal audit or assessor before you commit to it in writing.
Evidence that proves host-based intrusion prevention is working
Safeguard 13.7 is only as credible as the records behind it. The cards below cover the artifacts an assessor will ask to see, from the coverage math against the asset inventory to the exceptions that explain every gap. Keep them dated and linked to each other, and the evidence will still hold between audits.
Coverage calculation against the asset inventory
The Coverage metric in the CIS Controls Assessment Specification is the share of assets capable of supporting host-based intrusion prevention that have the software installed. The denominator must come from the asset inventory required by Safeguard 1.1, and the numerator from the agent console. Check that both use the same asset identifiers and the same capability criteria, and that the calculation is saved with a date and a named owner. An unexplained gap between the two counts is the first thing an assessor will question.
Agent deployment and health reports
Export reports showing which endpoints run the EDR client or host IPS agent, the agent version, the last check-in time and whether the service is running. Stale check-ins usually mean an agent was removed, blocked or never installed on a rebuilt machine, so these reports show coverage that the install count hides. Ask the team to confirm how offline devices appear in the export and how long a device can be silent before it is flagged.
Policy exports showing prevention mode
An installed agent in detect-only mode does not satisfy a prevention requirement. Export the active policy from the management console for each device group and record which rules block rather than alert. Compare the export against the change history to confirm that no group was moved back to monitoring without an approved change. Confirm with the vendor which prevention features are available on each operating system, because support varies by platform.
Dated exception register with compensating controls
Where an asset cannot run host-based prevention, record it in an exception register with the asset identifier, the reason, the named owner, an approval date, a review date and the compensating controls in place, such as network filtering under Safeguard 13.4 or enhanced logging under Control 8. Unrecorded exceptions are the most common reason coverage figures fail review. Each entry should be reviewed on a fixed schedule and closed when the asset is retired or supported.
Sample alerts and blocked events
Keep a sample of prevented events with timestamps, host names, rule names and the action taken, and link each sample to the ticket or investigation that followed. Blocked events show that prevention works on real activity, while a short alert review shows that someone acts on what the tool reports. If the environment has few blocks, record a test detection run and its result, and label it as a test so it is not mistaken for production activity.
Scheduled exports and change records
Between audits, schedule the coverage calculation, agent health report, policy export and exception review to run on a fixed cadence, and store each output in a dated, write-protected location. Tie each policy or agent version change to a change record so that the evidence trail shows what changed, when and who approved it. Ask the platform team to confirm how exports are retained and whether the console keeps history that can be queried for past dates.
Open-source tools that support the 13.7 evidence
osquery exposes host state as SQL tables, and its osqueryd daemon runs scheduled queries across an entire fleet. For Safeguard 13.7, that makes it useful for building the Coverage evidence the assessment specification measures, which is the share of assets capable of supporting host-based intrusion prevention that actually have software installed. A scheduled query can also show whether the prevention agent is running, which helps you find hosts where it has stopped.
- Process and module visibility: Scheduled queries over running processes and loaded kernel modules show whether the agent process is present and healthy on each host.
- Network connection checks: Open network connection tables help confirm that hosts report and that unexpected outbound connections are visible.
- File hash records: Hash queries provide a repeatable record of binaries on monitored hosts, which supports later review.
- Fleet-wide scheduling: The osqueryd daemon runs the same queries on every enrolled host, so results can be compared across the fleet.
- Coverage reporting: Query results can be exported to a log platform and compared with the asset inventory from Safeguards 1.1 and 2.1.
Confirm which platforms your osquery build supports, which tables exist on each operating system, and how results will be stored and retained before you rely on them as evidence.
Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts that gather one or more artifacts across a group of systems. Hunts are useful when you need to confirm, across the estate, whether a prevention agent is installed, whether it is reporting, or whether a host shows the indicators that prompted an investigation. It does not block activity, so it supports verification and response rather than prevention itself.
- Artifact-based hunts: A hunt can collect the same artifacts from a defined group of systems, producing comparable results for each host.
- Offline machines: Hunts schedule collection on machines that are offline and run it when they reconnect, which matters for laptops and remote assets.
- Per-hunt notebooks: Each hunt gets a notebook for analyzing the combined results, which gives reviewers a working record.
- Custom artifacts: Teams can write their own VQL artifacts to check for the presence and configuration of a specific agent.
- Licensing: Velociraptor is licensed under AGPL-3.0-only, so review how that license applies if you modify or distribute the software.
Confirm the agent's blocking capability on each of your operating systems with the vendor of your prevention product, and check the license terms with your legal team before deployment.
Wazuh decodes collected logs and compares each event against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you write. Matching events become alerts written to alerts.log and alerts.json, and they are mapped to MITRE ATT&CK, so reviewers can see which technique an alert relates to. This gives you a record of detection activity on hosts, which supports the detect side of Control 13 that sits alongside prevention.
- Built-in rule coverage: The over 3,000 built-in rules and decoders give a starting point that you then tune to your environment.
- Custom rules: Rules for your own applications and agents can flag events such as the prevention agent stopping or reporting errors.
- Alert files: alerts.log and alerts.json provide machine-readable output for review and export.
- MITRE ATT&CK mapping: Alert mappings help analysts and assessors trace detections to techniques.
- Dashboard review: Alerts forwarded to the Wazuh indexer can be reviewed in the dashboard, which keeps a central record.
Wazuh is licensed under GPL-2.0-only. Confirm whether it can take prevention actions on your platforms, which is separate from its alerting function, and tune rules before counting alerts as evidence.
OpenSearch Security Analytics runs detectors that match ingested logs from hosts, network devices and cloud services against prepackaged or custom Sigma rules. Each match is recorded as a finding with its rule, log type and severity, and alerts can be sent to channels such as Slack or email. A correlation engine links findings across log types in a correlation graph, which helps reviewers connect host events with network or cloud activity.
- Sigma rule detectors: Detectors apply prepackaged or custom Sigma rules to ingested host logs, giving a portable rule format.
- Findings records: Each finding stores the rule, log type and severity, which supports review and reporting.
- Alert channels: Notifications can go to Slack or email so that findings reach the responsible team.
- Correlation graph: Links between findings across log types help analysts trace an event from the host to the wider network.
- Licensing: OpenSearch is licensed under Apache-2.0, which permits commercial use with its conditions.
Confirm which log sources your hosts send to OpenSearch and whether the Sigma rules you need are available in the Security Analytics release you deploy. Detection through this tool does not block an event on the host.
What meeting 13.7 costs in licenses, engineering and upkeep
This table breaks the cost of Safeguard 13.7 into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written quote, since no price or duration is published here for this Safeguard. The main takeaway is that licenses are only one line, and engineering, tuning and evidence upkeep usually carry much of the effort.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Commercial EDR or host IPS licenses | Software vendor, through a subscription or license agreement | Recurring, usually priced per endpoint or per tier | Fleet size, agent features bought, mixed operating systems, and whether 24x7 vendor-managed response is included |
| Open-source alternative tooling (for example osquery, Wazuh or Velociraptor) | No license fee, but engineering and hosting are paid | Mostly one-time build, then recurring hosting and upkeep | Choice of components, how much custom detection content is written, and whether the team already runs similar stack |
| Deployment engineering | Internal platform or security team, or an implementation partner under a fixed-scope agreement | One-time for rollout, with recurring work for new asset onboarding | Asset inventory quality (Safeguards 1.1 and 2.1 are prerequisites), legacy systems, and number of supported platforms |
| Policy tuning and exception handling | Internal security operations staff | Recurring | Alert volume from false positives, business-critical hosts that cannot run the agent, and how often exceptions must be reviewed |
| Coverage reporting and evidence upkeep | Internal team; sometimes a reporting or GRC tool | Recurring, with a periodic peak before assessments | Number of capable assets, quality of the Coverage metric data, and how often evidence must be refreshed for auditors |
| External review and assessor time | Independent auditor or assessor, and any consultant preparing evidence | Periodic, tied to the assessment cycle | Scope of the assessment, number of sampled assets, and how well evidence is organized before fieldwork |
| Unsupported or legacy assets | Internal team for compensating controls or replacement | One-time for remediation, recurring for compensating monitoring | Operating systems that cannot run the agent, and how the organization documents the exception |
Who runs 13.7: your team, a partner and the independent assessor
Your organization owns Safeguard 13.7. That means deciding that host-based intrusion prevention is in scope, choosing where it is appropriate or supported, and accepting the residual risk on any asset where it is not. The CIS Controls Assessment Specification ties the measurement to asset and software inventories, so the internal team must also keep Safeguards 1.1 and 2.1 current, because the coverage figure cannot be trusted without them.
- Policy and scope: approve the written rule that every enterprise asset capable of running a prevention agent must have one, and define what counts as an exception.
- Exception decisions: record each asset where prevention is not deployed, the reason, the compensating control and the named owner who accepts the risk.
- Prerequisite inventories: maintain the detailed asset inventory and software inventory that the coverage metric depends on.
- Vendor and product choice: select the EDR client or host IPS agent and confirm its prevention modes on each operating system you run.
- Ongoing review: review coverage and exceptions on a schedule you set, and retain the approvals.
Before you engage anyone, confirm internally who signs the exception register and who can change prevention policy in production.
An implementation partner prepares systems and evidence. It does not own the control and it does not certify it. In practice this work is often outsourced because it is technical and time-consuming across a large fleet, but the partner acts on decisions your team has already made.
- Agent deployment: install and configure the EDR client or host IPS agent across the in-scope fleet, including staged rollout and rollback plans.
- Prevention tuning: move policies from detect-only to prevention in controlled steps, and tune rules so legitimate business software is not blocked.
- Coverage reporting: build reporting that counts supported assets with the agent installed, so the Coverage metric can be reproduced on demand.
- Evidence preparation: assemble policy exports, deployment records, exception logs and sample prevention events in a form your assessor can sample.
- Prevention testing: run controlled tests that confirm the agent blocks the behavior it claims to block, and document the results.
Ask any partner to state in its written scope which items it performs, which it only advises on, and which remain with your staff. Confirm that it will not sign or represent the control as independently verified.
An independent auditor, assessor or certification body tests the control and issues any report or certificate. Only that party can give an assurance opinion. The assessor reviews your evidence and tests samples directly, and must be separate from the people who designed, deployed or prepared the evidence for the same control.
- Independence: the assessor should not have built the coverage reports, tuned the policies or written the evidence package it reviews.
- Testing: expect sampling of assets to confirm the agent is present, running and set to prevention where the policy requires it.
- Exception review: the assessor checks whether each exception is approved, justified and compensated.
- Reporting: the report or attestation is issued by the assessor under its own name, with the scope and period it covers.
- Engagement terms: confirm the assessor's conflict-of-interest rules and whether it accepts evidence prepared by a third party.
If your assessment framework requires a particular accreditation or report type, confirm that with the assessor and your contract owner before work starts.
Where 13.7 programs usually fall short and how to close each gap
Most Safeguard 13.7 programs fail on paperwork and scope long before they fail on technology. The gaps below cluster around what the agent is set to do, which assets are counted, who owns exceptions, whether agents report, and when evidence gets collected. Each card names the closing action and the evidence an assessor would expect to see.
Prevention agents left in detect mode
An EDR client or host IPS agent installed in audit or detect-only mode looks like prevention on an inventory report but blocks nothing. Safeguard 13.7 asks for a host-based intrusion prevention solution, so detect-only deployments belong to 13.2, not 13.7. Check the policy setting on a sample of hosts from each build group, and confirm that blocking rules are enforced for the malicious activity categories your policy names. Evidence that closes this gap is a policy export showing the enforcement mode per group, plus a dated test showing a blocked action.
Coverage denominator omits servers and cloud
The Coverage metric counts the share of assets capable of supporting host-based intrusion prevention with software installed. Teams often set the denominator to laptops and desktops and leave out servers, virtual machines, containers and cloud workloads, which inflates the score. Start from the asset inventory that Safeguards 1.1 and 2.1 require, then classify each asset as capable or not capable with a documented reason. Evidence that closes this gap is a denominator query and its output, reviewed against the asset inventory export.
Exceptions with no owner or expiry
Legacy systems, appliances and vendor-managed hosts often run without an agent. When those exceptions have no named owner, compensating control, or review date, they become permanent gaps that nobody tracks. Record each excluded asset with its owner, the reason it cannot support the agent, the compensating measure such as network filtering under 13.4, and a review date. Evidence that closes this gap is an exception register with approval records and a log of reviews completed on schedule.
Agents installed but not reporting
A deployment tool can show an agent as installed while the agent is stopped, out of date, unable to reach its management console, or silent after an operating system upgrade. Check reporting status against the asset inventory rather than against deployment records. Set an alert for hosts that stop checking in and assign each alert to a responder. Evidence that closes this gap is a current check-in report that reconciles installed agents with inventoried assets, plus tickets showing silent hosts were investigated.
Evidence assembled only at audit time
Teams that gather screenshots and exports the week before an assessment cannot show that enforcement was continuous. Assessors look for records produced during normal operation, and a single snapshot does not show that the agent stayed in prevention mode through the period. Schedule recurring exports of policy mode, coverage and exceptions, store them with timestamps in a system the team cannot quietly edit, and review them at a fixed cadence. Evidence that closes this gap is a dated export archive covering the full assessment period.
Open-source checks for agent coverage
Where a commercial agent is not supported on a host, open-source telemetry can show whether the host still runs expected security processes and reports events. osquery can schedule queries for running processes and open network connections across a fleet, which helps confirm that a protection process is active on each host. Confirm which query output your assessor will accept as evidence before you rely on it. Evidence that closes this gap is the scheduled query definitions, their result history, and a documented decision on how the output supplements the agent report.
Questions buyers ask about 13.7 cost, effort and outside help
How much more effort is 13.7 than 13.2 host-based intrusion detection?
Safeguard 13.7 usually takes more effort than 13.2 because it moves from observing host activity to acting on it. Detection under 13.2 can start with alerts routed to a team that reviews them. Prevention under 13.7 means a agent or EDR client can block or contain activity on the host, so the team must agree on what gets blocked, who approves exceptions and how a blocked process is restored. Deployment across the fleet, policy testing on representative hosts and exception handling all add work. The effort is also shaped by your existing inventory under 1.1 and 2.1, because the Coverage metric depends on knowing which assets can support the agent. Ask a partner to separate deployment effort from policy tuning effort in any quote.
What does the work need from our own team?
Your team owns the decisions even when an implementation partner does the technical work. Expect to supply an accurate asset inventory, a software inventory, named owners for each host group and someone who can approve prevention policies. Security operations staff must agree on response actions, such as isolating a host, and on how alerts reach them. Platform or endpoint administrators must allow the agent deployment through change control and confirm which operating systems and images are in scope. Business owners should be consulted before prevention is enforced on systems that run specialized or legacy software, since blocking the wrong process can disrupt production.
Can a small IG3 team implement 13.7 without outside help?
A small team can implement 13.7 alone if it already has the skills and time, but the safeguard is a poor fit for an overloaded team starting from no inventory. Because 13.7 is an IG3 safeguard, your organization is likely to have security specialists and regulated assets, but a small group may still lack capacity for deployment, policy design, testing and evidence collection at the same time. Consider what you already run: an EDR product that is licensed but not fully deployed, or an open-source agent that is installed on some hosts. Outside help is most useful for scoping the deployment, building a prevention policy baseline and producing evidence that an assessor can review. Decide this on your own staffing figures rather than on a general rule.
How long does a 13.7 deployment take?
No duration applies to every environment, so ask a partner for one only after the scope is written. The main drivers are the number of enterprise assets that can support host-based prevention, how many operating systems and images are involved, whether the agent is already installed, how many policy exceptions must be negotiated, and how many change windows are available. Assets that cannot run the agent, such as some appliances or embedded devices, are documented rather than deployed, which can shorten or lengthen the work depending on how many there are. Ask for a phased plan with a pilot group, a rollout by host class and a separate period for tuning and evidence capture.
What should we ask for in a fixed-scope quote for 13.7?
A fixed-scope quote should name the work, the hosts, the deliverables and the responsibilities of each party. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and a quote follows from that written scope. Ask for:
- The list of asset classes and operating systems included, and those excluded with reasons.
- The prevention software to be deployed, its licensing source and who holds the licenses.
- A policy design and testing step, with the number of exception cycles included.
- The evidence package for the Coverage metric, including inventory references for 1.1 and 2.1.
- Handover and documentation, plus whether ongoing support or retainer work is separate.
Also confirm what happens to changes requested after sign-off.
Can our implementation partner issue the 13.7 assessment result?
No. An implementation partner prepares systems, controls and evidence, but only an independent assessor or certification body issues a report or certificate. Your organization owns its controls and decides how the safeguard is documented. DeployOpen does not issue audit reports, attestations or certifications. Where a customer, regulator or contract asks for independent confirmation, engage an assessor separately and give them the evidence your environment produces. The CIS Controls Assessment Specification defines what is measured, and your assessor will test against it and your own records.
What costs continue after the 13.7 deployment is complete?
Several costs recur after the initial deployment, and they are often larger than the setup. Licensing or subscription fees for the prevention software continue for each host. Policy maintenance, exception review and alert triage require ongoing staff time. Agent upgrades, operating system changes and new hosts must be brought under coverage, and the Coverage metric must be recalculated as the inventory changes. If you engage a partner for ongoing support, upgrades or continuous testing, those are typically handled through a retainer rather than the original fixed scope. Ask any partner to separate one-time work from recurring work in writing.
How DeployOpen scopes and prepares 13.7 evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the host-based intrusion prevention work for Safeguard 13.7 is scoped, built and handed over as part of your environment. We prepare systems and evidence for your assessment, while your organization owns the control and an independent assessor or auditor performs any formal review.
How we scope
- We agree a written, fixed scope that names the enterprise asset classes where host-based prevention is in scope and where it is not.
- We confirm the asset inventory from Safeguard 1.1 and the software inventory from Safeguard 2.1 as the basis for measuring coverage.
- We record which hosts can support prevention agents and document the reasons for any exclusions in the scope.
How we build
- We deploy and configure the chosen host prevention agent or EDR client on the in-scope assets within your cloud accounts or data centers.
- We check agent installation and telemetry on sample hosts so the coverage figure reflects agents that are actually running.
- We build coverage queries, for example with osquery, to report which assets have the agent installed and which do not.
How we hand over
- We deliver a coverage report that matches the Coverage metric in the CIS assessment specification, with the asset list behind it.
- We document the prevention policy, exception process, owner for each agent and the procedure for handling blocked events.
- We walk your team through the evidence set so your organization can show it to an independent assessor on request.
How we support
- Ongoing support, agent upgrades and coverage monitoring are available as a retainer after handover.
- We can extend the coverage checks when new asset classes or operating systems join the environment.
- Before work starts, confirm with us which evidence your assessor expects and how often it must be refreshed.
