When Berlin's government discovered a breach on Aug. 14 and disconnected two ministries from the state network, officials faced a familiar ultimatum: pay 30 bitcoin (roughly $2.3 million) or watch 5.79 terabytes of government data appear on the dark web. Governing Mayor Kai Wegner's response was clear: "The state of Berlin is being blackmailed. We will not comply."
But here's what most post-incident analyses miss: the question isn't whether to pay. It's whether you've built systems that let you refuse without operational collapse.
The Case for Never Paying
The argument against paying rests on three operational pillars. First, payment funds criminal infrastructure. Every bitcoin transferred strengthens the attacker's capability to hit the next target. For public sector organizations, this creates a compounding risk: today's payment finances tomorrow's attack on critical infrastructure.
Second, payment offers no guarantee of recovery. Even when attackers provide decryption keys, restoration often fails. Data corruption, incomplete key delivery, and continued extortion attempts are common. Berlin's decision reflects this reality: disconnecting affected systems and working through recovery independently provides more control than trusting an adversary's technical competence.
Third, paying creates a targeting signal. Organizations that pay once become known quantities in criminal forums. The Rhysida group's claim of 46,500 contracts and classified information in Berlin's case suggests they understood the political sensitivity of the timing (elections scheduled for Sept. 20). But Berlin's refusal sends a different signal: this target won't yield.
From a cyber insurance perspective, this approach aligns with underwriting incentives. Insurers increasingly write Cyber Extortion Coverage with sub-limits and require documented incident response capabilities. Your policy might cover the payment, but underwriters are pricing for organizations that can refuse it.
The Case for Pragmatic Payment
The counterargument isn't about principle. It's about operational reality. When your email systems go dark and staff resort to fax machines, you're not making decisions in a vacuum. You're weighing recovery time against service delivery obligations.
Consider the cascading disruption Berlin experienced. District offices lost the ability to process housing benefit applications because they relied on systems operated by the affected urban development ministry. This wasn't just inconvenience. These are services residents depend on for basic needs. For private sector organizations, the equivalent calculation involves revenue loss, contractual penalties, and customer attrition.
The payment decision also depends on backup maturity. Berlin could refuse because ITDZ Berlin, the state-owned IT provider, remained operational and the affected ministries operated independently. But many organizations discover during an incident that their backup strategy assumed away the scenario they're now facing. When your recovery time objective measures in weeks and your business can't survive days, payment becomes the least-bad option.
There's also a disclosure calculation. Berlin authorities acknowledged they "could not rule out that personal data or other non-public information was compromised." Under Breach Notification Requirements in most jurisdictions, that triggers investigation and potential notification obligations regardless of whether you pay. Payment might reduce the public exposure of that data, limiting downstream harm to individuals whose information was compromised.
Where Practitioners Actually Land
Most incident response teams don't make the payment decision in isolation. They're working through a decision tree that starts well before the ransom demand arrives.
The organizations that can credibly refuse share specific characteristics. They've tested their backup restoration under realistic conditions. They've documented their critical dependencies and know which systems must recover first. They've pre-positioned Breach Coach relationships and have clear authority chains for incident decisions. Berlin's ability to disconnect affected systems within days of discovery on Aug. 14 suggests this level of preparation.
The organizations that struggle have usually failed at one of these fundamentals. They discover during restoration that their backups are incomplete or corrupted. They realize their recovery time objectives were aspirational rather than tested. They lack the legal and technical resources to manage a complex incident response while maintaining operations.
Your cyber insurance application should reflect this reality. Underwriting Questionnaire responses about backup testing, incident response retainers, and business continuity planning aren't compliance theater. They're predictors of whether you'll have options when an extortion demand arrives.
Our Take
Berlin's refusal to pay was the right call, but not primarily because of the moral argument against funding criminal operations. It was right because Berlin had the operational capacity to make that choice.
The lesson for enterprise risk managers isn't "never pay." It's "build systems that let you refuse." That means:
Test your backup restoration quarterly under scenarios that assume your primary environment is compromised. Don't just verify the backup completed. Restore it and run operations from it.
Document your critical service dependencies. Berlin's experience with district offices losing housing benefit processing shows how operational disruptions cascade. Map those dependencies before an incident.
Pre-position your incident response resources. Berlin's Interior Senator could confirm election systems remained secure because they'd already assessed that environment. That's only possible with advance preparation.
Understand your Cyber Extortion Coverage terms before you need them. Know your sub-limits, your Insurer Consent Requirements, and whether payment requires law enforcement notification.
The Rhysida group's seven-day countdown and dark-web auction create artificial urgency. But the real timeline started months earlier, when you either built resilient systems or accepted the risk that you'd have no good options when the demand arrived.
Berlin's ministries are still operating on reduced IT capabilities. Staff are working through telephone and text message. That's not a comfortable position. But it's a position they could choose because they'd prepared for it. Your organization should have the same option.
