HIPAA Security Rule Requirements: Administrative, Physical, and Technical Safeguards

The HIPAA Security Rule requires covered entities and business associates to protect electronic protected health information (ePHI) through three categories of safeguards: administrative, physical, and technical. The requirements are set out in 45 CFR Part 164, Subpart C, and each safeguard category contains standards, most of which carry one or more implementation specifications marked either required or addressable.

What are the three types of HIPAA Security Rule safeguards?

The three types are administrative safeguards at 45 CFR 164.308, physical safeguards at 45 CFR 164.310, and technical safeguards at 45 CFR 164.312. Administrative safeguards govern the policies, procedures, and workforce actions that manage security. Physical safeguards protect facilities, workstations, and devices. Technical safeguards control access to ePHI within information systems and protect it as it moves across networks.

Every covered entity and every business associate must comply with all three. The categories are not a menu. An organization that implements strong technical controls but never documents its physical safeguards has not met the rule, and OCR's enforcement record reflects that omissions in one category are as actionable as omissions in another.

Required versus addressable: the distinction that trips organizations up

An addressable implementation specification is not optional. Under 45 CFR 164.306(d)(3), a covered entity or business associate must either implement the specification as written, implement an equivalent alternative measure that is reasonable and appropriate, or document why neither is reasonable and appropriate for its environment and implement an equivalent measure where the standard itself still requires protection.

A required implementation specification offers no such flexibility. Under 45 CFR 164.306(d)(2), when a standard includes a required specification, the covered entity or business associate must implement it as written.

The practical consequence is that addressable never means skippable. An organization that treats an addressable specification as optional, without conducting and documenting the risk-based analysis the rule demands, has misread the regulation. That misreading appears repeatedly in OCR investigations, most often around encryption, which is addressable in every place it appears in the rule.

The standard that sits above both categories is the general requirement at 45 CFR 164.306(a): covered entities and business associates must ensure the confidentiality, integrity, and availability of all ePHI they create, receive, maintain, or transmit, protect against reasonably anticipated threats, protect against reasonably anticipated impermissible uses or disclosures, and ensure workforce compliance. The individual safeguards are the mechanism; 164.306(a) is the objective.

Administrative safeguards: 45 CFR 164.308

Administrative safeguards are the largest of the three categories and the one OCR examines most closely. They cover the security management process, workforce controls, training, incident procedures, contingency planning, evaluation, and business associate contracts.

The table below maps every administrative standard to its implementation specifications, with R marking a required specification and A marking an addressable one, current as of the Security Rule in force in 2026.

The Security Management Process is the anchor

The Security Management Process at 164.308(a)(1) is the foundation of the entire Security Rule, and all four of its implementation specifications are required. Risk Analysis at 164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. Risk Management at 164.308(a)(1)(ii)(B) requires implementing security measures sufficient to reduce those risks to a reasonable and appropriate level. Sanction Policy at 164.308(a)(1)(ii)(C) requires appropriate sanctions against workforce members who fail to comply. Information System Activity Review at 164.308(a)(1)(ii)(D) requires regular review of records such as audit logs, access reports, and security incident tracking reports.

Risk Analysis is the most frequently cited deficiency in OCR Security Rule investigations. Every other safeguard decision depends on it, because the rule asks organizations to implement measures that are reasonable and appropriate for their specific risks, and that phrase has no meaning without an analysis that identifies what those risks are.

Risk analysis is not a gap analysis

A risk analysis and a gap analysis are different exercises, and confusing them is the most common reason organizations believe they have satisfied 164.308(a)(1)(ii)(A) when they have not. A gap analysis compares an organization's current controls against a framework checklist and reports where controls are missing. A risk analysis is asset-based: it identifies every system that creates, receives, maintains, or transmits ePHI, then assesses the specific threats and vulnerabilities to each, along with the likelihood and potential impact of each.

A checklist can tell an organization it lacks multi-factor authentication. Only a risk analysis can tell it that the specific unencrypted laptop a traveling clinician uses to reach the EHR is a high-likelihood, high-impact risk that a compensating control has not addressed. OCR expects the second. A gap analysis submitted as a risk analysis is a finding, not a defense.

Contingency planning carries three required specifications

The Contingency Plan standard at 164.308(a)(7) is worth reading closely because three of its five specifications are required, more than most standards. Data Backup Plan, Disaster Recovery Plan, and Emergency Mode Operation Plan are all required. Testing and Revision Procedures and Applications and Data Criticality Analysis are addressable. In practice, untested backups are among the deficiencies OCR encounters most often, and a backup plan that has never been exercised satisfies the letter of a required specification while failing the purpose behind it.

Physical safeguards: 45 CFR 164.310

Physical safeguards protect the facilities and equipment that house ePHI. They are the smallest category, and they contain a fact that surprises many organizations: every implementation specification under Facility Access Controls is addressable.

All four Facility Access Controls specifications are addressable, which means an organization must still assess each one and either implement it, implement an equivalent measure, or document why neither is reasonable and appropriate. Addressable status does not remove the obligation to protect the facility; it grants flexibility in how.

