What DORA Article 17 requires for ICT incident management
Article 17 requires a financial entity to run a defined ICT-related incident management process that detects, manages and notifies ICT incidents, and to record every ICT-related incident and every significant cyber threat, not only the ones that reach a reporting threshold. If you are a compliance lead or CIO, the practical test is whether you can show, on request, one written process, the register it feeds, and evidence that people followed it. The process has to cover early warning indicators, procedures to classify incidents by priority, severity and the criticality of affected services, and named roles for different incident types. It also has to route serious incidents to senior management and the management body, and it has to make sure root causes are identified, documented and fixed so the same failure does not come back. The risk Article 17 targets is slow detection and inconsistent handling: one team treats a service outage as a ticket, another treats the same outage as a security event, and nobody can say when the clock started.
The requirement is hard to meet for three recurring reasons. First, tooling is scattered: alerts sit in a SIEM, tickets in a service desk, forensic notes in documents and customer messages in email, so no one can reconstruct a timeline. Second, ownership is unclear: when an incident spans IT operations, security and a third-party provider, the reader cannot tell who classifies it and who signs off the decision to escalate. Third, minor incidents go unrecorded because they never trigger a report, which leaves a gap in the record that supervisors will test for. Illustrative example: a payment platform logs a ten-minute degradation in a support channel but not in the incident system, and months later the pattern of repeated degradations is invisible to management. Before you commit to tooling or outside help, confirm with your own compliance function which incidents must be recorded, who owns each classification decision, and where the single record of truth will live.
Self-hosted open-source platforms can carry parts of this evidence trail inside your own infrastructure. An incident case management tool such as DFIR-IRIS can hold one record per case with linked assets, indicators, tasks and evidence, plus an audit trail and a timeline, which helps with root cause documentation. Detection sources such as Wazuh and OpenSearch Security Analytics can generate alerts that feed triage, but the classification criteria, roles and escalation rules remain decisions your organization must document and approve. Tools produce records; they do not make an entity compliant. DeployOpen can plan, deploy and document these components in your environment, and an independent auditor or competent authority assesses whether the process works. The primary sources to read first are the text of Article 17 in EUR-Lex and the classification criteria in Delegated Regulation (EU) 2024/1774.
Which systems, teams and providers Article 17 covers
Article 17 applies to every ICT-related incident and significant cyber threat the entity handles, so the first work is deciding the boundary of what is in scope. The decisions below determine which systems feed detection, which functions hold incident roles, which providers must send information, and how group services are brought in.
ICT systems that feed detection
Decide which systems produce logs or alerts the incident process will rely on: core banking or payment platforms, identity providers, endpoints, network devices, cloud control planes and SaaS admin consoles. Each source you leave out is a blind spot that the early warning indicators and the incident register cannot see. Every included source adds parsing, retention, time synchronization and triage effort. Ask the team to list each source against the critical or important functions it supports, and confirm which ones can be recorded in a single incident register.
Business functions with incident roles
Article 17 requires roles and responsibilities for different incident types and scenarios, so the entity must name owners beyond the IT team. Typical holders include operations, customer service, legal, compliance, communications and the business line that owns the affected service. Each function you add needs a named deputy, training and access to the case tool. The workload grows with the number of scenarios, so map roles to the incident types your classification procedure will actually use.
ICT third parties that must notify you
Contracts with ICT service providers should oblige them to report incidents that affect your services fast enough for your own deadlines to be met. Identify which providers host or process in-scope data, run in-scope systems, or support critical functions, then check whether each contract names notification channels, timing and information content. Providers without these terms will need amendments, which adds negotiation time and legal review. Confirm how each provider's own monitoring feeds your register.
Self-hosted open-source components in scope
Self-hosted platforms such as a log analytics stack, a case management tool or a file sharing server are ICT systems that you operate, so they fall inside your own incident process. Their logs and audit trails must reach your detection pipeline, and their administrators must follow the same escalation rules as any other team. Scoping them early avoids gaps where a tool runs outside monitoring because no one owns it. Confirm which component owner signs off on logging coverage.
Intra-group and shared services
Where a group company runs identity, hosting or security monitoring for the regulated entity, the incident process must still cover how that service's incidents reach your management body. Agree in writing who detects, classifies and notifies, and who holds the evidence. The arrangement should be documented as an intra-group service, with its own service levels and exit conditions. Expect extra work to reconcile two incident taxonomies and two escalation chains.
Management body escalation scope
Article 17 requires that at least major incidents go to senior management and the management body with their impact, response and additional controls. Decide which thresholds trigger that escalation and which reports the board receives between incidents. Larger scopes produce more escalations and more board time, so keep the list of covered services tied to the criticality assessment. Confirm the reporting pack format and who prepares it before the first real incident.
How to build the incident management process step by step
This sequence turns the Article 17 requirement into a working process: a approved policy, a complete picture of where incidents come from, classification rules, a case record that keeps evidence, tested communication paths, and lessons fed back into controls.
Approve the incident management policy and roles
Start by drafting the ICT-related incident management policy and assigning roles for different incident types and scenarios, including who declares an incident, who leads the response, who speaks for the organization and who has authority to escalate. The management body or its delegate should approve the policy, and the approval record should name each role holder and their deputy. The step is complete when the signed policy and a role matrix are stored where responders can reach them outside the normal network, because an incident may disable the systems that normally hold them. Confirm the policy elements against Delegated Regulation (EU) 2024/1774 with your competent authority's expectations.
Map detection sources and log coverage
List every source that can reveal an ICT-related incident or significant cyber threat: SIEM and log platforms, endpoint and network tools, cloud audit trails, application logs, identity providers, vendor notifications and staff reports. For each source, record the owner, the log types it produces, retention, and whether it reaches the central platform. Gaps found here become the first items on the remediation backlog. The output is a source inventory that shows what is monitored, what is partly monitored and what is blind. Review it after every significant system change.
Define early warning indicators and classification criteria
Set the early warning indicators the team will watch for, such as unusual authentication failures, unexpected changes to privileged accounts, or service degradation reported by a third party. Then write the classification procedure that sorts incidents by priority, severity and the criticality of the services affected, using the criteria set under Article 18(1) and the detailed rules in Delegated Regulation (EU) 2024/1772. Map each indicator and category to a response owner. The output is a classification matrix with worked examples that analysts can apply without asking for interpretation at 2 a.m. Have a second reviewer test the matrix against past incidents.
Set up the case record and evidence logging
Configure the case management tool so that each incident becomes one record holding affected assets, indicators of compromise, tasks, decisions and evidence, with timestamps and an audit trail of who changed what. Define how evidence is collected, hashed and handed over, so the chain of custody can be shown later. Connect detection platforms to the case tool so alerts open or update cases automatically. The output is a tested case template, a logging standard and a short evidence procedure. Test it with a sample case and confirm that the timeline can be exported in a form that reporting teams can use.
Write communication and escalation procedures
Draft the communication plan for staff, external stakeholders and the media, the criteria for notifying affected clients, the internal escalation path (including ICT-related customer complaints), and the information to give financial entities that act as counterparts. Pair each path with a named contact, a backup and a pre-approved message template reviewed by legal and communications. The step is complete when the escalation contacts have been verified and the templates have been approved by the people who would send them. Note that reporting to the competent authority under Article 19 runs on its own process and should be linked here, not merged into it.
Run a tabletop exercise and record the results
Run a tabletop exercise based on a realistic but illustrative scenario that goes through detection, classification, escalation, communication and recovery. Include senior management and the people who would sign reports, not only the security team. Record each decision, delay, missing contact and unclear criterion in a test record with an owner and due date for every finding. The output is the signed test record and an updated procedure set. Repeat the exercise when the policy, critical services or key contacts change.
Close the loop with post-incident review and root cause follow-up
After each significant incident, hold a post-incident review that establishes the root cause, documents it and sets corrective actions to prevent recurrence, as Article 17 requires. Report the results to senior management and the management body, covering impact, response and any additional controls. Track each action to closure and feed recurring patterns back into the indicators, classification matrix and detection coverage. The step is complete when the review record, the action tracker and the management report exist for every in-scope incident, and an independent reviewer has checked a sample.
How an assessor tests the Article 17 process
This table compares five assessor test approaches for the Article 17 incident management process, the evidence each one asks for, and the gaps that tend to surface. Read it as a preparation checklist: for each row, confirm that your records would answer the assessor's question without reconstruction after the fact.
| Test approach | Evidence requested | Common findings |
|---|---|---|
| Policy and procedure walkthrough | Approved ICT incident management policy, detection and classification procedures, named roles for each incident type, and the version history showing review dates | Policy describes a process that staff cannot describe in the same way, roles are assigned to positions that no longer exist, or the document was never approved by the management body |
| Sampling of recorded incidents, including minor ones | Incident register extract covering a defined period, with timestamps, classification, severity and closure status for each entry | Minor incidents are missing or recorded only when they escalate, so the register looks complete for major events but not for the full population Article 17 requires |
| Tracing a sample incident from detection to senior management report | Detection alert or ticket, triage notes, classification decision, escalation record, communication log and the report that reached senior management | Gaps in timestamps between detection and escalation, classification changed without a recorded rationale, or the senior management report arrives after the process says it should |
| Review of root cause analysis and recurrence follow-up | Post-incident review documents, root cause findings, corrective action tickets with owners and due dates, and records of recurring incidents linked to those actions | Root causes stated as human error without underlying analysis, corrective actions without owners, or repeated incidents of the same type with no link to earlier reviews |
| Review of communication and escalation records | Internal escalation records, staff and external communication templates, client notifications and records of information provided to counterparts, including ICT-related customer complaints | Communication plan exists but was not followed in the sampled incident, complaints handled outside the incident process, or no record showing who approved external messages |
Evidence that passes an Article 17 review
An assessor reviewing Article 17 looks for a process that runs in practice, not a document set that was written once. The artifacts below connect to one another: the policy sets the rules, the register records what happened, and the closure records show whether the organization learned from it. Each one needs a named owner and a review cadence set by the organization itself.
Approved incident management policy
This is the written ICT-related incident management policy approved by the management body, covering the elements Delegated Regulation (EU) 2024/1774 specifies for it. Keep it current by assigning an owner, usually the head of ICT risk or the security lead, who updates it when detection tooling, roles or reporting routes change. Check that the approval record, version history and the date of the last review are visible, and that the policy names the people behind each role rather than only job titles.
Incident register covering all ICT incidents
The register must record all ICT-related incidents and significant cyber threats, not only the ones that reach a reporting threshold. Tools such as DFIR-IRIS can hold each case as one record with assets, indicators, tasks and evidence, which gives assessors a single source to sample from. Confirm that the register is complete by reconciling it against alert queues and service desk tickets, and assign a named custodian who checks that new entries are created on time and that duplicates are merged.
Classification and priority records
Each entry should show how the incident was categorised, prioritised and assessed for severity and criticality of the affected services. Record the reasoning, not just the final label, so an assessor can follow why an incident was rated as it was. Review a sample of classifications periodically with the people who own the affected services, and update the criteria when services or the threshold logic change.
Escalation and communication logs
These logs show who was told, when and through which channel: internal escalation, senior management, staff, external stakeholders, clients and counterparts. Keep timestamps on each message and link them to the register entry. The communication owner, often the incident manager with legal or compliance support, should review the templates and contact lists at a set interval and after any incident where the contact path failed.
Senior management reports
Major incidents must be reported to senior management and the management body with their impact, the response and any additional controls. Keep the reports as dated documents with the decisions and actions recorded, so assessors can see that the board was informed and acted. The reporting owner, usually the CISO or CRO, should confirm each report reflects the current register and that open actions carry forward until closed.
Root cause analyses and closure tracking
Article 17 expects root causes to be identified, documented and addressed to prevent recurrence. Each analysis should link to the incident, list corrective actions with owners and due dates, and show when each action was verified and closed. Track open items in a workflow tool, and have someone outside the response team check that closed actions were effective, particularly where the same incident pattern appears again.
Which open-source tools produce incident evidence
Self-hosted open-source tools can generate the records that an Article 17 process depends on, but they do not make an entity compliant. Article 17 requires the organization to define and run the process, record all ICT-related incidents and significant cyber threats, and keep root cause and response evidence. The tools below produce inputs to that process. The entity still owns the procedures, classification decisions, roles and sign-offs, and must confirm that each output meets its own requirements before relying on it.
DFIR-IRIS (LGPL-3.0-or-later) is the case-management layer most relevant to Article 17(1) and (2). It keeps each incident as one case record holding assets, indicators of compromise, tasks and evidence, with a full audit trail of changes. It triages alerts from SIEM, EDR and REST sources into cases, builds a consolidated investigation timeline, and logs evidence with SHA-256 verification and chain of custody. Reports are generated from case data, which helps when management reporting must show impact, response and additional controls. Confirm with your own testers that the case fields, retention and export formats match your incident policy. The DFIR-IRIS documentation is the natural next read for configuration.
OpenSearch Security Analytics (Apache-2.0) and Wazuh (GPL-2.0-only) generate the detection signals that feed early warning and recording. OpenSearch detectors match ingested logs from hosts, network devices and cloud services against Sigma rules, record matches as findings with rule, log type and severity, send alerts to channels such as Slack or email, and link findings across log types through its correlation engine. Wazuh decodes logs, compares events against over 3,000 built-in rules and decoders plus custom rules, maps alerts to MITRE ATT&CK, and writes matches to alerts.log and alerts.json. Nextcloud (AGPL-3.0-only) adds file-platform evidence: the admin_audit app writes event detail to audit.log, or to the path set with logfile_audit. Confirm that log retention, time synchronization and integrity protection of these files meet your evidence requirements, and that detection rules are reviewed against your classification criteria under Article 18.
What the Article 17 process costs to run
This table breaks the cost of running an Article 17 incident management process into components, showing who is paid, whether each cost is one-time or recurring, what drives it, and how to keep it down. Use it to structure a written quote and to see where self-hosted open-source tools shift spend from licenses to configuration and hosting.
| Cost component | One-time or recurring | What drives it | How to reduce it |
|---|---|---|---|
| Policy and procedure drafting | One-time, then periodic review | Number of entities in scope, existing incident policies, and how many incident types and scenarios must be defined under Article 17(3)(c) | Reuse existing security incident procedures and map them to the Article 17 elements, then ask the implementation partner to draft against a written checklist |
| Tooling and licenses | Recurring for commercial tools, one-time for setup | Log volume, number of seats in the case management tool, and whether SIEM, EDR or ticketing products are licensed per user or per data volume | Self-hosted open-source tools such as DFIR-IRIS, OpenSearch Security Analytics and Wazuh remove most license spend, but configuration and hosting remain. Ask the quote to separate license, infrastructure and labor lines |
| Engineering time to integrate log sources and build detectors | One-time build, recurring tuning | Number of log sources (hosts, network devices, cloud services, applications), parser work, and the number of Sigma or custom detection rules to write and test | Prioritize critical services first, reuse prebuilt rule sets, and confirm which sources the in-house team can onboard without outside help |
| Hosting and storage for logs and cases | Recurring | Retention periods chosen for incident records and audit trails, log volume, and whether the platform runs in the client's own cloud, data center or air-gapped network | Set retention by the entity's own policy and legal duties, tier older data, and confirm storage sizing before the quote is final |
| Staff time for incident roles and training | Recurring, with one-time role design | Number of staff named to incident roles, shift coverage, how many incident types need separate response roles, and training frequency | Assign roles to existing security and operations staff, cross-train backups, and use scenario-based training instead of separate courses |
| Communication plan and escalation setup | One-time, then periodic review | Number of internal stakeholders, client and counterparty notification duties, media contacts, and the scope of ICT-related customer complaint handling | Maintain one template for each audience and rehearse it during routine exercises |
| Evidence upkeep and records | Recurring | Volume of incidents and significant cyber threats recorded, depth of the audit trail, evidence handling requirements, and report generation needs | Automate record capture from the case tool, standardize fields, and review sample records on a fixed schedule |
| Root cause follow-up and management reporting | Recurring | Number of major incidents, depth of root cause analysis, and frequency of reports to senior management and the management body | Use one post-incident review template, track corrective actions in a single register, and set a fixed reporting cycle |
| External review or tabletop facilitation | Recurring or per exercise | Scope of the review, whether an outside facilitator runs scenarios, and whether the process is tested against the entity's own incident types | Run internal tabletop exercises between external sessions and ask for a fixed-scope facilitation package |
| Auditor or assessor sampling effort | Recurring at each assessment | Number of incidents sampled, availability of complete records, and whether classification decisions are documented with their reasoning | Keep classification rationale and timelines in the case record so sampled files can be produced quickly. Only the independent assessor sets the sample |
Your team, an implementation partner and the supervisor
The financial entity remains accountable for its ICT-related incident management process under Article 17. Its own team must approve the policy, name the people who hold incident roles, decide how each incident is classified, and take responsibility for what senior management and the management body are told. A partner can draft procedures, but a procedure only becomes the entity's process once its own managers adopt it and run it.
- Policy and ownership: Management approves the incident management policy and assigns an accountable owner, so the definition of an incident and the escalation path have a named decision maker.
- Incident roles: Incident commander, technical responders, communications lead and compliance contact are assigned by name, with deputies, for each incident type and scenario.
- Classification decisions: Staff apply the criteria in Article 18 and the related technical standards to decide priority, severity and criticality. The reasoning should be written down at the time, not reconstructed later.
- Management reporting: Senior management and the management body receive reports on major incidents, their impact, the response and the additional controls, and the minutes show they discussed them.
- Root cause follow-up: Owners of the affected services track corrective actions to closure and confirm that the recurrence risk has been addressed.
Before engaging anyone, confirm internally which roles can be fulfilled by existing staff and which require a named, trained backup.
An implementation partner works under a written, fixed scope and prepares the technical means by which the entity records, detects, manages and documents incidents. Its deliverables are systems, configurations, templates and evidence packs. It does not decide whether an incident is major, does not sign reports to the competent authority, and does not sign off the entity's assurance statements. Those remain with the entity.
- Log sources and detection: Connecting hosts, network devices and cloud services to a self-hosted SIEM, with tested detection rules and documented coverage gaps.
- Case management: Configuring a self-hosted case tool with templates for incident records, timelines, evidence logging and post-incident reviews.
- Runbooks and test records: Drafting runbooks for each incident scenario and recording the results of tabletop exercises and simulated alerts.
- Evidence packs: Assembling dated exports, configuration baselines and audit trails that show the process ran as described.
- Handover: Training named staff, documenting administration and agreeing what support, if any, continues after handover.
Ask for the written scope, the list of deliverables, the acceptance criteria and who on the entity's side approves each one before work starts.
An independent auditor tests the design and operation of the process, and a competent authority supervises compliance using its powers under the Regulation. Neither issues a certificate for Article 17 as such, because DORA provides no certification scheme. Their job is to sample real incidents, check that records are complete and that classification and escalation followed the entity's own policy, and report findings.
- Design testing: Checking that the policy, roles and procedures cover the required elements and match the entity's actual services.
- Operating effectiveness: Sampling incidents and cyber threats to confirm they were recorded, classified and escalated on time.
- Independence: An auditor who helped build the detection stack or wrote the runbooks must weigh whether it can still test them objectively, and the engagement letter should say how that conflict is handled.
- Findings and remediation: Findings are addressed by the entity, and the auditor verifies closure rather than fixing the problem itself.
- Supervisory contact: Supervisors may request records directly, so evidence must be retrievable without the partner's involvement.
Confirm with the auditor which evidence it will sample and whether it accepts evidence produced by a partner.
Where incident processes fall short and how to close them
Most Article 17 gaps are not missing policies. They are processes that exist on paper but do not produce records, alerts, decisions or reviews an assessor can sample. The cards below cover six gaps that recur in incident programs, with a practical fix and the evidence each fix should leave behind.
Minor incidents never recorded
Teams often log only incidents that reach the service desk or the security queue, so smaller events such as failed failovers, short outages or repeated access errors never enter the register. Article 17 expects all ICT-related incidents and significant cyber threats to be recorded, not only the serious ones. Fix this by making the incident register the single intake point for every alert, ticket and manual report, with a required minimum set of fields. Check that a sample of closed low-severity tickets maps back to a register entry.
Early warning indicators not wired
Early warning indicators are often written into a policy but never connected to a detector, so nobody is alerted when they trip. Article 17 requires indicators that give early warning, which only works if they fire into the queue people watch. Fix this by mapping each indicator to a concrete rule in the SIEM or detection platform, such as a Sigma rule in OpenSearch Security Analytics or a Wazuh ruleset entry, and routing its alerts to a monitored channel. Evidence to keep: rule IDs, alert samples and test records showing the alert fired.
Classification disconnected from criteria
Teams frequently classify incidents by gut feel or by a local severity scale that does not reference the criteria in Article 18. This makes classification inconsistent between analysts and impossible to defend in a review. Fix this by building the classification form around the Article 18 criteria and the thresholds in the applicable delegated regulation, so each incident record shows which criteria were assessed and why the result was reached. Evidence to keep: completed classification forms and a change log for the scale.
Unclear roles after hours
A RACI chart that names only business-hours staff leaves nobody accountable for a Saturday-night ransomware alert. Article 17 requires roles and responsibilities for different incident types and scenarios, including out-of-hours coverage. Fix this by defining a named incident commander, a deputy and a decision owner for each incident type, with an on-call rota and an escalation path that does not depend on one person. Test the path with a tabletop exercise and keep the rota, the contact list and the exercise record.
Root causes closed without recurrence checks
Post-incident reviews often end with a root cause written down and the ticket closed, without anyone confirming the fix worked or that the same cause has not produced other incidents. Article 17 requires root causes to be identified, documented and addressed to prevent recurrence. Fix this by linking every corrective action to a tracked task with an owner and a verification step, and by searching the register for prior incidents with the same cause before closure. Evidence to keep: linked action items, verification notes and a recurrence query result.
Management reports without impact or controls
Management reports that list incident counts but omit business impact, services affected and the additional controls adopted give the management body nothing to decide on. Article 17 requires that major incidents be reported to senior management and the management body with their impact, response and additional controls. Fix this by standardizing a one-page report template drawn from the case record, with fields for affected services, client impact, duration, response taken and controls added. Evidence to keep: issued reports, minutes showing they were discussed and the decisions recorded.
Questions about Article 17 cost, effort and outside help
How much effort does an Article 17 incident management process take to set up?
The effort depends on how many ICT systems, services and third parties the entity runs, how mature its existing security operations are, and how many incident types its procedures must cover. Setup work usually includes defining the incident management policy, writing classification and escalation procedures, setting up a case record and detection sources, and running tabletop exercises to test the roles. Ask any implementation partner for a written scope that lists each of these deliverables, the systems in scope and the assumptions about existing tooling. Figures for effort should come from that written quote or from the entity's own inventory of systems, not from a general estimate.
Can a financial entity build its Article 17 process in-house?
Yes, an entity can build the process in-house, provided it has staff who understand DORA, its own services and its incident response obligations. The organization owns the process, the policy, the roles and the decisions made during an incident, and it cannot hand those to a vendor. Outside help is most useful for preparing systems, configuring detection and case tooling, and documenting evidence. Confirm internally whether the team can cover the policy, the tooling and the regular exercises. A reader who cannot staff those three areas should treat outside help as a capacity question, not a shortcut.
What does Article 17 require from staff day to day?
Staff need defined roles for each incident type, a clear escalation path to senior management and the management body for major incidents, and a way to record every ICT-related incident and significant cyber threat. Analysts must be able to log incidents, apply the classification criteria and keep the timeline current. Communications staff need a plan for internal teams, clients, counterparts and media. Recurring work includes reviewing the incident log, reviewing root cause actions and running exercises. Ask the entity's own HR and operations leads how many people can absorb this work without leaving gaps in on-call coverage.
How long does a fixed-scope Article 17 engagement run?
The duration depends on the agreed scope, the number of systems and integrations, the state of existing logging and the time needed for reviews and approvals by the entity. A fixed-scope engagement at DeployOpen is agreed in writing before work starts, and the written scope should state the deliverables, the milestones and the dependencies on the client's teams. Ask for the start conditions, the review cycles, the acceptance criteria for each deliverable and what happens if the entity delays input. Do not accept a timeline that is not tied to those written items.
What will an auditor sample when testing Article 17 compliance?
Auditors and competent authorities typically sample the incident log, the incident management policy, classification records, escalation and communication records and root cause reviews. They look for evidence that incidents are recorded consistently, that classification follows the defined criteria, that roles were followed in practice and that corrective actions were tracked to closure. The entity should prepare sample incidents, including recurring ones and near misses, and check that each has a complete timeline. Only independent auditors and supervisors issue conclusions on compliance. DeployOpen prepares systems and evidence but does not issue audit reports or attestations.
How does Article 17 relate to the reporting duties in Article 19?
Article 17 sets the internal process that detects, records, classifies and escalates incidents, while Article 19 sets the duties to report major ICT-related incidents to the competent authority within defined deadlines. The incident process must produce the information that reporting needs, including the classification outcome, impact, timeline and response steps. If the process is weak, reports will be late or incomplete. Confirm the reporting deadlines and formats directly with the competent authority and the current delegated regulations, and check whether the Digital Omnibus proposal would change the single entry point before finalizing the workflow.
How DeployOpen scopes and prepares Article 17 evidence
DeployOpen helps financial entities and their ICT providers prepare the incident management process, records and evidence that Article 17 expects. We plan and implement the self-hosted tooling inside your own infrastructure, while your organization owns the policy, the decisions and the process itself.
How we scope
- Engagements are fixed-scope, with the systems, incident types and roles to be covered agreed in writing before work starts.
- We confirm which ICT systems produce logs and alerts, and which teams own triage, classification and escalation.
- The written scope names the deliverables, including the procedures, tooling configuration and evidence we will prepare.
How we build
- We deploy and configure open-source detection, case management and logging platforms within your cloud accounts, data centers or air-gapped networks.
- We set up incident records, early warning indicators, classification fields and escalation paths aligned with your written incident management policy.
- We test the workflow end to end with sample incidents so the logs, alerts and case trails can be shown to an assessor or competent authority.
How we hand over
- We document the configured process, runbooks and roles so your staff can operate and explain the workflow without us.
- We deliver an evidence map showing which records, logs and reports correspond to each Article 17 requirement in your scope.
- Your management body and internal reviewers receive the documentation needed to approve the process and track root cause follow-up.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We can update detection rules, case templates and retention settings when your services, providers or regulatory technical standards change.
- DeployOpen prepares systems and evidence only. Independent supervisors and auditors assess compliance and issue any findings or reports.
