Safeguard 2.4 automated software inventory tools: evidence

What Safeguard 2.4 automated software inventory tools asks for

If you are preparing for an IG2 assessment or answering a customer questionnaire, Safeguard 2.4 asks your enterprise to use software inventory tools wherever possible to automate the discovery and documentation of installed software. The point is that the software list is produced by tooling that scans endpoints, not by someone typing names into a spreadsheet. The Safeguard sits in the Software asset class and the Detect security function, and it applies at Implementation Group 2 and 3 only, not IG1. In practice, that means a small organization at IG1 is not measured against it, while an IG2 enterprise is expected to have automated discovery in place wherever its endpoints allow it.

The risk it addresses is simple: a manual software list drifts from reality as soon as someone installs an application, updates a package or spins up a new machine. Unrecorded software is software you cannot patch, license, assess for end-of-life status or review for unauthorized use. Automated tools close that gap by reporting what is actually installed. The CIS Controls Assessment Specification measures this Safeguard with a coverage metric, the share of software-capable endpoints covered by at least one inventory tool, and it scores the Safeguard as failing if no inventory tool is identified at all. Your first task is therefore to confirm which tools you use and which endpoints they report from, and to record both.

The hard part is usually coverage, not installation. Endpoints are heterogeneous: Windows and Linux workstations, servers, virtual machines, network devices and mobile devices each report software differently, and some do not report software at all. Unmanaged devices, such as contractor laptops or lab systems that never join the directory, fall outside any agent-based tool. Tools also report partial data. An agent may list installed packages but miss portable applications, or capture services without versions. Before you describe your coverage to an assessor, compare each tool's output against a sample of endpoints and confirm with the vendor which software types and fields it actually collects in your environment.

Which endpoints and teams Safeguard 2.4 covers in practice

Safeguard 2.4 is only as complete as the population it is measured against. The decisions below determine which software-capable endpoints count, which inventories feed the work, and which parties hold pieces of the data, so settle them in writing before choosing tools.

Defining software-capable endpoints

Start by agreeing which assets count as software-capable. Servers, workstations and laptops almost always do. Network appliances, printers and industrial devices may or may not, depending on whether they run installable software that a tool can read. The CIS Controls Assessment Specification measures coverage as the share of software-capable endpoints covered by at least one tool, so the denominator is the decision that changes the result. Write the definition into the scope document and list the excluded device types with reasons.

Cloud workloads and containers

Virtual machines in cloud accounts are software-capable endpoints and need the same coverage as on-premises hosts. Containers and ephemeral images are harder: they may start and stop between scans, so a host-based agent may miss them. Confirm with the team whether container images are treated as software assets, whether the image registry or the running hosts are the system of record, and how short-lived workloads are reported so they do not fall out of the coverage count.

Feeding from Safeguards 1.1 and 2.1

Safeguard 1.1 provides the enterprise asset inventory and Safeguard 2.1 provides the software inventory. The specification lists both as prerequisites for measuring Safeguard 2.4 because they define what should be found. Automated discovery then becomes the check against those lists. Assets found by a tool but missing from the asset inventory point to a gap in Safeguard 1.1, and software found on endpoints but absent from the authorized list points to work under Safeguard 2.3. Reconcile these sets rather than treating the tool output as the inventory.

Remote, roaming and offline devices

Laptops that spend weeks off the corporate network and devices in branch offices with limited connectivity are the usual coverage gaps. Agent-based tools report when a device reconnects, but the report may lag by days. Decide how long a device may stay silent before it is treated as uncovered, and whether an agent that has not checked in counts toward the coverage ratio. Ask vendors how their tools handle devices that return after long absences and whether queued results are retained.

Managed providers and endpoint vendors

Managed service providers often install and operate inventory agents on client endpoints, and endpoint management vendors may hold software records in their own consoles. Each holder of inventory data is a place where coverage can be measured differently. Agree which party produces the coverage figure, where the raw data is stored, and how an auditor will access it. Contracts should name the data owner and the reporting obligation, because the organization owns the control even when a provider runs the tool.

Ownership across IT and security

