Understanding the HIPAA Security Rule: Complete Guide

For hospitals, health systems, research institutions, and other organizations operating in the healthcare sector, the HIPAA Security Rule is a requirement. It is the foundation for protecting patient health information (PHI) at scale. Mature healthcare entities must not only understand the rule’s requirements but also operationalize them across complex infrastructures, distributed teams, and evolving threat landscapes.

The HIPAA Security Rule is the cornerstone of patient information security for organizations operating in the healthcare industry.

This guide unpacks its complexities, clarifies its role in maintaining regulatory compliance and patient trust, and explores how modern organizations can meet its demands. We cover its origins, structure, the three categories of safeguards, and provide practical guidance on risk assessments, automation, and aligning operations with HIPAA standards.

Let’s get started.

What is the HIPAA Security Rule?

The HIPAA Security Rule is a federal regulation that sets national standards for protecting electronic protected health information (ePHI). It requires healthcare providers (e.g., hospitals, hospital systems), health plans, and their business associates to implement administrative, physical, and technical safeguards to ensure the confidentiality, integrity, and availability of patient data.

Who regulates the HIPAA Security Rule?

The HIPAA Security Rule is regulated and enforced by the U.S. Department of Health and Human Services (HHS), specifically through its Office for Civil Rights (OCR). The OCR is responsible for investigating complaints, conducting audits, and issuing penalties for noncompliance.

Organizations found in violation of the Security Rule may face civil monetary penalties, required corrective action plans, and in severe cases, criminal charges. The OCR also provides guidance and resources to help covered entities and business associates meet their compliance obligations.

What is the history of the HIPAA Security Rule?

The HIPAA Security Rule is part of the broader Health Insurance Portability and Accountability Act (HIPAA), which was signed into law in 1996. The Security Rule was formally published in 2003 and became enforceable in 2005. Its primary focus is the protection of electronic protected health information (ePHI) by establishing national standards for administrative, physical, and technical safeguards.

Since its implementation, the Security Rule has been shaped by ongoing changes in technology and the threat landscape.

Major HIPAA Security Rule updates over the years

What are the 2025 updates to the HIPAA Security Rule?

The most significant overhaul of the HIPAA Security Rule in over a decade was proposed in 2025 through the “HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information“. This landmark update shifts the regulatory paradigm from flexible, “addressable” safeguards to mandatory, standardized protections designed to counter modern cyber threats. Key changes include:

• Elimination of “addressable” implementation specifications, making all safeguards mandatory
• Explicit requirements for multi-factor authentication and encryption
• Mandatory annual inventories and security testing
• Enhanced third-party oversight through annual business associate verifications
• Alignment with NIST SP 800-53 and CISA Cybersecurity Performance Goals

These updates reflect regulators’ response to escalating healthcare cyberattacks and aim to create a consistent, evidence-based security baseline across the industry. Below is a detailed summary of the key changes:

What are the 3 HIPAA Security Rule safeguards?

The Security Rule outlines three categories of safeguards: administrative, physical, and technical.

• Administrative safeguards: focus on risk analysis, security management, workforce training, and establishing policies and procedures.
• Physical safeguards: include facility access controls, workstation security measures, and the proper handling of electronic media containing ePHI.
• Technical safeguards: encompass access controls, audit controls, data integrity measures, authentication, and transmission security.

Administrative Safeguards

Administrative safeguards are a set of policies, procedures, and guidelines that a covered entity and its business associates must implement to manage the protection of ePHI. They account for over half of the Rule’s requirements and include the following:

• Security Management Process: Develop, implement, and maintain a process to identify and reduce potential risks to ePHI by conducting regular risk assessments, creating a risk management plan, and applying appropriate security measures to address identified vulnerabilities.
• Assigned Security Responsibility: Designate a security official responsible for developing, implementing, and maintaining security policies and procedures to ensure compliance.
• Workforce Security: Ensure only authorized members of a covered entity’s workforce can access ePHI by determining appropriate access levels, implementing authorization and supervision protocols, and maintaining workforce clearance procedures.
• Information Access Management: Prevent unauthorized access to ePHI by implementing role-based access controls (RBAC), restricting access to the minimum necessary information, and managing access.
• Security Awareness Training: Provide regular training for all workforce members that covers password management, malware protection, and reporting security incidents.
• Security Incident Procedures: Implement policies and procedures that outline a process for identifying, responding to, and reporting security incidents, including developing an incident response plan, analyzing incidents, and documenting the organization’s response to mitigate risks and prevent future occurrences.
• Contingency Plan: Establish a contingency plan to ensure the availability of ePHI during emergencies (including natural and environmental hazards) or system failures by developing data backup, disaster recovery, and emergency mode operation plans and periodically testing and revising these plans as needed.
• Evaluation: Regularly evaluate security policies and procedures to ensure ongoing effectiveness and compliance, including monitoring changes in the organization’s environment, performing audits, and making necessary adjustments.

Physical Safeguards

Physical safeguards are security measures designed to protect ePHI from unauthorized access, theft, and damage in physical environments and include the following requirements:

• Facility Access Controls: Limit physical access to facilities while providing authorized access to workforce members by creating access control and validation procedures, implementing a visitor management system, and maintaining appropriate security measures such as cards, locks, and alarms.
• Workstation Use: Establish appropriate use and functions of workstations that access ePHI by defining the physical attributes of workstations, setting access restrictions, and ensuring that workstations are used only for authorized purposes.
• Workstation Security: Implement physical measures to prevent unauthorized access to workstations containing ePHI by positioning workstations away from public view, using privacy screens, and employing additional security measures such as cable locks and secure enclosures.
• Device and Media Controls: Properly handle electronic media containing ePHI by creating guidelines for the disposal and reuse of media, maintaining an inventory of media devices, implementing data backup and storage procedures, and ensuring secure transport of ePHI when moving it between locations.

Technical Safeguards

Technical safeguards are technology-based measures designed to protect ePHI from unauthorized access, alteration, or destruction and include the following requirements:

• Access Control: Control access to ePHI on electronic systems by using unique user identification, implementing RBACs, establishing emergency access procedures, and utilizing automatic logoff features to prevent unauthorized intrusion.
• Audit Controls: Deploy hardware, software, or procedural mechanisms that record and examine activity in electronic systems containing ePHI to help monitor access, detect potential security incidents, and maintain accountability.
• Integrity: Protect ePHI from improper alteration or destruction by using mechanisms to authenticate ePHI, ensuring it has not been tampered with or altered, and employing data validation techniques such as checksums or digital signatures to maintain data integrity.
• Authentication: Verify that a person or entity seeking access to ePHI is who they claim to be by using various authentication methods, such as passwords, biometrics, or multi-factor authentication (MFA) systems.
• Transmission Security: Implement technical security measures to protect ePHI during transmission over electronic networks by using encryption technologies to safeguard data in transit, employing secure communication protocols such as SSL/TLS, and implementing integrity controls to detect unauthorized changes during transmission.

What Control Framework Should I Use for HIPAA Security Rule Compliance?

The HIPAA Security Rule requires covered entities and business associates to implement “reasonable and appropriate” safeguards for protecting electronic protected health information (ePHI). However, the regulation does not specify which security control framework to use. To build a defensible, audit-ready compliance program, organizations should rely on well-established frameworks and guidance documents that map HIPAA’s requirements to specific technical and administrative controls.

NIST SP 800-66r2: A Guide, Not a Control Framework

NIST SP 800-66 Revision 2 is the official implementation guidance from the National Institute of Standards and Technology (NIST) for the HIPAA Security Rule. It helps organizations interpret regulatory standards from § 164.308 to § 164.312 and provides practical direction on how to implement them. While it includes references to security controls and assessment tips, it is not a control framework itself. Instead, it points to frameworks like NIST SP 800-53 and the NIST Cybersecurity Framework (CSF) as sources for the actual security controls required to meet HIPAA’s expectations.

