DEV Community: PolySec

Nonprofit Healthcare Network Agrees to $1.3M Data Breach Settlement

PolySec — Mon, 24 Aug 2026 01:32:11 +0000

A $1.3 Million Settlement Closes Out a 2024 Healthcare Breach

A nonprofit community healthcare network based in Southern California has agreed to pay $1.3 million to resolve a class action lawsuit tied to a 2024 cyberattack that exposed the sensitive data of more than 129,000 people. The settlement gives affected patients several ways to recover money and get free credit monitoring, and it offers a useful case study for any medical practice trying to understand what a breach actually costs after the fact.

The money was agreed to after extended negotiations between the parties, and the organization settled without admitting any wrongdoing or liability. That structure is standard for these cases: settling ends the litigation risk and expense without the defendant conceding fault.

What Class Members Can Claim

The $1.3 million settlement fund covers attorneys' fees and expenses, the cost of administering the settlement, and service awards for the two class representatives who brought the case. Whatever remains after those deductions pays for benefits to class members, and there are three main ways to collect.

Reimbursement for documented losses. Class members can file for up to $5,000 to cover out-of-pocket costs they can document as tied to the breach, such as fraud losses or fees paid to deal with identity theft.
A pro rata cash payment. Even without submitting a documented-loss claim, class members can request a flat cash payment. That amount is estimated at roughly $25 per person, though the exact figure depends on how many people file.
A California statutory payment. Anyone who was a California resident on July 22, 2024, can also claim an additional statutory payment of $75.

On top of the cash options, every class member can sign up for two years of complimentary credit monitoring and identity theft protection. Credit monitoring is often the most practical benefit in breaches like this one, because exposed Social Security numbers can be misused long after the initial incident.

How the Breach Happened

Suspicious activity was first spotted inside certain computer systems on or around July 22, 2024. The organization launched an investigation, which confirmed that an unauthorized third party had reached an email server and pulled out emails and files containing personally identifiable information and protected health information.

The exposed data was extensive, and what each person lost varied from one individual to the next. Across the affected population, the compromised information included:

Names, addresses, phone numbers, and dates of birth
Social Security numbers, driver's license numbers, passport numbers, and birth certificate numbers
Financial account information
Health insurance details, Medicare and Medicaid numbers, medical record numbers, and patient IDs
Medical information such as diagnoses, treatments and procedures, medical histories, allergies, prescriptions, test results, and vital signs
User IDs and passwords, plus vehicle license plate and VIN numbers

That combination of financial, government-ID, and medical data is exactly what makes healthcare breaches so damaging. A stolen credit card can be canceled in minutes. A Social Security number paired with a full medical history cannot be reset, which is why these records sell at a premium and why the fallout can stretch for years.

The Legal Timeline

Notification letters went out to affected individuals starting in December 2024, and the incident was reported to the HHS Office for Civil Rights as involving the protected health information of 129,048 people.

The first class action followed in January 2025, with a second suit filed in early February 2025. The plaintiffs agreed to coordinate, and an amended complaint was filed in June 2025 in the Superior Court of California for the County of Riverside.

The lawsuit argued that the breach was preventable and stemmed from a failure to put reasonable and appropriate cybersecurity measures in place. It brought claims for negligence, breach of implied contract, and unjust enrichment, along with violations of the California Confidentiality of Medical Information Act, California's Unfair Competition Law, and the California Consumer Privacy Act. The defendant denies all of the material allegations.

Key Deadlines to Know

If you received a notice about this settlement, the dates below matter:

September 1, 2026 — deadline to exclude yourself from or object to the settlement
October 1, 2026 — final fairness hearing
October 21, 2026 — deadline to submit a claim

The court granted preliminary approval, and benefits will be paid out after final approval assuming the settlement holds.

The Real Lesson for Medical Practices

Strip away the specifics and the pattern here is familiar. An email server was compromised, files with patient data walked out the door, and the organization ended up paying $1.3 million plus the cost of notifications, credit monitoring, and legal defense. The lawsuit didn't allege exotic hacking. It alleged that basic, reasonable safeguards weren't in place.

That's the part practice owners should sit with. Regulators and plaintiffs' attorneys increasingly ask a straightforward question after a breach: did you know where your vulnerabilities were, and did you do anything about them? The HIPAA Security Rule already requires a risk analysis, yet a missing or outdated one is among the most common findings in OCR investigations.

You don't need to become a cybersecurity expert to answer that question well. PolySec runs in-person HIPAA security risk assessments built for healthcare practices, including on-site vulnerability scanning, network scans, and review of your policies and business associate agreements. You get an audit-ready findings report and a prioritized remediation roadmap, so instead of guessing where your email server or network might be exposed, you have a documented plan and the support to fix what matters most, while your team stays focused on patients.

Frequently Asked Questions

How much can I get from this settlement?
It depends on what you claim. You can request up to $5,000 for documented out-of-pocket losses, an estimated $25 pro rata cash payment, and, if you were a California resident on July 22, 2024, an additional $75 statutory payment. All class members can also claim two years of free credit monitoring and identity theft protection.

What was the deadline to file a claim?
Claims must be submitted by October 21, 2026. The deadline to opt out or object was September 1, 2026, and the final fairness hearing is set for October 1, 2026.

How many people were affected?
The breach was reported to the HHS Office for Civil Rights as involving 129,048 individuals.

Does settling mean the organization admitted fault?
No. The settlement was reached without any admission of wrongdoing or liability, and the defendant denies the material allegations. Settling ends the cost and uncertainty of litigation for both sides.

How can a practice avoid ending up in a similar lawsuit?
Start with a current HIPAA security risk assessment to find and document your vulnerabilities, then remediate them on a defensible timeline. Regular assessments, staff training, and tested safeguards are what regulators and courts look for when judging whether protections were "reasonable and appropriate."