Inventory data serves IT operations, security monitoring and audit, and these teams often disagree on what counts as installed software. IT may want managed packages only, while security wants every executable and running service. Name one accountable owner for the Safeguard 2.4 coverage metric, define the software categories the tool must report, and set a review cadence where both teams confirm the scope. Without this agreement, the same tool produces two different coverage numbers.

How an assessor tests Safeguard 2.4 under the CIS Assessment Specification

This table walks through how the CIS Assessment Specification scores Safeguard 2.4, from the pass or fail gate to the coverage measure and the evidence an assessor requests. Read each row as a step the assessor takes, and treat the findings column as the places where readiness usually breaks down.

Test element	What the assessment logic does	Evidence an assessor expects	Where it usually fails
Tool identification gate	The Safeguard fails outright if no software inventory tool is identified for the enterprise.	Named inventory tool or tools, with the owner and the purpose each serves.	Tools exist in practice but were never written down, so the assessor finds no tool of record.
Coverage measure	Where a tool is identified, the metric is the share of software-capable endpoints covered by at least one inventory tool.	Coverage report showing covered endpoints divided by the software-capable population for the period tested.	Coverage is reported as a single tool total without separating endpoints that are software-capable from those that are not.
Software-capable population	The denominator is the endpoints that can run software, which must be defined before coverage can be calculated.	Endpoint population list with the rule used to mark each device as software-capable or excluded.	Exclusions are undocumented or applied inconsistently between tool reports.
Prerequisite 1.1	Safeguard 1.1, the enterprise asset inventory, supplies the list of devices the coverage measure depends on.	Current asset inventory that matches the population used in the coverage calculation.	Coverage is calculated against an incomplete asset list, so unmanaged devices never enter the denominator.
Prerequisite 2.3	Safeguard 2.3, addressing unauthorized software, produces the response records that show how software discovered by the tool was handled.	Records of unauthorized software found by the tool and the removal or documented exception for each.	Tools report unexpected software, but no disposition is recorded, so the discovery data cannot be shown to drive action.
Tool configuration	Assessors check that the tool is configured to discover and document installed software on the endpoints in scope.	Configuration exports or screenshots, scan schedules and the agent or collection method used on each platform.	Agents are deployed to a subset of hosts, or collection is disabled on some operating systems without anyone noticing.
Scan currency	Coverage must reflect recent collection, so an endpoint whose last successful scan is old does not count as covered in practice.	Scan or check-in history showing last-seen dates for each endpoint.	Stale scans, offline laptops and retired hosts remain in reports and inflate apparent coverage.
Undocumented tools	Any tool that collects software data and is relied on for the measure must be identifiable to the assessor.	Tool register listing each product, its scope and its owner, including tools run by other teams.	Security, endpoint management and cloud teams each run a tool, and none of them is recorded as the tool of record.

How endpoint coverage is calculated and where the numbers go wrong

The coverage figure for Safeguard 2.4 is a ratio: the number of software-capable endpoints reported by at least one inventory tool, divided by the total number of software-capable endpoints in the population defined by Safeguard 1.1. The Assessment Specification scores the Safeguard as failing when no inventory tool is identified at all, so the ratio matters only once a tool exists. The denominator is the harder half. It should come from the enterprise asset inventory that Safeguard 1.1 requires, not from whatever a tool happens to see, because a tool cannot be credited for finding only the machines it already knows about. Confirm with the asset owner exactly which records feed the denominator and when that list was last reconciled against network discovery.

The first distortion comes from what counts as *software-capable*. Your organization must decide whether network appliances, printers, IP phones, industrial controllers and virtual machines are in the population, and write that rule down. Excluding a class of devices shrinks the denominator and inflates the percentage without any improvement in visibility. The second distortion is the *inactive agent*: a host with an installed agent that has not checked in for weeks still appears as covered if the tool keeps its last record. Set a staleness threshold, for example the age of the last inventory check-in, and count stale records as uncovered. The third is duplicate records, where one laptop appears under a hostname, a serial number and a cloud identifier. Duplicates inflate the numerator and can hide gaps, so deduplicate on a stable key before counting.

