DEV Community: PolySec

HIPAA Security Rule Violations: Common Causes, Penalties, and Fixes

PolySec — Fri, 18 Sep 2026 22:52:37 +0000

The fastest way to end up in an OCR investigation isn't a hacker. It's a missing risk analysis, an unencrypted laptop, or a former employee whose login still works. Most HIPAA Security Rule violations trace back to a handful of predictable gaps, and regulators know exactly where to look for them.

This post breaks down what the Security Rule actually requires, the violations that get cited most often, what penalties look like in 2025, and the practical steps that keep a practice out of the enforcement column.

What the HIPAA Security Rule Requires

The Security Rule applies specifically to electronic protected health information (ePHI), the patient data your practice creates, stores, and transmits digitally. It's separate from the Privacy Rule, which governs PHI in all forms.

The HIPAA Security Rule requires covered entities and business associates to implement administrative, physical, and technical safeguards to protect ePHI. Those three categories cover different territory:

Administrative safeguards are your policies, workforce training, and the security management process, including risk analysis.
Physical safeguards control access to facilities, workstations, and devices.
Technical safeguards govern how systems authenticate users, control access, and protect data in storage and transit.

One nuance trips up a lot of practices: not every specification is flatly mandatory. Addressable means that a covered entity has additional flexibility with respect to compliance. Addressable does not mean optional. It means you either implement the safeguard, or you document why an equivalent alternative is reasonable for your environment. Encryption is the classic example. Encryption is not mandatory under HIPAA Rules, but it cannot be ignored. If the decision is taken not to use encryption, an alternative, equivalent security measure must be used in its place.

The Most Common HIPAA Security Rule Violations

Enforcement patterns are remarkably consistent year to year. Most HIPAA Security Rule violations stem from predictable gaps: weak access control, missing data encryption, unmanaged vendors, and outdated risk analysis and security assessments.

Here are the ones that show up repeatedly in OCR cases:

1. No risk analysis, or a stale one. This is the big one, and it's covered in its own section below because it now drives a dedicated enforcement effort.

2. Missing or weak encryption on ePHI. Unencrypted laptops, phones, and backup drives turn an ordinary theft or loss into a reportable breach. If you skip encryption, you need a documented equivalent safeguard in its place.

3. Excessive access and workforce snooping. Staff with access to records they don't need for their jobs is a violation of the minimum-necessary principle and a frequent source of internal breaches.

4. Unmanaged access after role changes. Accounts that stay active after an employee leaves or changes roles are a well-known weak point.

5. Missing Business Associate Agreements. Every vendor that touches ePHI, from your billing service to your cloud host, needs a signed BAA. Regulators check.

6. No audit controls or activity monitoring. If you can't tell who accessed what and when, you can't detect misuse or prove compliance.

Why Risk Analysis Failures Dominate Enforcement

If you fix only one thing, fix this. Risk analysis is consistently the single most-frequently-cited deficiency in OCR investigations.

The requirement itself is specific. The Security Rule directs organizations to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the organization. A generic checklist or a vendor's boilerplate template rarely satisfies "accurate and thorough."

OCR has made this a priority in a concrete way. In late 2024 it launched a Risk Analysis Enforcement Initiative, and it has kept the pressure on since. In the fall of 2024, OCR announced the first enforcement action in its Risk Analysis Initiative. By April 2025, the initiative had already resulted in combined settlement payments of nearly $900,000 from eight different health care organizations. The pace continued through 2025, with 16 resolution agreements announced from January to August 2025 featuring failure to conduct an accurate and thorough assessment of potential risks.

The settlements aren't limited to large hospital systems. In one case, OCR reached a $250,000 settlement and a two-year corrective action plan requiring full risk analysis, policy updates, and workforce training. Small practices and business associates are squarely in scope.

What HIPAA Violations Actually Cost in 2025

Civil penalties run on a four-tier structure keyed to culpability, from an honest unknowing violation up to willful neglect that goes uncorrected. The dollar figures are indexed for inflation each year.

For 2025, per-violation floors and ceilings are: Tier 1 $145 to $73,011; Tier 2 $1,461 to $73,011; Tier 3 $14,602 to $73,011; Tier 4 $73,011 to $2,190,294, with an annual cap of $2,190,294 for an identical provision. Note that the top annual cap applies to the most serious category. HHS determined that the maximum annual penalty should only apply to the most serious Tier 4 violation category.

Two things worth keeping in perspective. Penalties scale with intent and with whether you corrected the problem, so a documented good-faith compliance program materially changes your exposure. And criminal liability exists but is rare. Jail time is a real risk for those who willfully and knowingly violate HIPAA rules, though it applies to a narrow set of egregious conduct, not ordinary compliance gaps.