Device and Media Controls is where the required specifications sit. Disposal at 164.310(d)(2)(i) and Media Re-use at 164.310(d)(2)(ii) are both required, because improper disposal of devices containing ePHI has been a recurring source of breaches. An organization that donates, resells, or discards drives, copiers, or mobile devices without sanitizing the ePHI on them has failed a required specification, regardless of how the rest of its program looks.

Technical safeguards: 45 CFR 164.312

Technical safeguards control how information systems grant access to ePHI and how ePHI is protected in transit. This is the category the proposed 2025 rule would change most, and it is where encryption's addressable status matters most.

Audit Controls at 164.312(b) and Person or Entity Authentication at 164.312(d) are standards with no implementation specifications, which means the standard itself is the requirement. Audit Controls requires hardware, software, or procedural mechanisms that record and examine activity in systems containing ePHI. It is a common mistake to conflate this with the administrative Information System Activity Review at 164.308(a)(1)(ii)(D). Audit Controls is the technical capability to record activity; Information System Activity Review is the administrative procedure to review those records. An organization needs both.

Is encryption required under the HIPAA Security Rule?

Encryption is addressable under the current HIPAA Security Rule, not required. It appears twice, both times as an addressable specification: Encryption and Decryption at 164.312(a)(2)(iv) for data at rest, and Encryption at 164.312(e)(2)(ii) for data in transit.

Both facts are true at once. Encryption is legally addressable, and it is very difficult to justify omitting on internet-facing systems or portable devices. An organization that decides against encryption must document, through its risk analysis, why encryption is not reasonable and appropriate and what equivalent measure it implemented instead. In practice, few organizations can build that justification for a laptop or an email gateway, and OCR's enforcement record shows unencrypted portable devices as a frequent origin of both breaches and penalties.

What the proposed Security Rule update would change, and what applies today

Everything in this section describes a proposed rule that is not in force. As of July 2026, the current Security Rule described above is the law, and it is what OCR enforces.

The HHS Office for Civil Rights (OCR) published a Notice of Proposed Rulemaking at 90 FR 898 on January 6, 2025, under RIN 0945-AA22. The public comment period closed March 7, 2025. OCR has not issued a final rule. OMB's Unified Agenda entry for RIN 0945-AA22 now targets July 2027 for final action, moved back from an earlier spring 2026 target. Regulatory agenda dates are projections, not commitments, and this one has already moved once; it could move again or the proposal could be withdrawn entirely.

If finalized as proposed, the rule would make several changes to the safeguards described above, as OCR's own fact sheet sets out:

• It would largely eliminate the distinction between required and addressable specifications, making most specifications mandatory.
• It would require encryption of ePHI at rest and in transit, subject to limited exceptions.
• It would require multi-factor authentication, again with limited exceptions.
• It would require network segmentation.
• It would set explicit testing intervals, including vulnerability scanning at least every six months and penetration testing at least once every twelve months.

In a joint stakeholder letter dated December 8, 2025, a coalition of more than 100 hospital systems, provider organizations, and healthcare associations, led by the College of Healthcare Information Management Executives (CHIME), asked HHS to withdraw the proposal and instead work with providers on a flexible, risk-based framework. Named signatories include Cleveland Clinic, Yale New Haven Health System, Advocate Health, the American Medical Association, and the American Academy of Pediatrics. The letter argued the rule would impose substantial financial burden and an unrealistic implementation timeline, particularly on smaller and rural organizations.

The right way to read all of this is that the controls the proposal would mandate, encryption, multi-factor authentication, asset inventory, and regular testing, are reasonable security practices in 2026 whether or not they are ever required by rule. OCR's current enforcement already looks for evidence of a functioning risk management program, and organizations that adopt these controls now are not gambling on a proposed rule. They are meeting the current one more defensibly.

Recognized security practices can reduce penalties

A provision most organizations overlook works in their favor. Public Law 116-321, signed January 5, 2021, amended the HITECH Act to require HHS to consider whether a regulated entity had recognized security practices in place for the prior twelve months when determining penalties, audit outcomes, and remedies for Security Rule violations. The law directs HHS to consider those practices as a mitigating factor, and it does not grant HHS authority to increase penalties for their absence.

The practical implication is that documented, sustained adoption of recognized security practices, such as the NIST Cybersecurity Framework or the practices developed under Section 405(d) of the Cybersecurity Act of 2015, can reduce exposure after an incident. The twelve-month look-back means the benefit accrues to organizations that invest before an investigation begins, not during it.

Do the safeguards apply to business associates?

Yes. Since the 2013 Omnibus Rule, business associates are directly liable for compliance with the HIPAA Security Rule, not merely contractually bound through a business associate agreement. A business associate that creates, receives, maintains, or transmits ePHI on behalf of a covered entity must implement the same administrative, physical, and technical safeguards, conduct its own risk analysis, and can be investigated and penalized by OCR independently.

