Why open source ITSM for financial services starts with DORA evidence
For a financial entity in scope of DORA, the service desk, asset records and change control have to produce evidence a supervisor can check. DORA, Regulation (EU) 2022/2554, has applied since 17 January 2025 to 20 types of financial entity, and it applies directly without national transposition. Article 28(3) requires a register of information covering all contractual arrangements for ICT services, and Article 28(8) requires documented, tested exit strategies for services that support critical or important functions. Your ITSM tool is where the underlying facts live: which service depends on which asset, which provider supplies it, and what happened when it failed. Before choosing a product, confirm with your compliance team which of these records must be exportable on request and in what format.
The function differs in financial services because the same ticket and CMDB records serve several regimes at once. PCI DSS v4.0.1 is the only active version, and its future-dated requirements became effective on 31 March 2025, so any system in the cardholder data environment needs change approvals and inventory that stand up to a Qualified Security Assessor. For US-listed firms, SEC Release 33-8810 names program changes, computer operations and access to programs and data as IT general control areas for SOX Section 404 assessments. A single change record with approver, test evidence and back-out plan can answer all three, but only if the process is designed for it from the start. DeployOpen prepares these controls and evidence for assessment; the assessor, not the vendor, issues any attestation.
In short, GLPI fits the asset and CMDB side. It is distributed under GPL-3.0, GLPI 12.0.0 was published on October 7, 2026, and GLPI Agent collects hardware and software inventory from Windows, macOS and Linux endpoints. Combodo iTop, licensed under AGPL-3.0 with version 3.3.0 published on September 15, 2026, fits organizations that need a customized CMDB model with richer relationships between services, providers and assets. Choose the ticketing workflow on process needs such as incident classification, approvals and escalation rules, then confirm the platform's supported database and PHP versions and its upgrade path before committing. Those checks, not the product name alone, decide whether the evidence trail holds up.
Which financial rules set the ITSM requirements
This table maps each financial rule to what it asks of the service management tool, the evidence an assessor or regulator expects, and the entity types it applies to. Read it by first finding your entity type in the applicability column, then checking the meaning for the build. Applicability depends on your license, jurisdiction and contracts, so confirm scope with your compliance lead before designing the CMDB.
| Rule or requirement | What it means for the ITSM build | Applies to |
|---|---|---|
| DORA Article 28(3): register of information | Keep a register of all contractual arrangements for ICT services, linked to the CMDB service and asset records so each provider maps to the systems it supports. | EU financial entities in scope of DORA, applicable since 17 January 2025 |
| DORA Article 28(8): exit strategies and transition plans | Record documented, tested exit and transition plans for ICT services supporting critical or important functions, with links to the services, owners and contract records. | EU financial entities with critical or important functions supported by ICT third parties |
| DORA Article 30(2): contract terms on location and data return | Store the service location, data processing location, change notice terms and data return conditions as structured fields on each third-party contract record. | EU financial entities contracting ICT services under DORA |
| DORA Article 8 and Article 17: asset and dependency identification, incident management | Model ICT assets and dependencies in the CMDB, then classify and time-stamp ICT-related incidents against those assets for regulator reporting. | EU financial entities in scope of DORA; sibling topic covers the Article 8 and 17 detail |
| SEC Rule 17a-4(b)(4): communications retention | Where ITSM tickets hold business communications, confirm the retention period of not less than three years and whether the tool's storage and deletion settings can meet it. | US broker-dealers subject to SEC recordkeeping rules; confirm with counsel |
| SEC Release 33-8810: ITGC areas for SOX 404 | Use change records, access reviews and incident and problem tickets as evidence for program changes, computer operations and access to programs and data. | US public companies with SOX 404 internal control assessments |
| FTC Safeguards Rule 16 CFR 314.4(c)(5): MFA | Enforce multi-factor authentication for every ITSM user account, or document a written equivalent control approved by the Qualified Individual. | Non-bank financial institutions under FTC jurisdiction |
| Swift CSP v2026: 32 controls, 26 mandatory, 6 advisory | Map ITSM assets, change records and access evidence to the relevant Swift controls, since users must have controls independently assessed and attest annually in KYC-SA. | Swift users; confirm which architecture types apply to your environment |
| PCI DSS v4.0.1: scope and change control | Keep an accurate inventory of system components in the cardholder data environment and approval, testing and back-out records for changes to them. | Entities that store, process or transmit cardholder data, or could affect its security |
How the rule set changes by entity type
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. It applies directly without national transposition, so an EU credit or payment institution needs its ITSM tool to hold the working records behind its ICT register and its incident trail. Whether your entity is in scope, and which articles apply to you, is a question for counsel. The regulation text is available on EUR-Lex.
- Register of information: one record per ICT contract, linked to the services it supports and flagged where a service supports a critical or important function (Article 28(3)).
- Service locations and data processing: where each service is provided and where data is processed, with the history of advance notices of change and the data return terms from the contract (Article 30(2)).
- Exit plans: documented, tested exit strategies and transition plans for ICT services that support critical or important functions, stored against the service record (Article 28(8)).
- ICT incident records: timestamps, classification, affected services and assets, and the decisions taken, to support the incident management process in Article 17 and any reporting duties.
- Supplier and asset links: each incident and change tied to configuration items, so the register and the incident trail can be reconciled during a supervisory request.
Confirm with counsel which entity type you fall under, and confirm the current reporting timelines with your competent authority before you configure ticket states and SLAs.
Broker-dealers registered with the SEC must preserve communications under Rule 17a-4(b)(4) of the Exchange Act rules, which requires originals of communications received and copies of communications sent relating to the business, including inter-office communications, to be kept for not less than three years. The ITSM tool does not hold the compliant archive itself. Its role is to hold the operational records that show how the systems carrying those communications were changed, accessed, repaired and backed up. The rule text is on the eCFR.
- Change records for communications systems: approval, implementation and back-out records for mail, chat and archive platforms, linked to the affected configuration items.
- Incident records: outages, data loss or failed archive jobs on in-scope systems, with timestamps that show when preservation may have been affected.
- Access requests: who requested and approved access to archive and supervision systems, and when that access was removed.
- Asset and location records: which hosts, storage and backup targets hold business communications, and where they are located.
Ask counsel whether your ITSM tickets about these systems are themselves business records subject to the rule, and set retention in the ITSM tool to match the answer.
Non-bank financial institutions under FTC jurisdiction fall under the Safeguards Rule in 16 CFR Part 314. Section 314.4(c)(5) requires multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing. For a lender, the ITSM tool is where the inventory of systems holding customer information and the evidence behind access decisions should live, so that the MFA position can be shown system by system. The text is on the eCFR.
- System inventory: every information system that holds or reaches customer information, with an owner, a hosting location and a link to the identity provider group that controls access.
- Access request and approval records: who was granted access, who approved it and when, kept with the request ticket.
- MFA exception records: written approvals by the Qualified Individual for any equivalent control, stored as linked approval records with review dates.
- Incident and vendor records: incidents that affect customer information and the service providers that host or process it, each with its contract reference.
Confirm with counsel and your Qualified Individual which systems fall under the Safeguards Rule, and check whether any state rules add record-keeping or notice obligations.
PCI DSS applies to entities that store, process or transmit cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment (CDE). This includes merchants, processors, acquirers, issuers and service providers. The current version is v4.0.1, published 11 June 2024, and the future-dated v4.0 requirements became effective on 31 March 2025. The PCI SSC does not enforce compliance. The payment brands decide who must validate, and assessments are documented as a Report on Compliance or a Self-Assessment Questionnaire, each with an Attestation of Compliance. The standard is on the PCI SSC site.
- CDE component inventory: every system component in or connected to the CDE, with its owner and network zone, so the assessed scope is traceable.
- Change records with approval and testing: approval, test evidence and back-out plans for changes to in-scope components, which map to the change control requirement in 6.5.
- Vulnerability remediation tickets: tickets tied to in-scope assets, showing when findings were raised, assigned and closed.
- Service provider records: third parties that affect the CDE, with their responsibility matrices and contract references.
- Assessor exports: saved reports that a QSA or internal reviewer can sample during the assessment.
Ask your acquirer or payment brand which validation level and assessment type applies to you, and confirm with your QSA which ITSM exports they will accept as evidence.
Which open-source ITSM platform fits which financial workload
Financial institutions rarely need one tool for every service management task. The cards below separate ticketing and financial records, CMDB and change modeling, customer-facing support queues and endpoint inventory, so each register or regulator request can be traced to the system that holds its evidence. Confirm each product's audit, retention and export features against its own documentation before you commit to a design.
GLPI for tickets, assets and contracts
GLPI combines ITIL incident and request handling with asset records, contracts and financial management under GPL-3.0. Version 12.0.0 was released on October 7, 2026. For DORA, the contract and supplier fields are the natural starting point for the register of information on ICT contractual arrangements, and the ticket history can serve as the first incident timeline. Confirm in the vendor documentation how contract records can be exported and whether change history on tickets is retained in a form an auditor can review.
iTop for a customizable CMDB
Combodo iTop is licensed under AGPL-3.0 and lets you model CMDB classes, relationships and change workflows to match your critical business services. That matters when a regulator asks which applications and providers support an important function. Confirm that the data model can express the dependencies your ICT risk team needs, and that change records can hold approval, testing and back-out fields in a way your change board will accept.
Zammad or FreeScout for customer queues
Use a separate helpdesk only where a customer-facing support queue needs its own channels, customer identity and reply history, such as a retail banking or payments contact channel. Zammad and FreeScout are both licensed under AGPL-3.0. Keep the link to the internal ITSM record through a defined ticket reference, and confirm how incidents raised from customer complaints are escalated into the incident process and timestamped.
GLPI Agent for endpoint inventory
GLPI Agent collects hardware and software inventory and runs on Windows, macOS and Linux. Complete, current inventory supports asset registers, unauthorized software checks and the link between endpoints and business services. Confirm the inventory frequency you can justify, how agents are deployed and authenticated across regulated segments, and how stale or decommissioned devices are removed so the register stays accurate.
How a CMDB supports regulator requests on short notice
When a supervisor asks for evidence on short notice, the answer is assembled by joining three records: the register of information on ICT contractual arrangements under DORA Article 28(3), the CMDB relationships that tie business services to applications, hosts and suppliers, and the incident and change history with reliable timestamps. A CMDB that holds these links in GLPI or iTop lets an operator answer "which services depend on this provider, and what changed there last quarter" from one place instead of from spreadsheets. Before go-live, confirm with your compliance team which fields the register must carry and map each one to a CMDB class or relationship, so the export matches what the supervisor will ask for.
Article 30(2) requires every ICT services contract to state where services are provided and where data is processed, and to give advance notice of changes to those locations. In practice, the location and processing-location fields must be mandatory on the supplier and contract objects, not optional notes. Assign an owner to update them when a provider moves hosting, and run a periodic check that every active supplier linked to a critical or important function has both fields populated. Confirm in your own environment whether your chosen GLPI or iTop data model enforces this, or whether it needs custom fields and reporting.
A recovery plan must cover the GLPI application itself. The update procedure in the installation documentation requires backing up the database, the files and the config directory, and that directory holds glpi.key and glpicrypt.key. Without those keys, encrypted values in the database cannot be read after a restore, so the register and CMDB would be unusable even with a good database backup. Store copies of both keys separately from the server, record who can retrieve them, and test a restore into a non-production instance on a schedule that fits your exit plan under DORA Article 28(8).
Deployment pattern for a regulated ITSM estate
A GLPI deployment for a financial entity is a set of components, each with a requirement the auditor or the regulator will eventually ask about. The cards below cover the platform layers, the identity and agent model, and the environment controls that connect them, so that the register and incident evidence come from a system you can explain end to end.
Dedicated database layer
GLPI supports only MySQL and MariaDB, so the database is a fixed design choice. The installation docs list MySQL 8.0 or MariaDB 10.6 for GLPI 11.0, while the README on the main branch lists MariaDB 10.11 or MySQL 8.0 for the current line. Use a dedicated instance with encrypted backups, and confirm which version your target release requires before procurement.
Web server and document root
The web server must point its document root at GLPI's public directory, not the installation root, with URL rewriting routing requests through index.php. This keeps configuration and source files out of web reach. Confirm the Apache, Nginx, lighttpd or IIS configuration with your security team, since the document root is one of the first items a penetration test checks.
Identity with local fallback
GLPI tries the internal database, LDAP directories, IMAP servers and external methods such as REMOTE_USER, in that order. Model the order deliberately: directory authentication for daily use, with a local administrator account kept for directory outages. GLPI 12.0.0 adds step-up authentication for certain administrative actions, which should be enabled and tested for privileged roles.
GLPI Agent rollout
GLPI Agent collects hardware and software inventory on Windows, macOS and Linux, and also runs network discovery and package deployment. Roll it out through your endpoint management tooling, measure coverage against the directory, and record which devices are unmanaged. Inventory gaps are the first finding in most asset reviews, so track them as tickets.
Monitoring and procurement integration
Incidents and changes are only as complete as the CMDB they reference. Connect monitoring alerts to ticket creation and feed procurement and contract records into GLPI so that the third-party register can be built from it. Document each interface, its owner, its data direction and the reconciliation check that proves it runs.
Separate test and production
Run a test instance with a copy of the configuration and a masked data set, and promote changes through it. GLPI's update procedure requires backing up the database, files and the config directory, including glpi.key and glpicrypt.key, and plugins are suspended after a new version is detected. Keep the key files out of the test copy's shared storage and record each promotion as a change.
How the rollout produces audit-ready records
The rollout runs in a fixed sequence so that each phase creates the register, mapping or log that the next phase depends on, and so that a regulator request can be answered from GLPI or iTop records rather than reconstructed from email. Effort depends on the entity's inventory size and contract count, which are confirmed during scoping.
Scope the entity and classify its ICT services
DeployOpen works with the compliance lead, the head of IT and the owners of critical or important functions to confirm which legal entities, business functions and ICT services fall under DORA and any other applicable rules. Each service is classified by its importance to the function it supports. The output is a written scope document and a classification list that names an owner for every service. The step is complete when the owners have signed off the list and the scope is agreed in writing before further configuration starts.
Build the register of information and map contracts
Every ICT contractual arrangement is entered as a contract record in the ITSM tool and linked to the services it supports. Contract fields capture the provider, the location where services are provided and data is processed, notice terms for changes, and data return on termination or insolvency, so the record matches what DORA Article 28(3) and Article 30(2) ask the entity to hold. Contract owners check each entry against the signed agreement. The output is a populated register that can be exported for a supervisor and a list of gaps that procurement must close.
Model the CMDB and run discovery
The team defines CMDB classes for the entity's business services, applications, infrastructure and their dependencies, then deploys GLPI Agent or the chosen discovery method across the estate. Discovered items are reconciled with procurement and monitoring data, and unmatched items are assigned to an owner. The output is a dependency map linking services to assets and contracts, which supports the ICT asset and dependency identification that DORA Article 8 expects. The step closes when the reconciliation backlog is below an agreed threshold and each critical service has a named owner.
Configure incident classification and the reporting workflow
DeployOpen configures incident categories, impact and severity fields, and a classification workflow that records the decision and the approver for each major ICT-related incident. Automatic timestamps capture detection, classification, notification and closure, and the workflow links each incident to affected services and assets in the CMDB. The regulator-facing report templates are built from these fields. The output is a working incident record that shows the sequence of decisions with times, and the step closes when test incidents produce a complete timeline without manual edits.
Set up change control and ITGC evidence
Change types, approval paths, testing evidence and back-out plans are configured as required fields, with separate handling for emergency changes. Access to change approval and to configuration of the ITSM platform is restricted and logged, so that the records can serve as evidence for the IT general control areas that auditors examine, such as program changes and access to programs and data. The output is a sample of closed changes that show authorization, testing and review. The step closes when the internal audit or compliance lead has reviewed that sample.
Record the supplier exit plans
For each ICT service that supports a critical or important function, the team documents an exit strategy and transition plan as a linked record. The record names alternative providers or in-house options, data return steps, the systems and contracts affected, and the test or review date for the plan. The output is an exit plan per service that is attached to the contract and the service in the CMDB. The step closes when the owners of those services have confirmed their plans and a review date is set in the tool.
Test the reporting path with a tabletop exercise
The team runs a tabletop exercise on a realistic but invented incident scenario, illustrative of a third-party outage affecting a critical service, and follows the reporting path from detection through classification, escalation and notification. The exercise checks that the register, the CMDB links and the timestamps produce a complete evidence trail. Gaps are logged as tickets with owners and dates. The output is an exercise report and a corrected workflow. The step closes when the gaps from the exercise are resolved or accepted in writing by the accountable executive.
Hand over the platform and its evidence set
DeployOpen delivers the configured platform with administration documentation, the register and CMDB exports, the workflow and approval configuration, and a runbook for updates and backups. Operators are trained on incident and change records, and the regulator-request procedure is documented with named roles. Ongoing support, if chosen, is agreed as a separate retainer. The step closes with a signed handover record that lists each artifact, its owner and where it is stored, so the entity can answer a supervisory request without relying on the implementation team.
Evidence regulators and auditors ask for, and what produces it
This table maps the evidence a financial entity typically needs to show a supervisor or auditor to the GLPI component that produces it. Read the middle column for where the record comes from and the last column for whether configuration alone is enough or a written procedure must back it up. The main takeaway is that the ITSM tool produces records, but the governance around them is still a documented process the entity must own.
| Evidence item | Produced by GLPI component | Configuration or written procedure |
|---|---|---|
| Register of information export (DORA Article 28(3)) | Contracts and suppliers records linked to ICT services, exported as a list of contractual arrangements | Configuration plus procedure: the entity must confirm the register covers every arrangement and is kept current |
| Contract terms on service location and data return (DORA Article 30(2)) | Contract fields and attached documents on each supplier record | Procedure: contract content comes from legal review; the tool only stores and links it |
| ICT asset list supporting critical or important functions | Inventory from GLPI Agent and assets linked to business services in the CMDB | Configuration: asset types and service links; procedure: defined criteria for what counts as critical |
| Incident log with classification and reporting timestamps | Incident tickets with category, impact fields and creation, update and closure timestamps | Configuration: mandatory classification fields; procedure: the classification criteria and reporting clock rules |
| Change approvals for SOX IT general control areas | Change records with approval steps, implementation dates and linked assets | Configuration: approval workflow; procedure: emergency change handling and segregation of duties |
| Access review records for MFA and admin step-up | Session and administrator activity visible in GLPI, plus authentication source settings | Procedure: the periodic review itself, signed by the owner; the tool supplies the underlying data |
| Retention settings for communications records | Ticket and notification retention is not a regulated archive by default | Procedure: retention schedules and archiving of communications, confirmed against the applicable rule and the entity's archive |
Questions to ask an ITSM implementation partner before you sign
Start by asking how the partner maps the fields that DORA Article 28(3) and Article 30(2) require into GLPI or iTop. Ask which object will hold each contractual arrangement, which custom fields or classes will record the service locations, data processing locations and advance-notice terms, and how a contract record links to the ICT services and the business functions they support. Ask for a sample record filled with illustrative data and check whether an auditor could trace it from the register to the underlying contract without help. Also ask who keeps the register current when procurement signs a renewal, because a register that drifts from the contracts fails the first time a supervisor asks for it.
Next, ask who owns the incident classification criteria. The partner should configure the classes, priorities, categories and escalation rules that your entity has approved, not a generic scheme of its own. Ask how those criteria are stored in the ticket template, how changes to them are versioned and approved, and whether existing tickets keep the classification that applied when they were raised. Then ask how the partner would test an exit plan for your ITSM supplier under Article 28(8): which data would be exported from GLPI or iTop, in what format, how often the export is rehearsed, and who signs off the result. Ask for the backup scope too, including the database, the files and the glpi.key and glpicrypt.key files, and how those keys are escrowed. Finally, ask how the support subscription interacts with self-hosted upgrades. Confirm with the vendor which support tier covers which versions, and whether the partner tests plugins after each update, since GLPI 11.0 suspends plugins until they are reactivated. Ask the partner to state in writing that it prepares evidence for your assessors and does not issue audit reports or certifications.
How much effort and cost does open source ITSM for financial services take?
What drives the cost of open source ITSM for a financial services firm?
Cost is driven mostly by scope and people, not by the software license, because GLPI and iTop are open-source platforms with no per-agent fee for the core product. The main cost components are the configuration of processes and the CMDB, the rollout of inventory agents, data migration from existing registers, integration with identity and monitoring, and ongoing administration. Each one rises with the number of entities, the number of in-scope systems and the depth of the DORA evidence you need. A written scope should list the ITIL processes, the CMDB classes, the number of endpoints and the systems to integrate, so each cost can be priced separately.
Is GLPI support subscription pricing published, and what does it cover?
Yes, GLPI Network publishes subscription prices, which are separate from the software itself. According to the GLPI Network subscriptions page, the public cloud option costs 19 euros per user per month, the private cloud option costs 21 euros per user per month with a 25-user minimum, and self-hosted subscriptions range from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise), which includes level 3 support and access to GLPI Network marketplace plugins. Confirm current prices and terms directly with the vendor, because a support tier is an optional cost that your in-house team or implementation partner may or may not need.
How long does it take to produce audit-ready evidence from a new service desk?
Time to audit-ready evidence depends on how much historical data must be reconstructed and how quickly process owners approve the workflows. A firm with clean asset data and a defined incident classification model can reach a first evidence set sooner than one that must rebuild its contract and third-party registers from spreadsheets. The timing should be set in the written scope, with milestones for the CMDB baseline, the register of ICT contracts, the incident workflow and a dry-run regulator request. Ask any partner to show which evidence artifacts are produced at each milestone and to name the date you can test them.
What does the bank or fintech team have to provide before implementation starts?
The team has to provide decisions and data that only the firm can supply. The main inputs are:
- Named process owners for incident, change, asset and third-party management, with authority to approve workflows
- Contract data for ICT services, including provider names, service locations, data processing locations and exit terms
- Written incident criteria that define what counts as a major ICT-related incident and who classifies it
- Existing asset lists, license records and network ranges for discovery and migration
- Identity source details for single sign-on and access roles
Missing inputs are the most common reason for delay, so confirm ownership of each item before the scope is signed.
Can our internal IT staff run GLPI or iTop after go-live?
Yes, many financial services teams run the platform internally once it is stable, but they need named administrators with platform skills and a clear upgrade routine. Routine work includes managing agents, reviewing the CMDB, maintaining workflows and applying updates. GLPI's update procedure requires a database, file and configuration backup, and plugins are suspended after a new version is detected in GLPI 11.0 and later, so updates need a planned test window. Decide before go-live whether the team will run it alone, use a retainer for upgrades and support, or split the work. Ask any partner to hand over runbooks and to train the staff who will own the platform.
Does DeployOpen issue compliance attestations for DORA or other rules?
No, DeployOpen does not issue audit reports, attestations or certifications. DeployOpen prepares systems, controls and evidence for compliance assessments, such as configured incident workflows, CMDB records, change approvals and register exports. Independent auditors, supervisors and certification bodies decide whether controls meet a requirement. DORA itself sets no certification scheme, so a sound readiness package should be presented as evidence for your auditors and supervisors, not as a certificate. Ask any partner to state this boundary in the written scope.
What recurring costs should we budget beyond the first implementation?
Recurring costs include hosting and infrastructure, backups, patching and upgrades, agent maintenance, CMDB and register upkeep, and any support subscription or retainer you choose. One-time costs cover scoping, configuration, migration, integrations and testing. Ask for the recurring elements to be quoted separately from the project, with the frequency of upgrades, the support hours and the response model written down. Also confirm who pays for hosting capacity in your own cloud or data center, since that cost sits outside the software itself.
Which parts of the work should we keep in-house versus outsource?
Keep decisions on risk, incident classification and register ownership in-house, because regulators will ask the firm, not a vendor, to answer for them. Outsourcing usually makes sense for platform planning, hardening, configuration, integration and migration, where specialist experience shortens the work. A practical split is to retain process ownership and approvals internally, while a partner handles build, testing and handover. Define that split in the scope so each deliverable has one accountable party.
How DeployOpen scopes and supports financial ITSM
DeployOpen starts with a written fixed-scope agreement that names the ITSM processes in scope, the GLPI or iTop modules and CMDB classes to be built, the discovery sources, the integrations with identity and monitoring, and the evidence each assessment will request. Deliverables and timelines are agreed before work begins, so the compliance lead can trace every DORA register, incident record and change record to a line in the scope. Where a finance team needs an incident register that maps to the reporting timelines in its own policy, that mapping is written into the scope rather than left to implementation. Your own compliance and legal teams should confirm which ICT services fall under the register of information and which contracts must carry the Article 30(2) terms, since DeployOpen configures the records but does not decide the regulatory classification.
DeployOpen then plans, implements and hardens the platform inside your own cloud accounts, data centers or private network, so ticket data, inventory and third-party records never leave your control. Hardening covers the database, web server document root, backups of the configuration keys and access controls such as step-up authentication for administrative actions in GLPI 12.0.0, which your security team should verify against its own baseline. DeployOpen prepares the evidence packs that auditors and supervisors ask for, including exported change and incident histories, access reviews and exit-plan documentation, but it does not issue audit reports, attestations or certifications. After go-live, retainers cover upgrades, plugin revalidation after major versions, backups tests and ongoing support, and the support terms should be checked against the written scope before signing.
Sources and further reading
- Regulation (EU) 2022/2554 (DORA), EUR-Lex ↗
- 16 CFR Part 314, Standards for Safeguarding Customer Information, eCFR ↗
- SEC Release 33-8810, Commission Guidance Regarding Management's Report on ICFR ↗
- SEC press release 2023-139: SEC adopts rules on cybersecurity risk management and incident disclosure ↗
- 17 CFR 229.106 (Regulation S-K Item 106) Cybersecurity, eCFR ↗
- ECB: Adopting TIBER-EU will help fulfil DORA requirements (September 2024) ↗