Commonly Used Security Control Frameworks

HITRUST CSF

HITRUST CSF is a certifiable, healthcare-specific control framework that integrates HIPAA, NIST, ISO, and other standards into a single set of controls. It offers multiple assessment levels (e1, i1, r2) to support organizations of different sizes and maturity. HITRUST directly maps to HIPAA Security Rule requirements and includes reporting features for regulators and business partners. It is especially useful for business associates or large provider networks seeking third-party certification.

NIST SP 800-53

NIST SP 800-53 is a comprehensive catalog of security and privacy controls used by federal agencies and contractors. It is referenced in NIST SP 800-66r2 as a source for detailed control implementation. It is ideal for organizations requiring high technical rigor or aligning with other federal compliance obligations.

NIST Cybersecurity Framework (CSF)

The NIST CSF is an outcome-based, risk-oriented framework organized around five functions: Identify, Protect, Detect, Respond, and Recover. It is scalable for organizations of all sizes and is increasingly recognized in healthcare cybersecurity guidance. The CSF maps naturally to HIPAA’s administrative, physical, and technical safeguards.

ISO/IEC 27001

ISO 27001 is a globally recognized standard for information security management systems (ISMS). It takes a structured, risk-based approach and can be mapped to HIPAA, though U.S.-based organizations may need to supplement it with HIPAA-specific controls. It is most useful for international health organizations or those already aligned with ISO standards.

HIPAA Security Risk Assessment (SRA) Tool

The HIPAA Security Risk Assessment (SRA) Tool is a free application from HHS OCR and the Office of the National Coordinator for Health IT (ONC). It is designed to help small and mid-sized organizations conduct a basic HIPAA risk analysis under § 164.308(a)(1). The tool walks users through key questions to identify risks and vulnerabilities to ePHI and includes references to the NIST Cybersecurity Framework (CSF) 2.0 and supply chain risk considerations.

While helpful for organizations with limited compliance resources, the SRA Tool does not replace a full control framework or risk management program. Larger organizations and business associates should use it only as a starting point.

HIPAA Security Rule Checklist

To meet the HIPAA Security Rule with confidence, organizations must implement operational programs that go beyond policy statements. Compliance hinges on how well entities manage real-world risks to electronic protected health information (ePHI) across internal systems and third-party relationships. The table below outlines four foundational programs every covered entity and business associate should establish. Each is mapped directly to regulatory requirements under § 164.308 and § 164.314, and reflects current enforcement priorities from the Office for Civil Rights (OCR).

What happens if there is non-compliance with the HIPAA Security Rule?

Non-compliance can seriously affect covered entities. HIPAA violations may result in the following:

• Investigations: The Department of Health and Human Services Office for Civil Rights (OCR) enforces the Security Rule. They may initiate investigations in response to complaints, reported breaches, or through random compliance audits. A covered entity found non-compliant may be required to take corrective actions.
• Corrective Action Plans (CAPs): Sometimes, the OCR may require non-compliant organizations to implement a corrective action plan (CAP). CAPs outline specific actions organizations must take to address identified deficiencies, improve security posture, and ensure future compliance. The OCR will closely monitor organizations during the CAP implementation period.
• Fines and penalties: Non-compliant organizations can face significant financial penalties and sanctions, depending on the nature and extent of the violation. Fines range from $100 to $50,000 (or per record), with an annual maximum of $1.5 million for identical violations. Penalties may be higher if the violation is due to willful neglect and not corrected within the required timeframe.
• Legal action: In extreme cases, non-compliant covered entities may face criminal charges, resulting in imprisonment for individuals responsible for the violations. Criminal penalties typically apply in deliberate, fraudulent, or malicious actions involving unauthorized access or disclosure of ePHI.

