Aetherize pillar
Business Continuity and Disaster Recovery
The emergency is rehearsed and the recovery time measured and documented.
Back to the overall concept
In the worst case, one number matters: how fast is the business running again? Only a rehearsed emergency plan answers that reliably. Rehearsal turns an estimated recovery time into a measured one.
DORA and NIS2 require solutions for business continuity and disaster recovery. Tested recovery plans in particular, and the drill record is your evidence toward the regulator. On top of that, attackers often encrypt the backups first, then the rest.
We turn your backup into a rehearsed recovery: immutably stored, prepared for the worst case, rehearsed and logged on a regular schedule.
What changes for you
No one can alter or delete your backups after the fact, not even an attacker with admin rights
Recovery time and acceptable data loss are measured, set per application with the business unit
The worst case is rehearsed, the record is your evidence toward auditor and regulator
If your site goes down, the second one takes over
Standard duration
4 to 10 weeks
Deployment scenarios
Implement immutable backups in a public cloud
1 week
Build the second site in a public cloud
2 weeks
Run the exercise, including preparation, writing the playbooks and exposing the weak points
2 weeks
Backups immutable, access circles separated. Your platform administrator is not your storage administrator, and not even the backup administrator can shorten retention. That way the recovery point sits before the initial infection, not just before the encryption.
02 hTarget 4 h6 h8 h
Drill Q1
6 h 12
Target missed. Cause: credentials were missing at the secondary site. Fixed, recovery order defined, noted in the record.
Drill Q3
3 h 20
Target held. Data loss 11 minutes against a 15 minute limit. The business unit signed off the restored data.
Example values from two drills. Your times are measured, not promised, and defined per application with the business unit. The first drill exposes the gap, that is what it is for. The result is the drill record, your evidence towards auditor and regulator.
When was your recovery last measured?
Book an intro call
M1: Backup
Recommended Start
Backups to a target that cannot be altered afterwards, with separate credentials decoupled from the admin
Schedules and retention per your protection needs and your deadlines
Databases included through your own mechanism
Platform state store backed up, restore verified
Restore of single applications without taking everything down
M2: Recovery and second site
Module
Recovery time and acceptable data loss per application, agreed with the business unit
Recovery as a rehearsed procedure with a log
Second site active or passive, per requirement and budget
Failover including name resolution and certificates
The way back to the first site is part of the procedure
M3: Drill and evidence
Module
Recovery drill under realistic conditions, measured and logged
Mapped to DORA Articles 11 and 12
Playbook handed over with a checklist, your team repeats it without us
Scheduled drills with us on request
Builds on the platform pillar, and also runs on your existing platform once it has passed our audit. You provide: a second site or cloud and the go-ahead for a drill in a separate environment.
Tested recovery plans
DORA Articles 11 and 12; NIS2 requires crisis management and backups.
Immutable backup, rehearsed recovery, the drill record as evidence.
Backups by protection need
DORA Article 12(1) requires the scope and frequency of backups by criticality, Section 30(2) no. 3 BSIG the backup management.
Schedule and retention follow your protection needs and your deadlines. Backups run automatically, including databases and the platform state.
Backups out of an attacker's reach
DORA Article 12(3): restoration on systems that are physically and logically separated from the source system.
The backup target cannot be altered after the fact. Its credentials are decoupled from the platform administrator.
Restoration without a full outage
DORA Article 12(2): backups must not jeopardise live operations, and their procedures are tested regularly.
Individual applications are restored while the rest keeps running. Every restoration is verified.
Measurable recovery objectives
DORA Article 12(6): recovery time and recovery point objectives per function, based on its criticality.
Recovery time and acceptable data loss are set per application, agreed with the business unit and measured in the drill.
Redundant capacity and second site
DORA Article 12(4) requires redundant ICT capacity, Article 11(6) the switchover to it as a test scenario.
Second site active or passive. The switchover including DNS and certificates is rehearsed, and the way back is part of the procedure.
Annual drill with an attack scenario
DORA Article 11(6) and (8): test annually, include a cyberattack scenario, keep records. Section 39 BSIG: operators of critical facilities provide evidence every three years.
The drill runs under realistic conditions and the record captures every step. Your team repeats it with the playbook without us.
The comparison across all pillars on the home page