The Bigger Change Coming: The 2025 Proposed Security Rule

If your compliance posture is currently "good enough," the ground is shifting. In January 2025, OCR published a Notice of Proposed Rulemaking, the first major overhaul of the Security Rule since 2013. The proposed modifications would revise existing standards to better protect the confidentiality, integrity, and availability of ePHI and increase cybersecurity for ePHI.

The most consequential shift is structural. Among other changes, it would eliminate the distinction between required and addressable implementation specifications, require comprehensive technology asset inventories and network mapping, and mandate multi-factor authentication. In other words, the "addressable" flexibility that many practices lean on today would largely disappear.

The proposal also introduces hard requirements and deadlines that look a lot more like modern cybersecurity frameworks:

A technology asset inventory and a network map showing ePHI flows, maintained and reviewed at least annually.
A detailed asset inventory, vulnerability scans every six months, penetration tests annually, and 72-hour disaster recovery plans.
Mandatory encryption of ePHI in transit and at rest, plus MFA.

Timing matters for planning. This is still a proposal, not final. The January 2025 NPRM has been delayed, with the update not expected until 2027. That gives practices runway, but the direction of travel is clear: inventories, MFA, encryption, and tested recovery plans are becoming the baseline, not the aspiration.

How to Close the Gaps

A practical sequence that maps to what OCR actually looks for:

Run a real risk analysis. Not a template. An accurate, organization-wide assessment of where ePHI lives, how it moves, and where it's exposed. Repeat it at least annually and after any major change.
Fix the findings, and document it. A risk analysis with no remediation is arguably worse than none. OCR wants to see that you acted on what you found.
Encrypt ePHI, or document your equivalent. Devices, backups, and transmissions.
Tighten access. Unique logins, least-privilege access, prompt deprovisioning when someone leaves, and audit logging.
Get your BAAs in order. Inventory every vendor that touches ePHI and confirm a signed agreement for each.
Get ahead of the proposed rule. Start building the asset inventory and network map now, and pressure-test whether you could restore systems within 72 hours.

For most practices, the hard part isn't wanting to comply, it's not having in-house security expertise to run a credible vulnerability scan or interpret the findings. That's the specific gap PolySec is built to fill. PolySec performs in-person HIPAA security risk assessments for healthcare organizations, including on-site vulnerability and network scanning, policy and BAA review, and an audit-ready findings report with a remediation roadmap, so the assessment-to-fix work is handled by specialists while your team stays focused on patients.

Frequently Asked Questions

What's the difference between the HIPAA Privacy Rule and Security Rule?
The Privacy Rule governs protected health information in all forms and sets the rules for how it can be used and disclosed. The Security Rule applies specifically to electronic PHI and requires administrative, physical, and technical safeguards to protect it.

Is encryption required under HIPAA?
Technically it's "addressable," not flatly required. If you choose not to encrypt, you must implement and document an equivalent safeguard. That said, the 2025 proposed rule would make encryption mandatory, and unencrypted devices are a leading cause of reportable breaches, so treating it as required is the safer posture.

How often should we do a HIPAA risk analysis?
At least annually, and again after any significant change to your systems, vendors, or operations. A one-time or outdated analysis is exactly what OCR cites most often.

Do small practices really get penalized?
Yes. Recent Risk Analysis Initiative settlements include small providers and business associates, with amounts in the tens to hundreds of thousands of dollars. Practice size doesn't exempt you.

When do the new HIPAA Security Rule requirements take effect?
The January 2025 proposal is not yet final, and the update isn't expected until around 2027. The requirements it describes, MFA, encryption, asset inventories, and 72-hour recovery, are worth adopting early regardless.

SEO metadata

Title tag: HIPAA Security Rule Violations: Common Causes, Penalties, and Fixes (60 characters)
Meta description: Learn what triggers HIPAA Security Rule violations, the 2025 penalty tiers, why risk analysis failures dominate OCR cases, and how to fix the gaps. (147 characters)
Primary keyword: HIPAA Security Rule violations (in title, first 100 words, an H2/H4, and meta description)
Secondary/semantic keywords: risk analysis, OCR enforcement, HIPAA penalties 2025, ePHI encryption, administrative/physical/technical safeguards, Business Associate Agreement, 2025 NPRM, security risk assessment
Intent: Informational with commercial-investigation overlap (readers assessing their own compliance risk and likely to seek a vendor)
Featured-snippet targets: the FAQ block and the "Most Common Violations" list

