GLPI for CIS Controls 1 and 2 asset inventory

How GLPI supports CIS Controls 1 and 2 asset inventory

If you must show an accurate, current asset and software inventory, GLPI can supply much of the evidence for CIS Safeguards 1.1, 1.3 and 2.1, through GLPI Agent inventory, network discovery and software records that carry publisher and version. Safeguard 1.2, the weekly process for handling unauthorized assets, depends on people and procedures outside the tool: someone must decide whether a device is removed, blocked or quarantined, and that decision and its timing belong in your incident or change process. Treat GLPI as the system of record for the inventory, not as proof that the controls are operating. DeployOpen plans, configures and documents these systems and prepares the evidence, but it does not certify or attest to compliance. The CIS Controls are voluntary guidance, and CIS states they do not replace any regulatory, compliance or authorization scheme that applies to you.

Start by mapping each Safeguard to a named owner, a data source and a review record. For 1.1, the question is coverage: whether end-user, server, network, virtual and cloud assets all reach GLPI, and whether any segment relies on manual entry that nobody reviews. For 1.3, the question is cadence: an active discovery method must run at least once a day, so confirm the schedule and the scan scope in writing before you claim the control. For 2.1, the question is record quality: each licensed software entry needs a title, a publisher, a business purpose and a first installation date, and GLPI's inventory fields do not hold all four by default, so confirm which fields you will populate by hand or through import rules. Ask your partner to show how these gaps are closed before go-live.

Mapping CIS Safeguards 1.1, 1.2, 1.3 and 2.1 to GLPI configuration

This table maps each supplied CIS safeguard to the GLPI capability that supports it, the configuration the team needs to set, and the gap that remains. Read each row as a question an assessor will ask, then check whether GLPI records or a documented manual process answers it. The main takeaway is that GLPI supplies the inventory data, while the review cadence, unauthorized asset process and evidence of review usually remain organizational work.

Safeguard	GLPI capability	Configuration needed	Remaining gap
1.1 Enterprise asset inventory	Computer, network device, printer and peripheral asset types populated by GLPI Agent inventory and manual entry	Agent deployed to in-scope endpoints, asset status and location fields set, owner fields completed, scope of asset types agreed	Coverage of unmanaged, cloud, virtual and IoT assets depends on discovery and manual records; confirm the scope with your own environment
1.1 Twice-yearly review	Saved searches and reports on assets by status, location and last inventory date	Named reviewer, saved report for stale or missing assets, review date recorded in a ticket or task	GLPI does not set the review schedule; the review record and sign-off must be kept outside the tool or in a documented ticket
1.2 Unauthorized asset handling (weekly)	Discovered assets not yet linked to a known asset record can be reviewed and tracked through tickets	Weekly review task, ticket category for unauthorized assets, agreed actions such as removal, blocking or quarantine	GLPI records the finding but does not block devices; enforcement sits with network access controls and the response procedure
1.3 Active discovery (daily)	GLPI Agent network discovery and inventory, with the GLPI Inventory plugin for scheduling and import	Discovery scan scope and schedule set to run at least once a day, results imported to a reviewed queue	Confirm that your chosen discovery method reaches every network segment and that the daily run is monitored for failures
2.1 Software record: title and publisher	Software catalog entries with name, publisher and version populated from agent inventory	Software normalization rules reviewed, publisher and version fields checked on imported titles	Inventory shows what is found on devices, not what is licensed; reconcile against license records separately
2.1 Software record: business purpose	Software model fields and comments can hold a documented purpose for each licensed title	Purpose field or comment standard agreed, owner assigned for each title	Purpose is usually not discovered automatically and must be entered and maintained by the business owner
2.1 Software record: first installation date	Installation records from agent inventory show when software was first seen on a device	Retention of inventory history kept long enough to show first sighting, agent runs confirmed on schedule	First-seen date reflects the first inventory run, not the true install date; state this limit in your evidence
2.1 Review at least twice a year	Software reports exported for periodic review and change tracking	Named reviewer, review record kept in a ticket or document, updates logged	The review itself and its approval are not generated by GLPI; document them in your own process

