DORA business continuity testing and scenarios: what to test

What DORA business continuity testing requires and what it costs to prepare

Boards and regulators now expect DORA-ready continuity tests. Article 11(6) of Regulation (EU) 2022/2554 requires ICT business continuity plans and response and recovery plans to be tested at least yearly and after substantive changes to systems supporting critical or important functions. Entities other than microenterprises must also include cyber-attack scenarios and switchovers between primary ICT infrastructure and redundant capacity, backups and facilities. The cost and effort of meeting this depend on scope: how many critical or important functions are in the business impact analysis, how many systems support each one, and how many ICT third-party services each depends on. A narrow scope with a few self-hosted platforms costs far less to test than a multi-region estate with several outsourced providers.

Ownership needs to be settled before you ask for a quote. The organization owns its continuity plans, decides the scenarios, runs the tests and signs off the results for its management body. An implementation partner can prepare the environments a test needs, such as a recovery site, backup restore targets and a switchover path for self-hosted platforms, and can document the evidence each test produces. No partner issues a DORA attestation or a test report that a supervisor accepts as an authority finding. Ask any provider to state in writing which tasks they perform, which remain with your staff, and which deliverables you receive at the end.

Separate one-time from recurring costs when you compare proposals. One-time work usually covers the initial test design, building the switchover and restore capability, and the first full test cycle. Recurring work covers the yearly test, the additional test each time a substantive change touches a critical system, staff time for scenario workshops, and remediation of deficiencies. Ask each provider to price these lines separately, to state the number of test exercises included, to name the systems and third-party services in scope, and to confirm whether a retest after remediation is included. The DORA technical standard for continuity testing, Delegated Regulation (EU) 2024/1774, sets the requirements; confirm its article references with your counsel or an independent assessor before you fix the scope.

Who is paid for what in DORA continuity testing

This table compares who pays for each part of DORA continuity testing, whether the cost is one-time or recurring, and what pushes it up or down. Use it to scope internal effort, partner work and independent review before you ask for a quote. No prices or durations are given because none are supplied in the researched facts; ask each party for a written estimate tied to your scope.

Cost component	Who is paid	One-time or recurring	Main cost drivers
Scenario design from the business impact analysis	Internal risk, business continuity and business staff	Recurring, at each annual test and after substantive changes	Number of critical or important functions, breadth of severe but plausible scenarios, including provider insolvency and political risk
Participation in tests and crisis communication drills	Internal staff time across IT, operations, communications and management	Recurring, at each test	Number of teams involved, governance and crisis communications challenges, and time away from production work
Test environments for switchover to redundant capacity	Implementation partner or internal platform engineers	One-time build, recurring upkeep	Size of the primary and redundant infrastructure, backup and facility variants, and how often the environment must mirror production
Runbooks for response and recovery plans	Implementation partner or internal documentation owners	One-time authoring, recurring revision after changes	Number of scenarios, systems covered by each plan, and frequency of substantive system changes
Testing and backup tooling	Tool vendors or open-source platform operators, paid through licences or internal operations	Mostly recurring (licences, hosting, storage)	Choice of open-source versus commercial tooling, data volumes restored in tests, and retention requirements
Provider cooperation in joint tests	ICT third-party providers, under contract terms	Recurring, if contracts require participation	Contract clauses on test rights, provider location and jurisdiction, and whether the provider charges for test support
Independent review of test results	Independent auditor or assessor, if the entity chooses one	Recurring if commissioned each cycle	Scope of review, depth of evidence sampling and whether the review covers multiple plans
Remediation of test deficiencies	Internal teams or implementation partner	Recurring, driven by test outcomes	Number and severity of deficiencies, and reporting to the management body required by the RTS

What makes DORA continuity testing larger or smaller

The size of a DORA continuity test programme follows from a handful of facts about the entity: which functions the business impact analysis marks as critical or important, how many systems and redundant sites sit behind them, how much depends on ICT third-party providers, and which regime applies. Maturity of backup and restore procedures then determines how much of that scope can be tested without disruption.

Critical or important functions in scope

Article 11(6) ties the yearly test to the systems that support critical or important functions, so the business impact analysis sets the boundary of the programme. A narrow, well-documented list of functions produces fewer scenarios and fewer systems to exercise. Check that every function in the list has a recovery time objective and a recovery point objective, and that the list is reviewed whenever the analysis changes. Scope that is defined loosely tends to grow during testing, so fix it in writing before the test calendar is set.

