ISO/IEC 27001:2022 · derived mapping target
A.8.13Information backup
Take regular backups of information, software and systems, and test that they can actually be restored. A backup you have never tested may not work when you need it.
Mapping at a glance
A.8.13Information backupISO/IEC 27001:2022
A.8.13 is covered by 13 Sekit CSF controls. +8 more in the table below. Open in the full graph →
Mapped from the Sekit CSF
The Sekit controls that cover this requirement, lens by lens.
RCF-0238Backup policy · PolicysupportsA.8.13 asks for backups that are taken and proven restorable. RCF-0238 is the policy leg: it sets scope, frequency, retention, and the restore-test cadence that the technical controls then execute.RCF-0239Backup policy · ProcesssupportsThe backup process facet executes backups on schedule and investigates every failed or missing run, the operational discipline A.8.13 requires beyond a written policy.RCF-0240Backup policy · TechnicalsupportsRCF-0240 covers the running backup tooling: scheduled jobs, protected copies, and executed restore tests. That is the operational core of A.8.13, which treats an untested backup as no backup.RCF-0241Immutable/offsite backups · PolicysupportsThe immutable-backup policy facet requires at least one copy to sit offsite or in storage attackers cannot alter, directly addressing A.8.13's expectation that ransomware cannot destroy every copy.RCF-0242Immutable/offsite backups · ProcesssupportsThe process facet keeps that offsite or tamper-proof copy verified in place through routine operational checks, so A.8.13's protection requirement holds up between audits.RCF-0243Immutable/offsite backups · TechnicalenablesThe technical facet enables write-once backup storage and replication to a separate location, the enforcement mechanism behind A.8.13's offsite protection requirement.RCF-0244Backup coverage · PolicysupportsThe backup coverage policy facet states in writing which systems and data are critical, requiring all of them inside the backup programme A.8.13 expects to be comprehensive.RCF-0245Backup coverage · ProcesssupportsThe process facet reviews backup scope on a recurring basis, confirming that no critical system has drifted out of the coverage A.8.13's policy leg committed to.RCF-0246Backup coverage · TechnicalenablesThe technical facet enables per-system backup reporting and alerts when a critical system falls out of scope, so A.8.13's coverage requirement is checked automatically rather than assumed.RCF-0247Restore testing · PolicysupportsThe restore-testing policy facet requires backups to be tested on a defined schedule with documented results, the written commitment that makes A.8.13's restore requirement enforceable.RCF-0248Restore testing · ProcesssupportsThe process facet runs real restores on schedule and records whether each recovery worked, the proof A.8.13 treats as the point of having backups at all.RCF-0249Restore testing · TechnicalenablesThe technical facet enables automated restore verification that checks recovered data for integrity without manual effort, the automation A.8.13's testing requirement benefits from at scale.RCF-0255DR exercises · TechnicalrelatedThe DR-exercise technical facet lets recovery be rehearsed in an isolated environment without touching production, a related capability that extends A.8.13's restore testing into full disaster recovery drills.
NIST CSF 2.0 counterparts
Reached through the Sekit CSF controls both map to — a mapping, not a formal equivalence.
Evidence that proves this control
What an auditor, or Sekit's evidence engine, asks for.
Backup configuration and restore-test record
How backups are made (what is backed up, how often, where they are stored) and the proof that a restore has been tested successfully.
From the Sekit evidence catalog
In practice
Most small organizations pass the backup question and fail the restore. The pattern that works: automate the backup, keep one protected copy off-site or in a separate tenant, and put a restore drill on the calendar. Quarterly is enough for most SMEs. Ransomware crews target backups first, so the protected copy matters as much as the schedule. Auditors rarely ask to see the backup itself; they ask when you last restored one, how long it took, and what failed.
Common gaps
Backups run on schedule, but no restore has ever been tested. The first real restoration attempt happens during an incident, which is the worst possible moment to discover it fails.
Retention and scope are undefined: nobody can say which systems are covered, for how long, or whether the copy survives a ransomware attack on the primary environment.
Questions your auditor will ask
When did you last restore from backup, and is the result documented?
The most recent restore test ran last quarter, logged in the backup configuration and restore-test record with the system restored, duration, and outcome.
Which systems are excluded from the backup scope, and who approved those exclusions?
The backup coverage review lists every excluded system with a named business owner who signed off on the exclusion and the reason for it.
How is at least one backup copy protected from the same ransomware that could hit production?
At least one copy is stored offsite or in immutable, write-once storage that production credentials cannot delete or modify.
Where regulation demands it
NIS2 Article 21(2)(c) names backup management explicitly among required business continuity measures. ENS op.cont controls expect the same discipline from Spanish public-sector suppliers.
Related controls
Via the shared Sekit CSF topic, not the framework's own index.
Ask Sekura: “What evidence proves A.8.13?”
Also via MCP, free with account