1. Introduction to the HIPAA Security Rule

1.1 Legislative Background and History

The Health Insurance Portability and Accountability Act (HIPAA) was enacted on August 21, 1996 (Public Law 104-191). While the Act originally addressed health insurance portability and administrative simplification, its Title II Administrative Simplification provisions established the framework that gave rise to both the Privacy Rule and the Security Rule—the two foundational pillars of health information protection under United States federal law.

The HIPAA Security Rule was published in the Federal Register on February 20, 2003 (68 Fed. Reg. 8334) and became effective for most covered entities on April 21, 2005. The Security Rule operationalizes the Privacy Rule’s protections specifically for electronic protected health information (ePHI), establishing a national minimum standard for the administrative, physical, and technical safeguards that covered entities and their business associates must implement to protect ePHI.

Two subsequent legislative and regulatory actions materially expanded and strengthened HIPAA’s security obligations for IT and security professionals:

• HITECH Act (2009):The Health Information Technology for Economic and Clinical Health Act, enacted as part of the American Recovery and Reinvestment Act of February 17, 2009, significantly enhanced HIPAA enforcement by introducing tiered civil monetary penalties, creating the Breach Notification Rule, extending direct liability to Business Associates, and mandating periodic HHS audits of covered entities and business associates.
• HIPAA Omnibus Final Rule (2013):Effective March 26, 2013, the Omnibus Rule made Business Associates directly and independently liable for HIPAA Security Rule compliance—not merely through contractual obligation—and extended those obligations to Business Associate subcontractors. The Rule also revised Breach Notification Rule standards, shifting from a subjective harm-based threshold to an objective four-factor risk assessment.

1.2 Purpose and Objectives of the Security Rule

The HIPAA Security Rule requires covered entities and business associates to protect the confidentiality, integrity, and availability of all ePHI they create, receive, maintain, or transmit. These three objectives correspond directly to the CIA triad of information security:

• Confidentiality:ePHI is not made available or disclosed to unauthorized persons or processes. Technical controls such as access control, authentication, and encryption serve this objective.
• Integrity:ePHI has not been altered or destroyed in an unauthorized manner. Hash verification, digital signatures, and file integrity monitoring serve this objective.
• Availability:ePHI is accessible and usable on demand by an authorized person. Contingency planning, disaster recovery, and system redundancy serve this objective.

The Security Rule is intentionally technology-neutral and scalable. It prescribes no specific technologies, products, or algorithms. Instead, it establishes a risk-management framework within which each entity determines the specific safeguards that are reasonable and appropriate for its operational environment, based on a thorough and documented risk analysis.

1.3 Enforcement Authority and Civil Monetary Penalties

Enforcement authority rests with the HHS Office for Civil Rights (OCR). OCR investigates complaints, conducts compliance reviews, and performs random and targeted audits. Since the HITECH Act, penalties are structured into four tiers based on culpability:

Criminal penalties under 42 U.S.C. §1320d-6 apply to individuals who knowingly obtain or disclose PHI, with fines up to $250,000 and imprisonment up to 10 years for offenses committed under false pretenses or for commercial advantage or personal gain.

2. Scope and Applicability

2.1 Covered Entities

The HIPAA Security Rule applies to three categories of covered entities:

• Health Plans:Individual and group plans that provide or pay for medical care, including health insurance companies, HMOs, company-sponsored health plans, Medicare, Medicaid, Medicare supplement insurers, and long-term care insurers.
• Healthcare Clearinghouses:Public or private entities that process non-standard health information received from other entities into a standard format or from standard format into a non-standard format, including billing services and community health information systems.
• Healthcare Providers:Any provider of medical or other health services, or supplies, who transmits any health information in electronic form in connection with a covered HIPAA transaction, including hospitals, physician practices, clinics, nursing homes, pharmacies, clinical laboratories, and home health agencies.

2.2 Business Associates

A Business Associate (BA) is any person or entity that performs functions or activities on behalf of a covered entity that involve the use or disclosure of PHI, or that provides services to a covered entity that require access to PHI. Since the HIPAA Omnibus Final Rule (2013), Business Associates are directly and independently subject to the HIPAA Security Rule—not merely contractually obligated through their Business Associate Agreements.

Examples of Business Associates include:

• EHR vendors and cloud-based health IT platform providers that host or process ePHI on behalf of providers or health plans.
• Managed security service providers (MSSPs) and cloud service providers (CSPs) with access to systems or storage containing ePHI.
• Third-party billing, coding, and revenue cycle management services.
• Health information exchange (HIE) organizations and data analytics firms.
• Legal, accounting, and consulting firms that access PHI in performing services.
• Subcontractors of Business Associates that create, receive, maintain, or transmit ePHI on behalf of the BA. Subcontractors are themselves Business Associates and must enter into BAAs with the primary BA.

2.3 Electronic Protected Health Information (ePHI)

The Security Rule applies exclusively to protected health information (PHI) that exists in electronic form. ePHI is any PHI that is created, received, maintained, or transmitted in electronic media—including information on hard drives, servers, databases, USB drives, backup tapes, CDs, mobile devices, and cloud storage—as well as any PHI transmitted over electronic networks.

PHI includes any individually identifiable health information that relates to an individual’s past, present, or future physical or mental health condition, the provision of healthcare, or payment for healthcare. HHS identifies 18 categories of direct identifiers, including names, geographic data, dates, phone and fax numbers, email addresses, Social Security numbers, medical record numbers, IP addresses, biometric identifiers, and full-face photographs. Note that paper PHI is governed exclusively by the HIPAA Privacy Rule—not the Security Rule.

2.4 Workforce

HIPAA defines “workforce” broadly to include all employees, volunteers, trainees, and other persons under the direct control of a covered entity or business associate, whether or not they are paid. All workforce members who access, use, or disclose ePHI are subject to the entity’s security policies, training requirements, and sanction policy.

3. Structure of the HIPAA Security Rule

3.1 Regulatory Framework

The HIPAA Security Rule is codified at 45 CFR Part 164, organized across three subparts:

• Subpart A (45 CFR §164.102–164.106):General Administrative Requirements, including applicability and definitions.
• Subpart C (45 CFR §164.302–164.318):The Security Standards themselves. Contains the three safeguard categories (Administrative, Physical, Technical), Organizational Requirements (§164.314), and Policies, Procedures, and Documentation Requirements (§164.316).
• Subpart D (45 CFR §164.400–164.414):Notification in Case of Breach of Unsecured Protected Health Information, added by the HITECH Act.

3.2 The Three Safeguard Categories

All Security Rule requirements are organized into three categories of safeguards:

• Administrative Safeguards (45 CFR §164.308):Policies and procedures and management processes governing the selection, development, implementation, and maintenance of security measures to protect ePHI, and managing workforce conduct in relation to ePHI protection. Nine standards with 18 implementation specifications.
• Physical Safeguards (45 CFR §164.310):Physical measures, policies, and procedures to protect electronic information systems, buildings, and equipment from natural, environmental, and human hazards. Four standards with nine implementation specifications.
• Technical Safeguards (45 CFR §164.312):Technology and the policies and procedures for its use that protect ePHI and control access to it. Five standards with nine implementation specifications.

3.3 Required vs. Addressable Implementation Specifications

Within each safeguard standard, individual requirements are classified as either Required or Addressable. This distinction is critical and frequently misunderstood:

• Required:The implementation specification must be implemented as stated. There is no flexibility to substitute an alternative measure or to omit the specification based on organizational circumstances. Required specifications represent the non-negotiable floor of HIPAA compliance.
• Addressable:The entity must conduct a documented assessment to determine whether the specification is reasonable and appropriate given its size, complexity, capabilities, technical infrastructure, cost, and probability of risk to ePHI. If reasonable and appropriate: implement it. If not: document why it is not, and implement an equivalent alternative that achieves the same protective purpose. Critically, “Addressable” does not mean “optional.”

3.4 General Rules (45 CFR §164.306)

Section 164.306 establishes four overarching requirements that all covered entities and business associates must satisfy and from which all specific standards and specifications flow:

• Ensure the confidentiality, integrity, and availability of all ePHI they create, receive, maintain, or transmit.
• Protect against any reasonably anticipated threats or hazards to the security or integrity of ePHI.
• Protect against any reasonably anticipated uses or disclosures of ePHI that are not permitted or required by the Privacy Rule.
• Ensure compliance by their workforce with the Security Rule.

4. Administrative Safeguards — 45 CFR §164.308

Administrative Safeguards are the policies, procedures, and management controls used to protect ePHI and to manage workforce conduct in relation to that protection. They represent the most extensive category of the Security Rule—nine standards and 18 implementation specifications—and are the most frequently cited category in OCR enforcement actions. The Security Management Process standard, and specifically Risk Analysis, is the bedrock upon which all other safeguards must be constructed.

4.1 Security Management Process — 45 CFR §164.308(a)(1)

The Security Management Process standard requires the implementation of policies and procedures to prevent, detect, contain, and correct security violations. OCR has cited inadequate risk analysis and risk management as root causes in the overwhelming majority of its enforcement actions.

Risk Analysis Required

A covered entity or business associate must conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI it holds. A compliant risk analysis must:

• Define the scope of ePHI—all ePHI created, received, maintained, or transmitted across all systems, applications, and electronic media, regardless of location.
• Identify all realistic threats to ePHI: natural threats (floods, fires, earthquakes, power failures), environmental threats (HVAC failures, hardware failure), and human threats (external attackers, malicious insiders, accidental disclosures).
• Identify current vulnerabilities in technical, physical, and administrative controls that could be exploited by the identified threats.
• Assess the likelihood that each threat will successfully exploit each identified vulnerability.
• Assess the impact on ePHI confidentiality, integrity, or availability if exploitation occurs.
• Determine an overall risk level for each threat/vulnerability pair (typically likelihood × impact).
• Document all findings in a risk analysis report that is retained as required documentation.

NIST SP 800-30 Rev. 1 (Guide for Conducting Risk Assessments) and NIST SP 800-66 Rev. 2 (Implementing the HIPAA Security Rule) provide the authoritative methodology for HIPAA-compliant risk analyses.

Risk Management Required

Based on the risk analysis findings, implement security measures sufficient to reduce identified risks to a reasonable and appropriate level. Risk management must be an ongoing program, not a one-time project:

• Prioritize identified risks and develop formal remediation plans for high and critical risks.
• Select, implement, and maintain administrative, physical, and technical safeguards proportional to identified risks.
• Define an acceptable residual risk threshold and document the rationale for accepting residual risks that fall below that threshold.
• Reassess risk and update the risk management plan whenever significant operational, technological, or regulatory changes occur, and at minimum annually.

Sanction Policy Required

Implement written policies that specify the range of sanctions applied to workforce members who fail to comply with the entity’s security policies and procedures. The sanction policy must: define categories of non-compliance with proportionate sanctions; be communicated to all workforce members during training; and be applied consistently, with each application documented.

Information System Activity Review Required

Implement procedures to regularly review records of information system activity. Reviews must cover audit logs, access reports, and security incident tracking records at a frequency sufficient to detect anomalous activity in a timely manner. For high-risk systems or after incidents, reviews should occur daily via automated mechanisms; periodic manual review is required across all CDE systems.

4.2 Assigned Security Responsibility — 45 CFR §164.308(a)(2)

Identify the security official who is responsible for the development and implementation of the policies and procedures required by the Security Rule. The HIPAA Security Officer designation must:

• Name a specific individual (not a role, team, or department) as the Security Officer.
• Document the designation in writing and communicate it across the organization.
• Empower the Security Officer with appropriate authority, resources, and executive support.
• Assign responsibilities covering: policy development, risk management oversight, training coordination, incident response management, evaluation, and OCR liaison functions.
• Ensure the Security Officer has adequate knowledge of current threats, security technologies, and regulatory developments in the healthcare sector.