• Reputational damages: Non-compliance can seriously harm the reputation of a covered entity. News of security breaches or violations can undermine patient trust, damage relationships with business partners, and potentially result in lost business.

Recent Examples of HIPAA Violations

Here are some recent examples of HIPAA Security Rule violations to further underscore the risks associated with non-compliance:

Comstar, LLC (May 2025)

• Violation: Ransomware breach and failure to conduct a thorough risk analysis.
• Scope: 585,621 individuals affected.
• Penalty: $75,000 settlement and a two-year corrective action plan.
• Root Cause: Inadequate risk analysis, insufficient technical safeguards, and delayed breach detection.

Comprehensive Neurology, PC (May 2025)

• Violation: Ransomware attack and failure to conduct an accurate and thorough risk analysis.
• Scope: 6,800 individuals affected.
• Penalty: $25,000 settlement and a corrective action plan monitored by OCR for two years.
• Root Cause: Lack of risk analysis and insufficient policies and procedures to address ePHI security.

Northeast Radiology, P.C. (April 2025)

• Violation: Failure to conduct an accurate and thorough risk analysis, leading to unauthorized access to ePHI.
• Scope: 298,532 individuals affected.
• Penalty: $350,000 settlement and a corrective action plan.
• Root Cause: Inadequate risk analysis and failure to implement sufficient security measures for PACS servers.

Oregon Health & Science University (March 2025)

• Violation: Failure to provide timely access to a patient’s medical records (Right of Access).
• Scope: At least one individual directly impacted.
• Penalty: $200,000 civil monetary penalty.
• Root Cause: Delayed response to patient record requests, violating the HIPAA Right of Access Initiative.

BayCare Health System (2025)

• Violation: Information access management failures, risk management deficiencies, and failure to review system activity.
• Scope: At least one individual directly impacted.
• Penalty: $800,000 settlement.
• Root Cause: Failure to restrict access to ePHI, insufficient risk management, and lack of regular information system activity review.

For a full and current list of settlements and corrective action plans, visit the HHS OCR Resolution Agreements page.

Why use HIPAA Security Rule Compliance Software?

HIPAA compliance often breaks down in two ways. Teams rely on spreadsheets and email to track assessments, vendors, and risks—or they’re stuck inside bloated GRC platforms that are too complex to use. Either way, key safeguards under 45 CFR Part 164 Subpart C go unmanaged, and compliance becomes reactive.

There are a select amount of GRC platforms available to hospitals and health systems, but a platform designed for security teams changes this. It replaces static tools with structured workflows for risk analysis, vendor oversight, and documentation. This helps security teams maintain visibility, meet regulatory expectations, and respond confidently to audits.

HIPAA Security Rule Compliance with Isora GRC

Isora GRC helps healthcare organizations translate HIPAA Security Rule requirements into structured, repeatable workflows.

Instead of relying on static spreadsheets or complex legacy tools, security teams use Isora to meaningfully engage their organization with risk assessments, inventory management, third-party reviews, and compliance documentation in one centralized system.

Here’s how Isora supports the four core programs needed for HIPAA Security Rule compliance:

Information Security Risk Management Program

• 164.308(a)(1)(ii)(A), § 164.308(a)(1)(ii)(B), § 164.316(b)(1)

Isora enables teams to conduct structured security risk assessments using built-in questionnaires. Assessments can be tailored to HITRUST CSF, NIST CSF, CIS Controls, or used to complete a HIPAA Security Risk Assessment (HIPAA SRA). Findings are scored and published to a collaborative risk register where they can be managed.

Third-Party Security Risk Management

• 164.308(b)(1), § 164.314(a)(1), § 164.308(a)(8)

Isora provides a centralized program for vendor risk, including business associate inventory, and evidence collection. Teams can send BAAs, deploy frameworks like HECVAT, CAIQ, or SIG, collect responses, and assign risk levels. Results are tied to vendors and retained for annual reviews and audits.

Risk Register

