Operation PAR, a substance-use-disorder treatment nonprofit in Pinellas Park, Florida, detected unauthorized access to its network on June 10, 2025. In its own words, from a notice dated June 24, 2026: "Following the completion of our investigation, it was determined on June 10, 2026 that the impacted files may have contained some personal information." Notification of affected individuals began June 25, 2026, and the HHS Office for Civil Rights breach portal records the submission that same day — 145,714 individuals, type "Hacking/IT Incident," location "Network Server."
Detection to determination: 365 days. One year to the day. Determination to notification: 15 days.
That second number is the one that explains the first.
Why a year is a compliant number
The HIPAA Breach Notification Rule requires notice no later than 60 days after discovery of a breach. A breach is discovered when the covered entity determines that unsecured protected health information was compromised — not when it notices an intruder. Operation PAR determined that on June 10, 2026 and notified 15 days later. On its face that is compliant, and nothing here suggests otherwise.
The clock is anchored to a date the breached organization computes for itself. What computes it is evidence.
The phrasing in the notice — "the impacted files may have contained some personal information" — tells you which kind was available. That is the language of an investigation that scoped the breach by reading the files, not by reading the logs. With file access logging on the affected share, scoping is a query: here are the objects that identity touched between these timestamps. Without it, the only remaining method is to take everything the attacker could plausibly have reached and review its contents, document by document.
That is not a forensics project. It is a document review project, and it is priced and paced like one. For a fifty-year-old treatment provider whose file server holds decades of intake paperwork, discharge summaries, and billing records, a year is roughly what that corpus costs to review.
The practice: make the corpus small enough to scope from logs
Two levers set the length of that review, and both are configured long before the incident.
Turn on object access auditing where regulated data actually lives. Most Windows environments have file system auditing off, because enabling it globally produces an unusable volume of Event ID 4663. The version that works is narrow: pick the two or three shares that hold regulated records, put a SACL on those paths only, and leave the rest of the estate alone.
auditpol /set /subcategory:"File System" /success:enable /failure:enable
$acl = Get-Acl -Path "D:\Shares\ClinicalRecords" -Audit
$rule = New-Object System.Security.AccessControl.FileSystemAuditRule(
"Everyone","Read,Write","ContainerInherit,ObjectInherit","None","Success")
$acl.AddAuditRule($rule); Set-Acl -Path "D:\Shares\ClinicalRecords" -AclObject $acl
The cost is worth stating plainly: even scoped to a few shares this is a meaningful event volume, and it only pays off if you ship those events somewhere with retention measured against your worst-case investigation rather than your storage budget. Ninety days is the common default and it is useless here. The intrusion was detected on day one; the question "which files" stayed open for a year. Logs that rolled off at ninety days would have answered nothing.
Then shrink what has to be reviewed. Auditing tells you which objects were touched; that doesn't help if 400,000 of them are in scope. The lever is retention on the data itself. Most organizations holding regulated records have no deletion schedule at all, so the corpus grows monotonically and the forensic cost of an intrusion grows with it. Eighteen months of documents is a few weeks of review. Twenty years is a year.
If neither is possible this quarter — a realistic answer for a small IT team with no dedicated security function — the compensating step is a data map: for each file server and share, one line recording what category of regulated data it holds and roughly how much. It takes an afternoon. It doesn't shorten the review, but it is the first artifact an incident response firm asks for, and producing it on day one instead of week six moves the whole timeline left.
What to check this week
- What is the actual retention on your file server and identity provider logs, in days? Not the policy — the configured value.
- Pick your most sensitive share. Can you produce a list of every file a given account read from it last Tuesday? If not, that is how you would scope a breach.
- Is there a deletion schedule on regulated records, and has anything ever been deleted under it?
- For each file server, do you know which categories of regulated data it holds? Write it down if not.
- Ask whoever would run your incident response what they would need on day one, and check whether it exists today.
As of August 3, 2026, neither Operation PAR's notices nor the OCR record names the initial access vector, so none of the above is a claim about how the intrusion started. It is about what determines the interval afterward — and that interval is set by logging and retention decisions made years before anyone gets in.
Related: why the determination took a year in the first place · the same determination gap at a cloud EHR vendor
North InfoSec runs AI-assisted penetration testing and security assessments, including tracing which systems can reach regulated data stores and what evidence that access leaves behind. northinfosec.com