In larger organizations, the Security Officer may be supported by an Information Security team or HIPAA Compliance Committee, but individual named accountability cannot be distributed. The Security Officer and Privacy Officer roles may be held by the same individual, provided both sets of responsibilities are explicitly assigned and documented.

4.3 Workforce Security — 45 CFR §164.308(a)(3)

Implement policies and procedures to ensure that all workforce members who require access to ePHI have appropriate authorization, and those who should not have access cannot obtain it.

Authorization and/or Supervision Addressable

Establish procedures for the authorization and supervision of workforce members who work with ePHI or in locations where ePHI may be accessed. This applies to all workforce categories: employees, contractors, temporary staff, volunteers, students, and interns. Supervision procedures must be documented and aligned with access levels granted.

Workforce Clearance Procedure Addressable

Establish procedures to determine that a workforce member’s access to ePHI is appropriate. The depth of clearance investigation should be commensurate with the sensitivity of the ePHI to be accessed: roles with broad ePHI access (e.g., system administrators, security staff) warrant more rigorous background screening than roles with narrow, read-only access to limited data sets.

Termination Procedures Addressable

Implement procedures for revoking access to ePHI when workforce members leave or change roles. Termination procedures must address: immediate revocation of all logical access credentials (network accounts, EHR accounts, email, remote access, VPN); physical access card deactivation; retrieval of portable devices, access media, and equipment containing ePHI; documentation of all access revocation actions taken. Involuntary terminations require immediate revocation; voluntary terminations should follow a defined maximum timeframe.

4.4 Information Access Management — 45 CFR §164.308(a)(4)

Implement policies and procedures for authorizing access to ePHI, consistent with the Privacy Rule’s minimum necessary standard. Access must be granted based on legitimate business need and the principle of least privilege.

Isolating Healthcare Clearinghouse Functions Required

Where a healthcare clearinghouse is part of a larger organization, the clearinghouse must implement policies and procedures that protect the ePHI it receives from unauthorized access by other parts of the larger organization. This Required specification applies exclusively to healthcare clearinghouses embedded in larger entities.

Access Authorization Addressable

Implement policies and procedures for granting access to ePHI. Every access grant must be: formally requested in writing, justified by business need, approved by an authorized manager, documented with the approver’s identity and the date, and time-limited where appropriate. Access authorization workflows must be auditable.

Access Establishment and Modification Addressable

Implement procedures for establishing, documenting, reviewing, and modifying user access rights to systems, applications, and data containing ePHI. Access rights must be reviewed at defined intervals (at least annually) and modified promptly—ideally within one business day—whenever a workforce member’s role changes.

4.5 Security Awareness and Training — 45 CFR §164.308(a)(5)

Implement a security awareness and training program for all workforce members, including management. Training is indispensable: even technically sophisticated safeguards can be defeated by a single uninformed or negligent workforce member. All training must be documented, with attendance records retained.

Security Reminders Addressable

Implement periodic security updates reminding workforce members of their obligations, current threats, and best practices. Security reminders should be delivered through multiple channels: email advisories, security bulletins, intranet posts, and brief awareness sessions. Reminders should respond to current threat intelligence—for example, issuing a phishing advisory following a healthcare sector phishing campaign.

Protection from Malicious Software Addressable

Implement procedures for guarding against, detecting, and reporting malicious software. Workforce training must cover: recognizing and avoiding phishing emails and social engineering attempts; safe web browsing habits; the risks of removable media and unauthorized software; how to report suspected malware infections; and the prohibition on downloading unauthorized software to systems that create, access, or store ePHI.

Log-in Monitoring Addressable

Implement procedures for monitoring log-in attempts and reporting discrepancies. Personnel with administrative or privileged access responsibilities must understand how to interpret login activity reports, what constitutes suspicious activity (e.g., logins outside normal business hours, failed login surges, logins from unexpected geographic locations), and the escalation path for reporting anomalies.

Password Management Addressable

Implement procedures for creating, protecting, and managing passwords. Training must address: selecting strong passwords or passphrases; the prohibition on sharing credentials; unique passwords across systems; how to use password managers; and the process for reporting suspected credential compromise. Password policies should align with current NIST SP 800-63B guidelines (long passphrases, no forced periodic rotation without evidence of compromise, no complexity rules that reduce entropy).

4.6 Security Incident Procedures — 45 CFR §164.308(a)(6)

Implement policies and procedures to address security incidents. The Security Rule defines a security incident as the attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an information system containing ePHI. All security incidents require response; not all security incidents constitute reportable breaches.

Response and Reporting Required

Identify and respond to suspected or known security incidents, mitigate any harmful effects to the extent practicable, and document security incidents and their outcomes. A HIPAA-compliant incident response program must:

• Define what constitutes a security incident and establish a clear, low-friction reporting mechanism (e.g., a dedicated email address, ticketing system, or hotline) for workforce members.
• Establish a documented incident response procedure covering: identification and triage, containment, eradication, recovery, and post-incident review (lessons learned).
• Designate an incident response team or assign incident response responsibilities to identified personnel.
• Conduct a four-factor breach risk assessment for every security incident involving ePHI to determine whether the incident is a reportable breach under Subpart D.
• Document all security incidents and their resolutions in an incident register, including incidents subsequently determined not to be reportable breaches. This register is a required documentation artifact.
• Preserve evidence from security incidents in a manner that supports potential OCR investigation, litigation, or law enforcement referral.

4.7 Contingency Plan — 45 CFR §164.308(a)(7)

Establish and implement policies and procedures for responding to an emergency or other occurrence that damages systems containing ePHI. The contingency plan must ensure that ePHI remains available to support patient care and business operations even during system failures, disasters, or security incidents.

Data Backup Plan Required

Create and maintain retrievable, exact copies of ePHI. Backup procedures must specify: frequency (at minimum daily for critical systems), media type and format, storage location including off-site or cloud backup, encryption of backup media, recovery point objective (RPO), and a schedule for restoration testing to verify that backups are usable.

Disaster Recovery Plan Required