Number of systems and sites

Each system that supports a function in scope adds dependencies, data flows and recovery steps to the test. The number of redundant sites adds the switchover work, because Article 25(2) of Delegated Regulation (EU) 2024/1774 requires tests of switchover from primary ICT infrastructure to redundant capacity, backups and facilities for entities other than microenterprises. Inventory systems and sites together, and map which secondary site backs which primary system, so that test cases can be built from that map.

Reliance on ICT third-party providers

Article 25 requires testing that includes ICT third-party services where they apply, with provider insolvency, failure or political risk in the provider's jurisdiction considered. Each outsourced service on a critical path adds a scenario and a dependency that the entity cannot fix alone. Confirm with each provider what it will contribute to a test, what notice it needs, and whether its own continuity arrangements can be observed. Providers that cannot take part in tests widen the gap between the plan and what is proven.

Regime: microenterprise, simplified or standard

The regime sets which tests apply. Microenterprises have no switchover requirement, and entities under the simplified regime must test backup and restore at least once every year or after every major change to the plan, under Article 40 of Delegated Regulation (EU) 2024/1774. Entities on the standard regime carry the full set of scenarios and switchover tests. Confirm the regime with the competent authority's guidance and your own classification before designing the programme, because the regime determines the required test list.

Maturity of backup and restore procedures

A test can only prove recovery if backups are complete, restorable and documented. Immature procedures force the first test cycles to fix basic restore failures instead of testing the plan, which lengthens and shrinks the useful scope. Measure how long a restore takes today, whether restores have been rehearsed, and whether backup integrity is checked. Procedures that are mature and repeatable let the programme move on to switchover and cyber-attack scenarios sooner.

Change rate and substantive changes

Article 11(6) requires a test after substantive changes to systems that support critical or important functions, so a fast-changing estate triggers more tests than a stable one. Each release, migration or new provider can reopen part of the plan. Use the change management process to flag which changes are substantive and feed them into the test calendar. A high change rate is manageable when the test scope is tied to a defined list of systems rather than to the whole estate.

Which severe but plausible scenarios DORA continuity tests must challenge

DORA continuity tests must be built on the business impact analysis and run severe but plausible scenarios. Article 25 of Delegated Regulation (EU) 2024/1774 sets this rule, and it means the scenario library is not chosen from whatever is easiest to rehearse. Each scenario should trace back to a critical or important function identified in the business impact analysis, with the recovery time and recovery point objectives that function depends on. Where a function relies on ICT third-party services, the scenario must consider provider insolvency, provider failure, and political risk in the provider's jurisdiction. A practical first check is whether every third-party service that supports a critical function appears in at least one scenario. If a provider's country of operation has never been considered, the test design is incomplete.

Article 26(2) of the same regulation lists the scenarios that response and recovery plans must consider. These include cyber-attacks, failure or insolvency of ICT third-party providers, loss of premises or data centres, loss of key staff, natural disasters and pandemics, insider attacks, political instability, and widespread power outages. The list is a minimum for planning, so the test calendar should cover each category over time, not only the two or three the team finds familiar. Scenarios can be combined, for example a cyber-attack that coincides with the loss of a data centre and the absence of a key engineer, as long as the combination is documented as illustrative and tied to a plausible threat. Ask the business continuity owner to show which scenario covers each item on the Article 26(2) list and when it was last exercised.

Every test must challenge its own assumptions, and DORA's test requirements explicitly include governance and crisis communications alongside technical recovery. In practice, this means testing whether the decision-makers named in the plan can be reached, whether the escalation path works outside business hours, and whether the messages to customers, regulators and staff are drafted and approved in time. A technical failover that succeeds while the crisis team cannot agree on activation has not passed the test. Record each assumption the test relied on, such as backup restore times or staff availability, and confirm whether it held. Assumptions that failed should be analysed, fixed, and reported to the management body, as Article 25(5) requires for deficiencies.

How switchover tests and 2-hour recovery apply to each entity type

Most financial entities other than microenterprises must test whether they can move critical operations from their primary ICT infrastructure to redundant capacity, backups and facilities. Under Article 25(2) of Delegated Regulation (EU) 2024/1774, these switchover tests are a required part of business continuity testing, and every test should challenge the plan's assumptions, including governance and crisis communications. The switchover test is where a plan is proven, not just described, so the scenario needs to reflect how your environment actually fails over.