PolySec placement note: PolySec is referenced once, in the "How to Close the Gaps" section (step-by-step remediation), which is the most natural point of need, where the reader has just been told to run a risk analysis and vulnerability scan they likely can't do in-house. The mention is clearly branded (not disguised as third-party endorsement), links to https://www.polysec.tech, and describes the actual service (on-site assessment, scanning, BAA/policy review, audit-ready report, remediation roadmap). No inflated claims. Adjust the CTA tone if you'd prefer it softer or want a second link to a specific PolySec blog post.

Verification flags: All penalty figures, settlement amounts, and NPRM details are drawn from secondary sources (industry/law-firm summaries and HHS material). Before publishing, I'd recommend confirming the current 2025 indexed penalty amounts and the latest count/total of Risk Analysis Initiative settlements against the official HHS/OCR pages, since these numbers update as new enforcement actions and annual inflation adjustments are announced.

How to Assign a Security Officer for HIPAA Compliance: A Practical Guide

PolySec — Fri, 18 Sep 2026 22:52:31 +0000

How to Assign a Senior Leader to Own Security Policy Across Your Organization

If your practice handles electronic protected health information, naming someone to own your security program isn't a nice-to-have. It's federal law. A regulated entity must designate a security official responsible for developing and implementing the policies and procedures required by the Security Rule. This guide walks through how to choose that person, define their authority, and set up the reporting structure so the role actually functions instead of existing only on paper.

The distinction matters more than it sounds. Organizations get penalized not just for skipping the designation, but for naming someone who never does the work. Below is how to do it properly.

Why the Designation Is a Legal Requirement, Not a Formality

HIPAA builds this responsibility into two separate rules, and healthcare organizations subject to both need to account for each.

The Security Rule covers electronic PHI. The Security Rule, which followed in 2005, separately requires covered entities and their business associates to designate a Security Official responsible for developing and implementing security policies and procedures. The Privacy Rule covers PHI more broadly. HIPAA's Privacy Rule, which took effect in 2003, requires covered entities to designate a Privacy Official responsible for developing and implementing privacy policies and procedures.

Both are mandatory. These are not optional recommendations, they are regulatory requirements. Failing to designate either role, or failing to ensure those individuals are actually performing the required functions, can result in financial penalties and corrective action plans during an OCR investigation.

The consequences are concrete. In the 2017 CardioNet case, a laptop with unsecured ePHI on roughly 1,400 patients was stolen from a car, and the follow-up investigation exposed how little was actually in place. The investigation found CardioNet had insufficient risk analysis and management processes, and its HIPAA Security Rule policies and procedures were in draft form and not implemented. The settlement reached $2.5 million. Draft policies that no one owned and enforced were treated the same as having no policies at all.

Security Officer vs. Privacy Officer: Which Role Are You Assigning?

These titles get used interchangeably, but they cover different ground, and understanding the split helps you assign the right person.

Security Officer protects ePHI through technical, physical, and administrative safeguards. Think access controls, encryption, network monitoring, incident response, and risk analysis.
Privacy Officer governs how PHI is used and shared. Think patient access requests, complaint handling, minimum-necessary decisions, and tracking changes in privacy law.

The Privacy Officer governs how PHI is used and shared, while the Security Officer protects ePHI through safeguards and vigilant monitoring.

Can one person do both? Yes, and in smaller practices they often should. The Security Officer and the Privacy Officer are both legally required under the Health Insurance Portability and Accountability Act, and in smaller organizations the same person sometimes fills both positions. Some organizations formalize this as a combined HIPAA Compliance Officer. There's one non-negotiable rule when you consolidate: HHS explained when finalizing the Security Rule that the same person may fill both roles, although final security responsibility must rest with one designated official.

That's the whole point of the requirement. Accountability has to trace back to a single named person.

Step 1: Choose the Right Individual

The regulation says "senior-level" for a reason. This person needs the authority to change how the organization operates, not just the knowledge to recommend changes.

Look for someone who can:

Understand both the technical side (systems, networks, ePHI flows) and the regulatory side (what HIPAA actually requires).
Influence decisions across departments, from IT to front-desk staff to clinical leadership.
Hold budget conversations and win them when a safeguard needs funding.

In larger systems this is a CISO. In a mid-sized practice it might be an IT director, compliance manager, or practice administrator who's given the mandate formally. The title matters less than the authority behind it.

One mistake OCR has repeatedly flagged: assigning the role to a department instead of a person. Naming "IT" as your security official is not a designation. The role has to attach to a named human being who can be held accountable, with documented authority, allocated time, and a budget to work with. A named officer who has none of those things is nearly as risky as having no officer at all.

Step 2: Define the Role in Writing

A verbal "you're our security person now" doesn't hold up in an audit. Create a written job description or charter that spells out the scope. The Administrative Safeguards of the HIPAA Security Rule require covered entities and business associates to "identify the security official who is responsible for the development and implementation of the policies and procedures."