The Assessment Specification defines what to measure but not how to measure it, so the method is yours to set and must be documented. Record the population source, the inclusion rules for software-capable endpoints, the staleness threshold, the deduplication key, the review date and the person accountable for the figure. An assessor will test whether that method is applied consistently across periods, so changing the rules quietly between reviews will look like manufactured improvement. An illustrative method might state that a host counts as covered only when a tool reported it within the last reporting cycle and it matches exactly one record in the Safeguard 1.1 inventory. Write your own version and keep the calculation reproducible.

How to implement automated software inventory in six steps

This sequence takes an enterprise from an unknown software footprint to an automated inventory that is reconciled against the asset list, measured for coverage and documented well enough for an assessor to follow.

Confirm the endpoint population from Safeguard 1.1
Start from the enterprise asset inventory that Safeguard 1.1 calls for, because the Assessment Specification treats it as a prerequisite for measuring Safeguard 2.4. Filter the list to software-capable endpoints such as workstations, servers, and virtual machines, and set aside devices like printers or sensors that cannot run an inventory agent. The IT or asset management lead owns this list. The step is done when every software-capable endpoint has an identifier and an owner, and the denominator for coverage is written down.
Choose one or more inventory tools
Select at least one tool that can discover installed software automatically and document it. Options described in the researched facts include GLPI, which records software against assets and receives data from its agent, Wazuh Syscollector, which collects installed software and other system data into dashboards, and osquery, which answers SQL queries about hosts across a fleet. Confirm each candidate's supported operating systems, agent deployment method, and data retention with its vendor or documentation before deciding. The step is done when a named tool or tool combination is approved and its scope is recorded.
Deploy agents or scans with a defined rollout
Install the chosen agents or configure network scans in waves, beginning with a pilot group and expanding to the full endpoint population. Record which device groups receive which agent, how credentials and certificates are handled, and how offline or intermittently connected devices will report. The platform or endpoint engineering team carries out the rollout, and a partner may prepare packages and runbooks under a written scope. The step is done when the rollout plan is documented and each wave reports its endpoints into the tool.
Reconcile tool output against the asset list
Compare the software records returned by the tools with the endpoint population from the first step. Identify endpoints that never reported, duplicate records for the same host, and software that appears on hosts but not in the inventory. Assign each gap to an owner and a fix, such as repairing an agent or correcting an asset record. The step is done when the unexplained difference between the asset list and tool results is small enough to name each remaining item and explain why it exists.
Set the coverage target and reporting cadence
Define the inventory tool coverage metric the Assessment Specification uses: the share of software-capable endpoints covered by at least one inventory tool. Set an internal target, a method for calculating it from the denominator in step one, and a recurring report that goes to the control owner. Confirm with your assessor which cadence and evidence they expect. The step is done when the metric formula, target, and report owner are written and the first coverage report has been produced.
Document the process and exceptions
Write the procedure that covers tool selection, deployment, reconciliation, coverage reporting, and how new endpoints are onboarded. Record each exception, such as an endpoint that cannot run an agent, with the compensating method used to inventory it, the approver, and the review date. Keep the procedure and exception register under version control. The step is done when an independent reviewer can follow the document from end to end and every endpoint outside the tool's coverage has a recorded reason.

Evidence that passes a Safeguard 2.4 review

A Safeguard 2.4 review tests whether the enterprise can show that automated inventory tools run, cover the software-capable endpoints it claims to cover, and are kept current. The cards below cover the artifacts that prove this, and each one should be refreshed on a schedule so the package is not rebuilt in the week before an audit.

Named inventory tool register

A controlled list of every software inventory tool in use, with its version, the owner, the scope of endpoints it targets and the configuration baseline it runs under. Assessors start here because the Safeguard is failed outright when no inventory tool is identified. Check that the register matches what is actually deployed, not what was planned. Review it at each change to the tooling, and export the configuration files or policy settings alongside it so the setup can be reproduced.

Endpoint population reconciliation

A reconciliation that compares the endpoint population from the Safeguard 1.1 enterprise asset inventory with the hosts each inventory tool reports. The gap between the two lists is the number the coverage metric depends on, so the reconciliation must show who owns the difference. Identify which endpoints are software-capable and which are not, such as network appliances or printers. Re-run the comparison on a fixed schedule and keep each dated result.