Primary to redundant capacity: Test the move from production to secondary capacity for systems supporting critical or important functions, and record the time and steps taken.
Backups and facilities: Include switchover to backup data and alternate sites, not only to a second server in the same location.
Assumption challenge: Check whether staff, runbooks, access and communications work during the switchover, not only whether the technology does.
Results and deficiencies: Document results, analyse deficiencies and report them to the management body, as Article 25(5) requires.
Provider dependencies: Where an ICT third-party service is involved, consider how its failure or insolvency would affect the switchover.

Confirm with your competent authority and your own classification whether switchover testing applies to every function in scope, and which systems count as supporting critical or important functions.

How a DORA continuity test runs from scenario to management body report

The sequence turns business impact analysis outputs into severe but plausible test scenarios, runs them including switchover, and produces documented results that the management body receives with deficiencies and remediation owners attached. Each phase closes with a named output that the next phase depends on.

Select scenarios from the business impact analysis
The continuity owner starts from the business impact analysis, which identifies critical or important functions, their dependencies and their recovery objectives. Scenarios are drawn from the Article 26(2) list of response and recovery plan scenarios, including cyber-attacks, failure or insolvency of ICT third-party providers, loss of premises or data centres, loss of key staff and widespread power outages, and are checked for severity and plausibility. Political risk in the jurisdiction of ICT third-party providers must be considered where those services apply. The step closes with a scenario register that links each scenario to the functions it tests and to the recovery time and recovery point objectives it must challenge.
Design the test and set success criteria
The test lead, with business owners and ICT operations, writes a test plan for each scenario. The plan states the scope, the systems and third parties involved, the participants, the assumptions the plan relies on, and the measurable criteria that show recovery worked, such as whether a function resumed within its recovery time objective and whether data restored to within its recovery point objective. Governance, escalation and crisis communications are included as test subjects, because all tests must challenge plan assumptions in those areas. The step closes with an approved test plan and a success criteria sheet that the people running the test can use without interpretation.
Prepare backups, redundant capacity and provider contacts
Before execution, the operations team confirms that the backups, redundant capacity and facilities named in the plan are available and in the state the plan assumes. For entities other than microenterprises, the switchover path from primary ICT infrastructure to redundant capacity is prepared and its rollback is defined. Where a scenario involves an ICT third-party provider, the team confirms how the provider will be engaged or simulated and what the exit or substitution path looks like. The step closes with a readiness checklist signed by the system owners, and any gap that could cause the test to fail for reasons unrelated to the plan is recorded and resolved first.
Execute the scenario and perform the switchover
The test is run under controlled conditions with an observer who records timings, decisions, communications and deviations from the plan as they happen. The team carries out the switchover from primary infrastructure to redundant capacity, restores from backup where the scenario calls for it, and exercises the crisis communication and escalation paths. The test lead can halt the exercise if it creates unacceptable risk to live services. The step closes with a time-stamped execution log and a record of each switchover, covering whether recovery met the stated objectives and where the plan's assumptions did not hold.
Document results and analyze deficiencies
After the exercise, the observer and system owners complete a results record for each scenario that compares actual outcomes with the success criteria. Each deficiency is analyzed for its root cause, whether that is a technical gap, an out-of-date runbook, an unrealistic assumption, unclear roles or a provider that did not perform as expected. The analysis separates findings that invalidate the plan from findings that only require adjustment. The step closes with a signed results record and a deficiency register that lists each finding, its cause, its severity and the owner responsible for addressing it.
Remediate and update the plans
Owners of each deficiency agree a corrective action with a target date, then implement it and verify the fix. Where the test showed that a plan assumption was wrong, the business continuity plan, response and recovery plans and related runbooks are updated, and the change is recorded under version control. Where a finding affects a critical or important function or a provider relationship, the change is also assessed against the testing requirement that follows a substantive change to supporting systems. The step closes with updated plans and a remediation tracker showing each finding as closed, accepted with a documented decision, or still open.
Report results to the management body
Under Article 25(5) of Delegated Regulation (EU) 2024/1774, test results must be documented, deficiencies analyzed and addressed, and the outcome reported to the management body. The continuity owner prepares a report for the board or the delegated committee that summarizes the scenarios tested, the objectives met and missed, the deficiencies found, the remediation status and any residual risk the board is asked to accept. The management body reviews and records its decision. The step closes with minuted board or committee approval of the report, which becomes part of the evidence that the continuity testing programme operates as designed.

What must be in place before the first DORA continuity test

