On July 31, 2026, an entity called Interim HealthCare of Oklahoma City, Inc. filed a breach report with HHS OCR: state OK, healthcare provider, 500 individuals, Hacking/IT Incident, protected health information in "Email, Network Server." Ten days later the Genesis ransomware group listed Interim HealthCare on its leak site, claiming roughly 1 TB attributed to the Oklahoma and Tulsa operations. Eleven days after that, on August 21, a second group — Anubis — listed the company claiming about 530 GB, corporate records rather than patient records. Both listings are attacker claims. The dates and volumes come from The HIPAA Journal's September 9 report, which stated the company had confirmed neither; teiss reported on September 13 that Anubis had gone on to release the data publicly.
The brand in those listings sits at 1551 Sawgrass Corporate Pkwy in Sunrise, Florida. Its own site describes "a national network of independently owned franchise locations" and counts 44 states.
Three organisations, one incident
Line those facts up and the reporting entity, the brand, and the data that allegedly moved are not the same organisation.
The Genesis listing describes patient material attributed to two Oklahoma operations. The Anubis listing, per The HIPAA Journal, claims "financial information about franchisees, details of internal and external audits" — material that belongs to whoever administers the franchise network, not to a home health office in Tulsa. Only one of those descriptions matches the entity that filed.
Two groups naming one victim is not necessarily two intrusions, and it is not necessarily one. It can be an affiliate who changed crews, access resold, or one group recycling another's dump. The defensive consequence is the same either way and it is unwelcome: you cannot scope an investigation off a listing, because a listing describes what an extortionist chose to advertise. The publication schedule belongs to the attacker, and so does the inventory.
I re-queried the OCR portal on September 30 — all 767 filings currently under investigation — and Interim HealthCare of Oklahoma City, Inc. is still the only matching row, still at 500. That is the threshold at which a breach appears on the portal at all, and a figure that commonly moves once a review finishes. Sixty-one days on, no corporate entity and no sibling franchise has filed beside it.
Enumerate what crosses the boundary, then test it
Nothing published establishes how Interim HealthCare's IT estate is arranged, and nothing here claims a franchisor and its franchisees shared anything. The reason the pattern is worth writing about at all is that in most multi-entity estates the contract draws a boundary and the infrastructure decides a different one, and nobody has written down which.
So write it down. For each legally separate but technically connected entity, answer these with an artifact rather than a form field:
- Identity. Is there one directory or several? Can a corporate administrator obtain a token in the unit's tenant — through delegated admin, a break-glass account, or a guest invite nobody revoked? Produce the role assignment list, not a policy statement.
- Clinical and line-of-business systems. Shared tenancy or separate instances? If shared, who holds tenant-admin, and does the unit's support contract give the franchisor a standing login?
- Network. Does a corporate VPN, SD-WAN circuit, or site-to-site tunnel terminate anywhere a unit workstation can route to? Show the route table.
- Backups. Where do unit backups land, and which credential can delete them?
- Managed tooling. RMM agents, EDR consoles, and help-desk software installed by corporate are administrative access into every unit that runs them.
Each of those has an observable answer. A questionnaire asks whether systems are segmented; a directory dump tells you who holds Global Administrator.
This costs about a week per affiliated entity, and it usually ends in a conversation neither side wants, because whoever runs it frequently has no contractual authority to demand the answer. Where you cannot get it, the working substitute is to treat the boundary as untrusted rather than assume it: no standing cross-entity credentials, all shared services reached through one monitored path, and unit backups written somewhere a unit credential cannot delete. That is weaker than knowing, and it is achievable without anyone's permission. It is the same move as bounding what a partner account can pull when you cannot control the device it is used from.
The second half is administrative and costs a meeting. For every affiliated entity, decide now who files, who notifies, who retains counsel, and who owns the forensic image — because an incident response plan with no named trigger does not start itself. In this incident, three answers were plausible and exactly one entity has filed.
What to check this week
- List every legally separate entity in your network and, for each, name the person who would file a regulatory report. If two people name different entities, that is the finding.
- Pull the privileged role assignments in your identity tenant and mark every principal belonging to a different legal entity.
- Confirm whether any franchise, affiliate, or subsidiary credential can reach your backup storage with delete permission.
- Check whether your incident response plan defines who takes custody of forensic evidence when the affected system is owned by an affiliated entity.
- Ask your insurer and outside counsel, in writing, whose policy responds when the breached system sits at an affiliate.
North InfoSec runs AI-assisted penetration testing and security assessments, including scoping work across affiliated and franchised entities. northinfosec.com