Dated coverage reports and calculation

Dated reports that show the share of software-capable endpoints covered by at least one inventory tool, along with the arithmetic behind the figure. The assessment specification measures coverage this way, so the numerator and denominator must be stated and traceable to the reconciliation. Store each report with its date and the source data it was built from. A report without its calculation is hard for an assessor to rely on, and a figure that cannot be reproduced will be questioned.

Agent deployment and health records

Records showing when each collection agent was installed, which version it runs, and whether it reports in. Silent agents are the most common reason coverage drops between audits, so track last-check-in times and failed deployments, not just the initial rollout. Automated deployment logs from configuration management or endpoint tools usually provide this. Check that agent versions are within the supported range your tooling vendor documents, and confirm that vendor support status before relying on it.

Documented inventory process

A written procedure that states how discovery runs, who reviews the results, how often the inventory is reconciled, and how findings feed the unauthorized software work in Safeguard 2.3. The process should name the roles responsible for each step. Assessors look for the process being followed in practice, so keep the review minutes or tickets that show it operating. Update the document when tools or scopes change, and record the approval and version date.

Exception records for uncovered endpoints

A register of endpoints that no inventory tool reaches, with the reason, the compensating measure, the owner and a review date. Unexplained gaps are harder to defend than documented exceptions, so every uncovered software-capable endpoint should appear here. Common reasons include unsupported operating systems or devices that cannot run an agent. Review the register at least as often as the coverage report, and close entries when coverage is extended.

What meeting Safeguard 2.4 costs in money and effort

This table breaks the cost of meeting Safeguard 2.4 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 shape a quote request, since no fixed figures are supplied for these items and the real total depends on your environment and scope.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it and what to request in a quote
Tooling or licenses	Software vendor for commercial tools; no license fee for GPL or Apache-licensed open-source tools	Commercial: recurring. Open source: none for the software itself	Open-source tools remove license spend but not hosting. Ask for a line item for any commercial tool, its per-endpoint or per-tier pricing basis, and whether support is extra.
Hosting and infrastructure	Your cloud provider, data center or hardware budget	Mostly recurring, with a one-time sizing and build	Endpoint count, retention period and number of sites drive storage and server capacity. Ask the implementer to state the server and storage sizing assumptions in writing.
Engineering time for deployment	Internal platform or IT staff, or an implementation partner under a fixed-scope agreement	One-time	Heterogeneity is the main driver: each operating system, agent type and network zone adds deployment work. Request a written scope listing platforms, sites and agent rollout steps.
Tuning and integration	Internal engineers or the implementation partner	One-time, with periodic rework	Integration with an existing CMDB, asset register or ticketing system adds effort. Ask which integrations are included and which need separate scope.
Endpoint coverage validation	Internal staff or implementation partner	Recurring, at each inventory review	Measuring the share of software-capable endpoints covered by a tool requires an agreed endpoint list. Request the method used to build and reconcile that list.
Evidence upkeep	Internal compliance or IT operations staff	Recurring	Coverage reports, change records and exception handling must be kept current. Ask what reports the platform produces by default and what must be assembled by hand.
Ongoing support and upgrades	Internal team, or a support retainer with the implementer	Recurring	Agent updates, platform upgrades and security patches add work over time. Ask whether support is a fixed retainer or billed per incident.
External review	Independent auditor or assessor, or an external consultant for a readiness check	Recurring when assessments repeat	Scope size, number of sites and the depth of sampling affect the effort. Ask the reviewer to confirm the sampling approach in writing before work starts.
Auditor sampling	Independent auditor, paid by the organization being audited	Recurring per assessment cycle	Auditors sample endpoints and inventory records. Consistent naming, a stable asset list and clean reconciliation reduce sampling effort and follow-up questions.

Open-source tools that can produce inventory evidence

