Systems contained, data exposed: why Columbus’s reassurance outran its evidence

Columbus could prove it had contained the attack on its systems. It could not yet prove what the stolen data held or whom it exposed. Each claim needs its own evidence, and borrowing from the first to answer the second costs trust.

Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.

The week

On July 18, 2024, the City of Columbus, Ohio, found signs of an intrusion and disconnected its systems from the internet. City officials said the move had stopped the attackers before they could encrypt city systems, though many online services and internal tools stayed disrupted for weeks. Around July 31 and August 1, the Rhysida ransomware group claimed the attack and put data it said it had taken from the city up for auction. It said it held about 6.5 terabytes and set a price in bitcoin. The city’s technology director later said the city had not received a ransom demand. In the first week of August, residents, employees and local media were asking the question that shaped the following month: what was in the stolen data, and whose information was it?

A city hit by ransomware makes three kinds of public claim. It makes claims about its systems: what was hit, what was contained, what is back. It makes claims about the data: what was taken and whether it is readable. And it makes claims about people: who is affected and what they should do. Each claim rests on different evidence, gathered by different teams on different timelines. Columbus had good evidence for the first claim early. Its trouble came when confidence about the systems was carried over to the data before anyone had read it. The three claims below are taken in the order in which the evidence usually arrives.

Claims about systems

Containment evidence comes from the incident responders. Endpoint telemetry, network logs and the state of backups show whether encryption ran, which hosts were touched and when service can return. This evidence arrives within days. It supports confident statements, such as that systems were disconnected in time to prevent encryption and that a named service is restored.

It does not support statements about what left the network. Exfiltration often happens before the defenders notice anything, and stopping encryption says nothing about files already copied. Communication plans should keep the two apart in their templates. A sentence of the form we stopped the attack belongs to the systems track. Any sentence about the impact on residents belongs to a different track, with different sign-off. Even systems claims have a shelf life. Forensic work can later find persistence or an earlier entry point than first thought. Dating each statement, as known on a given day, leaves room to update it without a retraction.

For elected officials, the systems track is also where the pressure to reassure is strongest. A mayor or county executive needs language that is accurate and useful, such as which services work, which workarounds exist and when the next update will come. Giving them that language reduces the temptation to say more.

Claims about data

Evidence about stolen data comes from analyzing the data itself. Until the organization has a copy of what was taken, or a forensic reconstruction of what was staged and sent out, any statement about its contents is a forecast. Columbus’s public account in mid-August, that the published files were largely encrypted or corrupted, was a claim of this kind. Within days a local security researcher and news organizations showed readable personal information in the leak.

The fix is procedural. When a ransomware group claims data, the organization needs a team ready to acquire whatever is published, in a controlled environment and with counsel’s guidance on handling. That team should index the material and classify it by data type within days, not weeks. Large leaks are searchable with ordinary tools. Corrupted archives often contain intact files. Backups and database dumps hold more personal data than the file shares people think of first. Outside forensic firms can do this work, but the contract and the legal arrangements need to exist before the incident. Agreeing them during one costs days.

If that analysis is not done fast, someone else does it. Journalists and independent researchers will open the leak. Their findings will then define the public record, and the organization is left reacting. Suing or seeking to silence them draws more attention to the leak. It also casts the organization as an opponent of the people who found the problem.

Claims about people

The third claim, who is affected, needs a further step: turning records into individuals. That means matching names, addresses and identifiers across files, removing duplicates, and finding contact details for notice. It also means identifying groups at heightened risk. A city holds data on police officers, prosecutors, crime victims, witnesses and juveniles, and exposure of their records can raise physical safety concerns as well as fraud risk.

This step drives notification under state breach law, so counsel should be involved in setting scope. It also drives practical help, such as credit monitoring, identity restoration support and a staffed call line. For at-risk groups it may mean direct contact by the police department or prosecutor’s office rather than a form letter, plus advice on home address protection.

Statements about people should therefore follow the analysis, not lead it. Early on, the honest message is about process: the city is analyzing the data, here is when residents will hear more, here is what anyone can do now, such as freezing credit. That message is less satisfying than reassurance. It holds up when the leak is examined.

Most of this can be prepared before an incident. The materials are a template set split into the three claim types, a pre-contracted data analysis capability, and a map of where the city keeps its most sensitive personal records. The map should cover law enforcement, courts, utilities, licensing and payment systems, so that exposure can be judged quickly once files appear.

With hindsight

Rhysida published a large part of the data around August 8, 2024, after the auction found no buyer. On August 13 Mayor Andrew Ginther said the published data was encrypted or corrupted and of little use. A local security researcher and news reports showed it contained readable personal records, including material on police officers, prosecutors and crime victims. On August 29 the city sued the researcher and obtained a temporary restraining order limiting his sharing of the data, which drew criticism from press freedom and security groups. The city later notified about 500,000 people that their information was involved, and offered credit monitoring. In October 2024 the city dropped the suit, with the researcher agreeing to a permanent injunction on sharing personal data from the leak. Ransomware groups have kept publishing local government data since. The order of evidence described here, systems first, then data, then people, has not changed.

  • Columbus
  • ransomware
  • Rhysida
  • breach communications
  • local government