ISM-1511 · September 2026
Performing and retaining backups
Guidelines for system management / Data backup and restoration / Performing and retaining backups
Official control wording
Backups of data, applications and settings are performed and retained in accordance with business criticality and business continuity requirements.
Applicability
These are ASD’s applicability markings. Select and tailor controls for your system’s risk, classification and operating context with the system owner and authorising officer.
ASD Essential Eight applicability: ML1 · ML2 · ML3. A profile marking does not establish maturity attainment.
// Latticework implementation guidance · partial coverage
Connect declared backup coverage to a tested recovery
Practical suggestions for a Kubernetes or cloud system. Adapt these steps to your architecture and approved system boundary.
Implementation steps
- Identify application data, configuration and settings, including state outside PersistentVolumeClaims. Agree recovery and retention requirements with business owners.
- Declare production PVC backup coverage and configure the backup service. Perform a representative restore and verify application recovery before relying on the backup.
Evidence to retain
- Keep the data inventory, approved retention/recovery requirements, backup configuration and dated completion records.
- Record restore-test steps, recovered data checks and recovery time. Add backup isolation and access evidence separately; a PVC label proves none of these.
What the mapped checks can establish
PolicyReports show whether production PVCs declare backup coverage; they do not prove backup completion, retention, resilience or restorability.
Responsibility boundary
Platform team: backup service and protected storage. Workload team: data consistency and restore validation. Organisation: continuity requirements, retention and test acceptance.
The public mapping’s detector allocation is provisional for both managed and self-managed clusters. Agree the responsibility matrix for the engagement; provider inheritance and whole-control ownership require a reviewed system boundary and applicable customer/provider evidence.
Mapped checks to inspect
- kyverno: ism-backups-require-pvc-backup-label
These identifiers are from the pinned public mapping. Kyverno mappings describe the policy configuration you must inspect; they do not mean a policy is installed or enforcing. A manifest scan cannot establish live runtime behaviour. Record the exact tool, policy and framework versions, settings, exclusions and execution time with each result.
Review the mapping and control-specific limitations at revision 07b348a. Supporting mapping excerpts (checks, evidence notes and responsibility allocations) are adapted from Latticework Systems’ public repository under Apache-2.0. ASD’s control wording stays under CC BY 4.0.
Official source
ASD’s ISM OSCAL v2026.09.4 · Original catalogue JSON · Pinned checksums and edition details
Control source identifier: ism-1511. Check the official release before relying on this snapshot for an assessment.
Official control wording and applicability: Australian Signals Directorate, © Commonwealth of Australia 2026. September 2026 ISM, OSCAL v2026.09.4, reproduced under CC BY 4.0. Formatting is adapted for this website.
Latticework Systems’ implementation guidance is our interpretation. Provenance and scope.