GLPI is an IT asset management platform. Its Assets module holds records for computers, monitors, software, network equipment, peripherals, printers, phones and racks. Records can be entered by hand, imported, or pushed automatically by the GLPI Agent, which uses native inventory built into GLPI since version 10. For Safeguard 2.4, the value is a central software register that is linked to each device, so you can show which endpoints report software and when they last reported. GLPI is licensed under GPL-3.0-or-later, which governs how you distribute modified copies. Running it internally for your own use generally does not trigger distribution obligations, but your counsel should confirm this for your deployment model.

Collection path: Confirm which endpoints run the GLPI Agent and whether the agent reports installed software on each operating system you run.
Device linkage: Software records tied to computer records give assessors a per-asset view that a spreadsheet rarely provides.
Manual entries: Records added by hand need an owner and a review date, or they will not reflect the current state.
Coverage reporting: Check that you can calculate the share of software-capable endpoints that report to GLPI, since that is the measure assessors use.
Version baseline: Confirm the GLPI release and agent version you deploy support native inventory as described.

Confirm with your environment whether GLPI's agent covers your mix of servers, laptops, containers and cloud workloads before treating it as the system of record.

Where organizations fall short on automated inventory

Most organizations that claim automated software inventory fail on coverage, not on tool selection. The gaps below are where assessors typically find the measurement breaks down, and each one maps directly to the coverage calculation the CIS Controls Assessment Specification uses for Safeguard 2.4.

No inventory tool named

The assessment specification fails Safeguard 2.4 when no software inventory tool is identified, so a process that relies on manual spreadsheets or occasional exports scores as a gap regardless of how accurate the data is. Before any other work, name the tool or tools in writing, state which asset types each one covers, and record who owns its configuration. An assessor will ask for that record first.

Coverage measured against an incomplete endpoint list

The coverage metric is the share of software-capable endpoints covered by at least one inventory tool, so the denominator matters as much as the numerator. Teams often count only the servers they manage and leave out laptops, virtual machines and cloud instances. Reconcile the tool's device count against the asset inventory from Safeguard 1.1, which the specification lists as a prerequisite, and document every endpoint excluded and why.

Unmanaged and offline devices

Agents cannot report from devices that are powered off, off the network for long periods or never enrolled. Contractor laptops, lab machines and field equipment commonly drop out of the count while still running software the organization has never reviewed. Check the last-seen timestamp for each endpoint, decide how long a silent device stays in scope, and define how an unreachable device is handled so it does not quietly fall out of the metric.

Agents installed but not reporting

A deployment dashboard that shows an agent as installed does not prove the tool is collecting software data. Agents can be installed with broken credentials, blocked by host firewalls, or left running with a stale configuration. Compare the number of agents deployed with the number that have reported in the last reporting window, and treat the gap as uncovered endpoints in your own calculation rather than as a rounding error.

Inventory not linked to unauthorized software response

Safeguard 2.4 discovery only has value if findings reach the process that handles them. When inventory data is not connected to Safeguard 2.3, unauthorized software is detected but never removed or documented as an exception. Define the handoff: which tool events create a review ticket, who reviews them, and how the outcome is recorded. Assessors look for that trail.

No documented exceptions or review cadence

Endpoints that are excluded from scanning, such as isolated systems or specialized operational technology, need a documented justification, a compensating method of inventory and an owner. Without that record, exclusions look like undisclosed gaps. Write each exception down with its scope and review date, and confirm the exception list matches what the scanner actually skips.

Questions buyers ask about Safeguard 2.4

Does Safeguard 2.4 apply at Implementation Group 1?

No. Safeguard 2.4 is assigned to Implementation Groups 2 and 3, not IG1. An organization working only through IG1 does not need to meet it to claim that Implementation Group. Still, IG1 includes the asset inventory and unauthorized software Safeguards that Safeguard 2.4 builds on, so an IG1 program is a sensible starting point. Confirm the exact Implementation Group assignment for your version in the CIS Controls Assessment Specification before you cite it in a report or contract.

Is one software inventory tool enough for Safeguard 2.4?

One tool can satisfy the Safeguard if it covers every software-capable endpoint in scope. The assessment specification does not require several tools. It checks whether at least one inventory tool is identified and how much of the estate that tool reaches. In practice, many environments use one tool for managed endpoints and add a second method for servers, cloud workloads or unmanaged devices that the first tool misses. Choose based on coverage gaps you can document, not on the number of products.

