When Berlin's government faced a breach in mid-August, resulting in 5.79 terabytes of stolen data and a $2.3 million ransom demand, officials publicly committed not to pay. For your organization, adopting the same stance requires more than just resolve. It demands a robust technical and operational framework to respond, recover, and maintain services without funding attackers.
This guide helps you build a no-negotiation ransomware response capability, even when your systems are encrypted and your data is on dark-web leak sites.
The Problem: Why No-Pay Policies Fail Without Infrastructure
Many organizations declare they won't pay ransoms, only to reconsider when systems are encrypted and backups fail. Berlin's affected ministries lost email, internet, and application access, forcing staff to use phones, texts, and faxes. District offices couldn't process housing benefit applications due to reliance on compromised systems.
A no-pay stance is sustainable only if you have the technical capability to restore operations independently. Without it, you're forced to choose between paying or enduring extended service disruptions that might lead to a policy reversal.
The issue isn't just about backup technology. It's about network segmentation to contain breaches, alternative communication channels to keep teams coordinated, and continuity plans to reroute critical functions around compromised infrastructure.
What You Need Before Starting
Before implementing a no-pay response framework, ensure you have:
Segregated network architecture: Critical systems must operate on isolated network segments. Berlin's IT provider, ITDZ Berlin, remained unaffected because the compromised ministries operated their network independently. If your systems share flat network access, containment is impossible.
Immutable backup infrastructure: Backups must be protected from encryption or deletion. Use air-gapped storage, write-once-read-many volumes, or cloud storage with MFA-protected retention policies. Test restoration monthly.
Out-of-band communication systems: If email and collaboration platforms are encrypted, how does your team coordinate? Use pre-configured Signal groups, satellite phones, or a separate collaboration tenant with no shared authentication infrastructure.
Authority to disconnect systems: Document who can authorize network disconnection without executive approval during intrusions. Berlin disconnected affected systems two days after discovering the breach. Delayed containment allows attackers to expand their foothold.
Legal and regulatory notification templates: Prepare breach notifications while managing the incident. Pre-draft templates for the General Data Protection Regulation's 72-Hour Notification Requirement, sector-specific rules, and public communications.
Step-by-Step Implementation
Phase 1: Network Segmentation and Monitoring (Weeks 1-4)
Deploy network segmentation to isolate critical functions:
Segment by data sensitivity and operational criticality: Place financial systems, customer databases, and authentication infrastructure on separate VLANs with firewall rules to prevent lateral movement. Use Role-Based Access Control to limit account access across segments.
Implement east-west traffic inspection: Use internal firewalls or network detection tools to monitor traffic between segments. Configure alerts for unusual authentication patterns or unauthorized traffic.
Create a protected recovery segment: Establish a network zone for backup infrastructure, incident response tools, and alternative communication systems. This segment should have no inbound access from production networks and require hardware token authentication.
Phase 2: Backup Architecture and Testing (Weeks 2-6)
Build backup systems that withstand encryption attempts:
Deploy immutable storage: Set immutability periods that exceed your maximum restoration time. If restoration takes three days, set a seven-day immutability window. Even if attackers gain backup admin credentials, they can't delete protected snapshots.
Establish air-gapped copies: Maintain offline backup copies on removable media stored separately. Rotate these weekly for critical systems and monthly for less critical infrastructure.
Test restoration under adversarial conditions: Simulate scenarios where your backup server is compromised, your primary admin account is locked out, or your documentation is encrypted. Can you still recover? Your test should measure how long critical services stay down, not just data recoverability.
Phase 3: Alternative Operations Capability (Weeks 4-8)
Develop workarounds for encrypted primary systems:
Document manual processes: Write procedures for each critical business function that don't rely on primary IT systems. Berlin staff used phones and faxes when email failed. What's your equivalent? Document it now.
Establish shadow IT infrastructure: Deploy a minimal parallel environment for incident response. This might be a separate Microsoft 365 tenant, a standalone Slack workspace, or a hosted wiki on a different cloud provider. Pre-populate it with runbooks and contact lists.
Pre-position communication tools: Issue hardware tokens, satellite phones, or encrypted messaging apps to your incident response team. Test them quarterly. When your primary identity provider is compromised, you can't reset passwords or provision new access.
Phase 4: Incident Response Integration (Weeks 6-10)
Connect your no-pay infrastructure to incident response procedures:
Update your playbooks: Revise your ransomware response runbook to reference your segmented architecture, backup systems, and alternative communication channels. Specify which systems get disconnected first and who authorizes it.
Define no-pay criteria: Document conditions under which you'll refuse ransom payment. This isn't a blanket policy. It's a decision tree based on data sensitivity, restoration time, regulatory exposure, and operational impact.
Integrate with legal and communications: Your legal team needs templates for ransom refusal communications, breach notifications, and regulatory filings. Your communications team needs holding statements for employees, customers, and media. Draft these now.
Validation: How to Verify It Works
Run a tabletop exercise simulating a Rhysida-style attack:
Scenario: Attackers exfiltrate 5.79 terabytes of data over five days before encrypting systems. They demand payment within seven days and publish a sample of stolen data.
Test objectives:
- Can you disconnect affected systems within two hours of detection?
- Can your incident response team coordinate without email or primary collaboration tools?
- Can you restore critical services from backups within 72 hours?
- Can you process regulatory notifications while managing the technical response?
- Can you maintain essential business functions using manual processes for one week?
Measure time to containment, time to restoration, and percentage of critical services maintained during recovery. If you can't meet your targets, you haven't built sufficient no-pay capability.
Maintenance and Ongoing Tasks
A no-pay posture requires continuous investment:
Monthly: Test backup restoration for a randomly selected critical system. Rotate air-gapped media. Verify alternative communication systems still function.
Quarterly: Run tabletop exercises with different attack scenarios. Update runbooks based on infrastructure changes. Test manual business processes.
Annually: Audit network segmentation effectiveness. Review and update your no-pay decision criteria. Validate that new systems are incorporated into backup and continuity plans.
After any significant change: When deploying new applications or reorganizing teams, update your segmentation rules, backup coverage, and incident response procedures immediately.
Berlin's refusal to pay wasn't just a policy statement. It was possible because they contained the breach, maintained election system security, and kept ministries operational despite IT disruption. Build that capability before you're deciding whether to fund ransomware operators with a countdown timer running.
