DORA major incident reporting automation with SOAR

How security automation supports DORA major incident reporting

When a financial entity classifies an ICT-related incident as major under Chapter III of DORA, a reporting clock starts, and the initial notification can be due within hours. Automation does not decide whether an incident is major. What it does well is gather the evidence that classification depends on, track each deadline against the moment of awareness and the moment of classification, and draft the notification fields for an accountable incident manager to check. The judgment on the six classification criteria in Article 18(1), and the decision to submit, stay with named staff, and the playbooks should record who made each call. A self-hosted SOAR platform such as Shuffle can run these steps as workflows on the entity's own infrastructure, with a case record that shows what the automation gathered and when.

Article 19(4) sets three reports: an initial notification, an intermediate report when status or handling changes significantly, and a final report once the root cause analysis is complete and actual impact figures replace estimates. Under Article 5 of Delegated Regulation (EU) 2025/301, the initial notification is due within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it, the intermediate report within 72 hours of the initial notification, and the final report no later than one month after the latest intermediate report. Playbooks should therefore carry two timers per incident, one from awareness and one from classification, and should check the weekend and bank holiday rules in the same Article before any deadline is shown to staff. Confirm the current templates and data fields in Commission Implementing Regulation (EU) 2025/302 with your regulator and legal team before mapping them into drafts.

DeployOpen plans, implements and hardens the self-hosted environment, builds the playbooks and prepares the evidence and control records that a supervisor may request. It does not issue audit reports, attestations or regulatory approvals, and it does not submit reports on the entity's behalf unless the entity's own process and approvals allow that. Before scoping, ask the implementation partner to show how each playbook step is logged, where credentials for reporting channels are stored, how the team tests the workflows against a simulated major incident, and which steps need a human approval gate. Those answers determine whether the automation will hold up on the day the clock starts.

Which DORA requirements the SOAR playbooks must cover and how to configure them

This table maps each DORA classification, reporting and timing rule to what the playbook must do, how to configure it in Shuffle, and what an assessor will expect to see. Read each row as a design requirement: the left column names the rule, the right columns show the workflow logic and the evidence it leaves behind. Confirm every timing rule against the current EUR-Lex text with your legal and compliance team before building timers.

Requirement	What the playbook must do	How to configure it and evidence to keep
Article 18(1): six classification criteria	Capture clients, counterparts, transactions, downtime, geographic spread, data losses, service criticality and economic impact for every incident	Mandatory case fields for each criterion with a timestamp and source; a workflow step blocks classification until all fields are populated
Article 18(2): significant cyber threats	Score threats on service criticality, number or relevance of clients or counterparts targeted, and geographic spread	Separate threat case type with a scoring branch; store the scoring inputs so the classification can be reproduced later
Article 8 of Delegated Regulation 2024/1772: major incident test	Route an incident as major when critical services are affected and either malicious unauthorised access with possible data loss occurred, or two or more other thresholds are met	Decision node in Shuffle that checks the critical-service flag and counts met thresholds; log the rule outcome and the analyst who confirmed it
Article 19(1): authority copy routing	Send the initial report to the relevant competent authority; significant credit institutions report to the national authority, which forwards to the ECB	Routing field set by entity type and significance status; a separate send step per recipient, with NIS2 or CSIRT copies added only where the member state requires them
Article 5 of Delegated Regulation 2025/301: initial notification timer	Start a deadline of 4 hours from classification as major, capped at 24 hours after awareness	Two timers per case: one from classification and one from awareness; the workflow uses the earlier date and records both timestamps
Article 5 of Delegated Regulation 2025/301: intermediate and final timers	Intermediate report within 72 hours of the initial notification; final report no later than one month after the latest intermediate report	Timers reset on each intermediate update; reminders escalate before expiry and the final timer is set only after the latest intermediate report is filed
Article 5(4) and (5): weekend and bank holiday rule	Move most deadlines falling on a weekend or bank holiday to noon on the next working day; initial notifications and intermediate reports by listed credit institutions, central counterparties, trading venues and NIS2 essential or important entities are excluded from this relief	Holiday calendar maintained per jurisdiction as a workflow input; the entity-type flag disables the roll-forward for excluded entities so the timer does not shift
Article 19(4): report sequence and updates	Initial notification, intermediate report when status or handling changes significantly, and final report once root cause analysis is complete and actual figures replace estimates	Status-change trigger that prompts an intermediate draft; a final-report gate that requires a completed root cause field and actual impact values
Approval gates on submissions	A named incident owner approves each outgoing report before it leaves the organization	Manual approval step with the approver identity, time and report version stored in the case audit trail; no automated submission without this step