A continuity test only tells you something if the plan it challenges is current, the recovery targets are written down, and the people and providers it depends on are ready to take part. The six items below are the preconditions a test team should verify before scheduling the first exercise.

A current business impact analysis

The business impact analysis (BIA) decides which functions are critical or important, which ICT systems support them, and how long each function can tolerate disruption. Article 25 of Delegated Regulation (EU) 2024/1774 requires tests to be based on it, so a BIA that predates your latest system changes will point the test at the wrong targets. Check that every critical or important function maps to named systems, that the dependencies match the current asset inventory, and that someone with authority has reviewed the document since the last significant change.

Documented RTO and RPO values

Recovery time objectives and recovery point objectives turn the BIA into measurable pass or fail criteria. Without them, a test can only show that something was restored, not whether it was restored fast enough or with acceptable data loss. Confirm that each critical function has a recovery time objective and a recovery point objective written in the continuity policy, that the values are consistent with the BIA, and that the test plan states how achievement will be measured.

Tested backups and restore procedures

A test that switches to a backup that has never been restored will fail for reasons unrelated to the plan. Before the first exercise, run a restore of representative data and confirm that the restored system works, that integrity checks pass, and that the time taken is recorded. For simplified-regime entities, Article 40 of Delegated Regulation (EU) 2024/1774 requires backup and restore testing at least once a year, so this check doubles as evidence. Record the date, scope and outcome of each restore.

Identified redundant capacity and facilities

Article 25(2) of Delegated Regulation (EU) 2024/1774 requires switchover tests from primary ICT infrastructure to redundant capacity, backups and facilities for entities other than microenterprises. Identify the secondary environment, its capacity, its configuration drift against production, and the steps to activate it. Confirm that the secondary site is not dependent on the same provider, network path or power supply as the primary, unless that dependency is accepted and documented as a residual risk.

Provider contracts that allow participation

Article 25 expects tests to consider ICT third-party services, including provider insolvency, failure or political risk in the provider's jurisdiction. Participation by a provider cannot be assumed. Review contracts for rights to take part in or observe tests, notice periods, data return and exit provisions, and named contacts for incidents. Where a provider will not commit to participate, record the limitation and test your own fallback for that service instead.

Named crisis communication roles

Article 25 requires tests to challenge governance and crisis communications, so the test needs named people, not job titles that someone must fill during the exercise. Assign an incident commander, a decision-maker for activation and deactivation, a communications lead for internal staff, management body and clients, and a deputy for each role. Confirm that the contact details are current, that the escalation path matches the continuity policy, and that the people listed know they are expected to take part.

Questions buyers ask about DORA continuity testing

How often must DORA business continuity plans be tested?

DORA requires ICT business continuity plans and ICT response and recovery plans to be tested at least yearly, and again after substantive changes to systems that support critical or important functions. Article 11(6) of Regulation (EU) 2022/2554 sets this floor. A yearly test is the minimum, not a target, so a major platform change, a new critical provider or a change in hosting can trigger an additional test even if the annual cycle is still open. Entities under the simplified regime follow the lighter schedule in Article 40 of Delegated Regulation (EU) 2024/1774, which focuses on backup and restore procedures. Confirm with your competent authority which regime applies to your entity before you set the calendar.

Does DORA require testing of an ICT provider failure?

Yes. Article 25 of Delegated Regulation (EU) 2024/1774 requires continuity testing based on the business impact analysis, and where ICT third-party services are involved, the tests must consider provider insolvency, failure or political risk in the provider's jurisdiction. Article 26(2) of the same regulation lists failure or insolvency of ICT third-party providers as a scenario that response and recovery plans must address. In practice, a provider scenario tests whether you can run critical functions without that provider, switch to an alternative, or restore data from an independent copy. Document the dependency, the exit route and the decision criteria before the test runs.

What does the 2-hour recovery rule mean for my firm?

The 2-hour figure in Article 24 of Delegated Regulation (EU) 2024/1774 applies to specific market infrastructures. It sets a maximum recovery time of 2 hours or less for the critical functions of central counterparties and the critical or important functions of central securities depositories, and requires trading venues to be able to resume trading within or close to 2 hours of a disruptive incident. If your entity is not a central counterparty, a central securities depository or a trading venue, this rule does not set your recovery time. Your own recovery time objectives still come from your business impact analysis and must be tested against it.

Can we run DORA continuity tests in-house?