Establish procedures to restore any loss of ePHI and the systems that contain it. The disaster recovery plan (DRP) must define: recovery time objectives (RTO) and recovery point objectives (RPO) for each critical ePHI system; step-by-step restoration procedures for each system; roles and responsibilities during recovery operations; escalation contacts and communication trees; and testing requirements.

Emergency Mode Operation Plan Required

Establish procedures to enable continuation of critical business processes and protection of ePHI while operating in emergency mode (i.e., when primary systems are unavailable). The plan must identify which ePHI applications are critical to patient care, define manual or degraded-mode alternatives when those systems are unavailable, and specify how minimum necessary ePHI protections are maintained during system outages.

Testing and Revision Procedure Addressable

Implement procedures for periodic testing of contingency plans and revision based on test results. Testing levels include: tabletop exercises (discussing response to a hypothetical scenario), functional testing (activating specific contingency plan components), and full failover testing (activating the complete DRP). All test results must be documented and used to update the contingency plan.

Applications and Data Criticality Analysis Addressable

Assess the relative criticality of specific applications and data in support of other contingency plan components. This analysis prioritizes systems based on their importance to patient care, operational continuity, and ePHI protection, enabling recovery resources to be allocated to the most critical systems first.

4.8 Evaluation — 45 CFR §164.308(a)(8)

Perform a periodic technical and non-technical evaluation of the extent to which the entity’s security policies and procedures meet the requirements of the Security Rule. Evaluations must occur: initially (to establish a compliance baseline before implementation); periodically thereafter (at minimum annually); and in response to environmental or operational changes affecting ePHI security, such as new technology adoption, changes in business operations, significant personnel changes, or regulatory updates. Evaluation results must be documented and used to drive remediation planning.

4.9 Business Associate Contracts and Other Arrangements — 45 CFR §164.308(b)(1)

Written Contract or Other Arrangement Required

Before disclosing ePHI to a Business Associate, a covered entity must obtain satisfactory assurances that the BA will appropriately safeguard the ePHI. Since the Omnibus Rule, BAs must also execute BAAs with their own subcontractors that handle ePHI on their behalf.

A HIPAA-compliant BAA must address:

• Permitted and required uses and disclosures of PHI by the Business Associate.
• The BA’s obligation to implement appropriate administrative, physical, and technical safeguards.
• The BA’s obligation to report security incidents—including breaches—to the covered entity within a defined timeframe.
• The BA’s obligation to make available its internal practices, books, and records to HHS for compliance audits.
• Requirements for the BA to return or certify destruction of ePHI at termination of the agreement.
• Obligations for BA subcontractors (sub-BAA requirements).

BAA management must include: a comprehensive BA inventory; a regular BA vetting process (security questionnaires, SOC 2 Type II review, or equivalent); defined breach notification timelines in BAAs (typically 10–30 days to allow CEs to meet their own 60-day obligation); and ongoing compliance monitoring.

5. Physical Safeguards — 45 CFR §164.310

Physical Safeguards govern the protection of the physical systems, buildings, and equipment that house or provide access to ePHI. They address the tangible means by which ePHI can be compromised: unauthorized entry into facilities, theft of workstations or portable devices, improper disposal of hardware or media, and abuse of physical access to ePHI systems. Four standards and nine implementation specifications govern physical protection.

5.1 Facility Access Controls — 45 CFR §164.310(a)(1)

Implement policies and procedures to limit physical access to electronic information systems and the facilities in which they are housed, while ensuring that properly authorized access is allowed.

Contingency Operations Addressable

Establish procedures that allow appropriate facility access in support of restoration of lost data under the disaster recovery plan and emergency mode operations plan. This includes defining access procedures for evenings, weekends, holidays, and disaster conditions when normal access infrastructure (e.g., badge readers, security personnel) may be unavailable.

Facility Security Plan Addressable

Implement policies and procedures to safeguard the facility and the equipment therein from unauthorized physical access, tampering, and theft. The plan must: document all facility entry/exit points and the controls protecting each; define access levels and the physical controls appropriate for each level; address after-hours access procedures; and define monitoring mechanisms (CCTV, access logs) and their review schedule.

Access Control and Validation Procedures Addressable

Implement procedures to control and validate a person’s access to facilities based on their role or function, including visitor and vendor management:

• Electronic badge access systems with role-based access profiles and audit logging of all entries.
• Visitor management procedures: sign-in with photo ID verification, temporary badges distinguishable from employee badges, escort requirements for sensitive areas, and visitor log retention.
• Vendor and contractor access management: temporary access provisioning with defined expiry, supervision requirements, and prompt revocation on departure.
• Clean-desk and screen-lock requirements for workstations in areas accessible to patients or the public.

Maintenance Records Addressable

Implement policies and procedures to document repairs and modifications to physical components of a facility related to security, including hardware, walls, doors, and locks. Maintenance records provide an audit trail that may be critical during incident investigations or OCR audits.

5.2 Workstation Use — 45 CFR §164.310(b)

Implement policies and procedures specifying the proper functions performed on workstations that access ePHI, how those functions are to be performed, and the physical attributes of the workstation’s surroundings. This standard applies to any electronic computing device used to access ePHI, including desktops, laptops, tablets, and thin clients. Policies must address:

• Permitted and prohibited activities on workstations that access ePHI (prohibition on personal use, restrictions on software installation, prohibition on local ePHI storage unless encrypted).
• Screen placement and privacy screen requirements for workstations in areas visible to patients, visitors, or the general public.
• Screen lock and automatic logoff settings and the inactivity timeout period.
• Prohibition on leaving workstations unattended with an active ePHI session open.
• Rules for remote work environments: requirements for home office physical security, prohibition on ePHI access from public Wi-Fi without VPN, and spousal/family member screen access prevention.

5.3 Workstation Security — 45 CFR §164.310(c)

Implement physical safeguards for all workstations that access ePHI to restrict access to authorized users. Unlike Workstation Use (which addresses policies and procedures), Workstation Security focuses on the physical controls protecting the hardware itself:

• Cable locks securing desktop and laptop computers to fixed furniture or wall anchors.
• Workstations placed in physically restricted areas with limited access.
• Privacy screens on monitors visible to unauthorized individuals.
• Secure mounting for tablets and kiosk devices in clinical settings.
• Asset identification mechanisms (barcodes, RFID asset tags) enabling inventory tracking and detection of missing equipment.

5.4 Device and Media Controls — 45 CFR §164.310(d)(1)

Implement policies and procedures governing the receipt, movement, and removal of hardware and electronic media that contain ePHI into and out of facilities, and the movement of these items within facilities.

Disposal Required

Implement policies and procedures to address the final disposition of ePHI and/or the hardware or electronic media on which it is stored. Acceptable methods must render ePHI permanently irretrievable, in compliance with NIST SP 800-88 (Guidelines for Media Sanitization):

• Hard drives:Physical shredding or degaussing (for magnetic media) to NIST-approved standards.
• Solid-state drives (SSDs and NVMe):Physical destruction or cryptographic erasure (deleting the encryption key when full-disk encryption was used, rendering data permanently inaccessible).
• USB drives and portable media:Physical destruction or NIST-compliant purging.
• Optical media:Physical shredding or incineration.
• Mobile devices:Factory reset followed by verification that ePHI is not recoverable, or physical destruction.

A Certificate of Destruction must be obtained from the disposing party and retained as required documentation.

Media Re-use Required

Implement procedures for the removal of ePHI from electronic media before the media is repurposed or made available for reuse. Simply deleting files, emptying the recycle bin, or formatting a drive does not constitute secure removal and does not satisfy this requirement. NIST SP 800-88-compliant purging or overwriting is required.

Accountability Addressable

Maintain a record of the movements of hardware and electronic media and the person responsible for each. An asset inventory must track: the current location of all devices containing ePHI; all movements of devices between facilities, departments, or custodians; the identity of the responsible custodian; and disposal records.

Data Backup and Storage Addressable

Create a retrievable exact copy of ePHI before movement of equipment containing that data. This specification applies specifically to backing up ePHI prior to the physical movement of hardware, ensuring data is not lost if a device is damaged, lost, or stolen during transit.

6. Technical Safeguards — 45 CFR §164.312

Technical Safeguards are the technology-based controls used to protect ePHI and to control access to it. The Security Rule is deliberately technology-neutral in this category—it specifies no particular products, algorithms, or protocols. However, OCR guidance, NIST publications, and the evolving standard of care in healthcare cybersecurity provide clear expectations for what constitutes reasonable and appropriate implementation. Five standards and nine implementation specifications govern technical protection of ePHI.

6.1 Access Control — 45 CFR §164.312(a)(1)

Implement technical policies and procedures for electronic information systems that maintain ePHI to allow access only to those persons or software programs that have been granted access rights as specified in the Information Access Management standard (§164.308(a)(4)).

Unique User Identification Required

Assign a unique name and/or number for identifying and tracking user identity. Shared accounts and generic logins are prohibited for workforce members accessing ePHI. Unique user identification is foundational to audit controls, access management, and incident investigation—without it, actions in ePHI systems cannot be attributed to specific individuals.

• Every human user of systems containing ePHI must have a unique, individually assigned account.
• Service accounts, application accounts, and system accounts must also be uniquely identified and separately managed from human user accounts.
• Username conventions should be standardized and documented in policy.
• Shared, group, or generic accounts are prohibited for interactive human access. Where technically unavoidable, mitigating controls (session recording, strict credential management, enhanced monitoring) must be implemented and documented.

Emergency Access Procedure Required

Establish procedures for obtaining necessary ePHI during an emergency. Break-glass or emergency access procedures ensure that patient care is not compromised during system outages or authentication failures while maintaining accountability:

• Identify the emergency accounts and the criteria for their use.
• Ensure that activation of emergency access triggers enhanced audit logging and immediate post-event review.
• Require notification to the Security Officer within a defined timeframe following any use of emergency access.
• Conduct periodic testing of emergency access procedures as part of contingency plan testing.

Automatic Logoff Addressable

Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity. Automatic logoff protects against unauthorized access to ePHI left visible on unattended screens in clinical and administrative settings:

• Define inactivity timeout periods based on contextual risk (e.g., 2–5 minutes for shared clinical workstations; 10–15 minutes for private administrative offices).
• Configure automatic logoff at both the operating system level and the EHR/application level to provide defense in depth.
• Screen lock (password-protected screensaver) is the minimum acceptable control; full session termination is preferable for high-risk workstations.

Encryption and Decryption Addressable

Implement a mechanism to encrypt and decrypt ePHI stored at rest. While Addressable, encryption at rest is widely considered the single most effective control for mitigating the risk of ePHI exposure from physical theft or loss of devices, and its absence is increasingly viewed as unreasonable and inappropriate. NIST SP 800-111 provides technical guidance:

• Full-disk encryption using AES-256 (via BitLocker, FileVault, Linux LUKS, or equivalent) on all workstations, laptops, and servers that store ePHI.
• Encryption of all USB drives and portable storage media containing ePHI.
• Device encryption enabled on all mobile devices (smartphones, tablets) used to access or store ePHI.
• Database-level or column-level encryption for particularly sensitive ePHI categories (e.g., psychiatric records, substance abuse treatment records, HIV status).
• Encryption key management must prevent the decryption key from being stored alongside the encrypted data.

6.2 Audit Controls — 45 CFR §164.312(b)

Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. This Required standard has no implementation specifications—the entity must determine what constitutes a reasonable and appropriate level of audit logging given its environment. A comprehensive audit controls program must address:

• What to log:All access to ePHI (user, resource, timestamp, action); all login and logout events; create, read, update, and delete (CRUD) operations on ePHI; failed access attempts; privilege escalation events; changes to security configurations; and administrative account activity.
• Where to log:All systems that create, receive, maintain, or transmit ePHI, including EHR and clinical information systems, databases, file servers, email servers, VPN gateways, and network infrastructure.
• How to protect logs:Audit logs must be protected from unauthorized modification, deletion, and access. Centralized, append-only log storage in a SIEM is strongly recommended. Log integrity should be verified through cryptographic signing or hash chaining.
• How long to retain logs:The Security Rule does not specify a retention period, but the six-year documentation retention requirement at §164.316(b) is typically applied. State law requirements and litigation hold considerations may mandate longer retention periods.
• How often to review logs:Automated review with real-time alerting for high-risk events (e.g., access to sensitive records, failed login surges, after-hours access) should be implemented. At minimum, periodic manual review of anomalous access reports must be performed and documented.

6.3 Integrity — 45 CFR §164.312(c)(1)

Implement policies and procedures to protect ePHI from improper alteration or destruction. The integrity standard ensures that ePHI accurately reflects the health information it represents and has not been tampered with, accidentally corrupted, or improperly deleted.

Mechanism to Authenticate ePHI Addressable

Implement electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner. Technical controls include:

• Cryptographic hashing (SHA-256 or SHA-3) to generate integrity checksums for ePHI files or database records. Hash values stored separately can be compared over time to detect unauthorized modifications.
• Digital signatures using PKI-based asymmetric keys to provide both integrity verification and non-repudiation for ePHI documents and electronic health records.
• File integrity monitoring (FIM) tools (e.g., Tripwire, Wazuh FIM, Qualys FIM) deployed on systems containing ePHI to detect unauthorized changes to critical files and system configurations.
• Immutable backup storage (write-once, read-many or object-lock storage) to preserve the integrity of backup copies against ransomware and malicious deletion.
• EHR and clinical system audit trails must maintain a complete, non-repudiable record of all data changes, including who made each change, when, and what the prior and new values were.

6.4 Person or Entity Authentication — 45 CFR §164.312(d)

Implement procedures to verify that a person or entity seeking access to ePHI is the one claimed. This Required standard applies to both human user authentication and system/application authentication. Authentication methods appropriate for HIPAA compliance include:

• Multi-Factor Authentication (MFA):Strongly recommended by OCR and increasingly viewed as a standard of care for ePHI access. MFA combines at least two independent factors: something you know (password or PIN), something you have (hardware token, TOTP authenticator app, smart card), or something you are (biometric). MFA significantly reduces the risk of credential-stuffing, phishing, and password spray attacks.
• Password-based authentication:Must comply with the Password Management Addressable specification under §164.308(a)(5). Passwords alone are considered an insufficient authentication control for high-risk ePHI access.
• PKI-based digital certificates:Suitable for both user authentication (smart card, certificate-based login) and system/entity authentication (machine-to-machine API authentication).
• Biometric authentication:Fingerprint, facial recognition, and iris recognition are appropriate in clinical settings where card or token-based authentication is impractical.
• Adaptive and risk-based authentication:Context-aware authentication that adjusts requirements based on risk signals (device health, geographic location, behavioral patterns) provides stronger security without excessive user friction.
• Service account and API authentication:Applications, interfaces, and automated processes accessing ePHI must authenticate using managed service accounts or API keys stored in a secrets management solution. API keys must not be hardcoded in application code or stored in version control.

6.5 Transmission Security — 45 CFR §164.312(e)(1)

Implement technical security measures to guard against unauthorized access to ePHI that is being transmitted over an electronic communications network. This standard applies to all electronic ePHI transmissions—not just internet-based transmissions.

Integrity Controls Addressable

Implement security measures to ensure that electronically transmitted ePHI is not improperly modified without detection. Controls include: TLS authenticated cipher suites (e.g., AES-GCM) that provide both confidentiality and authenticated integrity in a single operation; message authentication codes (MACs) applied to ePHI payloads; and cryptographic digital signatures on ePHI documents transmitted between systems.

Encryption Addressable

Implement a mechanism to encrypt ePHI in transit whenever deemed appropriate. While Addressable, encryption of ePHI in transit is the universal standard of care in healthcare and is considered a baseline expectation by OCR. NIST SP 800-52 Rev. 2 provides technical protocol guidance:

• All ePHI transmitted over the internet or other untrusted networks must be encrypted using TLS 1.2 at minimum; TLS 1.3 is strongly preferred for new implementations.
• All web-based ePHI portals, EHR APIs, health information exchange (HIE) interfaces, and patient-facing applications must use HTTPS with a valid, current TLS certificate.
• SSL, TLS 1.0, and TLS 1.1 are cryptographically deprecated and must not be used for ePHI transmissions.
• Email transmission of ePHI: TLS must be enforced for server-to-server SMTP relay transport. Where end-to-end confidentiality is required (e.g., patient communications), S/MIME or a secure messaging portal must be used.
• Remote workforce access to systems containing ePHI must use encrypted VPN tunnels (IPsec or TLS-based) or encrypted virtual desktop infrastructure (VDI).
• Internal network ePHI transmissions: Encrypted protocols should be used for sensitive internal communications, particularly in shared, multi-tenant, or wireless environments.

7. Organizational Requirements and Documentation Requirements

7.1 Business Associate Contracts and Other Arrangements — 45 CFR §164.314(a)

Section 164.314(a) establishes the organizational requirements for Business Associate Agreements (BAAs) and specifies minimum content requirements. This section supplements the administrative standard at §164.308(b) and provides the legal framework within which BA obligations operate. From a program management perspective:

• Maintain a comprehensive and current BA inventory identifying all entities that create, receive, maintain, or transmit ePHI on the covered entity’s behalf.
• Establish a BA vetting process: before executing a BAA and sharing ePHI, assess the prospective BA’s security posture through a security questionnaire, review of a current SOC 2 Type II report (if available), and contractual security requirements.
• Review and update BAA templates following each major regulatory change.
• Monitor BA compliance through contractual audit rights, annual attestation, and periodic security questionnaire renewals.
• Ensure BAA breach notification timelines are shorter than the statutory 60-day maximum—typically 10 or 30 days—to enable covered entities to meet their own notification obligations.
• Respond to known BA security violations: if the covered entity is aware of a pattern of activity by the BA that constitutes a material breach of the BAA and steps are not taken to cure the breach, the covered entity must terminate the BAA. Inaction is a compliance violation.