Choosing between GLPI Agent, network discovery and manual records

GLPI Agent is the most direct way to record end-user and server devices that run an operating system you can install software on. According to the GLPI Agent documentation, it collects hardware and software inventory and sends it to GLPI, and it runs on Windows, macOS and Linux. Because the agent reports from the device itself, the software records it produces are usually more detailed than what a scan from the network can see, which matters for the title, publisher and version fields that CIS Safeguard 2.1 asks for.

Coverage: Desktops, laptops and servers where the agent is installed and can reach GLPI.
Software detail: Installed application data is collected from the device, which supports software records with publisher and version.
Blind spot: Devices without an installed agent, including unmanaged laptops, appliances and guest-owned hardware, do not appear at all.
Blind spot: A device that is offline for long periods reports only when it returns, so changes in between are not visible.
Operational load: Deployment, upgrades and agent health checks recur and need an owner.

Before relying on agent data for Safeguard 1.1, confirm which operating systems and agent versions your fleet runs, and check the agent's reporting frequency against your review cadence.

Evidence GLPI produces for CIS Controls 1 and 2 auditors

An assessor testing CIS Safeguards 1.1 to 1.3 and 2.1 will ask to see records, not descriptions of intent. The cards below cover the records GLPI can produce, how each one is collected, and what should be kept with it. Whether the set is sufficient is the assessor's decision, so confirm the scope and format with them before collecting anything.

Dated inventory exports

A full export of the asset inventory, taken on a fixed date and kept unchanged, shows what the organization held at that moment. Assessors compare it against network scans and the Safeguard 1.1 requirement for an accurate, current inventory covering end-user, network, IoT, server, virtual and cloud assets. Record the export date, the filters applied and the user who ran it. Check that the export includes the asset type, owner, location and status fields the assessor will test.

Agent-collected hardware and software data

GLPI Agent sends hardware and software inventory from each device to GLPI, so the software records carry the title, publisher and version that Safeguard 2.1 asks for. Keep the agent version, deployment record and last-contact date alongside the data, because a stale agent produces an inventory that looks complete but is not. Confirm that the fields you intend to show for business purpose and first installation date are captured or maintained by a documented process, since agent collection alone may not supply them.

Discovery run logs

Logs from network discovery show when each scan ran, which address ranges it covered and which devices it found. Safeguard 1.3 expects an active discovery tool configured to run at least once a day, so the logs are the proof of that schedule, not the configuration alone. Retain the scan definitions, the run history and any failed runs with their causes. Gaps in the log are findings an assessor will raise, so explain each one in writing.

Unauthorized asset tickets

Each unauthorized device found during review should become a ticket that records the detection source, the action taken (removal, blocking or quarantine) and the closing approval. Safeguard 1.2 expects this handling to run at least weekly, so the ticket trail should show a weekly review cycle with dates. Assessors often sample a few tickets and trace them back to a discovery log entry, so keep those links intact.

Change history and audit trail

GLPI keeps history entries for asset and software records, showing who changed a field and when. This history shows whether an inventory record was edited after the fact, which matters when an assessor questions a value. Export the relevant history for the review period and store it with the inventory exports. Confirm with your administrators how long history is retained in your instance before you commit to a retention period.

Review sign-offs

Safeguards 1.1 and 2.1 call for inventory review at least twice a year. A signed review record, dated and linked to the exports it covers, shows that the review happened and who approved the result. Store the sign-off with the export it refers to, not in a separate folder, so the two cannot drift apart. Ask the assessor which reviewer roles they expect to see.

Configuring GLPI inventory for CIS evidence

This sequence turns a GLPI instance into a working source of asset and software records that can answer CIS Safeguards 1.1 to 1.3 and 2.1. Each step closes with a check so the evidence can be shown, not just described.

