Backups as Security Control, Not IT Housekeeping

For most of the history of enterprise IT, backup lived in the operations department and answered to availability. The threats it defended against were hardware failure, accidental deletion, database corruption and the occasional flood or fire. Nobody in the security team owned it, nobody in the security team tested it, and the backup infrastructure was frequently the least hardened part of the estate. The ransomware wave that began in late 2013 collapsed that distinction. When the threat is an adversary who deliberately destroys data, the backup stops being an operational nicety and becomes the control that determines whether the business survives. And the moment an attacker's objective includes preventing recovery, the backup itself becomes a primary target.

The Assumptions That Broke

The backup architecture that most organizations had in 2013 was built on three assumptions, all of which were reasonable against accidental loss and all of which failed against a deliberate adversary. That the threat was random. Hardware fails unpredictably; a fire does not wait until the backup window. This justified nightly cycles and multi-day recovery windows. An attacker, by contrast, chooses the timing — a long weekend, a public holiday, the night before a reporting deadline — and chooses it precisely to maximise the damage before anyone notices. That the threat was external to the backup system. Backups were protected against the failure of the thing being backed up, not against something that could reach the backup itself. Backup servers shared the production domain, used production administrative credentials, sat on the production network and were frequently excluded from patching cycles because they were considered infrastructure. An attacker with domain administrator rights had the backup as well. That verification meant the job completed. The backup report said success. What it verified was that data had been written, not that it could be read back, not that the data set was complete, and not that a restore would produce a working system. Organizations discovered the difference during incidents.

What a Security-Grade Backup Looks Like

The architecture that survives a deliberate attack has a small number of non-negotiable properties. At least one copy is unreachable from production. Physically disconnected media, write-once immutable storage, or a separate cloud account with independent credentials and no trust relationship to the production directory. The test is simple and unforgiving: if an attacker with full domain administrator rights can delete or encrypt it, it is not a protected copy. Backup credentials are entirely separate. Not a different password on the same directory. A separate authentication domain, separate administrative accounts, multi-factor authentication, and no shared service accounts. Credential reuse between production and backup is the most common single point of failure in ransomware incidents. Immutability is enforced by the storage, not by policy. Object lock, write-once media or a vendor-enforced retention lock that cannot be shortened by an administrator. Retention settings that an administrator can change are retention settings an attacker with administrative access can change. Retention spans the dwell time. Modern intrusions involve weeks of quiet presence before the destructive act. If retention is fourteen days and the attacker was inside for six weeks, every available restore point may contain their access. Retention needs to exceed realistic dwell time, which means months rather than days for critical systems. The backup system is monitored as a security asset. Mass deletion requests, retention policy changes, unusual administrative authentication, job disablement and configuration changes are all high-fidelity indicators of an attack in progress. In a great many incidents the backup system logged the attacker's preparation and nobody was watching. And restores are tested as a measured exercise. Not a file-level spot check. A full recovery of a representative critical system to a working state, timed, documented, with the result compared against the recovery time objective the business has been told it has.

The Recovery Time Nobody Measured

The most widespread and least discussed failure is the gap between stated and actual recovery time. Recovery time objectives are set in business continuity planning, usually by asking business owners how long they could tolerate an outage. The answers are aggressive. Four hours for the core financial system, one day for everything else. These numbers go into a document and are never validated. The actual time to recover, when measured, routinely exceeds the stated objective by an order of magnitude, and the reasons are consistent. Restore throughput is bounded by the slowest link. Multi-terabyte restores over a network sized for incremental backup take days, not hours. Cloud egress introduces both time and unexpected cost. Sequence matters and is rarely documented. Directory services before applications, databases before application servers, integration middleware before the systems that depend on it. Organizations recovering under pressure discover the dependency graph by failing. Clean infrastructure has to exist first. In a ransomware event you are not restoring onto the compromised estate. You need rebuilt operating systems, verified clean, before restoration begins. That step is frequently absent from the plan entirely. Validation takes longer than restoration. Confirming that restored financial data is complete and consistent, that integrations have resumed correctly, and that no partially processed transactions have been duplicated or lost is careful work that cannot be rushed. And staff capacity is finite. The plan assumes parallel recovery of twelve systems. The team that can do it consists of four people who have been awake for twenty hours.

Practical Guidance for Backup Resilience