At minimum, the written scope should cover:

Policy development and implementation for all administrative, physical, and technical safeguards.
Risk analysis and risk management, conducted regularly and documented.
Access controls, including provisioning, deprovisioning, multi-factor authentication, and least-privilege configurations.
Incident response, disaster recovery, and data backup, including testing those procedures rather than just writing them.
Workforce security awareness and training, run in coordination with the Privacy Officer.
Ongoing compliance monitoring, so gaps get caught before an auditor finds them.

The HIPAA Security Officer is responsible for monitoring compliance, which means the job doesn't end when the policies are signed. Someone has to keep checking that they're followed.

Step 3: Grant Real Authority and a Reporting Line

This is where designations quietly fail. A security officer with responsibility but no authority can't enforce anything, and enforcement is most of the job.

Give the role three things explicitly:

Decision authority over security controls and policy exceptions.
A budget or a direct path to security spending decisions.
Protected time, so the responsibilities aren't buried under an unrelated full-time job.

Reporting structure deserves thought too. In healthcare, the security leader most often reports through the CIO or into broader executive leadership rather than directly to the board. A CISO reporting directly to the board is highly irregular in healthcare. Healthcare requires a more clearly articulated risk-based strategy, with CISOs more effective as part of the chain of leadership. Whatever the line, the officer needs enough proximity to leadership that security concerns actually reach the people who set priorities.

Step 4: Distribute Responsibilities Without Diluting Accountability

Designating one official doesn't mean that person personally does everything. Larger organizations spread the work across a team.

Under the Security Rule, while one individual must be designated as having overall responsibility, other individuals in the covered entity or business associate may be assigned specific security responsibilities.

So your security officer might delegate network monitoring to IT, training coordination to HR, and vendor reviews to a compliance analyst. The delegation is fine. The accountability still lands on the designated official. Document who owns what so there are no gaps, and no assumptions that "someone else was handling it."

Step 5: Make Privacy and Security Officers Work Together

When the roles are held by two different people, coordination isn't optional. Many HIPAA obligations sit across both domains, and breaches usually involve both.

Both officers translate HIPAA requirements into practical controls, train the workforce, manage incidents, and drive documentation. A phishing attack that exposes patient records is simultaneously a security failure and a privacy incident. If your two officers aren't talking regularly, that seam is exactly where things fall through.

Build in recurring touchpoints: joint incident response planning, shared training calendars, and a common view of your risk register.

Where an Outside Assessment Fits In

Naming a qualified officer is the first move. Giving that person an accurate picture of where the organization actually stands is the next one, and it's where a lot of practices stall, because in-house staff rarely have the tooling to run a full technical assessment.

This is a reasonable place to bring in outside help. A firm like PolySec runs in-person HIPAA security risk assessments, including on-site vulnerability and network scanning, policy and BAA review, and an audit-ready findings report with a remediation roadmap. For a newly designated security officer, that kind of assessment turns a vague mandate into a prioritized to-do list, and it addresses the exact gaps that sank CardioNet: a real risk analysis and policies that are implemented rather than left in draft. The practice keeps focusing on patients while the technical compliance work gets handled by people who do it full-time.

Frequently Asked Questions

Does every healthcare organization need a HIPAA Security Officer?
Yes if you're a covered entity or business associate handling ePHI. All covered entities and business associates are required by 45 CFR 164.308, the Administrative Safeguards of the HIPAA Security Rule, to identify a HIPAA Security Officer. There's no size exemption.

Can one person be both the Privacy Officer and Security Officer?
Yes. One qualified individual may serve in both roles when the organization can support both sets of responsibilities effectively. Small practices commonly combine them, as long as final responsibility rests with one named person.

Can we outsource the Security Officer role?
The function can be supported externally, but accountability still has to attach to a designated individual. Many practices pair an internal named officer with outside expertise for the technical assessment and remediation work rather than trying to build that capability in-house.

What happens if we name someone but they don't do the work?
That's treated as a failure to comply. Failing to ensure those individuals are actually performing the required functions can result in financial penalties and corrective action plans during an OCR investigation. The designation only protects you if the role is active.

Who should the Security Officer report to?
Most often through the CIO or executive leadership rather than the board directly. What matters is that the officer has genuine authority, a budget path, and enough access to leadership that security priorities get heard.

The Bottom Line

Assigning a security officer is a legal requirement, but treating it as a box to check is how organizations end up paying seven-figure settlements. Name a senior person with real authority, put their responsibilities in writing, give them budget and time, and make sure they actually run the program. Then feed them an accurate risk picture so their first ninety days target the gaps that matter most. The designation is the easy part. Making the role function is what keeps you compliant, and keeps patient data protected.

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.