How to Do a HIPAA Security Risk Assessment (Step-by-Step)

PolySec — Tue, 11 Aug 2026 03:26:51 +0000

How to Do a HIPAA Security Risk Assessment (Step-by-Step)

A HIPAA security risk assessment is a written, dated evaluation of every threat and vulnerability to the electronic protected health information (ePHI) your practice creates, receives, maintains, or transmits. Do it well and you get a prioritized list of what to fix and proof that you took security seriously. Skip it or do it superficially, and you hand federal regulators an easy finding if you're ever breached or audited.

This guide walks through the assessment the way the HHS Office for Civil Rights (OCR) actually expects it to be done, the same elements that show up in enforcement actions when they're missing. It's written for practice owners, office managers, and compliance leads who need to get this right without a security background.

Why this matters more than it used to

The risk analysis has been a legal requirement since the HIPAA Security Rule took effect, but the stakes climbed sharply over the past two years. In the fall of 2024, OCR announced the first enforcement action in its "Risk Analysis Initiative," and a total of seven enforcement actions were announced within the first six months. Those weren't paperwork nitpicks. A ransomware attack affecting 14,273 patients led to a $90,000 settlement when the entity had not conducted a risk analysis.

The pattern accelerated through 2025. By the third quarter of 2025, 17 of 19 enforcement actions (89%) in the nine months ending September 30, 2025, were related to ransomware or other cyber incidents. Larger penalties followed bigger breaches: PIH Health settled for $600,000 with a two-year corrective plan after a phishing attack compromised nearly 190,000 records.

Two things drive this. First, healthcare is a top target for attackers because patient records are valuable and often poorly protected. Second, when OCR investigates a breach, the first thing it asks for is your risk analysis, and a conversation about security isn't evidence. You need written records showing what systems you looked at, what data you found, what threats you considered, and what you decided to do about them.

