HIPAA SECURITY RULE COMPLIANCE FOR HEALTHCARE ORGANIZATIONS

The HIPAA Security Rule establishes national standards for protecting electronic protected health information (ePHI) that a covered entity or business associate creates, receives, maintains, or transmits. Per the U.S. Department of Health and Human Services (HHS), the rule requires appropriate administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability of ePHI. The regulation text lives at 45 CFR Part 160 and Subparts A and C of 45 CFR Part 164 on eCFR.

Three groups of organizations must comply with the Security Rule:

• Covered entities - health plans, health care clearinghouses, and health care providers who transmit health information electronically in connection with covered transactions.
• Business associates - vendors and subcontractors that create, receive, maintain, or transmit ePHI on behalf of a covered entity. Since the 2013 Omnibus Final Rule implemented the HITECH Act, the Security Rule applies to business associates directly, with the same civil and criminal liability as covered entities.
• Subcontractors of business associates - any downstream partner that touches ePHI needs its own chain of written agreements.

HHS designed the Security Rule to be scalable and technology neutral: it does not dictate specific products. Instead, HHS directs regulated entities to consider their size, resources, the complexity of their environment, and the results of their risk analysis when selecting security measures. That flexibility is also the trap. "Reasonable and appropriate" is judged against a documented risk analysis, so a practice that skips the analysis has no defense for any safeguard decision it made - or failed to make.

The Security Rule is one of three rules that work together. The Privacy Rule governs who may use and disclose protected health information (PHI) and imposes the minimum necessary standard. The Breach Notification Rule governs what happens after something goes wrong. The Security Rule governs the safeguards that keep it from going wrong in the first place. Our HIPAA compliance guide covers all three rules end to end.

The risk analysis is the foundation of the entire Security Rule. Under the Security Management Process standard, 45 CFR 164.308(a)(1)(ii)(A) requires every regulated entity 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 covered entity or business associate."

OCR's Guidance on Risk Analysis states that 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 is foundational, and every other safeguard decision flows from it. The guidance, adapted from NIST publications, frames the minimum questions an analysis must answer:

• Have you identified all the ePHI within your organization, including ePHI you create, receive, maintain, or transmit?
• What are the external sources of ePHI - vendors, consultants, billing companies, cloud services?
• What are the human, natural, and environmental threats to information systems that contain ePHI?

Three companion implementation specifications sit alongside the risk analysis under the same standard, and all three are required, not addressable:

• Risk management (45 CFR 164.308(a)(1)(ii)(B)) - implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.
• Sanction policy (45 CFR 164.308(a)(1)(ii)(C)) - apply appropriate sanctions against workforce members who fail to comply with security policies.
• Information system activity review (45 CFR 164.308(a)(1)(ii)(D)) - regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.

Two practical points from the regulation and OCR guidance:

• The Security Rule does not prescribe a specific risk analysis methodology. OCR recognizes that methods vary with the size, complexity, and capabilities of the organization, but every methodology must achieve the objectives the rule states.
• The risk analysis is not a one-time event. The Evaluation standard at 45 CFR 164.308(a)(8) requires periodic technical and non-technical evaluation, and 45 CFR 164.306(e) requires re-evaluation in response to environmental or operational changes affecting ePHI security. In practice, most organizations re-run the analysis annually and after any material change - a new EHR, a merger, a new telehealth platform, a move to a new facility.

HHS and ONC publish a free HIPAA Security Risk Assessment (SRA) Tool for small and medium practices. It is a reasonable self-check. It is not a substitute for an engagement that maps your actual environment, tests your controls, and produces evidence an auditor or OCR investigator will accept. Our NIST SP 800-30 risk assessment methodology follows the same NIST guidance HHS references, and our NIST SP 800-66 guide maps each HIPAA standard to concrete controls. If you want to see how a risk analysis differs from the gap analysis you may already have had done, read risk assessment vs gap analysis explained.

HHS is explicit: "addressable" does not mean optional. Where an addressable specification is reasonable and appropriate for your organization, you must adopt it. Where it is not, the Security Rule lets you adopt an alternative measure that achieves the purpose of the standard - and you must document why the specification was not reasonable and appropriate, and why your alternative is (45 CFR 164.306(d); see also HHS's required vs addressable FAQ). That documentation requirement is where most self-managed programs fail.

Examples from the regulation text, verified against eCFR:

Read the full table in the regulation at eCFR 164.312. Note the practical consequence for encryption: encryption of ePHI at rest and in transit is technically addressable, but because encryption renders PHI "unreadable, indecipherable, and unusable" to unauthorized persons, encrypted PHI that is breached may fall outside the Breach Notification Rule's notification requirement for unsecured PHI (see HHS's breach notification guidance). Skipping encryption therefore converts every incident into a potential notifiable breach. That is why we treat encryption as effectively required for every healthcare client, and document the reasoning either way.