• 164.308(a)(1)(ii)(A), § 164.316(b)(1), § 164.308(a)(8)

Isora automatically publishes risks identified during assessments to a collaborative risk register. Each risk includes scoring, ownership, status, and remediation plans. The platform supports periodic reevaluation and system change tracking to ensure ongoing compliance and internal accountability.

Asset and Vendor Inventory

• 164.308(a)(1)(ii)(A), § 164.308(a)(7)(ii)(D), § 164.308(b)(1)

Isora consolidates all systems, applications, and vendors interacting with ePHI into one searchable inventory. Metadata fields such as ownership, data classification, and deployment location make it easy to scope HIPAA compliance assessments accurately and maintain readiness for audits and breach investigations.

GRC Assessment Platform for HIPAA Security Rule

Keep private health data private

Work together across your organization to comply with the HIPAA Security Rule. Assess and manage information security risk in Isora.

Learn More

HIPAA Security Rule FAQs

How do the HIPAA Privacy and Security Rules differ?

The Privacy Rule governs all forms of PHI, focusing on use and disclosure rules. The Security Rule specifically protects electronic PHI (ePHI), requiring technical, physical, and administrative safeguards to ensure confidentiality, integrity, and availability.

What types of information are protected under the HIPAA Security Rule?

The HIPAA Security Rule protects electronic protected health information (ePHI). This includes any individually identifiable health information that is created, received, maintained, or transmitted electronically by a covered entity or business associate. Examples include medical records, insurance data, lab results, and billing information stored or transmitted via electronic systems.

Who qualifies as a business associate under HIPAA?

A business associate is any person or organization that performs services involving the use or disclosure of PHI on behalf of a covered entity. This includes cloud service providers, billing firms, EHR vendors, legal consultants, and other contractors who handle ePHI. Under HIPAA, business associates must sign a Business Associate Agreement (BAA) and implement safeguards to comply with the Security Rule.

How does the HIPAA Security Rule apply to cloud service providers?

Cloud service providers (CSPs) that store, process, or transmit ePHI on behalf of a covered entity or business associate are themselves considered business associates. This means they are subject to all HIPAA Security Rule requirements, including having a signed BAA, maintaining access controls, encrypting data, and conducting regular risk assessments.

What is the role of a Security Official under the HIPAA Security Rule?

Under § 164.308(a)(2), covered entities and business associates must designate a Security Official responsible for developing and implementing security policies and procedures. This person ensures that the organization complies with the Security Rule, manages the risk analysis process, coordinates security training, and oversees incident response efforts.

How often should a HIPAA security risk assessment be conducted?

HIPAA does not mandate a specific frequency, but risk assessments should be conducted regularly and updated whenever there are significant changes to systems, threats, or operations. Best practice is to review risk assessments annually, or more often if there are new technologies, vendor changes, or security incidents.

What documentation is required to demonstrate HIPAA Security Rule compliance?

Organizations must maintain written documentation of all policies, procedures, and risk analysis activities under § 164.316. Required documents include security risk assessments, mitigation plans, incident response procedures, vendor due diligence records, and evidence of workforce training. Documentation must be retained for at least six years from the date of creation or last effective date.

How does HIPAA interact with NIST SP 800-53 or other federal frameworks?

HIPAA does not require use of a specific framework, but NIST SP 800-53 is referenced in official guidance (NIST SP 800-66r2) as a source of administrative and technical controls. Organizations can use NIST SP 800-53, NIST CSF, or HITRUST CSF to implement safeguards that meet HIPAA standards. These frameworks help structure risk-based programs that map to HIPAA’s flexible, scalable requirements.

How can healthcare organizations prepare for an OCR HIPAA audit?

To prepare for an OCR audit, organizations should maintain complete, current documentation of HIPAA compliance activities. This includes recent risk assessments, policies and procedures, evidence of mitigation efforts, training records, and vendor management logs. Audit readiness also means being able to demonstrate how safeguards are operationalized—not just documented.