How the reporting clock changes the playbook design

The reporting clock sets the playbook's timing before any technical step is designed. Under Article 5 of Delegated Regulation (EU) 2025/301, the initial notification is due within 4 hours of classifying the incident as major, and no later than 24 hours after the entity became aware of it. The playbook therefore needs two timers, not one: a classification timer that starts when the major classification is recorded, and an awareness timer that runs from first detection. The awareness timer is the hard outer limit, so a workflow that waits for classification to finish before it starts counting will miss the deadline on paper even if the team acts fast.

The clock must start from a logged awareness timestamp, written by the platform at the moment the first alert is ingested, not from when an analyst opens a case. Configure the Shuffle workflow so that the first step stores the source event time, the ingestion time and the case creation time in the case record, and make the timestamp immutable after write. Confirm with your counsel and your competent authority how awareness is defined for your entity, because the start of the 24-hour period determines everything after it. The intermediate report is due within 72 hours of the initial notification, and the final report no later than one month after the latest intermediate report. Schedule these as explicit reminders in the case, with escalation to the incident manager before each due time, and record every submission and acknowledgement as an event.

Weekend and bank holiday treatment needs a configuration decision. Deadlines that fall on a weekend or bank holiday move to noon on the next working day, except that initial notifications and intermediate reports by credit institutions, central counterparties, trading venue operators and NIS2 essential or important entities do not receive that relief under Article 5(4) and (5) of Delegated Regulation (EU) 2025/301. A calendar service that applies one rule to all entities will be wrong for some of them. Hold the working calendar, the holiday list for each jurisdiction and the entity type as versioned configuration values, and have counsel confirm which category applies to your organization before go-live.

Which open-source platforms feed and drive the reporting workflow

Detection platforms create the signals that start a major incident clock. In a DORA design, the detection layer has to produce timestamps, affected systems and service mappings that the classification step can use, because the six classification criteria in Article 18(1) depend on service criticality, duration and geographical spread. Wazuh covers host and endpoint telemetry, while Security Onion brings network monitoring with Suricata and Zeek and log management on the Elastic stack.

Wazuh licensing: the core repository is licensed under GPL version 2, with an OpenSSL linking exception, and the current release line is 4.14.
Security Onion licensing: the platform is licensed under the Elastic License 2.0, which is a different position from GPL-licensed components and should be reviewed by counsel before it is embedded in a service.
Network sensors: Suricata (GPL-2.0) and Zeek (BSD-style license) can be placed to show traffic affecting critical services, which matters for the geographical spread and affected-client questions.
Asset mapping: keep a tagged inventory that links each agent or sensor to an important function, so duration and criticality can be measured.

Confirm with your security team which log sources and retention periods support the timestamps your regulator will expect, and check each license with your legal team before production use.

Platforms that fit the DORA reporting workflow and why

DORA reporting depends on fast detection, a case record that holds the classification evidence, and credentials that automation can use without spreading them across tools. The platforms below cover those roles, and each one raises a specific check before it goes into a regulated environment.

Shuffle as the playbook engine

Shuffle runs the workflows that gather alert data, apply the six Article 18 classification criteria as structured fields, and draft the initial notification. It is licensed under AGPL-3.0 and its v2.3.0 release was published on September 28, 2026. Confirm how your team will version workflows, since reporting logic changes whenever the implementing standards are updated. Choose a deployment model early: Docker Compose, Swarm, a hybrid with Shuffle Cloud, or Kubernetes with Helm charts.

Wazuh for detection and evidence

Wazuh provides the event source for many incidents through its indexer, server, dashboard and agents. It is distributed under GPL-2.0, and the current release line is 4.14. Before relying on it for reporting timelines, confirm that agent clocks are synchronized and that alerts retain the fields your classification needs, such as affected services and data categories. The server can run as a cluster, which matters if reporting volume grows during an incident.

Keycloak for analyst access

Keycloak supports OpenID Connect and SAML 2.0, so analysts can sign in to Shuffle, the case system and the SIEM dashboard with the same workforce identity. It is licensed under Apache-2.0. Shuffle added SAML in 0.9.16 and OpenID Connect in 1.0.0, and it is moving Shuffle Cloud from SAML to OpenID Connect. Confirm which protocol each connected tool supports, and require multi-factor authentication for anyone who can approve a regulator submission.

