Using GLPI as the DORA ICT asset register: what it covers
A financial entity in scope of DORA, which has applied since 17 January 2025, needs records of its ICT assets and of the contractual arrangements behind them. GLPI can host and link much of that data, from inventoried hardware and software to contracts, suppliers and dependency maps, but the entity owns the register and makes the compliance decision. The platform supports the work; it does not decide what is in scope or whether the entity complies. The Article 28(3) register of information on all contractual arrangements for ICT services is the clearest fit. GLPI's contract management records contracts linked to assets and tracks renewals, and the impact analysis feature maps dependencies between assets, appliances and clusters, which helps show which ICT services support critical or important functions. Article 30(2) asks each ICT contract to state where services are provided and data processed, with advance notice of changes and data return on insolvency or termination. GLPI can hold those fields and attachments, but the contract wording itself must come from legal and procurement. For Article 28(8), exit strategies and transition plans must be documented and tested. GLPI can link them to services, but it does not test an exit. Confirm with your own team how the contract and supplier fields in your GLPI version map to the register template your supervisor expects.
Chapter II ICT asset records are largely an inventory exercise. Confirm which GLPI objects (computers, network equipment, software, databases and virtual machines) your entity will treat as ICT assets, and who owns each record. Automated collection through GLPI Agent helps keep hardware and software current, but inventory alone does not classify criticality or document recovery arrangements. Those judgments stay with your risk function. DORA sets no certification scheme, and GLPI will not produce one. Competent authorities supervise compliance, and the only authority-issued attestation the Regulation provides for is that a threat-led penetration test met the requirements under Article 26(7). DeployOpen can plan the GLPI data model, configure the contract and dependency records, and prepare evidence packs for your assessors. It does not issue audit reports, attestations or certifications; independent auditors and your supervisor do.
Which DORA requirements map to which GLPI capability
This table maps three DORA contract and register requirements to the GLPI objects that hold their evidence, and marks where the requirement needs content GLPI does not store. Read each row as a question: can GLPI hold the record, and if not, which document or process must sit alongside it. The main takeaway is that GLPI can serve as the register backbone, while risk assessments, exit test results and legal review stay outside it.
| Requirement | GLPI capability and configuration | Gap to plan for |
|---|---|---|
| Article 28(3): register of information on all ICT contractual arrangements | Create one contract record per ICT arrangement, set the contract type, link it to supplied assets and attach the signed agreement. Use the supplier record for legal name, entity and contact fields, and enable renewal alerts on the contract. | GLPI does not define the register schema for you. Confirm with your competent authority which fields it expects and map them to contract and supplier fields. |
| Article 28(3): linking providers to services supporting functions | Link each contract to the assets, appliances and clusters it supports, then use impact analysis to show dependencies between those items. | Function criticality (critical or important) is a business judgment. Record it in a custom field or linked document, since GLPI does not classify it automatically. |
| Article 28(8): documented, tested exit strategy and transition plan | Attach the exit plan as a document to the contract or supplier record, and create a recurring task or ticket for periodic review and test dates. | GLPI holds no exit test results. Test evidence, replacement provider options and transition timelines must be stored in your own test records and referenced from GLPI. |
| Article 30(2): service and data processing locations | Record provider locations and data hosting locations in contract or supplier fields and in the attached agreement, with location fields on linked assets where relevant. | Location data may depend on subcontractors. Confirm the subcontractor chain with the provider, since GLPI only holds what you enter. |
| Article 30(2): advance notice of changes | Use contract renewal and expiry alerts and a change-tracking process, with notices filed as documents on the contract record. | GLPI does not monitor provider notices. Someone must log incoming notices, and the notice period itself must come from the signed contract text. |
| Article 30(2): data return on insolvency or termination | Store the data return clauses as an attached document and link them to the contract, with a termination checklist ticket template. | Whether the clauses are adequate is a legal assessment. GLPI stores the reference but does not assess the wording. |
| Risk assessment of ICT third-party arrangements | Store the assessment outcome as a document or custom field on the contract or supplier record, with a review date. | The assessment method and risk content live outside GLPI. Keep the full assessment in your risk management system and reference it here. |
How GLPI inventory, contracts and impact analysis fit together
The core idea is that GLPI records one chain from a supplier's contract down to the hardware, software and clusters that deliver a function. GLPI Agent sends hardware and software inventory into GLPI, which creates and updates asset records. Contracts are then linked to the assets they cover, and each contract carries a supplier, a term and a renewal date. Contract management in GLPI inventories contracts related to assets and tracks renewals, so the team can see which arrangements are coming up for review. Impact analysis sits on top of the asset records and maps dependencies between assets, appliances and clusters. Together these three parts let you start from a supplier and reach the infrastructure behind it, or start from a server and find every contract and service that depends on it.
To trace a service that supports a critical or important function, start with the contract and work downward. Confirm that the contract is linked to every asset it covers, including virtual machines, appliances and cluster members, not only the headline product. Then check that impact analysis links those assets to the service, so a failed host or a lapsed licence shows its downstream effect. Test the chain with one real service before you rely on it: pick a function, follow it from the contract to the hardware, and confirm each link is present and current. Gaps usually appear where inventory data is missing for assets that were never enrolled with GLPI Agent, so decide early how those assets are found and recorded.
Be clear about what GLPI does not provide. The DORA register of information has its own required content and format, and GLPI's contract and asset fields do not produce that template for you. Confirm with your competent authority or supervisory guidance which fields and formats they expect, then map those requirements to GLPI fields and, where needed, custom fields. Confirm also how your supplier arrangements, including the provider location and data return terms DORA asks about, are captured on each contract. Document the mapping so an auditor can see how each register field is sourced.
What evidence GLPI produces and how to keep it
GLPI generates several kinds of records that can support an ICT asset and third-party register under DORA. Each one changes over time, so the evidence is only useful if you capture it at fixed points and protect it from later edits. The cards below cover what each record is and how to preserve it.
Dated asset inventory exports
Export the computer, network equipment, software and other asset lists from GLPI on a set schedule, and keep the inventory timestamp in each file name and header. Each record shows when GLPI last received data from an agent or a manual update, so a reviewer can see how current the list was on a given date. Check that agent-collected assets and manually entered assets are both present, because a register built only from agent data will miss ICT systems without an agent. Store each export as a read-only, dated copy.
Contract records with renewal dates
GLPI's contract module records contracts linked to assets, with renewal and end dates. These links show which ICT services depend on which contracted providers, and when those arrangements need review or exit planning. Check that every contract tied to an ICT service has a supplier, a start date, an end date and at least one linked asset. Keep dated exports of the contract list alongside the contract documents stored outside GLPI, since the register must reflect the signed terms.
Supplier records for ICT providers
Supplier records identify the ICT third-party providers behind each contract and asset. For the register, each provider should be recorded with a consistent legal name, a contact owner inside your organization, and the services it provides. Confirm with your compliance function which provider attributes the register must hold, including where services are provided and where data is processed, because DORA Article 30 sets contract content requirements. Export the supplier list with the contract list so the two stay matched.
Impact analysis views
Impact analysis in GLPI maps dependencies between assets, appliances and clusters, so you can show which services and systems a failing component affects. This view supports the criticality judgments that DORA requires for ICT services supporting critical or important functions. Save the impact diagrams as dated images or exports after each review, and record who approved the mapping. Note that the diagram reflects what was entered in GLPI, so gaps in dependency data appear as gaps in the view.
Change history and audit logs
GLPI keeps history entries for changes to assets, contracts and suppliers, and the log shows what changed and who made the change. This history lets an examiner trace when a register entry was altered, which matters when the register is used to show it was maintained over time. Protect it by backing up the database regularly, together with the glpi.key and glpicrypt.key files that the application needs to read encrypted data. Confirm with your compliance function how long these logs must be kept.
Scheduled snapshots and key backups
Take a full snapshot of the database and the application files on a fixed cadence that your compliance function sets, and store it separately from the live instance. Include the config directory with glpi.key and glpicrypt.key, because a database restore without those keys may not recover encrypted content. Test a restore on a separate system and record the result, so the snapshot can be shown to be usable. Confirm the cadence and retention period with your compliance function before you set the schedule.
Configuring GLPI as the register in order
This sequence turns GLPI into a register of ICT assets, contracts and suppliers that maps the services a financial entity depends on, from the supplier contract down to the server that runs the service. Each step produces a record or check that the compliance team can review and that an examiner can trace.
Agree the register scope with compliance
Compliance, risk and the owners of IT operations agree which legal entities, business functions and ICT suppliers the register covers. The scope should name the functions that support critical or important functions, since DORA Article 28(8) ties exit planning to those services. Write the scope down with the entity list, the function list and the supplier categories, and get sign-off before any records are created. The step is done when the scope document is approved and every later step can point back to it.
Define supplier and contract types
Set up the supplier categories, contract types and contract fields that the register needs in GLPI's contract and supplier records. Fields should cover the data processing location, the notice period for changes, data return on termination and the renewal date, which map to the contract content that DORA Article 30(2) asks for. Agree the naming convention and who may create or edit a supplier record. The step is done when a test contract for each type can be saved with every mandatory field filled in.
Deploy GLPI Agent and discovery
Install GLPI Agent on the in-scope servers, endpoints and network devices, and configure network discovery for ranges that the agent cannot reach. The GLPI Agent collects hardware and software inventory and runs on Windows, macOS and Linux. Confirm the GLPI version and the PHP and MariaDB or MySQL versions against the installation prerequisites before rollout, because they determine which GLPI release you can run. Count the devices reporting against the expected asset list. The step is done when unreported in-scope systems are listed and assigned to an owner for follow-up.
Link contracts to assets and services
Attach each contract to the assets, appliances or clusters it covers, so that a supplier can be traced to the hardware and software that depend on it. Use GLPI's contract management to inventory these relationships and to track renewals. Assign an owner for each link, normally the technical owner of the service. The step is done when every in-scope contract has at least one linked asset and every in-scope asset with a supplier dependency links to a contract.
Build impact analysis for critical functions
Map the dependencies between assets, appliances and clusters that support each critical or important function using GLPI's impact analysis. Start from the business function, then add the applications, servers, network components and suppliers beneath it. Review the map with the service owner to confirm it matches how the service actually runs. The step is done when each critical or important function has a dependency map that the service owner has reviewed and dated.
Set renewal alerts and review ownership
Configure GLPI notifications for upcoming contract expirations and renewal dates, and route them to the contract owner and the compliance contact. Review the alert recipients whenever a contract owner changes, since an orphaned contract is a common gap. The step is done when a test alert reaches the intended recipients and each contract in scope has a named owner.
Define export and snapshot routines
Set a routine that exports the register and keeps dated snapshots, so the state at any review date can be reproduced. Store exports under the entity's own control, with access limited to the compliance and IT teams. Record who runs the export, when, and which GLPI version produced it. Confirm the export includes contracts, suppliers, links and impact maps before relying on it. Plugins are suspended after a new GLPI version is detected and must be reactivated after major updates, so include plugin status in every upgrade check. The step is done when a snapshot has been produced, stored and checked against the live register.
Test a sample trace from supplier to server
Pick a sample of critical or important services and trace each one from the supplier contract, through the linked assets and impact map, to the physical or virtual server that hosts it. Confirm each link exists and that the data location and exit fields are populated. Record every break in the trace as a ticket with an owner and a due date set by the compliance team. Report the result to the compliance team, with the traced services, the breaks found and the fixes agreed. The step is done when the trace has been repeated after the fixes and no break remains open without an approved exception.
Who in the entity owns DORA records and what GLPI cannot decide
Before the register is populated, the entity should name one owner for the ICT asset and third-party information that DORA expects it to hold, usually a function in the risk or operational resilience area, with written responsibilities for IT operations, procurement and the compliance function. In practice IT operations maintains the inventory data in GLPI, including hardware, software, locations and the dependencies recorded through impact analysis. Procurement holds the contract and supplier terms that GLPI's contract records reference. The compliance function decides which arrangements support critical or important functions and checks that the register answers the questions a supervisor will ask. Writing this split down, with a named person for each field, is the first deliverable to plan, because GLPI can store data from all three teams but cannot assign accountability between them.
GLPI supports evidence; it does not make the regulatory decisions. The entity decides what counts as critical or important for each function, which providers fall into scope, and whether an exit strategy is adequate. Supervision sits with the national competent authority for each type of financial entity under Article 46 of DORA, with the ECB responsible for credit institutions classified as significant, and the European Supervisory Authorities acting as Lead Overseers for critical ICT third-party service providers. Confirm with your own competent authority which reporting format and depth it expects, since the register in GLPI must be exported or reviewed against that expectation. Treat the NIS2 and GDPR overlap as a separate scoping exercise with its own owner, since the data fields and retention rules those regimes require do not map one to one onto DORA's register.
Questions buyers ask before using GLPI for DORA records
Does using GLPI make our organization DORA compliant?
No. DORA applies to the financial entity, not to a software product, and no tool makes an entity compliant. GLPI can hold the inventory, contract and supplier records that feed the register of information described in Article 28(3), along with dependency mapping for impact analysis. Compliance still depends on your governance, risk processes, contract terms and how supervisors judge the evidence. DORA also sets no certification scheme, so there is no GLPI badge to obtain. Ask your compliance function to define what the register must contain before deciding what GLPI should hold.
How much effort does a DORA register build take?
The effort depends on the scope you set, not on a fixed duration. The main drivers are the number of ICT third-party arrangements, the quality of existing contract data, how much of the estate discovery already covers, and whether procurement records can feed GLPI or must be keyed in by hand. Each supplier with a contract that needs review adds work, and so does each service that supports a critical or important function. Ask for an effort estimate that breaks these drivers out, and confirm the counts from your own contract repository before you accept any figure.
Can our internal team build the DORA register in GLPI?
Yes, if the team owns the scope and the data. GLPI's contract management records contracts linked to assets and tracks renewals, and impact analysis maps dependencies between assets, appliances and clusters, so the platform is capable of the work. The harder part is agreeing what counts as an ICT service, which contracts fall under the register, and who signs off each entry. Teams without DORA experience often underestimate the contract review step. A partner can help with configuration and data loading, but the decisions about classification stay with your organization.
What does our organization need to provide for the build?
The engagement needs four inputs from your side:
- A complete contract inventory, including suppliers, contract terms, renewal dates and the services each one delivers.
- Named owners for each asset, service and supplier relationship, drawn from people who can answer questions about them.
- A sponsor with authority to settle scope disputes and approve classification decisions.
- Access to the data sources you already hold, such as procurement systems, identity directories and any existing discovery tools.
The quality of these inputs usually matters more than the platform configuration.
What should a quote for a GLPI DORA register include?
A quote should follow from a written scope and list the deliverables in that scope. Ask for the following in writing:
- The entities, service types and contract population in scope, and the assumptions behind the count.
- The data sources to be loaded, how each is mapped to GLPI objects, and who provides the extracts.
- The configuration work for contracts, suppliers, dependencies and impact analysis.
- Export formats for the register, with a sample export reviewed before sign-off.
- Handover documentation and any follow-on support you choose to buy.
DeployOpen does not publish a price list, and a quote follows from the written scope. Costs are mostly one-time labor, while hosting, licenses for any paid GLPI option and ongoing review of new contracts recur.
Does GLPI have a built-in DORA module?
Confirm this with the vendor before you plan around it. The GLPI documentation covers contract management, suppliers and impact analysis, but the material supplied for this page does not describe a DORA-specific module or a register template. Ask Teclib' whether any current GLPI release or plugin provides fields or reports aligned to Article 28, and request the version and documentation. If none exists, the register will be a configured use of standard objects, with custom fields or reports designed for your compliance team.
How do we keep the DORA register current after launch?
The register needs a defined update process, because contracts, suppliers and services change. Decide who records new arrangements, who reviews renewals and terminations, and how often the compliance function reconciles GLPI against procurement. Discovery data from GLPI Agent can confirm which assets exist, but it does not show contract terms or exit plans, so those still depend on people. Ask for the update workflow as part of the handover, and confirm which steps are automated in your environment before you assign the work.
How DeployOpen scopes GLPI register work for regulated entities
DeployOpen scopes GLPI register work as a fixed-scope engagement agreed in writing before any build starts. The written scope names which ICT services and suppliers enter the register, which GLPI objects hold them (assets, contracts, suppliers, and the impact relations between assets, appliances and clusters), which fields are mandatory, and which exports the compliance team needs. The deliverables and timeline follow from that scope, so the first decision for your team is which ICT services support critical or important functions, because that classification drives how much detail each record needs. Expect the scoping conversation to include your third-party risk, information security and business continuity owners, since they will consume the register and the exit planning evidence.
Delivery happens in your own infrastructure, on the platform, database and web server layout your team approves. DeployOpen configures the contract and supplier records, sets up the impact analysis dependencies, and sets the GLPI Agent inventory where asset data should come from automatically. Access follows your identity and profile model, and each change to the register is tested against the scope. Traceability tests are part of the handover: pick a sample ICT service, follow it from its contract to its supplier, its assets and its dependent business functions, and confirm that every link can be exported. Confirm early whether your GLPI version and your exports meet the formats your competent authority or internal audit expects.
DeployOpen prepares systems, controls and evidence, but it does not issue audit reports, attestations or certifications. Supervisory assessment under DORA is performed by your competent authority, and any independent review is performed by your auditors. Ongoing support, upgrades, register reviews and continuous testing can be taken on as a retainer after handover, which suits the recurring work of keeping contract renewals, supplier changes and asset records current. Ask any partner, including DeployOpen, to state in the written scope what is delivered, what is excluded and who owns each record after go-live.
