How GLPI supports an ISO 27001 asset inventory with owners
Yes, GLPI can hold the asset inventory that ISO/IEC 27001:2022 control A.5.9 asks for, but it cannot write the inventory's rules for you. A.5.9 asks the organization to develop and maintain an inventory of information and other associated assets, including their owners, so it can identify them and preserve their security. The 2022 control merges the 2013 controls A.8.1.1 (inventory of assets) and A.8.1.2 (ownership of assets), so one register now has to show both. NIST's crosswalk from SP 800-53 Rev. 5 relates A.5.9 to CM-8, System Component Inventory, which is a useful reference point when your assessors ask how the inventory maps to other frameworks. DeployOpen prepares the GLPI configuration, records and evidence for your assessment, but certification is issued by an accredited certification body, not by DeployOpen or ISO.
GLPI covers the mechanics. Assets are recorded with a location, a status, a user, a group and a technician in charge, so the owner question can be answered from the record itself. Multiple groups can be set on Group and Group in charge fields since GLPI 11.0.0, and assets assignable to users or groups can be scoped with View assigned and Update assigned rights, which matters when several teams share a platform. Contracts and financial fields give the commercial context. What stays with your organization is the policy: which asset classes are in scope, what an owner is accountable for, how often owners confirm their records, and how unowned assets are escalated. Confirm with your certification body which evidence they expect for owner attestation, because GLPI records only show who is assigned, not who agreed to be accountable.
Before the first assessment, run a reconciliation: export the asset list, pick a sample across locations and asset types, and check that each record has an owner, a status and a current contract link. Record the result in a ticket so the review itself becomes evidence. Plan the GLPI version as part of this work. GLPI 12.0.0 was released on October 7, 2026, and GLPI 11.0.11 on October 1, 2026, so confirm which line your instance runs and whether an upgrade is planned before your audit window opens, since plugin reactivation after major updates can change report output.
Mapping A.5.9 requirements to GLPI fields and configuration
This table maps each element of ISO/IEC 27001:2022 control A.5.9 to the GLPI asset fields, rights and records that can hold it, and the configuration each one needs. Read each row as a question to answer in your instance: where does this fact live, and who maintains it. The main takeaway is that owner data is only as useful as the rights and group structure behind it, so confirm those before you load assets.
| Requirement element | GLPI field or record | Configuration to confirm |
|---|---|---|
| Inventory of information and associated assets | Asset types (computers, monitors, software, network equipment and other asset itemtypes enabled in your instance) | Enable only the asset types in scope, and agree which systems count as information assets before import |
| Owner as a named person | User field on the asset (user in charge) | Use directory-linked user accounts so that owners stay current when staff leave or move teams |
| Owner as a team | Group field on the asset, which can hold multiple groups from GLPI 11.0.0 | Define groups that match accountable teams, and decide whether one asset may carry more than one group |
| Person responsible for handling the asset | Technician in charge field on the asset | Separate this from the business owner in your procedure, and assign technicians to the groups that maintain them |
| Owner rights over their own assets | View assigned and Update assigned rights on assets assignable to users or groups | Grant these rights through profiles, and test that an owner can update only the assets assigned to them |
| Location of the asset | Location records linked to the asset | Build a location hierarchy that matches your sites and rooms, and make location a required entry at intake |
| Status of the asset | Status values on the asset | Define statuses that show whether an asset is in use, in storage or retired, and who may change them |
| Contract and financial links | Contract and financial records linked to the asset | Link the contract or purchase record at creation so that licensing and support terms can be traced to the asset |
| Preservation of security (evidence of ongoing ownership) | Asset history and the ticket records that change ownership, location or status | Keep history logging on, and confirm with your auditor which change records they will sample |
Evidence an auditor will ask for from the GLPI inventory
An auditor testing A.5.9 will sample the inventory and ask how each record was kept accurate and where a given snapshot came from. The cards below cover the exportable records that answer those questions, along with how to keep each one current and how to preserve exports as dated evidence. The auditor decides whether the evidence is sufficient for the organization's scope and risk.
Asset lists with owner and status
The core record is the asset list filtered to the in-scope asset types, with the user, group or technician in charge, the status and the entity shown on each row. Check that every asset in scope has a named owner and that statuses such as in use, in stock or retired match what teams see on the ground. Owner fields that point to a departed employee or a shared mailbox are a common finding. Export the list on a set date and keep the file with its generation time.
Location and contract records
Location fields show where each asset sits, which matters when an auditor asks whether the inventory covers every site and data center. Contract and financial records link assets to the agreements that cover them, such as maintenance, licenses or leases. Confirm that locations are mapped to real sites and that contracts reference the assets they cover. Keep the location and contract exports alongside the asset list so each snapshot is consistent with the others.
History logs for changes to ownership
GLPI keeps history entries for changes to an asset, including changes to who holds it. These logs show when an owner or status changed and who made the change, which lets you answer questions about past states of the inventory rather than only the current one. Confirm that history is enabled for the asset types in scope and that retention settings do not purge entries before your review period ends. Export the history for a sample of assets when an auditor asks how an owner was reassigned.
Group membership and assignment rights
Ownership in GLPI can point to a group, so the auditor will want the group membership that proves who is accountable for a shared asset. Export group membership with the date of the export and compare it with the groups named in the asset records. The GLPI 11.0 changelog notes that group and group in charge fields may hold multiple groups and that assignment rights were added, so confirm how your version reports these fields before you design the export.
Dated exports as versioned evidence
An export is only useful if it can be shown as it was on a given day. Store each export with a file name that includes the date, the GLPI version, the filters applied and the person who ran it, and keep the files in a controlled location with restricted write access. Record the query or saved search used so it can be rerun and compared. Ask your auditor how long they expect snapshots to be retained and whether they accept a sequence of monthly exports or require a different sampling approach.
Reconciling the inventory with source data
Auditors often test whether the GLPI inventory matches what exists on the network, so compare exported asset lists with the output of discovery and agent inventory for the same period. Differences show up as assets without owners, owners without assets or devices GLPI has never seen. Record each reconciliation, the people who signed off on exceptions and the actions taken. Sufficiency of this evidence is for the auditor to judge, so agree the method and sample size with them before the audit window opens.
Configuring the GLPI inventory for A.5.9 in order
This sequence turns the ISMS scope into a GLPI inventory where every in-scope asset has a location, a status, a contract trail and a named owner. The result is a reconciled register that can be exported as evidence for A.5.9.
Confirm the asset scope from the ISMS
Start from the information security management system scope and the asset categories your organization has already decided to protect, such as servers, endpoints, network devices, applications, cloud accounts and information assets like databases or document repositories. The ISMS owner and the IT lead agree on the in-scope list and on what is excluded, with the reason written down. The step is done when the scope document names each asset class and the person who approved it. Ask your certification body or internal auditor which asset categories they expect to see, because the scope drives every later choice.
Define owner roles and the group structure
Decide how ownership is expressed in GLPI before any asset is created. Map each owner role to a GLPI user for named individuals, and to a group for teams that share responsibility. Plan the group hierarchy, and note that since GLPI 11.0 the Group and Group in charge fields on an asset may hold multiple groups, so you can record both the owning team and the team that operates the asset. Assign the rights that let owners view and update assets assigned to them. The output is a written role matrix that a reviewer can compare against the asset records later.
Configure entities and locations
Create the entity structure that reflects legal or business boundaries, then build the location tree for sites, data centers, offices and cloud regions where in-scope assets sit. Keep location names stable, because auditors often sample assets by site. Verify that each in-scope entity and location is visible to the people who will maintain its records. The check is a short walkthrough where an administrator opens a sample asset from each entity and confirms the location and entity fields are correct and not defaulted.
Set asset statuses and lifecycle values
Agree the status values that describe the asset lifecycle, such as in use, in stock, under maintenance and retired, and make sure each status has a clear meaning for the team that sets it. Retirement and disposal states matter for A.5.9 because an inventory that keeps decommissioned assets gives a false picture of current exposure. Document who may change a status and what evidence supports the change. Confirm the values with the operations team before bulk loading, since changing status names later affects every record and report.
Link contracts and financial records
Connect the relevant contracts, licenses, suppliers and financial records to the assets they cover. This gives the inventory a commercial trail: who supplies the asset, what agreement governs it and when that agreement ends. Costs for these records depend on how much history your finance and procurement teams already hold, and on whether data is migrated or entered by hand, so ask your team to confirm the source system for each contract type. The step is complete when a sample of assets can be traced from the asset record to its contract and back.
Assign owners and technicians in charge
For each asset, record the accountable owner in the user or group field and the technician or team in charge of day-to-day operation in the group in charge field. Keep the owner accountable for the asset's security and use, and the technician accountable for operating it. Use bulk assignment only after the role matrix is approved, then sample assets by class to catch mistakes. The output is an inventory where no in-scope asset lacks an owner, which is the core requirement of A.5.9.
Reconcile the register before the first export
Compare GLPI against the authoritative sources you already trust, such as the cloud provider consoles, hypervisor inventories, procurement records and the network discovery output. List assets found in one source but missing in GLPI, assets in GLPI with no owner, and assets marked as retired that still appear active. Resolve each difference, record the decision and the person who made it. Populating the register can be done with GLPI Agent for hardware and software inventory, or with import tools for spreadsheet data. Those methods are covered in the GLPI inventory and network discovery and migrating to GLPI topics. The step closes when the exception list is empty or each remaining item has a documented reason and a named owner.
Where the owner field stops and the ISMS decision starts
A GLPI asset record can tell you which user, group or technician is named as owner or in charge, but it cannot tell you what that name means. ISO/IEC 27001:2022 control A.5.9 asks for an inventory that includes owners, and the auditor will ask who is accountable for each asset's security and what that person actually decides. Those decisions belong to your information security management system. Before you populate the user and group fields in GLPI, write down the definition of owner, the classification levels you use and who approves changes to both. Store that rule in your ISMS documentation, such as the asset management procedure, rather than in a GLPI comment field, so it survives a change of tool.
The most common gap is between a technical custodian and an accountable owner. A custodian is the person or team that installs, patches, backs up or administers the asset, and in GLPI this is often the group in charge or the technician assigned to the asset. An accountable owner is the person who can accept risk, approve access, and decide how the asset is classified and retired. These can be the same person on a small estate, but in most organizations they are not. Decide which role each GLPI field represents, and confirm with your team whether the field labelled Group in charge is meant to capture custody, accountability or both, because GLPI will not enforce that distinction for you.
Ownership also needs a review cycle that sits outside GLPI. Set how often owners confirm their assets, what happens when an owner leaves or changes role, and who signs off the register as a whole. GLPI can support the evidence through user and group histories and reports, but the review decision and its record should be kept in your ISMS. Ask your certification body or internal auditor which evidence format they expect for owner reviews before you design the process, since the format determines whether a GLPI report alone is enough.
What GLPI does not cover for ISO 27001
GLPI can hold the asset register that A.5.9 asks for, but the surrounding management system is still your job. The cards below separate what the platform stores from what your organization must decide, document, verify and sign off before an auditor will accept the inventory as evidence.
ISMS scope and policy
GLPI does not define the scope of your information security management system, and it does not write the asset management policy that the standard expects you to approve. Decide which sites, business units and asset classes fall inside scope, then record that decision in your ISMS documents. Confirm that the entities and locations you configure in GLPI match that scope, so the register and the policy describe the same population.
Risk assessment and classification
GLPI ships no classification scheme that reflects your confidentiality, integrity and availability requirements. Any labels you add, such as criticality or data sensitivity, are custom fields or conventions you must define and govern. Ask your GLPI partner or review the documentation for your exact version to confirm which fields can hold classification values and who can edit them.
Completeness of discovered inventory
Inventory only shows what agents, imports or manual entry have reported. Devices that never ran an agent, unmanaged cloud resources and shadow tools can be absent without any warning in GLPI. Plan an independent reconciliation against network scans, identity directories and cloud consoles, and treat any gap between those sources and GLPI as a finding to resolve.
Ownership review process
Owner fields are only as accurate as the process that keeps them current. GLPI will not notice that a user has left, that a group was reorganized or that a technician no longer owns a server. Define who reviews owner assignments, how often, and what evidence of each review you keep, such as dated exports or approval tickets.
Field options in your version
Groups, technicians in charge, statuses and multi-group behavior changed across recent GLPI releases, so the options available to you depend on your installed version and any plugins you run. Before you write the procedure, confirm the exact field options, rights and report outputs in your environment. Record the version and the check results alongside the inventory.
Certification and audit outcome
GLPI cannot make your organization compliant, and DeployOpen does not certify it either. Only an accredited certification body can issue an ISO/IEC 27001 certificate after an audit. Use GLPI reports as inputs to your internal audit and management review, and ask the certification body which evidence it will sample before you finalize the register.
Questions buyers ask about GLPI and ISO 27001 asset inventory
Does GLPI alone satisfy ISO 27001 control A.5.9?
No. GLPI can hold the asset inventory that A.5.9 asks for, including each asset's owner, but the control is about the organization maintaining that inventory, not about a tool. A.5.9 asks for an inventory of information and other associated assets, with owners, so you can identify them and preserve their security. GLPI supplies the register, owner fields through users, groups and technicians in charge, locations, statuses and contract links. Your team still has to define what counts as an asset, who approves changes to the inventory, how often it is reviewed, and how gaps are handled. Those rules belong in your information security management system, and an auditor will test whether they operate in practice.
What drives the effort and cost of a GLPI asset inventory build?
The main drivers are the scope of asset types, the state of your existing data, the number of integrations and the sign-off process. Costs fall into one-time work (requirements, asset taxonomy, data cleanup, import, integration build, documentation and review) and recurring work (inventory reviews, owner updates and platform upkeep). Scope that covers only servers and laptops is far smaller than one that includes cloud accounts, SaaS, contracts and physical media. Poor source data, such as spreadsheets with missing owners, multiplies cleanup effort. When requesting a quote, ask for the written asset categories, the sources to import from, the named owners who must sign off, and which items are one-time versus recurring. No cost figure is available from our sources for this work, so the scope document is the basis for any estimate.
What does our organization need to supply for the build?
You need to provide an asset classification, a list of current inventory sources, named owners for asset groups, and decision-makers who can approve the ownership model. Engineers will need access to existing directories such as LDAP or Active Directory user and group data, procurement or contract records, and a test environment. You also need a person who can answer questions about business criticality and data handling for each asset class. Without these inputs, owner fields stay empty or inaccurate, which is the most common reason an inventory fails review. Confirm the exact access and approvals in the written scope before work starts.
Can an internal team build a GLPI inventory for ISO 27001 without a partner?
Yes, many teams do this internally, provided they have GLPI administration skills, time to define the asset model and clear ownership rules. The internal work includes installing GLPI, which the installation docs describe as requiring a supported PHP and MariaDB or MySQL stack, setting up profiles and entities, defining asset types and building import routines. The harder part is governance: agreeing who owns each asset class and proving the inventory is maintained. A partner can help with the design, import, integrations and documentation, while your staff keeps control of ownership decisions. Ask any partner to show the written scope, deliverables and handover plan before you decide.
How long does it take to build the inventory, and what changes the timeline?
No general duration is available from our sources, so the timeline depends on the scope and your environment. The biggest factors are the number of asset classes, the volume and quality of source data, how many systems must feed GLPI, and how quickly owners and approvers respond. Adding inventory agents or directory integrations extends the work, as does a GLPI version change. The GLPI 11.0.0 changelog notes that asset Group and Group in charge fields may now hold multiple groups, which can simplify shared ownership but still requires an ownership design. Request a timeline in the written scope that lists milestones, owner reviews and the dependencies you control.
How do certification bodies check the asset inventory?
Certification bodies test the inventory as part of the management system audit, looking at whether it is complete, current, owned and reviewed. ISO does not certify organizations; accredited certification bodies do, under ISO/IEC 17021-1 and ISO/IEC 27006-1. A management system certification cycle lasts three years, with at least one audit in every calendar year, so the inventory must be kept current between audits, not only prepared before one. Auditors usually sample assets, trace them to owners and ask for evidence of review and change. DeployOpen prepares systems, controls and evidence for these assessments but does not issue audit reports or certifications.
Which GLPI version should we use for the inventory build?
Choose a version that your team can keep supported, and check the current release notes before you commit. The GLPI releases page lists GLPI 12.0.0, released on October 7, 2026, and GLPI 11.0.11, released on October 1, 2026, alongside GLPI 11.0.0 from October 1, 2025. The GLPI 12.0.0 release notes describe a view of active user sessions with the ability to revoke them, and step-up authentication for certain administrative actions, which help with access control over the inventory. Confirm the requirements for your chosen version in the installation docs, since PHP and database requirements differ between releases. Plan the upgrade path before the build starts so the inventory model survives future updates.
What risks should we plan for when the inventory is incomplete?
An incomplete inventory leaves unknown systems outside your security controls, and an auditor will treat missing or unowned assets as findings. The main risks are shadow assets that never reach GLPI, owner fields that point to people who have left, and duplicate records from multiple import sources. Mitigate these with an owner review cycle, automated discovery where possible, and clear rules for retiring assets. Keep the change history for asset records so you can show when ownership changed. Document these checks in your management system so the process holds up between audits.
How DeployOpen scopes and delivers GLPI compliance configuration
DeployOpen plans, configures, documents and hands over GLPI as an asset inventory with named owners, inside infrastructure your organization controls. We agree the scope in writing first, then build the inventory structure, test it against your own asset records, and leave your team with the reports and procedures an assessment will ask for.
How we scope
- Confirm which asset classes, sites and entities fall inside the ISMS boundary before any configuration starts.
- Agree in writing which owner fields, groups and technicians in charge each asset class will carry.
- Set the deliverables, timelines and responsibilities in a fixed-scope written agreement, with the quote derived from that scope.
How we build
- Configure asset types, locations, statuses, groups and user links so every record has an accountable owner.
- Load a representative sample of your existing asset data and test ownership, duplicates and missing fields against it.
- Build the saved searches and reports that show owned, unowned and stale assets for review by your ISMS owner.
How we hand over
- Document the configuration, field definitions, rights model and owner assignment rules so your team can maintain them.
- Provide a written runbook for the periodic inventory review, including who approves changes and where evidence is stored.
- Walk your team through the reports an auditor typically requests, and state clearly which evidence remains your organization's responsibility.
How we support
- Offer ongoing support, upgrades and reviews of the GLPI instance as a retainer when your team wants continued help.
- Plan GLPI version upgrades with backups of the database, files and encryption keys before any change is applied.
- Confirm with your certification body or auditor how the inventory evidence will be sampled, since DeployOpen does not issue attestations.