MISP or OpenCTI for indicator context

Indicator context helps classify a cyber threat as significant under Article 18(2), which looks at the criticality of services at risk, the number of clients or counterparts targeted, and geographic spread. MISP is licensed under AGPL-3.0, and OpenCTI ships a Community Edition under Apache-2.0 alongside an Enterprise Edition under a separate license. Confirm which edition your team needs before automating enrichment against it, and decide whether shared indicators are subject to your sharing rules.

OpenBao for connector credentials

Shuffle stores saved app credentials and API keys in OpenSearch with AES-256, keyed by the SHUFFLE_ENCRYPTION_MODIFIER secret, and it warns that losing or changing that secret breaks every saved app authentication. OpenBao, licensed under MPL-2.0 and hosted under the OpenSSF, can hold that secret and the credentials for ticketing and cloud connectors. Plan key backup and rotation before go-live. HashiCorp Vault 1.15.0 and later use the Business Source License 1.1, which is not an OSI-approved open source license, so confirm whether that fits your procurement policy.

What evidence supervisors and auditors ask for and which component produces it

What timestamped records prove when an incident was detected and when the clock started?

Timestamped alerts from the detection layer and the execution history of the automation platform are the first records a supervisor asks for. Wazuh produces alerts with event times, stored in the Wazuh indexer, which show when a signal was first seen. Shuffle keeps an execution history for each workflow run, showing which triggers fired, which actions ran, and when each step completed. Together they give a sequence that can support the awareness time used for the 24-hour and 4-hour deadlines. Confirm with your compliance lead which timestamp counts as awareness under your own procedure, and make sure both systems use synchronized clocks, because a mismatch between sources can distort the timeline in front of an examiner.

What classification memo should we keep for each major incident?

A written classification memo records how the incident was assessed against the criteria in Article 18(1) and the thresholds in the delegated regulation on classification. The memo should state the facts used for each criterion, the people who made the decision, and the date and time the incident was classified as major. Shuffle can collect the enrichment results and attach them to a case record as the workflow runs, but the judgment itself stays with a named person. Store the memo in the same case record as the workflow output so the reasoning and the evidence can be read together. Illustrative example: a memo that cites the number of affected clients, the downtime of a payment service and the member states involved, with a link to the logs behind each figure.

How do we prove what was actually submitted to the competent authority?

Keep a copy of every notification exactly as transmitted, with the submission time, the channel used and the reference returned by the authority where one is issued. A workflow can generate the notification from the case fields, store the rendered document and the outgoing record in the case, and log the submission step. Confirm with your competent authority which template, format and channel it expects, since the implementing standards set the data fields and the authority may publish its own submission process. Keep each version of the initial notification, intermediate report and final report, so that updates can be compared against earlier submissions.

What root cause analysis and impact figures does the final report need?

The final report needs a completed root cause analysis and actual impact figures that replace the estimates given earlier. Those figures should trace back to source data such as service logs, client counts, transaction records and cost entries. Automation helps by pulling these records into the case as they are produced, but it does not write the root cause conclusion. Keep the analysis document, the data extracts used for each figure, and the review sign-off in the case. Ask your team which systems hold the authoritative counts for clients, transactions and losses, because the report will be compared against them.

Which access logs show who prepared and submitted reports?

Authentication and authorization events from the identity provider show which staff signed in to the case management and reporting tools, and when. If the workforce single sign-on runs on Keycloak or authentik, the event logs record logins, failed attempts, role changes and token issuance, and these should be forwarded to the SIEM. Shuffle's own login and SSO configuration should be reviewed too, since it can enforce SSO per tenant. Auditors often ask for a list of who had access to submit reports and whether that access was reviewed, so pair the logs with the access review records from your identity governance process. Confirm retention periods for these logs with your compliance team.

How do we show change records for automated playbooks?

Auditors expect a change record for every playbook that can touch systems or send reports, showing what changed, who approved it, when it was tested and when it went live. Keep playbook definitions in version control, link each change to a ticket, and record the approval and test results alongside it. Shuffle stores workflow revisions and execution history, which helps show which version ran during an incident. Confirm how your team handles changes to the Shuffle app containers and credentials, because a change to an app version can alter how a notification is generated and must be traceable.

What is the difference between an audit trail of the platform and evidence of the report?

