Skip to content
PolicyForge
All posts
By Vyrhak SATH · Founder, NAGASHIELD SECURITY5 minReviewed

How to write a backup and recovery policy

A backup policy defines what you back up, how often, where, and how you test restores. Here is what to include — and a free template aligned with ISO 27001.

Why backups are an audit focus

Anyone can claim they have backups. Auditors care that you defined what is backed up, how often, where copies live, and — critically — that you test restores. An untested backup is a hope, not a control.

What to include

  1. Scope — which systems and data are in scope, by criticality.
  2. Frequency — backup cadence tied to your Recovery Point Objective (RPO).
  3. Retention — how long copies are kept, and secure deletion afterwards.
  4. The 3-2-1 rule — three copies, two media, one off-site/immutable to survive ransomware.
  5. Encryption — backups encrypted at rest and in transit.
  6. Restore testing — periodic, documented restore tests with results retained; tie to your Recovery Time Objective (RTO).
  7. Responsibilities — who runs, monitors and tests backups.

Common mistakes

  • Never testing restores until a real incident.
  • No off-site or immutable copy, so ransomware encrypts the backups too.
  • Confusing replication with backup — a replicated bad state is still bad.

Framework alignment

Maps to ISO 27001:2022 Annex A 8.13 (information backup), the SOC 2 availability criteria, and NIST CSF Recover (RC.RP).

Primary sources

Generate it in minutes

See a sample backup & recovery policy or generate yours free.

Frequently asked questions

What is the 3-2-1 backup rule?

Keep three copies of your data, on two different media, with one copy off-site or immutable. The off-site or immutable copy is what lets you survive ransomware that also targets backups. It is a practical baseline auditors recognise under ISO 27001 Annex A 8.13.

How often should you test backup restores?

Test restores periodically and document the results, not just when a real incident strikes. An untested backup is a hope, not a control. Tie restore tests to your Recovery Time Objective (RTO) so you can prove you meet it.

What is the difference between RPO and RTO?

RPO (Recovery Point Objective) is how much data loss is acceptable, which sets backup frequency. RTO (Recovery Time Objective) is how fast you must recover, which sets restore-testing targets. A backup policy should define both per system, by criticality.