Women's Center for Radiology, an Orlando imaging practice acquired by Solis Mammography in January 2026, posted a notice of a data privacy event on June 26 and reported the incident to HHS the same day. The Office for Civil Rights breach portal records 66,422 individuals affected, classified as a hacking/IT incident against a network server. The practice became aware of suspicious activity on April 29; files were accessed in late April, in a window reported as April 26 to April 28. Solis said the unauthorized access reached parts of the legacy WCR systems, and WCR told Radiology Business the event "occurred prior to, and was unrelated to, the migration to Solis systems," with no impact on Solis centers.
The migration window
That last statement is offered as reassurance, and it is also the finding.
The boundary between the acquired practice and the acquirer held, which is not the usual outcome in post-acquisition breaches. But what sat on the other side of it was the legacy environment of a practice that had served central Florida for 36 years — still running, still holding the complete patient record set, three months into an acquisition and partway through a migration that had not finished.
This is the recurring shape, and it has nothing to do with radiology. Migration creates a period — usually months — in which an environment is treated as temporary and operates as production. It stops receiving investment because it is going away. It falls outside the acquirer's security scope because it is not their platform, and outside the acquired team's because that team is being absorbed or wound down. Patching, log review, and access recertification all degrade at precisely the point the system is least defended and still most valuable, because during a cutover the legacy store holds the full historical dataset while the target platform holds only what has been migrated so far.
The initial access vector has not been disclosed. OCR's "network server" is a location, not a vector, so what follows is about the class of failure rather than this specific intrusion.
The practice: give the legacy environment an owner and a deletion date
Write both down at the start of the migration, not at the end.
An owner. Name, in the migration plan, which security team is responsible for the legacy environment during cutover — the acquirer's, the acquired entity's, or a named individual at the MSP. The default answer is nobody, arrived at by both sides reasonably assuming the other has it. This is the same failure mode as the remote management console nobody audits: a system with real access to real data and no one whose job it is to look at it.
A deletion date. Not "after cutover" — a date, with the reconciliation milestones that gate it listed underneath. Here is the honest cost: you cannot delete the source data early. Finance and clinical reconciliation need the legacy system as the authority until validation passes, and that can run a quarter or more past the technical cutover. So the workable version is staged rather than binary:
- Cut external reachability first. This usually costs nothing operationally, because at that point access is internal and administrative. It is the single highest-value step and the one most often deferred to the end.
- Then read-only. Once writes have moved to the target platform, the legacy system does not need write paths, and read-only removes the ransomware outcome even if the exfiltration outcome remains.
- Then archive to offline storage and take the running system down.
If you cannot decommission on schedule, the compensating control is egress, not detection. A legacy imaging or records system has a small, boring set of destinations it legitimately talks to. Bulk transfer of 66,422 records has a shape — volume, duration, destination — that an egress rule can act on when an endpoint alert does not.
That emphasis on prevention over detection is deliberate, because this practice detected well and it did not help. Access ran April 26 to April 28. Suspicious activity was identified April 29, one day after it ended — a result most mid-size practices would be pleased with. It still produced 66,422 notifications, because for an intrusion whose objective is copying files, the exposure is set by what is reachable, not by how long the attacker stays. Fast detection limits persistence, lateral movement, and re-entry. It does not un-copy data. The lever that would have changed the number is how much of that dataset needed to be live on a legacy server in April at all — which is a data inventory question before it is a security one.
One further date worth noting: April 29 to June 26 is 58 days, inside the 60-day HIPAA notification rule with two days in hand, and that clock runs from determination rather than from discovery.
How to check
- List every system your organization has acquired, merged, or migrated off in the last 24 months. For each, confirm whether it is powered off, and if it is not, name the person responsible for its patching.
- For each still-running legacy environment, check whether anything reaches it from outside your network — VPN, vendor access, a forgotten port forward.
- Ask what the deletion date is. If the answer is a condition rather than a date, the condition has no owner either.
- Pull the egress rules for those systems. If there are none, that is the cheapest control available to you this quarter.
North InfoSec runs AI-assisted penetration testing and security assessments, including reachability testing of the kind described above. northinfosec.com