An audit trail shows how the systems were used, while report evidence shows what was decided and sent. Both are needed. The platform audit trail includes alerts, workflow runs, user sign-ins and configuration changes, and it should be protected against tampering and kept for the period your regulator expects. The report evidence includes the classification memo, the submitted documents, the analysis and the sign-offs. Treat the two as separate collections linked by incident identifier so an examiner can move from a reported figure to the log that supports it. Ask your compliance lead to define the retention period for each, because the regulation sets the reporting duties while retention rules come from your own policy and national requirements.

Can our own team assemble this evidence, or do we need a partner?

Your own team can assemble this evidence if it owns the detection, automation and identity systems and has time to maintain the records. A partner is useful when the work includes configuring the log sources, building the case records, documenting the playbooks and preparing the evidence set for an assessment. DeployOpen plans, implements, documents and supports self-hosted open-source platforms in the client's own infrastructure and prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or attestations. Engagements are fixed-scope and agreed in writing, so define which evidence items are in scope before work starts and confirm who keeps the records after handover.

What automation alone does not satisfy in DORA reporting

A SOAR playbook can gather evidence, fill fields and send notifications on time, but it cannot decide that an incident is major or answer for that decision. The cards below cover the judgments, template and channel confirmations, access controls, regulatory changes and governance that stay with the financial entity.

Classification needs accountable sign-off

Article 18(1) asks for classification against six criteria, including clients affected, duration, geographic spread, data losses, service criticality and economic impact. A playbook can score the inputs it can measure, such as downtime from monitoring or affected client counts from a service inventory. The determination that an incident is major under Delegated Regulation (EU) 2024/1772 should still be made and signed by a named role. Confirm who holds that role, how overrides are logged, and what the playbook does while a decision is pending.

Templates and channels need confirmation

The content of notifications and reports is set by the implementing standards, and the competent authority determines how submissions are made. Automation can prefill fields, but the entity must confirm the current template version, the required format and the submission channel with its own supervisor before go-live. Ask whether the authority accepts automated submissions, whether it requires copies to NIS2 authorities or CSIRTs in your member state, and how it handles corrections to a submitted report.

App credentials are not an access policy

Shuffle encrypts saved app credentials and API keys in OpenSearch, which protects them at rest but does not decide who may run a playbook that uses them. Each connected system, such as a ticketing tool, cloud account or identity provider, needs its own least-privilege service account, owner and rotation schedule. Confirm who can edit workflows, who can approve execution of a reporting step, and how changes to the SHUFFLE_ENCRYPTION_MODIFIER secret are controlled, since changing it breaks saved authentications.

Digital Omnibus may change requirements

The Commission proposal COM(2025) 837, the Digital Omnibus, is pending and may alter parts of the DORA framework that reporting playbooks depend on. The Article 58 review, due by 17 January 2028, also covers the criteria for designating critical ICT third-party providers. Before fixing playbook logic and thresholds, check the current status of procedure 2025/0360(COD), the text as adopted, and the date of any application change. Build thresholds as configuration so they can be updated without rewriting workflows.

Playbook testing stays with the entity

A partner can build and document playbooks, but the financial entity remains responsible for its incident reporting. Each playbook needs test cases that cover a major incident, a non-major incident, a missing data field and a failed submission, with results kept as evidence. Define who approves a playbook change, how versions are controlled when Shuffle or its apps are upgraded, and how the entity runs a tabletop exercise that does not depend on the automation being available.

Worker availability affects deadlines

The initial notification is due within 4 hours of classification, so an outage in the SOAR platform can cause a missed deadline. Shuffle's high availability guidance recommends an OpenSearch cluster and more than one Orborus node so workflows keep running if one fails. Confirm where workers run, how a failed execution alerts a named person, and what manual procedure applies if the platform is down during the reporting window.

How a DORA reporting automation project moves from scope to live playbooks

The sequence turns DORA's classification and reporting duties into tested Shuffle playbooks that run on infrastructure the financial entity controls, with each stage closed by a written output the compliance and security owners can sign off.

