Purpose
Backup is not the same as recovery
Care charities must protect highly sensitive information while keeping it available to legitimate staff and partners. RACF-CC combines preventative controls—identity, device trust, sharing, encryption and data-loss prevention—with backup scope, resilient copies and tested restoration.
What good looks like
Priority systems are mapped to backup coverage, restore procedures are tested against realistic objectives, resilient copies are protected from production compromise, and sensitive access and sharing are controlled according to risk.
Risk picture
Common paths to loss or exposure
Unmanaged download
A valid user can move sensitive information onto a device outside organisational control.
Untuned data controls
Report-only policies provide visibility but may not stop high-risk sharing or exfiltration.
Unreviewed sharing
Guests and links can remain active after the original need has ended.
Incomplete backup scope
A backup product may omit a critical system, cloud workload or dependency.
Connected backup compromise
Ransomware may target recovery infrastructure and accessible copies.
Untested restoration
Jobs can report success while timing, completeness and operational recovery remain unknown.
Prioritised action
The RACF-CC data resilience control set
| Priority | Control direction | Outcome | Evidence |
|---|---|---|---|
| First | Map every priority system and dataset to confirmed backup scope and ownership. | Identifies recovery gaps before an incident. | Critical-service backup matrix. |
| First | Test representative cloud and on-premises restores. | Proves recoverability and exposes procedural gaps. | Timed restore records and validation. |
| First | Close endpoint encryption and recovery-key gaps. | Protects data on lost or stolen devices. | Encryption and key evidence. |
| Next | Define realistic recovery time and recovery point objectives with service owners. | Aligns technology recovery with care priorities. | Approved objectives and test results. |
| Next | Restrict sensitive downloads from unmanaged or non-compliant devices. | Maintains control beyond authentication. | Access-policy and exception outcomes. |
| Next | Pilot high-confidence data-loss and external-sharing controls. | Reduces accidental and malicious distribution. | Policy incidents and false positives. |
| Develop | Strengthen offline, off-site or immutable recovery and mature information governance. | Improves ransomware resilience and lifecycle control. | Architecture tests and governance reviews. |
Implementation
A four-phase roadmap
Phase 1
Prove the basics
- Map critical systems to backup
- Review failed and warning jobs
- Test priority restores
- Close encryption gaps
Phase 2
Control access
- Define recovery objectives
- Restrict unmanaged downloads
- Review guests and sharing links
- Pilot high-confidence DLP
Phase 3
Strengthen resilience
- Protect backup administration
- Improve off-site or immutable copies
- Exercise multi-system recovery
- Train more than one recovery operator
Phase 4
Mature governance
- Expand classification and retention
- Automate sharing review
- Test supplier recovery claims
- Refine objectives after exercises
Test with safe, representative data
Restore exercises should protect confidentiality and avoid overwriting production. Use authorised test locations, clear success criteria and documented disposal. DLP and download restrictions also need pilots so legitimate care collaboration is not blocked without warning.
Pilot controls that can block data use
Audit/report-only → pilot → validate → enforce → monitor → reviewDLP, download restrictions, retention changes and sharing controls should be tested against genuine collaboration and accessibility needs before blocking. Recovery changes also require safe, representative restore validation. Use the Safe Enforcement Pattern →
Understand the supplier recovery boundary
Confirm who protects which data, who restores the service, how information can be retrieved and what happens if several services depend on the same provider. Use the Supplier and Third-Party Risk guide →
Prevent Publisher files becoming stranded
Microsoft 365 subscribers are expected to lose access to Publisher from 1 October 2026. Find important .pub files, choose a future format and validate their content and appearance before the deadline. Use the Publisher continuity guide →
Evidence
Measure recovery confidence
Residual risk and escalation
Record data and recovery gaps that remain
What may remain unresolved?
Untested restores, incomplete SaaS or legacy-system backup, limited immutable copies, excessive sharing, weak classification and licensing-limited DLP or retention coverage may remain.
Supplier boundaries, storage cost, licensing, confidentiality constraints, legacy platforms, unavailable test environments or unclear service ownership may limit assurance.
Restrict access and sharing, maintain additional copies, protect backup administration, monitor data movement and document manual recovery procedures.
The accountable information or service owner owns the consequence, supported by data-protection, backup and platform administrators.
Review after restore exercises, platform or supplier change, major data migration, control failure and at the agreed recovery-assurance interval.
Failed priority restore, ransomware activity, backup compromise, uncontrolled sensitive-data movement, repeated job failure or inability to meet essential recovery needs.
Recording does not equal acceptance. Recovery assumptions and data-protection gaps require explicit ownership, safeguards and a time-bound decision.
References
Standards alignment
- NCSC: Ransomware-resistant backups — protecting recovery copies from destructive attacks.
- NCSC: Offline backups in an online world — isolation principles for cloud and local copies.
- NIST SP 800-53 Revision 5 — contingency planning and data protection controls.
Continue
Make attacks visible
Domain 6 turns existing logs and alerts into a sustainable monitoring routine.