Data Exfiltration: The Breach Your Backups Cannot Undo

Executive Summary
Every resilience review I have sat in follows the same arc. We walk the recovery time objectives. We confirm the backups are immutable and tested. Someone asks about the failover region, someone else asks what happens if the primary data centre is unreachable for a week, and the room relaxes when the answers hold up. Then the meeting ends. In twenty years of these reviews, I have almost never heard the question that the Berlin state administration is now living with: what happens when nothing goes down, and everything gets out.
On 5 September 2026, the ransomware group Rhysida published roughly 1.44 million files taken from Berlin’s state administration — about 5.8 terabytes — after the city refused a demand of 30 bitcoin, near two million euros. Governing Mayor Kai Wegner had stated the position plainly: “The State of Berlin will not give in to blackmail.” The files went up anyway.
Nothing was encrypted. No service stopped. Two Senate departments kept operating throughout. By every metric a traditional continuity programme measures, Berlin did not have an incident at all.
Why Data Exfiltration Breaks the Continuity Model
Disaster recovery is good at a specific job, and the discipline itself is sound — it is simply aimed elsewhere. Recovery planning exists to restore a service that stopped. Backups answer the question “can we get it back.” Recovery point objectives answer “how much do we lose.” Failover answers “how fast.” These are availability questions, and a mature programme answers them well.
Data exfiltration asks none of them. The service never stopped, so there is nothing to restore. The data was never lost, so there is nothing to recover. What changed is that a copy now exists outside your control, and there is no operation in any runbook that removes it.
This is not an edge case any more. Securelist’s review of the 2026 landscape found that 22% of ransomware incidents now involve no encryption at all. Google’s threat researchers tracked pure data-theft extortion rising from roughly 2% of cases in 2020 to about 15% by 2025 — a sevenfold shift in five years. The attackers made a rational calculation before we did: encryption is operationally fragile, noisy, and recoverable, while publication is cheap, quiet, and permanent.
The Berlin timeline shows the asymmetry clearly. Attackers held access before 7 August. Data left the network between 7 and 12 August. The intrusion was discovered on 14 August — two days after the theft had already finished. The perimeter held on the way in long enough to matter, and nobody was watching the way out.
What Berlin Actually Lost
The contents are the argument. Alongside employee files and official correspondence, the dump reportedly includes pay stubs, scanned identity documents, and home addresses of civil servants. Investigators have pointed to material on combined heat and power plants, fuel storage facilities, emergency power supply systems, prisons, and water treatment installations. State criminal police investigation documents appear in the set, as do details of the federal chancellery expansion.
Consider what a credential rotation does to that list. It closes an access path that the attackers had already finished using a month earlier. It does not touch a single published file.
Jochim Selzer of the Chaos Computer Club made the downstream point to the Frankfurter Allgemeine: “The more you know about a person, the better you can impersonate them and the better you can figure out what you need to know about them in order to, say, place an order on their behalf.” The harm is not fraud on a stolen card, which a bank reverses in a week. It is durable impersonation built from a complete identity file, and there is no issuing authority that reissues a person.
Thorsten Schleheider, vice-chairman of Berlin’s police union, said the quiet part in public: “It is unthinkable that highly sensitive data was compromised for days, and the only action taken appears to be instructing employees to change their passwords.” He is not describing negligence. He is describing an organisation reaching, under pressure, for the only lever its playbook contained.
Four Pillars for Confidentiality Resilience
If availability planning does not cover this, something else has to. Three of the four pillars below are governance decisions rather than technology purchases.
Pillar 1: The Inventory You Do Not Have
You cannot protect a file you do not know you are holding. Most organisations can describe their systems of record precisely and their file shares not at all, which is where the damaging material actually accumulates: scanned documents, exports pulled for a one-off analysis, contracts from partners, HR correspondence, and the attachments of fifteen years of email.
Berlin’s exposure came from departments responsible for transport and urban development. Nobody designed those shares to hold the layout of a water treatment plant. They held it because a planning process once needed it and nothing ever removed it.
- Classify by sensitivity of consequence rather than department of origin
- Identify every store holding identity documents, financial records, or third-party material
- Record which of those stores has an owner who could say what is inside it today
Pillar 2: Retention as a Security Control
Deletion is the only control that reduces exfiltration impact to zero, and it is the one most organisations treat as a storage-cost question rather than a risk question.
Every file retained past its purpose is pure liability: it cannot generate value, and it can be published. The discipline is to give data an expiry at the moment of creation and to enforce it automatically, because a retention policy that depends on someone remembering to run a cleanup is not a control.
- Set retention at the moment of ingestion, before any audit cycle forces the question
- Make expiry automatic and logged, so the absence of a file is evidence rather than a mystery
- Treat “we might need it someday” as the cost centre it is
Pillar 3: Egress as the Primary Signal
Nearly six terabytes left a network that connects roughly 600 sites, and the detection came after it stopped. Volume leaving the estate is the most boring telemetry in the building, and almost nobody alerts on it.
Prevention metrics — blocked attempts, patch coverage, phishing simulation pass rates — measure the perimeter. They do not measure the thing that determines severity, which is how long an adversary operates inside before anyone notices. Mean time to detect is the number that predicts how bad a breach becomes, and it is rarely the number a board is shown.
- Baseline normal outbound volume per system, then alert on the deviation
- Instrument the paths that bypass the proxy: cloud sync, personal storage, administrative tooling
- Report detection time to the board as a standing metric, reviewed every cycle, never only after an incident forces the question
Pillar 4: The Disclosure Posture, Written in Peacetime
Berlin’s refusal was correct and it was also insufficient on its own, because refusing is only half a posture. The other half is knowing, in advance, who you notify, in what order, with what evidence, and how you support the people whose documents are now public.
That plan cannot be drafted during the incident. Under a countdown, with counsel and communications and a regulator all wanting different things, an organisation will reach for whatever is written down — and if the only thing written down concerns restoring service, it will reset passwords and call that a response. This is the same failure mode that turns incident response documentation into paper that nobody can execute, and it has the same remedy: rehearse the decision before you need it.
The Mistakes I Keep Seeing
1. Treating credential rotation as remediation. Rotation closes a door. It does not retrieve what already walked through it. When a password reset is the headline of your response, the response has not addressed the loss.
2. Reporting resilience exclusively in RTO and RPO. Both are availability measures. An organisation can hit every recovery target it has set and still suffer the worst breach in its history. Add a confidentiality measure or the board is reading half a picture.
3. Treating the file share as a filing cabinet. A cabinet in a locked room has a blast radius of one room. A share replicated across a flat network has a blast radius of the network, and data governance is the discipline that decides which one you are running.
Questions Executives Are Asking
We have immutable, tested backups. Does that not cover us?
It covers ransomware that encrypts. It does nothing for ransomware that publishes. Immutability guarantees you can restore your copy; it makes no claim about the attacker’s copy. If your continuity programme’s strongest control is backup integrity, you are insured against the attack pattern that is becoming less common and uninsured against the one that is growing.
Our systems never went down. Do we still have to notify?
Almost certainly, and the absence of an outage is what makes this counterintuitive. Notification obligations under Indonesia’s Personal Data Protection Law, as under the GDPR, are triggered by unauthorised access to personal data. Service interruption has nothing to do with it. An organisation whose only incident criterion is downtime will fail to recognise a reportable event while it is happening.
Is this not simply an argument for cyber insurance?
Insurance transfers financial consequence. It does not transfer the consequence that matters here. No policy un-publishes an employee’s identity document or restores a third party’s confidence that their material was safe with you. Insurance belongs in the plan; it does not substitute for retention discipline or detection capability.
Where does this leave disaster recovery?
Exactly where it was, doing the job it was designed for. Availability planning remains necessary — the argument is that it was never sufficient, and the assumptions underneath most recovery plans have been quietly outgrown by the threat they are meant to answer. Keep the programme. Stop presenting it as coverage for a risk it does not address.
What This Changes
For anyone who has invested years in continuity capability, that investment was aimed at the previous decade’s failure mode. Encryption was a problem you could engineer your way out of with enough redundancy. Publication is not. It is a problem you can only reduce in advance, by holding less, keeping it for less time, and noticing sooner when it moves.
Ransomware stopped being a technical inconvenience some years ago. What Berlin demonstrates is that it has now stopped being an availability problem as well. The question a board should be asking is no longer how quickly the organisation could recover. It is what would become public if it never had to.
You can restore a server. You cannot rotate a leaked identity document.