Open source ITSM for DORA: what Articles 8 and 17 ask your service desk to prove
A financial entity under DORA must identify and document its ICT assets and dependencies, and run an ICT-related incident management process that records and classifies every incident. An ITSM tool is the system of record for the asset map and the incident trail, not the whole compliance program. Article 8(1) asks for identification, classification and documentation of ICT-supported business functions, the information and ICT assets behind them, and their dependencies, with the classification reviewed as needed and at least yearly. Article 17 asks for a defined process to detect, manage, notify and log incidents, and for root causes to be identified and addressed. DORA applies from 17 January 2025 (Article 64). It is a regulation, directly applicable in member states, and it sets no certification scheme, so supervisors judge your evidence rather than a certificate. Confirm with your competent authority which entity types apply to you under Article 2(1) and Article 46, since the sibling page on financial services covers the timelines in more depth.
Your service desk can hold three records that supervisors will ask for: an asset register with configuration items linked to the business services they support, dependency links to ICT third-party providers, and incident tickets with timestamps, category, priority and severity, and linked assets. In GLPI, asset records, CMDB relations and tickets can be connected, and in iTop the CMDB model is customizable, so the design work is in agreeing which classes, relations and mandatory fields reflect Article 8(4) and 8(5). Decide early who owns each field, how remote sites are recorded, and how the yearly review and post-change updates under Article 8(6) are triggered. Confirm the configuration details for your chosen tool against its current documentation during scoping.
Incident records can show detection, classification and root-cause follow-up, but they cannot by themselves prove communication plans, management body reporting or the restoration of services. Those depend on procedures, roles and tooling outside the ticket, such as notification templates, escalation rules and reports for senior management. Plan the ticket workflow, custom fields and reporting so that a major incident can be traced from first record to closure, and agree with compliance which classification criteria under Article 18(1) the fields must reflect. Keep the audit trail intact by controlling who can edit or delete closed records and by backing up the database with the configuration files, which the GLPI update documentation also treats as essential.
Which DORA requirements an ITSM configuration must satisfy
This table maps each DORA provision in scope for ITSM (Articles 8 and 17) to what the service management function must do and how to set up GLPI or iTop to meet it. Read each row as a requirement, the configuration element that answers it, and the evidence an assessor will ask to see. The main takeaway is that DORA compliance depends on the data model (assets, relations and incident fields) as much as on the workflow itself.
| Requirement | What the function must do | How to configure GLPI or iTop |
|---|---|---|
| Article 8(1): ICT business functions and assets | Identify and classify the business functions, roles and the information and ICT assets that support them, and review this at least yearly | Create business service and application records linked to owning roles and supporting asset types; set a yearly review task and a classification field |
| Article 8(4): Critical assets and remote sites | Identify all information and ICT assets, including those at remote sites, and map which are critical | Use location hierarchy for remote sites, a criticality field on each asset, and GLPI Agent or network discovery to capture assets outside the head office |
| Article 8(4): Configuration, links and interdependencies | Map configuration, links and interdependencies between assets and services | Model relations between servers, applications, databases and network items in the CMDB (iTop relation classes or GLPI item links) and keep them as required fields for critical services |
| Article 8(5): Dependence on ICT third-party providers | Identify processes that depend on ICT third-party providers, including providers supporting critical or important functions | Create supplier and contract records linked to services; flag those supporting critical or important functions and link them to the affected business services |
| Article 8(6): Inventory updates | Keep inventories updated periodically and after every major change | Tie asset and CI updates to change records so each major change prompts a CMDB update; schedule periodic inventory review reports |
| Article 17(1) and (2): Incident process and recording | Run a defined process to detect, manage and notify incidents, record all ICT-related incidents, and identify and address root causes | Use a dedicated incident workflow with mandatory fields, problem records linked to recurring incidents, and root cause fields that must be completed before closure |
| Article 17(3)(a) to (c): Early warnings, classification and roles | Use early warning indicators, log and classify incidents by priority, severity and service criticality, and assign roles by incident type | Add ICT incident categories, a priority matrix combining impact and urgency with service criticality, and assignment rules or groups per incident type |
| Article 17(3)(d): Communication and escalation | Define communication plans, client notification, internal escalation and complaint handling | Use notification rules and escalation templates, and record client-facing communication and complaint references on the incident |
| Article 17(3)(e) and (f): Major incidents and senior reporting | Report major incidents to senior management and the management body with impact, response and added controls, and restore services securely and in time | Add a major incident flag with reporting fields for impact, response actions and added controls, plus service restoration timestamps and a dashboard for management reporting |
How a CMDB records ICT assets and third-party dependencies
GLPI records ICT assets as typed items such as computers, network equipment, software, monitors and racks, and connects them through relations, contracts, budgets and suppliers. Its data center and infrastructure objects let you record where an asset sits, which supports the mapping of critical assets that Article 8(4) asks for. Teams usually start here when they want one platform for assets, tickets and contracts, and when their interdependency map can be expressed through relations between items and services.
- Typed asset records: Create item types for the ICT assets your business functions depend on, and record owner, location and status on each one.
- Relations between items: Link assets to the services, applications and other assets they support, so dependencies can be queried rather than reconstructed from spreadsheets.
- Contract and supplier links: Attach contracts and suppliers to the assets they cover, which gives a starting point for the third-party register that Article 8(5) requires.
- Criticality attributes: Add fields or categories that mark which assets support critical or important functions, so the critical subset can be reported on directly.
- Configuration data: Store configuration details as fields or linked records, and confirm with your team which attributes must be kept for each class.
Before committing to this model, confirm with your architects that the relation types and asset classes can express every dependency your regulator-facing inventory must show.
iTop is built around a configurable CMDB, where classes, attributes and relations are defined by the implementer to match the entities your organization uses. This suits organizations that need a detailed configuration model, such as application components linked to servers, databases, network links and provider services. Because the class model is yours to shape, the design work happens early and the resulting structure has to be maintained as the estate changes.
- Custom classes and attributes: Define classes for ICT services, applications, infrastructure and providers with the attributes Article 8 requires, including criticality and documentation references.
- Explicit interdependency links: Model which services depend on which components, and which components depend on which providers, as first-class relations.
- Provider and contract objects: Represent third-party service providers and their contracts as objects linked to the services they support, which helps document processes that depend on those providers.
- Change-linked history: Connect configuration items to change and incident records so that the inventory can show what changed after a major change.
- Model governance: Assign an owner for the class model, because changes to classes affect every downstream report and integration.
Confirm with your implementation partner who will maintain the class model after go-live and how model changes are reviewed.
Article 8(4) expects ICT assets on remote sites to be identified, which in practice means discovery has to reach offices, branches, data centers and staff devices that are not on the main network. GLPI Agent collects hardware and software inventory and sends it to GLPI, and also performs network discovery and inventory, package deployment and remote ESX inventory. It runs on Windows, macOS and Linux and is the successor of FusionInventory Agent, so teams migrating from that agent should check their deployment against the GLPI Agent documentation.
- Agent-based inventory: Deploy GLPI Agent on endpoints and servers so that remote devices report to the central GLPI instance without requiring inbound connections.
- Network discovery: Use the agent's network discovery features at each remote site to find devices that have no agent installed, and record them as unmanaged items for review.
- Remote ESX inventory: Confirm whether remote ESX hosts can be inventoried in your topology and how credentials are stored.
- Reconciliation of discovered items: Define a process for matching discovered items with existing records, so duplicates do not undermine the inventory.
- Site attributes: Record the site on each asset so that remote estates can be reported by location.
Before rollout, confirm which sites have connectivity constraints and how each one will be covered in the discovery design.
Article 8(5) asks entities to identify and document processes that depend on ICT third-party service providers and the interconnections with providers whose services support critical or important functions. The tool can hold the provider record, the contract and the link to each service, but the judgment about which providers are critical comes from the organization's own risk assessment. Both GLPI and iTop can represent these links, and the choice depends on how much detail your register needs and who maintains it.
- Provider records: Hold the legal entity, contact, service description and criticality rating for each ICT third-party provider.
- Contract linkage: Attach contract terms, renewal dates and responsible owners to the provider and to the services under contract.
- Service-to-provider mapping: Link each business function and ICT service to the providers it depends on, including subcontracting chains where you can obtain them.
- Interconnection records: Document data flows and network interconnections with providers that support critical or important functions.
- Register export: Confirm that the register can be exported in a format your compliance team and supervisors accept.
Ask your legal and third-party risk teams to confirm which fields the register must contain before the data model is built.
Article 8(6) requires inventories to be updated periodically and after every major change. The tool supports this with timestamps, change links and discovery schedules, but the obligation itself is a process duty that belongs to change management and asset owners. A CMDB that is correct on the day of go-live can drift quickly if changes are not recorded, so the operating model matters as much as the software.
- Scheduled discovery: Set discovery frequency so that drift is detected between formal reviews, and confirm the schedule with your operations team.
- Change-triggered updates: Require that every major change record links to the affected configuration items and that the inventory is updated before the change is closed.
- Periodic review: Assign owners to review the classification and dependencies on a fixed cycle, which supports the yearly review referenced in Article 8(1).
- Audit trail: Use the history features of your chosen tool to show when records were created or changed.
- Ownership reporting: Report assets and providers without an owner or without recent verification.
Ask your implementation partner to document the update procedure as a process owned by a named role, because the software can record that updates happened but cannot decide that they must.
GLPI and iTop as open-source options for DORA record keeping
DORA Article 8 and Article 17 both depend on records that link assets, dependencies, incidents and their classification. The options below cover the two open-source ITSM platforms that can hold those records, plus the helpdesk tools that can feed customer complaints into them.
GLPI as the asset and ticket core
GLPI is IT asset management and ITIL service desk software licensed under GPL-3.0, with GLPI 12.0.0 published on October 7, 2026. Its scope covers tickets, assets, CMDB, contracts and financial management, so one platform can hold the Article 8 inventory and the Article 17 incident log. Check whether its CMDB model can express the business functions and third-party dependencies your register needs, not only hardware and software.
GLPI hosting and runtime requirements
GLPI's README lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, while the installation docs list PHP 8.2 or later and MySQL 8.0 or MariaDB 10.6 for GLPI 11.0. Confirm which version your platform team will support, because the two sources differ. Only MySQL and MariaDB are supported as databases, and the web root must point to GLPI's public directory.
GLPI managed by Teclib'
Teclib', which maintains GLPI, offers GLPI Network as a managed service. Subscription pricing is published per user for cloud options and per month for self-hosted tiers, and the self-hosted tiers include level 3 support. Before choosing, ask whether the managed option keeps the register data in your required jurisdiction and whether it supports the audit log access and retention your supervisor may request.
iTop as a customizable CMDB
Combodo iTop is licensed under AGPL-3.0, with 3.3.0 published on September 15, 2026. Its data model can be extended, which suits a register that links business functions, critical ICT assets, providers and services in one model. Expect the design work to sit with your team or partner, and confirm that the data model changes can be versioned and reviewed before they reach production.
Choosing between GLPI and iTop
GLPI fits a register that starts from asset inventory and ticket handling with a standard data model. iTop fits an institution that needs a bespoke model of dependencies and critical service mapping. Both are open source, so the decision rests on the data model, the skills available in-house and the support you will buy. Run both against a sample of critical services before you commit.
Zammad and osTicket as complaint channels
Zammad is licensed under AGPL-3.0 and osTicket under GPL-2.0. Use either only as a customer complaint intake that creates or links records in the ITSM platform, because Article 17 expects complaints to flow into incident escalation. Confirm the license obligations if you modify the code, and make sure the complaint tickets carry the timestamps and identifiers that the incident record needs.
Configuring the ITSM tool for Article 17 classification
This sequence turns a generic GLPI or iTop service desk into a classification and escalation workflow that records, categorizes and root-causes ICT-related incidents in the way Article 17 expects. Each step produces a configuration artifact that compliance and operations can review before go-live.
Define the incident taxonomy and classification criteria
Compliance and the operations lead agree a written taxonomy of ICT-related incident types, such as availability, data integrity, security, third-party outage and change-induced failure. They then set classification criteria for priority, severity and criticality of affected services, linked to the impact thresholds the entity uses under Article 18(1). The team configures these as categories, priority matrix values and required fields in the ticket template. Done means a signed taxonomy document exists and a test ticket of each type lands in the correct category with the correct priority.
Map roles and responsibilities to each incident type
For each incident type, the team names the responsible resolver group, the incident manager, the escalation owner and the person who approves major-incident status. In GLPI or iTop this means groups, assignment rules and approval steps tied to the taxonomy categories. Responsibilities must also cover who decides whether an incident is reported to senior management and the management body. Done means every category maps to a named group and a named escalation owner, and a role matrix is stored with the process documentation.
Link service criticality to SLAs and OLAs
Using the asset and service records, the team tags each business service and its supporting ICT assets with a criticality level. It then configures SLAs for response and restoration targets against those levels, and OLAs for internal resolver groups and third-party providers that support critical or important functions. Targets should be set by the entity's own risk and continuity owners, not copied from a template. Done means each critical service has an SLA and each dependent group has an OLA, and a sample incident on a critical service shows the correct clock and escalation behavior.
Build escalation and notification templates
The team writes notification templates for internal escalation, senior management briefings, client notification, staff and media communication under the entity's communication plan, and information for counterpart financial entities where relevant. Templates are attached to the taxonomy and priority triggers through notification rules, so a major incident generates the right messages to the right recipients. Each template includes fields for impact, response actions and additional controls, which Article 17(3)(e) and (f) ask the entity to report. Done means a test escalation sends each template to a test recipient list and the sent messages are retained in the ticket history.
Enable root cause and problem fields
The team adds mandatory root cause, contributing factor, corrective action and recurrence-prevention fields to incident closure, and links incidents to problem records when a root cause is confirmed. Affected CMDB items are linked to each incident so that dependencies can be traced later. The configuration should prevent closure of a major incident without these fields completed. Done means a closed test incident cannot be closed without a root cause entry, and a problem record created from it keeps the link to the affected assets.
Run a tabletop test of the full workflow
The incident manager runs a scripted tabletop exercise with operations, security, compliance and a senior management representative. The scenario includes a major third-party outage that touches a critical service, so the team exercises classification, escalation, notification, OLA breach handling and closure with root cause. Observers record gaps in the ticket trail and in the timestamps. Done means a written test report lists each defect, the owner and the fix date, and the fixes are retested before the workflow is accepted.
Apply GLPI update rules as a recurring operating step
Before any GLPI upgrade, the administrator backs up the database, the application files and the config directory, including the glpi.key and glpicrypt.key files, because losing these keys can make stored data unreadable. After the application files are replaced, the administrator runs the database update command, then reactivates plugins, since GLPI 11.0 suspends plugins after a new version is detected and they must be reactivated after major updates. The workflow configuration is re-tested after each upgrade to confirm categories, SLAs and notifications still behave as documented. Done means the upgrade runbook is stored, the post-upgrade tabletop checks pass, and the change record links to the ticket evidence.
Evidence DORA supervisors and auditors ask for from the ITSM record
This table maps each evidence item a supervisor or internal auditor is likely to request to the GLPI or iTop component that produces it, and lists what to confirm about retention and export. Read it as a checklist for the design workshop: any row where the producing component or retention period is unclear is a gap to close before go-live. The main takeaway is that DORA evidence is only as strong as the timestamps, relations and audit history the tool keeps.
| Evidence item | Producing component | What to confirm on retention and export |
|---|---|---|
| Asset register export (Article 8(1), 8(4)) | GLPI asset inventory objects (computers, network equipment, software) populated by GLPI Agent or import; iTop CMDB classes | Confirm the export format and fields you can produce on request, that retired assets remain queryable, and how long your retention rule keeps them. |
| Dependency and interconnection map (Article 8(4), 8(5)) | GLPI relations between assets, services and suppliers; iTop CMDB relations such as depends on and impacts | Confirm that relations are maintained by process, not only at initial load, and that you can export the relation graph, not only a flat list. |
| Third-party dependency register (Article 8(5)) | GLPI supplier and contract records linked to services; iTop provider and contract objects linked to business services | Confirm which supplier records link to critical or important functions and that contract end dates are captured so the register stays current. |
| Change-linked inventory updates (Article 8(6)) | GLPI change records linked to affected assets; iTop change tickets with impacted CIs | Confirm that an approved change updates the linked asset or CI record and that the update is traceable to the change ID. |
| Incident log with timestamps (Article 17(1), 17(2)) | GLPI or iTop incident tickets with opened, assigned, resolved and closed dates; ticket history | Confirm the timezone used for timestamps, that history entries cannot be edited silently, and how the log is exported for a regulator request. |
| Classification history (Article 17(3)(c)) | Ticket fields for priority, severity and affected service, with the change history kept in the ticket log | Confirm that reclassifications are logged with the old value, the new value, the user and the reason, and that the criteria used match your Article 18(1) mapping. |
| Major incident reporting to senior management (Article 17(3)(e)) | Ticket linked to a major incident category, plus reports or dashboards and notification records | Confirm where management notifications are recorded, since a ticket alone may not show that senior management was informed. |
| Root cause records (Article 17(2)) | Problem records linked to the originating incidents in GLPI or iTop | Confirm that each major incident has a linked problem record, that closure requires a root cause entry, and that corrective actions are tracked to completion. |
| Audit log of administrative and configuration changes | GLPI and iTop change logs for configuration, user and rights changes; web server and database logs for access | Confirm that the application audit trail and database logs are retained for the period your DORA policy sets and are included in backups. |
Common questions on DORA and ITSM tooling
Does using GLPI or iTop make us DORA compliant?
No. DORA sets no certification scheme, and no tool makes an entity compliant on its own. Competent authorities supervise compliance using their powers under Article 50, and the only authority-issued attestation the Regulation provides for concerns threat-led penetration testing under Article 26(7). An ITSM platform is evidence infrastructure: it can hold the ICT asset register required by Article 8, the incident records and classifications required by Article 17, and the links to third-party providers. Your compliance function still decides how those records map to your obligations and what your auditors and supervisor will accept. Confirm that scope with your legal and compliance leads before design starts.
How much effort does building the ICT asset inventory take?
The effort depends mostly on how many assets and dependencies you already track in other systems and how much of that data is trustworthy. Discovery agents can populate hardware and software records on endpoints and servers, but Article 8(4) also asks for remote sites, critical asset mapping and configuration links, which usually need interviews with business owners and review of contracts and architecture diagrams. The main drivers are the number of business functions in scope, the number of third-party services they depend on, the quality of existing CMDB data, and the number of owners who must confirm entries. Ask any partner for a written breakdown by discovery, data cleansing, dependency mapping and owner sign-off.
Can our own team set up and run GLPI without a partner?
Yes, many teams install and run GLPI in-house, and it is licensed under GPL-3.0, so there is no license fee for the software itself. A capable internal team still needs time for the web server setup, database administration, agent deployment, process design and ongoing updates. The GLPI installation docs require pointing the web server document root to the public directory, and the update procedure requires backing up the database, files and the config directory, including glpi.key and glpicrypt.key, before running the database update. Assess whether your staff have the capacity and skills for those tasks, and whether you want an external partner for design, migration or a fixed-scope rollout.
How long does an ITSM rollout for DORA take?
The timeline depends on the number of assets, the state of your existing records, the number of processes you configure, and how quickly business owners can review their entries. Each phase, from requirements and CMDB design to discovery, migration, incident classification workflows and training, adds its own dependencies. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. Ask for a phase plan with named dependencies on your side, such as access to directories, change windows and owner availability, rather than a single headline duration.
What does GLPI cost to run, and what should a quote include?
The software license is free under GPL-3.0, so cost comes from infrastructure, implementation, administration and optional vendor subscriptions. The GLPI Network subscriptions page lists public cloud at 19 euros per user per month, private cloud at 21 euros per user per month with a 25-user minimum, and self-hosted subscriptions from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise), with level 3 support and marketplace plugins. Those are vendor list figures and may have changed, so confirm them directly. A quote should separate one-time work (design, migration, integrations, training) from recurring items (hosting, backups, subscriptions, updates and support retainers).
What does the operations team need to provide during the project?
Your staff need to provide decisions and access more than hands-on configuration. Typically that means a named process owner for incident classification, a business owner for each ICT-supported function, directory and network access for discovery, a change calendar, and a reviewer for the data migrated from spreadsheets or older tools. Security and compliance staff should review the classification criteria against the Article 18(1) criteria and the Article 17 roles. Ask a partner to list these commitments by role and hours per week so that dependencies are visible in the plan before work starts.
Which DORA evidence should be kept in the ITSM tool?
Keep the records that show how you identified and maintained your ICT environment and how you handled incidents. For Article 8, this means the register of ICT-supported business functions, the assets supporting them, their dependencies, classifications, owners and the dates of the periodic reviews. For Article 17, it means the incident records with timestamps, categories, priority, severity, affected services, escalation steps, notifications and root cause actions. Confirm with your compliance team which fields, retention periods and approval trails your supervisor expects, since the Regulation sets the requirements but the evidence format is set by your own control design.
What an ITSM tool does not satisfy on its own
DORA asks for more than an accurate asset record and a clean incident trail. Risk scenario reviews, the register of third-party arrangements, resilience testing and regulator reporting each need their own process, owner and evidence. The cards below name the gap in each area and who must close it before an ITSM deployment can be called DORA-ready.
Threat scenario and risk reviews
Article 8(2) requires continuous identification of ICT risk sources, assessment of cyber threats and vulnerabilities, and a review of risk scenarios at least yearly. An ITSM tool can hold vulnerability and asset records, but it does not score scenarios or decide which risks the entity accepts. The chief risk officer or ICT risk function must own the risk register and scenario reviews, with the ITSM records used as inputs. Check that each scenario links to the affected assets and services.
Register of third-party arrangements
Article 8(5) requires documented processes that depend on ICT third-party providers and the interconnections with providers supporting critical or important functions. A CMDB can link a supplier to an asset or service, but contract terms, subcontracting chains, exit strategies and audit rights sit in procurement and legal systems. The third-party risk owner, usually procurement with legal, must maintain the contractual layer. Confirm that the CMDB references the register by identifier instead of duplicating contract data.
Resilience testing under Chapter IV
Chapter IV requires digital operational resilience testing, and the Regulation provides for threat-led penetration testing with an authority-issued attestation under Article 26(7). An ITSM ticket can record that a test was scheduled, its findings and the remediation request, but it does not run or validate the test. The security testing function and the testers must own scope, methodology and results. Check that each finding becomes a tracked change with a link back to the test report.
Regulator reporting and submissions
Article 17(3)(e) and (f) require major incidents to be reported to senior management and the management body, and the competent authority also receives notifications. The ITSM tool holds the incident timeline, classification and impact fields, but the submission to the authority and the approval by the management body happen outside it. The incident response lead and compliance must own the notification workflow and the reporting templates. Confirm the ticket fields map to the content each report requires.
Digital Omnibus changes still pending
The Digital Omnibus proposal, COM(2025) 837, is still in the European Parliament's legislative procedure 2025/0360(COD), so its final wording on incident reporting and related duties is not settled. Designing the ITSM data model around today's text alone risks rework. Compliance counsel should track the procedure and decide which fields are configurable. Build reporting fields as configuration so they can change without a platform migration.
Periodic review of classifications
Article 8(1) requires the classification of ICT-supported functions and assets to be reviewed as needed and at least yearly, and Article 8(6) requires inventories to be updated after every major change. An ITSM tool supports these reviews with change records and asset lifecycle data, but the decision to reclassify a critical function is a governance act. The ICT risk owner and business function owners must sign off. Check that the ITSM instance records who approved each classification and when.
How the ITSM build fits DORA readiness work
An engagement starts by fixing the scope in writing, before anyone touches the GLPI or iTop configuration. Most engagements are fixed-scope, so the agreed document should name the ICT-supported business functions in scope, the roles that own them, the asset classes to be recorded, the dependency types to be mapped and the incident taxonomy that will be used. Article 8(1) asks for exactly this identification and documentation, and Article 8(6) asks that the inventories be kept current after every major change. The practical decision is which CMDB classes and relationships will carry the Article 8(4) mapping of critical assets, configuration, links and interdependencies, including assets on remote sites. Confirm early whether the entity wants third-party dependencies modeled as their own class, because Article 8(5) requires the processes that depend on ICT third-party providers to be documented.
On the incident side, the same work defines the record that Article 17 needs. The taxonomy should map incident categories to priority, severity and the criticality of affected services under the Article 18(1) criteria, and the ticket workflow should assign roles for each incident type, including who notifies senior management for major incidents and who owns communication under Article 14. Teams should also agree which fields carry the timestamps and root cause references that Article 17(2) expects. Evidence exports, such as asset register extracts, relationship reports and incident logs with their change history, are defined at this stage so they can be tested against a sample scenario before go-live.
DeployOpen prepares the systems, controls and evidence described above for the entity's own assessment by its competent authority, but it does not issue audit reports, attestations or certifications. Readiness of the ITSM configuration is one input among many, alongside the entity's ICT risk framework and its third-party register. Before the engagement, confirm with your compliance function which records the supervisor will request, in what format and within what timeframe, and whether the entity's own internal audit will sample the tickets. Ask the implementation partner to show how each export maps to an Article reference and who inside the entity signs off on the classification rules.
How DeployOpen scopes, deploys and supports a DORA-ready ITSM
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a DORA-ready ITSM on GLPI or iTop, that means the asset, dependency and incident records are built to match your own Article 8 and Article 17 evidence needs, deployed in your environment and handed over with the documentation your teams will use.
How we scope
- Agree in writing which ICT-supported business functions, asset classes and third-party dependencies the register must cover.
- Confirm the incident categories, priority and severity fields, and the roles that classify incidents against your service criticality.
- Define the review cadence for the asset register and the process for updating it after major changes.
How we build
- Configure the CMDB model, asset types and relationships so critical services link to the hardware, software and providers they depend on.
- Set up incident workflows with timestamps, escalation paths and fields that record root cause and follow-up actions.
- Connect inventory discovery and identity sources, then test that records reconcile with monitoring and procurement data.
How we hand over
- Document configuration, data model, workflows and integration points so your team can maintain them without us.
- Provide test records and a walkthrough showing how an incident moves from detection to recorded root cause.
- Deliver backup, update and access procedures, including how the platform's encryption and configuration keys are protected.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope engagement ends.
- Review the register and workflows against regulator requests, major changes and updates to your DORA obligations.
- Confirm with your legal and compliance teams how the outputs map to the supervisory evidence your authority expects.