Before a covered entity may permit a business associate to create, receive, maintain, or transmit ePHI on its behalf, it must obtain satisfactory assurances that the business associate will appropriately safeguard the information - in writing. That written contract or other arrangement is the business associate agreement (BAA), required by 45 CFR 164.308(b) with content requirements at 45 CFR 164.314.

Per HHS, the BAA must require the business associate to:

• Implement the administrative, physical, and technical safeguards of the Security Rule with respect to ePHI.
• Report to the covered entity any security incident of which it becomes aware - and under the Breach Notification Rule at 45 CFR 164.410, notify the covered entity of a breach without unreasonable delay and no later than 60 days after discovery.
• Ensure any subcontractors that create, receive, maintain, or transmit ePHI agree to the same restrictions and conditions in writing.
• Make records available to the Secretary of HHS for compliance review.
• Return or destroy all ePHI at termination of the agreement where feasible.

Because the HITECH Act made business associates directly liable under the Security Rule, a BAA is no longer just risk transfer - your billing company, your EHR hosting vendor, your IT provider, your shredding service, and your transcription service all carry direct obligation. HHS publishes a business associates guidance page covering who qualifies. Common questions we field: does a BAA cover data stored by a cloud vendor outside the agreement's scope (no), and does an IT provider that cannot access ePHI need one (usually not - the access test controls). Our BAA services page covers agreement drafting and vendor inventory, and our contracts specification page walks the 164.308(b) text requirement by requirement. Practices that want a vendor-by-vendor review should also see our HIPAA for practices and business associates page.

The Breach Notification Rule at 45 CFR 164.402 and the subpart that follows defines a breach as, generally, an impermissible use or disclosure under the Privacy Rule that compromises the security or privacy of PHI. An impermissible use or disclosure is presumed to be a breach unless the covered entity or business associate demonstrates a low probability that the PHI has been compromised, based on a risk assessment of at least four factors HHS lists:

1. The nature and extent of the PHI involved, including types of identifiers and likelihood of re-identification;
2. The unauthorized person who used the PHI or to whom the disclosure was made;
3. Whether the PHI was actually acquired or viewed;
4. The extent to which the risk has been mitigated.

If notification is required, the clocks and audiences per HHS's Breach Notification Rule guidance:

• Individuals - notified without unreasonable delay, no later than 60 days after discovery of a breach of unsecured PHI, by first-class mail (or email if the individual agreed to electronic notice).
• The Secretary of HHS - breaches affecting 500 or more individuals are reported without unreasonable delay and no later than 60 days after discovery; breaches affecting fewer than 500 individuals may be reported annually, within 60 days after the end of the calendar year.
• Prominent media outlets - for a breach affecting more than 500 residents of a state or jurisdiction, also within 60 days.
• Covered entities, from business associates - a business associate must notify the affected covered entity without unreasonable delay and no later than 60 days from discovery (45 CFR 164.410).

Two details carry most of the weight in an investigation. First, notification is only required for unsecured PHI - PHI not rendered unusable, unreadable, or indecipherable through a technology or methodology specified by the Secretary, which is where properly implemented, validated encryption changes the outcome. Second, the burden of proof is on the regulated entity: you must be able to demonstrate that all required notifications were made, or that the incident was not a notifiable breach, and that demonstration rests on your documented four-factor risk assessment. Our breach notification and response service covers the full response playbook, and our HIPAA breach response team page describes what happens in the first 48 hours. Forensic evidence preservation matters here - our digital forensics team is led by an NC Licensed Digital Forensic Examiner.

What you receive

• A documented risk analysis that answers the questions OCR's guidance expects: where ePHI lives, who touches it, what threatens it, and what safeguards were chosen in response.
• A written remediation plan ranked by risk level, with each addressable implementation specification decision (adopt or alternative) documented as 45 CFR 164.306(d) requires.
• Evidence packages an auditor can follow: control mapping to NIST SP 800-66 and cross-references to NIST SP 800-53 control families.
• A reassessment cadence aligned to the Evaluation standard, so the analysis stays current when your environment changes.

Practices that need an executive-level security function without a full-time hire can attach the assessment to an ongoing vCISO engagement - the named vCISO can serve as security officer of record for HIPAA under 45 CFR 164.308(a)(2), with formal designation documentation. Organizations in the Research Triangle can work with us locally through our HIPAA consulting in Morrisville, Wilmington, or Charlotte pages; the engagement model is the same everywhere. If you want to test your exposure before you call, start with our free security risk self-assessment or the cybersecurity audit overview.