Why a software inventory decides what the other CIS software controls can prove
Safeguard 2.1 asks the enterprise to keep a detailed record of every piece of licensed software installed on its enterprise assets, and to review and update that record at least twice a year. If you are preparing for an audit, answering a CIS-based customer requirement, or responding to an internal push to find out what actually runs on your estate, this is the first question to settle. Software nobody has written down is software nobody patches, licenses or manages. Unknown installs often sit outside change control, and they widen the attack surface without anyone noticing. That risk is the reason Safeguard 2.1 sits in IG1, the essential cyber hygiene set that CIS describes as the minimum standard for every enterprise.
The Safeguard is harder in practice than its wording suggests. Shadow installs made by users, leftover software from retired projects, and endpoints or cloud workloads that appear and disappear all make the record drift from reality. Many entries are also missing fields such as publisher, business purpose or deployment method, which is where accuracy is lost. The CIS Controls Assessment Specification scores Safeguard 2.1 as failing when no software inventory is provided or when it was last updated more than six months ago. Beyond that point, the accuracy score depends on how many entries carry complete information, so a stale or sparse list fails in two different ways.
This matters beyond Safeguard 2.1 itself. The assessment specification names Safeguard 2.1 as a prerequisite for 50 other Safeguards, including 2.2, 2.3, 2.5 and 2.6. Support status, unauthorized software handling and allowlisting all need a trustworthy list to start from. Before you commit budget to those controls, confirm who owns the inventory, how often it is refreshed, and whether a sample of entries can be traced to a real asset. An implementation partner can prepare the tooling and the record, but the organization must own the decisions about what is authorized, and only an independent assessor can give an opinion on whether the controls are met.
Which assets, software and teams fall inside the software inventory
Safeguard 2.1 sounds simple until someone asks what counts as an asset, what counts as software, and who owns the answer. The cards below cover the scoping decisions that set the size of the inventory, the teams that must contribute, and the third-party software that is easy to leave out.
Enterprise assets with installed software
Start with every asset where software is installed: workstations, servers, virtual machines, cloud workloads, and network and mobile devices that run operating systems or firmware-based applications. Hardware with no installed software, such as a passive switch, usually sits outside the software record but should stay in the asset inventory under Control 1. Confirm with your asset owner which device classes the software record must cover, and document the boundary so an assessor can see why a device was excluded.
Licensed versus all installed software
Safeguard 2.1 asks for licensed software, but the operating system, drivers, agents and utilities on each asset also run in the enterprise and shape its attack surface. Many teams keep a licensed-only list for procurement and a broader technical list for security. Decide early which view the inventory holds, because a licensed-only record will not show unsupported components that Safeguard 2.2 and 2.3 depend on.
SaaS, containers and developer tooling
Software delivered as SaaS has no installed binary on an endpoint, so it must be recorded through contracts, identity provider application lists or procurement data rather than a host scan. Container images and developer tools such as package managers, IDE plug-ins and build runners often run outside the standard image catalog. Ask engineering leads to list image registries, repositories and developer tool standards, and record each as a separate entry with an owner and business purpose.
Teams that own the inventory data
No single team holds all the facts. IT operations knows what is deployed, procurement and finance know what is licensed and renewed, application owners know the business purpose and version, and security decides which entries need review. Assign a named owner for each field of the inventory record and set a review cadence that meets the twice-yearly expectation. Without those assignments, entries go stale between reviews and the accuracy score falls.
Third parties with managed devices
Managed service providers, outsourced help desks, contractors and vendors that operate devices on your network often install software you never approved. Their endpoints and remote management tools belong in scope when they touch enterprise assets or data. Confirm in each service contract who records the software on managed devices, how the record reaches your inventory, and how often it is refreshed, and tie that obligation to Control 15 service provider management.
Software embedded in products
Appliances, industrial controllers, medical devices and other products often ship with embedded or vendor-managed software that standard endpoint tools cannot see. Treat each as a recorded entry with the vendor, version and support contact, even when the software is not updated by your team. Ask vendors for an software bill of materials or version statement during procurement, and mark any device that cannot report its software so the gap is visible to assessors and the risk owner.
How an assessor tests the software inventory against Safeguard 2.1
This table walks through how an assessor applying the CIS Controls Assessment Specification would test a software inventory against Safeguard 2.1, from the inputs requested to the findings that most often lower the score. Read each row as a question the assessor asks and the evidence you should have ready before the assessment starts.
| Assessment step | What the assessor checks | Evidence to prepare | Common finding |
|---|---|---|---|
| Input: inventory export | A software inventory is provided for the enterprise's licensed software installed on its assets | Full export from the system of record, with the export date and the tool that produced it | No inventory is provided at all, which fails the Safeguard outright |
| Input: last update date | The inventory was reviewed and updated within the six-month window the specification sets | Change history or review log showing dates of the last two updates | Export is current in name only, with the last real update older than six months |
| Input: asset coverage | The inventory reaches the endpoints and servers in scope, not just a subset of the estate | Count of assets in scope compared with assets reported in the inventory, with the scope statement | Servers are listed but laptops and workstations are missing, or cloud workloads are absent |
| Operation: existence check | Whether an inventory record exists for each piece of licensed software installed on enterprise assets | Sample of installed software from one or more endpoints matched to inventory entries | Software installed by users or bundled with other applications never appears in the list |
| Operation: date check | Whether the last update falls within six months of the assessment date | Dated review sign-off, such as meeting minutes or a ticket closing each review cycle | Review is performed informally, so no date can be shown to the assessor |
| Operation: field sampling | Whether sampled entries carry the title, publisher, business purpose and first-install or first-use date | Sample of entries with complete fields, plus the rule used to define a complete entry | Business purpose and first-install dates are blank for older or inherited software |
| Score: accuracy | How many inventory entries contain complete information, which determines the accuracy result | Completeness report showing the share of entries with all required fields populated | Fields are present but filled with placeholders such as unknown or TBD |
| Prerequisites | Safeguard 2.1 has no prerequisite Safeguards, so the assessor tests it on its own terms | Standalone inventory evidence, not a dependency on other Safeguard records | Teams assume prior Safeguards cover it and skip the inventory itself |
| Dependent Safeguards | Fifty other Safeguards list 2.1 as a prerequisite, including 2.2, 2.3, 2.5 and 2.6 | Confirm with the assessor which dependent Safeguards will rely on this inventory | A weak inventory undermines later results for unsupported, unauthorized and allowlisted software |
How to build a software inventory that passes the twice-yearly review
This sequence turns scattered software records into a single, dated inventory that an assessor can trace, check for completeness and see was reviewed on schedule. Each step produces an artifact that the next one depends on.
Set the field standard for every entry
Before collecting anything, write down the fields each software entry must carry. Required fields are the title, publisher, business purpose and date of first installation or use. Recommended fields are license count, decommission date, deployment method, versions, app stores and URL, included where they apply. Assign an owner for the standard, usually the IT asset or security lead, and approve it in writing. The output is a field standard that defines what counts as a complete entry, which is also what the assessment specification scores for accuracy.
Choose the discovery source and system of record
Pick one system that will hold the authoritative inventory. Open-source options such as GLPI can hold asset records manually or through its agent, Wazuh Syscollector can report installed software from endpoints into its indexer, and Dependency-Track is suited to software components and SBOM data rather than end-user applications. Many organizations use more than one source, so document which source feeds which fields and which one wins when they disagree. Confirm in each product's documentation which fields it collects natively. The output is a written data-source map with one named system of record.
Run discovery across in-scope enterprise assets
Collect installed software from the in-scope devices and servers using the chosen tools, and export the raw results with timestamps and the device each record came from. Cover operating systems, endpoints, servers and any virtual or cloud workloads in scope for the assessment. Record which assets were not reachable so gaps are visible rather than silently missing. The output is a raw discovery export that shows what was found, where and when.
Reconcile discovered software with purchasing and license records
Compare the raw export against procurement records, license agreements, subscription lists and vendor portals. Discovered software with no purchase or license record needs a justification or a follow-up with the owner, and licensed software that no longer appears on any asset may need a decommission date. Enter the missing fields during this pass, such as publisher, license count and first-use date, and note the source of each correction. The output is a reconciled inventory where every entry traces to both a discovered installation and a business record.
Assign a named owner to every entry
Give each software entry a business or technical owner who can confirm its purpose and approve its continued use. Owners are usually the department or system administrator who relies on the software, not the person who ran the scan. Keep the owner register in the same system of record so that questions about a product can be routed quickly. Confirm that every entry has an owner, and escalate orphaned entries to the asset owner or IT leadership. The output is an owner register linked to each inventory line.
Set the twice-yearly review calendar and change process
Schedule the review at least twice a year, and write down who runs it, who approves it and what is checked, such as completeness, owner confirmation and decommission status. Add a change process so that new installations are recorded in the inventory when they occur, with the owner and first-use date captured at approval time. Note that the assessment specification fails the inventory when it was last updated more than six months ago, so the change process matters between reviews. The output is a documented review calendar and change procedure.
Produce the first dated export and signed review record
Export the reconciled, owner-assigned inventory with a date and version number, then have the designated approver sign a review record that states the scope, sources, exceptions and open items. Store the export and record together in controlled storage so an assessor can retrieve the same version later. Ask your independent assessor to confirm which evidence format they accept before you finalize it. The output is the first dated inventory export and a signed review record that starts the evidence trail.
Which evidence shows a current software inventory
An assessor testing Safeguard 2.1 looks for a dated, complete software inventory and records that show how it stays accurate. The cards below cover the artifacts that carry that proof, how each one is kept current between reviews, and why the date of the last update matters as much as the content.
Dated inventory export with required fields
This is the core artifact: a full export of licensed software across enterprise assets, with each entry showing title, publisher, business purpose and date of first installation or use, plus licenses, versions and deployment method where relevant. Check that every entry has the fields the assessment scores for completeness, and that the export carries a generation date. Schedule the export from your inventory platform and store each run so the latest one can be shown on request. Keep the field list in a version-controlled schema so changes to required fields are traceable.
Discovery and reconciliation records
Automated discovery reports show what agents or scans actually found on each endpoint, and reconciliation records show how those findings were matched against the manual register. Differences between discovered software and recorded software are the gaps an assessor will probe first. Keep the discovery run logs and the reconciliation worksheet together, with each discrepancy assigned an owner and a closing date. Confirm which discovery tool covers which asset class in your environment, since coverage varies by platform.
Owner and business purpose register
Each software entry needs a named owner and a documented business purpose, because the purpose field is what separates authorized software from unexplained installs. Maintain the register as a table linked to the inventory record, with the owner's role, the business function served and the date the purpose was last confirmed. Ask owners to confirm entries when they change teams or when a product is re-platformed. Without this register, the purpose field tends to decay into placeholder text that reviewers will reject.
Twice-yearly review sign-off
Safeguard 2.1 calls for review and update at least twice a year, so the sign-off record is the proof that the review happened. The record should name the reviewers, state the inventory version reviewed, list the changes made and carry a dated approval. Set a review calendar with two fixed dates per year and assign a reviewer who is independent of the person maintaining the inventory. Confirm with your assessor how they will sample sign-offs across the year.
Change records for installs and retirements
Change tickets for new installations, upgrades and decommissions show that the inventory moves with the environment instead of being rebuilt before an audit. Each record should reference the inventory entry it changes, carry the date of first installation or retirement and record the decommission date where one applies. Connect the ticketing system to the inventory so that a closed change ticket cannot leave the inventory untouched. Sample a handful of recent changes against the inventory to confirm the link holds.
License reconciliation statements
License reconciliation compares the number of licenses purchased with the number of installations and users recorded in the inventory, and flags any overuse or unused entitlements. It is useful evidence because it ties the inventory to procurement and contract records, which an assessor can verify independently. Run the reconciliation at each review and keep the output with the sign-off. Ask your software asset management team which entitlement source is authoritative, since contract and purchase records often disagree with installed counts.
What a software inventory costs to build and keep current
This table compares the cost components of building and maintaining a Safeguard 2.1 software inventory, showing who is paid for each, whether it is one-time or recurring, and what drives it up. No prices or durations are given because none are supplied; use the drivers and quote requests to scope a real estimate.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it |
|---|---|---|---|
| Inventory tooling or licenses | Software vendor or open-source project host; internal team for hosting and upgrades | Recurring for commercial licenses; open-source removes license spend but keeps hosting and upkeep | Number of endpoints with agents, number of software titles, and whether existing asset or CMDB licenses can be reused |
| Discovery and field design | Internal administrators, sometimes with an implementation partner | One-time, repeated when the schema changes | Number of asset types, required fields chosen (title, publisher, purpose, first install date and others), and quality of existing records |
| Agent deployment and data reconciliation | Internal endpoint or platform engineers | One-time for rollout, then ongoing for new hosts | Mix of Windows, Linux and macOS, cloud images, and whether devices are on the corporate network |
| Owner time for entries and reviews | Application and business owners, paid through their own budgets | Recurring, at least twice a year for the Safeguard review | Number of owned applications, distributed teams, and how many owners must confirm business purpose |
| Evidence upkeep and reporting | Internal compliance or security staff | Recurring, with each review cycle and each audit period | Number of reports kept, retention rules, and whether the inventory feeds dashboards automatically |
| Cloud and SaaS sprawl coverage | Cloud platform and SaaS administrators | Recurring as new accounts and subscriptions appear | Number of cloud accounts, unmanaged SaaS subscriptions, and whether procurement records reach the inventory |
| External assistance for setup | Implementation partner or consultant, under a written scope | One-time for setup, optional retainers for upkeep | Size of the estate, integration count, and whether the partner must build fields or reports from scratch |
| Auditor or assessor sampling time | Independent auditor or assessor, under its own engagement terms | Recurring with each assessment cycle | Number of samples requested, count of inventory gaps found, and how easily evidence can be retrieved |
Which self-hosted open-source tools can produce software inventory evidence
GLPI is an open-source IT service management platform, licensed under GPL-3.0-or-later. Its Assets module manages computers, software, monitors, network equipment, peripherals, printers, phones and racks, so it works well as a system of record where the inventory itself is kept and reviewed. Software records can be entered by hand or pushed automatically by the GLPI Agent, which uses native inventory built into GLPI since version 10.
- Central register: Computers and the software installed on them sit in one database that can be filtered, exported and reported on.
- Agent-based collection: The GLPI Agent sends software data from enrolled machines, reducing manual entry for devices it reaches.
- Manual entry for gaps: Software on devices the agent cannot reach, or licensed items with no installed footprint, can be added by an administrator.
- Not covered: Business purpose, the owner of each entry, and the twice-yearly review sign-off must still be recorded by the organization in its own process.
Confirm with your environment whether the GLPI Agent can reach every device class you must inventory, and whether your review workflow lives inside GLPI or in a separate governance record.
Wazuh is an open-source security platform licensed under GPL-2.0-only. Its Syscollector module runs on each endpoint and collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates. The data is stored in the Wazuh indexer and displayed as inventory views and reports in the dashboard, which makes it a strong source of current, machine-observed software data.
- Continuous endpoint data: Syscollector reports the software observed on each agent-enrolled endpoint, so the inventory reflects what is installed rather than what was requested.
- Dashboard views and reports: Inventory data can be filtered by agent and exported for review meetings.
- Adjacent context: The same agent data shows services, processes and users, which helps assessors connect software to the asset and account records.
- Not covered: Software on devices without a Wazuh agent is not collected, and the tool does not record business purpose, owner or license terms for each product.
Confirm with your environment which endpoints can run the agent, and how Syscollector scope and collection intervals are configured for your fleet.
OWASP Dependency-Track is an open-source component analysis platform licensed under Apache-2.0. It consumes and produces CycloneDX software bills of materials (SBOMs) and vulnerability exploitability exchange (VEX) data, identifies components with known vulnerabilities, outdated or modified components and license risk, and tracks license use by component using SPDX license IDs. It is most useful for the application and library layer of the inventory, which installed-software scans often miss.
- SBOM ingestion: CycloneDX SBOMs from build pipelines or other tools are stored as a component inventory for each project.
- SBOM output: Dependency-Track can produce CycloneDX SBOMs, which can be shared with customers or auditors.
- License tracking: Components are linked to SPDX license IDs so license use can be reviewed by component.
- Not covered: It does not discover software on endpoints or servers, so it complements rather than replaces an endpoint inventory. Business purpose and owner data remain the organization's responsibility.
Confirm with your environment which applications and build pipelines can supply SBOMs, and whether your inventory scope includes application dependencies or only installed software.
Trivy is an open-source scanner licensed under Apache-2.0. It identifies the OS packages and software dependencies present in a target, can produce them as a software bill of materials, and can also scan existing SBOMs. It is typically run against container images, filesystems or repositories, so it fits well into build and release workflows where software content must be documented before deployment.
- Target scanning: Trivy inspects an image, filesystem or repository and lists the OS packages and dependencies it finds.
- SBOM generation: The scan output can be produced as an SBOM for storage or hand-off.
- Existing SBOM scanning: SBOMs created elsewhere can be re-scanned, which helps when inventory data comes from several sources.
- Not covered: Trivy reflects only the targets you point it at, so it does not inventory the whole enterprise by itself. Ownership, business purpose and review records still come from the organization.
Confirm with your environment which images, hosts and repositories must be scanned, and how the output will be stored and linked to the central inventory record.
Where software inventories usually fail the assessment
Assessors test Safeguard 2.1 on freshness and completeness, and most failures trace back to a few predictable gaps. The cards below cover what the assessment checks, where inventories fall short, and the closure step that usually resolves each gap.
Inventory older than six months
The assessment specification scores Safeguard 2.1 as failing when the software inventory was last updated more than six months ago, regardless of how good the content is. An inventory that was accurate at the last audit can fail on the day it is reviewed. Check the last-updated timestamp on the inventory itself and on each data source feeding it. Close the gap by scheduling an automated refresh and a recorded manual review so the date moves forward on a fixed cycle.
Discovery that skips user endpoints
Many inventories are built from server build records, configuration management data or cloud accounts, so laptops and desktops that users installed software on never appear. Software on user endpoints is often where unauthorized tools surface, so the gap matters for Safeguards 2.2 and 2.3 as well. Compare the inventory's asset count against the device inventory from Control 1 to find the missing population. Close the gap by pointing an endpoint agent or software collector at workstations, not only servers.
Missing purpose and first-install dates
Entries that list only a title and publisher cannot show why software is present or how long it has been there, which assessors need to judge accuracy. The specification scores the share of entries with complete information, so sparse records lower the score even when the software is real. Under Safeguard 2.1, the entry should carry business purpose and date of first installation or use. Close the gap by adding these fields to the intake form for new software and backfilling existing entries from change records.
Entries with no named owner
An entry without an accountable owner cannot be confirmed, retired or justified during review, so it tends to remain in the inventory indefinitely. Assessors reading the record look for who approved the software and who answers for it. Ownership also drives the monthly support and unauthorized software checks in later Safeguards. Close the gap by requiring an owner field on every entry and reassigning orphaned entries to the business unit that uses them.
SaaS and developer tooling left out
Browser-based SaaS subscriptions, package managers, container base images and developer tools often sit outside the endpoint scan, so the inventory understates the software in use. Procurement records can show subscriptions that were never installed locally. Each omitted category is a potential gap that an assessor can find by sampling business applications. Close the gap by reconciling the inventory against finance and procurement records for SaaS and against build manifests or software bill of materials exports for developer tooling.
No record of the twice-yearly review
Safeguard 2.1 calls for the inventory to be reviewed and updated at least twice a year, and the assessment looks for evidence that the review happened. A current inventory without a dated review record can still leave the enterprise unable to show compliance. Retain the review minutes or ticket, the reviewer, the date and the changes made. Close the gap by creating a recurring review task with a stored sign-off so each cycle produces a dated artifact.
Who owns the software inventory and what a partner can take on
Your organization owns the software inventory as a control. Accountability for what is licensed, who uses it and why it exists stays with your staff, because those facts come from business owners and procurement records that an outside party cannot verify on its own. Your team sets the scope of licensed software, assigns an owner to each entry, and signs off on each review cycle. Safeguard 2.1 expects the record to be reviewed and updated at least twice a year, so the review calendar and its approvals must be run internally.
- Scope and policy: Decide which assets and which kinds of licensed software fall inside the inventory, and document that decision.
- Business owners: Name a person for each entry who can confirm the business purpose, the license count and the decommission date.
- Reviews and sign-off: Run the twice-yearly review, record who approved it and keep the dated approval on file.
- Exceptions: Decide how gaps are handled, such as software that cannot be discovered automatically, and track each one to closure.
Before engaging anyone, confirm that you can name an accountable owner for every licensed product and that someone internal will sign each review.
An implementation partner such as DeployOpen can plan and build the technical side of the inventory inside your own environment. That work includes deploying discovery and inventory tooling, such as GLPI or Wazuh, on infrastructure you control, reconciling data from procurement, endpoints and identity systems, and writing the process documentation. The partner then assembles an evidence pack that your team can hand to an assessor. The partner does not issue audit reports, attestations or certifications, and it does not decide whether your inventory is compliant.
- Planning and deployment: Design and deploy self-hosted discovery and inventory tooling in your cloud accounts, data centers or air-gapped network.
- Field standard: Design the inventory fields, such as title, publisher, business purpose and first-use date, and the rules for completeness.
- Data reconciliation: Match records from endpoints, license records and identity systems so duplicates and gaps are visible.
- Documentation and evidence: Document the process and prepare the evidence pack, including exports, review records and configuration.
Most engagements are fixed-scope, so ask for the written scope, deliverables and timelines before work starts.
An independent auditor or assessor tests the inventory against the CIS Controls Assessment Specification and reaches its own conclusion. The assessor samples entries, checks dates and completeness, and confirms that the process ran as documented. Only an independent party can issue a report or certificate, and the assessor's role is to test your control, not to build it.
- Independent testing: Select samples, compare entries with live endpoints and license records, and check review dates against the required cadence.
- Completeness checks: Measure how many entries carry the required information and whether the record was updated within the required window.
- Why the auditor cannot design it: An auditor who designed the inventory would be testing its own work, which removes the independence the assessment depends on.
- Reporting: The assessor documents findings and reaches its own conclusion, which your organization and any partner cannot issue.
Before hiring an assessor, confirm that its engagement is separate from the team that built the inventory.
How much effort does a CIS software inventory take, and can we do it ourselves?
How much effort and cost does a CIS software inventory take?
The effort depends mostly on how many assets and software sources you have, how fragmented your records are, and whether the inventory is built once or kept current automatically. No fixed figure applies to every estate, so ask for a quote built from a written scope. The main cost components are staff time to collect and reconcile records, tooling (licenses, hosting and maintenance), and any outside help. Costs that recur include the twice-yearly review, keeping entries complete as software is installed or retired, and running the tooling. Ask any provider to break its quote into discovery, reconciliation, tooling, documentation and recurring review so you can see what is one-time and what repeats.
How long does it take to be ready for an assessment?
The pace is set by the state of your existing records, not by the Safeguard itself. An organization with a current asset register and procurement history can usually move faster than one whose software is spread across unmanaged endpoints, shadow purchases and undocumented servers. The assessment specification fails an inventory that is missing or was last updated more than six months earlier, so the inventory must be current at the time of review, not just complete once. Before committing to a timeline, confirm which asset populations are in scope, who can grant access to each system, and how many reconciliation rounds your records will need.
What does the work need from our organization?
Plan for named owners from IT operations, procurement or finance, and the security team that will review the result. Procurement and accounts payable records show which licenses were bought, but they rarely match what is installed, so those teams are needed to reconcile the two. Engineers need administrative access or agent deployment rights on endpoints and servers to collect installed software accurately. Each entry needs a business purpose and an owner, which usually requires input from application owners who can explain why software exists. Confirm these responsibilities in writing before work starts, because gaps in ownership are the most common reason inventories go stale.
Can an internal team build this inventory without a partner?
Yes, if the team has time, access and clear ownership. Safeguard 2.1 does not require a particular tool or a third party, and many organizations build the inventory with existing IT staff. The harder part is sustaining it: the review must happen at least twice a year, entries must stay accurate between reviews, and the team must produce evidence that an assessor can trace. Internal teams often underestimate reconciliation work across procurement, endpoints and application owners. A partner can help by preparing the tooling, the data model and the evidence pack, but the organization still owns the inventory and its results.
Do open-source tools remove the cost of software licenses?
Open-source tools remove license fees for the tool itself, but they do not remove hosting, configuration, integration or staff effort. Platforms such as GLPI, Wazuh and OWASP Dependency-Track each have their own deployment and upkeep needs, and they still need someone to define fields, maintain connectors and review results. Confirm the license terms of each component with its publisher before you deploy it. Ask any implementation partner to separate the one-time setup from the recurring operating cost, so the comparison with commercial tooling is based on total effort rather than on license price alone.
How often must the review happen, and what counts as evidence?
Safeguard 2.1 expects the software inventory to be reviewed and updated at least twice a year. Evidence is a dated inventory export showing the entries, the fields each entry carries (title, publisher, business purpose, first installation or use date, and where relevant license count, versions and decommission date), and a record of the review and who approved it. Assessors also look at how many entries are complete, since the assessment specification scores accuracy on that basis. Keep change records between reviews so you can show the inventory was maintained, not only refreshed before an audit.
Can a partner make the assessor's job easier without changing who issues the report?
Yes. A partner can prepare the inventory, document how records are produced, and assemble the evidence an assessor will request, so the review is faster and easier to follow. That work does not change who decides the outcome. The organization owns its controls, and only an independent auditor, assessor or certification body issues a report or certificate. CIS itself does not certify organizations against the Controls, so any claim that an outside party has verified your implementation should be checked against the scope and the assessor's written conclusions.
How DeployOpen works on this
DeployOpen treats Safeguard 2.1 as the foundation for the other software Safeguards, so the inventory is scoped, built and documented in a form an assessor can test. DeployOpen prepares the inventory and its evidence inside your own infrastructure, while your organization owns the Safeguard and an independent assessor makes the judgment.
How we scope
- The written scope names which asset classes, networks, cloud accounts and sites the software inventory must cover.
- We agree which inventory fields are required and which are recommended, such as publisher, business purpose and first installation date.
- The scope states who owns the twice-yearly review and how the last-updated date will be recorded for assessors.
How we build
- We deploy open-source inventory tooling in your environment, such as GLPI Assets or Wazuh Syscollector, and configure it to collect installed software.
- We test the collected data against a sample of endpoints to confirm entries are complete and accurate before the inventory is treated as final.
- Where you need software bills of materials, we set up Dependency-Track or Trivy to generate and track them alongside the inventory.
How we hand over
- You receive the configured inventory, a field-by-field data dictionary and the procedure for the twice-yearly review.
- Documentation records the tool configuration, data sources, review dates and known gaps so an assessor can trace each entry.
- We walk your team through the evidence an assessor will request, including the last-updated record and completeness results.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work is complete.
- Retainer support can keep the inventory current as platforms change, and cover the review cycle that Safeguard 2.1 requires.
- Before any work starts, confirm with us in writing which support level, scope and deliverables apply to your environment.
