What a CIS Safeguard 1.1 asset inventory must contain and why it comes first
Safeguard 1.1 asks you to establish and maintain an accurate, current inventory of every enterprise asset that can store or process data, and to review it at least twice a year. The inventory has to cover end-user devices (including mobile), network equipment, IoT devices and servers, whether they sit on premises, run virtually, work remotely or live in the cloud. It also has to include assets that regularly connect to your network but that you do not fully control, such as contractor laptops. For each asset, record the static network address if there is one, the hardware address, the machine name, the asset owner, the owning department and whether the asset is approved to connect. Within the Devices asset class and the Identify security function, Safeguard 1.1 sits in IG1, so it is part of the essential cyber hygiene baseline every enterprise is expected to meet.
The inventory comes first because the assessment specification lists no prerequisite Safeguards for 1.1, while 64 other Safeguards name it as a prerequisite, including 1.2, 1.4, 2.3 and 2.4. Unauthorized assets (1.2) can only be identified against an approved list, DHCP logs (1.4) only update a record that exists, and software inventory and allowlisting (2.3 and 2.4) depend on knowing which devices they apply to. An assessor who finds no inventory, or one last updated more than six months ago, will score 1.1 as failing before looking at anything else. Confirm the update date and the review cadence on the day of the assessment, because a stale record fails even when the devices themselves are well managed.
The hard part is rarely the first list. Shadow IT adds devices outside procurement, cloud and virtual workloads appear and disappear faster than a spreadsheet can track, and mobile devices may be owned by staff but used for work. Records also go stale when machines are reimaged, renamed or handed to a new owner. Ask who owns the inventory process, which tools feed it (for example, a mobile device management console, a hypervisor and cloud account exports), and how new assets get an owner before they go live. Your inventory platform, such as the asset module of an open-source service desk, should hold those fields, but you still have to confirm that every field is populated and reviewed.
Which assets and teams fall inside the CIS Safeguard 1.1 asset inventory
Safeguard 1.1 covers any enterprise asset able to store or process data, so the first job is deciding where the boundary sits. The cards below cover the asset types, connection models and ownership questions that most often decide whether an inventory is complete when an assessor reviews it.
End-user and mobile devices
Laptops, desktops, tablets and phones are the most visible part of the inventory, and mobile devices are where gaps usually appear. Safeguard 1.1 expects each record to carry a hardware address, machine name, owner, department and an approval status, which is hard to keep current for devices that roam. Mobile device management tools can supply much of this data for phones and tablets, so confirm which fields your MDM platform actually exports before you rely on it.
Network, IoT and OT devices
Switches, routers, firewalls, printers, cameras, sensors and building controllers all connect to the network and can store or process data. These devices often lack an agent, so they are easy to omit from an inventory built only from managed endpoints. Ask who is responsible for each device class, and confirm that the inventory includes the network address if static, which is one of the fields Safeguard 1.1 names.
Servers and workloads
Physical servers, hypervisors and their guest machines belong in the inventory, and so do the containers and services they host where your assessor treats them as assets. Virtual machines can be created and destroyed within a day, so the record must reflect the current state rather than a quarterly snapshot. Check that the inventory's review cycle is at least twice a year and that decommissioned workloads are removed.
Cloud, virtual and remote assets
Cloud instances, SaaS tenants, home-office equipment and virtual desktops all fall within the scope of Safeguard 1.1 when they store or process enterprise data, whether on premises, virtual, remote or in the cloud. Cloud assets are usually provisioned by teams outside central IT, so the inventory needs an automated feed from each cloud account rather than manual entries. Confirm that every account and subscription is listed, including those created for pilots.
Assets outside enterprise control
Contractor laptops, personal phones used for work email and visitor devices often connect regularly without being enterprise controlled. Safeguard 1.1 expects these assets to appear in the inventory when they regularly connect, which means recording them with an owner and an approval status even if IT does not manage them. Decide how such devices are approved or restricted, and document that decision in the inventory procedure.
Ownership across IT, cloud, OT and facilities
The inventory fails when no team admits to owning a class of asset. Building systems may belong to facilities, production lines to OT engineering and cloud accounts to a platform team, while IT holds the central record. Assign an asset owner and department to each asset class in writing, and agree which team updates each feed. Assessors look for this ownership evidence when they test accuracy against discovered assets.
How an assessor tests the CIS Safeguard 1.1 asset inventory
This table compares the four measures the CIS Assessment Specification uses for Safeguard 1.1, what each one looks at, the evidence to prepare and the findings that usually lower a score. Read it as a checklist: a stale or missing inventory fails outright, while accuracy, completeness and procedure reviews determine how much of the inventory passes.
| Measure | What the assessor checks | Evidence to prepare | Common findings |
|---|---|---|---|
| Currency gate (fail at 0) | Whether an inventory exists and was last updated within six months. A missing or older inventory scores 0 regardless of its quality. | Inventory export showing last-updated date, change history or system timestamps, and the date of the most recent review. | Inventory exists only as a spreadsheet last touched a year ago; no one can show when it was updated. |
| Accuracy score against discovered assets | Compares assets found by discovery tools on the network with records in the inventory, and checks that recorded assets are real and reachable. | Discovery scan results (active, DHCP or passive) side by side with the inventory export, plus the scan dates and scope. | Discovery finds laptops, virtual machines or cloud instances that have no record, or records for hosts that were retired long ago. |
| Completeness score for detailed records | Checks that each record carries the fields CIS expects: network address if static, hardware address, machine name, asset owner, department and network approval status. | Field-level export of the inventory, with a count of records missing each field and the rule used to decide what is required. | Owner and department fields are blank for most endpoints, or hardware addresses are absent for virtual and cloud assets. |
| Manual review of inventory procedures | Confirms that a documented process defines how assets are added, changed, retired and reviewed, and that the process is followed. | Written inventory procedure, assigned roles, review records from at least the past two reviews, and onboarding and offboarding tickets. | A procedure exists but reviews are not recorded, or the process covers only IT-issued devices and ignores personal or contractor equipment. |
| Scope of asset types | Checks that the inventory reaches end-user, mobile, network, IoT, server, virtual, remote and cloud assets, including non-enterprise devices that regularly connect. | Asset class breakdown from the inventory, and a list of connection points (VPN, wireless, cloud accounts, mobile device management) used to identify assets. | The inventory matches only the server estate, while laptops, mobile devices, network gear and cloud workloads are missing. |
| Ownership and approval status | Checks that every asset has a named owner who can answer for it and a recorded decision on whether it is approved to connect. | Owner assignments with contact details, and approval records or onboarding forms for each asset class. | Owners are departed employees or a shared team mailbox, so no one can confirm the asset is still needed. |
How to build a CIS Safeguard 1.1 asset inventory step by step
This sequence takes an organization from no defined inventory to a documented, owned and first-checked record of enterprise assets, the baseline that Safeguard 1.1 asks for and that an assessor will test against discovery results.
Define the asset scope and classes
Start by writing a scope statement that lists every class of enterprise asset able to store or process data: end-user devices including mobile, network equipment, IoT, servers, virtual machines, cloud resources and remote devices. Include assets that regularly connect to the network but are not enterprise controlled, such as contractor or personal devices used for work. Agree the scope with IT operations, security and the business units that own systems, then have the approver sign it. The step is done when the scope statement is signed and every asset class has a named owner for keeping it current.
Choose a system of record
Select one authoritative register, such as a configuration management database or an asset module in an open-source IT service management platform like GLPI, and retire parallel spreadsheets as sources of truth. Confirm that the tool can hold every field Safeguard 1.1 expects: static network address, hardware address, machine name, asset owner, department and network approval status. Ask the vendor or your own test environment to confirm each field and any custom field you need, since capabilities differ by version. The step is done when a written decision record names the system, its administrators and where the data is stored.
Load discovered and known assets
Import what you already know from procurement records, hypervisor and cloud inventories, directory services and mobile device management, then add what automated inventory agents report from endpoints. Where you deploy an agent such as the Wazuh Syscollector module, it can collect hardware, operating system, installed software, network interfaces and services for the inventory views. Tag each record with its source so you can later see which entries were confirmed by a tool and which were entered by hand. The step is done when the register holds one record per asset, with duplicates merged and the source of each record visible.
Assign owner, department and approval status
For each record, assign an accountable owner and a department, and mark whether the asset is approved to connect to the network. Assets without an owner are the most common gap found in reviews, so treat them as an exception queue to be resolved, not as a default value. Record the static network address where one exists and leave it blank for dynamically addressed devices rather than guessing. Where mobile devices are managed centrally, use that tool as the source for their owner and approval fields. The step is done when no record lacks an owner, department or approval flag, or when each remaining gap has a dated ticket.
Set the review cadence and currency rule
Write a review procedure that requires the inventory to be reviewed at least twice a year and records who performs each review and what they check. Add a currency rule of your own design that flags any inventory last updated more than six months ago, because the CIS assessment specification scores a missing or stale inventory as failing. Schedule reminders in the system of record and keep the review log with the procedure. The step is done when the procedure is approved, the reminders exist, and the first review date is in the calendar.
Run a first accuracy check against discovery
Compare the register with the results of an independent discovery run, such as an active scan or agent data, and produce a reconciliation report. The report should list assets found by discovery but missing from the register, register entries not seen by discovery, and records with missing fields. Measure the share of discovered assets that match a record, since the assessment specification reports an accuracy score against discovered assets, and the share of records with all required fields, which relates to its completeness score. Route each discrepancy to an owner with a decision: add, correct or retire. The step is done when the reconciliation report is filed and the open discrepancy list is assigned.
Which evidence shows the CIS Safeguard 1.1 asset inventory is current
An assessor testing Safeguard 1.1 looks for one thing: whether the inventory is accurate, complete and recently maintained. The cards below cover the artifacts that prove this, from the record itself to the procedure and sign-offs behind it, and they work together, because a clean export means little without reconciliation and review records to back it up.
Inventory export with required fields
The inventory export is the primary artifact. For each asset, it should record the network address if static, the hardware address, the machine name, the asset owner, the department and whether the asset is approved to connect to the network. Check that every row has all six fields populated, and sample rows for blanks or placeholder values such as "unknown" or "TBD". An export missing owners or approval status will fail the completeness review even if the asset count looks right. Pull the export directly from the system of record, not from a spreadsheet someone edited by hand.
Last-updated record and review sign-offs
The assessment specification fails Safeguard 1.1 when the inventory was last updated more than six months ago, so the export must carry a visible last-updated timestamp. Keep dated review sign-offs from the inventory owner, showing that the inventory was reviewed at least twice a year as the Safeguard requires. Records of who reviewed, what changed and which assets were added or retired make the review trail credible. Without sign-offs, a current-looking export can still be challenged.
Reconciliation between inventory and discovered assets
An assessor measures accuracy by comparing the inventory with what discovery tools actually see on the network. Keep dated reconciliation reports that list discovered assets missing from the inventory, inventory entries never seen on the network, and the disposition of each difference. Feeds from active scanning, DHCP logs or passive discovery can supply the discovered side. Investigate every unexplained gap, because an unmatched device with no owner is the finding an assessor is most likely to write up.
Documented inventory procedure
A written procedure shows how the inventory is created, updated, reviewed and retired. It should name the inventory owner, the sources that feed it, the required fields, the review cadence and the steps for adding assets such as cloud instances, virtual machines and remote laptops. Assessors use this procedure for the manual review portion of the Safeguard, so it must match what staff actually do. Confirm that the procedure version and approval date are recorded, and that it covers assets that are not enterprise controlled but regularly connect.
MDM reports for mobile devices
Safeguard 1.1 covers end-user devices including mobile phones and tablets, and CIS notes that mobile device management tools can help maintain that part of the record. Export MDM device lists that show device identifiers, assigned users, operating system versions and enrollment status, then match them against the main inventory. Mobile devices that are enrolled in MDM but absent from the inventory, or inventory entries with no MDM record, both need a documented explanation. Confirm which fields your MDM platform exports before you promise an assessor a specific format.
Keeping evidence current between audits
Assessors test the state of the inventory on the day they look, so evidence has to be produced continuously. Schedule exports, reconciliations and sign-offs on a fixed calendar and store them with dates. Map the requirement to the CIS Controls Navigator, which links Safeguard 1.1 to NIST CSF 2.0 ID.AM-01 and ID.AM-08, NIST SP 800-53 Rev. 5 CM-8 and PM-5, ISO/IEC 27001:2022 Annex A 5.9 and 8.8, SOC 2 CC3.2 and CC6.1, and PCI DSS v4.0 requirements 9.5.1 and 11.2. Confirm each mapping against the Navigator before relying on it, since mappings change between releases.
What meeting CIS Safeguard 1.1 costs in money and effort
This table breaks down the money and effort behind keeping a detailed asset inventory under Safeguard 1.1, showing who is paid, what recurs and what drives each cost. No fee figures were published for this work, so use the table to shape a written, fixed-scope quote and to ask the right questions of each vendor.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Tooling and licenses | Recurring (subscriptions) and one-time (setup) | Mobile device management, discovery and commercial CMDB products carry license fees. GLPI and Wazuh are open source and remove license spend, though hosting and support still apply. | Confirm which asset types the inventory must cover, then reuse tools already licensed before buying new ones. |
| Engineering time to build the register | One-time | Defining the required fields (address, machine name, owner, department, approval status), importing existing records and connecting feeds from DHCP, discovery and endpoint agents. | Agree the field list and data sources in writing before work starts, and limit the first release to devices already under management. |
| Integrations and data feeds | One-time, with recurring upkeep | Each new source (MDM, cloud accounts, DHCP logs, endpoint agents) needs mapping and testing, and each source change can break a feed. | Prioritize the sources that cover the most asset types, and document feed owners so changes are reviewed. |
| Ongoing reconciliation and review | Recurring | Safeguard 1.1 requires review at least twice a year. Larger and more dynamic estates (cloud, remote, mobile) need more reconciliation work. | Automate discovery comparisons, and assign named owners for each asset class so reviews are short and repeatable. |
| Owner and approval maintenance | Recurring | Records go stale when staff change roles or assets change hands. Each asset needs a current owner and a decision on whether it is approved to connect. | Tie ownership to HR and procurement events so changes update the register as they happen. |
| Evidence upkeep | Recurring | Assessors look for a dated inventory, a record of the last update and proof of the review process. Gaps in these records cause a failed score. | Keep exports of each review with dates and sign-offs in a fixed location, rather than rebuilding them before an assessment. |
| External review or testing | Optional, periodic | Independent reviewers, consultants or testers may check accuracy against the network. Scope, sample size and fees come from the provider's written proposal. | Limit external work to a defined sample and ask for a fixed-scope quote with named deliverables. |
| Auditor sampling | Recurring, set by the assessment or audit | Auditors choose samples from the inventory and compare them with live systems. Cost depends on how many records and reporting cycles the auditor reviews. | Ask the auditor how samples are chosen and make sure the inventory can produce them quickly. |
Which open-source tools can produce CIS Safeguard 1.1 inventory evidence
Safeguard 1.1 needs one current inventory record per enterprise asset, with defined fields and a review cadence. Two open-source platforms can hold and populate that record, but each covers a different part of the asset estate, so the choice depends on what your inventory must include and where the gaps sit.
GLPI for the managed asset register
GLPI (GPL-3.0-or-later) is an IT asset management and service desk platform. Its Assets module records computers, monitors, software, network equipment, peripherals, printers, phones and racks, and it accepts entries typed in by staff or pushed automatically by the GLPI Agent through native inventory, available since version 10. This makes it a practical system of record for the fields Safeguard 1.1 asks for, such as machine name, hardware address and department. Confirm that the owner and approval-to-connect fields are configured as you need them, since these usually require custom fields or a defined business process.
Wazuh for endpoint inventory evidence
Wazuh (GPL-2.0-only) uses its Syscollector module to collect hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates from each monitored endpoint. The results are stored in the Wazuh indexer and shown in dashboard inventory views and reports. This gives assessors a current, machine-generated view of agent-managed devices that can be compared with the register. Wazuh does not establish ownership or approval status, and it does not see devices that run no agent, so it complements rather than replaces a managed register.
Closing the mobile device gap
Safeguard 1.1 covers end-user mobile devices, and CIS notes that mobile device management tools can help. Neither GLPI nor Wazuh is presented here as a mobile device management product, so phones and tablets may need a separate source for their records. Ask whether your mobile fleet is enrolled in an MDM platform, whether its export includes the hardware address and owner, and how those records are merged into the main inventory. Without this step, an assessor may find mobile assets missing from the evidence.
Covering non-agent and remote assets
Devices that cannot run an agent, such as printers, network appliances, IoT sensors and unmanaged remote systems, are the most common reason an inventory fails Safeguard 1.1. GLPI can hold these as manual or imported entries, but someone must keep them current. Wazuh only sees hosts where its agent is installed. Pair either tool with network discovery or DHCP logs so that unmanaged assets that regularly connect still appear. Confirm, with your own network team, which segments you cannot instrument before you commit to an approach.
Confirming fit and license terms
Before adopting either platform, test it against a sample of your real estate: count the assets it reports, compare that count with your existing records, and note which fields are blank. Review the license terms with your legal or procurement team, since GPL-3.0-or-later and GPL-2.0-only carry different obligations when code is modified or distributed. Ask your implementation partner to document the configuration, data sources and review cadence, because these become the evidence an independent assessor will test.
Who owns, who implements and who assesses the inventory
Your organization owns Safeguard 1.1. The inventory is a business record of which assets exist, who is responsible for them and whether they are allowed on the network, so the decisions behind each record sit with your staff, not with any outside firm. Ownership means someone accountable names the owner of each asset, sets the rules for what counts as an enterprise asset, and approves which devices may connect. These decisions must be made and recorded by people inside the organization, even when tools collect the data.
- Inventory owner: A named role, usually in IT operations or the CMDB team, is accountable for the inventory as a whole and for its review at least twice a year.
- Asset owners: Each asset record names a responsible person or department, which the Safeguard expects the inventory to show.
- Approval decisions: Staff decide whether each asset is approved to connect and document exceptions for unmanaged or mobile devices.
- Scope rules: Your team defines which cloud, virtual, remote and IoT assets fall inside the inventory.
- Evidence retention: Your staff keep dated exports and review records that show the inventory was current.
Confirm internally who holds each of these roles before any partner is engaged, because the partner cannot approve assets on your behalf.
An implementation partner such as DeployOpen can prepare the system of record, connect discovery sources and build the evidence trail, but it does not decide what the inventory says or issue any assessment result. Work is usually scoped as a fixed engagement under a written agreement that sets the systems, deliverables and timelines before work starts. Any partner work runs inside your own cloud accounts, data centers or networks, and your organization keeps the credentials and administrative control.
- System of record: Configuring a CMDB or asset register, such as GLPI, with the fields Safeguard 1.1 expects.
- Discovery integration: Deploying agents, such as Wazuh Syscollector, and connecting them to the inventory inside your environment.
- Evidence build: Creating exports, dashboards and reports that show the inventory is current and complete.
- Procedure documentation: Writing the inventory procedure for your review and approval.
- Handover: Training your staff so they can run the inventory without the partner.
Ask the partner in writing which deliverables it will not perform, such as approving assets or scoring the control.
Only an independent auditor, assessor or certification body reports on whether Safeguard 1.1 is met. The CIS Controls Assessment Specification defines the measures an assessor uses, including accuracy against discovered assets, completeness of detailed records and a manual review of procedures. Those measures are applied by the assessor, not by the team that built the inventory. Independence is what gives the result weight with a regulator, customer or contract counterparty.
- Independence limit: A partner that configured the system should not score its own accuracy or completeness.
- Sampling: The assessor selects assets from the network and checks them against the inventory.
- Procedure review: The assessor reads the approval and review process and tests whether it was followed.
- Timing check: The assessor checks the last update date, since the specification fails a Safeguard with no inventory or one updated more than six months earlier.
- Scope confirmation: The assessor confirms the scope you define matches the assets it observes.
Confirm with any assessor, before work starts, which evidence it will accept and how it will treat work done by a partner.
Where CIS Safeguard 1.1 inventories usually fall short
Most inventories fail Safeguard 1.1 for reasons that have little to do with tooling. They cover the wrong asset types, lack the fields an assessor checks, or drift out of date between reviews. Each gap below is one the assessment specification can detect, and each fix is a check you can run this month.
Inventory lists only servers
Many inventories start with data center servers and never add end-user laptops, phones, printers, network gear or IoT devices. Safeguard 1.1 covers end-user, network, IoT and server devices, whether on premises, virtual, remote or in the cloud. Check the inventory against a sample from each category, such as a wireless controller, a badge reader and a remote employee laptop. If any category is missing, add it before you add another field.
Missing owner and department fields
A record with a hostname and an IP address cannot be acted on. Safeguard 1.1 expects each asset to show its owner, department, network address if static, hardware address, machine name and whether it is approved to connect. Run a report for blank owner or department values and treat each blank as an open finding. Assign ownership to a named role, not a shared mailbox, so that someone can answer for the device.
Records older than six months
The assessment specification scores Safeguard 1.1 as failing when no inventory exists or when the last update is more than six months old. Staff often update the list once for an audit and then let it drift. Set a recurring review on the calendar, record the date of the last update in the inventory itself, and alert the owner when a record passes the six-month mark.
Cloud and virtual assets not captured
Cloud instances, containers, virtual machines and SaaS-connected devices often appear in a platform console but not in the enterprise inventory. Safeguard 1.1 explicitly covers virtual and cloud assets. Pull the instance lists from each cloud account and hypervisor, then match them to inventory records by identifier. Ephemeral assets need a rule that records them at creation and retires them at deletion, not a manual annual sweep.
Mobile devices outside MDM
Phones and tablets that access enterprise email or files but are not enrolled in mobile device management are invisible to most inventories. CIS notes that mobile device management tools can help with mobile assets. Compare the MDM enrollment list with the inventory and with directory accounts that have synced mobile devices. Devices present in email access logs but absent from both lists should be investigated or blocked from access.
No reconciliation against discovery
An inventory maintained only by hand is hard to prove accurate. The assessment specification measures accuracy by comparing the inventory with the assets discovered on the network. Schedule a reconciliation that compares the inventory with DHCP logs, active scan results and passive discovery output, and record the match rate and the unexplained differences. Unexplained devices feed the unauthorized asset process in Safeguard 1.2.
Questions buyers ask about the CIS Safeguard 1.1 inventory
How much effort does a detailed asset inventory take?
Effort depends mostly on the size and spread of the estate, not on the tool chosen. The main drivers are the number of endpoints, servers, cloud accounts, network devices, IoT and mobile devices, how many places asset data already lives (CMDB, spreadsheets, hypervisor consoles, MDM, procurement records), and how much of the estate is remote or unmanaged. Work falls into two parts: a one-time build that reconciles those sources, and a recurring effort to record new, moved and retired assets. Ask any quote to split discovery setup, data reconciliation, owner confirmation and ongoing review so you can see which part recurs.
How long do the initial build and first review take?
CIS does not fix a duration for Safeguard 1.1, and DeployOpen does not quote one until the scope is agreed in writing. The main drivers are the size of the estate, the quality of existing records, how many asset owners must confirm their entries, how quickly system access is approved, and any change freeze windows. Ask for milestones: source collection, reconciliation, owner sign-off and the first review. Plan the first review to finish well inside six months, because the CIS assessment specification scores the Safeguard as failing when the inventory was last updated more than six months earlier.
Can our own team build the inventory without outside help?
Many teams can, provided they have a named owner, access to the underlying sources and protected time for reconciliation. Outside help is most useful when assets span several clouds or subsidiaries, when no discovery tooling is in place, or when the team lacks capacity to configure and maintain an inventory platform. The organization always owns the control and the approval of its records. An implementation partner can prepare the systems and the evidence, but the internal team must still confirm that each record is correct and accepted.
What does the client need to provide for the inventory work?
The client needs to supply people and access. Those are named asset owners for each department, read access to hypervisors, cloud consoles, MDM, DHCP servers, network management and procurement records, and an approver who can sign off the inventory. The fields Safeguard 1.1 expects include the network address if static, the hardware address, machine name, asset owner, department and whether the asset is approved to connect to the network. Mobile devices can be recorded with help from mobile device management tools. Agree the asset classes in scope before work starts, since that choice drives most of the data gathering.
How often does the inventory need to be reviewed?
Safeguard 1.1 expects the inventory to be reviewed at least twice a year, and the assessment specification fails the Safeguard when the inventory has not been updated within six months. Those are the minimum points. Between reviews, automated feeds from active discovery, DHCP logs and passive discovery keep records current, which is why the review cadence should be written into a procedure with named owners. A review that is not reconciled against discovered assets produces weak evidence, because the specification also scores accuracy against what discovery actually finds.
Does CIS certify that we meet the CIS Controls?
No. CIS publishes the Controls and their assessment specification, but it does not certify organizations or issue compliance certificates. Assessment is carried out by your own staff, your internal audit function or an independent assessor, and the resulting reports come from them. CIS Controls Accreditation applies to CIS SecureSuite member organizations that provide implementation, auditing or assessment services, not to the organizations that adopt the Controls. DeployOpen prepares systems, inventories and evidence for assessment, but it does not issue reports, attestations or certifications.
How do Safeguards 1.2 through 1.5 relate to Safeguard 1.1?
Safeguard 1.1 is the record, and the other four Safeguards keep that record accurate. Safeguard 1.2 handles unauthorized assets found outside the approved inventory. Safeguard 1.3 adds active discovery at least daily and feeds results into 1.1. Safeguard 1.4 uses DHCP or IP address management logs, reviewed at least weekly. Safeguard 1.5 adds passive discovery, reviewed at least weekly, and is the only IG3 Safeguard in Control 1. Safeguard 1.1 is also a prerequisite for 1.2, 1.4, 2.3 and 2.4, among 64 Safeguards in total, so an incomplete inventory weakens several other assessments.
Which open-source tools can populate the inventory?
Two open-source platforms are commonly used. The GLPI Assets module manages computers, monitors, software, network equipment, peripherals, printers, phones and racks, entered manually or pushed automatically by the GLPI Agent through native inventory built into GLPI since version 10. The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups from each endpoint, then stores them for inventory views in the dashboard. Confirm coverage for your network gear, IoT and mobile devices before you rely on either tool for the full record.
How DeployOpen prepares the CIS Safeguard 1.1 inventory and its evidence
DeployOpen plans, builds and documents the systems that hold a Safeguard 1.1 asset inventory, inside your own infrastructure. We prepare the inventory platform, its feeds and the records an assessor will review, while your organization keeps ownership of the Safeguard, its procedures and its asset data.
How we scope
- Engagements are fixed-scope, with the asset classes, sites and record fields for Safeguard 1.1 agreed in writing before work starts.
- The written scope names which device types, cloud and remote assets and mobile devices the inventory must cover.
- Scope also states the review cadence for the inventory, so the twice-yearly minimum is built into the agreed deliverables.
How we build
- We deploy and configure a self-hosted inventory platform such as GLPI within your cloud accounts, data centers or air-gapped networks.
- We set up agents or native collection, such as Wazuh Syscollector for endpoints, so asset records populate without manual entry.
- Required fields, including hardware address, machine name, asset owner, department and approval status, are configured and tested against sample assets.
How we hand over
- We document the inventory procedure, update schedule and ownership so your team can run it after handover.
- Deliverables include exported inventory reports and configuration records that show how each field is populated and reviewed.
- Your assessor receives a clear evidence pack, while the independent auditor or assessor, not DeployOpen, forms any conclusion on the Safeguard.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover platform upgrades, periodic checks that the inventory is no more than six months old and review of feed health.
- Ask your provider to confirm in writing how support is priced, what it includes and how changes to the Safeguard scope are handled.

