Define the operational boundary
A backup can be complete and still fail during a cyber incident if the same identities, consoles and automation can delete both production and recovery copies. Immutability is therefore an authority and architecture decision, not a storage checkbox. It should be tied to the services, recovery points and retention periods the organisation actually needs.
Document the systems, identities, information and external dependencies inside the decision. The most important failure paths are shared production and backup administrators, mutable copies reachable by ransomware, missing encryption or configuration dependencies, restore tests that validate files but not services. Assign one accountable owner and record any boundary that remains outside the current work. This prevents a technically sound control from being mistaken for protection of a wider process it cannot actually cover.
Design controls around the real workflow
Separate backup administration from production administration and require stronger approval for destructive changes. Use retention locks, offline or isolated copies and independent alerting appropriate to the platform. Protect configuration, encryption keys and recovery documentation as carefully as the data, because a copy that cannot be decrypted or located is not a usable recovery capability.
Build the control path from separate administrative authority, retention locking, isolated recovery copies, protected key custody, service-level restore testing. Each layer should have a stated purpose, an implementation owner and a safe failure mode. Test ordinary work as well as privileged and emergency journeys. Where the strongest option cannot yet be used, document the temporary safeguard, residual consequence and date by which the design will be reconsidered.
Operate from evidence
Monitor failed jobs, unexpected retention changes, deletion attempts and loss of protected-copy coverage. Reconcile the protected inventory with critical services and new data stores. Perform restorations into a controlled environment, then validate application consistency, identity, dependencies and business function rather than stopping when files appear.
Useful operational evidence includes retention-change records, deletion attempts, backup coverage reports, restore results, recovery access logs. Protect that evidence from routine administrators where practical, define how long it remains useful and make gaps visible. Measures such as critical services with isolated copies, verified restore success, unprotected data-store age, time to obtain recovery authority should trigger a review, escalation or investment decision; a dashboard without an accountable response path is only decoration.
Prepare for failure and misuse
Practise recovery when production identity, network services and management consoles are unavailable or untrusted. Establish who can authorise access to protected copies and how that authority is verified. Preserve evidence of destructive activity while preventing compromised automation from reconnecting to or overwriting the restored environment.
Exercise a scenario that removes a trusted dependency or exposes an abused privilege. Require the team to use real contacts, alternate authority, preserved records and recovery procedures. Capture what was known, what remained uncertain and which decision changed the outcome. Improvements should be verified through a repeated technical check rather than closed when a document is approved.
Move from a pilot to sustained control
Begin with one representative service and complete the sequence: identify one critical service, map its complete recovery set, separate destructive authority, lock and monitor a protected copy, restore and validate the service. Publish the minimum standard, the exception route and the evidence required for acceptance. Expand only after the pilot shows that owners can operate the control without hidden manual work or unsafe workarounds.
Review the design after major platform, supplier, identity or business-process changes. Retire obsolete access and configuration rather than carrying every historical exception forward. Report progress in terms of reduced attack paths, faster verified recovery and clearer ownership. This keeps the programme connected to operating risk instead of measuring activity alone.
What to do next.
- ✓Separate production and backup administration.
- ✓Protect retention from unilateral change.
- ✓Include keys, configuration and dependencies.
- ✓Monitor deletion and coverage changes.
- ✓Restore into a controlled environment.
- ✓Test without trusting production identity.
Use guidance responsibly
Technology, provider behaviour and legal requirements change. Validate implementation details against current official documentation, test changes safely and obtain qualified legal advice where required.
Thandiwe Jacobs
Business Resilience ContributorWrites about incident preparation, service recovery and the decisions organisations need to make before disruption.
More from this writerKabelo Nkosi
Infrastructure Assurance ContributorWrites about cloud foundations, cryptographic services, container platforms and resilient infrastructure operations.
More from this writer