The HIPAA Security Rule is a set of federal standards that establish minimum requirements for how covered entities and their business associates must protect electronic protected health information (ePHI). Established under the Health Insurance Portability and Accountability Act of 1996 and finalised in the Security Standards for the Protection of Electronic Protected Health Information rule published in 2003, the Security Rule applies specifically to health information in electronic form — stored in computer systems, transmitted across networks, or processed by electronic devices of any kind.
The Security Rule's purpose is to ensure the confidentiality, integrity, and availability of all ePHI that a covered entity creates, receives, maintains, or transmits. Confidentiality means ePHI is not disclosed to unauthorised individuals. Integrity means ePHI has not been altered or destroyed in an unauthorised manner. Availability means ePHI is accessible and usable on demand by authorised users. These three goals — often referred to as the CIA triad in information security — are the foundation around which the Security Rule's specific requirements are organised.
The rule is organised around three categories of safeguards: administrative, physical, and technical. Each category contains both required specifications — things an organisation must do — and addressable specifications, which the organisation must either implement as described or document an equivalent alternative measure that achieves the same security objective. This flexibility allows organisations of vastly different sizes and technical capabilities — from small physician practices to large hospital systems — to comply in ways proportionate to their specific risk environment and resources.
Understanding the HIPAA Security Rule is genuinely essential for anyone working in healthcare administration, health information management, healthcare IT, compliance, or any business that handles sensitive electronic health data on behalf of covered entities. The Security Rule is enforced by the U.S. Department of Health and Human Services Office for Civil Rights (OCR), which investigates complaints, conducts audits, and can impose significant financial penalties for non-compliance. A solid grounding in HIPAA Privacy Rule fundamentals, covered in detail in the HIPAA Privacy Rule overview, complements the more technical focus of the Security Rule.
The Health Insurance Portability and Accountability Act became law, including a mandate for the Department of Health and Human Services to establish security standards for health information. At the time, electronic health records were less common, but Congress anticipated the growing digitisation of healthcare and included security requirements in the law's framework.
HHS published the final Security Rule in the Federal Register on February 20, 2003. The rule established the specific administrative, physical, and technical safeguard requirements that covered entities must meet. The two-year implementation period before the 2005 compliance deadline gave organisations time to assess their ePHI environments and implement required protections.
The Health Information Technology for Economic and Clinical Health (HITECH) Act significantly strengthened HIPAA enforcement by increasing penalty amounts, extending Security Rule obligations directly to business associates (previously covered only through contracts), and mandating breach notification requirements for unsecured ePHI. HITECH made business associates directly liable for Security Rule compliance for the first time.
The HIPAA Omnibus Rule implemented HITECH's business associate provisions and clarified many Security Rule requirements. It formally extended covered entity Security Rule obligations to business associates and their subcontractors, requiring business associate agreements (BAAs) at every level of the ePHI handling chain. The Omnibus Rule also modified breach notification standards and updated enforcement provisions.
The HIPAA Security Rule organises its requirements into three safeguard categories. Understanding the scope and intent of each category is essential for compliance planning and risk assessment. Each category contains both required and addressable implementation specifications — required specs must be implemented exactly as described, while addressable specs must either be implemented as described or replaced with a documented equivalent that achieves the same security objective for the organisation's specific risk environment.
Administrative safeguards are the policies, procedures, and processes that govern how an organisation manages the selection, development, implementation, and maintenance of security measures — and how the workforce that handles ePHI behaves. Administrative safeguards include designating a Security Officer responsible for the organisation's HIPAA compliance, conducting a Security Risk Analysis to identify vulnerabilities and risks to ePHI, implementing a Security Risk Management program to address identified risks, establishing sanction policies for workforce members who violate security policies, maintaining information access management controls, and providing regular security awareness training to all workforce members who handle ePHI.
Administrative safeguards are often underestimated by organisations that focus primarily on the technical side of HIPAA — but OCR investigations consistently show that failures in administrative safeguard implementation are among the most common sources of HIPAA Security Rule violations.
Physical safeguards govern the physical access to facilities and equipment where ePHI is stored, processed, or transmitted. Physical safeguard requirements include facility access controls limiting physical access to electronic information systems to authorised users, workstation security policies specifying how workstations displaying or processing ePHI must be positioned and protected, workstation use policies restricting what activities can occur on systems handling ePHI, and device and media controls governing how hardware and electronic media containing ePHI are disposed of, moved, or reused.
For organisations with cloud-based or hosted systems where the physical infrastructure is managed by a vendor, the physical safeguard obligations for data centre security transfer to the business associate that manages the infrastructure — but the covered entity remains responsible for ensuring the business associate agreement appropriately covers these requirements.
Technical safeguards are the technology-based controls that protect ePHI and control access to it.
Technical safeguards include access control mechanisms that allow only authorised users to access ePHI (including unique user identification, emergency access procedures, and automatic logoff), audit controls to record and examine activity in information systems containing ePHI, integrity controls to ensure ePHI is not improperly altered or destroyed, and transmission security controls that guard against unauthorised access to ePHI transmitted over networks.
Encryption is an addressable specification — meaning organisations can choose not to implement it if they document a reasonable alternative — but OCR strongly recommends encryption for all ePHI both at rest and in transit, and its absence is consistently identified as a major risk factor in HIPAA breach investigations and settlement agreements.
When breached ePHI was encrypted, the data is typically considered unusable to unauthorised parties and the breach may not trigger mandatory breach notification obligations under HIPAA's Breach Notification Rule.
The Security Risk Analysis (SRA) is the foundational administrative safeguard requirement — organisations must conduct an accurate and thorough assessment of the potential risks and vulnerabilities to ePHI confidentiality, integrity, and availability. The SRA must be documented, updated when significant changes occur (new technology, new workflows, facility changes), and used as the basis for implementing appropriate risk management measures. OCR's most common finding in investigation settlements is a failure to conduct or adequately document the SRA.
Every covered entity must designate a Security Officer responsible for developing and implementing the organisation's security policies and procedures. In large organisations, the Security Officer may be a dedicated CISO or compliance director. In small practices, it may be the physician owner or office manager who holds the role in addition to other duties. The designation must be documented and the Security Officer given appropriate authority and resources to carry out the role effectively.
All workforce members who work with or around ePHI must receive security awareness and training. The Security Rule requires organisations to implement procedures for guarding against, detecting, and reporting malicious software; procedures for monitoring log-in attempts; and procedures for creating, changing, and safeguarding passwords. Training must be documented and updated as threats and systems evolve. Workforce training failures are consistently cited in OCR settlements involving phishing attacks and ransomware incidents.
Covered entities must establish policies and procedures for responding to emergencies or system failures that affect ePHI availability. Contingency planning requirements include a data backup plan (creating retrievable copies of ePHI), a disaster recovery plan for restoring lost data, an emergency mode operation plan for maintaining access to ePHI during emergencies, testing and revision procedures, and an applications and data criticality analysis. Ransomware incidents have made contingency planning one of the most operationally critical Security Rule requirements for healthcare organisations.
Required implementation specifications must be implemented exactly as described in the Security Rule — organisations cannot substitute alternatives or claim they are not reasonable and appropriate based on their risk environment.
Addressable specifications must either be implemented as described OR the organisation must document why the specification is not reasonable and appropriate for their environment AND implement an equivalent alternative measure.
"Addressable" does NOT mean optional. Organisations that fail to implement an addressable specification without documented justification are non-compliant.
The Security Risk Analysis (SRA) is the most important — and most frequently cited as deficient — component of HIPAA Security Rule compliance. It is the required starting point for all other security decisions: you cannot appropriately protect ePHI without first understanding where it lives, how it flows, and what threatens it.
OCR guidance specifies that the SRA must include: identifying the scope of ePHI (where it is stored, received, maintained, and transmitted), identifying and documenting potential threats and vulnerabilities to ePHI, assessing the probability and impact of each identified threat or vulnerability, implementing security measures to reduce risks to a reasonable and appropriate level, documenting the chosen security measures and rationale, and maintaining continuous, reasonable, and appropriate security protections over time.
The SRA is not a one-time exercise. The Security Rule requires covered entities to review and update their SRA when operations, facilities, technology, or the threat environment changes significantly. In practice, most compliance experts recommend reviewing and updating the SRA annually and following any significant operational change — acquisition of new technology, a change in EHR systems, a move to cloud storage, addition of a new facility, or a significant change in how ePHI is shared with business associates.
OCR has published a free Security Risk Assessment Tool (SRA Tool) for small and medium-sized providers — a software application that guides organisations through the risk analysis process and generates documentation that can be used as evidence of compliance. While the SRA Tool is not mandatory (organisations can use other approaches), it represents HHS's guidance on what a thorough risk analysis should contain and is a reasonable starting point for practices that lack in-house compliance expertise.
The tool is available at the HealthIT.gov website and has been updated to reflect current cybersecurity threats and HIPAA guidance. For practices new to HIPAA compliance, starting with the SRA Tool provides structure and produces the documentation that OCR looks for when investigating complaints or conducting audits. This practical compliance foundation is also at the core of the knowledge tested in HIPAA training and certification programmes for healthcare professionals.
One of the most significant expansions of the HIPAA Security Rule's scope was the formal extension of direct compliance obligations to business associates under the HITECH Act and the 2013 Omnibus Rule. A business associate is any individual or organisation that performs functions or activities involving the use or disclosure of ePHI on behalf of a covered entity.
This includes cloud storage providers, EHR hosting companies, medical billing services, IT support vendors, transcription services, legal counsel who reviews ePHI, accounting firms that access ePHI, and any other party that creates, receives, maintains, or transmits ePHI in the course of providing services to a covered entity.
Business associates are now directly subject to HIPAA Security Rule requirements — they must implement the same administrative, physical, and technical safeguards as covered entities for the ePHI they handle. They are directly liable to OCR for violations and can face the same civil monetary penalties as covered entities. The obligation to protect ePHI doesn't stop at the first-tier business associate — it flows through to subcontractors, meaning a business associate's cloud storage provider that handles ePHI is also a business associate with direct compliance obligations.
Business Associate Agreements (BAAs) are the contractual mechanism that documents the ePHI handling arrangement and each party's compliance obligations. Every covered entity must have a signed BAA in place before allowing any business associate to access ePHI. BAAs must specify the permitted uses and disclosures of ePHI, require the business associate to implement appropriate safeguards, require the business associate to report breaches and security incidents, and ensure the business associate will return or destroy ePHI when the contract ends.
Reviewing and updating BAAs regularly — particularly when renewing vendor contracts or adopting new services — is a fundamental covered entity compliance responsibility. Understanding how these relationships work is central to HIPAA compliance management across healthcare organisations of all sizes.
OCR's publicly available settlements and civil monetary penalty records provide a detailed picture of where covered entities most commonly fall short. The Security Risk Analysis is far and away the most frequently cited deficiency — organisations that have never conducted one, that have an outdated one that no longer reflects their current ePHI environment, or that conducted one but failed to use it to drive actual risk management decisions are all non-compliant. The SRA must be a living document tied to real security decision-making, not a checkbox exercise performed and then filed away.
Insufficient access controls are another recurring theme in OCR settlements. Organisations that allow shared user accounts (violating the unique user ID requirement), that don't implement automatic logoff on workstations displaying ePHI in shared spaces, or that fail to promptly terminate access for departed employees expose ePHI to unnecessary insider threat risk. The 2023 and 2024 OCR enforcement actions show particular attention to access control failures that enabled insider breaches — situations where former employees, disgruntled workers, or curious staff accessed ePHI they had no authorisation to view.
Ransomware and phishing-related breaches have driven a large share of recent HIPAA enforcement activity. When ransomware encrypts an organisation's ePHI, OCR treats it as a presumed breach unless the organisation can demonstrate that the attack did not result in ePHI disclosure.
Organisations that fell victim to ransomware and were found non-compliant with Security Rule requirements — particularly in the areas of workforce training, malware protection, risk management, and contingency planning — have faced significant penalties. The clear lesson from these settlements is that cybersecurity preparedness is not optional under the Security Rule; it is directly required by multiple safeguard provisions.
For organisations beginning their HIPAA Security Rule compliance journey — or re-evaluating existing programmes after a gap or audit finding — the most effective approach starts with a thorough, documented Security Risk Analysis rather than jumping directly to technology purchases or policy writing. The SRA tells you what you actually need to protect, what the realistic threats are, and what gaps exist between your current state and a reasonable security posture. Without this foundation, security investments are often misdirected, and the documentation that OCR requires in any investigation will be missing.
Once the SRA is complete, risk management priorities follow naturally from it. Organisations should address the highest-probability, highest-impact risks first — typically those involving ePHI accessible to the largest number of users, transmitted over external networks, or held by workforce members with inadequate training. Encryption of ePHI in transit (email, data transfers, remote access) is almost universally cost-effective and should be implemented unless there's a documented specific reason it's not feasible. Multi-factor authentication for access to systems containing ePHI has become a near-universal recommendation from OCR guidance and settlement resolution agreements.
Ongoing compliance requires treating HIPAA security as a continuous programme rather than a periodic project. Security awareness training must be updated as threats evolve — the phishing attacks that compromise most healthcare systems today are different from those of five years ago. Business associate relationships must be reviewed when vendors are changed or contracts renewed. The SRA must be updated when operations change. Audit logs must actually be reviewed, not just collected. Incident response procedures must be tested before they're needed in a real breach scenario.
For small and rural healthcare providers who lack dedicated IT and compliance resources, HHS's Security Risk Assessment Tool and the free resources available through the HHS Office of the National Coordinator for Health Information Technology (ONC) provide practical starting points. Regional Extension Centers and Health Information Exchanges often offer HIPAA compliance assistance as part of their mission to support underserved providers.
The cost of establishing a functional, documented HIPAA Security Rule compliance programme is almost always far less than the cost of a breach investigation, settlement, or civil monetary penalty — making proactive investment in compliance a sound financial decision as well as a clear regulatory obligation for any organisation handling ePHI.