Almost nobody fails this strategy for not having backups. They fail on two requirements that sit slightly outside what a backup team traditionally measures: proving restoration has been tested, and proving that the accounts an adversary is likely to compromise cannot destroy the backups.
The second one is the whole ballgame in a ransomware scenario, and it is the requirement that tightens most sharply as maturity increases.
What Maturity Level One asks
- Backups of important data, software and configuration settings performed and retained with a frequency and retention timeframe in accordance with business continuity requirements.
- Backups synchronised to enable restoration to a common point in time.
- Backups retained in a secure and resilient manner.
- Restoration tested as part of disaster recovery exercises.
- Unprivileged accounts unable to access backups belonging to other accounts.
- Unprivileged accounts unable to modify or delete backups.
Note the first bullet ties frequency and retention to a stated business continuity requirement. "Nightly, kept 30 days" is not an answer on its own — an assessor will ask what business requirement produced those numbers, and there needs to be a document behind it.
The two that actually fail
Restoration testing
The requirement is not that restoration works. It is that restoration to a common point in time has been tested as part of disaster recovery exercises, and can be evidenced. A successful ad-hoc file recovery for a user last March is not that.
What satisfies it: a dated exercise record naming what was restored, to what point in time, how long it took, whether it succeeded, and what was learned. Run one this quarter if you have not — it is the cheapest requirement in the whole framework to close.
Backup access control
This tightens level by level, and the progression tells you exactly what it is defending against:
- Level One: unprivileged accounts cannot access, modify or delete other accounts' backups.
- Level Two: extends to privileged accounts other than backup administrators.
- Level Three: tightens further, reaching accounts' own backups and restricting deletion to break glass accounts.
Read the Level Two requirement again. It says a domain administrator should not be able to delete your backups. That is not bureaucracy — it is the single control that decides whether a full domain compromise is an expensive week or an extinction event.
Prove restoration, not just retention
GRC Copilot tracks each backup requirement with its evidence attached, including the restoration test record that most assessments find missing.
Try GRC Copilot free Generate an AI-powered assessment Download checklist Book a demo
Designing to meet it
- Separate the backup identity plane. If backup infrastructure authenticates against the same directory as production, compromise of that directory reaches the backups. This is the most common architectural failure.
- Use immutability where the platform offers it. Object lock, immutable snapshots and write-once retention satisfy the modification and deletion requirements far more convincingly than access control lists alone.
- Keep an offline or logically isolated copy. Resilient retention is explicitly required, and online-only copies share a fate with the environment.
- Back up configuration, not only data. The requirement names data, software and configuration settings. Rebuilding a domain controller from a data-only backup is not a restoration.
- Alert on backup deletion attempts. Mass deletion is a reliable early indicator of a ransomware operator preparing to detonate.
Evidence to hold
The schedule and retention configuration tied to a documented business continuity requirement; evidence of synchronisation enabling a common restore point; access control configuration on the backup system showing the account restrictions at your target level; a dated restoration test record from a disaster recovery exercise; and from Level Two, evidence the restriction extends to privileged accounts other than backup administrators.
Frequently asked questions
How often do we need to test restoration?
The model ties it to disaster recovery exercises rather than naming a frequency. Annual is the common practical interpretation, more often for critical systems. What matters is that it has demonstrably happened and been recorded.
Does cloud backup satisfy the resilience requirement?
It can, provided the copy is genuinely isolated from the compromise scenario you are defending against. A backup in the same tenancy, reachable by the same administrative credentials, is not isolated in the way that matters.
What counts as important data?
Whatever the business cannot operate without, which is a decision to make and document rather than infer. The requirement covers data, software and configuration settings — configuration is the one most often left out.
Do backup administrators keep full access at Level Two?
Yes — the requirement excludes backup administrator accounts precisely because someone must be able to manage the system. That makes those accounts high value, so they warrant MFA, monitoring and tight membership.
Key takeaways
- An untested backup does not evidence the restoration requirement, however reliable it is.
- Level Two means a domain administrator cannot delete your backups.
- Separate the backup identity plane from production, or compromise reaches both.
- Configuration and software are in scope, not just data.