When the Rhysida ransomware gang demanded 30 bitcoins from Berlin's government, officials made a decision that still divides security teams: they refused to pay. This decision, now unfolding publicly with a Friday deadline, has reignited debates about ransom payment strategy. Much of that debate rests on persistent myths that don't hold up under scrutiny.
These myths persist because ransomware decisions are made under pressure, with incomplete information, and often without the benefit of post-incident analysis from other victims. Let's examine what the evidence actually shows.
Myth 1: Refusing to Pay Stops the Data Leak
Reality: Refusal doesn't prevent publication; it just removes your ability to influence timing or scope.
When Berlin declined to pay, Rhysida didn't quietly walk away. The group set up an auction for 5.79 terabytes of claimed data, including 16,389 emails, 11,963 phone numbers, and thousands of personnel files. They're running that auction until Friday, promising to give the data to "one buyer" if Berlin doesn't pay.
The British Library made the same choice in 2023 when Rhysida demanded 20 bitcoin. The gang published around 600 gigabytes anyway, including staff details that reportedly forced relocations. Your refusal doesn't eliminate the threat; it just means you've lost any negotiating position you might have had.
What you can control: your containment speed, your notification obligations under the General Data Protection Regulation (GDPR) 72-Hour Notification Requirement, and your communication strategy with affected data subjects. You can't control whether the attacker publishes.
Myth 2: Payment Guarantees Data Deletion
Reality: You're trusting criminals to honor a verbal agreement with no enforcement mechanism.
Even organizations that do pay face a fundamental problem: you have no way to verify deletion. Double extortion groups like Rhysida exfiltrate data before encrypting systems. Once that data leaves your environment, you've lost technical control over it.
Payment might stop one specific leak or auction, but you can't confirm the attacker deleted all copies, didn't retain samples for future extortion, or won't sell portions to other parties later. You're accepting a promise from an entity that just attacked you.
The only verifiable action you can take is treating all exfiltrated data as permanently compromised. That means your Data Subject Access Request processes, your breach notification protocols, and your regulatory reporting all proceed as if the data is public, regardless of payment status.
Myth 3: Non-Payment Protects You From Legal Liability
Reality: Your liability stems from the breach itself, not your ransom decision.
Some teams believe refusing payment demonstrates good faith to regulators or limits legal exposure. That's backwards. Under the GDPR, your obligations trigger when personal data is compromised, not when you make payment decisions.
Berlin's response illustrates the actual compliance path: immediate containment (disconnecting affected departments from the central network), forensic investigation to determine scope, notification to supervisory authorities, and communication with affected individuals. None of those obligations change based on whether you pay.
Your Statement of Applicability under ISO/IEC 27001 should document your incident response controls, including how you execute Containment, Eradication, and Recovery. Your Computer Security Incident Response Team's procedures should outline decision criteria for various scenarios. But those frameworks focus on technical response, not ransom negotiation.
What regulators will examine: Did you have appropriate preventive controls? Did you detect the breach promptly? Did you contain it effectively? Did you meet notification timelines? Your payment decision doesn't feature in that audit trail.
Myth 4: Strong Backups Eliminate the Extortion Risk
Reality: Backups solve the encryption problem, not the data theft problem.
Berlin officials discovered the attack on Aug. 14 and immediately began system restoration. But Rhysida had already exfiltrated data between Aug. 7 and Aug. 12. Your backup strategy doesn't address that seven-day window when attackers were inside your environment, copying files.
This is why double extortion works. Traditional ransomware relied on encryption as the sole pressure point. If you had clean backups, you could restore and refuse payment. Modern groups added data theft precisely to bypass that defense.
Your backup program should align with NIST SP 800-53 control CP-9 (Information System Backup) and include offline, immutable copies. But you also need controls that prevent or detect exfiltration: network segmentation, data loss prevention, anomalous transfer monitoring, and logging that captures egress traffic patterns.
Consider what Berlin's forensic investigation revealed: credentials stored in plaintext, some in files named "Password.docx," with passwords like "Sunshine13." Those aren't backup failures; they're fundamental access control and Privileged Access Management failures that no backup strategy addresses.
Myth 5: Paying Is Cheaper Than Recovery
Reality: Payment is an additional cost, not an alternative to recovery costs.
Even organizations that pay still face the full recovery burden. You still need to rebuild systems, patch vulnerabilities, rotate credentials, and implement the controls that should have been there initially. Berlin canceled remote work access, disconnected departments, and began scanning 12,000 systems to verify no other departments were compromised.
Those activities happen whether you pay or not. Payment might decrypt files faster than restoration from backup, but it doesn't eliminate the forensic investigation, the system hardening, the credential rotation, or the regulatory response.
The Federal Office for Information Security's password recommendations, which Berlin's "Sunshine13" credentials clearly violated, represent baseline controls. Implementing them post-incident costs the same whether you paid ransom or not. The difference is that payment adds the ransom amount on top of recovery costs; it doesn't replace them.
What to Do Instead
Stop framing this as a binary choice between paying and refusing. Your actual decision tree is more complex:
Before an incident: Document your decision criteria now, when you're not under pressure. What data types would trigger payment consideration? What's your threshold for operational disruption? Who has authority to authorize payment? Your Computer Security Incident Response Team procedures should include this framework, reviewed annually by your board or audit committee.
During an incident: Execute containment first, decision-making second. Berlin's immediate network disconnection was correct. You can't make informed payment decisions until you know what was taken, what's encrypted, and what your restoration options are.
For compliance obligations: Treat payment as irrelevant to your notification and remediation duties. Your 72-hour clock under the GDPR starts when you discover the breach, not when you decide about payment.
For long-term risk reduction: Address the controls that failed. Berlin's plaintext passwords and non-compliant credential practices created the initial access vector. Your SOC 2 Type II audit should verify password policies align with current standards. Your Privileged Access Management implementation should eliminate plaintext credential storage entirely.
The question isn't whether to pay. It's whether your preventive controls, detective capabilities, and response procedures give you meaningful options when an attacker makes demands. Berlin's Friday deadline will pass regardless of their decision. What matters is whether they've used this incident to build controls that prevent the next one.