Install and secure the GLPI instance
Your platform engineers install GLPI on infrastructure you control, using a supported PHP and database combination. The GLPI 11.0 installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6, and the GLPI 12.0.0 README lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, so confirm the version you target before you build. Only MySQL and MariaDB are supported as databases. Point the web server document root at GLPI's public directory, not the installation root, and enable URL rewriting to route requests through index.php. Back up glpi.key and glpicrypt.key from the config directory now and store them outside the server, because restoring data without them is not possible. Done when the login page loads only through the public root and the key files exist in your backup vault.
Connect identity and roles for inventory administrators
Decide who can edit asset and software records and who can only read them. Configure authentication sources in the order GLPI tries them (internal database, LDAP, IMAP, then external methods such as REMOTE_USER) and map administrators to a narrow profile. Keep the inventory editors separate from the people who approve unauthorized-asset decisions, so the record of a decision is not written by the person who made it. Done when a test read-only account cannot change an asset or software record and every administrative login appears in the history.
Deploy GLPI Agent to endpoints and servers
Install GLPI Agent on Windows, macOS and Linux systems you manage. The agent collects hardware and software inventory and sends it to GLPI, and it is the successor of FusionInventory Agent. Packaging and rollout are usually handled by your endpoint management team, and the scope should be written down: which device classes must report, and which are excluded with a stated reason. Done when a sample of enrolled devices shows a current inventory entry with hardware fields and an installed software list in GLPI.
Schedule network discovery at least daily
Configure network discovery so that it runs at least once a day across every subnet in the defined inventory scope, as CIS Safeguard 1.3 expects an active discovery tool to run at that frequency. Include ranges for on-premises, virtual, cloud and remote segments where you can reach them, and record which ranges are not covered. Check the discovery task history for failed runs, because a schedule that silently fails leaves gaps you will have to explain later. Done when the last 7 daily runs show completed status or each failure has a ticket.
Build software records with publisher and version
For each licensed product, create or confirm a software record that holds the title, publisher, installed version and the first installation date that GLPI shows for each installation, as CIS Safeguard 2.1 describes. Add the business purpose and an owner in the software or asset notes, since GLPI does not infer purpose from the inventory alone. Use normalization rules to merge equivalent names from different endpoints, and review unmatched entries. Done when a random sample of licensed software matches its publisher and version in the inventory and each entry has a named purpose.
Define the weekly unauthorized-asset workflow
Write the procedure for handling assets that discovery finds but nobody has approved. Each new or unrecognized device or software entry should generate a ticket that assigns an owner, records the decision (remove from the network, block remote connection, quarantine, or approve and add to the inventory) and links the asset record. The procedure must run at least weekly, so schedule a recurring review and assign a named backup. Done when a test unknown device produces a ticket, the decision is recorded on the asset, and the weekly review has a dated record.
Schedule the twice-yearly review and keep evidence
Set a recurring review of the inventory and the software register at least twice a year, as CIS Safeguards 1.1 and 2.1 call for, and record each review as a dated ticket or report with reviewer names and changes made. Keep exports of the review and the discovery history so an assessor can trace a finding to a record. Confirm with your assessor or framework mapping how they expect this evidence to be packaged, since CIS does not dictate the format. Done when the first review is closed in GLPI with a saved report and the next review date is scheduled.

What GLPI does not cover for CIS Controls 1 and 2

GLPI can hold the inventory and software records that CIS Controls 1 and 2 ask for, but it only sees what its agents, discovery jobs and imports reach. The gaps below sit between the tool and the control, and each one needs a named owner, a process or a separate connector before an assessor will accept the evidence.

Discovery blind spots

Agents report only from devices where they are installed, and network discovery depends on subnets, SNMP access and credentials you have configured. Devices that are powered off, on isolated segments, or behind filtering may never appear. Compare GLPI's asset count against your network records and your DHCP and endpoint management data, and document which segments are outside discovery scope.

Business purpose and licence ownership

CIS Safeguard 2.1 asks for business purpose and first installation date per software entry, and GLPI cannot infer either from the installed software list. Someone in the business must assign each title a purpose and an owner, and procurement must supply licence entitlements. Confirm who will maintain these fields and how often the records are reviewed.

