Run c52cbd1d-de1c-45fb-bd0b-a911ac7abaa8

[PERSON_001] Disaster Recovery Test Report Backup Restore Validation and Production Migration Microsoft Azure to OVHcloud Organization [PERSON_002]. Exercise period [DATE_001] - [DATE_002] Actual recovery validation [DATE_002] Document version 1.0 Classification Confidential - ISMS record Overall result PASS Recovery objectives achieved: RTO approximately 1 hour | RPO 0 (no data loss) 1. Purpose and objective This report records the execution and outcome of [PERSON_002].'s [DATE_003] disaster recovery exercise. The exercise was initiated on [DATE_001] and concluded with an actual backup restore and production migration on [DATE_002]. The purpose was to validate that [PERSON_001] can recover its critical platform and data from backup within the recovery objectives defined for critical systems. Rather than relying only on a simulated or tabletop scenario, the recovery capability was validated during a real infrastructure migration from Microsoft Azure to OVHcloud. The migration therefore provided practical evidence of backup availability, restore capability, data integrity, technical recovery and functional operation. 2. Scope [PERSON_001] production database and associated application data. Backup and restore capability from the Microsoft Azure environment. Recovery into the new OVHcloud environment, first to staging and subsequently to production. Technical operation of the database, infrastructure and relevant services after recovery. Functional operation of the [PERSON_001] platform after recovery. Verification workflow and Sumsub integration after production cutover. Validation against [PERSON_001]'s recovery objectives: RTO <= 24 hours and RPO <= 24 hours. 3. Roles and responsibilities [PERSON_003] [PERSON_002]. - ISMS Manager / Test Owner; coordination, business validation and formal acceptance. [PERSON_004] [PERSON_005] - [ORGANIZATION_001]; technical restore, migration, infrastructure validation and technical confirmation. 4. Recovery objectives and acceptance criteria Metric Target Observed Result RTO <= 24 hours Approximately 1 hour PASS RPO <= 24 hours 0 - no data loss identified PASS Data integrity Recovered data available and usable Confirmed PASS Platform operation Core functions operational Confirmed PASS 5. Exercise timeline 5.1 Phase 1 - Initiation and preparation, [DATE_001] The disaster recovery exercise commenced on [DATE_001]. This phase covered the start of the recovery test, preparation of the recovery approach and review of the backup/restore process in advance of the planned infrastructure migration. 5.2 Phase 2 - Actual recovery validation, [DATE_002] On [DATE_002], the recovery procedure was executed as part of the planned production migration from Microsoft Azure to OVHcloud. The migration, temporary service unavailability and technical activities were planned, coordinated between [PERSON_001] and [PERSON_005], and communicated in advance to the relevant stakeholders. 6. Recovery execution Step Activity Outcome 1 Backup selection The most recent available backup created immediately prior to the migration was selected for recovery. [PERSON_006] exact backup timestamp was not separately recorded in this report. 2 Restore to staging [PERSON_005] restored the backup into the OVHcloud staging environment. 3 Staging validation The recovered environment and data were checked before production cutover. 4 Production cutover Following successful staging validation, the environment was moved to the OVHcloud production environment. 5 Technical validation [PERSON_005] confirmed that the database, infrastructure and relevant services were operational and stable after cutover. 6 Functional validation [PERSON_001] confirmed that the platform was accessible, existing data was present and usable, and core platform functionality operated correctly. 7 Integration validation A new verification was performed and the Sumsub integration and processing of the verification/result operated correctly. 7. Validation results Control / validation Result Evidence / observation Azure backup availability reviewed PASS Supporting Azure evidence demonstrates completed automated backups and configured retention. Backup restored to OVHcloud staging PASS Actual restore performed by [PERSON_005] as part of the migration. Staging environment validated PASS Recovered environment validated before production cutover. Production environment operational PASS [PERSON_001] successfully went live on OVHcloud. Existing customers/accounts/data available PASS Existing information was checked and remained available and accessible. Data loss PASS No data loss was identified. Observed RPO: 0. Platform access and core functionality PASS Platform operated correctly after recovery. New verification PASS A new verification was executed successfully. Sumsub integration PASS Integration and result processing operated correctly. Technical stability PASS [PERSON_005] confirmed database, infrastructure and services were stable. Recovery time PASS Total staging restore, validation and production cutover completed in approximately 1 hour. 8. Availability and recovery performance The production migration required approximately one hour of planned service unavailability. This period was planned, coordinated and communicated in advance. After approximately one hour, [PERSON_001] was fully operational in the OVHcloud production environment. Target RTO <= 24 hours Observed RTO Approximately 1 hour Target RPO <= 24 hours Observed RPO 0 - no data loss identified Planned unavailability Approximately 1 hour Recovery objective result PASS 9. Deviations, incidents and improvements No errors, incidents, unexpected recovery issues or deviations were identified during the exercise or production migration. No corrective actions or specific improvement actions were considered necessary as a direct result of this exercise. 10. Evidence The ISMS evidence package for this exercise consists of this signed report and the separately archived Azure backup evidence. The Azure evidence supports the availability and successful completion of automated backups. It does not, by itself, evidence the restore performed on [DATE_002]. The actual restore, migration, technical validation and functional validation are recorded in this report and are formally attested by the [PERSON_001] and [PERSON_005] signatories. Supporting evidence file: [PATIENT_ID_001] [PERSON_001] Disaster Recover Backup Azure.pdf. The screenshot shows the Azure Database for PostgreSQL backup and restore view, including completed automated backups and backup retention information. Because the screenshot was captured before the final migration date, it is treated as supporting evidence of the backup process rather than evidence of the specific [DATE_004] restore. 11. Overall conclusion OVERALL RESULT: PASS The [DATE_003] disaster recovery exercise successfully demonstrated [PERSON_002].'s ability to recover its critical platform and data from backup and resume operations within the defined recovery objectives. A real backup restore was completed as part of the Microsoft Azure to OVHcloud migration. Recovery was first validated in staging and then moved to production. No data loss was identified, the platform and integration functionality operated correctly, and the total recovery/cutover period was approximately one hour. [PERSON_007] RTO and RPO objectives were therefore achieved. 12. Formal sign-off By signing below, the undersigned confirm that the recovery activities and results described in this report accurately reflect the disaster recovery exercise and production migration performed in [DATE_003]. [PERSON_002]. [PERSON_005] [PERSON_003] [PERSON_004] [PROFESSION_001] Manager / Test Owner [ORGANIZATION_001] Signature: __________________________ Signature: __________________________ Date: ______________________________ Date: ______________________________ Document control note Store the signed final version of this report together with the supporting Azure backup evidence in [PERSON_001]'s ISMS archive. This document records the actual outcome of the exercise and should not be altered after sign-off except through controlled versioning. [PERSON_002]. | ISMS RECORD Confidential - ISO/IEC 27001:2022 evidence