7.2 Requirements for Group Health Plans — 45 CFR §164.314(b)

Group health plans sponsored by employers must include provisions in their plan documents requiring the plan sponsor to: implement administrative, physical, and technical safeguards for ePHI disclosed by the plan to the plan sponsor; ensure that subcontractors handling ePHI agree to the same restrictions; report security incidents to the plan; and not use or disclose ePHI except as permitted by the plan documents. The plan sponsor must agree to make ePHI available to HHS for compliance audits.

7.3 Policies and Procedures — 45 CFR §164.316(a)

Implement reasonable and appropriate policies and procedures to comply with all Security Rule standards and implementation specifications. This meta-requirement means that every Security Rule obligation must be addressed through formally documented policies and procedures that are implemented, enforced, and consistently followed. A comprehensive HIPAA security policy library must include:

• Overarching Information Security Policy
• Risk Analysis and Risk Management Policy
• Access Control and User Account Management Policy
• Workforce Security Policy (hiring, background checks, termination, role changes)
• Security Awareness and Training Policy
• Security Incident Identification, Response, and Reporting Policy
• Business Continuity and Disaster Recovery Policy
• Device and Media Control Policy (including acceptable use, disposal, and encryption requirements)
• Workstation Security and Acceptable Use Policy
• Audit Logging and Monitoring Policy
• Transmission Security Policy (encryption, email security, remote access)
• Business Associate Management Policy
• Breach Identification, Risk Assessment, and Notification Policy
• Physical Security Policy

7.4 Documentation Requirements — 45 CFR §164.316(b)

The Security Rule imposes specific documentation requirements for all policies, procedures, assessments, and actions taken in furtherance of Security Rule compliance:

• Written Form — Required:All policies, procedures, and other actions, activities, or assessments required by the Security Rule must be maintained in written form, which includes electronic documents.
• Time Limit — Required:Documentation must be retained for six years from the date of its creation or the date when it was last in effect, whichever is later. This is the minimum; state law or litigation hold requirements may mandate longer retention.
• Availability — Required:Documentation must be made available to those responsible for implementing the policies and procedures to which it relates. Security policies must be accessible to the workforce members required to follow them.
• Updates — Required:Documentation must be reviewed and updated periodically in response to environmental or operational changes affecting the security of ePHI.

Documentation that must be retained for six years includes: all risk analyses and supporting evidence; risk management decisions and evidence of implementation; security incident reports and resolution documentation; workforce training records; access authorization approvals; evaluation reports and findings; BAAs and BA correspondence; contingency plan test results; and all policy and procedure versions with effective dates.

8. Breach Notification Rule — 45 CFR Part 164, Subpart D (§§164.400–164.414)

8.1 Overview

The HIPAA Breach Notification Rule, added by the HITECH Act and codified at 45 CFR §§164.400–164.414, requires covered entities and business associates to provide notification following the discovery of a breach of unsecured protected health information. The Rule transformed the risk calculus of ePHI security by creating powerful incentives for robust technical safeguards—especially encryption—and by mandating timely, transparent, and public notification to affected individuals, media outlets, and HHS.

8.2 Definitions: Breach and Unsecured PHI

• Breach:An impermissible use or disclosure under the Privacy Rule that compromises the security or privacy of the protected health information. A breach is presumed to have occurred whenever an impermissible use or disclosure takes place, unless the covered entity or business associate demonstrates that there is a low probability that the PHI has been compromised based on a documented four-factor risk assessment.
• Unsecured PHI:PHI that has not been rendered unusable, unreadable, or indecipherable to unauthorized individuals through HHS-specified methods: (1) encryption conforming to current NIST standards; or (2) destruction—physical destruction for paper/film, rendering media unusable and indecipherable for electronic media. Only a breach of unsecured PHI triggers the Breach Notification Rule.

8.3 Breach Risk Assessment — The Four-Factor Test

When an impermissible use or disclosure of PHI occurs, the entity must conduct and document a risk assessment evaluating at minimum the following four factors to determine whether the incident constitutes a reportable breach:

• Factor 1 — Nature and Extent of the PHI Involved:Consider the types of identifiers, the sensitivity of the health information, and the likelihood of re-identification from the disclosed data. A disclosure containing a full medical record with SSN, diagnosis, and financial information carries a higher probability of compromise than a disclosure of only a name and appointment date.
• Factor 2 — Who Accessed or Could Have Accessed the PHI:Consider whether the unauthorized recipient is another healthcare provider (lower risk, likely understands PHI obligations), an unknown individual, or a known bad actor with intent to misuse the data (higher risk).
• Factor 3 — Whether PHI Was Actually Acquired or Viewed:Assess whether the impermissible disclosure resulted in actual acquisition or viewing of the PHI. A misdirected email confirmed to have been immediately and unread deleted presents lower risk than an email confirmed to have been opened.
• Factor 4 — Extent to Which Risk Has Been Mitigated:Assess the degree to which risk of harm has been mitigated post-incident. For example, a confidentiality agreement executed by the unintended recipient combined with confirmed deletion reduces residual risk.

If the analysis concludes that there is a low probability that the PHI has been compromised, breach notification is not required, but the analysis and conclusion must be thoroughly documented and retained. OCR will scrutinize breach risk assessments and may override determinations of low probability if the assessment is inadequate or the conclusion is unsupported.

8.4 Notification Requirements

8.4.1 Notification to Individuals

Without unreasonable delay and no later than 60 calendar days after discovery of a breach, covered entities must notify each affected individual. Written notice must be sent by first-class mail (or email if the individual has agreed to electronic notice). Required content includes: a description of the breach; the types of PHI involved; steps individuals should take to protect themselves (e.g., fraud alerts, credit monitoring); the entity’s investigation and mitigation steps; and contact information for questions.

8.4.2 Notification to Media