Confirm entity type and competent authority
The project starts by establishing which of the 20 financial entity types in Article 2(1) the organization is, whether it is a significant credit institution, and which national competent authority receives its reports. Compliance, legal and the security lead agree this in writing, because it sets the recipients, the notification routes and whether copies go to NIS2 authorities or CSIRTs. The output is a one-page scope memo that names the authority, the reporting routes and the owner of each. The step is done when that memo is approved.
Inventory critical services and incident sources
Operations, technology and business owners list the ICT services that support critical or important functions, the systems behind them, and the tools that generate alerts about them, such as SIEM, EDR, cloud and identity logs. Each service is tagged with its client base, counterparts, transaction volumes and recovery dependencies, since these are the figures the classification criteria later need. The output is a service and source register that maps every alert source to the services it can affect. The step closes when the register is reviewed against the current configuration management database.
Define classification inputs and thresholds
Working from the six criteria in Article 18(1) and the thresholds in Delegated Regulation (EU) 2024/1772, the team decides which data each playbook must collect automatically and which values a human must confirm. Examples include affected client counts, downtime, affected member states and estimated losses. Where a threshold depends on figures the entity does not yet track, the gap is logged with an owner. The output is a classification input specification that compliance signs off. The step is done when every threshold has a named data source or a documented manual input.
Build and test playbooks in a non-production Shuffle instance
Engineers deploy Shuffle in a non-production environment inside the entity's own infrastructure, then build workflows for triage, enrichment, classification prompts and draft report generation. Credentials for connected tools are stored in Shuffle's encrypted store, and the encryption secret is recorded in the entity's secrets process before any app is connected. Each workflow is run against replayed or synthetic alerts, and the results are compared with the expected classification. The output is a tested workflow set with a test log. The step closes when every workflow passes its test cases and failures are resolved or accepted in writing.
Add approval gates and deadline tracking
Before anything reaches a regulator, the team places human approval steps before each external submission and before any automated containment action that affects a production service. Deadline logic is added to the case record, using the notification, intermediate and final report timings in Delegated Regulation (EU) 2025/301, including the rules on weekends and bank holidays. The team confirms with the competent authority which templates and submission channels apply, since the implementing standards set the formats. The output is a gate and deadline matrix with named approvers. The step is done when a tabletop test confirms that a missed approval triggers escalation.
Run tabletop exercises with the incident team
The incident response, operations, legal, communications and compliance teams walk through a scripted major incident and the playbooks that handle it. The exercise covers the initial notification, a change in status that triggers an intermediate report, and a final report once the root cause analysis is complete. Participants record where the playbooks, the templates or the roles were unclear. The output is an exercise report with a corrective action list and owners. The step closes when corrective actions are assigned and the affected workflows are retested.
Go live with a support and change plan
The workflows move to the production Shuffle deployment through the entity's change control process, with production credentials issued separately from the test environment. Monitoring covers worker health, failed executions and the deadline queue, and the team confirms that more than one Orborus node is available so workflows keep running if one fails. A support plan defines who maintains connectors when vendor APIs change and how Shuffle upgrades are tested first. The output is a signed go-live record and an operating runbook. The step is done when the first live reporting cycle is reviewed by compliance.

How much effort and cost does DORA incident reporting automation take?

What drives the cost of DORA incident reporting automation?

The cost is driven by how many incident sources, playbooks and integrations you automate, how the platform is hosted, and how much Shuffle execution you run. Shuffle's open-source edition includes all features, and its paid tiers differ in feature limits, scaling and support, so the licence question depends on the edition you choose. Licensing is priced on app runs, meaning actions that actually execute in a workflow, while triggers and skipped actions are not counted. Ask any partner to separate one-time build work from recurring items: hosting, worker capacity, connector upkeep and the Shuffle edition. Ask for a quote that lists each playbook and each connected tool as a line item.

Can our internal security team build DORA reporting playbooks alone?

A capable internal team can build the first playbooks, but the work needs skills across security operations, regulatory interpretation and platform engineering. The team must write Shuffle apps from OpenAPI specifications or the Python SDK, store credentials safely, and keep workflows working as connected tools change. Classification decisions and report content also need people who understand the six classification criteria and the reporting templates. Many organizations split the work: internal staff own classification and approvals, while an implementation partner builds and tests the workflows under a written scope. Confirm your own skills gaps before deciding.

What does the team need to provide during the project?

The project needs named classification owners, a legal or compliance reviewer for each report, and people who can approve changes to automated steps. You also need access to the source systems that feed incident data, such as SIEM alerts, ticketing and identity logs. Plan test windows that do not overlap live incidents, and use a non-production Shuffle environment for tabletop runs. Agree in advance who signs off the templates and timing rules, because the reporting deadlines depend on when the institution classifies an incident as major. Document these responsibilities in the statement of work before work starts.

How long does DORA reporting automation take to implement?

