The Incident Outgrew the Org Chart
What the Berlin ransomware attack reveals about cyber incident response, executive decision-making and decision authority under pressure.
In August 2026, a ransomware attack on Berlin's state network began as a containment and forensic problem. Over the following weeks, the Rhysida ransomware incident expanded into data theft, extortion, public disclosure, citizen and employee exposure, and renewed operational measures.
Berlin responded as the situation evolved. Two affected Senate administrations were isolated from the state network. An IKT emergency crisis team was established. The administrations were later reconnected. Additional data exfiltration was discovered. Berlin rejected an extortion attempt. Stolen data was published. Then a further data package containing access credentials appeared.
On September 5, Berlin established an additional central steering unit under the Chief Digital Officer to coordinate review of the stolen information and support the affected administrations.
From the outside, we cannot know every factor behind those decisions, nor should we pretend to. What the public sequence does reveal is something more useful: as the incident changed, the decision environment changed with it.
That creates a governance question every organization should be ready to answer: when an incident moves beyond the structure you started with, does decision authority move with it?
An incident-response structure has to evolve when the decisions evolve
Berlin's response shows why a complex cyber incident cannot always be managed as a single-function problem. As the incident progressed, questions involving cybersecurity, restoration, law enforcement, extortion, data protection, citizen notification, operational availability and public communication all became relevant.
There is no public basis for concluding that Berlin experienced a decision-authority failure. The more useful lesson is that a changing incident can create new decision requirements, new stakeholders and new consequences that the original response structure must absorb.
That is why executive teams should distinguish between knowing who participates in an incident and knowing who is authorized to make each consequential decision.
The question is not simply, "Who owns the incident?" It is, "Who owns this decision, under these conditions, right now?"
A ransomware incident can quickly become an executive cyber crisis
Berlin's public timeline shows how quickly the nature of an incident can change.
On August 14, two affected Senate administrations were isolated from the state network. On August 17, an IKT emergency crisis team was established under Berlin's state information-security leadership to coordinate additional security measures and forensic investigations. Law enforcement, prosecutors and Germany's Federal Office for Information Security were involved.
By August 23, the two administrations had been reconnected to the state network, although forensic investigations and heightened monitoring continued.
Three days later, Berlin announced that investigators had identified additional data exfiltration that occurred before the August 14 network isolation. Officials said the scope and contents were still under review and that personal or other non-public information could be involved.
The immediate decision problem had changed. Containment and restoration were no longer the only concerns. The incident now carried potential privacy, legal, operational and public consequences.
An incident-response structure designed for the opening phase of a crisis may not be sufficient for the phase that follows. Organizations should define how decision authority changes when the consequences expand, new stakeholders enter the response, or the incident crosses functional boundaries.
What specific change in consequence, severity or scope causes decision authority to move beyond the team that initially owns the incident?
Incident ownership is not decision ownership
Organizations often ask who "owns" a cyber incident. That can be useful for establishing operational leadership, but effective cyber incident response requires more than identifying who owns the technical response. It does not answer every governance question the incident will create.
A CISO may lead the cybersecurity response. Legal may interpret regulatory and disclosure obligations. Operations may determine what level of disruption the organization can tolerate. Communications may advise on public messaging. Law enforcement may control aspects of a criminal investigation. Senior executives may own enterprise-level consequences.
All of those responsibilities can exist at the same time.
Berlin's situation illustrates why a single incident can require many different decisions. Someone must decide whether systems remain isolated or return to service. Someone must determine how newly discovered data loss changes the response. Someone must decide how to address extortion. Someone must determine who needs to be informed when stolen information becomes public. Someone must decide whether new evidence requires additional operational restrictions.
Those are not necessarily the same decision, and they do not necessarily belong to the same person.
"Who owns the incident?" may be too broad a governance question. A more operational model identifies who owns each consequential decision, what triggers that authority, when another function becomes involved, and who has the deciding authority when legitimate responsibilities overlap.
If Cybersecurity, Legal, Operations and Communications all have legitimate stakes in the same incident, who owns which decisions?
Cyber incident escalation requires more than coordination
Crisis teams, cyber incident response groups and steering committees are essential because complex incidents require multiple perspectives, clear escalation paths and coordinated action.
But coordination and authority are different.
A meeting can bring the right people together and still leave a consequential question unresolved. Who can make the call? Who can approve an action? Who can override it? Does everyone need to agree? What happens when two leaders with legitimate responsibilities reach different conclusions?
On September 5, after stolen Berlin government data had been published, the Senate Chancellery established an additional central steering unit under Chief Digital Officer Florian Hauer. According to Berlin, the unit coordinates the review, examination and assessment of the leaked data and supports the two affected Senate administrations in informing and advising affected citizens and businesses.
The unit includes Berlin's State Criminal Police Office, the affected administrations, the state data-protection authority, information-security leadership and other security authorities. It also coordinates the notification of state and federal bodies when security-relevant data is involved.
We cannot infer from that announcement how every internal decision right is allocated. What we can see is that the decision environment had become broader than the technical investigation that began in August.
Organizations should design both coordination and authority. Coordination establishes who needs to contribute. Decision authority establishes who can act when consultation is complete, consensus is unavailable, or time does not permit another round of discussion.
When your incident team cannot reach consensus on a consequential action, who has authority to decide?
New information can change who needs authority
Cyber incidents rarely unfold with complete information. New evidence can change the operational picture after containment measures have already been taken and recovery has begun.
Berlin's sequence demonstrates that clearly. The affected administrations were reconnected to the state network on August 23. Additional exfiltration was announced on August 26. Berlin publicly rejected an extortion attempt on August 28. On September 3, officials said the group Rhysida claimed to possess approximately 5.7 terabytes of stolen data and was offering it for auction.
The data was subsequently published. On September 6, Berlin reported that the attackers had released an additional package containing access credentials. The responsible Senate administration reassessed measures already taken and tightened some of them as a precaution. Berlin warned that those additional measures could temporarily affect the use of some administrative systems.
That is a governance reality worth paying attention to: a decision that was reasonable with yesterday's information may need to be revisited when today's information changes the risk.
Decision authority should include conditions for re-evaluation. Organizations need to know not only who can make the initial decision, but what new information triggers reconsideration, who can reopen the decision, and whether additional authority is required when the consequence changes.
What new evidence would automatically force your organization to revisit a decision it already made during an incident?
Ransomware response decisions often happen before the investigation is complete
One of the hardest parts of ransomware response and cyber crisis management is that executives often need to make consequential decisions before the organization knows everything it would like to know.
Berlin's August 26 announcement is a useful example. Officials knew additional data had been exfiltrated, but the contents and scope were still under review. They could not yet rule out the involvement of personal or other non-public information. The forensic work continued.
The organization still had decisions to make.
That distinction matters. Forensic certainty and operational necessity do not always run on the same clock. Legal, privacy, communications, security and operational leaders may need to act based on credible indicators, thresholds and potential consequences before the technical picture is complete.
The answer is not to lower the standard for consequential decisions. It is to define in advance what level of uncertainty the organization is willing to tolerate for different categories of action.
Mature decision governance does not assume that certainty will arrive before action is required. It establishes what evidence is sufficient for a given decision, which thresholds activate authority, when precautionary action is permitted, and who can authorize escalation as the facts develop.
Can your executives act when the consequence is becoming clear but the full technical picture is still being investigated?
Decision authority has to move with the incident
Berlin's evolving ransomware incident points to five capabilities leadership teams should pressure-test as part of cyber incident response planning.
1. Define decisions, not only participants
An incident plan should identify more than who joins the response. It should establish who owns the consequential decisions the organization is likely to face.
2. Map authority to thresholds and consequences
Decision rights should change when severity, operational impact, regulatory exposure, safety implications or other consequences cross defined thresholds.
3. Build succession into the model
Critical decisions cannot depend on one person being reachable. Organizations should know who inherits authority, under what conditions and with what limits.
4. Define cross-functional decision rights
When Cybersecurity, Legal, Operations, Communications and executive leadership all have legitimate interests, the model should clarify who advises, who decides and who can override.
5. Exercise how authority changes
Tabletops should not test only the incident everyone expected. They should introduce new evidence, new consequences and unavailable decision-makers to see whether authority can evolve without unnecessary delay.
The incident you start with may not be the incident you are managing three hours, three days or three weeks later
Berlin's experience should not be reduced to a scorecard of what outsiders think officials did right or wrong. We do not have the information, context or operating constraints required to make that judgment responsibly.
What we can examine is the structure of the decision problem. A cyber event began with network isolation and forensic investigation. It expanded into restoration, additional data loss, extortion, public disclosure, privacy concerns, citizen and business notification, security-sensitive information and renewed operational measures.
Each change introduced different decisions and different stakeholders. That is exactly why organizations should establish decision authority before a crisis forces them to negotiate it under pressure.
The question is not whether your incident-response plan can handle the incident you anticipated. It is whether your decision-authority model can adapt when the incident becomes something else.
Your incident plan may define who is involved. Does it define who can decide when the incident changes?
The Governance Continuity Assessment is a focused working session for leadership teams that want to identify where responsibility, decision authority, cyber incident escalation and succession may separate under pressure.
- Identify consequential decisions that may not have an explicit authority owner
- Clarify where authority changes when severity, consequence or scope crosses a threshold
- Surface dependencies on executives who may not be available when the decision is required
- Examine where Cybersecurity, Legal, Operations, Communications and executive authority overlap
- Identify which parts of the authority model should be pressure-tested before an incident does it for you
Sources
- State of Berlin, "IKT-Vorfall im Landesnetz Berlin," August 17, 2026. View source
- State of Berlin, "Senatsverwaltungen wieder ans Landesnetz Berlin angebunden," August 23, 2026. View source
- State of Berlin, "Mehr Daten beim IKT-Vorfall abgeflossen," August 26, 2026. View source
- State of Berlin, "Der Regierende Bürgermeister Kai Wegner und Innensenatorin Iris Spranger: 'Das Land Berlin lässt sich nicht erpressen'," August 28, 2026. View source
- State of Berlin, "Aktuelle Lage nach dem IKT-Vorfall im Landesnetz Berlin," September 3, 2026. View source
- State of Berlin, "Aktuelle Lage nach dem IKT-Vorfall im Landesnetz Berlin und der Veröffentlichung der gestohlenen Daten," September 4, 2026. View source
- State of Berlin, "Aktuelle Lage nach dem IKT-Vorfall – Zentrale Steuerungseinheit in der Senatskanzlei eingerichtet," September 5, 2026. View source
- State of Berlin, "Nach dem IKT-Vorfall – Weiteres Datenpaket veröffentlicht," September 6, 2026. View source
Source note: This case study is based on public statements issued by the State of Berlin between August 17 and September 6, 2026. The incident remains under investigation. Public reporting does not disclose the full internal decision structure, authority assignments or information available to officials at each stage. This analysis therefore does not assess whether Berlin made the "right" or "wrong" decisions. It examines what the publicly documented evolution of the incident reveals about the decision-authority questions other organizations should be prepared to answer.