Disaster Recovery Readiness Assessment

No. The assessment is fully read-only against describe / list APIs at a controlled rate. We never trigger failover, modify replication, change DNS, restore from backup, run chaos experiments, or initiate any DR action. Every recommendation is delivered as commands and game-day plans for your team to execute on a schedule that suits you. Where your CSPM / SIEM might flag the read activity we can pre-coordinate with your detection team - but in practice the API calls look identical to a normal admin running aws backup describe-* commands.

AWS, Azure, GCP, Oracle Cloud, and hybrid / on-prem. We pull configuration and aggregate signal from AWS Backup, Backup Vault Lock, Backup Audit Manager, Resilience Hub, Elastic Disaster Recovery (DRS), AWS Fault Injection Service (FIS); Azure Backup, Azure Backup Center, Azure Site Recovery, Azure Chaos Studio; GCP Backup and DR Service, Active Assist; plus third-party Veeam, Rubrik, Cohesity, Commvault, Druva, Zerto, and chaos-engineering platforms (Gremlin, Chaos Mesh, Litmus, ChaosToolkit).

Ransomware-resistance is scored explicitly. We check whether backups are immutable (AWS Backup Vault Lock in compliance mode, Azure Backup immutable vault and soft-delete, GCP Backup and DR Service with Object Lock, Veeam Hardened Repository, Rubrik immutability, Cohesity DataLock), whether they live in a separate AWS account / Azure subscription / GCP project with break-glass access only, whether MFA-delete is enforced on backup buckets, retention vs RPO targets, cross-region / cross-cloud copies, and most importantly whether a clean-room recovery is actually rehearsed. The most common gap we find is backups that exist but cannot survive a determined ransomware actor with admin credentials.

Yes - and this is one of the most useful parts of the assessment. We map each critical service to its current backup model, replication topology, and last-measured restore time, then calculate the achievable RTO / RPO and compare it to your stated target. It is common to find 1-3 services whose stated RTO is mathematically impossible given the current architecture (e.g. a stated 1-hour RTO for a service whose database backup takes 6 hours to restore) - and the report quantifies exactly what would need to change to close the gap.

Yes. Every finding is mapped to specific controls in ISO 22301 (business continuity), NIST SP 800-34 (contingency planning), SOC 2 CC9 / A1 (system operations and availability), HIPAA Security Rule §164.308(a)(7) (Contingency Plan), PCI-DSS Requirement 12.10 (Incident Response Plan), DORA (EU Digital Operational Resilience Act), and FedRAMP CP-family controls - so the report drops directly into your compliance evidence pack and DORA register of information.

We pull restore-test evidence from AWS Backup Audit Manager, Azure Backup Center, GCP Backup and DR Service, and your backup vendor's reporting (Veeam, Rubrik, Cohesity, Commvault, Druva, Zerto), then audit cadence (annually, quarterly, monthly, automated), scope (component-level, service-level, full game-day), pass / fail rates, time-to-recover trends, and most importantly the date and result of your last successful end-to-end restore. The deliverable includes a 12-month DR test calendar with specific game-day scenarios using AWS FIS, Azure Chaos Studio, Gremlin, or Chaos Mesh.

Yes. The cost-optimisation backlog quantifies overspend across over-provisioned warm-standby fleets for non-critical services, hot replicas where Pilot Light suffices, S3 / Blob / GCS Standard backups that should be Glacier Deep Archive / Archive Tier / Coldline, untiered backup logs, missing Reserved Instance / Savings Plan / Committed Use Discount alignment for DR fleets, and cross-region replication on services whose business case does not justify it. Typical savings are 20-40% of DR spend without weakening readiness.

Typical turnaround is 5-7 business days from the moment read-only access is granted, plus a 45-minute live findings walkthrough at a time that suits your platform, security, and business-continuity leads. Larger multi-cloud estates with hundreds of services and complex regulatory drivers (DORA, FedRAMP) can take a little longer; we confirm the timeline as soon as we see the scope.