How ISO 27001, DORA, and NIS2 Are Forcing a Fundamental Rethink of AWS Backup Strategies
TL/DR for Decision Makers:
- ISO 27001, DORA, and NIS2 mandate geographic separation AND account isolation — Multi-AZ alone doesn’t cut it
- Multi-AZ protects against hardware failure, NOT ransomware (Jaguar Land Rover: £1.9 billion damage)
- CACR = Compliance + Ransomware Protection in one solution (Cost: ~$10-15/month for 100GB database)
- Recovery Time: <Hours vs. 2.5 months production downtime (JLR)
Reading time: 8 minutes
The New Compliance Reality
On September 1, 2025, Jaguar Land Rover was forced to shut down all global production facilities. Not because of a hardware failure. Not because of a natural disaster. But because their traditional disaster recovery architecture couldn’t protect them against compromised credentials.
The result: £1.9 billion in damages — the first cyber-bailout in England in history.
For executives navigating the increasingly complex landscape of digital operational resilience regulations, this incident reveals an uncomfortable truth: traditional high-availability solutions are not security controls.
Regulatory Requirements Have Changed
Three major compliance frameworks now explicitly require architectural decisions that go beyond conventional disaster recovery:
DORA (Digital Operational Resilience Act) — Articles 11-12:
- Mandatory geographic separation of backup locations
- Point-in-time recovery capabilities
- Documented and tested recovery procedures
- Enforcement: January 2025 for EU financial institutions
ISO 27001:2022 — Updated Controls:
- A.5.30: ICT Readiness for Business Continuity
- A.8.13: Information Backup (regularly tested)
- A.8.14: Redundancy of Processing Facilities
- Geographic diversity explicitly mentioned
NIS2 Directive (EU) — Article 21:
- “Multi-layered” cybersecurity approach
- Backup and disaster recovery as essential operators
- Penalties: Up to €10M or 2% of global annual turnover
KRITIS/BSI (Germany):
- Account isolation as core requirement for critical infrastructure
- Immutable backup storage mandated
The common thread: Geographic redundancy without account isolation is insufficient.
Why Multi-AZ Is Not a Security Control
Multi-AZ Same Account Same Blast Radius Diagram
Caption: Multi-AZ replicates infrastructure — and attacker access
The Uncomfortable Problem
Multi-AZ deployments excel at infrastructure resilience. But they fail catastrophically when credentials are compromised:
| Multi-AZ Protects Against: | Multi-AZ Does NOT Protect Against: |
|---|---|
| Hardware failure in one AZ | Compromised AWS credentials |
| Network outage in one AZ | Ransomware with admin access |
| Local natural disaster | Malicious insider threats |
| Power outage in one datacenter | AWS account suspension/compromise |
| Maintenance windows | Supply chain attacks on CI/CD |
| Sophisticated APT with persistence | |
| Regional AWS service outages |
The Jaguar Land Rover Case Study: When Multi-AZ Failed
The Timeline:
- Day 0 (August 31, 2025): Vishing campaign successfully bypasses MFA through social engineering
- Day 1 (September 1): All production facilities worldwide shut down (UK, Slovakia, India, Brazil, China)
- Week 5 (October 8): Controlled restart begins
- Week 11 (Mid-November): Normal production finally resumed
The Damage:
- Direct loss: £50 million per week
- Total economic impact: £1.9 billion
- Jobs at risk: 120,000-200,000 across supply chain
- Government bailout: £1.5 billion (unprecedented for cyber incident)
The Attack Path:
- Initial Access: 4-year-old credentials from Jira (third-party with JLR access)
- Lateral Movement: Active Directory ? SAP NetWeaver ? Production systems
- Defense Evasion: Clear Event Logs (wevtutil) + Delete all local backups (vssadmin)
- Impact: Ransomware deployed across all regions and availability zones simultaneously
The Question Regulators Will Ask:
“Could you have prevented this damage with appropriate technical measures such as account isolation?”
The answer — and the liability — lies in your architecture.
This is just one example out of many happened recent past time!
Cross-Account Cross-Region as Compliance Enabler
Enhanced Cold Pilot Strategy
How CACR Fulfills Three Compliance Requirements Simultaneously
1. Geographic Separation (DORA Art. 11)
Production Region: eu-central-1 (Frankfurt) (f.i.)
DR Region: eu-west-1 (Ireland) (f.i.)
Distance: ~1,200 km
Compliance met: “Geographic diversity of backup locations”
2. Account Isolation (ISO 27001 A.5.30)
Production Account: 123456789123 (separate AWS account)
DR Account: 234567890199 (separate credentials, separate IAM)
Compliance met: “Redundancy of processing facilities” with separate security perimeter
3. Immutable Backups (NIS2 Art. 21)
DR Vault: AWS Backup Vault Lock enabled (compliance mode)
Retention: 30 days (allowing forensic analysis)
Delete Protection: Cannot be deleted even with Production admin access
Compliance met: “Multi-layered cybersecurity approach”
The Critical Difference During an Attack
| Traditional DR (Single Account): | CACR (Cross-Account): |
|---|---|
| Attacker obtains Production Admin credentials ? Access to: Production + Backups + Replicas ? Blast Radius: 100% of infrastructure ? | Attacker obtains Production Admin credentials ? Access to: ONLY Production Account ? NO Access to: DR Account (separate credentials) ? Blast Radius: ~50% — DR remains secure ? |
| Result: Complete compromise (JLR scenario) | Result: Business continuity maintained |
CACR Compliance Matrix – ISO 27001, DORA, NIS2, KRITIS
Caption: 12/12 Compliance Requirements Fulfilled
Technical Implementation: Proof of Concept
Code Snippet: Cross-Account Backup Plan
Here’s how CACR is implemented using Infrastructure as Code (Terraform excerpt):
Note: Production-grade Terraform modules with complete error handling, monitoring, and multi-region support available upon request.
Implementation Reality Check
We built a proof-of-concept CACR architecture for a production-like system (web server + Aurora PostgreSQL). Results:
Key Metrics:
- Setup Time: ~40 hours engineering effort (Infrastructure as Code)
- Recovery Time Objective (RTO): 22 minutes (measured in testing)
- Recovery Point Objective (RPO): 24 hours (daily backups)
- Terraform Codebase: ~2,000 lines (modular, reusable)
- Monthly Cost: $12-15 for 100GB Aurora database
What Works (and What Doesn’t):
- Multi-AZ RDS Instances: AWS Backup cross-account copy works out-of-the-box
- Multi-AZ Clusters: Requires Lambda + EventBridge orchestration (AWS limitation as of Nov 2025)
- Encrypted Databases: KMS key sharing handled automatically
- Automated Testing: Restore tests via terraform apply
AWS Backup Recovery Points in DR Account Ireland
Caption: Recovery Points Successfully Replicated to DR Account (Ireland)
The Business Case: Cost vs. Catastrophe
Cost Reality Check
| Component | Monthly Cost (100GB Aurora) |
|---|---|
| Daily snapshots in Production | ~$3-5 |
| Cross-region copy to DR account | ~$5-9 |
| Vault storage in DR account | ~$2-3 |
| Total CACR Overhead | ~$10-15/month |
| Annual Cost | ~$120-180 |
ROI Calculation
If CACR prevents even one ransomware attack:
| JLR Scenario (without CACR): Production downtime: 2.5 months Direct loss: £50M/week × 11 = £550M Supply chain damages: £1.4 billion Government bailout: £1.5 billion Total impact: £1.9 billion | With CACR: RTO: <Hours RPO: 24 hours Annual costs: acceptable Production downtime: Avoided Forensic capability: Preserved |
Break-Even Point: First prevented incident
Compliance as Competitive Advantage
Beyond risk mitigation, CACR implementation delivers measurable business benefits:
- Faster Audits: DORA/NIS2-ready architecture accelerates certification
- Reduced Insurance Premiums: Cyber insurance recognizes account isolation
- Customer Trust: B2B customers increasingly require supplier resilience audits
- M&A Due Diligence: Strong DR posture increases company valuation
Getting Started: Implementation Roadmap
Phase 1: Assessment (Week 1)
- Inventory current backup strategy
- Map compliance requirements (DORA/NIS2/ISO 27001)
- Identify critical databases requiring CACR
- Calculate current RTO/RPO vs. business requirements
Phase 2: DR Account Setup (Week 2)
- Create dedicated DR AWS account via Organizations
- Configure KMS keys with cross-account access
- Deploy DR backup vaults with Vault Lock
- Establish networking (VPC, subnets, security groups)
Phase 3: Backup Automation (Week 3-4)
- Implement Terraform modules for backup plans
- Configure cross-account IAM roles and policies
- Set up EventBridge rules (if using Multi-AZ Clusters)
- Deploy Lambda functions for automated copy jobs
Phase 4: Recovery Testing (Week 5-6)
- Perform test restore in DR account
- Measure actual RTO/RPO
- Document recovery procedures
- Train operations team on DR execution
Phase 5: Continuous Improvement (Ongoing)
- Quarterly DR drills
- Review CloudTrail logs for anomalies
- Update compliance documentation
- Optimize costs (retention policies, storage classes)
Conclusion: Compliance Drives Architecture
The shift toward account-isolated disaster recovery isn’t just about checking compliance boxes — it’s about building architectures that can survive the modern threat landscape.
Key Takeaways:
- Multi-AZ ? Security Control — Geographic redundancy without account isolation is insufficient
- Compliance Frameworks Are Converging — ISO 27001, DORA, NIS2 all mandate separation
- Cost is Negligible — $10-15/month to prevent £1.9 billion scenarios
- Recovery Speed Matters — 30 minutes vs. 2.5 months changes everything
- Forensics Capability is Critical — Clean recovery requires preserved evidence
The question isn’t whether to implement CACR, but whether you can afford not to.
Take Action: Is Your AWS Infrastructure DORA/NIS2-Ready?
Free Discovery Session
Let’s assess your current disaster recovery posture:
- Gap analysis of your AWS backup strategy
- Compliance mapping (ISO 27001/DORA/NIS2/KRITIS)
- ROI calculation for CACR implementation
- Custom architecture recommendations
Downloadable Resources
| Attack Path Analysis with Amazon Athena Complete guide to forensic CloudTrail analysis for incident investigation Request Access | Terraform State Management Advanced patterns for multi-account Infrastructure as Code Request Access | DORA/NIS2 Compliance Mapping Detailed requirement-by-requirement assessment template Request Access |
These resources are available after a brief introduction call to ensure relevance to your specific requirements.
About the Author
Kenneth Hede is a Senior IT Infrastructure & Cloud Architect specializing in AWS disaster recovery, business continuity management, and compliance frameworks (ISO 27001, DORA, NIS2). With over 20 years of enterprise-scale experience and certifications including AWS Solutions Architect Associate and HashiCorp Terraform Associate, Kenneth helps organizations build resilient, compliant cloud architectures.
IT-Consulting Kenneth Hede
AWS Cloud Architecture | Disaster Recovery | Infrastructure as Code
kenneth-he.de | LinkedIn
Tags: AWS Disaster Recovery, DORA Compliance, NIS2, ISO 27001, Cross-Account Backup, Ransomware Protection, Infrastructure as Code, Terraform, Business Continuity, Cloud Architecture
Last Updated: February 3, 2026
No responses yet