How is inventory tool coverage calculated for Safeguard 2.4?

Coverage is the share of software-capable endpoints that are covered by at least one inventory tool. You need two numbers: the count of software-capable endpoints in scope, taken from the enterprise asset inventory, and the count of those endpoints that report to a tool. Assessors also expect the Safeguard to fail when no inventory tool is identified at all. The assessment specification names Safeguards 1.1 and 2.3 as prerequisites because they produce the asset list and the unauthorized software data this measurement uses. Agree the definition of software-capable endpoint with your assessor before you start.

How long does it take to automate software inventory?

The duration depends on scope. The main variables are the number of endpoints and servers, how many operating systems and network zones are involved, whether you already have an asset inventory to reconcile against, and how many agents or connectors must be approved and deployed. A single managed fleet with an existing asset register takes far less time than a mixed estate with cloud workloads, air-gapped segments and legacy hosts. Ask any implementation partner for a timeline tied to a written scope with the endpoint counts and environments listed.

What does the work need from our team?

Four things, mainly. First, access to the asset inventory and the systems where agents will run, with change approval for deployment. Second, a decision on who owns the tool after handover, including who reviews results and who fixes gaps. Third, network and firewall rules that let agents or collectors report to the server. Fourth, someone who can confirm which endpoints count as in scope and which exceptions are approved. Without these inputs, coverage numbers will be hard to defend in an assessment, however good the tooling is.

Can we automate software inventory in-house?

Yes, if your team has engineers who can deploy agents, administer a database and server, maintain the scope definition and produce reports. Many organizations do this with the open-source tools described on this page. Consider the recurring work: agent updates, server upgrades, backups, onboarding of new endpoint types and periodic coverage reviews. Outside help is often used for the initial design, deployment and evidence pack, while the organization keeps operating the system. Either way, the organization owns the control and its result.

What can an implementation partner not do for the auditor?

An implementation partner cannot assess the control, issue a report, or certify that Safeguard 2.4 is met. DeployOpen prepares systems, configurations and evidence, such as tool deployment, coverage reports and documented procedures. Only an independent assessor or certification body can test those items and issue a conclusion. The organization remains responsible for its own control statements, for any gaps it chooses to accept, and for answering the assessor's questions. Ask any partner to confirm this split in writing before work starts.

How DeployOpen prepares inventory evidence for Safeguard 2.4

DeployOpen prepares the inventory tooling and the coverage evidence for Safeguard 2.4, but the enterprise owns the control and an independent auditor or assessor is the only party that issues a report or certificate. Work starts with a fixed-scope engagement agreed in writing before any system is touched. That document names the software-capable endpoint populations in scope, the inventory tools to be deployed, the hosting location inside the client's own cloud accounts, data centers or air-gapped network, the owners who approve changes, and the deliverables. Confirm early whether the scope includes servers, virtual machines, cloud workloads and employee laptops, because the coverage denominator is only as complete as the population named here.

Deployment is then carried out inside the client's infrastructure. Depending on the scope, this can mean installing and hardening a self-hosted inventory platform such as GLPI with its agent, or deploying the Wazuh Syscollector module, osquery or Velociraptor on the endpoints in the agreed population. The work covers service accounts with least privilege, network paths to the collection points, retention settings, role-based access to the inventory views, and a documented procedure for adding new endpoints. Ask for the configuration baseline and change record as part of the deliverables, since an assessor will want to see how the tool was set up, not only what it reports.

The final stage reconciles tool output against the enterprise asset inventory and the software inventory that Safeguards 1.1 and 2.1 call for, which the assessment specification treats as prerequisites. Endpoints the tools see but the asset list does not, and endpoints on the list that no tool reports, are investigated and recorded with an owner and a date. The coverage evidence then shows the share of software-capable endpoints covered by at least one inventory tool, the scope boundary, the reconciliation log and the exception register. Confirm with your assessor which reports and screenshots they accept, and how often they expect the coverage figure to be recalculated.

Safeguard 2.4 Utilize automated software inventory tools