Baseline Recovery of myDRE Service
1. Governance Baseline & Risk Tolerances
To ensure high availability and resilient service continuity, anDREa B.V. (hereafter referred to as "anDREa") maintains a standardized framework for the baseline recovery of the myDRE service. This configuration governs scenarios involving catastrophic disruptions, system-wide outages, or disaster events that fall outside the standard remediation boundaries of Microsoft Azure.
The baseline objectives prioritize the preservation and rapid restoration of patient/researcher workspaces and client-facing myDRE infrastructure, while non-essential administrative corporate workflows are temporarily de-prioritized to maximize operational focus.
1.1 Recovery Metrics Matrix (RTO & RPO)
The Recovery Time Objective (RTO) defines the maximum tolerable period that the myDRE platform can remain offline before causing unacceptable business or clinical impact, as codified in the Service Level Agreement and justified via the mydre CIA-AA Classification.
The Recovery Point Objective (RPO) defines the maximum allowable data currency loss in the event of a severe infrastructure compromise. While native Microsoft Azure replication protects against localized hardware or zone failures, the following matrix defines the tactical RPO boundaries in the event of cascading systemic failures:
| Core Asset Class | Specific Failure Scenario Context | Maximum Target RPO |
|---|---|---|
| myDRE Core Functionality | Azure active environments compromised; GitHub repository intact | Last verified deployment state |
| myDRE Core Functionality | Azure environments compromised; GitHub compromised; ESCROW intact | 3 months maximum |
| myDRE Core Functionality | Azure environments, GitHub, and ESCROW concurrently compromised | Unknown / Total Catastrophic Drift |
| Identity & User Data | myDRE Microsoft Entra ID compromised; Google Workspace copy and ESCROW intact | 1 week maximum |
| Identity & User Data | myDRE Entra ID compromised; Google Workspace copy compromised; ESCROW intact | 3 months maximum |
| Identity & User Data | myDRE Entra ID, Google Workspace, and ESCROW concurrently compromised | Unknown / Total Identity Drift |
| Workspace Central Storage | Azure West Europe region operational; storage account entities uncorrupted | 1 day maximum |
| Workspace Central Storage | Azure West Europe storage accounts corrupted under standard provider SLA | Unrecoverable |
| Workspace Central Storage | Azure West Europe fully compromised; backups active in secondary region | Last backup state verified by Local Research Support |
| Virtual Machines (VMs) & VM Data | VM compute uncorrupted but detached from workspace mappings | Best Effort (Re-attach to correct workspace/roles) |
| Virtual Machines (VMs) & VM Data | Storage blocks or VM compute images fully compromised | Unrecoverable |
2. Backup Strategy & Multi-Cloud Diversification
To fulfill the mandated RPO thresholds, backup schedules are strictly harmonized with technical data lifecycle requirements. Cryptographic and logical diversity are implemented across distinct infrastructure providers to prevent single points of failure.
- Source Code Configuration: Active source repositories are securely hosted within
<DocEmbedLink title="Github" doc="https://github.com/andrea-consortium">Github</DocEmbedLink>. - Legal and Technical Escrow: A snapshot of the complete production codebase is exported and transferred to the independent ESCROW Portal every 3 months.
- Identity Ledger Multi-Cloud Backups: User profiles, credential configurations, and corresponding anDREa roles from Microsoft Entra ID are exported weekly and archived securely within an isolated repository structure.
- Virtual Machine & Compute Tracking: Telemetry profiles, operational status, and metric state baselines for all active workspace VMs are regularly monitored, compiled and stored in Insights.
3. Sequential Disaster Recovery & Service Restoration Procedures
In the event of an infrastructure invocation under the Disaster Recovery Plan (DRP), the Development Team must execute restoration operations according to the following strict technical sequence:
[Isolate & Validate Core Assets]
│
▼
[Evaluate Target Azure Region (West Europe vs. Alternate)]
│
▼
[Deploy Core myDRE Code & Scripts]
│
▼
[Rebuild Entra ID & AADDS Identity Directory]
│
▼
[Re-attach Storage Accounts & Bind Workspaces/Roles]- Asset Isolation and Verification: Recover and validate the integrity of required baseline data assets, including deployment scripts, core application code, active user records, specific workspace configuration descriptions (names, users, roles), target storage account tokens, and individual workspace VM designations.
- Geographic Zone Assessment: Evaluate the stability of Microsoft Azure Region West Europe. If the primary region remains critically degraded, instantiate an isolated target environment within an alternate, uncompromised Microsoft Azure geographic region.
- Core Platform Deployment: Initiate normal automated pipeline deployment to stand up the primary myDRE system functionality in the target zone.
- Identity Directory Reconstruction: Rebuild Microsoft Entra ID and Azure Active Directory Domain Services (AADDS) schemas leveraging the latest uncorrupted weekly or escrow configuration baselines.
- Storage and Compute Re-attachment: Execute logical re-binding to attach surviving central workspace storage accounts to their corresponding restored workspace descriptions, verifying role mappings to prevent privilege escalation or data leakage.
4. Operational Controls, Redundancy, and Validation
- System Redundancy: Critical operational paths of the myDRE platform must leverage highly available architectures and geo-redundant configurations to eliminate localized single points of failure.
- Annual Verification Framework: The underlying scripts, configuration assets, and data sets required to fully execute a platform restoration must be structurally verified and tested at least annually to guarantee operational viability. Test outcomes, failure logs, and required remediation steps must be formally documented, with necessary patches applied directly to the master DRP.
- Crisis Communications: The DRP maintains an updated stakeholder communication chart and emergency contact ledger to orchestrate real-time notification updates throughout the lifecycle of an incident.
5. Roles and Governance Responsibilities
- Management Team: Holds ultimate fiduciary and governance authority for approving the baseline recovery policy, evaluating business impact analysis updates, and ensuring adequate budgetary and personnel resources are dedicated to business continuity testing.
- Development Team: Holds technical responsibility for authoring, maintaining, and testing the disaster recovery scripts, administering scheduled backup routines, verifying data integrity, and leading technical restoration maneuvers during an incident.
- All Employees: Accountable for strictly adhering to data security guidelines, avoiding unvetted architectural changes that break backup lineages, and immediately flagging any observed availability anomalies to the security team.
6. Enforcement and Policy Maintenance
- Policy Enforcement: Adherence to these baseline recovery requirements is mandatory. Non-compliance, intentional bypassing of backup controls, or failure to perform mandated validation routines may result in formal disciplinary action, up to and including termination of contractual or employment agreements.
- Review Cycle: This policy is subject to a formal review at least annually. It must be dynamically adjusted to account for structural changes in cloud infrastructure, shifting threat landscapes, or evolving regulatory mandates under ISO/IEC 27001:2023 and the EU NIS 2 Directive.