Design solutions that align with security best practices and priorities
Ransomware Resiliency and Recovery
CoreArchitect business-led resilience that protects critical assets, isolates recovery capability, constrains privileged paths, and restores trusted operations after ransomware or destructive attacks.
Aligned to SC-100 skills measured as of October 21, 2026; candidates testing earlier should review the transition note in the lane overview.
Why this matters
An architect must make recovery a security capability, not a backup procurement exercise. The design begins with business impact and ends with evidence that clean identities, infrastructure, data, and operating procedures can restore the required service.
Must Know
- Prioritize recovery tiers from business impact, dependency mapping, and credible threat paths rather than assigning one recovery target to every workload.
- Keep backup administration and recovery credentials separated from production administration, and protect recoverable copies from deletion or encryption by compromised operators.
- A resilient design combines immutable or isolated recovery points, tested restoration, clean-room procedures, and documented authority to declare a cyber recovery event.
- Ransomware mitigation gives special priority to identity control planes, privileged access, backup systems, security tooling, and other assets that attackers can use to prevent recovery.
- Security-update architecture must cover asset inventory, exposure-based prioritization, deployment rings, exception handling, rollback, and proof of remediation across all platforms.
Compare and Distinguish
- High availability keeps a service running through component failure; cyber recovery restores a trustworthy service after compromise and may require rebuilding identity and management planes.
- A replicated copy improves availability, but replication can copy corruption; an isolated and tested recovery point addresses the destructive-change requirement.
Scenario examples
- Scenario: A hospital requires patient systems within four hours but the identity tier could be compromised. Think: isolate identity and backup administration, then rehearse dependency-ordered clean recovery.
- Scenario: A manufacturer cannot patch controllers during production shifts. Think: use inventory, exposure, compensating controls, maintenance windows, and time-bounded exceptions rather than a blanket delay.
Exam traps
- More backup frequency does not provide clean recovery if the same privileged account can alter production and delete every copy.
- A vulnerability count alone cannot prioritize updates without asset criticality, exploitability, exposure, and operational constraints.
Key takeaways
- A recovery tier is a business-service decision, not a server-count ranking.
- Replication is not clean recovery; prove isolated restore points through rehearsal.
- Recover trusted identity and shared dependencies before releasing application tiers.
How it works
- Dependency mapping determines restoration order; isolated identity and backup administration prevent the original compromise from controlling recovery.
- Deployment rings expose changes gradually while health gates, rollback criteria, and compliance reporting manage update risk.
Objects and administrative surfaces
- Recovery vaults, backup policies, immutability controls, privileged roles, update rings, asset inventories, and restoration evidence.
- Business impact analysis, recovery time and point objectives, dependency maps, incident authority, and exercise records.
When to use it
- Use a cyber-recovery architecture when destructive compromise, not ordinary infrastructure failure, defines the continuity threat.
Security and governance implications
- Executives approve recovery priorities and residual risk, while service owners prove that recovery objectives and exercises remain current.
Troubleshooting signals
- If a restore succeeds but the service cannot authenticate, revisit identity, name resolution, secrets, and dependency order.
- If compliance reports show chronic patch exceptions, inspect ownership, expiration, compensating controls, and unsupported assets.
More detail
- Map business-critical assets to recovery tiers, upstream dependencies, and accountable owners.
- Design secure backup, restore, and clean-room paths for hybrid and multicloud estates.
- Evaluate update solutions by coverage, prioritization, safety, reporting, and exception lifecycle.
Ready for the quiz?
- Which identity and management dependencies must be restored before the first critical application?
- What evidence proves backups survive a compromised production administrator?
- How should exposure and rollback constraints change update sequencing?
Related objectives
- D1.1.S1 — Design a security strategy to support business resiliency goals, including identifying and prioritizing threats to business-critical assets
- D1.1.S2 — Design solutions for business continuity and disaster recovery (BCDR), including secure backup and restore for hybrid and multicloud environments
- D1.1.S3 — Design solutions for mitigating ransomware attacks, including prioritization of BCDR and privileged access
- D1.1.S4 — Evaluate solutions for security updates