Often yes, provided the team has the skills, independence and access to run the tests and document the results. DORA does not require an external firm for basic continuity testing. Your team must still design scenarios from the business impact analysis, include cyber-attack scenarios and switchover between primary infrastructure and redundant capacity, challenge plan assumptions including governance and crisis communications, and document deficiencies for the management body. An in-house team that also operates the systems may find it hard to test its own assumptions objectively. Some organizations use an external implementation partner to prepare the environment, scenarios and evidence, while the organization keeps ownership of the decisions and results.

What does a DORA continuity test require from the executive team?

The management body has to own the outcome. Article 25(5) of Delegated Regulation (EU) 2024/1774 requires test results to be documented, deficiencies analysed and addressed, and the results reported to the management body. Executives need to approve the scenarios that reflect severe but plausible risk, attend or receive the results of tests that involve crisis communications, and fund the remediation work that follows. Under DORA the board carries personal responsibility for ICT risk, so it should expect a clear report with each finding, its owner, its deadline and any residual risk it accepts.

Can an implementation partner certify our DORA compliance?

No. DORA sets no certification scheme, and no implementation partner can issue a DORA certificate or compliance attestation. Competent authorities supervise compliance using the powers in Article 50 of Regulation (EU) 2022/2554. The only authority-issued attestation the Regulation provides for is the attestation that a threat-led penetration test met the requirements under Article 26(7). An implementation partner can prepare systems, plans, test scenarios and evidence. Your organization owns its controls and its reporting to the supervisor, and the supervisor decides whether those controls meet DORA.

What drives the cost and effort of DORA continuity testing?

The main drivers are the number of critical or important functions in scope, how many ICT third-party services those functions depend on, how many redundant sites or backup targets must be exercised, and how often systems change. Each test has a one-time setup cost for scenarios, environments and runbooks, and a recurring cost for each annual run, remediation and the report to the management body. Ask any provider for a fixed-scope quote that lists the systems covered, the scenarios tested, the environments used, who runs each test, what evidence is delivered and what happens if a test finds a deficiency that needs a retest. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and quotes follow from that written scope.

Which DORA scenarios must a continuity test cover?

Article 26(2) of Delegated Regulation (EU) 2024/1774 lists the scenarios that response and recovery plans must consider. They include cyber-attacks, failure or insolvency of ICT third-party providers, loss of premises or data centres, loss of key staff, natural disasters and pandemics, insider attacks, political instability and widespread power outages. Not every scenario needs its own exercise each year, but each must be assessed and tied to the business impact analysis. Confirm with your supervisor how they expect the scenarios to be selected and documented.

Why DORA continuity tests stall or produce weak evidence

Most DORA continuity programs fail on the same few points: the scenarios are too narrow, the tests stop at backup restore, and the results never reach the management body. Each card below names one gap, what an assessor will look for, and what to check before the next test cycle.

Provider failure left untested

Article 25 of Delegated Regulation (EU) 2024/1774 expects tests to include ICT third-party services where applicable, with provider insolvency, failure or political risk in the provider's jurisdiction considered. Many plans assume the cloud or SaaS vendor will simply recover. Check that at least one test removes a critical provider from the runbook, measures how long the function stays down, and confirms that an exit or alternative path exists in writing.

Backup restore mistaken for switchover

Restoring a backup proves data can come back, but it does not prove that services can run on redundant capacity. For entities other than microenterprises, the tests must cover switchover from primary ICT infrastructure to redundant capacity, backups and facilities. Check that each test records the time to move workloads, the state of data at the point of switch, and whether the redundant site handled real production load.

Management body left out of results

Test results must be documented, deficiencies analysed and addressed, and the findings reported to the management body. A test that closes with an internal ticket and no board paper will not satisfy this. Check that every test has a dated results record, a list of deficiencies with owners and deadlines, and a minute or briefing showing the management body received and reviewed them.

Business impact analysis out of date

Tests are only meaningful if they start from the current business impact analysis, which drives the recovery objectives and the critical functions in scope. Systems added, retired or re-hosted since the last review can make a passing test irrelevant. Check that the BIA is refreshed before each test, that test scenarios trace back to named critical functions, and that recovery time and recovery point objectives match what the test measured.

Crisis communications never tested

The Delegated Regulation requires all tests to challenge plan assumptions, including governance and crisis communications. Many exercises focus on technical recovery and skip who decides, who informs clients and regulators, and how staff are reached when primary channels are down. Check that each exercise includes an escalation step, a communication decision with timestamps, and a review of whether the contact list works without the corporate network.

Scenario list too narrow

