HIPAA Security Rule
U.S. Department of Health and Human Services · Version 1996 / 2013 Omnibus · 2003 (Security Rule effective); 2013 (Omnibus update)
Federal law governing the security and privacy of protected health information in the United States.
Overview
HIPAA, the Health Insurance Portability and Accountability Act of 1996, established national standards for the protection of individually identifiable health information. The law includes three primary rules relevant to information security: the Privacy Rule, which governs the use and disclosure of Protected Health Information; the Security Rule, which requires administrative, physical, and technical safeguards for electronic PHI; and the Breach Notification Rule, added by the HITECH Act of 2009, which requires covered entities to notify affected individuals, HHS, and in some cases the media following a breach of unsecured PHI. Covered entities include health plans, healthcare providers, and healthcare clearinghouses.
The Security Rule's safeguards contain both Required and Addressable specifications. Required specifications must be implemented exactly as stated. Addressable specifications must be implemented if reasonable and appropriate, or the entity must document why they are not implementing them and what equivalent alternative they have adopted instead. This distinction is frequently misunderstood. Addressable does not mean optional. The Security Rule also applies to Business Associates, entities that create, receive, maintain, or transmit ePHI on behalf of a covered entity. Business Associate Agreements are required contracts that define each party's responsibilities.
Who Needs This
Hospitals, physician practices, health plans, and healthcare clearinghouses as covered entities
Technology vendors, billing companies, and cloud providers handling ePHI as business associates
Health IT companies building software that accesses, processes, or stores ePHI
Health system business associates including legal, audit, and consulting firms with ePHI access
Any organization entering into Business Associate Agreements with HIPAA covered entities
Structure at a Glance
Risk analysis, risk management, sanction policy, information system activity review, assigned security responsibility, workforce training, access management, contingency planning, and evaluation.
Facility access controls, workstation use policies, workstation security, and device and media controls.
Access control, audit controls, integrity controls, authentication, and transmission security.
Business Associate Agreement requirements and requirements for group health plans.
AI Prompt Recipes
Copy these prompts directly into Claude or any capable model. Replace the bracketed placeholders with your organization-specific details.
Risk Analysis (§164.308(a)(1))
Use this for the required HIPAA Security Rule risk analysis, which HHS OCR audits first.
You are a HIPAA Security Rule specialist. I need to conduct a risk analysis as required by §164.308(a)(1)(ii)(A). My organization is a [TYPE OF COVERED ENTITY OR BUSINESS ASSOCIATE]. We handle ePHI in the following systems: [LIST SYSTEMS AND DATA FLOWS]. Threats identified include: [LIST KNOWN THREATS]. Help me: (1) structure a complete risk analysis methodology that satisfies HHS OCR's seven required elements, (2) evaluate the likelihood and impact of each threat against each system, (3) produce a risk register with residual risk ratings, and (4) identify the top five safeguard gaps relative to the identified risks.
Business Associate Agreement Review
Use this to evaluate whether a proposed BAA meets HIPAA requirements.
Review the following Business Associate Agreement for HIPAA compliance: [PASTE BAA TEXT OR SUMMARIZE KEY PROVISIONS]. The BAA is between [COVERED ENTITY TYPE] and [BUSINESS ASSOCIATE TYPE]. The BA will handle ePHI by: [DESCRIBE FUNCTION]. Evaluate: (1) whether the BAA contains all required elements under §164.308(b) and §164.504(e), (2) specific gaps or ambiguous provisions, (3) whether subcontractor provisions are adequate, and (4) recommended revisions with exact contract language.
Technical Safeguard Assessment
Use this to assess conformance with the Technical Safeguards section.
Assess my organization's HIPAA Technical Safeguards compliance under §164.312. For each of the five technical safeguard standards — Access Control, Audit Controls, Integrity, Authentication, and Transmission Security — evaluate our current implementation: [DESCRIBE CURRENT TECHNICAL CONTROLS FOR EACH]. For each standard, identify: whether Required specifications are met, whether Addressable specifications are implemented or have documented alternatives, the evidence an HHS OCR auditor would request, and specific remediation for any gaps.
Breach Risk Assessment
Use this after a security incident to determine whether breach notification is required.
I need to conduct a HIPAA breach risk assessment following a security incident. Incident description: [DESCRIBE WHAT HAPPENED]. PHI involved: [DESCRIBE TYPE AND VOLUME OF PHI]. Parties who may have accessed it: [DESCRIBE]. Using the four-factor test from the HITECH Breach Notification Rule, analyze: (1) the nature and extent of the PHI involved including identifiers and likelihood of re-identification, (2) the identity of the unauthorized person who accessed the PHI, (3) whether the PHI was actually acquired or viewed, and (4) the extent to which the risk has been mitigated. Conclude with a breach or no-breach determination and the notification obligations triggered.
Common Pitfalls
These are the mistakes practitioners see repeatedly in real assessments and implementation projects.
Treating Addressable specifications as optional. HHS OCR audits have repeatedly cited organizations for not documenting why they did not implement an addressable specification or what equivalent alternative they adopted.
Risk analysis conducted once and never updated. HHS requires risk analysis to be ongoing, not a point-in-time exercise. Every significant change to the environment — new system, new vendor, new location — triggers a reassessment.
BAAs signed without verifying that the BA actually has security controls. Signing a BAA creates contractual protection but does not reduce your organization's risk if the BA has a breach.
Workforce training treated as a once-per-year checkbox. The Security Rule requires training that reflects the actual threats the workforce faces. Generic annual training on HIPAA basics does not satisfy §164.308(a)(5).
Failing to include encryption as the primary method to render PHI unusable. If ePHI is encrypted in accordance with HHS guidance, a breach involving that data does not trigger notification. Organizations that skip encryption lose this safe harbor.
Cross-Framework Mapping
SOC 2
Healthcare SaaS vendors often pursue SOC 2 Security simultaneously with HIPAA. SOC 2 addresses the technical safeguards with more detailed control testing, which supports HIPAA audit readiness.
View Detailed Mapping ↗ISO 27001
ISO 27001 Annex A Technological Controls address most HIPAA Technical Safeguard requirements. A certified organization has a head start but must still complete HIPAA-specific documentation.
View Detailed Mapping ↗NIST CSF 2.0
HHS OCR references NIST CSF in its cybersecurity guidance for healthcare. The Protect and Respond functions align with HIPAA's safeguard categories.
View Detailed Mapping ↗All content sourced from official issuing body documentation.
Official source ↗