A backup is only useful if an attacker cannot erase it
Many Central Florida businesses can answer the first backup question: **Is our data copied?** The harder question is: **Could the same compromised account that reaches production systems also alter or delete those copies?**
That distinction matters because modern ransomware incidents are not limited to encrypting files. Attackers may search for privileged accounts, backup consoles, snapshots, cloud storage, hypervisors, and recovery tools. The Cybersecurity and Infrastructure Security Agency (CISA) warns that malicious actors often leverage privileged accounts for network-wide ransomware attacks. Its StopRansomware guidance recommends offline or cloud-to-cloud backups, delete protection or object lock where appropriate, version control, and alerts for abnormal use.
NIST's 2026 ransomware profile likewise treats recovery as part of a broader program spanning governance, protection, detection, response, and recovery. A business should therefore evaluate not only whether a backup job completed, but who can administer it, how deletion is controlled, and what evidence would show the controls are working.
This guide is general information, not a product configuration manual or a guarantee against ransomware. Exact controls depend on the backup platform, identity provider, contracts, regulatory obligations, and business impact.
The failure pattern to avoid
A fragile setup often looks like this:
- The same identity administers email, servers, cloud services, and backups.
- Backup agents and consoles trust the primary business directory without additional safeguards.
- One administrator can change retention, disable jobs, and permanently delete recovery points.
- Alerts go to the same mailbox an attacker may control.
- The backup dashboard says “successful,” but no one tests whether a clean restore can be completed.
- Recovery instructions exist only inside the affected network.
This creates a shared failure domain. A stolen administrator session, compromised remote-management account, or malicious insider may reach both the live environment and the recovery environment. Replication alone does not solve the problem: a destructive change can be copied just as efficiently as a legitimate one.
1. Map the recovery control plane
Start with an inventory of every identity and system that can influence recovery. Include:
- Backup service and storage administrator accounts.
- Cloud tenants, subscriptions, vaults, buckets, and object-storage policies.
- Hypervisor, server, network-attached storage, and database credentials.
- Encryption keys and the identities permitted to use or rotate them.
- Backup agents, service accounts, API tokens, certificates, and automation.
- Managed service provider and vendor support access.
- Alerting destinations and ticketing integrations.
- Physical media and any offsite storage process.
Name a business owner and a technical owner for each component. Record what the identity can do: view jobs, create backups, restore data, change retention, disable protection, or permanently delete copies. “Administrator” is too broad to support a meaningful review.
2. Separate everyday identity from backup authority
People who manage backups should use a dedicated administrative identity for that work—not the same account used for email, web browsing, or ordinary office tasks. Apply least privilege so a help-desk technician, server administrator, or application owner receives only the recovery permissions required for the role.
Where the platform supports it, reduce dependence on the primary corporate identity system for the most sensitive backup administration. The goal is not to make recovery difficult; it is to prevent a single compromised identity store or administrator session from becoming a universal delete key.
Practical safeguards can include:
- Dedicated backup administrator accounts with phishing-resistant multifactor authentication where supported.
- No shared administrator credentials.
- Separate roles for backup operations, security policy, and audit review.
- Just-in-time or time-limited privileged access instead of permanent assignment.
- A hardened administrative workstation or controlled management path for high-impact changes.
- Emergency access credentials stored and tested under a documented process.
- Immediate removal of former employees, abandoned integrations, and unused vendor accounts.
Do not assume that adding MFA fixes excessive privilege. MFA helps protect authentication, while role design limits what an authenticated identity can do. Both matter.
3. Put deletion behind stronger controls
Ask the backup provider to demonstrate—not merely describe—what prevents premature deletion or overwrite. Depending on the technology, options may include immutable retention, object lock, delayed deletion, soft delete, legal hold, vault lock, offline media, or an independently controlled recovery copy.
Document the answers to these questions:
1. Can one administrator reduce retention and permanently delete all recovery points?
2. Is there a waiting period or second-person approval for destructive changes?
3. Can a compromised production account modify backup policies or storage?
4. Are encryption keys separated from the systems they protect?
5. Does changing a policy affect existing recovery points or only future ones?
6. Can the provider help recover from administrator-account takeover?
7. How long are audit logs retained, and can an administrator erase them?
A label such as “immutable” is not enough. Confirm scope, duration, exceptions, and who retains override authority.
4. Send alerts outside the likely blast radius
High-risk events should reach a monitored destination that does not depend entirely on the protected environment. Useful events include:
- Backup jobs disabled or repeatedly failing.
- Retention shortened or immutability changed.
- Mass deletion attempts or unusual restore activity.
- New administrators, role changes, or MFA resets.
- Backup agents removed or storage disconnected.
- Logging disabled or audit settings changed.
- Unusual sign-ins, locations, devices, or access times.
Assign a named person and backup contact to review these alerts. An alert that reaches an unattended mailbox is not a control. Test the route periodically and preserve evidence of the test.
5. Prove recovery without weakening production
NIST emphasizes that backups must be maintained and tested. A restore exercise should verify more than file availability. Select a representative business process—such as accounting, scheduling, customer records, or a critical shared drive—and confirm:
- The required people can obtain emergency access.
- A known-clean recovery point can be identified.
- Restoration occurs in an isolated or appropriately controlled environment.
- Integrity and malware checks are performed before reconnecting systems.
- Dependencies, encryption keys, configurations, and documentation are available.
- Recovery time and data loss stay within leadership's approved objectives.
- Lessons, owners, and due dates are recorded.
Do not conduct a test that risks overwriting live data. Agree on scope, safety controls, and rollback steps before starting.
A 30-day separation plan
Week 1: Inventory
List backup systems, storage, identities, service providers, keys, and deletion capabilities. Identify any account that can control both production and recovery.
Week 2: Reduce privilege
Create dedicated administrative identities, require strong MFA, remove stale access, and separate operational, security, and audit roles where possible.
Week 3: Protect copies and signals
Configure appropriate retention protection, maintain a separate or offline recovery path, protect encryption keys, and route high-risk alerts outside the primary environment.
Week 4: Demonstrate recovery
Perform a scoped restore test, record results, address gaps, and give leadership a concise report of remaining risks and decisions.
Questions for a managed service or backup provider
Central Florida businesses often rely on outside providers for backup operations. Ask for clear, written answers:
- Which party owns backup policy, monitoring, testing, and incident decisions?
- Which provider personnel can alter retention or delete copies?
- Is privileged access individual, logged, protected with MFA, and reviewed?
- Are customer backups isolated from provider administrative compromise?
- What recovery assistance and response times are included in the contract?
- Can the business export data and recovery documentation if the relationship ends?
- How will the provider notify the business about a security incident?
The provider's controls matter, but the business still must understand its own continuity requirements and verify that the contracted service meets them.
The evidence leadership should receive
A concise quarterly recovery report can include:
- Protected systems and important exclusions.
- Backup success and failure trends.
- Privileged identities and recent access reviews.
- Retention and deletion-protection settings.
- Alert tests and significant administrative changes.
- Restore-test scope, result, recovery time, and unresolved gaps.
- Risks requiring funding, acceptance, or a vendor decision.
The outcome is not a perfect diagram or a product badge. It is evidence that a stolen everyday identity cannot quietly remove every recovery option—and that the organization can restore an important service under controlled conditions.
Human-reviewed draft. Guidance is general information and should be adapted to the organization's technology, contracts, and legal obligations.