Duration depends on how many sources, playbooks and approval gates are in scope, how mature your incident records are, and how quickly your classification and legal reviewers can respond. A narrow first release covering one notification path usually takes less time than a full set of initial, intermediate and final report workflows across several entities. Dependencies such as access to tools, credential approvals and change windows often set the pace more than the build itself. Ask a partner for a timeline tied to written milestones, and confirm which dependencies on your side could move the schedule.

What should a fixed-scope quote for this work include?

A fixed-scope quote should name the entities and incident types covered, the list of playbooks, each source and destination system, and the reporting outputs. It should state the Shuffle deployment model, the high-availability design, and who operates it after go-live. Ask for separate lines for discovery, build, testing, documentation and handover, plus any recurring support or upgrade retainer. The quote should also state exclusions, such as legal interpretation, regulator communication or changes to source systems. Scope, deliverables and timelines are agreed in writing before work starts, so ask for these terms in the first draft.

Does DeployOpen provide the regulatory report or legal opinion?

No. DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and it prepares the evidence and workflows that your team uses. Classification decisions, report content and regulator communication remain the responsibility of your organization and its legal advisers. DeployOpen does not issue audit reports or attestations, and it does not publish a price list, so a quote follows from the written scope. Confirm this division of responsibility in the contract.

What ongoing costs should we expect after go-live?

Ongoing costs usually include hosting and worker capacity, Shuffle app-run usage, updates to connectors when vendors change their APIs, and periodic testing of playbooks. Shuffle recommends the latest Docker tag for stable releases, so an upgrade plan is part of the running cost. Some organizations keep this work in-house, while others buy a support retainer that covers upgrades and continuous testing. Ask a partner to estimate these recurring items in writing and to state what happens when a connected tool changes.

How DeployOpen scopes DORA reporting automation work

DeployOpen scopes DORA reporting automation as a fixed-scope written engagement, with the playbooks, connectors, hosting and evidence set out before work starts. A typical scope for this topic covers the self-hosted Shuffle deployment inside your environment, the detection sources that feed it, the classification and notification workflows for the Article 18 and Article 19 steps, and the case records and audit trail that a reviewer will sample. Your team should expect the written scope to name each playbook, each connected system, each approval gate, and the people who own each decision, including who can declare a major incident and who signs off each report. Ask any partner to list those items explicitly, because a scope that says only "DORA reporting" leaves the deadline logic and the approval path undefined.

Beyond the build, DeployOpen plans and hardens the platform the playbooks run on, documents how it is operated, and supports it over time. Hardening work usually covers access to the Shuffle interface, the handling of the encryption secret used for saved app credentials (where the configuration documentation warns that losing or changing it breaks all saved app authentications), backup and restore of that secret, and the high availability design recommended in the Shuffle configuration docs. Ongoing support, upgrades and continuous testing are available as retainers, which matters because connectors and detection platforms change between releases. Confirm with the partner which upgrade and testing activities sit inside the retainer and which are billed separately.

DeployOpen prepares systems, controls and evidence for assessment, but it does not issue audit reports, attestations or certifications. DORA sets no certification scheme, so your competent authority or independent reviewers will judge the evidence you produce, not a DeployOpen statement. Ask the partner to show you the evidence pack in advance: playbook version history, approval logs, timestamped notification records and the test results for the deadline logic. Confirm with your own compliance function and your competent authority which records they expect, and agree in the written scope who maintains them after handover.

How DeployOpen works on this

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For DORA major incident reporting, we start from your classification criteria and reporting clock, then build the Shuffle playbooks and evidence capture around them in your environment.

How we scope

Written scope covers which alert sources feed the playbooks and which ICT services fall under classification.
Scope records the six Article 18 classification criteria and the thresholds your organization uses to call an incident major.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Playbooks are built in self-hosted Shuffle, with each deadline step tied to a logged timestamp.
Credentials for connected tools are stored in Shuffle's encrypted store, with the encryption secret managed under your change control.
Workflows are tested against sample incidents in a non-production environment before they touch live alerts.

How we hand over

Handover includes playbook documentation, report templates mapped to the implementing standards, and an operator runbook.
Your team receives walkthroughs of classification decisions, approval gates and the evidence each report draws from.
Documentation records what the automation does and what remains a human decision, so your compliance team can review it.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover platform upgrades, connector maintenance when reporting templates or tools change, and playbook reviews.
Ask any partner to confirm how updates to the regulatory technical standards would be reflected in your playbooks and reports.

Security automation for DORA major incident reporting