Unauthorized asset decisions

Safeguard 1.2 requires a process, run at least weekly, that decides whether an unknown asset is removed, blocked or quarantined. GLPI can flag a new device, but it does not enforce anything on the network. Your security team needs a documented owner, a response window, and the technical path to block the device at switches, wireless controllers or NAC.

Cloud and IoT coverage

Safeguard 1.1 covers cloud, virtual, remote and IoT assets, but on-premises agents and network scans do not reach most SaaS tenants, public cloud accounts or building systems. Each of these needs its own data source, such as cloud provider APIs, identity provider exports or manual registers. Decide which source is authoritative for each asset class and confirm the connector's data fields with the vendor.

The CIS assessment itself

CIS publishes the Controls Assessment Specification, which defines the inputs, measures and metrics used to verify each Safeguard, but GLPI does not run that assessment or produce an assessor's conclusion. An internal review or an independent assessor must test the records against the specification, sample assets, and sign off on exceptions. Ask who in your organization owns that review and what evidence they expect.

How agent data and discovery results reach the inventory

Inventory data reaches GLPI through two paths that the review process must treat as separate sources. On endpoints, the GLPI Agent collects hardware and software inventory and sends it to GLPI. The same agent can also run network discovery and inventory, so one installed component can feed both endpoint records and records for devices it finds on a subnet. Agents report into the GLPI database, and that database is the single place where the inventory is kept. Before you rely on it for Safeguard 1.1 or 2.1, confirm with your own environment which subnets and endpoint groups the agents cover, since coverage gaps show up as assets that never appear in GLPI at all.

Network discovery is the active side of the picture. Safeguard 1.3 expects an active discovery tool that identifies assets connected to the network and runs at least once a day, so the discovery schedule, the scanned ranges and the target list are settings you need to document and verify. Results from scans and agent check-ins land in the same asset records, which means a device seen on the network but not running an agent still needs an owner-assigned record and a reconciliation step. Confirm how your chosen GLPI Agent version handles scheduling and credentials in its own documentation before you commit to a daily cadence.

The unauthorized-asset workflow sits on top of this data, not inside the agent. A weekly review should compare newly created or unmatched asset records against your approved list, then decide whether each one is removed, blocked or quarantined under Safeguard 1.2. GLPI can hold the tickets and history that record those decisions, but the blocking or quarantine action happens in your network and endpoint tooling, so define which team executes it and how the GLPI record is closed. Keep the review output, the decision and the date together, because the reviewer will ask for that trail rather than the raw scan data.

How much effort does a GLPI CIS Controls 1 and 2 inventory take?

What actually drives the cost and effort of a GLPI inventory project?

Effort follows the size and shape of your estate and how much process work sits around the tool. The main drivers are the number of assets, the number of network segments that need discovery, the rollout method for agents, how much cleanup the existing software records need, and how much process design is required for handling unauthorized assets. A flat network with a few hundred managed endpoints and a clear owner for each segment is a very different job from a multi-site estate with legacy servers, shadow devices and inconsistent naming. Ask any partner to show which of these drivers their estimate depends on, so you can see where your numbers could move.

Which parts of a GLPI inventory are one-time work and which recur?

The setup is one-time work: installing and hardening GLPI, configuring discovery ranges, deploying GLPI Agent, building the import and normalization rules, cleaning software titles, and writing the weekly and review procedures. The recurring work is operational: keeping agents current, reviewing unmatched or unauthorized assets at least weekly, running the discovery schedule daily, reviewing inventory and software records at least twice a year, and handling GLPI upgrades. Ask for both lists separately in any quote so you can budget the first year and the steady state on their own terms.

Can our own team run a GLPI CIS inventory without a partner?

Often yes, if you have people who can administer Linux, a web server, and a database, and who can manage endpoint deployment tools. The skills that are harder to staff are the process decisions: deciding what counts as an enterprise asset, who owns each record, what happens to an unauthorized device, and how software is classified by publisher and business purpose. Teams that split the work into platform setup, agent rollout and process design, and assign each to a named owner, usually find the platform part is the smallest. A partner is most useful when the internal team lacks time, or when the scope must be fixed in writing before work starts.

