Craneware Group
Nobody outside healthcare finance has heard of them. Their software touches the billing operations of hospitals across the United States.
What happened?
Craneware Group was listed as a victim on the Chaos ransomware group's leak site on July 29, 2026. Craneware builds revenue cycle and value cycle software for hospitals and health systems — chargemaster management, pricing, coding integrity, and revenue analytics. The company is listed in the UK and conducts the substantial majority of its business in the US provider market.
The listing has not been independently verified and the company has not, as of this writing, issued a public confirmation. Leak site entries are claims. What follows treats the listing as unconfirmed and analyses the sector exposure it points to.
What data was actually inside?
The specific data types have not been publicly disclosed as of this writing.
Based on the function of revenue cycle software, the environment would be expected to contain charge and billing data, procedure and diagnosis codes, payer contract terms and negotiated rates, and patient account records — with the depth depending heavily on whether a given customer runs the software on-premise or in a hosted deployment. This is an inference from product function, clearly labeled as such, not a confirmed inventory.
Two distinct categories of sensitive material sit in that list. Protected health information belonging to patients, and negotiated payer rates belonging to the hospital — commercial terms that health systems treat as among their most closely guarded secrets.
Who gets hurt and how?
If patient-level data was involved, the harmed parties are people who received care at client hospitals — again, individuals with no relationship to the vendor and no knowledge it processes their information. Procedure and diagnosis codes describe medical events precisely; CPT and ICD codes are not ambiguous about what happened to a person.
The commercial harm falls on the hospitals. Exposed payer contract terms reveal what each insurer actually pays a given health system for a given procedure — information that materially weakens the hospital's position in every future negotiation and that competitors, insurers, and employers would all find valuable. There is no notification statute for that. There is also no remedy.
What did they think they were doing right?
While not publicly confirmed, healthcare software vendors serving US hospitals operate as HIPAA business associates, execute business associate agreements with every client, and typically maintain HITRUST or SOC 2 attestation because health system procurement requires it. A publicly listed company additionally carries disclosure obligations and board-level security oversight.
The health systems on the other side did their part too. They ran vendor security assessments, executed BAAs, and documented the relationship in their third-party risk register. Every control the industry prescribes for this situation was almost certainly in place.
What none of those controls establish is how much data actually moved. A BAA governs handling. It does not enumerate volume.
What did they not know about their own data?
Health systems inventory the EHR obsessively. It is the system of record, it is audited, its access logs are reviewed, and everyone knows what is in it. Then they extract from it — into revenue cycle platforms, coding tools, denial management systems, quality reporting, and analytics warehouses — and the extracts are almost never re-inventoried after go-live.
Each extract is as sensitive as the original and receives a fraction of the scrutiny. The initial data flow was scoped during implementation, often years ago, by a project team that has since dispersed. Nobody re-checks whether the nightly feed is still sending the fields it was scoped to send, or whether a subsequent module expanded it.
This is why vendor incidents in healthcare produce such slow attribution. When a revenue cycle vendor is listed, every client hospital has to answer "what did we send them, and for how long?" — and for most, that answer has to be reconstructed rather than retrieved.
If you handle patient data, could you identify within 24 hours exactly which records were accessed in a breach?
What does attribution look like the morning after?
A business associate breach cascades. Under HIPAA, the business associate must notify each affected covered entity, and each covered entity then runs its own analysis to determine which of its patients require notification — meaning the vendor's single incident becomes dozens of parallel breach investigations, each with its own counsel, its own timeline, and its own filing on the OCR breach portal.
The 60-day HIPAA clock runs from discovery, and hospitals frequently discover through the vendor rather than independently, which compresses their available time. Craneware's UK listing adds a second dimension: UK GDPR obligations and a 72-hour ICO notification requirement for any personal data of UK data subjects, running concurrently with the US analysis. For a publicly traded company, materiality assessment runs alongside both.
What would have changed the outcome?
A live record, on the hospital side, of exactly which PHI elements flow to each downstream platform — so a vendor listing triggers a lookup instead of an archaeology project.
Every system you extract protected health information into becomes a system you must be able to speak for, to a regulator, on a 60-day clock. The BAA allocates liability but produces no visibility, and the implementation-era data flow diagram stopped being accurate the first time someone added a field. Health systems that can answer the vendor question quickly are the ones treating extract inventories as a standing obligation rather than a project artifact. See also our analysis of the MCBS billing vendor breach, where the same cascade took eight months to resolve.
Craneware Group found out the hard way.
Your team could spend the next 6 months rebuilding systems, notifying customers, and answering legal questions. Or you could spend 24 hours finding out what's actually at risk.