Why GLPI for banks and financial services needs a regulator-ready build
A bank, payment institution or insurer that runs GLPI needs more than a working helpdesk. It needs IT asset, contract and change records that it can show a supervisor on request. GLPI already covers the core record types: tickets, assets, a CMDB, contracts and financial management, and it can be self-hosted inside the institution's own infrastructure, which keeps those records under the institution's control. The question for a regulated firm is not whether GLPI has the modules, but whether the instance is designed so that the records it holds are complete, attributable and separable by business unit or legal entity.
DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 to 20 types of financial entity, from credit and payment institutions to insurers and crypto-asset service providers. Its Article 28(3) requires a register of information on all contractual arrangements for ICT services, which makes the GLPI contract and asset data a candidate source for that register. A generic install does not meet that need on its own. Decisions to make early include how entities map to legal entities and business units, which fields and approval steps create evidence, how users authenticate and what administrative actions are logged, and where the database, file store and encryption keys sit. Confirm the exact register fields and data retention rules with your competent authority and compliance team before the schema is fixed. GLPI supports the record-keeping; it does not make the institution compliant.
Which financial rules shape the GLPI build
This table maps each financial rule to the evidence it expects and the part of the GLPI build it affects, such as the data model, workflows or hosting. Read each row as a design input to settle before configuration starts. The main takeaway is that most of these rules ask for records, not features, so the data model and contract fields matter more than any single plugin.
| Rule | What it asks for | What the GLPI build must do |
|---|---|---|
| DORA Article 28(3) | A register of information covering all contractual arrangements for ICT services | Model ICT providers and contracts as linked GLPI contract and supplier records, with a field or export that maps each entry to the register your supervisor expects |
| DORA Article 28(8) | Documented, tested exit strategies and transition plans for ICT services that support critical or important functions | Tag assets and services that support critical or important functions, and link each to a stored exit plan and the dependencies needed to run it |
| DORA Article 30(2) | Contract terms stating where services are provided and data processed, advance notice of changes, and data return on termination | Record hosting location, processing location and notice periods as mandatory contract fields so that gaps are visible in reports |
| SEC Release 33-8810 (ITGC areas) | Evidence over program development, program changes, computer operations and access to programs and data for SOX 404 assessments | Route application and infrastructure changes through approval tickets with retained history, and keep profile and access change logs available for review |
| FTC Safeguards Rule, 16 CFR 314.4(c)(5) | Multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing | Enforce MFA for all GLPI accounts through your identity provider, and store any written equivalent-control approval against the affected accounts |
| PCI DSS v4.0.1 scope | Defined scope for systems that store, process or transmit cardholder data or could affect that environment | Place any GLPI asset records for cardholder environment systems in a separate entity with restricted profiles, and keep card data out of tickets and attachments |
| Swift CSCF v2026 | Independent assessment of 32 controls (26 mandatory, 6 advisory) with annual attestation in KYC-SA where Swift is used | Inventory Swift-connected systems and their components as assets, and link evidence of control owners and review dates to those records |
Which GLPI modules and settings matter for a bank
A bank does not need every GLPI module on day one, but a few of them carry the evidence that supervisors and auditors ask for. The cards below cover the records, approvals, access controls and integrations that connect GLPI to your ICT risk, change and audit processes. Each module has its own workstream, so treat these cards as the scope decisions to make first.
Asset and contract records as the ICT register
Assets, software, suppliers and contracts in GLPI can form the starting point for the register of information on contractual arrangements for ICT services that DORA Article 28(3) requires. Link each ICT service to its supplier contract, the location where services are provided and data is processed, and the owner who can answer for it. Check that contract fields hold the data-location and exit terms Article 30(2) expects, and confirm with your legal team which fields they need before the data model is set.
Change management as audit evidence
Change records with approvals, risk ratings and implementation notes give auditors a trail for program changes and computer operations, two of the IT general control areas named in SEC Release 33-8810. Decide which changes need a second approver, who can close a change, and whether emergency changes get a retrospective review. Keep these rules in the workflow configuration, not in people's memory, so the evidence is produced automatically during normal work.
Entities and profiles for isolation
Entities separate data between business lines or legal entities, and profiles decide what each group can read or change inside an entity. Map each legal entity or business unit to an entity, then grant access through profiles and authorization rules rather than individual accounts. Test the boundaries with a user from each entity and confirm that shared suppliers and shared assets are placed deliberately, because records visible in one entity can be visible to staff who should not see them.
Authentication, MFA and session controls
Sign-in should go through your directory, whether LDAP or Active Directory, or through web server or identity provider SSO, with two-factor authentication enabled for every account that can change records. The GLPI 12.0.0 release adds a view of active user sessions with the ability to revoke them, and step-up authentication for certain administrative actions. Confirm which administrative actions trigger step-up, and document how a revoked session is handled for staff working across shifts.
GLPI Agent inventory and network discovery
GLPI Agent sends hardware and software inventory to GLPI and can run network discovery, which helps keep the asset register current without manual data entry. For a bank, the question is coverage: which endpoints, servers and network devices must report, how often, and who reviews the records that never report. Agree the discovery ranges with your network team before scanning begins, and confirm that the agent deployment fits your endpoint management and change controls.
API and webhook integrations to CMDB or SIEM
The GLPI API and outbound webhooks can feed asset and incident data to your CMDB, monitoring tools or SIEM, so security teams can correlate events with the owner and criticality of each asset. Decide which fields leave GLPI, where the integration credentials are stored, and which service account is used. Treat every integration as an ICT third-party arrangement that must appear in the register and be covered by your exit plan.
How GLPI records become a DORA ICT asset register
The register of information that DORA requires under Article 28(3) covers all contractual arrangements for ICT services, and it is an organizational artifact that the institution owns and submits in the form its supervisor expects. GLPI does not produce that register on its own. It supplies the underlying records: the ICT providers as supplier entries, the contracts as contract records linked to those suppliers, and the services and assets each contract supports. The practical design question is how these objects link together so the register can be exported and kept current. Before the build, confirm with your compliance and vendor management teams which fields the register template requires, and map each one to a GLPI object, a custom field or a document attached to a contract. Confirm the GLPI version you will run first, because the field types and plugin options you rely on depend on it.
Two categories of field need legal and procurement input before anyone configures them. The first is data location: Article 30(2) requires every ICT services contract to state where services are provided and data processed. GLPI should hold that location as structured data on the contract or provider record, not only as free text in a comment, so it can be filtered and reported. The second is provider notice terms, meaning the advance notice a provider must give before changing locations or subcontracting, and the data return terms that apply on insolvency or termination. These terms come from the signed contract, so the field design should follow the clauses your lawyers have agreed, not a template invented by the GLPI team. Confirm the exact wording, units and mandatory status of each field in writing before it goes live.
Keeping the register current is an operations task, and it should be assigned an owner and a review cadence. Link each contract to the services and critical or important functions it supports, since Article 28(8) requires documented, tested exit strategies for ICT services that support those functions. A contract record without a linked service is a gap the register review should catch. Define who may create or change contract and provider records, and log those changes through GLPI's history. Then test the export against a sample of contracts with your compliance team before the supervisor asks for it. The output should be checked against the current contracts, not assumed correct because GLPI holds the data.
Rolling out GLPI in a regulated financial environment
The sequence moves from control mapping and hosting decisions through entity design, hardening, data load and approval testing to a documented handover, so that each phase produces evidence an auditor or supervisor can trace. Each phase depends on the one before it, so skipping ahead usually means rework in the entity model or the register.
Map scope and controls with compliance
Start by agreeing which regimes apply to the GLPI instance: DORA for EU financial entities, PCI DSS if cardholder data environments are touched, SOX ICFR if IT general controls matter for financial reporting, or the FTC Safeguards Rule for non-bank institutions under FTC jurisdiction. Compliance, internal audit and IT should map each requirement to the GLPI records that will hold the evidence, such as the ICT register fields, change records and access reviews. Done means a signed control map that names an owner for every evidence source and states which controls GLPI does not cover. Confirm the applicable obligations with your compliance team and legal counsel, since DeployOpen prepares evidence but does not interpret regulation for you.
Decide architecture and hosting location
Record where the instance will run, which data centers or cloud regions hold GLPI and its database, and where backups and inventory agents report. DORA Article 30(2) expects contracts to state where services are provided and data processed, so the hosting location decision feeds directly into vendor contracts. Check the supported stack in the installation docs (PHP and MySQL or MariaDB versions for your target GLPI release) and plan the web server layout so the public directory is the document root. Done means an architecture record with the hosting location, component versions, network zones and a named exit or data return path for each component.
Design entities and profiles
Model entities for business units, legal entities or regions, then define profiles and access rules so staff only see the assets, tickets and contracts their role requires. Separate duties for administrators, change approvers and asset custodians so no one can both raise and approve a change. Test the design with a small set of accounts in a non-production instance before any production data arrives. Done means a written access matrix that reviewers can compare against actual GLPI profiles, with each profile tied to a business role and a review owner.
Configure authentication and harden the instance
Connect the instance to your identity source, typically LDAP or Active Directory, and set the order in which internal and external authentication methods are tried so local accounts do not bypass central controls. Enforce multi-factor authentication for every user with access to an information system, as the FTC Safeguards Rule expects unless an equivalent control is approved in writing. Apply hardening steps for session cookies, encryption keys, exposed endpoints and status pages, and back up the glpi.key and glpicrypt.key files securely. Done means a hardening checklist signed by the security team, plus test results showing that a disabled account cannot sign in.
Load data and roll out inventory agents
Import the asset register, contract records and supplier data from source spreadsheets or systems, keeping the original files and a load log for each batch. Deploy GLPI Agent to endpoints in waves, starting with a pilot group, and reconcile the agent inventory against the existing asset register to find gaps and duplicates. Record which records came from imports and which from agents, since auditors will ask how each entry was created. Done means a reconciliation report with counts of matched, unmatched and duplicate assets, and an agreed list of exceptions with owners.
Validate change and approval workflows
Build the change and approval workflow in the same way it will run in production, with approval steps that match the delegation in your change policy. Run test changes through each path, including emergency changes, rejected changes and changes that touch systems in scope for critical or important functions. Confirm that every approval is recorded with the approver identity, timestamp and decision, since these records become the audit trail. Done means a test log where each workflow path has a passing case and a recorded approval, and any gaps have an agreed fix.
Test controls and capture evidence
Run a structured test script covering access reviews, backup restores, role changes, audit log retention and the ICT register export, then store the results with the control map from the first step. Where a test fails, record the finding, the fix and a retest, so the evidence shows the control working over time rather than only on the day of go-live. If the instance supports a threat-led penetration test or external security assessment, schedule it after the controls are stable, and keep the scope statement with the results. Done means an evidence pack indexed to each control, ready for internal audit or an external assessor to sample.
Hand over operations with documented runbooks
Transfer day-to-day ownership to your operations team with runbooks for backups, the update procedure (which requires a database backup, file backup and config directory backup before replacing application files and running the database update), plugin reactivation after major updates, and exit or data return steps. Agree who approves upgrades and how upgrades are tested first, since GLPI 11 suspends plugins after a new version is detected. Done means a signed handover record listing owners, runbooks, monitoring alerts and the next scheduled control review, with the exit strategy tested at least once.
Choosing self-hosting, managed cloud or a hybrid for GLPI
Self-hosting runs GLPI in your data center or your cloud account, under your network controls and your operations team. The web server, database, backups and encryption keys all sit inside your control boundary, so you decide where every copy lives. The trade-off is that your team carries patching, capacity planning and recovery work for the life of the platform.
- Data residency: You choose the location of the primary database, replicas and backups, which gives you direct control over the location details your ICT service contracts must state.
- Encryption keys: Your team generates and stores
glpi.keyandglpicrypt.key, and both must be backed up with the rest of the configuration, as the GLPI update procedure requires. - Exit planning: Export, restore and any move to a successor tool stay in your hands, but you still need to rehearse them.
- Support: Support comes from your staff and any partner you contract. A GLPI Network self-hosted subscription adds vendor support, with the Enterprise tier including level 3 support.
- Upgrade load: Major upgrades remain your work, including reactivating plugins after GLPI 11 detects a new version.
Check which keys, backups and recovery steps your team can run without the vendor on the day something fails.
With public cloud, Teclib' operates the GLPI instance on shared infrastructure, and the GLPI Network subscriptions page lists the price at 19 euros per user per month. The provider decides the hosting region, sub-processors and operational access, so each of these needs written confirmation before any regulated data enters the platform.
- Price model: The listed rate is per user per month. The 25-user minimum on the page applies to private cloud, so ask whether public cloud has any minimum.
- Data residency: Confirm the hosting region, backup locations and whether support staff access data from outside the EU.
- Encryption keys: Ask who generates and holds the keys, whether you can supply your own, and how keys are handled at termination.
- Exit planning: Request a documented export format, export timelines and written confirmation of data deletion, because DORA expects tested exit strategies for ICT services that support critical or important functions.
- Support levels: Confirm which support tier is included, the response commitments in writing and which provider roles can view your tickets and assets.
Get these answers in the contract before the pilot, not after the first audit request.
Private cloud gives you a dedicated GLPI Network instance. The subscriptions page lists it at 21 euros per user per month with a 25-user minimum. Isolation is tighter than public cloud, but the operator still runs the platform layer, so the same questions about location, keys and exit still apply.
- Price model: The listed rate is 21 euros per user per month, and the 25-user minimum applies even to small teams. Confirm how users, agents and read-only accounts are counted.
- Isolation: A dedicated instance does not by itself settle who can reach backups or administrator sessions, so ask how those are separated from other customers.
- Data residency: Confirm the hosting country for the instance, its backups and any disaster recovery copy.
- Encryption keys: Ask whether the provider holds the database and file encryption keys, and whether a customer-managed key option exists.
- Exit and support: Confirm export at termination, the time allowed to return data and certified deletion, and the support tier included in the price.
Ask the provider to show the isolation and key-management evidence you will need for your own third-party risk file.
A hybrid splits GLPI across two environments, usually by data sensitivity or function. For example, an illustrative design could keep the authoritative asset register and change approvals in your own data center while a vendor-operated service handles lower-sensitivity intake. This can match the risk profile of different records, but it also creates two operating models, two sets of contracts and a synchronization path to govern.
- Split by data class: Decide which records must stay in your control, such as asset registers, approval evidence and entity data, and which can move.
- Two contract sets: Each environment needs its own register entry, data location terms and exit plan, as DORA Article 28(3) requires for contractual arrangements.
- Integration risk: Identity federation, API tokens and sync jobs become new attack paths and must be tested like any other interface.
- Keys: Keep keys for the sensitive store on your side, and document which key protects which data set.
- Exit and support: Plan the exit for both halves together, including how records are reconciled when one side leaves.
Confirm that a single person can explain where each record lives and which provider can access it.
Compliance considerations DeployOpen prepares evidence for
Financial institutions answer to several regimes at once, and the same GLPI records often serve more than one of them. The cards below show which GLPI data each regime tends to ask for and what to confirm before the build starts. DeployOpen prepares systems, controls and evidence, but independent auditors, Qualified Security Assessors, supervisors and regulators decide whether requirements are met.
DORA ICT asset and contract register
DORA Article 28(3) requires a register of information covering all contractual arrangements for ICT services, and Article 30(2) requires each ICT contract to state where services are provided and data processed. In GLPI, this usually means linking supplier records, contracts and the assets they support, so the register can be exported from one source. Confirm with your supervisor and legal team which fields the register must hold, and who maintains the link between a contract and the assets it covers.
PCI DSS v4.0.1 scope of the GLPI instance
If GLPI stores asset records for systems in the cardholder data environment, or its tickets contain cardholder data, the GLPI instance itself may fall into PCI DSS scope. Scope is decided by the assessor and the payment brands, not by the platform owner. Document which asset types, network segments and ticket categories touch payment systems, and decide early whether GLPI sits inside or outside the boundary.
Swift CSCF attestation evidence
Swift users must have the Customer Security Controls Framework controls independently assessed and attest compliance each year in the KYC-SA application. For GLPI, the relevant evidence is usually an accurate inventory of Swift-connected servers, operator workstations and their software versions, plus change records for the systems that touch Swift. Confirm with your Swift security officer which assets are in scope before you build the inventory.
SEC ICFR IT general controls
SEC guidance on internal control over financial reporting names program changes, computer operations and access to programs and data as IT general control areas. GLPI change records, approval workflows and entity-scoped access rules can supply evidence for these areas if they are configured and retained consistently. Ask your external auditor which change approvals and access reviews they will sample, and test that GLPI produces those records on demand.
FTC Safeguards Rule authentication
The FTC Safeguards Rule requires multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing. For a GLPI instance that holds customer-related tickets or records, this means reviewing how staff sign in, whether MFA is enforced for local accounts and whether directory or SSO sign-in covers every access path. Record the written approvals for any exception, and keep them with the GLPI access review evidence.
NIS2 and DORA interaction
DORA is a sector-specific Union legal act for the purposes of NIS2 Article 4 for financial entities identified as essential or important entities. In practice, the asset inventory and incident records you keep in GLPI may need to serve both regimes, so one record should not be built twice. Confirm with counsel which obligations apply to your entity, and map each GLPI record type to the regime that uses it.
What banks ask before outsourcing a GLPI build
What drives the cost of an outsourced GLPI build at a bank?
The written scope drives cost more than anything else. The main components are discovery and requirements, the design of entities, profiles and authentication, integration work with directories and identity providers, data loading from existing registers, hardening and testing, documentation, and knowledge transfer to your staff. Ongoing items such as support, upgrades and continuous testing are usually priced separately as retainers. Your own infrastructure costs, including cloud or data center capacity, database hosting and backups, are paid to your providers, not to DeployOpen. When you request a quote, ask for each component as a separate line, the one-time work versus the recurring work, the assumptions about data volume and number of integrations, and what changes the price if scope grows. DeployOpen does not publish a price list; a quote follows from the written scope.
How long does a GLPI build take, and what sets the duration?
Duration depends on the number of integrations, the volume of asset data to migrate, the number of entities and approval paths, and how many internal reviews and sign-offs the bank requires. A build that only installs GLPI with one directory connection is much shorter than one that includes change approvals, DORA-oriented asset registers, contract records and tested backups. Your security review, change windows in your own data center or cloud account, and availability of your staff for testing are often the longest waits. Ask for a timeline in the written scope with named milestones, the dependencies on your side, and the acceptance tests that close each phase. Any date you are given should be tied to those dependencies rather than to a generic promise.
What must the bank provide before a GLPI engagement starts?
A bank needs to provide several inputs for the build to be planned accurately:
- Named staff for asset owners, IT service management, security, network and compliance, with decision rights documented
- Existing registers of ICT contracts and providers, including where services are provided, where data is processed and the exit terms in each contract
- Network access to the target environment, such as directory servers, database hosts, mail relays and monitoring endpoints, through change-controlled routes
- Written sign-off on the scope, acceptance criteria, data classification and the hosting location
Also confirm which cloud accounts, data centers or air-gapped networks will host GLPI, who holds administrative access, and how secrets and encryption keys will be stored. Agree these items in the written scope before work starts.
Can an internal team build and run GLPI without an outside partner?
Yes, many internal teams can, provided they have engineers who can operate Linux, a web server, a supported PHP and database stack, and directory integration. The harder parts for banks are usually the controls around the platform: entity and profile design for segregation, change approval workflows that produce audit evidence, documented exit and data return procedures, and tested backups. Internal teams often underestimate the upgrade work and the time needed to keep plugins compatible. Before deciding, compare your team's available hours and skills against the scope, and ask a partner to state which deliverables it would leave with your team. Whichever route you choose, the operating runbooks and the decisions behind them should belong to the bank.
How are upgrades to GLPI 11 and GLPI 12 handled?
GLPI 11.0.0 was released on October 1, 2025 and GLPI 12.0.0 on October 7, 2026, according to the GLPI releases page. The update procedure requires a database backup, a backup of the files and the config directory including the keys, replacing the application files and running the database update console command. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so each plugin needs a compatibility check before the change window. Confirm in the written scope whether the upgrade is a one-time task, a retainer, or part of a support agreement, and whether it includes a staging rehearsal, rollback steps and plugin testing. Check GLPI's own release notes for the version you target before scheduling.
Are GLPI plugins safe to use in a bank environment?
A plugin is safe only when its source, maintenance status and permissions have been reviewed for your environment. Start with the plugins you need for the defined use case and remove any that do not serve it. Check whether each plugin is supported, whether it is maintained for the GLPI version you run, whether it requests database or file access beyond its purpose, and how it handles credentials and personal data. Test every plugin in a non-production copy before enabling it, and record the review in your change records. Ask the partner for a written list of plugins in scope, the review criteria used, and the process for disabling a plugin that fails testing or is no longer maintained.
What happens to data, keys and configuration at exit?
Your contracts with any provider should state how data is returned and deleted, and GLPI should be designed so that this is practical. Keep the database, the files and the config directory, including the encryption key files, under your control, and document where each copy is stored. At exit, the expected deliverables include a full export of asset, ticket and contract records, the configuration needed to rebuild the instance, a list of integrations and credentials to rotate, and a confirmed deletion of copies held by a provider. Confirm in the written scope who holds the keys, how they are rotated, whether the exit plan has been tested, and how long the provider keeps backups after termination.
Which compliance evidence should the build produce for DORA?
DORA requires financial entities to keep a register of information on all contractual arrangements for ICT services, and the contract terms must state where services are provided and data processed. GLPI can hold the asset and contract records that feed that register, but the register itself is a bank obligation and must be reviewed by your compliance function. Ask the partner to map which GLPI objects and fields support each register column, what evidence the change approval workflow produces, and how the records are kept current. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and supervisors make those judgments.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted GLPI inside your own infrastructure, including your cloud accounts, data centers or air-gapped networks. For a bank or financial services firm, the work starts with the regulatory evidence GLPI must hold and then shapes the build around it.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names which regulatory evidence GLPI must produce, such as ICT asset registers and change approval records.
- Scope also records entity layout, identity sources, hosting location and the in-house owners who will run GLPI afterward.
How we build
- Deployment follows the GLPI installation requirements, with the web server document root set to the public directory.
- Authentication, entity isolation and profile rules are configured and tested against the access model in the written scope.
- Agents, plugins and the GLPI 11 or 12 upgrade path are built, tested in a non-production environment and documented before go-live.
How we hand over
- Handover includes configuration records, runbooks for backups and updates, and the evidence each control produces.
- Encryption keys, the config directory and database backup procedures are documented so your team can restore GLPI independently.
- Test results cover access, change approvals and asset inventory, mapped to the controls named in the written scope.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover GLPI version upgrades, plugin reactivation after major updates and periodic access reviews.
- Ask any provider to confirm which regulatory assessments they prepare for and which remain with your auditors or supervisor.