For breaches affecting 500 or more residents of a single state or jurisdiction, covered entities must notify prominent media outlets serving that area without unreasonable delay and no later than 60 calendar days after discovery. This requirement is in addition to—not a substitute for—individual notification.

8.4.3 Notification to HHS

All breaches must be reported to HHS. Timing depends on breach size:

• Breaches affecting 500 or more individuals:Notify HHS within 60 days of discovery. HHS publishes these on its public breach portal (commonly called the “Wall of Shame”).
• Breaches affecting fewer than 500 individuals:Maintain a log of all smaller breaches during the calendar year and submit the log to HHS within 60 days after the end of the calendar year.

8.4.4 Business Associate Notification Obligations

A Business Associate that discovers a breach of unsecured PHI must notify the covered entity without unreasonable delay and no later than 60 calendar days following discovery. The BA must provide all information necessary to enable the covered entity to comply with its notification obligations. BAAs should require shorter BA notification timeframes (10–30 days) to provide the covered entity adequate preparation time.

8.5 Encryption Safe Harbor and Risk Reduction

If ePHI was encrypted in conformance with HHS guidance at the time of the incident, and the decryption key was not compromised, the incident does not constitute a reportable breach. HHS specifies NIST-approved encryption methods:

• Data at rest:Encryption per NIST SP 800-111 using AES-128 at minimum (AES-256 recommended).
• Data in transit:Encryption using current NIST-approved TLS protocols as defined in NIST SP 800-52.

The encryption safe harbor makes full-disk encryption of devices and encrypted transmission protocols among the highest-return HIPAA security investments. Combined with proper key management, these controls eliminate breach notification liability for the most common category of HIPAA breaches—physical loss or theft of devices—and provide a documented, defensible record of reasonable safeguard implementation.

9. HIPAA Security Rule Compliance Checklist

The following table covers all HIPAA Security Rule standards and implementation specifications. Use this checklist as a self-assessment and gap analysis tool. It does not substitute for a formal HIPAA risk analysis or an independent compliance assessment.

10. Glossary of Key Terms

The following glossary defines key terms used throughout this document and within the HIPAA Security Rule regulatory framework. Terms are presented in alphabetical order.

11. Conclusion

The HIPAA Security Rule establishes a risk-based, technology-neutral, and scalable framework for the protection of electronic protected health information. Its flexibility—grounded in the Required vs. Addressable distinction and the principle that what is “reasonable and appropriate” depends on the entity’s specific environment—means that compliance cannot be reduced to a product purchase or a one-time checklist exercise. It is a continuous program: analyzing risk, implementing safeguards, training the workforce, monitoring systems, responding to incidents, and updating everything when the environment changes.

For IT and security professionals in healthcare, the HIPAA Security Rule provides the regulatory minimum. The standard of care in healthcare cybersecurity has evolved substantially beyond the Security Rule’s literal requirements, driven by an escalating and increasingly sophisticated threat landscape—ransomware, business email compromise, EHR data exfiltration, and supply-chain attacks—and by the substantial financial, legal, and reputational consequences of large-scale breaches.

11.1 Priority Actions for Security Program Maturity

• Risk Analysis as the Unbreakable Foundation (Req. §164.308(a)(1)):Every HIPAA security investment must be grounded in a current, comprehensive, documented risk analysis. An absent or outdated risk analysis is the single most common finding in OCR enforcement actions. Perform a full risk analysis at least annually and after every significant operational or technical change.
• Encryption as Risk Elimination:Full-disk encryption on all endpoints and portable media, combined with TLS for all ePHI in transit, triggers the Breach Notification Safe Harbor for the most common breach scenario—physical loss or theft. The insurance value of these controls far exceeds their implementation cost.
• MFA for All ePHI Access:While not Required in the regulatory text, MFA for all ePHI access—particularly remote access, VPN, and patient portals—is a de facto standard driven by OCR corrective action plans. Implement MFA starting with highest-privilege accounts and internet-facing systems.
• Incident Response Readiness:Every security incident involving ePHI must be triaged, documented, subjected to a four-factor breach risk assessment, and resolved. An ad hoc response is both a compliance failure and an amplifier of harm.
• Business Associate Program Rigor:A BA breach is a covered entity breach. Conduct meaningful BA vetting before sharing ePHI, require short breach notification windows in BAAs, and monitor BA compliance on an ongoing basis.
• Audit Logging and Active Monitoring:Without comprehensive audit controls and regular log review, it is impossible to detect unauthorized ePHI access, investigate incidents, or demonstrate compliance during an OCR audit. Invest in SIEM capabilities and automated anomaly detection.
• Documentation Discipline:Six-year retention of all risk analyses, policies, training records, incident reports, evaluation results, BAAs, and access authorization approvals is the minimum. Documentation is your primary defense in an OCR investigation.

11.2 Alignment with Complementary Frameworks

Healthcare organizations seeking security programs that exceed the HIPAA minimum should align with:

• NIST SP 800-66 Rev. 2 — Implementing the HIPAA Security Rule:The authoritative NIST implementation guide specifically designed for HIPAA, including cross-references to NIST cybersecurity controls.
• Health Industry Cybersecurity Practices (HICP):The HHS 405(d) Program’s voluntary healthcare-specific cybersecurity practices, providing practical, prioritized mitigations aligned with the NIST CSF and tailored to the top healthcare threat scenarios.
• NIST Cybersecurity Framework (CSF) 2.0:A broadly adopted risk management framework whose Identify, Protect, Detect, Respond, and Recover functions map directly to HIPAA Security Rule requirements and provide a maturity model for continuous improvement.
• CIS Controls v8:Prioritized, actionable technical controls addressing the most common attack vectors in healthcare and other sectors.
• SOC 2 Type II:For Business Associates providing cloud or managed services, an independent SOC 2 Type II assessment provides external validation of security controls and can support BA vetting and BAA compliance assessments.

Reference: U.S. Department of Health and Human Services, Office for Civil Rights. (2003). HIPAA Security Rule. 45 CFR Part 164. Retrieved from https://www.hhs.gov/hipaa/for-professionals/security/index.html