Berlin's decision not to pay the Rhysida group's ransom after a breach compromising 5.79 terabytes of government data has been praised as a stand against cybercrime. However, this incident highlights persistent myths about ransomware response that undermine effective public sector cybersecurity. These misconceptions persist because they simplify the complex reality of incident response and allow leaders to avoid tough questions about preparedness.
Myth 1: Refusing to Pay Is Always the Right Call
Reality: The decision to pay should come after containment and impact assessment.
Berlin announced its refusal to pay before fully investigating what data was stolen. Governing Mayor Kai Wegner stated the government wouldn't comply with demands, even as authorities admitted they "could not rule out that Personally Identifiable Information or other non-public information was compromised." The stolen material allegedly included 46,500 contracts, emails, telephone numbers, passwords, and classified information.
This approach is flawed. Your focus should be on containment speed and recovery capability, not on making public statements before understanding the compromise.
The correct sequence: isolate affected systems (as Berlin did on Aug. 14), assess the scope of compromise, determine recovery options, evaluate legal obligations, then decide if payment serves your recovery strategy. Payment is about recovery, not morality. If you can restore systems without paying, don't pay. If payment is the only way to prevent disclosure of protected citizen data, the calculation changes.
Myth 2: Strong Cybersecurity Means Never Getting Breached
Reality: Resilience is about limiting impact and maintaining operations during an incident.
Two Berlin ministries lost access to email, internet services, and core IT systems. Some district offices couldn't process housing benefit applications because they relied on systems operated by the affected urban development ministry. Staff resorted to phone, text, and fax to communicate.
This reflects poor segmentation. The fact that Berlin's state-owned IT provider, ITDZ Berlin, remained unaffected shows the importance of network segmentation. The compromised ministries operated independently, lacking the hardened infrastructure ITDZ maintained.
Your security program's success isn't measured by avoiding breaches. It's about whether a breach in one area forces others to use outdated communication methods. Implement network segmentation per NIST SP 800-53 control SC-7, ensuring each ministry can fail independently, and design recovery so that losing email in one building doesn't disrupt services elsewhere.
Myth 3: Election Systems Are Either Secure or They Aren't
Reality: Security depends on threat model, attack surface, and monitoring, not a binary state.
Interior Senator Iris Spranger assured the public that "according to our security officials, the election environment is secure" and that "no data has been exfiltrated from there." The breach occurred less than a month before Berlin's Sept. 20 elections, raising concerns about infrastructure disruption.
This statement confuses two issues: whether election systems are isolated from compromised networks (they were), and whether they're "secure" in an absolute sense (nothing is). The correct framing: election systems operated on separate infrastructure with no evidence of compromise as of the statement date, and monitoring is in place to detect lateral movement attempts.
Your board should demand precision. When your CISO says a system is "secure," ask: secure against what threat? Monitored how? Tested when? The Berlin incident shows different government functions operated on different network segments with varying security postures. That's appropriate. What's inappropriate is describing any of them as "secure" without specifying the threat model and control set.
Myth 4: Attribution Matters for Response Decisions
Reality: Attribution is for intelligence and prosecution, not for containment or recovery.
Multiple sources reported that Rhysida, likely Russian-speaking and operating since at least May 2023, claimed responsibility for the attack. Berlin authorities confirmed data theft and an extortion demand but "have not publicly attributed the attack to Rhysida or verified the group's claims about the volume or contents of the stolen information."
This caution is correct, but irrelevant to your response timeline. Whether Rhysida or another group stole your data doesn't change your containment steps, recovery sequence, or notification obligations. Attribution helps law enforcement and threat intelligence teams, but it shouldn't delay your incident response actions.
Your Incident Response Plan should trigger on observables (unauthorized access detected, data exfiltration confirmed, systems encrypted), not on attribution confidence. Isolate first, attribute later.
Myth 5: Ransomware Is Primarily a Technical Problem
Reality: Ransomware exposes governance failures, communication gaps, and policy debt.
Berlin's response revealed that two ministries operated IT infrastructure independently from the state's primary IT provider, that some district services depended on ministry-operated systems without clear continuity plans, and that the government's position on ransom payment was announced before impact assessment was complete.
These aren't technical failures. They're governance failures. Your board should ask: why did ministry IT operate independently? What risk acceptance process approved that architecture? Which services have single points of failure in ministry-operated infrastructure? What's our decision framework for ransom payments, and why wasn't it applied before the public statement?
Ransomware succeeds because it finds the gaps between your technical controls, operational procedures, and governance oversight. The technical breach is just the exploitation of accumulated policy debt.
What to Do Instead
Stop treating ransomware response as a binary choice between paying and refusing. Build a decision framework before the incident that considers recovery time objectives, legal obligations, data sensitivity, and operational impact. Document it in your Incident Response Plan per NIST SP 800-61, and ensure your board has reviewed and approved the framework.
Implement network segmentation that allows different functions to fail independently. Test it with tabletop exercises that simulate ministry-level compromise and measure cascade effects. If losing email in one building breaks benefit processing in another, you have an architecture problem, not a security problem.
Define "secure" precisely in every board report and public statement. Specify the threat model, the control set, and the monitoring coverage. Replace "the election environment is secure" with "election systems operate on isolated infrastructure with no observed indicators of compromise as of [date], monitored per [standard]."
Separate attribution from response in your procedures. Your containment checklist shouldn't include "confirm attacker identity" as a prerequisite for action. Isolate, assess, recover, then attribute.
Treat every ransomware incident as a governance audit. The technical breach reveals which policies weren't enforced, which dependencies weren't documented, and which decision frameworks didn't exist. Fix the governance gaps, not just the technical vulnerabilities.
Berlin's refusal to pay may ultimately prove correct, but not because refusal is inherently principled. It'll prove correct only if their recovery capability, legal exposure, and operational impact made payment unnecessary. Everything else is performance.