What does our team need to provide during a GLPI inventory engagement?

Expect to provide access and decisions rather than just time. You will need network ranges and segment owners, access to the directories or endpoint management tools used for agent deployment, a named approver for the asset classes and software categories, and someone who can make calls about unknown devices. You will also need a maintenance window for the GLPI server and its database, and a stakeholder who signs off on the review cadence. Confirm these inputs in writing, because delays on them are one of the most common reasons an inventory takes longer than planned.

How much do GLPI Network subscriptions cost, and do we need one?

GLPI itself is open source under the GNU General Public License version 3, so the platform does not require a subscription. According to the GLPI Network subscriptions page, GLPI Network public cloud costs 19 euros per user per month and private cloud 21 euros per user per month with a 25-user minimum. Self-hosted subscriptions range from 100 euros per month for the Basic tier, which covers up to 10 agents and 500 assets, to 4,500 euros per month for Enterprise, which includes level 3 support and marketplace plugins. Whether any tier fits depends on whether you need vendor support, the marketplace plugins, or a managed service. Confirm current pricing directly with the vendor before you budget.

What should a written scope for a GLPI CIS inventory include?

A written scope should state the asset classes in scope, the network segments and cloud accounts to discover, the agent rollout method and target count, the software records to clean and how they will be classified, and the process documents to deliver. It should also name the review cadence for Safeguards 1.1 and 2.1, the weekly unauthorized-asset procedure for Safeguard 1.2, and the daily discovery schedule for Safeguard 1.3. Ask for the deliverables, the acceptance criteria, what the client must provide and by when, which items are fixed and which are optional, and how changes to scope are priced. Fixed-scope engagements are typically agreed in writing before work begins.

Which CIS Controls 1 and 2 requirements change the effort the most?

The requirements that add the most work are the ones that need a process, not just a tool. Safeguard 1.2 asks for a process, run at least weekly, for handling unauthorized assets, which may be removed from the network, blocked or quarantined, so it needs decision owners and a tested runbook. Safeguard 2.1 asks for a detailed software record with title, publisher, business purpose and first installation date per entry, which means cleanup of existing data. Safeguard 1.3 requires an active discovery tool configured to run at least once a day, which depends on network access and scheduling. Confirm these requirements against the CIS Controls Assessment Specification for your Implementation Group before you size the work.

How DeployOpen works on this

DeployOpen starts from the CIS Controls 1 and 2 safeguards your organization is targeting, then designs the GLPI inventory, discovery and software records to produce that evidence inside infrastructure you control. Engagements are fixed-scope, with the deliverables and timelines agreed in writing before work starts.

How we scope

Confirm which Implementation Group and which Safeguards 1.1 to 1.3 and 2.1 are in scope for your environment.
Inventory the asset populations to cover: end-user, network, server, virtual, cloud and remote devices.
Agree in writing how weekly unauthorized-asset handling, daily discovery and twice-yearly reviews will be run and recorded.

How we build

Deploy GLPI with the supported PHP and MariaDB or MySQL versions and a web server layout that serves only the public directory.
Roll out GLPI Agent to endpoints and configure network discovery schedules that run at least once a day.
Define software records with title, publisher, version, business purpose and first installation date, then test them against sample assets.

How we hand over

Document the inventory coverage check, review cadence and unauthorized-asset workflow so your team can repeat them.
Provide a configuration record covering agent settings, discovery schedules, ticket routing and backup procedures.
Walk through the evidence reports your auditors or assessors will ask for, and note the gaps GLPI does not close alone.

How we support

Plan GLPI upgrades, including the requirement to reactivate plugins after a major update, before they reach production.
Offer ongoing support, upgrades and continuous testing as a retainer if your team wants them after handover.
Ask any partner to confirm in writing which CIS and framework conclusions remain the responsibility of your own assessors.

GLPI for CIS Controls 1 and 2 asset and software inventory