What Safeguard 13.2 host-based intrusion detection requires
If an auditor, a customer questionnaire or a CIS adoption project has asked you to show Safeguard 13.2, the short answer is that it requires a host-based intrusion detection solution on enterprise assets where appropriate or supported. The safeguard is detect-only: it asks you to see suspicious activity on a host, not to block it. Blocking belongs to Safeguard 13.7, which is an IG3 requirement for host-based intrusion prevention through an EDR client or host IPS agent. CIS v8.1 places 13.2 in Implementation Group 2, so it applies to IG2 and IG3 enterprises and not to IG1 organizations. It sits in the Devices asset class and the Detect security function. The assessment specification treats Safeguards 1.1 (detailed enterprise asset inventory) and 2.1 (software inventory) as prerequisites. In practice, you cannot prove 13.2 until you can list every asset, say which ones can run a host-based detection agent, and name the software that runs on them.
The usual difficulty is scoping. The assessment specification scores 13.2 with a Coverage metric: the share of assets capable of supporting host-based intrusion detection that have the software installed. The denominator is the hard part. Confirm with your assessor how they define "capable of supporting" and "where appropriate or supported" for your estate, including endpoints, servers, cloud workloads, containers and any appliances where an agent is not supported. Record the exclusions and the reason for each one, because an undocumented exclusion looks like a gap. To prepare, reconcile your asset inventory against your agent deployment records and produce a dated list of assets with and without coverage. Ask your team to document the decision rule for each exclusion. An implementation partner can help build the reconciliation, deploy and configure a self-hosted detection platform, and collect the evidence, but the organization owns the scope decision and the assessor issues any conclusion about compliance.
Which hosts and teams fall inside Safeguard 13.2 scope
Safeguard 13.2 applies only where a host can support a host-based intrusion detection agent, so the scope starts with an accurate asset inventory and a documented decision for every host. The cards below cover the host types, the exceptions and the teams that own each decision.
Servers and workstations
Physical and virtual servers and user workstations are the core of the Safeguard. For each one, confirm that a host-based detection agent such as osquery, Wazuh or Velociraptor can be installed on the operating system in use and is running. Record the agent version and the last check-in, because an installed agent that has stopped reporting does not count toward coverage. Inventory data from Safeguards 1.1 and 2.1 tells you which hosts to check.
Cloud instances and virtual machines
Cloud instances are in scope when they run an operating system that supports a host agent. Autoscaling groups and short-lived instances are the usual gap, because a fixed inventory list goes stale quickly. Check that the agent is part of the base image or the provisioning template, and that instances launched outside the template are detected and flagged. Ask the platform team how instances are created and retired.
Containers and ephemeral workloads
Containers share the host kernel, so the host agent usually belongs on the node that runs them, not inside each container image. Decide whether the Safeguard covers the node, the container runtime or both, and document that decision. Container images that are rebuilt often need their monitoring configuration to come from the orchestrator, not from manual setup. Confirm this with the team that operates the cluster.
Appliances and unsupported assets
Network appliances, embedded controllers, medical devices and many industrial systems often cannot run a host agent. Do not count them as covered by assumption. Record each one as an exception with the reason it cannot host an agent, the compensating control (for example, network-based detection under Safeguard 13.3) and a review date. The assessment measures coverage against assets capable of supporting the software, so the reason for each exclusion must hold up to an assessor's questions.
Owners of inventory and endpoint tooling
The asset inventory owner decides which hosts exist, the endpoint or platform team deploys and maintains the agent, and the security operations team reviews the alerts. These responsibilities should be written down with named roles. A common failure is an inventory owned by IT operations that does not feed the security team's coverage report. Agree how new hosts move from provisioning to the agent deployment list.
Third-party managed hosts
Hosts run by a managed service provider or hosting vendor may still be part of your scope if they process your data. Confirm in the contract or service description who installs and operates the host agent, who receives its alerts and how the provider reports coverage to you. Where the provider cannot install an agent, record the gap and the compensating measure. Your organization stays responsible for its controls even when another party runs the host.
How an assessor tests Safeguard 13.2 coverage
This table sets out what an assessor checks for Safeguard 13.2, from the prerequisite inventories through the Coverage measure to the evidence requested and the findings that most often appear. Read each row as a question the assessor will ask, then confirm your own records can answer it before the assessment begins.
| Assessment element | What the assessor checks | Evidence that usually satisfies it | Common finding |
|---|---|---|---|
| Prerequisite: asset inventory (1.1) | Whether a detailed enterprise asset inventory exists and is current enough to define which assets are in scope for host-based detection | Dated inventory export listing hostname, owner, operating system and last-seen date for each enterprise asset | Inventory stale or missing servers, cloud instances and endpoints, so the coverage denominator is wrong |
| Prerequisite: software inventory (2.1) | Whether the organization knows which operating systems and software platforms are present, so it can tell which assets can support a host-based IDS | Software inventory export mapped to asset records, with operating system versions | Unknown operating systems on some hosts, leaving the assessor unable to confirm which assets are capable |
| Scope definition | Which assets are capable of supporting host-based intrusion detection, and the documented reason any asset is excluded | Written scope statement, asset class filter (Devices) and exclusion rationale for unsupported systems | Exclusions with no rationale, or appliances and legacy hosts silently removed from scope |
| Coverage metric | The share of capable assets that have host-based intrusion detection software installed, which is the measure the specification uses | Calculation sheet showing capable asset count, agent-installed count and resulting ratio, with the date of the data | Numerator built from a different list than the denominator, so the ratio cannot be reproduced |
| Agent deployment report | That the detection agent is present on the assets counted in the numerator, and that the deployment matches the inventory | Management console report of installed agents, joined to the asset inventory by hostname or unique identifier | Agents installed on hosts that are no longer in the inventory, or on duplicate records for the same machine |
| Agent health and reporting | That installed agents are actively reporting events to a monitored location, not merely present on disk | Recent heartbeat or last-check-in report, and a sample of alerts or logs shipped from several hosts | Agents installed but not reporting after upgrades, certificate expiry or network changes |
| Exception records | Whether assets without the agent have a documented, approved reason and a compensating view or planned remediation | Exception register with asset, reason, owner, approval and review date | Gaps with no exception record, or exceptions that were never reviewed after they were approved |
How to implement host-based intrusion detection step by step
This sequence takes Safeguard 13.2 from an unverified asset list to a documented, monitored estate in which every eligible host runs host-based detection, its alerts reach central alerting, and every gap has a recorded reason.
Confirm the asset inventory and software inventory
Start from the detailed enterprise asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1). The CIS Controls Assessment Specification lists both as prerequisites for measuring 13.2, so the Coverage figure you later report depends on them. Reconcile the two lists against discovery data from your network and cloud accounts, and note assets that appear in one source but not the other. The output is a reconciled inventory with an owner and a last-verified date for each enterprise asset. If you cannot show that the inventory is complete, the coverage measure will not be defensible.
Classify which assets can support a host IDS agent
Sort each asset into one of three groups: supports a host-based intrusion detection agent, does not support one, or supports one only with a compensating control. Safeguard 13.2 applies where appropriate or supported, so the classification is the record of that judgment. Check operating system versions, kernel or agent compatibility, resource limits on embedded or legacy devices, and vendor restrictions on installing third-party software. The output is a classification table signed off by the system owner, with a reason written against every asset that is excluded.
Choose and deploy the host monitoring tooling
Select the agent or self-hosted tooling for the supported group, such as osquery for scheduled host queries, Wazuh for file integrity monitoring, or Velociraptor for artifact collection and hunts. Confirm each tool's current capabilities and licensing against the vendor documentation before you commit, because the features you rely on must be present in the version you deploy. Deploy to a pilot group first, then roll out in waves through your configuration management. The output is a deployed agent on every asset in the supported group, with installation confirmed by the management server rather than by the installer alone.
Configure file integrity and process monitoring
Define what the agents watch: monitored file and directory paths for system binaries, configuration files and security tooling, and scheduled queries for running processes, loaded kernel modules, open network connections and local accounts. For file integrity monitoring, record a baseline of checksums and attributes before you enable real-time alerts, so that the first alert is a real change and not an artifact of setup. Document the paths and queries in version control. The output is a reviewed monitoring configuration with a baseline recorded for each host and a list of the changes that generate alerts.
Route host alerts to centralized alerting
Forward host detection events to the central SIEM or log analytics platform established under Safeguard 13.1, so that host alerts are correlated with network and identity events. Map each alert type to a severity and an owner, and test the path by generating a controlled, documented change on a test host and confirming that the alert arrives, is correlated and reaches the on-call queue. The output is a test record showing the alert trail from host to case queue, with the timestamp and the expected result for each test.
Verify coverage and record the Coverage metric
Calculate the Coverage metric the Assessment Specification uses: the share of assets capable of supporting host-based intrusion detection that have the software installed and reporting. Compare the agent management console against the classified inventory, not against the installer count, and investigate every host that is missing or silent. The output is a coverage report with its numerator, denominator, date and the list of assets that are excluded and why. Keep the report with the inventory so an assessor can trace each figure.
Document exceptions and set the review cycle
Write an exception record for every supported asset without an agent, every excluded asset and every compensating control, and assign each one an owner and a review date. Confirm with your assessor and the CIS Controls Navigator mappings how your organization records exceptions for SOC 2, ISO/IEC 27001 and PCI DSS, since those frameworks map to 13.2 and may expect different evidence. Schedule periodic reviews of the classification and coverage report. The output is an exception register and a review calendar that the organization owns, which an independent auditor can test.
Why the Coverage metric makes inventory the first deliverable
The Coverage metric in the CIS Controls Assessment Specification for Safeguard 13.2 is a share, and its quality depends entirely on the denominator: the assets capable of supporting host-based intrusion detection. If that list is incomplete, the percentage looks healthy while unmonitored servers, virtual machines and workstations sit outside the calculation. An inflated denominator, which includes assets that cannot run an agent, produces the opposite error and hides real gaps behind exceptions nobody reviewed. For this reason, the asset inventory that Safeguards 1.1 and 2.1 require is the first deliverable, not a precursor to the detection project.
Define "capable" as a written rule before counting anything. In practice this means deciding which operating systems, versions and asset classes your intrusion detection product supports, which devices are excluded because they run vendor firmware or cannot host an agent, and which cloud workloads count as hosts. Record every exclusion in a register with an owner, a reason, a compensating control and a review date. Ask your detection vendor or implementation partner to confirm supported platforms in writing, and do not rely on a general list of operating systems from marketing material.
Reconcile agent reports against the inventory on a fixed schedule, and treat every mismatch as a finding. Assets that appear in the inventory but never report, agents that report from hosts absent from the inventory, and hosts that reappear after long dormancy all indicate either a gap in deployment or a gap in asset discovery. An illustrative example: a cloud account with autoscaling groups may show a healthy agent count on Monday and a shrinking fleet by Friday, and only a reconciliation against the inventory reveals that replacement instances never received the agent. Confirm with your assessor how often they expect this reconciliation to run and what records they will sample.
Evidence that shows host-based detection is running
Safeguard 13.2 is tested by measuring coverage, so the evidence has to show which assets are in scope, which ones run the detection agent and what that agent actually reports. The artifacts below connect the asset inventory to live agent data and to the exceptions your team has approved, which is the chain an assessor will follow.
Asset inventory with detection status
The Coverage metric divides assets capable of supporting host-based intrusion detection by those with the software installed, so the denominator comes from the asset inventory required by Safeguard 1.1. Export the inventory with a detection status column that marks each eligible host as covered, excluded or pending. Check that the eligible population matches the inventory and that no host is silently dropped from the count.
Agent deployment and health reports
Keep reports showing which hosts run the detection agent, the agent version and the time of its last check-in. A host that appears in the inventory but has not reported recently is not covered in practice. Compare the deployment report against the inventory each month and record every gap with an owner and a date to close it.
Baseline and alert samples from file integrity monitoring
Where the detection tool includes file integrity monitoring, such as Wazuh, keep the recorded baseline of checksums and attributes for monitored paths, plus sample alerts showing who or what changed a file and when. Retain at least one dated alert with its triage notes. An assessor can then see that detection produces usable output rather than an idle agent.
Exception records with approvals
Any eligible host without the agent needs a written exception that names the reason, the compensating measure, the approver and an expiry or review date. Unapproved gaps are the most common finding in this area. Store each exception with its change ticket and the dates of every review, so the record shows the gap was known, accepted and revisited.
Monthly exports tied to change tickets
Assessors look for evidence that is current, not just a snapshot taken for the audit. Schedule a monthly export of the inventory, deployment report and exception register, and file each export against the change ticket that added, removed or excused a host. This keeps the trail continuous between audits and shows who acted on each gap.
What meeting Safeguard 13.2 costs in money and effort
This table breaks down the cost components of meeting Safeguard 13.2 and shows who is paid for each, whether the cost is one-time or recurring, and what drives it up or down. Read it as a checklist for building a quote, since no fixed prices are implied. The main takeaway is that open-source tooling removes license spend but shifts the cost into engineering and operating time that you must budget for.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it |
|---|---|---|---|
| Agent or EDR-style licensing | Software vendor, if a commercial agent is chosen | Recurring, usually per endpoint or per year | Host count, operating system mix, and whether prevention features are bundled |
| Open-source agent or query tooling | No license fee; internal staff or an implementation partner for setup | One-time setup, then recurring operating time | Number of hosts to cover and how many platforms and agent versions must be supported |
| Engineering time to deploy and tune | Internal platform engineers or an implementation partner under a written scope | One-time, with periodic retuning | Operating system diversity, legacy hosts, and how many detection rules are enabled |
| Inventory reconciliation | Internal asset management or IT operations staff | Recurring, tied to asset churn | Quality of the asset inventory required by Safeguards 1.1 and 2.1, and the rate of host changes |
| Alert triage and tuning | Security operations staff | Recurring | Alert volume, false-positive rate, and the staffing model for on-call review |
| Evidence upkeep | Control owner, with support from the implementation partner if scoped | Recurring, often at each review cycle | Number of hosts sampled, retention settings, and how often coverage reports are exported |
| External review and auditor sampling | Independent auditor or assessor, who issues any report | Recurring at each assessment | Sample size chosen by the assessor, scope boundaries, and the completeness of the coverage evidence |
| Ask for in every quote | Written scope, named deliverables, host and platform counts, and support hours | Set once per engagement | Confirm whether the quote covers agent packaging, deployment, tuning, runbooks and evidence exports |
Open-source tools that produce host detection evidence
osquery exposes operating system state as SQL tables, so a team can ask the same question across many hosts and keep the answers as dated records. For Safeguard 13.2, that makes it useful for showing what the host detection layer observes on each device, such as running processes, loaded kernel modules, open network connections and file hashes. Its osqueryd daemon can schedule these queries to run across a fleet, which turns a one-time check into a repeatable measurement.
- Scheduled fleet queries: The osqueryd daemon runs saved queries on a schedule, so results accumulate over time rather than existing only for one review.
- Process and kernel module tables: Queries against running processes and loaded kernel modules provide the host-level visibility that detection rules depend on.
- Open connection and file hash data: Open network connections and file hashes give the security team material to compare against known-good or expected states.
- Licensing: osquery is available under Apache-2.0 OR GPL-2.0-only, so confirm which license option your legal team accepts before embedding it in a product.
- Coverage gaps: osquery reports only on hosts where it is installed and running, so pair its results with an asset inventory to show the coverage figure the assessment specification uses.
Confirm with your security engineers which tables, query schedules and retention periods your environment needs, and check how the results will be stored and reviewed for the assessor.
Wazuh's file integrity monitoring records a baseline of checksums and attributes for the files and directories you choose, then alerts when a user or process creates, modifies or deletes a monitored file. For Safeguard 13.2, this produces change evidence that shows the host detection layer notices alterations to the system. Monitoring can run on a schedule or in real time, and the alert details record how and when the change happened and who made it.
- Baseline creation: The initial checksum and attribute snapshot becomes the reference point that later changes are measured against.
- Real-time or scheduled checks: Teams choose the mode that fits their change-control rhythm and resource limits.
- Attribution details: Alerts identify the user or process responsible, which supports incident triage and the review of unexpected changes.
- Licensing: Wazuh is licensed under GPL-2.0-only, which should be reviewed against how your organization distributes or modifies the software.
- Scope decisions: Choose monitored paths deliberately, since an overly broad baseline produces noise and an overly narrow one misses changes that matter.
Confirm the monitored paths, alert routing and baseline update process with your change management owner, and verify that the baseline itself is protected from unauthorized edits.
Velociraptor collects forensic artifacts from endpoints using artifacts written in VQL, and its hunts gather one or more artifacts across a group of systems at once. For Safeguard 13.2, hunts provide a way to demonstrate that host detection data can be pulled from many endpoints on demand, not only from the device that raised an alert. Offline machines are scheduled to collect when they reconnect, and each hunt gets a notebook for analyzing the combined results.
- Group collection: A single hunt can target a defined set of systems, which helps teams verify coverage across a population.
- Offline handling: Machines that are not connected at hunt time collect automatically when they return, reducing gaps in the evidence.
- Hunt notebooks: Each hunt produces a notebook that records the analysis of combined results, useful as a review record.
- Licensing: Velociraptor is licensed under AGPL-3.0-only, so confirm the obligations that apply if you modify it or make it available to users over a network.
- Operational load: Broad hunts consume endpoint and server resources, so schedule them and agree on limits with the platform owners.
Confirm that the artifacts you define match the detection questions in your assessment, and confirm who is authorized to launch hunts and how their activity is logged.
Bareos is an open-source backup system, and its Verify jobs compare files on a host against attributes it stored in its catalog during an earlier backup. This works like a Tripwire-style integrity check: after a suspected compromise, the comparison shows which files differ from their cataloged state. For Safeguard 13.2, this is a complementary source of change evidence, particularly for teams that already run Bareos for recovery and want to reuse the catalog.
- Catalog comparison: Verify jobs check files against previously cataloged attributes, so the reference point is tied to backup history.
- Post-incident use: The mechanism is well suited to answering whether files changed after an event, rather than providing real-time alerts.
- Shared infrastructure: Teams already operating Bareos for backups can extend it to integrity verification, though the backup and detection roles should stay distinct in documentation.
- Licensing: Bareos is licensed under AGPL-3.0-only, so review the terms with counsel before deploying it in a commercial service.
- Timing limits: Verify jobs run on a schedule or on demand, so they do not replace continuous detection on their own.
Confirm that the Verify job scope covers the systems you must show, that catalog records are retained long enough for your review cycle, and that the catalog itself is protected from tampering.
Where Safeguard 13.2 programs usually fall short
Host-based intrusion detection programs often fail less on tooling than on the surrounding process: the asset list the agents are meant to cover, the health of the agents themselves, and the path from an alert to a person who acts on it. The cards below cover the gaps assessors and implementers most often find, each with a closing action the organization can check.
Assets missing from the inventory
Safeguard 13.2 is measured against the share of assets capable of running host-based detection, and the assessment specification lists Safeguards 1.1 and 2.1 as prerequisites. If the asset inventory omits laptops, build servers, cloud instances or contractor devices, the coverage figure looks healthy while large parts of the estate have no agent at all. Reconcile the detection console against the asset inventory and the cloud account listings each review cycle, and confirm that every asset capable of supporting an agent is either covered or recorded as an exception.
Agents installed but not monitored
An agent that stops reporting, crashes after an operating system update or runs with an expired configuration does not show up as a gap unless someone watches for it. Teams often count installed agents without tracking whether each one checked in recently. Set an alert for hosts that go silent, and include agent version and last-seen time in the coverage report so that the metric reflects working detection, not just installed software.
Detection without alert routing
Host-based detection produces events that have value only when they reach an owner who can triage them. Many programs send agent alerts to a console nobody opens, or to a mailbox without a rotation. Confirm that each high-severity host alert forwards to the centralized alerting platform under Safeguard 13.1, that it has a named responder, and that the responder's escalation path is written down and tested at least once a year.
Undocumented exclusions
Teams often exclude directories, processes or hosts from monitoring to reduce noise or to fix performance problems, and the exclusion is rarely recorded. An attacker who learns of a broad exclusion can operate inside it. For each exclusion, record the owner, the reason, the expiry date and the compensating control, then review the list on a fixed schedule. Assessors commonly ask for this list first, so it should exist before the review starts.
Confusing 13.2 detection with 13.7 prevention
Safeguard 13.2 requires detection on enterprise assets. It does not require the agent to block malicious activity. Safeguard 13.7, an IG3 safeguard, moves to prevention through an EDR client or host-based IPS agent. Programs that describe a detect-only tool as blocking threats create a gap between the policy and what the tool does. State in the control narrative which safeguard each tool satisfies, and where prevention is claimed, confirm that the product is configured to block and not only to alert.
Coverage reported without evidence
The assessment specification measures coverage, but a percentage in a dashboard is not evidence on its own. Assessors ask for the inputs behind the number: the asset list, the agent deployment record and the console export on the date of review. Keep dated exports from the detection platform and the inventory together, so that anyone can recompute the coverage figure. Without this, the metric cannot be defended in an audit.
Questions buyers ask about Safeguard 13.2
Does CIS Control 13.2 apply to IG1 organizations?
No. Safeguard 13.2 sits in Implementation Group 2, so it applies to IG2 and IG3 enterprises and is not part of the IG1 set. IG1 is CIS's essential cyber hygiene baseline and the minimum standard for every enterprise, and it asks for a smaller group of Safeguards. An IG1 organization can still deploy host-based detection voluntarily, and the work will help later steps, but an assessor measuring against IG1 will not score 13.2. Before deciding, confirm your Implementation Group on the CIS Implementation Groups pages and check which Safeguards your contracts or regulator actually reference. A customer may ask for IG2 coverage even when your own profile is IG1, and that request, not the IG label alone, should set your scope.
Must we add host-based prevention under Safeguard 13.7 at the same time?
Only if you are an IG3 enterprise. Safeguard 13.2 asks for host-based detection on enterprise assets where appropriate or supported. Safeguard 13.7, an IG3 Safeguard, moves from detection to host-based intrusion prevention, for example through an EDR client or a host-based IPS agent. An IG2 organization can satisfy 13.2 with detection alone. Many teams still choose to plan prevention early, because the agent choice, the asset classes it covers and the alert workflow all shape the later decision. A practical sequence is to deploy detection and confirm inventory coverage first, tune alerts, and then treat prevention as a separate project with its own scope, change windows and rollback plan so that blocking actions never reach production systems that were not yet measured.
What does host-based intrusion detection need from our internal staff?
Internal staff keep ownership of the control and the decisions behind it, even when an implementation partner prepares the systems and evidence. Expect four groups to be involved. Asset owners approve which production systems receive agents and which exclusions are acceptable. The platform or infrastructure team deploys, patches and configures the agents and the collection backend. The security operations team owns alert triage, escalation and the tuning decisions that follow. Change management schedules maintenance windows and records approvals. Legal or privacy staff should review what host telemetry, user activity and file metadata are collected and retained. Ask the partner to name which tasks they perform, which decisions remain with you and how many hours of your staff time the written scope assumes.
How long does host-based intrusion detection take to deploy?
No duration is fixed by the CIS material, so the honest answer depends on your starting point. The main driver is the maturity of your asset and software inventories, because the CIS Controls Assessment Specification lists Safeguards 1.1 (detailed enterprise asset inventory) and 2.1 (software inventory) as prerequisites for measuring 13.2. If those inventories are current, the work is mostly agent rollout, alert tuning and evidence capture. If they are incomplete, discovery and reconciliation come first and usually take longer. Other drivers include the number of operating system families, cloud images, change freeze periods and the number of approval layers. Ask any provider for the phases, the asset classes in scope, the platforms covered and the assumptions behind the schedule, and confirm that the timeline appears in the written scope before work starts.
Can open-source tools produce the evidence for Safeguard 13.2?
Open-source tools can produce much of the telemetry and integrity evidence, but no single tool should be assumed to cover every expectation of the Safeguard without checking. The main candidates are osquery, which exposes running processes, loaded kernel modules, open network connections and file hashes as SQL tables and whose osqueryd daemon schedules queries across a fleet; Wazuh file integrity monitoring, which records a baseline of checksums and attributes and alerts when monitored files are created, modified or deleted; Velociraptor, which collects artifacts defined in VQL and runs hunts across groups of systems; and Bareos Verify jobs, which compare files against cataloged attributes. Confirm each agent's capabilities against your own requirements, and have counsel review the licenses, which include Apache-2.0 OR GPL-2.0-only, GPL-2.0-only and AGPL-3.0-only. osquery documentation describes the query model in detail.
How does the assessment specification measure Safeguard 13.2?
The Assessment Specification scores Safeguard 13.2 with a Coverage metric: the share of assets capable of supporting host-based intrusion detection systems that have host-based intrusion detection software installed. The result is only as good as its two inputs. The numerator is the count of agents actually running on assets, verified from the deployment tool or endpoint console. The denominator is the set of assets your organization has classified as capable of supporting the software, which depends on the asset inventory from Safeguard 1.1. Document the classification rules, the reasons for each exclusion and the review cycle for those exclusions, because an assessor will test whether the denominator was defined before the result was measured. The specification explains what to measure but not how to build the process, so the method is yours to define and defend.
How do we choose a partner for Safeguard 13.2 work?
Choose a partner that prepares systems, controls and evidence, and make sure you understand that only an independent auditor, assessor or certification body issues reports or certificates. Ask for a fixed written scope that names the Safeguards covered, the asset classes, the agents, the exclusions, the deliverables and the handover documents such as runbooks and evidence procedures. Ask how the partner handles licensing for any commercial agent you choose, how they test alert tuning, and whether ongoing support or a retainer for upgrades is available. Ask whether they hold any accreditation for CIS Controls work. CIS Controls Accreditation explains how CIS accredits SecureSuite members that provide implementation services, and you should verify any claimed status directly with CIS.
How DeployOpen prepares host-based detection evidence
DeployOpen starts Safeguard 13.2 work with a written scope that names the enterprise assets in question, the operating systems and workloads on them, the detection platform to be used and the people who approve exceptions. Because the Coverage measure in the CIS Controls Assessment Specification is a share of assets, the first deliverable is a scope register that ties each in-scope host back to the asset inventory (Safeguard 1.1) and the software inventory (Safeguard 2.1). Without those two prerequisites, the denominator of the Coverage calculation cannot be defended, so we treat them as blocking items. Your organization owns the decision on which assets are in scope and where detection is not appropriate or supported. DeployOpen prepares the register and the reasoning behind each entry.
DeployOpen then deploys and hardens self-hosted open-source detection inside your own cloud accounts, data centers or air-gapped networks. Depending on the scope agreed in writing, this may combine osquery for scheduled, fleet-wide queries of processes, open network connections and file hashes, Wazuh file integrity monitoring for baselines of critical files and directories, and Velociraptor for collecting artifacts from groups of endpoints. The hardening work covers agent configuration, update channels, log forwarding and access to the management servers. Your security team should confirm which tools are approved under its own change process before deployment begins, and should decide how alerts reach the centralized alerting described in Safeguard 13.1.
DeployOpen builds the evidence set in the order an assessor would test it: the inventory, the list of hosts where detection is installed and reporting, the per-host coverage figure, and the records for every exception. Each exception is documented with the reason, the compensating measure and an owner who accepts the residual risk. DeployOpen prepares systems, configurations and evidence for your assessment, but does not issue audit reports, attestations or certifications. Those come only from an independent auditor or certification body that you select. Ask any implementation partner to confirm this boundary in writing before work starts.
