ASD Essentials IT.PRO-10.2 Isolate Backup Repositories from General User Environments and Production Workloads
What it says
Isolate backup repositories from general user environments and production workloads, ensuring they are separated from primary systems to prevent unauthorised access, modification or deletion.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishKeeps backups separate from staff computers and live systems, so anyone who breaks into those cannot reach, change or delete them.
Backups are kept in a separate, protected place. Ordinary staff accounts, live business systems (production) and the admins who run them cannot get in. No system can reach its own stored backups. To meet this, only backup admins get in, using separate logins and a separate route that don't depend on the main sign-in system. The separation is tested the way an attacker would try to break it, for example from a hacked server.
Free. Save your status, tasks and notes.
Where this action applies
What's in each domain?ASD orders the work by domain: apply this action to each ticked domain, phase by phase.
- Phase 3
- Business systems
- User devices (does not apply)
Why it matters
Ransomware gangs often delete or encrypt backups before hitting the main systems. If backups can be reached from live systems or with live-system logins, one hacked account can leave nothing clean to restore and expose sensitive data.
How to implement
The backup platform owner should record an isolation design for every backup store.
Name what it must be kept apart from, such as staff networks and live systems, and the only data flows and admin routes allowed.
Infrastructure and cloud engineers should move backups off the systems they protect and their shared storage, into a separate network zone or cloud account.
Block user and production networks from reaching backup stores or their management consoles.
Backup administrators should set up jobs so protected systems can only send in new backup data.
Remove anything that would let a hacked system read, change or delete its backups, such as mapped drives, shares, saved passwords or keys.
The identity and backup teams should keep backup systems and accounts, including emergency access, off the production sign-in system.
Remove production admins, accounts used by production systems and general users from every backup role and share.
The security team should test isolation after major changes and on a risk-based schedule.
Try from a production system, a production admin, an identity admin account and a standard user, then fix and retest any path found.
Keep it running
The backup platform owner makes isolation part of adding every system to backup. Quick point-in-time copies (snapshots) kept on the same system or storage are not isolated backups. Follow ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems, then business systems. Never add production admins to backup roles for convenience. Check the isolation again after changes to the design, network or sign-in systems.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the backup design diagram and the list of backup stores and systems they protect.
Look at
Whether backup stores sit on protected systems, shared storage or a network zone shared with users or production.
Good evidence
Every backup store sits apart from production and general users, and the diagram matches reality.
- Check 2 of 5What an auditor asks for
Ask for
Request the firewall and cloud access rules for the backup network zone or account.
Look at
Whether user networks, production networks or overly broad rules can reach backup stores or their management consoles.
Good evidence
Only the set backup flows and the dedicated admin route can reach the backup stores.
- Check 3 of 5What an auditor asks for
Ask for
Request sample backup job settings, showing how each protected system sends its data.
Look at
Whether protected systems keep mapped drives, shares, saved passwords or keys that reach their stored backups.
Good evidence
No protected system can read, change or delete its backups once they are stored.
- Check 4 of 5What an auditor asks for
Ask for
Ask for every account and role with backup access, and how backup admins sign in.
Look at
Whether production admins or system accounts have access, or sign-in or emergency access uses the production sign-in system.
Good evidence
Only dedicated backup accounts, kept outside the production sign-in system, can reach backups.
- Check 5 of 5What an auditor asks for
Ask for
Request the latest isolation test, such as a penetration test, with findings and fixes.
Look at
Whether isolation was ever tested from hacked systems and accounts, and every path found was closed.
Good evidence
Documented tests confirm a hacked system or account gives no access to backups.
ASD indicators of good practice (7)
The indicators below are quoted as published from ASD's Assessment evidence guide for enterprise IT. These optional indicators help an assessor judge the action in each domain where it applies: if any not effective statement is true, the action is rated not effective; if every applicable fully effective statement is true and no other statement is, it is rated fully effective; otherwise it is rated partially effective. ASD says the indicators "do not replace expert judgement, nor are they intended to serve as a checklist".
Not effective(2)
- NE-1Backup repositories are accessible from the production environment or by production administrators.
- NE-2Compromise of a system would provide a direct path to access, modify or delete its own backups.
Partially effective(2)
- PE-1Backup repositories are logically separated but use credentials managed by the same identity platform as production.
- PE-2Isolation is implemented but has not been tested or validated.
Fully effective(3)
- FE-1Backup repositories are isolated from production environments and general user access.
- FE-2Access is controlled through credentials and administrative paths isolated from compromise of the primary identity environment.
- FE-3Isolation has been validated to confirm that compromise of a system does not provide access to backups.
Mappings
Closest match in ISO/IEC 27001: A.8.22, Network Segregation for Security, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.22.
IT.PRO-10.2 requires backup repositories to be isolated from general user environments, production workloads and primary systems to prevent unauthorised access, modification or deletion. Network segregation under Annex A 8.22 is a principal way to achieve this, making IT.PRO-10.2 a specific application of segregating a sensitive group of systems from users and other systems. Annex A 8.22 covers segregation of all groups of information services, users and information systems, while IT.PRO-10.2 addresses only backup repositories.
ASD Essential Eight: 6 mappings
This control partially overlaps E8-RB-ML1.3.
IT.PRO-10.2 requires backup repositories to be isolated from user and production environments to prevent unauthorised access, modification or deletion; E8-RB-ML1.3 requires backups to be retained in a secure and resilient manner, a broader aim that such isolation supports.
This control partially overlaps E8-RB-ML1.5.
IT.PRO-10.2 requires backup repositories to be isolated from user and production environments to prevent unauthorised access, modification or deletion; E8-RB-ML1.5 ensures unprivileged user accounts cannot access backups belonging to other user accounts, one case of preventing unauthorised access.
This control partially overlaps E8-RB-ML1.6.
IT.PRO-10.2 requires backup repositories to be isolated from user and production environments to prevent unauthorised access, modification or deletion; E8-RB-ML1.6 prevents unprivileged user accounts from modifying and deleting backups, one specific case of that protection.
This control partially overlaps E8-RB-ML3.1.
IT.PRO-10.2 requires backup repositories to be isolated from user and production environments to prevent unauthorised access, modification or deletion; E8-RB-ML3.1 ensures unprivileged user accounts cannot access even their own backups, a stricter form of that separation.
This control partially overlaps E8-RB-ML3.2.
IT.PRO-10.2 requires backup repositories to be isolated from user and production environments to prevent unauthorised access, modification or deletion; E8-RB-ML3.2 ensures privileged user accounts, except backup administrator accounts, cannot access their own backups, extending that separation to privileged users.
This control partially overlaps E8-RB-ML3.3.
IT.PRO-10.2 requires backup repositories to be isolated from user and production environments to prevent unauthorised access, modification or deletion; E8-RB-ML3.3 stops even backup administrator accounts modifying and deleting backups during their retention period, a strict form of that protection.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.