The Business Associate Contracts standard at 164.308(b)(1) sits on the covered entity's side of this relationship. A covered entity must have a written contract or other arrangement with each business associate, and the agreement must flow the relevant obligations down. A signed agreement, however, does not discharge the covered entity's duty to assess the vendor's actual security, and it does not shrink the business associate's independent obligation to comply.

Frequently asked questions

What are the three types of HIPAA Security Rule safeguards?

Administrative safeguards (45 CFR 164.308), physical safeguards (45 CFR 164.310), and technical safeguards (45 CFR 164.312). Administrative safeguards cover policies, procedures, and workforce management. Physical safeguards protect facilities and devices. Technical safeguards control system access to ePHI and protect it in transit. All three apply to every covered entity and business associate.

Is encryption required under the HIPAA Security Rule?

No. Encryption is addressable, not required, and it appears twice that way: at 164.312(a)(2)(iv) for data at rest and at 164.312(e)(2)(ii) for data in transit. Addressable means an organization must implement it, implement an equivalent measure, or document why neither is reasonable and appropriate. On internet-facing systems and portable devices, that justification is difficult to sustain.

What is the difference between required and addressable implementation specifications?

A required specification must be implemented as written, under 45 CFR 164.306(d)(2). An addressable specification, under 164.306(d)(3), must be implemented as written, satisfied by an equivalent alternative, or formally documented as not reasonable and appropriate with an equivalent measure in place where protection is still needed. Addressable does not mean optional.

How often does a HIPAA risk analysis need to be updated?

The Security Rule requires an ongoing process rather than a fixed interval, and 164.308(a)(8) calls for evaluation in response to environmental or operational changes. An annual cycle is the practical norm, and updates are required when new systems are deployed, after mergers or relocations, and following significant security incidents. Providers attesting for Promoting Interoperability must conduct or review one each reporting period. Our guide to conducting a HIPAA risk assessment covers scope and cadence in detail.

Does the HIPAA Security Rule apply to business associates?

Yes. Since the 2013 Omnibus Rule, business associates are directly liable for Security Rule compliance and can be investigated and penalized by OCR independently of the covered entity. A business associate must implement the same administrative, physical, and technical safeguards and conduct its own risk analysis.

How long must HIPAA documentation be retained?

Under 45 CFR 164.316(b)(2)(i), documentation must be retained for six years from the date of its creation or the date it last was in effect, whichever is later. This applies to policies, procedures, risk analyses, and the documentation of addressable-specification decisions.

Is multi-factor authentication required under HIPAA?

Not under the current Security Rule. MFA is not named as a required specification in the rule as in force in 2026. The proposed rule published January 6, 2025 would, if finalized as proposed, require it with limited exceptions. As a practical matter, MFA is widely treated as a baseline control and is commonly expected by cyber insurers and during OCR investigations.

What is the difference between the HIPAA Security Rule and the Privacy Rule?

The Security Rule (45 CFR Part 164, Subpart C) governs the protection of ePHI specifically, through administrative, physical, and technical safeguards. The Privacy Rule (Subpart E) governs the use and disclosure of all protected health information, in any form, including paper and oral. The Security Rule is a subset focused on electronic protection; the Privacy Rule is broader.

Building a defensible HIPAA Security program

The organizations that struggle with the Security Rule usually do not struggle for lack of knowing what it says. They struggle to demonstrate it. Most organizations in the 50-to-1,000-employee range can produce a risk analysis document. Far fewer can show a continuous risk management program behind it: remediation tracked to closure, system activity actually reviewed rather than merely logged, evaluations performed after material changes to the environment, and documentation current and retrievable when OCR asks.

That gap is where findings originate, and it is a staffing problem more often than a knowledge problem. The requirements are legible. Sustaining them across a rural critical access hospital or a multi-site specialty group, quarter after quarter, alongside everything else an internal team carries, is the hard part.

Mandry Technology works with healthcare organizations in Texas and adjacent states to build and sustain that program, mapping administrative, physical, and technical safeguards to the evidence OCR and cyber insurers actually inspect, under SOC 2 Type II operating discipline. If you want to know whether your safeguards would hold up under review, request an assessment.

Last reviewed: July 2026

Sources

• HIPAA Security Rule, 45 CFR Part 164 Subpart C, verified against eCFR: 164.306, 164.308, 164.310, 164.312, 164.316
• HIPAA Privacy Rule, 45 CFR Part 164 Subpart E
• HHS OCR, Notice of Proposed Rulemaking to strengthen the cybersecurity of ePHI, 90 FR 898, published January 6, 2025, RIN 0945-AA22. Proposed; comment period closed March 7, 2025. HHS fact sheet
• OMB Unified Agenda, RIN 0945-AA22. Final action targeted July 2027; projection, not binding
• CHIME-led joint stakeholder letter to HHS, December 8, 2025, coalition of 100 or more providers seeking withdrawal
• Public Law 116-321, January 5, 2021, HITECH amendment on recognized security practices
• HHS OCR, Guidance on Risk Analysis Requirements under the HIPAA Security Rule
• NIST SP 800-66 Revision 2, February 2024