On or about June 10, 2025, Operation PAR, Boley Centers, and PEMHS dba Eleos — three behavioral health organizations with addresses in Pinellas Park and St. Petersburg, Florida — detected unauthorized access to their network. The access window was June 6 to June 10, 2025. Notification letters reached 145,714 people starting June 25, 2026.
Detection took four days. Notification took 380.
The joint notice is unusually specific about why, and the sequence is worth reading closely:
Following the completion of our investigation, it was determined that some of our files may have been accessed or removed by the unauthorized individual(s) between June 6, 2025 and June 10, 2025. We conducted a thorough review of the potentially impacted data and on June 10, 2026, we determined that the impacted files may have contained your personal information.
Those are two separate findings. Files were taken. Then, 365 days later, what was in them. The delay is entirely in the second one.
What the gap is made of
As of August 3, 2026, no initial access vector has been publicly disclosed, so this isn't a story about how anyone got in. It's about what happens after, which generalizes to any organization running a file server.
An intrusion investigation resolves quickly because the questions have log-shaped answers. Which hosts were touched, which accounts authenticated, how many gigabytes left the network and when. EDR telemetry, firewall flow records, and disk images produce those answers in days to weeks.
Notification requires a different answer: which specific people are in the files that left. That is not a security question, it's a content question, and after the fact the only way to answer it is to open the documents. On a share that has been accumulating since the last server migration, that means classifying hundreds of thousands of PDFs, scanned intake forms, spreadsheets, and email exports nobody has looked at in years. Vendors sell this as a service. It takes months, and the output still has to be deduplicated against a client roster.
Nobody decided to build that problem. Shares grow one folder at a time, each addition locally reasonable, and the aggregate is only ever examined under exactly these circumstances. HIPAA's notification ceiling is 60 days from discovery. Meeting it requires knowing the contents of your repositories before the incident, because a year is roughly what it costs to find out afterward.
There is a second clock running during that year. Worldleaks listed Operation PAR on its leak site on July 21, 2025 — 339 days before the letters went out. The determination process is not a private administrative delay. It runs while the data is already public.
The practice: pre-compute the answer for the shares that matter
Not every repository. The ones an attacker can reach from a compromised workstation or service account, which is a much shorter list than your total storage.
- Enumerate reachable shares, not all shares. From a standard user account and from each service account, list what actually mounts. The gap between that list and the documented one is where this problem lives.
- Run a content classifier over them for regulated identifiers — SSN, DOB paired with name, MRN, driver's license, payment card. Microsoft Purview does this if you're already in E5; open-source options exist if you're not.
- Record the output with a date: repository → data classes present → approximate record count → owner. That table is the first draft of a notification list.
- Re-run it quarterly. Shares drift.
The cost is mostly tuning. Nine-digit matching produces enormous false positives — invoice, account, and part numbers all look like SSNs to a regex — so the first pass returns a set nobody trusts, and someone spends a week tightening rules and validating samples. Full scans are also I/O heavy enough to need an off-hours window on production file servers.
The less-discussed cost is that a scan finds data you're then obligated to act on — the 2014 intake forms nobody knew were still there. That's the actual reason this gets deferred. Name it when you propose it; it surfaces later regardless.
If you can't do the scan this quarter, the cheaper fallback changes the problem from "read every file" to "query which files that session opened." On Windows, enable Advanced Audit Policy → Object Access → Audit Detailed File Share, which writes event 5145 per file-level access attempt over SMB:
auditpol /set /subcategory:"Detailed File Share" /success:enable /failure:enable
Event 5145 is high-volume — that's why it's off by default — and it's a real SIEM ingest cost to size before enabling. Still cheaper than the alternative, and only useful if retention exceeds your realistic dwell time. Ninety days of 5145 does nothing for an intrusion you find in month five.
What to check this week
- From a standard user account, list every share that mounts. Compare it to the documented inventory.
- For your three largest shares: can anyone tell you, in writing and within a day, what classes of regulated data are in them? Time the answer. That interval is your notification timeline.
- Is object-access or detailed file-share auditing enabled anywhere? If yes, what's the retention window?
- Is log retention longer than the dwell time you'd realistically expect?
- Does your incident response plan assign an owner to the data-determination step, separate from the containment owner? In most plans it has no owner, because nobody expected it to be the long pole.
Related: why a year-long determination can still be a compliant number · the same gap in a cloud data store, where six days of access took 100 days to scope
North InfoSec runs AI-assisted penetration testing and security assessments, including the reachability testing described above. northinfosec.com