logo
Contact Us

844-740-7100

    Colington Consulting

    Helping Organizations Achieve HIPAA Compliance™

    Contact Us

    Author: Colington Consulting

    • HIPAA Security Rule Delay: Why You’re Not Off the Hook

      HIPAA Security Rule Delay: Why You’re Not Off the Hook

      Quick answer: HHS has pushed its target for finalizing the HIPAA Security Rule update from May 2026 to July 2027. But the delay only applies to the proposed new requirements— the current HIPAA Security Rule is still fully in effect, still enforced by OCR, and still carries the same penalties for noncompliance. Organizations that treat this as a compliance holiday are misreading what actually changed.

      What Actually Happened

      In January 2025, HHS’s Office for Civil Rights (OCR) published a Notice of Proposed Rulemaking (NPRM) proposing the most significant overhaul of the HIPAA Security Rule since 2013. The proposal would replace many of today’s flexible, “addressable” safeguards with hard requirements, including:

      • Mandatory encryption of ePHI at rest and in transit (no more “addressable” workaround)
      • Mandatory multi-factor authentication on all systems touching ePHI
      • 72-hour incident reporting timelines
      • Annual penetration testing
      • Tighter oversight and contractual obligations for business associates

      More than 100 hospital systems and provider associations — including Cleveland Clinic, Yale New Haven Health, Advocate Health, and the American Medical Association — formally asked HHS to withdraw or scale back the proposal, citing cost and implementation timelines.

      HHS didn’t withdraw it. Instead, the agency moved final action from its near-term regulatory agenda to its Long-Term Actions agenda, now targeting July 2027 for a final rule. That’s a one-year-plus slip from the original May 2026 estimate — and Unified Agenda dates are planning estimates, not binding deadlines, so this could move again.

      What the Delay Does Not Change

      This is the part that gets lost in the headlines:

      1. The current Security Rule is still active and enforceable. Every requirement already on the books — risk analysis, access controls, audit controls, transmission security, business associate agreements — remains fully in force. OCR investigations, audits, and civil monetary penalties for violations of the existing rule continue exactly as before.
      2. OCR enforcement priorities haven’t slowed down.Ransomware, ePHI breaches, and risk-analysis failures remain top enforcement targets, and settlements under the current rule continue to be announced regularly.
      3. State law and contractual obligations don’t pause. Many states have their own health data security and breach-notification laws that meet or exceed HIPAA. Cyber insurance underwriters, hospital system contracts, and business associate agreements increasingly bake in MFA, encryption, and incident-response expectations regardless of what the federal rule says.
      4. The direction of travel hasn’t changed, only the timing. Encryption, MFA, and faster breach reporting aren’t going away as regulatory priorities — they’re simply arriving later. Organizations that wait until the rule is finalized to start will be doing a rushed 240-day sprint (60 days to effective date + 180 days to compliance, under the current proposal) instead of a planned multi-year rollout.

      “We Have More Time” Is the Wrong Read

      The delay gives organizations breathing room to prepare well, not permission to deprioritize security. Three reasons this matters:

      • Rulemaking timelines are not compliance timelines.Nothing in HIPAA law says organizations must wait for a final rule before improving encryption or access controls. Most of what’s proposed is already considered best practice and is often expected by cyber insurers and auditors today.
      • A pushed date is not a canceled rule. HHS has reaffirmed the rulemaking is still active; it’s simply been reclassified as a longer-term project. Treating this like the Security Rule update “went away” sets organizations up for a scramble later.
      • Breaches don’t wait for regulations. Ransomware and phishing attacks against healthcare targets have continued to rise. The safeguards in the proposed rule exist because current threat activity outpaced the 2013-era requirements — that risk doesn’t disappear because the paperwork is delayed.

      What Compliance Teams Should Do With the Extra Time

      Run or refresh your risk analysis now, mapping current safeguards against the proposed rule’s requirements to identify gaps early.

      1. Move encryption and MFA from “addressable” to “implemented,” even ahead of any mandate — these are the two changes most likely to survive the rulemaking process largely intact.
      2. Review business associate agreements and vendor oversight, since expanded BA accountability is one of the more consistent themes across the NPRM comments and industry response.
      3. Stress-test your incident response plan against a 72-hour reporting window, even though the current rule doesn’t require it yet — this is the kind of internal capability that takes real time to build.
      4. Document everything. If the rule is finalized on a compressed timeline later, organizations with a documented head start will have an easier path to demonstrating good-faith compliance.

      Frequently Asked Questions

      Is the HIPAA Security Rule update dead?
      No. HHS moved the target for final action to July 2027 on its Long-Term Actions agenda; it did not withdraw the proposal.

      Do I still have to comply with HIPAA Security Rule requirements right now?
      Yes. The current HIPAA Security Rule remains fully in effect and enforceable regardless of the delay to the proposed update.

      When will the new HIPAA Security Rule requirements take effect?
      HHS currently targets July 2027 for final action, but this is an estimate, not a legal deadline, and could shift again. If finalized as proposed, the rule would take effect 60 days after publication, with a 180-day compliance window after that.

      What should healthcare organizations do now?
      Use the additional time to close gaps against the proposed requirements — especially encryption, MFA, business associate oversight, and incident response — rather than waiting for a final rule to start preparing.

      Not Sure Where Your Gaps Are? Find Out Before the Rule Forces You To

      The safest move during this delay isn’t waiting — it’s finding out now where your organization stands against encryption, MFA, business associate oversight, and incident response expectations, so you’re not scrambling later.

      Get a free HIPAA Risk Review. We’ll help you identify gaps in your current Security Rule compliance and show you exactly where to focus before the final rule lands.

      Schedule Your Free HIPAA Risk Review →

      Source

      U.S. Office of Information and Regulatory Affairs, Unified Agenda of Federal Regulatory and Deregulatory Actions — RIN 0945-AA22 (HIPAA Security Rule), reginfo.gov.

    • Does Billing Medicaid Make Schools HIPAA Covered?

      Does Billing Medicaid Make Schools HIPAA Covered?

      Schools Are Billing Medicaid for Behavioral Health Services — Does That Make Your District a HIPAA Covered Entity?

      Quick answer: In most cases, yes — technically. The moment your district (or a provider it employs) electronically bills Medicaid for a student’s mental health or behavioral health services, federal rules treat you as a HIPAA “covered entity” for that transaction. In practice, though, HIPAA’s Privacy Rule almost never governs the actual student records — FERPA does, because the information lives in an “education record.” The real compliance risk isn’t a phantom HIPAA violation; it’s assuming neither law applies and skipping the safeguards both actually require.

      Why Districts Are Asking This Question Right Now

      School-based Medicaid billing for mental and behavioral health services has expanded quickly, and much of that growth is happening outside the traditional special-education framework:

      • A growing number of states — including Arkansas, Missouri, Minnesota, Tennessee, and South Carolina — now allow districts to bill Medicaid for behavioral health services without even filing a State Plan Amendment.

      • Schools nationally receive an estimated $4–6 billion a year in Medicaid reimbursement for school-based services, and only a fraction of states have expanded reimbursement beyond students served under IDEA.

      • Students are roughly six times more likely to access mental health care when it’s offered at school, which is pushing more districts to add counselors, therapists, and telehealth partnerships — and to bill Medicaid for them.

      As behavioral health billing becomes a bigger part of how districts fund student services, the HIPAA question follows naturally: if we’re submitting health care claims, are we now a HIPAA-regulated organization?

      The Technical Answer: Electronic Medicaid Billing Makes You a Covered Entity

      HHS guidance is direct on this point: a school that employs a health care provider — a school psychologist, counselor, therapist, or nurse — who electronically submits a Medicaid claim for a covered transaction becomes a HIPAA “covered entity” for that transaction. This is true whether the district thinks of itself as a health care organization or not.

      It doesn’t matter who does the billing. A school nurse submitting a claim, a contracted mental health provider billing on the district’s behalf, or a telehealth vendor billing under the district’s Medicaid provider number can all trigger covered-entity status for the underlying transaction.

      But FERPA — Not the HIPAA Privacy Rule — Usually Still Governs the Records

      HIPAA’s own regulations carve out an exception: information maintained in “education records” as defined under FERPA is excluded from HIPAA’s definition of protected health information (45 CFR § 160.103).

      Because nearly every health-related record a K-12 school keeps on a student — nurse visit logs, counseling session notes, therapy records tied to an IEP or 504 plan — meets FERPA’s definition of an education record, HIPAA’s privacy protections generally don’t apply to it. FERPA’s do instead.

      The result is a scenario that confuses a lot of administrators: your district can be a HIPAA covered entity that, for privacy purposes, has no protected health information at all — because everything it holds is a FERPA education record instead.

      Where HIPAA Doesn’t Go Away Entirely

      Covered-entity status isn’t purely academic. Even when the Privacy Rule steps aside, a few things still apply:

      • Your district must still comply with HIPAA’s Transaction, Code Set, and Identifier Rules for the Medicaid billing itself — whoever submits the claim, and whatever software or clearinghouse touches it, has to meet those technical standards.

      • If a contracted provider bills independently under its own name — for example, an outside behavioral health agency or telehealth vendor that isn’t itself subject to FERPA — that provider may be a full HIPAA covered entity for the records it creates, privacy rule included.

      • Private and religious schools generally don’t receive federal education funding and typically aren’t subject to FERPA at all — which means a private school billing Medicaid electronically may be a HIPAA covered entity with no FERPA exclusion to fall back on.

      Why the Distinction Actually Matters for Your Compliance Program

      This isn’t just a legal technicality. It changes what your district is required to do in several concrete ways:

      1. Consent requirements differ. FERPA requires written parental (or eligible student) consent before disclosing information for Medicaid billing purposes — a separate requirement from HIPAA authorization, and the one that usually governs here.

      2. Breach response follows different rules. Education records generally trigger FERPA and state student-data-privacy breach obligations, not the HIPAA Breach Notification Rule — unless an independent, non-FERPA-covered provider’s records are involved.

      3. Vendor paperwork needs to match reality. Internal school-based providers typically need FERPA-compliant data-sharing or “school official” agreements. Outside billing vendors, clearinghouses, or telehealth partners that are themselves HIPAA covered entities need Business Associate Agreements.

      4. Security expectations are converging either way. FERPA doesn’t include HIPAA’s detailed Security Rule requirements, but cyber insurers, state privacy laws, and CMS program-integrity reviews increasingly expect HIPAA-grade safeguards around any system that touches Medicaid claims data — regardless of which privacy law technically applies to the record.

      A Compliance Checklist for Districts Billing Medicaid for Behavioral Health

      • Map every point where a district employee or contracted provider submits an electronic Medicaid claim for mental or behavioral health services.

      • For each record type, confirm the governing framework: education record → FERPA governs privacy; independent outside provider not subject to FERPA → HIPAA Privacy Rule likely governs.

      • Update consent forms so FERPA consent language explicitly covers disclosure of information for Medicaid billing purposes.

      • Audit vendor contracts: FERPA-compliant data-sharing agreements for internal providers, Business Associate Agreements for any outside billing vendor, clearinghouse, or telehealth partner that qualifies as a HIPAA covered entity.

      • Apply HIPAA-grade technical safeguards — encryption, access controls, audit logging — to whatever system actually submits the Medicaid claims, even if the broader student record system is FERPA-governed.

      • Train school health staff, counselors, and administrators on which framework governs which piece of information. This is where most real-world confusion, and risk, actually lives.

      Frequently Asked Questions

      Does billing Medicaid for a student’s counseling or therapy services make our school district a HIPAA covered entity?
      Generally, yes. If the district or a health care provider it employs submits an electronic Medicaid claim for a covered transaction, HHS treats the district as a HIPAA covered entity for that transaction — even if the district doesn’t think of itself as a health care organization.

      Does that mean the HIPAA Privacy Rule applies to our students’ behavioral health records?
      Usually not. If those records qualify as “education records” under FERPA — which most school-maintained counseling and mental health records do — HIPAA’s Privacy Rule explicitly excludes them, and FERPA governs privacy instead.

      Do we still need to worry about HIPAA at all?
      Yes. Your district still has to comply with HIPAA’s Transaction, Code Set, and Identifier Rules for the Medicaid billing itself. And if you contract with an outside provider that isn’t subject to FERPA, that provider’s records may be governed by the full HIPAA Privacy Rule.

      What’s the difference between FERPA consent and HIPAA authorization for Medicaid billing?
      FERPA requires written parental or eligible-student consent before disclosing information for Medicaid billing purposes. HIPAA authorization is a separate, more detailed requirement that generally doesn’t apply when the record is a FERPA education record — but it can apply to an independent HIPAA-covered provider working with your district.

      What should our district do first?
      Start by mapping every point where student behavioral health information is electronically billed to Medicaid, then confirm which framework — FERPA or HIPAA — governs each record and each vendor relationship involved.

      Not Sure Which Rules Apply to Your District’s Medicaid Billing? Find Out Before It Becomes a Problem

      FERPA and HIPAA overlap in ways that trip up even well-run compliance programs — especially as more districts add behavioral health billing to their Medicaid programs. The safest move is finding out now exactly which framework governs each piece of your student health data and each vendor relationship, not after an incident forces the question.

      Get a free HIPAA Risk Review. We’ll help you map where FERPA and HIPAA intersect in your district’s Medicaid billing and show you exactly where your compliance gaps are.

      Schedule Your Free HIPAA Risk Review

      Sources

      U.S. Department of Health and Human Services & U.S. Department of Education, Joint Guidance on the Application of FERPA and HIPAA to Student Health Records (December 2019 update).

      45 CFR § 160.103 — HIPAA definitions; exclusion of FERPA “education records” from “protected health information.”

      MACPAC, School-Based Services for Students Enrolled in Medicaid (March 2024), macpac.gov.

      Healthy Schools Campaign, Medicaid Funding for School-Based Services.

    • OCR Fined a Health System $800,000 for Ransomware, Then Published the Fix the Next Day

      OCR Fined a Health System $800,000 for Ransomware, Then Published the Fix the Next Day

      Why Did Lehigh Valley Health Network Pay $800,000, and What Does OCR Expect?

      Quick answer: OCR found that Lehigh Valley Health Network (LVHN) failed to conduct an accurate, thorough risk analysis, did not regularly review information system activity, and notified patients and HHS late after a 2023 ransomware attack exposed the protected health information (PHI) of 248,359 individuals. OCR announced the $800,000 settlement on October 29, 2026. The next day, its October 2026 Cybersecurity Newsletter linked the Cybersecurity and Infrastructure Security Agency’s (CISA) essential steps, including phishing training, multifactor authentication (MFA), logging, backups, and encryption, directly to HIPAA Security Rule requirements. For every covered entity and business associate, the message is the same: these safeguards are already required, and OCR expects them in place before an attack, not after.

      What Happened at Lehigh Valley Health Network

      On February 4, 2023, LVHN, a Pennsylvania health system, detected suspicious activity in its IT system that was later confirmed to be ransomware. LVHN filed a breach report with HHS on May 15, 2023. Attackers exfiltrated PHI and posted it on the dark web; the compromised information included radiation oncology treatment photographs, names, addresses, dates of birth, Social Security numbers, driver’s license numbers, financial information, diagnoses, lab results, medications, and treatment information.

      Under the resolution agreement, LVHN paid $800,000 and agreed to a corrective action plan that OCR will monitor for three years. OCR identified the settlement as its 22nd ransomware enforcement action. OCR Director Paula M. Stannard summarized the agency’s position plainly: “The best defense against cyberattacks is full implementation of the HIPAA Security Rule.”

      What OCR Found

      OCR’s investigation began with LVHN’s breach report and found potential violations of the Privacy, Security, and Breach Notification Rules:

      • No accurate and thorough risk analysis of the potential risks and vulnerabilities to all of its electronic protected health information (ePHI).
      • No procedures to regularly review information system activity, such as audit logs, access reports, and security incident tracking reports.
      • An impermissible disclosure of the PHI of 248,359 individuals.
      • Late notification to affected individuals of a breach of unsecured PHI.
      • Late notification to the Secretary of HHS of the same breach.

      The corrective action plan requires a new risk analysis, a risk management plan, revised policies and procedures, and updated workforce training.

      Three Lessons From the Findings

      1. Enforcement has a long tail

      More than three and a half years passed between discovery of the attack and the settlement. The documentation you have today is what OCR will evaluate years from now; it cannot be rebuilt after the fact.

      2. Logging is only half the control

      The Security Rule separates audit controls, which record system activity, from information system activity review, which requires someone to examine it. OCR cited LVHN for the second. Logs nobody reads will not catch an intruder before data leaves the network.

      3. The breach notification clock does not wait for the investigation

      HIPAA requires notice to affected individuals without unreasonable delay and no later than 60 calendar days after discovery, and notice to HHS within the same window when 500 or more individuals are affected. LVHN’s breach report was filed more than three months after LVHN discovered the suspicious activity, and OCR cited late notice to both individuals and HHS as separate violations. A slow response adds violations on top of the breach itself.

      One Day Later, OCR Published the Roadmap

      OCR’s October 2026 Cybersecurity Newsletter, released for Cybersecurity Awareness Month under the theme “Securing the Next 250,” took the essential steps CISA recommends for critical infrastructure organizations, including the Healthcare and Public Health sector, and tied each one to a specific Security Rule requirement.

      Phishing training maps to security awareness and training; strong passwords and MFA map to person or entity authentication; software updates map to risk analysis and risk management; logging maps to audit controls and information system activity review; backups map to the data backup plan; encryption maps to the encryption specifications for data at rest and in transit; incident response plans map to security incident procedures; and preparing for system disruptions maps to the contingency plan. The one step HIPAA does not require is reporting cyber incidents to CISA, which OCR encourages but does not mandate.

      Where the Settlement and the Newsletter Point to the Same Gaps

      The risk analysis drives everything else. The newsletter ties authentication choices and patching priorities back to the risk analysis, and OCR’s recommendations in the LVHN announcement start with identifying how ePHI enters, flows through, and leaves your systems. Without an accurate and thorough risk analysis, no other security decision is defensible.

      System activity review is a recurring enforcement theme. It is a finding in the LVHN settlement and a core step in the newsletter. If you cannot show who reviews logs, how often, and what happens next, OCR will find that gap.

      Backups must survive the attack. Because some ransomware deletes or disrupts online backups, OCR advises keeping at least some backups offline, reviewing backup logs, and periodically testing restorations.

      Addressable does not mean optional. ePHI must be encrypted at rest and in transit wherever reasonable and appropriate; where it is not, the organization must implement an equivalent alternative, if reasonable and appropriate, and document its rationale.

      Reporting to CISA is not HIPAA breach reporting. A CISA report does not satisfy HIPAA breach notification; individuals, HHS, and, where required, the media must still be notified.

      What to Do Before OCR Asks

      • Complete or update a risk analysis that traces ePHI where it enters, flows through, and leaves every system, vendor, and location.
      • Build a risk management plan that assigns an owner, a safeguard, and a target date to each identified risk.
      • Assign responsibility for regular log and access report review, and document each review.
      • Confirm backups include offline copies, and keep records of successful restoration tests.
      • Document your encryption decisions for ePHI at rest and in transit, including any equivalent alternatives.
      • Base authentication decisions, including where MFA is required, on your risk analysis.
      • Rehearse your incident response plan at least annually with leadership, legal counsel, and technical staff, and confirm it meets HIPAA’s 60 day breach notification deadline.
      • Train every workforce member, including management, on phishing and their role specific responsibilities.

      Frequently Asked Questions

      What was the Lehigh Valley Health Network HIPAA settlement?

      On October 29, 2026, OCR announced that LVHN paid $800,000 and agreed to a corrective action plan monitored for three years, resolving an investigation into a 2023 ransomware attack that affected 248,359 individuals. It was OCR’s 22nd ransomware enforcement action.

      Why would OCR penalize an organization that was the victim of a ransomware attack?

      OCR does not penalize the attack itself; it penalizes the compliance failures uncovered by the investigation. At LVHN, those included a lack of an accurate and thorough risk analysis, no regular review of information system activity, and late breach notification.

      Does HIPAA require multifactor authentication?

      The Security Rule does not prescribe a specific authentication method, but it requires procedures to verify that anyone seeking access to ePHI is who they claim to be. OCR’s October 2026 newsletter explains that the risk analysis should guide the choice and that MFA may be needed to reduce risk for remote access and more sensitive systems.

      Is encryption required under HIPAA?

      Encryption is an addressable specification, meaning regulated entities must encrypt ePHI at rest and in transit wherever reasonable and appropriate. If encryption is not reasonable and appropriate in a specific circumstance, the organization must implement an equivalent alternative measure, if reasonable and appropriate, and document its decision and rationale.

      Don’t Let Your Risk Analysis Become the Finding; Colington Consulting Can Help

      Ransomware settlements keep returning to the same core finding: a lack of accurate, thorough risk analysis. Colington Consulting’s lead consultants have personally conducted more than 1,000 HIPAA risk assessments. We map how ePHI is created, moves, and leaves your organization across every system, vendor, and location; we evaluate the safeguards OCR actively enforces, including system activity review, backup isolation and testing, encryption decisions, authentication, and incident response; and we deliver a documented risk management plan that holds up when OCR requests it.

      Get a free HIPAA Risk Review. We will show you where your organization stands against the findings in the LVHN settlement and the steps in OCR’s October 2026 newsletter, and where to focus first.

      Schedule Your Free HIPAA Risk Review →

      Sources

      U.S. Department of Health and Human Services, Office for Civil Rights, “HHS’ Office for Civil Rights Settles Ransomware Investigation of Lehigh Valley Health Network,” October 29, 2026.

      U.S. Department of Health and Human Services, Office for Civil Rights, October 2026 OCR Cybersecurity Newsletter, “Cybersecurity Awareness Month 2026,” October 30, 2026.

      U.S. Department of Health and Human Services, Office for Civil Rights, October 2022 Cybersecurity Newsletter, “HIPAA Security Rule Security Incident Procedures.”

      Cybersecurity and Infrastructure Security Agency, Cybersecurity Awareness Month Toolkit (2026), cisa.gov.

      45 C.F.R. § 164.308(a)(1), Security Management Process; § 164.308(a)(5), Security Awareness and Training; § 164.308(a)(6), Security Incident Procedures; § 164.308(a)(7), Contingency Plan.

      45 C.F.R. § 164.312(b), Audit Controls; § 164.312(d), Person or Entity Authentication; §§ 164.312(a)(2)(iv) and 164.312(e)(2)(ii), Encryption; § 164.306(d)(3), Addressable Implementation Specifications.

      45 C.F.R. §§ 164.400 through 164.414, Breach Notification Rule.

    • 5 HIPAA Compliance Gaps That Put Healthcare Organizations at Risk

      Why Small Gaps Create Big Exposure

      HIPAA compliance failures rarely begin with a single dramatic mistake. More often, they stem from overlooked documentation, inconsistent staff practices, incomplete risk reviews, or security controls that have not kept pace with operational change. For healthcare providers and business associates, these gaps can increase exposure during audits, investigations, and breach response.

      Colington Consulting helps organizations build defensible HIPAA compliance programs that are practical, documented, and aligned with real-world regulatory expectations. Below are five common compliance gaps that deserve immediate attention.

      1. Incomplete Risk Assessments

      A HIPAA risk assessment should do more than satisfy a checkbox. It should identify where protected health information is created, stored, transmitted, and exposed across systems, vendors, workflows, and physical environments. When assessments are outdated, too narrow, or unsupported by evidence, organizations may struggle to demonstrate a reasonable compliance posture.

      • A defensible risk assessment creates the foundation for stronger decisions, better documentation, and more credible compliance efforts.

      2. Weak Risk Management Follow-Through

      Finding risks is only the beginning. A common problem is the absence of a documented risk management plan that prioritizes issues, assigns responsibility, and tracks remediation over time. Without follow-through, known weaknesses remain unresolved and can become harder to explain after an incident.

      3. Staff Training That Lacks Depth

      HIPAA training should reflect actual job responsibilities and current threats, not just generic annual reminders. Workforce members need clear guidance on privacy expectations, security practices, phishing awareness, device use, reporting procedures, and how to handle protected health information in day-to-day operations.

      • Role-based training improves relevance
      • Recurring refreshers reinforce accountability
      • Documented completion records support compliance readiness

      4. Outdated Policies and Documentation

      Policies that do not match current systems, vendors, or workflows can create significant compliance risk. Organizations should regularly review privacy and security documentation, business associate oversight practices, facility safeguards, and incident response procedures to ensure written materials reflect operational reality.

      5. Limited Access to Expert Guidance

      Many organizations do not need a large internal compliance department, but they do need reliable expertise when important decisions arise. Virtual HIPAA compliance officer support and hourly consulting can help leadership evaluate risks, respond to questions, and strengthen documentation before issues escalate.

      What a Stronger Program Looks Like

      A stronger HIPAA compliance program is not built on assumptions. It is built on documented assessments, practical risk management, informed staff, current policies, and access to experienced consulting support. When these elements work together, organizations are better positioned to reduce risk exposure and respond confidently to regulatory scrutiny.

      How Colington Consulting Helps

      Colington Consulting supports healthcare providers and business associates with HIPAA risk assessments, risk management plans, staff training, policy reviews, privacy and security rule documentation, facility security planning, and ongoing consulting guidance. The goal is to help organizations create compliance programs that are practical, defensible, and ready for real-world challenges.

      If your organization is unsure whether its current HIPAA program would hold up under an audit, investigation, or breach review, now is the right time to evaluate the gaps and strengthen the foundation.

    • Why HIPAA Is Still Confusing After Thirty Years, Especially for Small and Midsize Providers

      Why HIPAA Is Still Confusing After Thirty Years, Especially for Small and Midsize Providers

      Quick answer: HIPAA has been federal law since 1996, yet small and midsize providers still get tripped up by it, and the reason is rarely carelessness. Most owners and office managers never received formal HIPAA training; they inherited assumptions from a prior job, a vendor’s marketing page, or an online forum, and those assumptions are often wrong. The confusion tends to fall into two camps that look opposite but create the same exposure: providers who assume a tool or vendor already handles compliance for them, and providers who never learned the regulations well enough to tell a permitted disclosure from one that actually requires authorization. Both leave real gaps, and OCR, along with a growing number of state regulators, is actively finding them.

      Thirty Years Old, Still Misunderstood

      HIPAA is not a new law, and that is part of the problem. It has been amended, reinterpreted, and layered with guidance so many times since 1996 that the version most people learned, whether from a compliance seminar a decade ago or a coworker’s offhand explanation, is often out of date. Add in the fact that most clinicians and practice administrators never sat through a formal HIPAA course in school, and you get a compliance culture built on secondhand information rather than the actual rule text.

      That gap shows up constantly in small practice communities online, where one commenter insists a tool is safe, another insists it never can be, and a third says solo practices simply do not get looked at. None of them are working from the regulation itself; they are working from what they have heard. The confusion is understandable. It is also, according to compliance experts who work directly with small practices, a training problem rather than a character problem, and it is fixable once the actual myths are named and corrected.

      Myth One: “Our Software Already Makes Us HIPAA Compliant”

      This is the myth doing the most quiet damage right now. A recent survey of IT leaders and practice managers at organizations with fewer than 250 employees found that nearly all of them believed their email platform automatically encrypted messages containing patient information. In reality, common business tools like Microsoft 365 and Google Workspace do not guarantee that protection by default; encryption can drop entirely if the recipient’s mail server does not support current protocols, leaving protected health information exposed without anyone realizing it. Close to half of healthcare email breaches trace back to Microsoft 365 environments alone.

      The same false confidence shows up with EHR platforms. A vendor’s business associate agreement covers how that vendor handles data inside its own system; it does not cover how your staff handles PHI outside the EHR, and it does not satisfy your own obligation to conduct a Security Risk Analysis. An EHR is a clinical documentation tool. It is not a compliance program, no matter what the marketing page implies.

      Myth Two: “Regulators Only Care About Big Health Systems”

      Every headline breach involves a hospital system or a national health plan, so it is an easy leap to assume enforcement follows the same pattern. It does not. OCR has been explicit that practice size does not create an exemption, and enforcement data backs that up: small medical and dental practices accounted for the majority of OCR’s financial penalties in a recent reporting year. Investigations are frequently triggered by something small, a single patient complaint, a lost laptop, or a phishing email that catches one employee, not a headline grade breach.

      Risk analysis failures have been the single most cited deficiency in OCR enforcement actions for more than a decade, and that pattern holds regardless of organization size. A five provider practice and a five hundred provider hospital system are held to the same underlying standard; the hospital system just has more staff to absorb the work.

      Myth Three: “HIPAA Only Applies Once Someone Is Officially Our Patient”

      It is a natural assumption. In most professional relationships, obligations start once a formal engagement begins, so providers assume PHI protections kick in once someone signs an intake form or shows up for a first visit. HIPAA does not draw that line. Protected health information is defined as individually identifiable information related to a person’s past, present, or future healthcare, which means a phone call, an intake questionnaire, or even a scheduling message can already be covered before a formal patient relationship exists.

      Myth Four: “The Safest Move Is to Share Nothing With Anyone”

      Overcorrection is just as common as underprepared, and it carries its own cost. Some practices become convinced they cannot discuss a patient anywhere on the premises, or that every routine disclosure for treatment purposes needs a separate signed authorization. Compliance risk management professionals who work with small providers regularly see practices treat ordinary care coordination, like transferring records to a specialist for continued treatment, as though it required the same authorization process as a marketing disclosure. It does not. HIPAA already permits use and disclosure of PHI for treatment, payment, and healthcare operations without a separate authorization each time; practices that add friction here are not being safer, they are just slower, and staff eventually start looking for workarounds that create real risk.

      Myth Five: “A HIPAA Compliant Vendor Means We Are a HIPAA Compliant Practice”

      This one deserves its own heading because it is so common. Signing on with a vendor who advertises HIPAA compliant software, hosting, or messaging is a meaningful step, but it addresses one piece of a much larger program. Your practice still needs its own current Security Risk Analysis, its own written policies and procedures, its own workforce training, and its own documented incident response plan; none of that transfers from a vendor’s compliance posture to yours. Even organizations with no self funded health plan or complex vendor stack still need these four documented pieces, because they are what OCR asks for first in any investigation or audit.

      Why This Confusion Is Expensive, Not Just Awkward

      None of this would matter much if the stakes were low, but they are not. Healthcare has held the highest average breach cost of any industry sector for well over a decade running, and small practices absorb that cost with far less cushion than a large system. State regulators have also become more active alongside OCR, with several states bringing high profile settlements against small practices in the past year, which means a multi-state practice can no longer rely on federal HIPAA alone; state overlay requirements increasingly apply too.

      The pattern across almost every enforcement action tells the same story: it is rarely one dramatic mistake. It is a pile of ordinary, unremarkable decisions, a personal phone used for patient texts because it is faster, a new scheduling tool adopted without a signed business associate agreement, a risk analysis that was accurate three systems ago and never got updated, that nobody treated as a compliance decision when it was made.

      What Actually Clears Up the Confusion

      The fix is not memorizing the regulation. It is building a small number of documented habits that hold up regardless of which myth an employee picked up somewhere along the way.

      • Treat your Security Risk Analysis as a living document, not a one time project; update it whenever you change EHR systems, add a telehealth platform, or bring on new staff.
      • Confirm encryption in writing rather than assuming it; ask your email and EHR vendors directly whether encryption is guaranteed by default or dependent on the recipient’s system.
      • Map every point where PHI can leave your walls, phone, email, fax, text, patient portal, and confirm a business associate agreement or a documented safeguard covers each one.
      • Separate treatment, payment, and healthcare operations disclosures, which generally do not require a signed authorization, from marketing or research disclosures, which usually do.
      • Put workforce training on a real schedule, not a onboarding checkbox; most confusion traces back to staff repeating what they were told once, years ago, by someone who was also guessing.

      A Quick Self Check for Small and Midsize Practices

      ☐  Do you have a Security Risk Analysis completed or updated within the last twelve months?

      ☐  Have you confirmed, in writing, whether your email and messaging platforms encrypt PHI by default?

      ☐  Do your written policies distinguish between disclosures that require patient authorization and those that do not?

      ☐  Does every vendor touching PHI have a current, signed business associate agreement on file?

      ☐  Has your team received HIPAA training in the last year, beyond a one time onboarding session?

      ☐  If you offer a self funded employee health plan, has it been assessed as its own separate covered entity?

      Not Sure Where Your Practice Actually Stands? Colington Consulting Can Help You Find Out

      Most of the small and midsize providers we work with are not careless; they are working from secondhand information that was never fully accurate to begin with. Colington Consulting works hands on with small practices, clinics, and specialty groups to replace assumptions with a documented, defensible compliance program built for organizations that do not have a dedicated compliance department.

      Get a free HIPAA Risk Review. We will walk through where your practice’s understanding of HIPAA may be out of date, identify the gaps that matter most, and show you exactly where to focus first.

      Schedule Your Free HIPAA Risk Review →

      Sources

      Medical Economics, “Most small practices think they’re HIPAA compliant, a new report says they’re wrong,” reporting on Paubox survey data of IT leaders and practice managers at organizations under 250 employees.

      Patient Protect, “HIPAA Compliance for Independent Medical Practices: The Complete 2026 Guide.”

      Facet Technologies, “What the 2026 HIPAA Changes Actually Mean for Your Practice.”

      HIPAA Journal, “Editorial: HIPAA Compliance Challenges for Small Medical Practices” and “Why You Don’t Need to Understand HIPAA to Make Your Small Practice HIPAA Compliant.”

      Physicians Practice, “Four Common HIPAA Misconceptions.”

      U.S. Department of Health and Human Services, HIPAA Guidance Materials, hhs.gov.

      Frequently Asked Questions

      Is a small medical or dental practice actually at risk of a HIPAA investigation?

      Yes. OCR has increasingly focused enforcement attention on smaller practices, and in a recent reporting year, small medical and dental practices accounted for the majority of OCR’s financial penalties. Investigations are often triggered by a single patient complaint or a routine incident, not a large scale breach.

      Does using a HIPAA compliant EHR mean our practice is fully compliant?

      No. An EHR vendor’s business associate agreement covers how that vendor handles data within its own system. It does not cover how your staff uses PHI outside the EHR, and it does not satisfy your practice’s own requirement to complete and maintain a Security Risk Analysis.

      Does HIPAA require a signed authorization before discussing a patient with another treating provider?

      Generally, no. HIPAA permits use and disclosure of PHI for treatment, payment, and healthcare operations without a separate authorization for each instance. Authorization requirements typically apply to disclosures outside those categories, such as marketing.

      When do HIPAA protections actually start applying to a person’s information?

      Protected health information is defined by an individual’s past, present, or future healthcare, not by whether a formal patient relationship has begun. Information shared during an intake call or scheduling message can already be covered.

      What is the single most common deficiency OCR cites in enforcement actions?

      Risk analysis failures. An incomplete, outdated, or missing Security Risk Analysis has been the most frequently cited deficiency in OCR enforcement for more than a decade, across organizations of every size.

    • Does Having an MSP Mean Your Practice Is HIPAA Compliant? Not on Its Own

      Does Having an MSP Mean Your Practice Is HIPAA Compliant? Not on Its Own

      Quick answer: No, and this is one of the most common and most understandable misconceptions in healthcare compliance. A skilled managed service provider, or MSP, can lock down your network, patch your systems, and manage backups better than most practices could on their own; if that MSP handles protected health information, it is likely a business associate with its own direct HIPAA obligations. None of that, on its own, satisfies your practice’s obligations. The Security Rule requires every covered entity to maintain its own compliance program; a practice still needs its own risk analysis, policies, workforce training, and a signed business associate agreement with every vendor that touches patient data, including its IT partner.

      Where the False Sense of Security Comes From

      It is an easy assumption to make. A practice hires a capable IT company; that company installs firewalls, manages antivirus tools, sets up secure backups, and generally keeps the network running well. From the practice’s point of view, the technical side of compliance feels handled. The trouble is that HIPAA compliance is not only a technical question. It also requires a documented risk analysis, written policies and procedures, a designated privacy and security officer, workforce training records, and an incident response plan tied specifically to protected health information. A great MSP can support several of these pieces; it cannot generate them on its own, and it certainly cannot sign them on the practice’s behalf.

      What a Good MSP Actually Covers, and What It Doesn’t

      Most reputable MSPs are genuinely strong at the technical safeguards: encryption, access controls, patch management, monitoring, and secure backups. Where the gap tends to show up is on the administrative side, since a Security Risk Analysis, HIPAA-specific workforce training, and a program for managing business associate agreements across every vendor a practice uses are compliance program tasks, not network tasks; they belong to the covered entity, even when an MSP is excellent at its own job.

      Why Not Every MSP Understands HIPAA Either

      This is the part that deserves equal attention. In our experience, most MSPs are genuinely good at IT; general cybersecurity, network uptime, and help desk support are their bread and butter. HIPAA, though, is a specific regulatory framework with its own definitions, documentation requirements, and enforcement history, and general IT training does not automatically cover it. A provider that assumes any IT company can double as a HIPAA partner is often building its compliance program on an assumption nobody actually verified. This is not a knock on MSPs; it is simply a reminder that HIPAA knowledge and IT skill are two different areas of expertise, and a practice should confirm, in writing, that its MSP genuinely understands the requirements rather than assuming it by default. Because of this, Colington Consulting works only with MSP referral partners who demonstrably understand HIPAA’s administrative, physical, and technical safeguard requirements, not just general network security.

      The Data Behind the Confidence Gap

      A recent survey of 214 IT leaders and practice managers at healthcare organizations with fewer than 250 employees found that 98 percent believed their email platforms encrypted messages by default, and more than 80 percent expressed overall confidence in their HIPAA compliance posture; in reality, tools like Microsoft 365 and Google Workspace do not guarantee that protection, and encryption can silently fail if a recipient’s server does not support current protocols. The same survey found that 83 percent believed a patient’s consent to email removed the legal requirement for safeguards, which is incorrect. As the Director of the HHS Office for Civil Rights has said, risk assessments are not optional; they are foundational, and that obligation applies to the covered entity’s own program, even when a capable vendor manages the network.

      What This Means for Your Practice

      • A signed business associate agreement with your MSP covers how it protects data, not whether your practice as a whole is HIPAA compliant.
      • Your practice still needs its own current Security Risk Analysis, documented policies, and workforce training records; none of that transfers from a vendor.
      • Ask your MSP directly how it stays current on HIPAA-specific requirements, not just general cybersecurity best practices.
      • A strong MSP and a strong compliance program work together; one does not substitute for the other.

      Not Sure If Your IT Setup Actually Covers Your Compliance Obligations? Colington Consulting Can Help You Find Out

      A capable MSP is a valuable part of a compliance program; it was never meant to be the whole program. Colington Consulting works directly with small and midsize providers to build the documented, defensible pieces that sit outside of IT, and we only refer clients to MSP partners who genuinely understand HIPAA’s requirements.

      Get a free HIPAA Risk Review. We’ll help you see exactly where your IT setup ends and your compliance obligations begin, and show you what still needs to be built.

      Schedule Your Free HIPAA Risk Review →

      Sources

      U.S. Department of Health and Human Services, Office for Civil Rights, statement on HIPAA Security Rule risk assessment obligations.

      Paubox, survey of 214 IT leaders and practice managers at healthcare organizations under 250 employees, reported in Medical Economics, “Most small practices think they’re HIPAA compliant, a new report says they’re wrong.”

      Frequently Asked Questions

      If our IT company signs a business associate agreement, are we HIPAA compliant?

      No. A business associate agreement establishes how your MSP is expected to protect data it can access; it does not satisfy your practice’s own obligation to complete a Security Risk Analysis, maintain policies, or train your workforce.

      Does a HIPAA-compliant MSP mean we do not need our own compliance program?

      No. Even organizations with excellent technical safeguards still need their own documented risk analysis, policies, and training; these are the covered entity’s own administrative requirements, and they hold regardless of how compliant your MSP is with its own separate obligations.

      How do we know if our MSP actually understands HIPAA?

      Ask specific questions, such as how they support your Security Risk Analysis, how they handle breach notification timelines, and whether they can speak to the difference between HIPAA and general cybersecurity best practices; a partner who cannot answer clearly is a signal worth taking seriously.

    • Why Syncing Data to the Cloud Isn’t a Valid HIPAA Ransomware Strategy

      Why Syncing Data to the Cloud Isn’t a Valid HIPAA Ransomware Strategy

      If your practice or business relies on continuous cloud sync or daily cloud snapshots as your primary disaster recovery strategy, your ePHI is far more vulnerable than you think.

      Modern malware doesn’t just encrypt local workstations; it actively targets connected network drives, mapped cloud folders, and online backup repositories. If your backup target is continuously connected to your network, ransomware can encrypt the backup right along with your live electronic Protected Health Information (ePHI).

      The Flaw in Standard Cloud Sync

      Standard cloud storage services mirror changes made on local devices in real time. If a ransomware strain silently encrypts files on a local server, those encrypted files instantly sync to the cloud, overwriting clean versions.

      In its Ransomware and HIPAA Fact Sheet, the HHS Office for Civil Rights (OCR) emphasizes that ransomware is specifically designed to deny access to data. Simply having a cloud backup provider sign a Business Associate Agreement (BAA) satisfies administrative requirements. Still, it does not satisfy the technical requirements of data recovery if the underlying backup mechanism is vulnerable to simultaneous encryption.

      What the HIPAA Security Rule Actually Requires

      Under the HIPAA Security Rule, maintaining retrievable data isn’t just an IT best practice—it is an explicit legal mandate under the Contingency Plan standard (45 C.F.R. § 164.308(a)(7)).

      According to HHS guidance on HIPAA contingency planning, covered entities and business associates must implement three core specifications:

      1. Data Backup Plan (§ 164.308(a)(7)(ii)(A)): Establish and implement procedures to create and maintain retrievable, exact copies of ePHI.
      2. Disaster Recovery Plan (§ 164.308(a)(7)(ii)(B)): Establish procedures to restore any lost data resulting from an emergency or cyberattack.
      3. Testing and Revision Procedures (§ 164.308(a)(7)(ii)(E)): Perform periodic testing and revision of contingency plans to verify data can actually be restored.

      Building an HHS-Aligned Cyber Resilience Strategy

      To meet OCR expectations during a post-incident investigation, HHS security guidance recommends moving beyond basic cloud sync to a resilient backup framework:

      • Maintain Isolated/Air-Gapped Copies: Backups must be decoupled from the primary network. Immutable storage—where data is written once and cannot be altered or deleted, even by an administrative account—ensures ransomware cannot wipe out recovery points.
      • Implement Strict Access Controls: Under 45 C.F.R. § 164.308(a)(3), backup administrative controls must be isolated, requiring multi-factor authentication (MFA) and restricted access to prevent credential-based wiping.
      • Document Regular Restoration Tests: OCR auditors evaluate whether an organization regularly tests data restoration. Running routine restoration drills proves that backup files are uncorrupted and accessible within necessary operational timeframes.

      Action Steps for Practice Managers

      1. Audit Backup Isolation: Verify with your IT team or Managed Service Provider (MSP) whether your backups are truly air-gapped or protected by immutable object locking.
      2. Verify Testing Logs: Ensure your technical staff or vendor provides written verification of successful data restoration tests to include in your annual Security Risk Assessment (SRA) documentation.

      Not Sure Your Backups Would Actually Survive a Ransomware Attack? Colington Consulting Can Help You Find Out

      A cloud sync tool and a signed Business Associate Agreement feel like protection, but they do not test whether your data actually comes back after an attack. Colington Consulting works directly with practices and businesses to build a documented, defensible contingency plan that meets the Security Rule’s backup, disaster recovery, and testing requirements, not just the appearance of one.

      Get a free HIPAA Risk Review. We will help you evaluate your backup isolation, restoration testing, and contingency planning against what OCR actually expects, and show you exactly where to focus first.

      Schedule Your Free HIPAA Risk Review →

    • What OCR Told Us at the 2026 HIPAA Security Conference: Enforcement, Risk Analysis, and Policy Gaps

      What OCR Told Us at the 2026 HIPAA Security Conference: Enforcement, Risk Analysis, and Policy Gaps

      Quick answer: At the OCR/NIST “Safeguarding Health Information” conference held September 2 to 3, 2026, in Gaithersburg, Maryland, HHS’s Office for Civil Rights delivered a consistent message across sessions: enforcement is not slowing down; risk analyses remain the most commonly cited deficiency because they are still inaccurate or incomplete; and many organizations still lack the documented policies and procedures needed to turn a risk analysis into an actual risk management program. OCR was direct on one point in particular: organizations should not wait for a breach, or a completed OCR investigation, before conducting a compliant risk analysis.

      Why This Conference Matters for Compliance Programs

      Each year, OCR and NIST’s Information Technology Laboratory co-host this conference to walk through where enforcement is headed and where organizations continue to fall short. This year’s agenda, spanning two full days, included briefings from OCR’s Director, threat intelligence updates from the Health Information Sharing and Analysis Center, and a dedicated OCR track on the Health Information Privacy, Data, and Cybersecurity Division’s own enforcement data.

      For compliance teams that could not attend, the sessions functioned less like a lecture and more like a preview of what OCR expects to see when it opens the next investigation, whether that investigation starts with a breach report or a routine complaint.

      Three themes ran through nearly every OCR-led session.

      1. Enforcement Is Not Slowing Down

      OCR used its own numbers to make the point directly. As of this year’s conference, OCR reported 21 completed ransomware investigations and 14 completed investigations under its Risk Analysis Enforcement Initiative; separately, its Right of Access Initiative, focused on individuals being denied timely access to their own health records, has produced 55 completed enforcement actions to date, with a newly stated focus on parent and personal representative access requests.

      The shift in breach data helps explain where that enforcement attention is concentrated. Comparing OCR’s historical breach portal data, September 2009 through December 2025, against the first seven months of 2026:

      • Hacking and IT incidents grew from 52 percent of reported large breaches to 75 percent.
      • Network servers, as the breach location, grew from 39 percent to 68 percent.
      • Theft, once 18 percent of reported breaches, has fallen to roughly 1 percent.
      • Physical causes, such as paper records and lost laptops, have both dropped to a small share of the total.

      In short, OCR’s own data show breaches are concentrated almost entirely in network-based, hacking-related incidents, and its enforcement priorities follow that data. Organizations that assume a strong physical security posture covers their exposure are missing where the actual risk, and the actual enforcement attention, now sits.

      2. OCR Still Finds Risk Analyses Inaccurate and Incomplete

      If OCR repeated one message more than any other, it was this: a risk analysis is requested in every Security Rule investigation OCR conducts, and it remains one of the most commonly deficient documents organizations produce.

      OCR drew a specific distinction that trips up many compliance programs: a gap analysis is not the same as a risk analysis. A gap analysis compares current practices against a checklist or a set of standards. A risk analysis, as required under the Security Rule’s Security Management Process standard, is a more rigorous exercise; it requires organizations to assess risks to all electronic protected health information at every stage in which that information exists within the organization, with enough specificity to drive decisions.

      OCR’s guidance broke this down into three stages that a thorough risk analysis has to cover:

      • Where ePHI is created or enters the organization: file transmissions and uploads, manual data entry or edits to existing ePHI, and lab results or images coming in from outside systems.
      • Where ePHI flows within the organization: movement into EHR systems, between clinical and other departments, through applications such as office productivity tools, web and mobile platforms, and remote access, and across infrastructure such as backups and system logs.
      • Where ePHI leaves the organization: email, fax, and file transfer applications, collaboration tools, and equipment disposal.

      An organization that has assessed risk at only one of these three stages, most commonly the point where ePHI enters or lives in the primary EHR, has not completed the kind of accurate and thorough risk analysis the Security Rule actually requires. This is very likely why risk analysis deficiencies remain the most cited finding across OCR’s enforcement actions.

      3. Organizations Still Lack Comprehensive Policies and Procedures

      The third theme is closely tied to the second. OCR was clear that a risk analysis is not the finish line; it is meant to be a direct input into an organization’s risk management process, used to develop corrective actions for each identified risk and to guide the implementation of security measures that reduce risk to a reasonable and appropriate level while protecting the confidentiality, integrity, and availability of ePHI.

      In practice, this is where many compliance programs stall. A risk analysis is completed, findings are documented, and then the corresponding policies, procedures, and corrective action plans are never built, updated, or tied back to what the risk analysis actually found. The Right of Access Initiative is a clear example of this gap in action: individuals have a right under the Privacy Rule to timely access to their own health records, generally within 30 days, with the possibility of one 30-day extension, and at a reasonable, cost-based fee. OCR continues to receive a high volume of complaints alleging denial of access, which points less to organizations being unaware of the rule and more to access request procedures that are not documented, not followed consistently, or not updated to reflect current staff and systems.

      The pattern OCR described is consistent: a risk analysis without a connected risk management program, and policies without a documented, current process behind them, are both incomplete compliance postures, even when each piece looks reasonable on its own.

      What OCR Wants Organizations to Do Right Now

      OCR’s message on timing was direct, and it is worth stating exactly as presented: organizations should not wait for a breach, or for a completed OCR investigation, before conducting a compliant risk analysis. Waiting is, itself, the exposure.

      OCR also pointed attendees to its own risk analysis resources, including a risk analysis explainer video, the Security Risk Assessment (SRA) Tool, and ongoing guidance and cybersecurity newsletters, all built to help organizations complete a risk analysis that meets the Security Rule’s standard rather than a lighter gap assessment.

      Organizations must also notify affected individuals of a breach no later than 60 calendar days after discovery, a deadline that does not shift based on the organization’s size or complexity.

      Not Sure Your Risk Analysis Would Hold Up to OCR’s Standard? Colington Consulting Can Help You Find Out

      OCR was clear that a risk analysis needs to cover ePHI at every stage it exists in your organization, feed directly into a documented risk management program, and stay current, not sit as a one-time project. Colington Consulting works directly with covered entities and business associates to build and maintain the accurate, thorough risk analysis and related policies and procedures OCR expects to see before an investigation starts.

      Get a free HIPAA Risk Review. We will help you see exactly where your risk analysis and policies and procedures stand relative to what OCR is actually enforcing, and show you where to focus first.

      Schedule Your Free HIPAA Risk Review →

      Sources

      U.S. Department of Health and Human Services, Office for Civil Rights, and National Institute of Standards and Technology, “Safeguarding Health Information: Building Assurance Through HIPAA Security” Conference, September 2 to 3, 2026, NIST Gaithersburg Campus, Gaithersburg, MD.

      U.S. Department of Health and Human Services, Office for Civil Rights, conference session materials: Risk Management; Key Takeaways; Right of Access Initiative; Risk Analysis: Accurate and Thorough.

      U.S. Department of Health and Human Services, Office for Civil Rights, HIPAA Breach Portal data, breaches by type and location of breach, September 23, 2009 through July 31, 2026.

      45 C.F.R. § 164.308(a)(1) — Security Management Process (Risk Analysis and Risk Management).

      45 C.F.R. § 164.524 — Right of Access.

      Frequently Asked Questions

      Is OCR’s HIPAA enforcement slowing down in 2026?

      No. OCR reported 21 completed ransomware investigations, 14 completed Risk Analysis Enforcement Initiative investigations, and 55 completed Right of Access enforcement actions as of its 2026 conference, and its breach data shows hacking and network server incidents making up a growing share of reported breaches.

      Is a gap analysis the same as a HIPAA risk analysis?

      No. OCR was explicit that a gap analysis, which compares current practices to a checklist, does not meet the Security Rule’s risk analysis requirement. A compliant risk analysis assesses risk to all ePHI as it is created, as it flows through the organization, and as it leaves the organization.

      Does OCR require a risk analysis for every investigation?

      Yes. OCR stated that it requests a risk analysis in every Security Rule investigation it conducts, which makes an outdated or incomplete risk analysis one of the most common findings across enforcement actions.

      What is OCR’s Right of Access Initiative?

      It is an enforcement initiative focused on individuals being denied timely access to their own health records. The HIPAA Privacy Rule requires access generally within 30 days, with one possible 30-day extension, at a reasonable, cost-based fee; OCR has completed 55 enforcement actions under this initiative and has signaled a new focus on parent and personal representative access.

      Should organizations wait for a breach before doing a risk analysis?

      No. OCR was clear on this point: organizations should not wait for a breach or a completed OCR investigation before conducting a compliant risk analysis.

    • OCR and ONC Just Updated the Free SRA Tool; Here’s Why That Doesn’t Solve Your Risk Analysis Problem

      OCR and ONC Just Updated the Free SRA Tool; Here’s Why That Doesn’t Solve Your Risk Analysis Problem

      Quick answer: On September 10, 2026, OCR and ONC released version 3.7 of the Security Risk Assessment (SRA) Tool, adding new content on remote access, telework, and system activity logging, as well as expanded asset examples and revised reports. The update is genuinely useful, but it doesn’t change what makes the SRA Tool a weak standalone fit for many organizations: it doesn’t stop you from leaving sections incomplete; OCR itself has never confirmed the tool meets its own “accurate and thorough” risk analysis standard; OCR has described the tool as built for smaller organizations without ever defining what that means; and a broad, general questionnaire can’t fully account for how ePHI actually moves through your specific organization. For most practices, the SRA Tool is a reasonable starting point, not a finish line.

      OCR and ONC Just Released SRA Tool Version 3.7

      On September 10, 2026, HHS’s Office for Civil Rights and the Office of the National Coordinator for Health IT announced version 3.7 of the free SRA Tool. According to the release, the update includes:

      • Revised assessment coverage and scope questions and education
      • New remote access and telework questions and education
      • Updated system activity logging language and education
      • Expanded asset examples to reflect newer technology
      • Updated software libraries for bug and vulnerability fixes
      • Report revisions to capture additional details and comments

      OCR and ONC also scheduled webinars on September 15 and 16, 2026, to walk organizations through the new features. All of this is a real improvement over the prior version; it’s also not, on its own, the same as a compliant HIPAA risk analysis, and that gap is where many organizations run into trouble.

      The Tool Lets You Stop Before You’re Finished

      During the September 2026 OCR/NIST “Safeguarding Health Information” conference, Nick Heesters, Senior Advisor for Cybersecurity in OCR’s Health Information Privacy, Data, and Cybersecurity Division, described a pattern OCR has seen play out in real investigations: organizations that used the SRA Tool but left portions of it incomplete. The software doesn’t require every section to be finished before a user can close it out or generate a report; it simply picks back up wherever the user left off, whenever that happens to be.

      That flexibility is convenient for whoever is filling it out. It’s a liability for the organization relying on it, since an incomplete assessment isn’t a defense in an investigation; it’s a finding. If your risk analysis has gaps because the tool allowed those gaps to sit unresolved, OCR treats that the same way it treats any other incomplete risk analysis.

      OCR Has Never Said the SRA Tool Meets Its Own Standard

      Here’s the detail worth sitting with. At past OCR/NIST conferences, Heesters has been asked directly whether OCR considers output from the SRA Tool to be an “accurate and thorough” risk analysis, which is OCR’s own standard under the Security Rule’s Security Management Process provision. He hasn’t given a direct yes or no. His answer has consistently been that the SRA Tool is one of the tools an organization can use as part of a broader risk analysis process, not a guarantee of adequacy on its own.

      The agency that enforces this standard has had multiple chances to say that its own free tool satisfies it, but hasn’t. That’s not a condemnation of the tool; it’s a statement about its limits, and it should shape how much weight any organization places on a completed SRA Tool questionnaire on its own.

      OCR Built This Tool With Smaller Organizations in Mind, and Never Said What “Smaller” Means

      OCR and ONC have described the SRA Tool as designed for small and medium-sized health care providers. Neither agency has defined where that scope actually ends. No stated employee count, revenue threshold, patient volume, or system complexity marks the line between an organization the tool was built for and one that has outgrown it.

      That ambiguity matters because many organizations using the tool don’t actually know which side of that undefined line they’re on. A practice with ten providers and a single EHR is a very different compliance environment than a forty-provider, multi-specialty group running telehealth, a patient portal, and three billing vendors; yet nothing in OCR’s own materials tells either one whether the tool was designed with them in mind. Absent a definition, organizations tend to assume the tool fits them because it’s free and easy to access, not because OCR ever confirmed that it does.

      A Broad Checklist Wasn’t Built Around Your Environment

      OCR’s own guidance, reinforced at the same 2026 conference, describes a risk analysis as an assessment of risk to ePHI at three distinct stages: where it’s created or enters the organization, where it flows internally between systems and departments, and where it leaves the organization entirely. A compliant risk analysis must trace all three stages for your specific systems, your specific vendors, and your specific workforce, not a generalized questionnaire built to apply to every covered entity at once.

      The SRA Tool asks the same structured questions of a practice with five providers, a hospital system, and a school district billing Medicaid. When your organization’s actual ePHI flow doesn’t map cleanly to the tool’s built-in categories, gaps appear, and the tool has no way to flag a misapplied category or a missed system entirely.

      What This Costs Small and Midsize Practices in Practice

      None of this means the SRA Tool has no value; it’s free, and it gives an organization a starting structure. But the real cost shows up when practice staff, who aren’t compliance professionals and aren’t expected to be, spend hours interpreting technical questions about encryption, access controls, and system logging, only to close out a tool that was never confirmed to fit their size or environment in the first place. That’s hours spent and a false sense of security produced, at the same time.

      Why Spend Hours on a Tool OCR Won’t Vouch For?

      A free tool that OCR itself won’t confirm meets its own standard, that was built with an undefined idea of “smaller” in mind, that lets you walk away with unfinished sections, and that treats a five-provider practice the same as a five-hundred-provider health system isn’t a shortcut. It’s a slower path to the same uncertainty you started with.

      Colington Consulting’s lead consultants have personally conducted more than 1,000 HIPAA risk assessments; we work directly with your systems, your vendors, and your staff, and build a documented, defensible risk analysis mapped to how ePHI actually moves through your organization, not a generic questionnaire built to apply to everyone at once.

      Get a free HIPAA Risk Review. We’ll show you where a generic tool would leave gaps and what a thorough, defensible risk analysis looks like for your organization.

      Schedule Your Free HIPAA Risk Review →

      Sources

      U.S. Department of Health and Human Services, Office for Civil Rights, and Office of the National Coordinator for Health IT, “HHS Releases Updated Security Risk Assessment Tool,” September 10, 2026.

      U.S. Department of Health and Human Services, Office for Civil Rights, and National Institute of Standards and Technology, “Safeguarding Health Information: Building Assurance Through HIPAA Security” Conference, September 2 to 3, 2026, NIST Gaithersburg Campus, Gaithersburg, MD.

      U.S. Department of Health and Human Services, Office for Civil Rights, and Office of the National Coordinator for Health IT, Security Risk Assessment (SRA) Tool product documentation and user guide.

      45 C.F.R. § 164.308(a)(1), Security Management Process (Risk Analysis and Risk Management).

      Frequently Asked Questions

      Does using the free HHS SRA Tool satisfy HIPAA’s risk analysis requirement?

      Not necessarily. OCR has repeatedly declined to confirm that output from the SRA Tool meets its own “accurate and thorough” risk analysis standard, describing it instead as one tool that can support a broader risk analysis process.

      Does OCR require organizations to use the SRA Tool?

      No. OCR and ONC offer the SRA Tool as a free resource to help organizations conduct a risk analysis; it isn’t a mandated format, and using it doesn’t by itself guarantee compliance with the Security Rule’s risk analysis requirement.

      Is the SRA Tool meant for organizations of any size?

      OCR and ONC have described the tool as designed for small and medium-sized health care providers, but neither agency has defined what counts as small or medium. Organizations of any size can use it, but there’s no official guidance on where it stops being an appropriate fit.

      Can I leave sections of the SRA Tool incomplete and finish later?

      Yes, and that’s part of the concern. The software allows users to save an incomplete assessment and resume it later, which means an organization may end up relying on a risk analysis that was never completed.

      What did OCR update in SRA Tool version 3.7?

      Version 3.7, released September 10, 2026, added revised assessment coverage and scope questions, new remote access and telework content, updated system activity logging language, expanded asset examples, updated software libraries, and revised reporting.

      What should a practice do instead of relying only on the SRA Tool?

      Use it as a starting point if you choose to, but pair it with, or replace it with, a risk analysis conducted by someone who can map ePHI creation, flow, and exit points specific to your organization, and who can speak to whether the result would hold up under OCR’s own standard.

    • MIPS Security Risk Analysis 2026: The New Risk Management Attestation

      MIPS Security Risk Analysis 2026: The New Risk Management Attestation

      Your 2026 MIPS Attestation Now Covers Risk Management, Not Just Risk Analysis

      Did you know CMS requires a security risk analysis for MIPS? Under the Promoting Interoperability (PI) performance category, clinicians must attest that they conducted or reviewed a security risk analysis as required by the HIPAA Security Rule at 45 CFR 164.308(a)(1). Beginning with the 2026 performance period, CMS added a second required attestation: that the clinician also conducted security risk management activities under the same Security Rule standard. Failing to complete either attestation results in no score for the entire PI category, which accounts for 25 percent of a traditional MIPS final score and directly affects a clinician’s Medicare payment adjustment.

      What CMS Requires for the 2026 Performance Period

      The requirement sits under the PI category’s Protect Patient Health Information objective as the Security Risk Analysis measure (PI_PPHI_1). For 2026, CMS split it into two separate “Yes” attestations:

      • Risk analysis: the clinician, group, or APM Entity conducted or reviewed a security risk analysis in accordance with 45 CFR 164.308(a)(1).
      • Risk management: the clinician, group, or APM Entity conducted security risk management activities as required under the HIPAA Security Rule, implementing security measures sufficient to reduce identified risks and vulnerabilities to a reasonable and appropriate level.

      A few details matter when planning the work. The analysis must be completed or reviewed annually within the calendar year of the performance period, though it need not fall within the PI reporting window. CMS expects it to cover each certified EHR technology (CEHRT) the clinician or group uses. The measure earns no points on its own; it functions as a gatekeeper, so a “No” or an unsupported “Yes” zeroes out the category regardless of how well every other PI measure performs.

      The same objective also includes a separate required attestation for an annual self-assessment using the High Priority Practices SAFER Guide. That measure addresses EHR safety practices; it is not a substitute for a HIPAA risk analysis.

      Why CMS Added Risk Management

      The HIPAA Security Rule has always required both steps. The Security Management Process standard pairs risk analysis at 45 CFR 164.308(a)(1)(ii)(A) with risk management at 164.308(a)(1)(ii)(B); the former identifies the risks, and the latter requires the organization to act on them. CMS finalized the change for clinicians in the Calendar Year 2026 Physician Fee Schedule final rule and made a parallel change for eligible hospitals and critical access hospitals in the FY 2026 IPPS final rule.

      The change also mirrors what OCR told attendees at its September 2026 conference with NIST: a risk analysis that does not feed into a documented risk management program is an incomplete compliance posture. CMS now asks clinicians to attest to both halves, meaning a risk analysis that identified problems and then sat in a folder no longer supports a clean attestation.

      The Attestation Is Only as Strong as the Analysis Behind It

      A “Yes” in the MIPS submission is a representation to CMS that affects Medicare payment, and MIPS submissions are subject to CMS data validation and audit. If a clinician cannot provide documentation supporting the attestation, the PI score and the payment adjustment tied to it can be revised.

      The exposure does not stop with CMS. The HIPAA obligation exists independently of MIPS, and OCR measures a risk analysis against its own standard: an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all electronic protected health information (ePHI) the organization holds. OCR has also been clear that a gap analysis, which compares current practices against a checklist, does not meet that standard. A thin risk analysis therefore creates risk on two fronts: payment under MIPS and enforcement under HIPAA.

      In our experience, the gaps that undermine a MIPS attestation are typically the same ones OCR cites:

      • Scope is limited to the EHR. CMS requests coverage for each CEHRT; HIPAA requires coverage of all ePHI, including email, patient portals, billing systems, remote access, backups, and vendors.
      • Last year’s analysis carried forward. A prior assessment that was never reviewed against new systems, locations, or staff does not reflect the current environment.
      • Findings without follow-through. Risks were identified, but no remediation plan, owner, or target date was ever documented; this now directly contradicts the risk management attestation.
      • Group attestations that exceed the documentation. A group or APM Entity attests for every clinician, while the underlying analysis covers only one site or one system.

      What to Do Before You Attest for 2026

      • Confirm timing and scope. Make sure your risk analysis was completed or reviewed during calendar year 2026 and covers every system, location, and vendor that creates, receives, maintains, or transmits ePHI.
      • Document risk management, not just risk. For each identified risk, record the safeguard selected, who owns it, the target date, and its current status.
      • Assemble an evidence file. Keep the dated risk analysis, the risk management plan, and records of completed remediation together so the attestation can be supported if CMS or OCR requests it.
      • Align group submissions. If you report as a group or APM Entity, confirm the analysis covers every participating clinician’s environment and CEHRT.
      • Separate MIPS status from HIPAA obligations. Some clinicians, including many small practices, may have the PI category reweighted. That changes MIPS scoring; it does not change the HIPAA Security Rule requirement to conduct and act on a risk analysis.

      Attesting “Yes” Should Mean Something; Colington Consulting Makes Sure It Does

      Your 2026 MIPS attestation now asks two questions, and both require documentation that holds up to CMS and OCR. Colington Consulting’s lead consultants have personally conducted more than 1,000 HIPAA risk assessments, and our process is designed to be extensive, accurate, and thorough. We map how ePHI is created, how it moves, and where it leaves your organization across every system, vendor, and location, not just your EHR; we assess and rate each risk specific to your environment; and we deliver a documented risk management plan that supports both your MIPS attestations and the HIPAA Security Rule standard enforced by OCR.

      Get a free HIPAA Risk Review. We will show you where your current risk analysis and risk management documentation stand, and what it will take to attest with confidence.

      Schedule Your Free HIPAA Risk Review →

      Sources

      Centers for Medicare & Medicaid Services, Quality Payment Program, 2026 MIPS Promoting Interoperability Performance Category Measure Specification: Security Risk Analysis (PI_PPHI_1).

      Centers for Medicare & Medicaid Services, Quality Payment Program, 2026 MIPS Promoting Interoperability Performance Category Measure Specification: High Priority Practices SAFER Guide (PI_PPHI_2).

      Centers for Medicare & Medicaid Services, Calendar Year 2026 Physician Fee Schedule final rule, 90 FR 49874.

      Centers for Medicare & Medicaid Services, FY 2026 Hospital Inpatient Prospective Payment System (IPPS) and Long Term Care Hospital PPS final rule, Medicare Promoting Interoperability Program.

      45 C.F.R. § 164.308(a)(1), Security Management Process (Risk Analysis and Risk Management).

      U.S. Department of Health and Human Services, Office for Civil Rights, Guidance on Risk Analysis Requirements under the HIPAA Security Rule, hhs.gov.

      U.S. Department of Health and Human Services, Office for Civil Rights, and National Institute of Standards and Technology, “Safeguarding Health Information: Building Assurance Through HIPAA Security” Conference, September 2 to 3, 2026, Gaithersburg, MD.

      Frequently Asked Questions

      Does MIPS require a security risk analysis?

      Yes. The Security Risk Analysis measure is a required attestation within the MIPS Promoting Interoperability performance category. Without it, the clinician, group, or APM Entity receives no score in the category.

      What changed for the 2026 MIPS performance period?

      CMS added a second required attestation. Clinicians must now attest “Yes” to both conducting or reviewing a security risk analysis and conducting security risk management activities under the HIPAA Security Rule.

      Does the risk analysis have to be done during the PI performance period?

      No. It may be completed or reviewed outside the PI reporting window, but it must occur within the calendar year of the performance period.

      What happens if we attest “Yes” without a supporting risk analysis?

      MIPS submissions are subject to CMS data validation and audit. If the attestation cannot be supported, the PI score and the related payment adjustment may be affected, and the missing analysis is also a HIPAA Security Rule deficiency that OCR can cite independently.

      Is a risk analysis that only covers our EHR enough?

      Not for HIPAA purposes. CMS asks that the analysis cover each CEHRT, but the HIPAA Security Rule requires an accurate and thorough assessment of risk to all ePHI the organization holds, wherever it is created, flows, or leaves.

      If our practice is reweighted out of Promoting Interoperability, do we still need to conduct a risk analysis?

      Yes. Reweighting affects how MIPS calculates your score, but it does not remove the HIPAA Security Rule requirement to conduct a risk analysis and implement risk management.

    Helping healthcare organizations navigate HIPAA requirements, reduce compliance risks, and protect sensitive health information.

    Quick Links

    Our Services

    Specialty Services

    Need Help?

    Facebook X-twitter Linkedin Youtube

    © 2026 Colington Consulting. All rights reserved.