Architecture

Ransomware-Resilient Backup Architecture for SMBs

A practical reference architecture that separates production, backup control and recovery paths for small and midsize organizations.

Direct answer

Quick answer

A resilient SMB backup design uses separate administrative identities, at least one recovery copy outside the production trust boundary, and a recovery path that can operate when the normal identity provider or network is unavailable. Buying more backup capacity without separating control planes does not materially reduce ransomware blast radius.

How to frame the decision

Architecture decisions should be evaluated against shared failure domains. Geographic distance alone does not create independence when identities, management tools or deletion privileges are shared.

For this decision, document the protected service, assumed compromise, required recovery point and the maximum acceptable time to a trusted business state. Keep product capability, configured capability and tested capability as three separate fields: they are rarely identical.

What is the first low-cost control to add?

For a cloud-first organization, a separately administered backup account is often the first control worth pricing because it changes the deletion and credential path without requiring a second production platform.

  • Keep the backup account inside the organization when central guardrails and audit ownership are mature enough to protect it.
  • Apply preventive policy, dedicated recovery identities and protected retention as separate controls; an account boundary alone is not an air gap.
  • Test restore from the recovery account while normal production identity and operator endpoints are treated as unavailable.

Decision table

The following factors convert the decision into requirements that can be reviewed, tested and retained as evidence.

FactorPractical guidanceEvidence to retain
Trust boundariesPlace backup administration outside the production identity and endpoint management boundary.A diagram showing distinct identities, networks and emergency access paths.
Recovery copyMaintain an immutable or operationally offline copy with independently enforced retention.A deletion attempt from a compromised production administrator account must fail.
Recovery pathProvide clean compute, credentials and name resolution without depending on infected systems.A timed restore exercise starting from an assumed total production compromise.

Validation procedure

Run this procedure in a non-production or isolated recovery environment. Define a named owner and time limit before the test begins.

  1. Draw the actual trust and data flows before changing controls.
  2. Translate the requirement into a pass/fail test for ransomware-resilient backup architecture for smbs.
  3. Capture timestamps, logs, restored-object counts and operator actions for each decision factor.
  4. Repeat the test with one dependency unavailable so the result reflects a hostile recovery, not a clean demo.

A pass means the recovery outcome and supporting evidence meet the pre-declared requirement. A partial restore, undocumented manual workaround or result that depends on an unavailable production service should be recorded as an exception—not rounded up to a success.

Common failure modes

These conditions can make a compliant-looking design unusable during an actual recovery.

  • The backup console uses the same SSO tenant and privileged group as production.
  • All copies are reachable through one storage credential.
  • The runbook assumes Active Directory, DNS and documentation remain available.

Failure modes should become tabletop injects and technical tests. If the team has never performed the recovery while one normal dependency is unavailable, the runbook describes a best-case restore rather than a ransomware recovery.

Evidence checklist

Keep this evidence with the recovery plan so that a reviewer can distinguish a documented capability from a reproduced result.

  • Record the design decision, owner, exception and next test date.
  • A tested requirement exists for: Trust boundaries.
  • A tested requirement exists for: Recovery copy.
  • A tested requirement exists for: Recovery path.
  • Evidence includes a date, environment, operator and reproducible procedure.
  • The exception path identifies who can accept residual risk.
Editorial note. This guide separates design guidance from vendor claims. Product, licensing and regional availability must be rechecked against dated official documentation and validated in the reader’s own environment. Review cadence: review annually and after a material infrastructure change.

Frequently asked questions

These answers state the decision in plain language and preserve the conditions that can change it.

What is the cheapest meaningful ransomware backup improvement?

For many cloud environments, the first meaningful improvement is copying recovery points into a separately administered account. It changes the attacker’s required privilege path, but it only counts after deletion resistance and cross-account restore are tested.

Should the backup account be outside the AWS Organization?

Not necessarily. M.Neboke’s current preference is a dedicated high-security member account inside the same AWS Organization so central guardrails and audit ownership remain enforceable; independence must then be verified against management-account compromise.

Does a separate account create an air gap?

No. A separate account reduces shared privilege, while a logical air gap also needs protected retention, constrained sharing and a restore path that survives production compromise.