Berlin's recent ransomware incident, where Rhysida operators claimed to have stolen 5.79 TB of data from the city's administrative network, offers valuable insights. The attack, discovered in mid-August and disconnected on August 14, prompted a coordinated response involving the State Criminal Police Office, public prosecutor's office, and federal security agencies. Mayor Kai Wergner's immediate public statement refusing to pay the ransom set a decisive tone. The operational questions that followed are ones your team will face when containment ends and recovery begins.
Should You Publicly Refuse to Pay the Ransom?
Yes, make a public statement. Berlin's approach of having the Mayor publicly refuse payment served three purposes: it removed negotiation uncertainty for staff, set expectations with the public before data surfaced, and denied the attackers a tactical advantage.
Silence can lead ransomware operators to assume you're negotiating. They'll extend deadlines and adjust demands, using ambiguity to pressure your board. A clear "no ransom" position lets your incident response team focus on recovery instead of managing parallel negotiation tracks.
Your statement doesn't need to detail the breach scope or technical entry point while investigations are ongoing. It should establish your position and confirm law enforcement involvement. Under General Data Protection Regulation (GDPR) requirements, you have 72 hours to notify your supervisory authority, so the public stance often follows your regulatory notification naturally.
Does GDPR Pressure Change Your Legal Exposure if You Don't Pay?
No, paying a ransom doesn't satisfy GDPR obligations and may create additional violations. The Rhysida operators used GDPR pressure in Berlin's case, but your regulatory exposure stems from your security controls before the breach, not your payment decision after.
Article 32 of GDPR requires "appropriate technical and organizational measures" to protect Personally Identifiable Information. Your supervisory authority will evaluate whether you implemented encryption, access controls, network segmentation, and monitoring commensurate with the risk. If attackers exfiltrated plaintext credentials, unencrypted database dumps, and personnel files, your Article 32 compliance was already in question before they posted the ransom demand.
Payment might delay public disclosure, but it doesn't reduce your notification obligations under Article 33 or your potential liability under Article 83. Document your containment timeline, notification process, and remediation plan. That documentation matters more to your regulator than whether you negotiated with the threat actor.
How Can You Determine What Data Was Actually Taken?
You probably won't know with precision until forensic analysis completes. Berlin's announcement correctly stated "the extent of the data theft has yet to be determined" even after attackers published their claim of 1.44 million files.
Focus on three evidence sources: your data loss prevention logs, network egress monitoring for the suspected exfiltration window, and forensic analysis of accessed systems. Berlin's investigators identified August 7-12 as the likely exfiltration period for specific departments. That specificity comes from network logs, not the attacker's word.
Assume attackers' public claims are inflated for extortion purposes, but don't assume they're entirely fabricated. In Berlin's case, the threat actor listed specific document types, suggesting they accessed those systems, even if the total volume is exaggerated.
Your materiality assessment for regulatory notification should use the maximum plausible scope based on system access, not the minimum you can prove. If they had database access, assume they copied the database.
Should You Disconnect Affected Departments Immediately?
Yes, disconnect. Berlin severed the affected Senate departments on August 14, shortly after discovery. The containment value outweighs the operational disruption, and the idea that you can monitor attackers without them noticing your incident response is optimistic.
Ransomware operators typically maintain multiple access points. If you've detected their activity, they likely know you're responding. Delaying disconnection to "gather intelligence" usually just gives them time to expand laterally or accelerate exfiltration.
Your containment checklist should include: isolate affected systems from the network, disable compromised accounts, reset credentials for any account that accessed affected systems, and preserve forensic evidence before you start rebuilding. The NIST SP 800-61 containment guidance is explicit: containment decisions should favor limiting damage over preserving normal operations when facing active exfiltration.
How to Verify Voting Systems Weren't Compromised Without Causing Panic
Separate your technical assessment from public communication, and be specific about what you verified. Berlin's Senator Iris Spranger stated that investigators "found no evidence that election data was compromised" and that "the technical environment supporting the upcoming Berlin House of Representatives election is considered secure."
That statement works because it's precise: it addresses election systems specifically, confirms an active investigation, and avoids claiming absolute certainty about systems that weren't the focus of the breach.
Your verification process should include: confirm whether election infrastructure shares network segments with compromised systems, review access logs for election databases during the suspected breach window, validate the integrity of voter registration data and ballot systems, and engage your election commission directly in the technical assessment.
If your election systems were properly segmented and you can demonstrate no access from compromised accounts, say that. If you can't demonstrate it, don't claim it. The public trust damage from a false assurance exceeds the short-term anxiety from acknowledging you're still investigating.
Who Runs the Investigation When Federal Agencies Are Involved?
You run your investigation. Federal agencies provide resources, intelligence, and coordination, but your legal obligations and operational decisions remain yours.
Establish clear communication channels: one point of contact for law enforcement, one for your supervisory authority, one for affected parties. Berlin's multi-agency response included the State Criminal Police Office, the public prosecutor's office, and federal security agencies. That's three different mandates: criminal investigation, prosecution, and national security intelligence.
Your incident response team needs to coordinate with all three without letting the investigation paralyze your recovery. Law enforcement may ask you to delay certain remediation steps to preserve evidence or monitor attacker activity. You need to balance those requests against your obligation to affected individuals and your operational continuity requirements.
Document every request from external agencies, every decision you make in response, and the rationale. That record protects you if questions arise later about why recovery took longer than expected or why certain notifications were delayed.
Next Steps
Review your network segmentation now, before you're disconnecting departments in crisis. If a breach in one administrative system forces you to isolate multiple Senate departments, your architecture has given attackers more leverage than necessary.
Test your crisis communication process with a scenario that includes regulatory deadlines, law enforcement coordination, and public statements. The quality of Berlin's response suggests they'd rehearsed these decisions, not invented them under pressure.
Verify that your encryption key management actually protects data at rest. If your forensic team finds "plaintext credentials" and "database accounts" in attacker hands, your encryption strategy failed at the design level, not just the implementation level. That's a control effectiveness problem that matters more than any incident response plan.