• Verify that one copy is genuinely unreachable from production. Test it by asking what a domain administrator could destroy, then confirm the protected copy survives that answer.
• Separate backup authentication completely from production identity. Independent accounts, independent directory, multi-factor authentication, no shared service credentials.
• Use storage-enforced immutability rather than configurable retention. Settings an administrator can change offer no protection against an attacker holding administrative rights.
• Set retention longer than realistic attacker dwell time. Weeks of presence before detonation means short retention windows may contain nothing clean.
• Monitor the backup platform for security events. Mass deletions, retention changes and job disablement are among the highest-value early warnings available.
• Test a full system recovery quarterly and record the elapsed time. Then compare it with the recovery time objective the business believes it has.
• Document the recovery sequence and dependencies. Discovering the dependency graph during an incident costs hours you do not have.
• Plan for rebuilding clean infrastructure before restoring. You cannot restore onto a compromised estate, and most plans omit this step.

The Regional Considerations

For organizations in the Gulf, a few factors change the backup design problem in practical ways. Data residency constrains where copies can live. For regulated entities and government-adjacent organizations, requirements under the UAE data protection framework, Saudi PDPL and sector-specific rules mean backup copies are subject to the same residency constraints as production data. That rules out some conveniently cheap offsite options and makes the availability of regional cloud infrastructure genuinely significant — an immutable copy in an in-region account satisfies both the security and the residency requirement, which was much harder to arrange a decade ago. Multi-entity groups need per-entity recovery, not just group recovery. A group with entities across the UAE, Saudi Arabia, Qatar and Egypt has separate statutory reporting obligations per entity. A restore that recovers the consolidated group position but leaves one entity's subledger inconsistent creates a filing problem in that jurisdiction. Recovery testing needs to validate at entity level. Bilingual and localised data must survive the restore intact. Arabic-language master data, bilingual invoice templates and locale-specific formatting are exactly the things that break in a restore performed under pressure onto rebuilt infrastructure with default configurations. This is worth explicitly including in restore validation, because it is routinely missed. E-invoicing and statutory submission systems have their own recovery requirements. Where ZATCA clearance or equivalent regimes require structured submission of invoices, a recovery that restores the ERP but loses the submission status creates either duplicate submissions or a compliance gap. The reconciliation position between internal records and the tax authority's records needs to be part of the recovery plan. And payroll has an unforgiving calendar. Wage protection system obligations mean salary payment timing is a regulatory matter, not merely an employee relations one. A recovery that takes four days in the wrong week of the month has a compliance consequence in addition to an operational one. Payroll systems frequently deserve a shorter recovery objective than their transaction volume would suggest.

Where This Is Heading

Three developments have changed the backup problem since the ransomware model established itself. Exfiltration made recovery insufficient. When attackers steal data before encrypting it, a perfect restore resolves availability and does nothing about disclosure. This does not diminish the value of backup; it means backup can no longer be the whole answer. Data minimisation, encryption of data at rest with controlled keys, and detection during the intrusion phase carry weight that recovery capability alone cannot. The backup platform became an attack surface in its own right. Vulnerabilities in widely deployed backup software have been actively exploited, precisely because compromising the backup system is the highest-value move available to an attacker preparing a destructive event. Backup infrastructure now requires the patching discipline and hardening applied to internet-facing systems. And SaaS data has largely fallen through the gap. Organizations with disciplined backup of on-premises systems frequently have none for their collaboration platform, their CRM or their HR system, on the assumption that the provider handles it. Providers protect against their own infrastructure failure. They generally do not protect against a customer administrator deleting data, a compromised account destroying content, or a malicious insider with legitimate access. That exposure has grown in step with SaaS adoption and is one of the least addressed risks in most estates. The underlying shift that started in 2013 is settled, though. Backup is a security control, it belongs in the security programme, and its value is determined entirely by whether it has been tested against a scenario in which someone is deliberately trying to prevent you from recovering.

Common Questions

Why is backup considered a security control rather than an operations function?

Because the dominant threat to data availability is now a deliberate adversary rather than accidental loss. When attackers specifically target backups to prevent recovery, the backup architecture has to be designed against an intelligent opponent, which is a security problem.

What makes a backup copy genuinely protected?

It must be unreachable from the production environment: physically disconnected, in storage-enforced immutable form, or in a separate account with independent credentials and no trust relationship to production identity. If a domain administrator can delete it, it is not protected.

Why does backup retention need to be long?

Because modern intrusions involve weeks of quiet access before the destructive event. Short retention windows may contain only restore points that already include the attacker's presence, leaving no clean recovery option.

Do cloud and SaaS providers handle backup?

They protect against their own infrastructure failure. They generally do not protect against customer-side deletion, compromised administrative accounts or malicious insiders. SaaS data is one of the most commonly unprotected categories in otherwise well-run estates.

---

Backup Resilience Review — Outpace tests whether your backups survive a determined attacker, and measures how long recovery actually takes.