How DORA operational resilience applies to event streaming
A bank or payment institution whose payments, trades or account events flow through a broker needs its streaming platform to produce evidence for DORA's resilience requirements. Regulation (EU) 2022/2554 requires documented backup policies and procedures that set the scope of data backed up and the minimum backup frequency, restoration and recovery procedures, redundant ICT capacity adequate for business needs, recovery time and recovery point objectives set per function, and yearly testing of continuity plans that includes switchover between primary infrastructure and redundant capacity. DORA has applied since 17 January 2025 and, as a regulation, is directly applicable in every member state without national transposition, so these expectations are not optional for in-scope entities.
For a broker, that translates into concrete design decisions. Topic backups must be defined per topic class, and the team must show that a restore of a critical topic reproduces the expected offsets and partitions. Redundant capacity has to be sized for the business need, and the switchover path, whether it uses Kafka's cross-cluster replication, MirrorMaker 2, or Pulsar geo-replication, has to be exercised in the annual test, including the cyber-attack scenario the Article 11(6) text requires. The recovery objectives set for each function determine the replication lag and retention that the platform must meet. Confirm with your supervisor and your own architecture team how these objectives map onto your functions, because DORA does not supply numbers for them.
DeployOpen plans, implements and documents these controls on self-hosted Kafka or Pulsar inside your own data centers or cloud accounts, and prepares the runbooks, test records and configuration evidence your teams will rely on. DeployOpen does not issue audit reports, attestations or certifications. Competent authorities supervise compliance, and independent assessors judge whether your evidence is sufficient. Ask any implementation partner to show how each backup, switchover and restoration test produces a dated, reviewable record, and to explain who holds the keys and logs that support it.
Mapping DORA articles 11 and 12 to streaming controls
This table maps the DORA provisions on continuity testing, backup, redundant capacity and recovery objectives to the concrete streaming configuration an assessor will expect to see. Read each row as a requirement, the control to build for it, and the evidence to keep; the controls are starting points to confirm against your own risk assessment and the Kafka or Pulsar version you run.
| Requirement | Streaming control to configure | Evidence to keep |
|---|---|---|
| Article 11(6): yearly continuity tests, including cyber-attack scenarios and switchover to redundant capacity | Schedule at least one switchover test per year for each critical function's topics, and repeat it after substantive changes to brokers, clusters or network paths. Include a scenario where the primary cluster is unavailable or compromised, and confirm that producers and consumers reconnect to the secondary cluster. | Dated test plans, scenario scripts, switchover timings, consumer lag and message loss results, and sign-off of corrective actions |
| Article 12(1): documented backup policy setting data scope and minimum frequency by criticality | Define which topics, consumer offsets, schemas, ACLs and cluster configuration are backed up, and how often, per criticality tier. Topics are not a database, so mirror or export them to a separate storage target and document why retention alone does not count as a backup. | Backup policy document, topic inventory with criticality tags, backup job logs and configuration exports |
| Article 12(2): backup systems that can be activated safely, with periodic restore tests | Restore topics into an isolated cluster on a fixed schedule and check record counts, ordering keys and offset ranges against the source. Activate backups without reopening the production trust path, using separate credentials and ACLs for the restore environment. | Restore test reports with checksums or record counts, isolated-environment access records, and failed-restore remediation tickets |
| Article 12(4): redundant ICT capacity adequate for business needs | Run a replication factor of at least three for critical topics on Kafka, with min.insync.replicas set so writes are not acknowledged on a single copy. For Pulsar, size BookKeeper ensemble and write quorum settings for the same goal. Keep a mirrored cluster with enough broker and storage capacity to carry the critical load, confirming the sizing against peak throughput. | Capacity model, replication settings per topic, broker and disk headroom reports, and sizing review records |
| Article 12(5) and geographic separation: secondary site at a distance from the primary | Article 12(5) applies to central securities depositories, but many financial entities use the same logic for streaming. Place the mirrored cluster in a separate facility or availability zone, and use MirrorMaker 2 or Pulsar geo-replication for cross-site copies. Confirm the distance and independence requirement applicable to your entity type with your competent authority or legal team. | Site inventory, replication topology diagram, and documented distance and independence rationale |
| Article 12(6) and (7): recovery time and recovery point objectives per function, with reconciliation | Set RTO and RPO per business function, not per cluster. Measure replication lag against the RPO and failover duration against the RTO. After recovery, reconcile message counts, consumer offsets and business-level totals (such as payment counts) before consumers resume, and record discrepancies. | Approved RTO and RPO per function, replication lag dashboards, reconciliation reports and timestamped recovery logs |
| Access control during failover: ACLs and authentication on every cluster | Apply the same authentication and ACLs on primary, mirrored and restore clusters. For Kafka in KRaft mode, the StandardAuthorizer stores ACLs in the metadata log, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Keep that setting false and confirm ACL replication on the secondary cluster. | ACL exports from each cluster, authentication configuration, and access reviews covering the secondary and restore environments |
| Monitoring to detect loss, lag and failed backups | Alert on under-replicated partitions, offline partitions, replication lag beyond the RPO, failed backup or mirror jobs, and certificate or credential expiry. Route alerts to the on-call team responsible for the critical function and keep alert history for the test record. | Alert rules, alert history, on-call runbooks and incident tickets linked to test results |
| Version support during upgrades that change the recovery path | Confirm the Kafka or Pulsar version is still supported before each test cycle and after each upgrade. Kafka 4.0 supports only KRaft, so ZooKeeper clusters must migrate first. Repeat the switchover test after upgrades, since Article 11(6) treats substantive system changes as a trigger. | Version inventory, upgrade change records, and post-upgrade test results |
Which self-hosted platforms fit a DORA resilience design
DORA does not name a streaming product, but the backup, redundancy and switchover duties in its ICT continuity articles apply to whatever carries critical functions. The cards below cover the two Apache platforms that offer log-style replay and cluster-level redundancy, then the conditions under which NATS or RabbitMQ can still be considered.
Apache Kafka for replayable critical streams
Kafka is licensed under Apache-2.0 with no paid edition from the project itself, so the license cost is zero and the recurring cost is people and infrastructure. Supported releases are 4.3.1, 4.2.2 and 4.1.2, and Kafka 4.0 and later run in KRaft mode only, so ZooKeeper-based clusters must migrate first. Confirm that your design uses the KRaft controller model and a tested upgrade path, since rolling upgrades are supported from the last three releases. For geo-replication, the documented approach is cross-cluster mirroring, which you must test as part of your switchover exercise.
Kafka security and access controls
Kafka supports SSL/TLS for traffic between clients, brokers and tools, and SASL mechanisms including SCRAM-SHA-512 and OAUTHBEARER. Security is optional in Kafka, so an unsecured listener can remain open unless you disable it. In KRaft clusters, ACLs live in the metadata log, and resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true. Confirm that this default is off in your environment, because backup and restore access should be limited to named roles.
Apache Pulsar with independent storage scaling
Pulsar is an Apache-2.0 project with stateless brokers, BookKeeper bookies for persistent storage and a separate metadata store. Storage capacity grows by adding bookies without adding brokers, which can simplify capacity planning for large retention needs. The 5.0 LTS release was published on October 5, 2026, with active support until October 5, 2028 and security support until October 5, 2029. Pulsar 4.0 LTS reaches the end of active support on October 21, 2026, so plan any upgrade with that date in view.
Pulsar geo-replication and operations
Pulsar includes geo-replication as a built-in feature, with multi-tenancy, authentication, authorization and quotas that support shared platforms. Confirm how your team will test cross-site replication, failover and consumer position recovery, because a switchover is only evidence if it is exercised. Operating Pulsar means running three component types (brokers, bookies and the metadata store), so you should confirm skills for each before choosing it over Kafka.
NATS for non-replay messaging
NATS fits request-reply and lightweight messaging where a critical function does not need to replay a full history of events. Before selecting it for a DORA-relevant function, confirm how JetStream persistence, replication and backup are configured, and whether restoration tests cover the streams you rely on. If the function requires audit replay or reprocessing from a recovery point, NATS may not meet the recovery point objective you set, so test that requirement explicitly.
RabbitMQ for task queues
RabbitMQ suits work queues and message routing where each message is consumed once and then removed. Confirm the queue type, quorum queue replication and the backup approach for definitions and messages in your environment. Because consumed messages are generally not kept for replay, check whether your recovery procedures can rebuild state from source systems within the recovery time objective agreed for that function.
How yearly switchover tests should run on a streaming platform
Plan the yearly switchover as a scripted exercise with a written scenario, a named owner for each step and a pre-agreed pass or fail rule. Article 11(6) requires switchovers between primary ICT infrastructure and redundant capacity, and for entities other than microenterprises the test must include cyber-attack scenarios. For a streaming platform, that means the scenario should cover more than a site outage: for example, a credential compromise that forces rotation of SASL or TLS credentials on the primary cluster, or a corrupted topic that must be restored from backup before consumers resume. Each scenario should state which topics and consumer groups are in scope, which systems depend on them, and what the team will do if the redundant cluster rejects clients. Confirm with your competent authority and internal audit how they expect cyber scenarios to be documented.
Test the mechanics that usually break during failover. Consumer offset translation has to be exercised with real consumer groups, not assumed, so record the translated offsets, the lag each group resumes with and any duplicate or skipped processing. Producer reconfiguration is the second check: confirm that applications point to the redundant bootstrap servers through the agreed mechanism (DNS change, configuration service or client library setting) and that producers with idempotence or transactions behave as documented in the Kafka version you run. Verify ACLs on the redundant cluster before the test, because a cluster where resources without ACLs are restricted to super users, unless allow.everyone.if.no.acl.found is set, will block clients that work on the primary. Confirm the setting and the authorization model with your platform team and with the Apache Kafka security documentation for your release.
Measure the result against the recovery time objective and recovery point objective set for each function, which Article 12(6) requires to be set per function according to whether it is critical or important. Time the interval from the declared incident to the first successful consumption on the redundant side, and compare the last committed message on the primary with the last message available after switchover to calculate the data gap. Article 12(7) also expects checks and reconciliations during recovery, so reconcile record counts or checksums for the affected topics and keep the output as evidence. Record every deviation, assign remediation owners, and treat any missed objective as a finding that feeds the next test, not as a closed exercise.
Evidence auditors and supervisors ask for
This table lists the artifacts a competent authority or internal audit is likely to sample for a streaming platform supporting a critical function, and which component or team produces each one. Use it to plan evidence collection before a supervisory request arrives. The main takeaway is that most items come from the cluster itself, the runbooks and monitoring, and the change tickets, so they must be captured as the platform runs rather than assembled afterwards.
| Artifact | What it shows | Produced by |
|---|---|---|
| Documented backup policy | Scope of topics, metadata and configuration backed up, and minimum backup frequency set by criticality (Article 12(1)) | Runbooks and governance documents, reviewed against cluster configuration |
| Backup and restore test records | Periodic tests of backup and restoration procedures, with results and defects (Article 12(2)) | Runbooks executed on a test cluster, recorded in the ticketing system |
| Switchover test reports | Yearly continuity tests including switchover to redundant capacity and cyber-attack scenarios (Article 11(6)) | Test plans, failover runbooks, monitoring timelines and post-test reports |
| Redundancy design | Redundant capacity adequate for business needs, including broker, storage and metadata quorum layout (Article 12(4)) | Architecture documents and cluster configuration exports |
| Per-function RTO and RPO register | Recovery objectives set per function, reflecting whether it is critical or important (Article 12(6)) | Business owners and risk function, with the platform team confirming achievable values |
| Reconciliation logs after recovery | Checks confirming offsets, record counts and data integrity after restoration (Article 12(7)) | Consumer offset reports, reconciliation scripts and monitoring output |
| Access control and ACL exports | Who can produce to or consume from each topic, and that resources without ACLs are restricted | Authorizer ACL exports from the cluster metadata, and identity system records |
| Change records | Tests performed after substantive changes to systems supporting critical functions (Article 11(6)) | Ticketing system, change advisory approvals and pipeline logs |
How to sequence the work from design to first passing test
The sequence turns DORA's continuity, backup and recovery requirements into a streaming platform that has defined recovery objectives, tested restores, a proven switchover and a repeatable yearly test. Each step closes with an output that a competent authority or internal auditor could inspect.
Classify critical functions and set recovery objectives
Start by listing which business functions depend on streams and whether each is critical or important under the entity's own assessment. For each function, agree a recovery time objective and a recovery point objective, as Article 12(6) requires, and record which topics, consumers and producers serve it. Business owners sign off the objectives with the risk function, and engineering confirms they are technically achievable with the chosen replication design. Done means a signed register mapping each function to its topics, RTO and RPO.
Design redundant capacity and backup scope
Using the register, design the redundant capacity that Article 12(4) expects, including the secondary site or cluster, replication method and sizing for peak load during failover. Define the backup scope under Article 12(1): which topics, configurations, ACLs, schemas and metadata are backed up, and the minimum frequency tied to criticality and confidentiality. Confirm with the vendor or documentation how the chosen platform handles offsets, metadata and access control during recovery. Done means a reviewed architecture and backup policy that name every backed-up component.
Build and harden the cluster
Deploy the brokers, controllers or bookies, and supporting services in the entity's own infrastructure, using a supported release and a documented upgrade path. Enable TLS for client and broker traffic, configure SASL authentication, and set ACLs that deny by default. Confirm the Java runtime and operating system versions against the vendor's current requirements before installation. Done means a hardened build that matches the design, with configuration held in version control and a baseline security scan on file.
Implement backup and restoration procedures
Configure the backup jobs and write the restoration runbook, covering who can start a restore, the order of steps, and the reconciliation checks Article 12(7) requires to confirm data integrity after recovery. Backup systems must be able to be activated without weakening security or integrity (Article 12(2)), so store backup copies with separate credentials and test that they can be read. Done means a runbook reviewed by operations and security, with restore steps that have been dry-run in a non-production environment.
Run the first restore and switchover
Execute a documented restore of a representative topic set into an isolated environment, then perform a controlled switchover from the primary cluster to the redundant capacity. Measure the elapsed time and the data gap against the RTO and RPO set in step one, and record every deviation with its cause. Include a cyber-attack scenario in the exercise, since Article 11(6) requires one for entities other than microenterprises. Done means a test report with measured results, reconciliation outcomes and a list of corrective actions with owners.
Document evidence and close corrective actions
Assemble the evidence an assessor will ask for: the function register, backup policy, architecture diagrams, runbooks, test logs, reconciliation results and approvals. Track each corrective action from the first test until it is closed and retested. Ask the implementation partner to state in writing which artifacts they produce and which remain the entity's responsibility. Done means an evidence index that maps each artifact to the DORA article it supports, with open actions visible to management.
Schedule the yearly test and retest after changes
Set the annual continuity test calendar in the ICT business continuity plan, covering switchover, restoration and recovery, as Article 11(6) requires at least yearly. Add a trigger for retesting after substantive changes to systems supporting critical or important functions, such as a major upgrade, a topology change or a new critical topic. Confirm with the partner whether retesting is included in a retainer or quoted separately. Done means an approved test calendar and change criteria that the change board applies to every platform modification.
Questions financial entities ask before hiring help
What drives the cost of DORA resilience work for event streaming?
The main drivers are how many critical or important functions depend on streams, how many clusters and sites the design covers, how replication is built between them, and how wide the yearly continuity tests need to be. Each function adds backup scope, restoration procedures, recovery objectives and test cases. A second site with replicated topics adds capacity, networking and failover work that a single-site design does not need. Ask any partner for a quote that lists these items separately, with the functions, clusters, replication topology and test scenarios named in writing.
Which parts of DORA streaming work are one-time and which recur?
The initial build is one-time: documenting backup policies, configuring backup and restoration, setting up redundant capacity, defining recovery time and recovery point objectives per function, and running the first continuity test. Recurring work includes the yearly continuity tests that Article 11(6) requires, retesting after substantive system changes, periodic backup and restoration tests under Article 12, version upgrades and evidence refresh. Ask whether a proposal prices these categories separately, and whether ongoing support is a fixed retainer or billed per request.
How long does a DORA resilience engagement take?
Duration depends on the number of functions in scope, the state of the existing cluster, how much replication and failover design is still missing, and how quickly your teams can review and approve changes. DeployOpen does not publish durations, so the honest answer comes from a written scope. Ask the partner to show the phases, the dependencies on your change calendar, the points where your staff must act, and the test windows. Be cautious of any timeline quoted before the functions and clusters are listed.
What does the entity need to provide for a streaming resilience project?
Engagements go faster when the entity names accountable owners before work starts. Typical needs include a business owner for each critical function who sets recovery objectives, an operations owner for the clusters, a security contact for access and key management, and an approver for change windows. The work also needs access to the environment in your own accounts or data centers, test windows that do not disrupt production, and a formal change approval path for switchover tests. Confirm these roles and access in the written scope.
Can our internal platform team run DORA resilience for Kafka or Pulsar alone?
Many teams can, provided they already operate the broker in production and have capacity for documentation, testing and evidence collection. The gaps usually appear in four places: documented backup and restoration procedures that have been run end to end, redundant capacity and failover that has been exercised, recovery objectives agreed with business owners, and a continuity test that includes switchover. Ask your own team to write down who performs each test, how long they expect it to take, and which steps have never been rehearsed. That list shows whether outside help is needed for the build, for the testing, or for both.
Can DeployOpen certify that our streaming platform is DORA compliant?
No. DeployOpen plans, implements, tests and documents systems and controls, and prepares evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. DORA sets no certification scheme, and your competent authority supervises compliance using its own powers. Independent auditors and your supervisor judge whether your controls meet the requirements. A partner's role is to make the evidence complete, consistent and easy to sample, including backup policies, restoration test records, recovery objective documents and continuity test reports.
Which DORA articles should we check before scoping streaming resilience?
Start with Article 11(6) for continuity plan testing, including cyber-attack scenarios and switchovers between primary infrastructure and redundant capacity. Article 12 covers backup policies, backup systems that can be activated without jeopardizing security or data integrity, periodic restoration testing, redundant capacity, and recovery objectives set per function. Article 12(6) and (7) add checks and reconciliations during recovery. Your compliance team should confirm how these apply to your own entity type and critical functions. Read the regulation directly on EUR-Lex before fixing scope.
What tooling alone does not satisfy
A resilient streaming platform is necessary for DORA but not sufficient. The cards below cover the obligations and evidence that sit outside the broker: certification claims, third-party oversight, governance and incident reporting, and end-to-end recovery proof.
No certificate to buy
DORA sets no certification scheme, so no vendor, integrator or product can sell a DORA certificate for a streaming platform. Competent authorities supervise compliance using their Article 50 powers, and they judge the entity's own controls and records. Treat any claim of DORA certification as a warning sign. Ask instead for documented configurations, test records and evidence packs that your supervisor can review against your ICT risk framework.
Third-party risk still applies
If a managed Kafka service, a partner running your brokers, or a cloud-hosted control plane supports a critical function, the ICT third-party risk chapter applies to that provider. Expect contractual terms on audit access, incident notice, subcontracting and exit. Confirm in writing who operates brokers, who holds administrative credentials, and where backups are stored, so the register of information and exit plan reflect the real operating model.
Governance and reporting sit outside the broker
Board accountability for ICT risk, the roles that approve recovery objectives, and the process that classifies and reports major ICT-related incidents are organizational decisions. A broker cannot classify an incident or decide when to notify a supervisor. Document who owns each decision, how a stream outage reaches the incident process, and how the board receives test results and residual risk for each critical function.
A passing test is not end-to-end proof
A failover test that shows a topic is available on the secondary cluster does not show that the business process resumed within its recovery time objective. Producers, consumers, offsets, schema registry, downstream databases and reconciliation all sit on the path. Measure the full function, including checks that confirm data integrity after restoration, and record the elapsed time against each objective set for that function.
Attestation covers threat-led testing only
The only authority-issued attestation in DORA is the one confirming that a threat-led penetration test met the requirements of Article 26(7). It does not cover broker configuration, backup testing or continuity exercises. Plan the threat-led test scope with your authority's expectations in mind, and keep the continuity, backup and switchover evidence separate so each assessment can be answered from its own records.
How DeployOpen scopes and delivers DORA-ready streaming
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted streaming platforms inside the client's own infrastructure, so the resilience controls for Event streaming for DORA operational resilience are built and evidenced in the environment the institution already governs. Engagements start from a written, fixed scope that names the critical functions, recovery objectives and tests before any work begins.
How we scope
- Written scope lists each critical function that depends on streaming and its recovery objectives.
- Backup, restoration and redundant capacity requirements are mapped to the specific topics and clusters in scope.
- Switchover tests, cyber-attack scenarios and yearly test cadence are agreed as named deliverables before work starts.
How we build
- Clusters are deployed in your data centers or cloud accounts with documented backup policies and restoration procedures.
- Redundant capacity and switchover paths are configured and checked against the agreed recovery time and recovery point objectives.
- Authentication, encryption and access controls are hardened, and backup systems are verified to activate without weakening security.
How we hand over
- Runbooks cover backup scope, minimum backup frequency, restoration steps and switchover procedures for each function.
- Test records from restoration and switchover exercises are delivered as evidence for internal and supervisory review.
- Operating staff receive training and documentation so the institution can run the platform without ongoing dependency on DeployOpen.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover scheduled restoration tests, switchover exercises and patching of brokers and Java runtimes.
- Changes to systems supporting critical functions can trigger re-testing against the continuity plan under the agreed scope.