Article 26(2) of the Delegated Regulation lists scenarios that response and recovery plans must consider, including cyber-attacks, loss of premises or data centres, loss of key staff, insider attacks and widespread power outages. Test programs that repeat one familiar outage each year leave most listed scenarios unexercised. Check that the scenario register covers every item on the list, with a documented reason for any scenario not tested in a given year.

What may change before the 2028 DORA review

The main scheduled change point is the Commission review required by Article 58(1) of DORA, which must be reported to the European Parliament and the Council by 17 January 2028. That review covers, among other things, the criteria for designating critical ICT third-party providers and the voluntary nature of significant cyber threat notification. Continuity testing is not the headline topic of that review, but a financial entity should still plan for the possibility that supervisory expectations on testing evolve as the Commission and the European Supervisory Authorities gather experience with how the regime works in practice.

A nearer proposal is the Commission's Digital Omnibus, COM(2025) 837, dated 19 November 2025. It would amend Article 19 of DORA so that major incident reports and voluntary threat notifications pass through a single entry point under NIS2. The procedure, 2025/0360(COD), is listed by the European Parliament's Legislative Observatory as awaiting committee decision. For continuity planning, the practical question is whether your incident reporting chain, and the crisis communications steps your business continuity plan rehearses, still point to the right channels if the entry point changes. Test the reporting path as part of your scenario exercises so that a change in routing does not become a gap during a live disruption.

The proposal does not, on the current text, target the testing obligations in Article 11(6) or Article 25 of Delegated Regulation (EU) 2024/1774, including the yearly test, the switchover tests and the reporting of results to the management body. Do not treat that as a permanent guarantee. Ask your competent authority which requirements it expects you to meet now, whether it has issued supervisory guidance on continuity testing, and how it will communicate any change to reporting channels. Keep a dated record of those answers and review the procedure status at each annual test cycle, so the plan you are testing against is the one the regulator currently applies.

Who owns DORA continuity tests and who prepares the evidence

The financial entity owns its ICT business continuity plans, response and recovery plans, test scenarios and the decisions that follow from test results. Article 11(6) of DORA places the duty to test on the entity itself, and the management body remains accountable for approving the plans and receiving reports on what the tests found. An outside firm cannot take over these decisions, and an entity cannot delegate its accountability for them to a supplier.

Plans and scenarios: The entity sets the business impact analysis inputs, recovery time and recovery point objectives, and the severe but plausible scenarios that each test must challenge.
Test decisions: Staff with authority decide which switchovers to primary infrastructure, backups and facilities are run, when cyber-attack and provider-failure scenarios are tested, and whether a test may disrupt production.
Results and deficiencies: The entity documents results, analyses deficiencies, assigns remediation owners and reports to the management body as required by the regulatory technical standard.
Management body reporting: Board or committee minutes should show that the plans were reviewed, tests were challenged and open deficiencies were accepted or closed.

Ask internally who holds each of these decisions in writing before any external work starts.

How DeployOpen prepares self-hosted systems for DORA continuity tests

DeployOpen's role in a DORA continuity test starts with a written scope. Before work begins, we agree which self-hosted open-source platforms, which critical or important functions they support, and which tests are in scope, such as backup and restore, switchover from primary ICT infrastructure to redundant capacity, and failover after a simulated provider failure. The organization keeps ownership of its business impact analysis, its severe but plausible scenarios, its recovery time and recovery point objectives, and its decisions on when a test counts as passed. We prepare the systems and the evidence so those decisions can be made on facts.

In the client's own cloud accounts, data centers or air-gapped networks, we implement and harden the platforms, then configure the backup, restore and switchover paths they depend on. That usually means scheduled backups with documented retention, restore runbooks that a named team can execute without the original builders, and redundant environments whose activation steps are written down. Each test run produces a dated record of what was attempted, what the measured recovery time was, and which assumptions in the plan were challenged. Anything that failed is logged so it can be analysed, addressed and reported to the management body, as Article 25(5) of Delegated Regulation (EU) 2024/1774 requires. Confirm with your own assessors which log formats and sign-off steps they expect.

DeployOpen supports test execution and hands over documented evidence, but it does not issue audit reports, attestations or certificates. Those come only from the organization's own governance and, where applicable, from the competent authority or an independent assessor. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and DeployOpen does not publish a price list, so a quote follows from that written scope. Ask any implementation partner to state in the scope which tests it will run, which it will only observe, and which remain with your internal teams or your ICT providers.

DORA business continuity testing and scenarios