How open source ITSM supports NIS2 incident handling
If your organization is an essential or important entity under NIS2, you must report significant incidents on fixed clocks. Article 23(4) of Directive (EU) 2022/2555 requires an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report within one month of the notification. A self-hosted ITSM tool does not make the report for you, but it can hold the timestamps, affected asset links and supplier records that show when you became aware, what was affected and what you did. NIS2 also creates no certificate of compliance. Competent authorities check compliance through inspections, security audits, information requests and fines, so the evidence trail is what you will be asked to produce. This section covers two self-hosted fits, GLPI and iTop. The obligations start with classification. Article 3 sorts in-scope entities into essential or important, and the classification affects how you are supervised: essential entities face ex ante supervision, while important entities face ex post supervision (Articles 32 and 33). Both categories carry the same risk-management duties under Article 21 and the reporting duties under Article 23. Confirm your status with your national transposition law, because Member States implement NIS2 through national rules. Also check whether the Commission's January 2026 proposal (COM(2026) 13), which is still a proposal, changes your category or thresholds before you fix your design.
Decide early which ITSM records will carry the clock. Incident tickets should capture the moment of awareness, the classification as a significant incident, the assets and services affected, and each submission to the national CSIRT or competent authority. In GLPI, that means configuring incident categories, SLAs and linked assets, and in iTop, a customized incident class with links to the CMDB. Supplier records need the same discipline, because NIS2 supply-chain duties reach your third parties. Confirm with your partner which fields are mandatory, who can edit timestamps, and whether audit logging captures changes to closed tickets. Also confirm the limits of your chosen version, since GLPI 12.0.0 and iTop 3.3.x have different requirements and plugin behavior, and test the design against a tabletop exercise before a real incident.
Which NIS2 reporting requirements the ITSM must meet
This table maps the NIS2 timelines, risk-management measures and Implementing Regulation 2024/2690 incident criteria to specific ITSM functions in GLPI or iTop. Read each row as a question the tool must answer during an incident, and the cell as the configuration that makes the answer available. Confirm significance criteria with your national authority and counsel before fixing any flag values.
| Requirement | What the ITSM must support | Evidence an assessor or authority will expect |
|---|---|---|
| Early warning within 24 hours (Article 23(4)) | A significant-incident ticket type that can be opened fast, with a mandatory field for the time the entity became aware of the incident | Ticket creation timestamp, awareness timestamp and the early warning sent, linked to the ticket record |
| Incident notification within 72 hours (Article 23(4)) | A notification task or follow-up linked to the incident, with an SLA-style timer counting from awareness | Timer start and stop times, notification content version and the recipient authority recorded on the ticket |
| Final report within one month of notification (Article 23(4)) | A report stage with a mandatory root cause, impact and remediation fields, and an escalation rule before the due date | Dated report revisions, approval history and closure reason tied to the same incident number |
| Significant incident criteria (Regulation 2024/2690) | Category and significance flags on incident tickets, with rules that promote a ticket to the reporting workflow | Documented criteria version, the flag applied and the person who set it, kept in the ticket history |
| Risk management measures (Article 21) | Incident categories linked to affected assets, services and controls, so each incident maps to a measure | Asset and service links on each incident, and a register showing which measures each incident tested |
| Asset and supplier linkage | CMDB relations from affected assets and services to supplier contracts and support providers, with mandatory supplier field on relevant tickets | Current asset list, supplier register and proof that third-party incidents were linked to the supplier record |
| Approval workflow and escalation | Approval steps for notifications and reports, with escalation rules to named roles when a timer nears its deadline | Approval timestamps, named approvers and escalation logs showing who was alerted and when |
GLPI or iTop for NIS2 incident records
Both GLPI and iTop can hold the incident, asset and supplier records that NIS2 reporting depends on, but they differ in how they model the CMDB, how inventory reaches the database and how much administration they demand. The cards below compare the two tools and name the situations where a helpdesk front door is also needed.
GLPI as the inventory-led core
GLPI (GPL-3.0) combines ticketing, assets, contracts and CMDB-style records in one application, and its GLPI Agent collects hardware and software inventory and sends it to GLPI. For NIS2 this means affected-asset lookups can start from the same record the incident uses. Check whether your asset classes and relations match the systems you must list as essential or important services, and confirm that the agent covers every operating system in scope. The current release is GLPI 12.0.0, published October 7, 2026.
iTop as the CMDB-first model
iTop (AGPL-3.0) is built around a customizable CMDB with graphical impact analysis, so an analyst can see which services and suppliers sit behind a compromised server before deciding on early warning content. Its data consistency audits help catch orphaned assets and broken links that would weaken a regulator-facing report. Version 3.3.0 was published September 15, 2026. Confirm that your data model is designed before go-live, because changing relations later is costly.
Change and incident timestamps
NIS2 Article 23(4) sets a 24-hour early warning, a 72-hour notification and a final report within one month of notification. Both tools record incident creation, assignment and status changes, but the evidence is only as good as the clock and the audit trail behind it. Ask each candidate how it logs status transitions, who can edit timestamps and whether history is retained when a ticket is reopened. Map each NIS2 deadline to a field you can export.
Access control for incident records
Incident records contain sensitive detail about vulnerabilities and affected systems, so administrative rights need tight control. GLPI 12.0.0 adds step-up authentication for certain administrative actions and a view of active sessions that can be revoked. iTop relies on profiles and role separation that you configure yourself. Decide who can close or back-date incidents, and test that the restriction holds in the tool rather than only in the procedure document.
Supplier and SLA tracking
Essential and important entities must consider supplier security, so supplier records should link to the services they support and to the incidents that involve them. GLPI offers group-managed OLAs and contract records, while iTop provides customizable SLA management and service and contract modeling. Confirm which tool can show, for a single supplier, every open incident, contract and dependent service in one report.
Fit by team size and front door
Combodo suggests an all-in-one iTop server with 2 vCPU and 4 GB of memory for fewer than 200 tickets a month and under 20 console users, with separate servers for larger installations. GLPI self-hosting needs PHP 8.3 or later and MariaDB 10.11 or later, and its web root must point to the public directory. Choose iTop for a small team that wants a modeled CMDB, and GLPI when inventory from agents is the primary need. Add Zammad or osTicket only if external reporters, such as customers or suppliers, need a separate intake channel into the ticket system.
How tickets, CMDB links and timestamps become the evidence trail
The evidence trail starts with one incident record that links every affected configuration item, supplier and contract to the same ticket. In GLPI or iTop, the incident should reference the CMDB items it touches (servers, network devices, cloud tenants, business services) and the supplier or contract that provides or hosts them, so an authority asking which third-party ICT services were involved can be answered from one record instead of five spreadsheets. Confirm with your administrator how relations are modeled in your chosen tool, since GLPI assets and iTop's customizable CMDB classes handle these links differently, and test that a sample incident displays its linked items and supplier in a single view. The NIS2 clocks run from one timestamp: when the entity became aware of the significant incident. Record that awareness time explicitly in its own field, separate from the ticket creation time, because the two often differ when a monitoring alert or a phone call precedes the ticket. From the awareness timestamp, the 24-hour early warning, the 72-hour incident notification and the one-month final report under Article 23(4) of Directive (EU) 2022/2555 are each calculated, so the record should show the deadline for each stage and who owns it. Decide in advance whether the awareness time is entered by the first responder or confirmed by the incident lead, and document that rule in your procedure.
Timestamps only carry evidential weight if they cannot be quietly changed. Use the tool's history or audit log so that creation, acknowledgement, notification and closure events are recorded automatically with the acting user, and restrict edit rights on closed incidents and on the awareness and notification fields to a small incident-manager role. Check that the audit log cannot be disabled or purged by the same administrators who work the tickets, and export or back up the log on a schedule you set. Confirm the exact behavior of your version (GLPI or iTop) with a test: close an incident, attempt an edit, and verify the history shows who changed what and when. The tool supports the evidence trail but does not make a report legally sufficient. Whether a notification meets the requirements of your national competent authority depends on its content, your transposition law and the authority's own channels, which your legal and compliance teams should confirm. Plan for an incident to be reconstructed from exported records, so agree with counsel which fields, attachments and approvals must be retained together and how long, and test one tabletop incident end to end before a real one.
How the 24-hour, 72-hour and one-month clocks run in the ITSM
This sequence turns a suspected incident into a traceable chain of tickets, timestamps and approvals, so the reporting clocks under NIS2 Article 23 can be shown to have been met. It also gives the team a single record to draw from for each report.
Log the detection and triage ticket
The first person who notices a possible security event opens an incident ticket in GLPI or iTop immediately, without waiting for confirmation. The record captures the detection time, the reporter, the detection source (monitoring alert, user report, supplier notice), the affected assets and the first containment action. The service desk lead confirms receipt and assigns an incident owner. The ticket is complete when the detection timestamp is locked, linked to at least one CI or asset record, and the owner has accepted it. Ask your implementation partner how the ticket template enforces these mandatory fields.
Record the significance assessment
The incident owner, with the security lead, decides whether the event may be a significant incident under the criteria in your national transposition law and in Implementing Regulation (EU) 2024/2690 where it applies to your sector. The assessment is recorded as a dated task or child ticket with the criteria considered, the services affected, the number of users or customers impacted and the decision reached. The approver is the designated incident response authority named in your policy. Keep the reasoning in the record even when the answer is no, because the decision itself is evidence.
Prepare and submit the early warning
If the assessment indicates a significant incident, the incident owner prepares the early warning required within 24 hours of becoming aware of it, under NIS2 Article 23(4). The ITSM record holds the awareness timestamp, the submission time, the channel used and a copy of the content sent. The approver is the accountable executive or CISO. The task closes when the submission reference from the national authority is attached to the ticket. Confirm the form, fields and submission channel with your national competent authority, since these vary by Member State.
Submit the incident notification
Within 72 hours of becoming aware of the incident, the owner submits the incident notification under Article 23(4), updating the initial assessment with what is known about severity, impact, indicators of compromise and mitigation. The ticket links to the affected CIs, the relevant supplier records and any change records raised during containment. The approver signs off the content before submission. The step is complete when the notification reference and timestamp are stored and the record shows which information was confirmed and which remained open.
Maintain interim updates and task logs
While the incident is open, the owner records each status change, containment action, supplier contact and authority request as a timestamped follow-up in the ticket. Changes to affected assets go through linked change records so the CMDB reflects the current state. Any update the authority requests is logged with the request date and the response. Completion is measured by a continuous, unbroken activity trail from detection to closure, with no gaps between entries that cannot be explained.
Submit the final report within one month
Within one month of the incident notification, the owner submits the final report. It describes the root cause, the severity and impact, the mitigation applied, and where relevant the cross-border impact. The ticket links every supporting artifact: the root cause analysis, change records, asset and supplier references and the full timeline. The approver is the accountable executive. The step closes when the report reference is attached and the ticket can be exported as a single, consistent evidence bundle.
Hold the post-incident review
After closure, the incident owner and service management lead run a post-incident review and record its outcome as a problem record. Findings are linked to the risk register, to any affected asset or supplier record that needs updating and to corrective actions with owners and due dates. The review is complete when every action is tracked to closure and the CMDB and supplier records reflect what was learned. Ask your partner how these reviews feed the Article 21 risk management measures you must maintain.
What auditors and supervisors ask for and what tooling cannot cover
What evidence do supervisors ask for after a significant incident?
Supervisors look for a dated, unaltered record showing when you became aware of an incident, what you did, and when you reported it. In a GLPI or iTop setup, the ticket history and its timestamps carry most of that weight, because every status change, assignment and comment is logged against the record. Keep the ticket as the single incident record and link every related communication to it. Confirm with your national competent authority and your legal counsel which fields they expect in an early warning and an incident notification, because the NIS2 timelines of 24 hours, 72 hours and one month are fixed, but the content of each report is set by national transposition and the Commission's Implementing Regulation (EU) 2024/2690.
How do asset and supplier registers support an incident report?
They show which systems, services and third parties were affected, which is the first thing a reviewer checks. The component that produces this is the CMDB: configuration items for servers, applications and network devices, linked to the incidents that touched them, and supplier records linked to the contracts and service owners behind them. Use GLPI's asset and contract modules or iTop's CMDB classes and relations, then run a consistency audit before an incident so the links are current. Assets discovered by the GLPI Agent need manual review when they cannot be matched to an owner, since an unowned asset is itself a gap an auditor will question.
Which approval records must the ITSM tool keep for changes made during an incident?
Auditors expect to see who authorized a change, when, and whether the change was emergency or planned. The ITSM tool produces this through change records with approval steps, timestamps and linked incidents, so a fix made during recovery can be traced back to the incident that required it. Define in writing which emergency changes may skip standard approval and require retrospective review. Confirm the exact retention period and format with your legal team, since these depend on your national law and sector rules rather than on NIS2 alone.
How should supplier incident notices be recorded in the ticket trail?
Record each notice from a provider as a ticket or a linked item, with the date and time it was received, the sender, the affected service and the actions taken. Where a supplier is in a managed or cloud role, the notice can be the trigger that starts your own awareness clock, so the receipt time matters. Attach the original message or file rather than retyping it, and link the supplier record so reviewers can see the contract and contact owner. Confirm with your suppliers which channels they use for incident notices and whether they publish a contact point that your team monitors.
Which lessons-learned records should the service desk keep after an incident?
Keep a post-incident review linked to the original ticket, covering root cause, affected assets, corrective actions, owners and due dates, and the status of each action. Problem records in GLPI or iTop are a natural place to track recurring causes, and linking them to the incident and the CMDB items shows that changes were made where the weakness sits. Reviewers look for evidence that actions were closed, so store closure dates and verification notes, not only a summary document.
Does the ITSM tool decide whether an incident is significant?
No. The tool records and routes what your people classify, but it does not decide whether an incident is significant under NIS2. Significance depends on the criteria in Implementing Regulation (EU) 2024/2690 for the relevant entity types and on your own impact assessment, which must be made by accountable staff. Build a classification field and a documented decision step into the workflow so the decision, its author and its time are recorded, and confirm the criteria that apply to your sector with your national authority.
Can the ITSM tool submit early warnings and reports to authorities?
No. GLPI and iTop do not submit reports to national competent authorities or CSIRTs, and they do not replace the reporting channel your country requires. They can hold the draft content, track the 24-hour, 72-hour and one-month deadlines through due dates and SLA rules, and keep a copy of what was sent. Submission itself must go through the channel your authority specifies, and the person sending it should be named in your procedure.
Does an ITSM tool satisfy the Article 21 risk-management obligations?
No. Article 21 requires a risk-management program covering policies, supply chain security, business continuity, vulnerability handling and other measures, and an ITSM tool supports only some of these with inventory, tickets and records. Risk analysis, policy approval, testing of continuity plans and the management of supplier security remain organizational work. DeployOpen can help plan, implement and document the ITSM part of that program, and prepare the evidence it produces, but it does not issue compliance certificates. Independent auditors and national authorities make the assessment.
Evidence auditors ask for and which ITSM component produces it
This table maps the records a NIS2 assessor or national authority is likely to request after an incident to the GLPI or iTop component that produces them. Read each row as a question: what must be retained, which component holds it, and what your own environment must confirm before you rely on it. The main takeaway is that timestamps and links set up at ticket creation, not reconstructed later, carry most of the evidentiary weight.
| Evidence item | What the reader must retain | Producing component | What to confirm in their environment |
|---|---|---|---|
| Incident timeline with awareness timestamp | The time the entity became aware, each 24-hour early warning, 72-hour notification and one-month final report, with who made each entry | GLPI or iTop ticket history and creation, status and assignment timestamps | Whether the awareness time is captured in a dedicated field, and whether ticket history is write-protected from edits by agents |
| CMDB impact linkage | Which configuration items, services and sites the incident affected, and which were out of scope | iTop impact analysis and relations on tickets, or GLPI assets linked to tickets | That affected services are modeled in the CMDB and the links are mandatory for significant incident tickets |
| Asset inventory from GLPI Agent or iTop imports | Asset state at the time of the incident, including owner, location, OS and installed software | GLPI Agent inventory records or iTop CSV import and synchronization history | How often inventory runs, and whether agents cover all in-scope systems, including cloud and OT hosts |
| Supplier and contract records | Third-party providers involved, contract terms, support contacts and their dependency on affected services | GLPI contract and supplier records, or iTop service and contract objects | Whether supplier records are kept current and linked to the services they support |
| SLA or OLA timer history | Response and resolution clocks, pauses and breaches, which show how quickly the entity acted | GLPI SLA and OLA timers, or iTop customizable SLA management | That timer rules match the internal escalation targets for incident reporting, and that pause reasons are recorded |
| Change records for remediation | Changes made to contain or fix the incident, with approvals, testing notes and back-out plans | GLPI change records or iTop change management linked to the incident ticket | Whether emergency changes raised during an incident are logged and reviewed after the fact |
| Access control evidence | Who could view and act on incident records, including administrator actions and session activity | GLPI session review and step-up authentication for administrative actions, plus LDAP or IMAP-based authentication logs | Which authentication sources are enabled, the order they are tried, and where authentication and audit logs are retained |
What the ITSM tool alone does not satisfy
GLPI or iTop can hold the tickets, assets and timestamps that a NIS2 report depends on, but it does not make the reporting decisions or cover the wider security measures. The cards below set out what sits outside the tool, who owns it, and what to confirm before the first early warning clock starts.
Significance decisions and legal judgment
The ticket records when an incident was detected, but it does not decide whether the incident is significant under the national law that applies to you. That judgment belongs to a named person who can explain the criteria used, usually with counsel. Check that your runbook records who makes the call, the time it was made, and the facts relied on. The 24-hour early warning clock under Article 23(4) runs from awareness, so the decision point must be fixed in advance.
National authority submission channels
Each Member State designates its own authority, portal and reporting format under its transposition law. A ticket cannot be filed with a regulator directly, so the ITSM record only feeds a submission that is made through a channel you confirm in advance. Ask counsel or your national competent authority which channel, template and contact points apply to your sector, and rehearse one submission with the ticket fields you will copy from.
Article 21 measures beyond service management
Article 21 requires risk management measures that go well beyond the service desk, including business continuity, supply chain security, access control, cryptography and vulnerability handling. An ITSM tool records that these activities happened but does not perform them. Map each measure to the system that actually operates it, such as identity, backup, patching or monitoring, and link the evidence back to the relevant asset or change record.
Supplier due diligence and contract clauses
Supplier records in the CMDB show who provides a service, but they do not show whether the supplier can meet your incident notification timelines. Contracts need clauses that require the supplier to notify you early enough to meet the 24-hour and 72-hour deadlines, to share logs, and to cooperate on the final report. Ask each critical supplier for its own incident process and confirm that its contacts are stored against the affected services.
Backup and update discipline
GLPI stores data in its database and also depends on the glpi.key and glpicrypt.key files in the config directory. Without them, encrypted fields and the tool itself may not be restorable, which would break the evidence trail during an incident. Test restores of the database, files and config directory, and confirm that updates are preceded by a backup as the GLPI update documentation describes. The same discipline applies to iTop and its database.
Pending changes to NIS2 under COM(2026) 13
The Commission proposed targeted amendments to NIS2 on 20 January 2026, including a new small mid-cap category. The proposal still needs approval by the European Parliament and the Council, so reporting thresholds, scope and procedures may change. Record which version of the rules your runbook was built against, assign an owner to track the proposal, and schedule a review of the timelines and templates once the text is final.
NIS2 incident handling on open source ITSM: common questions
What does a self-hosted GLPI or iTop deployment cost?
The software licence is free, so the cost is the work around it. GLPI is distributed under GPL-3.0 and iTop under AGPL-3.0, so you pay for the parts that take effort: hosting, process and CMDB configuration, agent rollout, data migration, administration and optional support. Some costs are one-time, such as configuration, integration and migration. Others recur, such as hosting, patching, upgrades, support subscriptions and administrator time. The main cost drivers are the number of agents and assets to inventory, how many approval and SLA workflows you model, how many systems you integrate with monitoring and identity, and how much history you migrate. Ask any implementation partner for a quote built from a written scope that lists each of these items separately.
How long does a NIS2 incident handling ITSM setup take?
The duration depends on scope, and no supplied figure gives a generic timeline, so treat any number you hear as unverified until it is tied to a written scope. The scope drivers are the incident categories and classification rules you need, the number of entities or sites sharing the tool, the asset and supplier data you must reconcile, the integrations with monitoring, identity and mail, and whether you need to migrate existing tickets. A single-entity deployment with a defined category model and a small set of integrations will take far less time than a multi-entity CMDB with discovery across several networks. Ask the partner to break the timeline into phases with named deliverables and to state what the client must provide in each phase.
What must our team supply before an ITSM implementation starts?
Three inputs decide whether the incident trail works from day one. First, your incident categories and significance criteria, written so that a ticket can be classified as a potential significant incident and time-stamped at the moment of awareness. Second, named asset owners for each system, service and site, so that every CMDB record links to an accountable person. Third, a supplier list with the services each supplier provides, contract contacts and the systems they touch, which supports supplier records and third-party incident notifications. Your team should also provide the escalation contacts for the early warning, notification and final report steps, along with the national competent authority contact details that your legal team confirms. Missing any of these usually surfaces as rework during configuration.
Can our own IT team deploy GLPI or iTop without a partner?
Often yes for a small, well-understood scope, but the decision depends on skills and capacity rather than the software. GLPI requires PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later according to its README, and the installation docs require the web server's document root to point to the public directory with URL rewriting. iTop 3.3.x requires PHP 8.2 to 8.4, MariaDB 10.6 to 11.8 or MySQL 5.7 or later, and GraphViz. Your team also needs to design the CMDB model, configure SLAs and approvals, write migration scripts and keep backups and upgrades on schedule. Confirm internally who owns each task, how many hours per month administration will take, and who covers the system during an incident, because an ITSM tool that is down during a live incident defeats its purpose.
How do GLPI Network and iTop Community support tiers compare on cost?
They differ in what you pay for, so compare the cost drivers rather than headline prices. According to the GLPI Network subscriptions page, GLPI Network public cloud costs 19 euros per user per month, private cloud 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), with level 3 support. Combodo offers iTop Community free for up to 10 agents, iTop Atelier for up to 50 agents and iTop Forge for more than 50 agents, each available on premises or as SaaS. Compare the agent and asset limits, support levels, hosting responsibility, and whether a plugin or extension you need is included. Remember that a free tier still carries your configuration, hosting and administration costs.
Does the proposed NIS2 amendment change the 24-hour and 72-hour clocks?
Not on the supplied facts. The current NIS2 text in Article 23(4) requires an early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours and a final report within one month of the notification. On 20 January 2026 the Commission proposed targeted amendments (COM(2026) 13) that include a new small mid-cap category, but the proposal still needs approval by the European Parliament and the Council, and Commission pages updated through July 2026 describe it as a proposal. Plan around the current clocks, and configure your ITSM timestamps so that awareness, classification and each submission are recorded separately. That way a change to the timing rules only requires a configuration update. Have your legal or compliance team confirm the status of the proposal and your national transposition law before you rely on it.
Which ITSM timestamps and records do NIS2 incident reports depend on?
The report is only as strong as the timestamps behind it. Record the moment an incident is first detected or reported as the awareness point, then record classification as significant or not, the early warning send time, the notification send time, the final report date and every status change in between. In GLPI or iTop, keep these as ticket fields or history entries rather than free text, link each ticket to the affected assets and services in the CMDB, and link to the supplier record where a third party is involved. Set SLAs and escalations on the ticket so that the 24-hour and 72-hour deadlines are visible to the on-call team. Verify with your partner that the audit history cannot be edited silently and that backups preserve it.
How DeployOpen scopes and delivers NIS2 incident handling in your ITSM
DeployOpen is a Chainscore Labs company that plans, implements, configures, integrates, hardens, backs up and documents self-hosted GLPI or iTop inside your own infrastructure. For NIS2 incident handling, that means the work covers the ticket workflows that carry early warnings and notifications, the CMDB classes that link affected assets and suppliers to those tickets, the timestamp and audit settings that make the sequence provable, and the backup and update routine for the platform that holds the record. The hosting can be your cloud account, a data center or an air-gapped network. DeployOpen does not issue audit reports, attestations or certifications. Your competent authority, independent auditors and certification bodies make those judgments, so DeployOpen's role is to prepare the systems, controls and evidence they will examine.
Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. For this topic, a useful scope statement names the GLPI or iTop version, the incident categories and significance criteria you will apply, the roles that can open, classify and approve notifications, the integrations with monitoring and identity, the asset and supplier data to be loaded, and the test incidents used to prove the 24-hour, 72-hour and one-month steps can be reconstructed. Ask the partner to list which of these items are excluded, and who at your organization owns each decision. DeployOpen does not publish a price list, so the quote should follow directly from that written scope. Ask for it to separate one-time build work (configuration, migration, testing, documentation) from recurring items (support, upgrades, continuous testing), and to state what changes the price if your scope grows.