What a HIPAA risk assessment is (and isn't)

A risk assessment is not a firewall, an antivirus subscription, or a checklist your IT vendor signed once. It's an analytical process. A HIPAA risk assessment is the systematic process of identifying where ePHI exists, evaluating threats and vulnerabilities that could compromise that information, determining the likelihood and impact of potential security incidents, and documenting the results.

It also isn't the same as a security evaluation or a gap analysis, even though vendors often blur the terms. A gap analysis compares your controls against a checklist of requirements. A true risk analysis goes further: it looks at your specific environment and asks how ePHI could actually be exposed, how likely each scenario is, and how bad it would be.

OCR has published guidance describing the elements every risk analysis must contain regardless of the method or tool you use. The steps below map to that guidance.

Step 1: Define the scope

Scope is where most weak assessments fall apart. The rule is broad on purpose. The scope of risk analysis includes the potential risks and vulnerabilities to the confidentiality, availability and integrity of all e-PHI that an organization creates, receives, maintains, or transmits.

That means all electronic media, in every location. The scope must include all ePHI in all forms of electronic media. Examples include portable devices such as thumb drives, laptops, and mobile phones as well as individual desktops, email accounts, fax machines, and printers.

Write down the boundaries before you start: which locations, which systems, which vendors, and which workflows are in play. A practice that "forgets" its backup drive, a legacy billing system, or a physician's personal phone used for scheduling has already created the gap an auditor will find.

Step 2: Build an ePHI inventory and map the data flows

You can't protect what you haven't located. Document every place ePHI lives and every path it travels: your EHR, practice management software, email, cloud backups, imaging systems, patient portals, and every vendor that touches patient data.

For each asset, record where the data comes from, where it's stored, who has access, and where it goes. The scope and asset inventory should cover every system, device, application, and vendor that creates, receives, maintains, or transmits ePHI, plus a map of how ePHI flows between them. This map becomes the backbone of everything that follows, because you'll evaluate threats asset by asset.

While you're at it, pull your business associate agreements (BAAs). Every vendor with access to ePHI needs a signed BAA, and a missing or outdated one is its own compliance problem.

Step 3: Identify threats and vulnerabilities

With your inventory in hand, list what could go wrong for each asset. A threat is a potential source of harm; a vulnerability is a weakness that a threat could exploit. Once scope is defined, you must identify potential threats (sources of harm) and vulnerabilities (weaknesses that could be exploited) relevant to your environment.

Be specific and be complete. OCR guidance notes that risk analysis should consider all reasonably anticipated threats. Threats fall into a few buckets:

Human and malicious: phishing, ransomware, stolen credentials, a departing employee copying records.
Technical: unpatched software, weak or shared passwords, unencrypted laptops, misconfigured cloud storage.
Environmental and physical: fire, flood, power loss, an unlocked server closet, a laptop left in a car.

Generic categories aren't enough. Tie named threats to specific assets. "Ransomware encrypting the on-premise EHR server that lacks offline backups" is a finding an auditor can respect. "Cybersecurity risks" is not.

Step 4: Assess your current safeguards

For each threat and vulnerability, document the controls you already have in place and whether they actually work. HIPAA groups safeguards into three families: administrative (policies, training, access management), physical (locks, facility access, device controls), and technical (encryption, audit logs, authentication).

The key word is evidence. The current safeguard evaluation covers the administrative, physical, and technical controls already in place, with evidence. Saying you have "security awareness training" means little without records of who was trained and when. Encryption on paper means nothing if half the laptops aren't actually encrypted.

Step 5: Determine likelihood and impact

This is the analytical heart of the assessment and what separates a real risk analysis from a checklist. For every threat-vulnerability pair, you estimate two things: how likely it is to happen and how much damage it would cause.

The level of risk is determined by analyzing the values assigned to the likelihood of threat occurrence and the resulting impact of threat occurrence. Risk is a function of the likelihood of a given threat exploiting a specific vulnerability and the resulting impact.

A simple, defensible approach is a rating scale, low/medium/high for both likelihood and impact, combined into an overall risk level. An unencrypted laptop holding thousands of records is high impact; if it leaves the building daily, it's also high likelihood, which puts it near the top of your list. Document your scoring method so a reviewer can follow your logic.

Step 6: Assign risk levels and prioritize

Combine likelihood and impact into a risk rating for each item, then rank them. This should produce a documented scoring method that yields a prioritized risk level for each risk. The output is a risk register: a ranked list that tells you, and any auditor, exactly where your worst exposures are and which to tackle first.

Prioritization matters because no practice can fix everything at once. Regulators don't expect perfection; they expect you to identify your highest risks and address them in a reasonable order.

Step 7: Document everything

If it isn't written down, it didn't happen, as far as OCR is concerned. Your assessment needs to capture what you reviewed, what patient data you found, what threats you considered, what controls existed, how you rated each risk, and what you decided to prioritize. Weak documentation is often the deciding factor in enforcement: it's nearly impossible to convince regulators you cared about security if you can't show what you actually examined and what you did about it.

Date it, and have it signed by whoever is accountable. A written, dated, signed assessment scoped to your specific environment, with documented likelihood and impact for each risk and a linked remediation plan, is exactly what a regulator wants to see.

Step 8: Build a risk management plan and remediate

The assessment identifies risks. The risk management plan is where you actually reduce them, and OCR now scrutinizes both. OCR has made the risk analysis provision an enforcement priority, and that initiative is being extended to include risk management; if a breach is reported, OCR will require evidence that risks have been managed in a timely manner.

For each significant risk, decide on an action, assign an owner, and set a deadline. Encrypt the laptops. Turn on multifactor authentication. Move backups offline. Update the BAAs. Then track it to completion and keep the records, because "we identified the risk" without "we fixed it" is precisely the gap that turns a breach into a penalty.

How often should you do this?

There's a persistent myth that a risk assessment is a once-a-year checkbox. The truth is more demanding. The HIPAA Security Rule requires an ongoing risk analysis process rather than a fixed calendar interval. You need a cadence that reflects your systems, threats, and regulatory requirements.

In practice, that means a comprehensive assessment at least annually, plus an update whenever something meaningful changes: While HIPAA does not specify an exact frequency, OCR guidance and industry best practice recommend conducting a risk assessment at least annually, and assessments should be updated whenever significant changes occur. New EHR, new office, a new vendor, a merger, or a security incident all trigger a fresh look. Treat it as a living process, not an annual event you can forget about for twelve months.

Common mistakes that lead to fines

Scoping too narrowly. Leaving out email, mobile devices, backups, or a vendor system. If ePHI touches it, it's in scope.
Confusing a gap analysis for a risk analysis. A checklist against requirements isn't the same as analyzing likelihood and impact in your actual environment.
Generic threats. Listing "cyber threats" instead of naming specific threats tied to specific assets.
No documentation. Verbal assurances and undated notes don't survive an OCR investigation.
Identifying risks but never fixing them. OCR's recent actions repeatedly cite entities that had findings but no evidence of timely remediation.
Set-and-forget. Doing one assessment years ago and never updating it after new systems or incidents.

When to bring in outside help

A small practice with a simple setup can complete a credible assessment internally using free resources like the ONC/OCR Security Risk Assessment (SRA) Tool. But the process demands real security knowledge to do well, especially identifying technical vulnerabilities, running vulnerability and network scans, and judging likelihood accurately. Many practices don't have that expertise in-house, and a superficial self-assessment can create false confidence that's worse than knowing where you stand.

This is where an in-person assessment pays off. PolySec (polysec.tech) performs on-site HIPAA security risk assessments built for healthcare practices: vulnerability and network scanning, policy and BAA review, an audit-ready findings report, a prioritized remediation roadmap, and ongoing support to actually close the gaps. The idea is simple, your team focuses on patients while the security and compliance work is handled by people who do it every day. Given that healthcare breaches now average around $7 million and that more than 350 million individuals were affected by healthcare data breaches across 2024 and 2025, a thorough, personalized assessment is cheap insurance.

Frequently asked questions

Is a HIPAA risk assessment legally required?
Yes. It's a required implementation specification under the Security Rule's administrative safeguards. Every covered entity and business associate that handles ePHI must conduct one, and OCR asks for it first when investigating a breach.

Is a risk assessment the same as becoming HIPAA compliant?
No. The assessment is a foundational step, but compliance also requires implementing safeguards, training staff, signing BAAs, maintaining policies, and remediating the risks you find.

Can I use a free tool to do it myself?
For a simple practice, yes, the government's SRA Tool is a reasonable starting point. Just be honest about whether you have the technical skill to identify vulnerabilities and rate risk accurately. A checked box isn't the same as a thorough analysis.

How long does an assessment take?
For a small practice, a focused assessment can be completed in a few weeks depending on how complex your systems and vendor relationships are. Larger or multi-location organizations take longer.

What happens if I don't have one and get breached?
OCR will ask for your risk analysis during the investigation. Not having one, or having an inadequate one, has directly driven settlements ranging from tens of thousands to hundreds of thousands of dollars, plus multi-year corrective action plans.

The bottom line

A HIPAA security risk assessment isn't paperwork for its own sake. It's the map that tells you where patient data is exposed and what to fix first, and it's the single most important document OCR will ask for if things go wrong. Scope it broadly, inventory every place ePHI lives, analyze real threats against real assets, rate the risk, write it all down, and then actually remediate. Do that on a regular cadence and you protect your patients, your practice, and your license to operate.

If you'd rather not shoulder the technical work alone, an on-site assessment from a healthcare-focused partner like polysec.tech can take you from "we should probably do this" to an audit-ready report and a clear plan.

How Often Should a Medical Practice Run a Security Risk Assessment?

PolySec — Tue, 11 Aug 2026 03:25:36 +0000

How Often Should a Medical Practice Run a Security Risk Assessment?

If you're looking for a single number, here it is: run a full security risk assessment at least once a year, and again any time something meaningful changes in your practice. That's the short answer. The longer answer matters, because "at least annually" is where most practices get tripped up in an audit or, worse, after a breach.

The HIPAA Security Rule is the source of the requirement, and it's deliberately vague on timing. Under the HIPAA Security Rule, a security risk assessment isn't a one-and-done project. It is an ongoing risk analysis process. There's no fixed calendar deadline written into the regulation. That flexibility is meant to fit practices of every size, but it also means the responsibility for setting a defensible cadence falls on you.

What HIPAA actually requires

The rule uses the term "risk analysis" and requires it under 45 CFR 164.308(a)(1)(ii)(A). It never says "do this every 12 months." Instead, it expects the analysis to stay current. HIPAA requires an ongoing, current risk analysis. There is no fixed calendar frequency in the rule; you must reassess whenever your environment, systems, threats, or operations change and keep documentation up to date.

Because the requirement is risk-based rather than date-based, regulators and compliance professionals have converged on a practical standard. Because the HIPAA Security Rule is risk-based, the smart answer to "how often" is: at least annually enterprise-wide, plus event-driven reviews and continuous monitoring. Industry guidance is consistent on this point. While the federal regulation does not state a rigid calendar deadline, administrative guidelines and industry best practices dictate that a HIPAA security risk assessment must be completed at least once every 12 months (annually).

So the annual cadence isn't in the statute, but skipping it leaves you without the documentation an investigator will ask for first.

The annual baseline, plus three things that reset the clock

A yearly assessment covers your whole environment: where patient data lives, who can touch it, how it moves, and what could go wrong. Think of it as your baseline. On top of that, certain events should trigger a fresh assessment regardless of when you last did one.

The CMS security risk analysis guidance is explicit about this rhythm. Conducting a security risk analysis is required when certified EHR technology is adopted in the first reporting year. In subsequent reporting years, or when changes to the practice or electronic systems occur, a review must be conducted.

Here are the changes that should prompt an assessment before your next annual review comes due:

New or changed technology. New or substantially changed systems (EHR modules, imaging, patient portals, telehealth). Cloud migrations. A new practice management platform or a switch to cloud-hosted records reshapes where your data sits and how it's protected.
Operational changes. Opening a second location, merging with another practice, onboarding a large group of staff, or bringing on new vendors that handle patient data.
Security incidents and threat shifts. A ransomware scare, a phishing incident, or a newly disclosed vulnerability affecting software you rely on. After any material event, you reassess rather than wait.

Quarterly targeted reviews for high-risk systems and recent changes. Ad hoc assessments after material events (technology changes, incidents, new vendors). Continuous monitoring of key controls to detect drift between formal assessments. For most small and mid-sized practices, a full annual assessment plus event-driven check-ins is realistic and defensible. Larger organizations layer in more frequent targeted reviews.

If you attest to MIPS, the annual requirement is firmer

Practices participating in the Merit-based Incentive Payment System (MIPS) don't get to treat the timing as optional. The security risk analysis is a required attestation objective, and it has to be completed within the performance year you're reporting on.

The attestation is part of your annual MIPS submission. This means your SRA must be finalized, documented, and available for review before you submit your MIPS data, no late completions. Note that the assessment must cover your full environment. This security risk assessment must include all devices (including medical devices), connecting interfaces. If you bill Medicare and report through MIPS, budget for the assessment as a fixed annual task, not a "when we get to it" item.

The mistake that fails audits: assessment vs. analysis

A lot of practices believe they've met the requirement because they filled out a compliance checklist. That's not the same thing, and the distinction is exactly what OCR scrutinizes.

A compliance checklist tells you whether you've implemented specific safeguards. A risk analysis tells you where your actual exposures are. If a compliance assessment asks, "How compliant are we?" then the risk analysis asks, "how secure are we?" The terms get used interchangeably in conversation, but only one satisfies the legal requirement. The HIPAA Security Rule uses "risk analysis" in 164.308(a)(1)(ii)(A) to describe the required evaluation, while "risk assessment" has become the common term in practice. For compliance purposes, both terms refer to the same fundamental requirement.

The stakes here aren't theoretical. Throughout 2018 and 2019, the OCR has identified the failure to conduct an adequate risk assessment as a key finding in nearly half of their settlements, making it the largest single source of identified HIPAA violations. More recently, OCR launched an enforcement initiative aimed squarely at this failure. "Failure to conduct a HIPAA Security Rule risk analysis leaves health" care organizations exposed, and penalties have followed.

Why the frequency question is worth taking seriously

Healthcare remains one of the most targeted sectors for cyberattacks, and the numbers behind that have grown sharply. In 2025, large healthcare data breaches were reported at an average rate of 2.1 data breaches per day. In 2024, an average of 792,226 individuals were affected by a healthcare data breach every day.

The financial exposure is significant too. Recent OCR settlements tied to risk-analysis failures illustrate the range. The monetary fines announced in conjunction with the resolution agreements ranged from as little as $25,000 at the low end to as much as $3 million for a national medical supplier that did not conduct a compliant risk analysis. A regular assessment cadence is one of the few controls that both reduces your breach risk and gives you the documentation to defend yourself if OCR comes knocking.

A practical schedule for most practices

If you want a cadence you can actually follow, this is a sensible default:

Once a year: a complete, documented risk assessment covering every system that stores, processes, or transmits patient data. Date it, sign it, keep the prior versions.
On every major change: a focused reassessment when you add or replace an EHR, migrate to the cloud, open a location, or change vendors.
After any incident: a review triggered by a breach, near-miss, phishing event, or newly disclosed vulnerability.
Between formal assessments: ongoing monitoring of your highest-risk systems so problems surface early rather than at year-end.

Document everything, including the reasoning behind decisions you make. If an investigator asks why you did or didn't act on a given risk, your notes are the record that answers for you.

Frequently asked questions

Is a HIPAA risk assessment legally required every year?
The Security Rule doesn't name a specific interval, but it requires an ongoing, current analysis. In practice, annually is the accepted standard, and it's effectively mandatory if you attest to MIPS. Waiting longer than a year is hard to defend in an audit.

What's the difference between a risk assessment and a risk analysis?
They're used interchangeably in everyday conversation and refer to the same core requirement, but OCR's language is "risk analysis." The key distinction to remember is between a risk analysis (identifying and prioritizing your actual security exposures) and a compliance checklist (confirming you've implemented specific safeguards). Only the former satisfies the rule.

Does a small practice really need to do this as often as a hospital?
The frequency baseline is the same: annually plus event-driven reviews. The scope differs. A solo practice's assessment is far simpler than a health system's, but the obligation to keep it current applies regardless of size.

What triggers an off-cycle assessment?
New or changed technology, cloud migrations, opening or merging locations, new vendors that handle patient data, and any security incident or newly disclosed vulnerability.

The bottom line

Run a full security risk assessment at least once a year, then reassess whenever your technology, operations, or threat picture changes, and keep every version documented. That cadence satisfies the HIPAA Security Rule's ongoing-analysis expectation, meets MIPS attestation needs, and gives you a defensible record if you're ever audited or breached.

Most practices don't have in-house security staff to run this well, and a checklist filled out by a busy office manager is exactly the kind of "assessment" that fails an OCR review. If you'd rather have the technical work handled properly, PolySec performs in-person HIPAA security risk assessments built around your specific practice, including on-site vulnerability and network scanning, policy and BAA review, an audit-ready findings report, and a remediation roadmap so you know what to fix and in what order.

Healthcare Data Breach Exposes Sensitive Information of Nearly 312,000 Patients

PolySec — Tue, 11 Aug 2026 03:25:35 +0000

A regional medical group has confirmed that a security incident uncovered late last year led to the potential exposure of protected health information belonging to almost 312,000 people. The organization disclosed the breach in notifications sent to state regulators, though as of this writing it has not posted a public notice on its own website.

What Happened

According to filings submitted to the Attorneys General of Massachusetts and Vermont, the organization first detected suspicious activity on a legacy file server on December 16, 2025. Once the anomaly was identified, the server was immediately taken offline and isolated from the rest of the network while a forensic investigation got underway to determine what had occurred and how far it reached.

That investigation later confirmed that the intrusion was confined to the single file server, which an unauthorized party had accessed over a two-day window in mid-December. Importantly, the organization's electronic medical record system was not touched, the exposure was limited to files stored on the compromised server.

What Information Was Involved

Determining exactly what data lived on the affected server took time. It wasn't until several months later, in June 2026, that a full file review was completed. That review found the server contained a wide range of sensitive information, including:

Full names and dates of birth
Contact details
Social Security numbers
Driver's license numbers and other government-issued ID numbers
Credit and debit card numbers
Financial account information
Personnel and human resources records, which in some cases included compensation and payroll data, licensure and credentialing details, and medical or disability-related information The breadth of this data, spanning financial, personal, and employment-related records, is what makes the incident particularly serious for those affected. A combination like this gives criminals nearly everything needed to attempt identity theft, open fraudulent accounts, or file false tax returns in a victim's name.

The Response

Following the discovery, the organization says it has strengthened its technical safeguards to reduce the likelihood of a similar incident happening again. It has also arranged complimentary credit monitoring and identity theft protection services for affected individuals, covering a period of 24 months.

In terms of scope, the breach affected 290,357 residents of Massachusetts and 86 residents of Vermont. Separately, federal breach-tracking data from the U.S. Department of Health and Human Services' Office for Civil Rights lists the number of individuals impacted at 311,760, a figure broadly consistent with the organization's own reporting.

Why This Matters

Healthcare organizations remain a favored target for cybercriminals because the records they hold are so valuable: unlike a stolen credit card number, which can be canceled, a person's medical history, Social Security number, and identifying details don't expire and can be exploited for years. Incidents like this one are also a reminder that legacy or seemingly low-priority systems, like an old file server, can still hold troves of sensitive data and represent real risk if left inadequately protected or monitored.

For anyone who receives a breach notification like this, the standard advice applies: enroll in any free monitoring services offered, watch account and credit statements closely for unfamiliar activity, consider placing a fraud alert or credit freeze with the major credit bureaus, and be wary of unsolicited calls, texts, or emails referencing the breach, since scammers often use these incidents as cover for follow-up phishing attempts.

Breaches like this one often start with something as unremarkable as a forgotten legacy server: a system nobody thought to lock down or decommission. If it's been a while since your practice had its systems, network, and ePHI handling reviewed, now's the time.

PolySec builds comprehensive HIPAA security risk assessments specifically for healthcare practices. We find the gaps, outdated protocols, unpatched systems, unencrypted data, before an attacker does, and hand you a clear, prioritized roadmap to fix them.

Schedule a demo today ->

HIPAA Security Rule vs. Privacy Rule: What's the Difference

PolySec — Tue, 11 Aug 2026 03:22:40 +0000

People use "HIPAA" as if it's one thing, but compliance actually rests on two separate rules that do very different jobs. The Privacy Rule governs who can see or share patient health information and under what conditions. The Security Rule governs how you protect the electronic version of that information from being stolen, altered, or lost. Confusing the two is one of the most common reasons practices think they're compliant when they aren't.

Here's the short version: the Privacy Rule is about permission and disclosure. The Security Rule is about technical and physical protection. You need both, and they cover different scopes. This guide breaks down what each rule requires, where they overlap, and what a medical practice actually has to do to satisfy them.

The quick answer

Privacy Rule: Sets national standards for the use and disclosure of protected health information (PHI) in any form, on paper, spoken, or electronic. It defines patient rights and limits who can access or share PHI.
Security Rule: Sets standards specifically for electronic PHI (ePHI). It requires administrative, physical, and technical safeguards to keep that data confidential, intact, and available.

Think of it this way: the Privacy Rule decides whether a disclosure is allowed. The Security Rule makes sure the electronic systems holding that data can't be breached, tampered with, or knocked offline.

What the HIPAA Privacy Rule covers

The Privacy Rule was the first of the two to take effect, with a compliance date of April 14, 2003. Its scope is broad: it applies to PHI in every format, whether that's a paper chart, a conversation at the front desk, a fax, or a record in your EHR.

At its core, the Privacy Rule controls use and disclosure. It tells covered entities and their business associates when they can share patient information without authorization (for treatment, payment, and healthcare operations, for example) and when they need the patient's written permission first.

A few of its most important provisions:

The minimum necessary standard. The minimum necessary standard requires covered entities to make reasonable efforts to limit the use, sharing, or requests for protected health information to only what's necessary to accomplish the intended purpose. A billing clerk doesn't need a patient's full clinical history to process a claim, so they shouldn't have access to it. Notably, this standard has exceptions, it doesn't apply to disclosures to the patient themselves, disclosures for treatment, or uses required by law.

Patient rights. The rule gives patients concrete, enforceable rights over their own records: the right to access and get copies of their PHI, to request corrections, to receive an accounting of certain disclosures, and to ask for restrictions or confidential communications.

Notice of Privacy Practices. A HIPAA Notice of Privacy Practices advises patients and plan members of their privacy rights, how the organization can use or disclose PHI, and how an individual can complain if they believe their privacy rights have been violated or their information misused.

One more thing worth knowing: HIPAA establishes a federal floor, so if a state law is more protective of privacy, you must follow the stricter state law.

What the HIPAA Security Rule covers

The Security Rule came later, with an effective compliance date of April 21, 2005 for most covered entities. Its scope is narrower and more technical: it applies only to electronic PHI. Paper records and spoken disclosures fall under the Privacy Rule, not the Security Rule.

The Security Rule is built around three protective goals for ePHI, confidentiality, integrity, and availability, and it organizes its requirements into three categories of safeguards:

Administrative safeguards. The policies, procedures, and workforce management that govern how you protect ePHI. This includes assigning a security official, training staff, managing access privileges, and, most importantly, conducting a risk analysis.

Physical safeguards. Controls over the physical environment: facility access, workstation security, device and media disposal, and preventing unauthorized people from physically reaching systems that store ePHI.

Technical safeguards. The technology controls, access controls, audit logs, encryption, and authentication that protect ePHI as it's stored and transmitted.

The single most important requirement here is the risk analysis. Conducting a risk analysis is the first step in identifying and implementing safeguards that comply with the standards and implementation specifications in the Security Rule. It isn't optional, and it isn't a one-time checkbox. The risk analysis requirement is a required implementation specification, which means all covered entities and business associates must conduct risk assessments, and there's no alternative compliance path.

This matters more than most practices realize. When OCR investigates breaches or conducts compliance reviews, inadequate risk assessment documentation consistently appears among the most cited deficiencies. A missing or shallow risk analysis is often the first thing regulators find, and it's frequently what turns a bad situation into a costly one.

Where the two rules overlap

The rules are distinct, but they're not independent. A practice can follow the Privacy Rule perfectly, only disclosing information when permitted, and still violate HIPAA if a laptop full of unencrypted patient records gets stolen. That's a Security Rule failure, and it's also, in effect, an impermissible disclosure.

The overlap is easiest to see in a breach. When ePHI is exposed, you've usually failed a Security Rule safeguard and triggered privacy consequences at the same time, because the information ended up in unauthorized hands. Both rules also share the same enforcement body, the HHS Office for Civil Rights, and the same penalty structure. For 2025, HIPAA civil monetary penalties range from $145 per violation to $2,190,294 per violation, depending on the level of culpability.

Why the distinction matters right now

This isn't an academic exercise. Healthcare is one of the most attacked industries in the world, and the numbers from the last two years are staggering.

In 2024, an average of 792,226 individuals were affected by a healthcare data breach every day, driven in large part by the Change Healthcare breach that affected 192.7 million individuals. That single incident ranks among the largest health data breaches ever recorded. And the financial fallout is severe: healthcare data breaches cost an average of $7.42 million per incident, the costliest of any industry. The healthcare sector has held the position of most expensive industry for data breaches for 14 consecutive years.

The reason the distinction matters is that most modern breaches are Security Rule problems. Ransomware, stolen credentials, and unpatched systems don't care about your Notice of Privacy Practices. If your practice has invested heavily in privacy paperwork but never completed a real risk analysis or encrypted its data, you're exposed exactly where attackers are aiming.

What's changing: the proposed Security Rule update

The Security Rule hasn't had a major update since 2013, and the technology landscape has shifted dramatically since then. That's about to change. On December 27, 2024, the Office for Civil Rights at HHS issued a Notice of Proposed Rulemaking to modify the HIPAA Security Rule and strengthen cybersecurity protections for ePHI.

Several proposed changes would raise the bar significantly:

No more "addressable" safeguards. Under the current rule, some safeguards are labeled "addressable," which many organizations have historically treated as optional. The NPRM proposes to remove the distinction between "required" and "addressable" implementation specifications and make all implementation specifications required, with specific, limited exceptions.
Mandatory encryption. The addressable category for encryption would be eliminated, and encryption would be required for all ePHI data in transit and at rest.
Multi-factor authentication and asset inventories. The proposal would require MFA for systems accessing ePHI and an accurate, maintained inventory of technology assets.

A quick but important caveat on timing: this rule is not yet final. The proposed update is still not final, and OMB now targets July 2027 for final action. Even so, the direction is clear, and many of these measures (encryption, MFA, current asset inventories) are already standard security practice. Practices that adopt them now won't be scrambling later.

What your practice should actually do

If you take one thing from this comparison, make it this: privacy policies and security controls are two separate obligations, and you need to satisfy both.

Handle the Privacy Rule basics. Confirm your Notice of Privacy Practices is current, your minimum-necessary access rules are enforced, and your process for patient access requests works.
Complete a real Security Rule risk analysis. Not a template you filled out once. Identify where ePHI lives, what threatens it, and where your gaps are, then document the whole thing.
Fix the technical basics ahead of the new rule. Encrypt data at rest and in transit, turn on MFA, and keep an accurate inventory of every device and system touching ePHI.
Keep documentation for six years. Maintain all risk analysis, mitigation, and training documentation for a minimum of six years, kept organized and audit-ready.

The hard part for most practices is step two. A thorough risk analysis requires security expertise that a typical clinic or dental office doesn't have on staff, and a generic online questionnaire won't hold up if OCR comes knocking. This is where an in-person, practice-specific assessment pays off. PolySec (polysec.tech) performs on-site HIPAA security risk assessments for healthcare practices, including vulnerability and network scanning, policy and BAA review, an audit-ready findings report, and a remediation roadmap, so you're not guessing about where your gaps are. The idea is simple: you focus on patients, and a security team handles the technical compliance work.

Frequently asked questions

Is the Privacy Rule or the Security Rule more important?
Neither. They cover different things and you're legally required to comply with both. The Privacy Rule governs use and disclosure of all PHI; the Security Rule protects electronic PHI specifically.

Does the Security Rule apply to paper records?
No. The Security Rule applies only to electronic PHI. Paper records and spoken disclosures are covered by the Privacy Rule instead.

Do both rules apply to business associates?
Yes. Both covered entities and their business associates must comply, which is significant given how many major breaches originate with vendors and third parties.

What's the first step to Security Rule compliance?
A documented risk analysis. It's a required specification, it has no alternative compliance path, and it's the most common deficiency OCR cites during investigations.

When do the new Security Rule requirements take effect?
The 2024 proposed rule isn't final yet, with final action currently targeted for 2027. But since measures like encryption and MFA are already best practice, implementing them now is the safe move.

The HIPAA Security Risk Assessment Checklist Every Practice Should Follow

PolySec — Tue, 11 Aug 2026 03:20:35 +0000

If your practice handles electronic protected health information, a documented security risk assessment isn't optional paperwork. It's the single requirement OCR investigators ask for first after a breach, and the one small practices most often get wrong. Conducting a risk analysis is the first step in identifying and implementing safeguards that comply with the standards and implementation specifications in the Security Rule. A risk analysis is foundational, and must be understood in detail.

This checklist walks through exactly what a compliant HIPAA security risk assessment includes, the elements HHS expects to see, and the gaps that get practices penalized. Whether you run a two-provider dental office or a multi-site specialty group, the core requirements are the same.

What a HIPAA security risk assessment actually is

A security risk assessment (sometimes called a risk analysis) is a written evaluation of every place your practice creates, receives, stores, or transmits electronic PHI, and the threats and vulnerabilities that could compromise that data. It's required under the HIPAA Security Rule at § 164.308(a)(1)(ii)(A).

Two things trip people up. First, a risk assessment is not the same as buying antivirus software or signing a checklist your IT vendor emailed you. It's an analysis of risk, meaning you have to identify what could go wrong, how likely it is, and how bad the impact would be. Second, it's not a one-time project. HIPAA does not mandate a fixed interval, but regulators expect a documented, enterprise-wide security risk analysis performed periodically and updated after changes. Most organizations conduct a full assessment annually, supplemented by more frequent, risk-based reviews.

The Security Rule organizes protections into three categories, and your assessment needs to touch all of them. The Security Rule requires regulated entities to implement reasonable and appropriate administrative, physical, and technical safeguards for protecting ePHI.

The core checklist: what your assessment must cover

HHS doesn't dictate a specific format, but it does expect certain elements in every risk analysis. Use these as your master checklist.

1. Define the scope. List every system, device, and location where ePHI lives: your EHR, billing software, patient portal, email, imaging systems, laptops, phones, backup drives, and any cloud service. If it touches patient data, it's in scope. Missing systems is the most common way an assessment fails an audit.

2. Collect and document your data flows. Map how ePHI enters, moves through, and leaves your practice. Where is it stored? Who has access? What third parties (labs, billing companies, cloud vendors) receive it? Write this down. HHS requires the analysis in writing.

3. Identify threats and vulnerabilities. Catalog the realistic threats to each system: ransomware, phishing, lost or stolen devices, insider misuse, unpatched software, weak passwords, and physical break-ins. A vulnerability is any weakness a threat could exploit, like an unencrypted laptop or a shared login.

4. Assess your current security measures. Document the controls you already have in place, encryption, access controls, firewalls, audit logging, and evaluate whether they're actually configured and working, not just installed.

5. Determine the likelihood of each threat. Take account of the probability of potential risks to ePHI; in combination with the potential threats and vulnerabilities, this assessment allows for estimates on the likelihood of ePHI breaches.

6. Determine the potential impact. Using either qualitative or quantitative methods, assess the maximum impact of a data threat to your organization. How many people could be affected? What extent of private data could be exposed, just medical records, or both health information and billing information combined?

7. Assign a risk level. HHS suggests taking the average of the assigned likelihood and impact levels to determine the level of risk. A common approach is to score likelihood and impact each on a 1-to-5 scale and multiply them, then sort results into low, medium, high, or critical. One of the simplest ways to determine risk levels is to assign the likelihood of a risk occurring a number between 1 and 5 and the impact the event would have a number between 1 and 5, then multiply the two numbers together.

8. Finalize documentation with corrective actions. Documented risk levels should be accompanied by a list of corrective actions that would be performed to mitigate risk. HHS doesn't specify any format, but they do require the analysis in writing. This written record is your remediation roadmap and your proof of compliance.

9. Review and update periodically. Repeat the assessment on a schedule and after any significant change. Run additional, focused assessments when conditions shift, such as new or substantially changed systems like EHR modules, imaging, patient portals, or telehealth. Event-driven reviews keep your posture aligned with reality and your risk register current.

Safeguard-by-safeguard checklist

Within your assessment, evaluate specific controls across the three safeguard categories.

Administrative safeguards

A named security officer responsible for policies and procedures
Workforce security and access management (who can see what, and why)
Regular security awareness training, including phishing recognition
A written incident response and breach notification plan
Signed Business Associate Agreements with every vendor that touches ePHI
Sanction policies for staff who violate procedures

Physical safeguards

Facility access controls (locked server rooms, restricted areas)
Workstation security and positioning so screens aren't visible to patients
Device and media controls covering disposal, reuse, and off-site movement
An inventory of hardware that stores ePHI

Technical safeguards

Unique user IDs and strong authentication (ideally multi-factor)
Encryption of ePHI at rest and in transit
Automatic logoff on unattended workstations
Audit controls and log review to detect unusual access
Data backup and a tested disaster recovery plan

The gaps that get practices penalized

The failures OCR flags most often aren't exotic. They're basic and repeated. The biggest is having no risk analysis at all, or one that only covers part of the practice's systems. A close second is treating the assessment as a document you file and forget rather than a process you act on.

Two related mistakes cost real money: skipping Business Associate Agreements with vendors, and running an assessment but never remediating the risks it uncovered. An assessment that identifies a critical vulnerability and then sits in a drawer can actually make things worse, because it proves you knew and did nothing.

The financial stakes are concrete. HIPAA penalties come from four tiers: lack of knowledge, reasonable cause, willful neglect corrected within 30 days, and willful neglect not corrected. For 2025, penalties range from a minimum of $145 per violation at the lowest tier up to $2,190,294 per violation for willful neglect that is not corrected. The published annual penalty cap per identical provision is $2,190,294. The encouraging part: real-world settlements often fall below those caps when organizations cooperate, self-report, and remediate quickly.

Where to get help

HHS and ONC publish a free assessment aid worth knowing about. The Office of the National Coordinator for Health Information Technology, in collaboration with OCR, developed the HIPAA Security Risk Assessment Tool. The tool is useful in assisting small and medium-sized health care practices and business associates in complying with the HIPAA Security Rule.

The free tool is a solid starting point, but it assumes you can accurately identify your own vulnerabilities, and that's exactly where clinical teams without security expertise tend to struggle. You can't score the likelihood of a threat you didn't know existed, and self-assessments routinely miss misconfigured firewalls, unpatched systems, and network weaknesses that only surface with actual scanning.

This is where an outside assessment earns its keep. PolySec performs in-person HIPAA security risk assessments built specifically for healthcare practices, on-site vulnerability and network scanning, policy and BAA review, and an audit-ready findings report with a prioritized remediation roadmap. The point is to let clinical staff focus on patients while the technical and compliance work is handled by people who do it full time, including support through remediation rather than just handing you a report.

HIPAA security risk assessment FAQ

How often do I need to do a HIPAA risk assessment?
There's no legally fixed interval, but the practical standard is at least once a year plus a fresh review whenever something significant changes, like a new EHR, a telehealth rollout, or a merger. Regulators expect a documented analysis performed periodically and updated after changes, and most organizations conduct a full assessment annually.

Does my IT company's security setup count as a risk assessment?
No. Installing security tools is remediation, not analysis. A compliant assessment identifies and documents risks, rates them, and maps corrective actions. HHS specifically requires the analysis to be in writing.

What's the difference between a risk assessment and a risk analysis?
In practice the terms are used interchangeably for the Security Rule requirement. Note that a broader HIPAA compliance review can be even wider. A risk assessment for all elements of HIPAA compliance should include the Privacy, Security, and Breach Notification Rules.

What happens if I've never done one?
Operating without a documented risk analysis is one of the most commonly cited HIPAA failures, and after a breach it's the first thing OCR requests. Given that fines start at $145 and reach into the millions for uncorrected willful neglect, the cost of doing an assessment is trivial next to the cost of not having one.

Do small practices really get audited?
Enforcement isn't limited to hospitals. Small practices face the same rules and are frequent targets for ransomware and phishing precisely because they tend to have weaker defenses. The size of your practice doesn't reduce your obligation.

The bottom line

A HIPAA security risk assessment comes down to a simple loop: find where your ePHI lives, figure out what could go wrong, rate how serious each risk is, fix the worst ones first, write it all down, and revisit it regularly. Do that consistently and you're not just checking a compliance box, you're genuinely reducing the odds of a breach that could damage patient trust and your practice's finances.

If you haven't run an assessment in the past year, or you're not confident the last one covered every system, that's the place to start. Book one, act on the findings, and keep the documentation current.