What it does. Implement the HIPAA Security Rule (45 CFR Part 164 Subpart C) to protect electronic protected health information (ePHI): conduct the required risk analysis, deploy the administrative, physical, and technical safeguards, handle required vs addressable implementation specifications, execute Business Associate Agreements, and stand up breach-notification readiness. Use when an organization is a HIPAA covered entity or business associate, when protecting ePHI, when preparing for an OCR audit or responding to a breach, when performing a HIPAA Security Risk Analysis, when drafting or reviewing a BAA, or when mapping security controls to the §164.308/310/312/314/316 safeguards. Notes the 2025 NPRM proposed changes (not yet final). Keywords: HIPAA, HIPAA Security Rule, ePHI, PHI, 45 CFR 164, risk analysis, administrative safeguards, physical safeguards, technical safeguards, addressable, required, Business Associate Agreement, BAA, OCR, breach notification, HITECH, covered entity, business associate. Part of mukul975/Anthropic-Cybersecurity-Skills (817 security skills) (mukul975/Anthropic-Cybersecurity-Skills).

Upstream	mukul975/Anthropic-Cybersecurity-Skills
Skill file	skills/implementing-hipaa-security-rule-safeguards/SKILL.md
License	Apache-2.0 (skill folder LICENSE)
Author	mukul975
Fetched	2026-09-10

Install

• npx skills add mukul975/Anthropic-Cybersecurity-Skills --skill implementing-hipaa-security-rule-safeguards, or copy the skill folder into ~/.claude/skills/implementing-hipaa-security-rule-safeguards/.
• Raw file: curl -sL https://raw.githubusercontent.com/mukul975/Anthropic-Cybersecurity-Skills/HEAD/skills/implementing-hipaa-security-rule-safeguards/SKILL.md

SKILL.md (verbatim)

name: implementing-hipaa-security-rule-safeguards
description: >-
  Implement the HIPAA Security Rule (45 CFR Part 164 Subpart C) to protect electronic
  protected health information (ePHI): conduct the required risk analysis, deploy the
  administrative, physical, and technical safeguards, handle required vs addressable
  implementation specifications, execute Business Associate Agreements, and stand up
  breach-notification readiness. Use when an organization is a HIPAA covered entity or
  business associate, when protecting ePHI, when preparing for an OCR audit or responding
  to a breach, when performing a HIPAA Security Risk Analysis, when drafting or reviewing a
  BAA, or when mapping security controls to the §164.308/310/312/314/316 safeguards. Notes
  the 2025 NPRM proposed changes (not yet final). Keywords: HIPAA, HIPAA Security Rule,
  ePHI, PHI, 45 CFR 164, risk analysis, administrative safeguards, physical safeguards,
  technical safeguards, addressable, required, Business Associate Agreement, BAA, OCR,
  breach notification, HITECH, covered entity, business associate.
domain: cybersecurity
subdomain: compliance-governance
tags:
- hipaa
- hipaa-security-rule
- ephi
- phi
- 45-cfr-164
- risk-analysis
- baa
- breach-notification
- ocr
- compliance
- governance
version: "1.0"
author: andrewibrah
license: Apache-2.0
nist_csf:
- GV.OC-03
- GV.RM-01
- ID.RA-01
- ID.RA-05
- PR.DS-01
- PR.AA-01
- DE.CM-01
mitre_attack:
- T1078
- T1566
- T1486
- T1530
- T1048

Implementing HIPAA Security Rule Safeguards

When to Use

• When an organization is a covered entity (health plan, clearinghouse, or provider transmitting electronic transactions) or a business associate handling ePHI on their behalf.
• When standing up or maturing controls to protect electronic protected health information.
• When performing the mandatory HIPAA Security Risk Analysis (§164.308(a)(1)(ii)(A)) — the single most-cited gap in OCR enforcement.
• When preparing for an OCR audit/investigation or responding to a suspected breach.
• When drafting, reviewing, or remediating a Business Associate Agreement (BAA).
• When mapping existing security controls to the HIPAA safeguard standards and implementation specifications.

Scope note: this skill covers the Security Rule (ePHI). The Privacy Rule (uses/disclosures of all PHI) and the Breach Notification Rule are related but distinct; this skill touches breach readiness and BAAs where they intersect security.

Prerequisites

• A clear determination of the organization's role (covered entity vs business associate) and where ePHI lives, flows, and is stored (an ePHI data map).
• An asset inventory of systems that create, receive, maintain, or transmit ePHI.
• Knowledge of the current rule's structure (45 CFR §§164.302–318) and the required vs addressable distinction.
• Awareness that a 2025 NPRM proposes significant changes (see Workflow step 7 and references/standards.md) — track but do not assume them as in force.

Workflow

1. Conduct the Security Risk Analysis (§164.308(a)(1)(ii)(A))

This is required and foundational. Inventory ePHI and systems, identify threats and vulnerabilities, assess current controls, determine likelihood and impact, and assign risk levels. (Pair with the NIST 800-30 methodology and HHS's SRA Tool.) Output is a documented, dated risk analysis — the artifact OCR asks for first.

2. Implement Administrative Safeguards (§164.308)

The largest section. Includes the Security Management Process (risk analysis, risk management, sanction policy, information-system activity review), assigned security responsibility (a named Security Official), workforce security, information access management, security awareness and training, security incident procedures, contingency planning (data backup, disaster recovery, emergency-mode operation), evaluation, and BAAs with business associates.

3. Implement Physical Safeguards (§164.310)

Facility access controls, workstation use and workstation security, and device and media controls (disposal, media re-use, accountability, data backup and storage).

4. Implement Technical Safeguards (§164.312)

Access control (unique user ID, emergency access, automatic logoff, encryption/decryption), audit controls, integrity (mechanisms to authenticate ePHI), person/entity authentication, and transmission security (integrity controls + encryption).

5. Resolve "Required" vs "Addressable" specifications

Under the current rule, each implementation specification is Required (must implement) or Addressable (assess whether reasonable and appropriate; if so implement, if not document why and implement an equivalent alternative). Addressable does not mean optional — it means make and document a risk-based decision.

6. Execute Business Associate Agreements (§164.314 / §164.308(b))

Every business associate that touches ePHI needs a BAA binding it to safeguard ePHI, report incidents, and flow requirements to subcontractors. Maintain the BAA inventory.

7. Track the 2025 NPRM proposed changes (NOT yet final)

HHS OCR published an NPRM (Jan 6, 2025) proposing to remove the required/addressable distinction (make nearly all specifications required), and to mandate MFA, encryption of ePHI at rest and in transit, asset inventory and network maps, vulnerability scans every 6 months, annual penetration testing, 72-hour restoration of certain systems/data, and annual risk-analysis updates. These are proposals — the current rule remains in force until a final rule is published and effective. Plan toward them, but comply with what is current.

8. Stand up breach-notification readiness (45 CFR §§164.400–414)

Define how you detect, assess (the four-factor risk assessment), and report breaches of unsecured PHI: to individuals and HHS (and media for breaches affecting 500+ in a state/jurisdiction), within the required timelines. Encryption to NIST standards renders PHI "secured" and is a safe harbor from breach notification.

9. Document everything (§164.316)

Maintain policies, procedures, and records of actions/decisions in writing, retain for six years, review periodically, and update in response to environmental or operational change.

Key Concepts

Concept	Definition
ePHI	Electronic protected health information — the Security Rule's scope.
Covered entity	Health plan, clearinghouse, or provider doing electronic transactions.
Business associate	A vendor that handles ePHI for a covered entity; bound by a BAA.
Risk analysis	Required, documented assessment of risks to ePHI (§164.308(a)(1)(ii)(A)).
Required vs addressable	Must-implement vs risk-based-decision implementation specifications.
Administrative / Physical / Technical safeguards	§164.308 / §164.310 / §164.312.
BAA	Business Associate Agreement — contractually binds vendors to safeguard ePHI.
Breach (unsecured PHI)	Triggers notification under §§164.400–414; encryption is a safe harbor.
OCR	HHS Office for Civil Rights — enforces HIPAA.
Six-year retention	Documentation retention requirement (§164.316).

Tools & Systems

• 45 CFR Part 164 Subpart C — the Security Rule text (and Subpart D, Breach Notification).
• HHS Security Risk Assessment (SRA) Tool — free guided risk analysis.
• NIST SP 800-66 Rev 2 — implementing the HIPAA Security Rule (NIST guidance, maps to 800-53).
• NIST SP 800-30 — risk-assessment methodology to ground the SRA.
• GRC / compliance platforms — to manage policies, the BAA inventory, and evidence.
• Encryption / MFA / SIEM / audit-logging tooling — to satisfy technical safeguards and the proposed mandates.

Common Scenarios

• OCR investigation after a breach. First request is almost always the current, dated risk analysis and the risk-management plan — have them ready.
• New SaaS handling ePHI. Sign a BAA before any ePHI flows; confirm the vendor's safeguards.
• Addressable spec you won't implement as written. Document the risk-based rationale and the equivalent alternative you implemented instead.
• Preparing for the proposed rule. Pre-position MFA, at-rest/in-transit encryption, asset inventory, scanning, and pen-testing so a final rule is a small step, not a scramble.
• Lost/stolen device. If ePHI was encrypted to NIST standards, the safe harbor applies; if not, run the four-factor breach assessment and notify as required.

Output Format

Produce a HIPAA Security Rule Gap Assessment using assets/template.md, containing:

1. Role & ePHI scope — covered entity vs BA; ePHI data map and systems.
2. Risk analysis summary — top risks to ePHI with likelihood/impact (feeds risk management).
3. Safeguard status — Administrative / Physical / Technical, each specification marked Implemented / Partial / Gap with required-vs-addressable noted.
4. BAA inventory — business associates and BAA status.
5. Breach-notification readiness — detection, four-factor assessment, notification workflow.
6. 2025 NPRM gap view — readiness against the proposed mandates (clearly labeled proposed).
7. Remediation plan — prioritized, with owners and dates; required specs and risk-analysis gaps first.

Use scripts/process.py to score a safeguard-status JSON across the §164.308/310/312 standards, weight required gaps above addressable ones, and emit the gap table plus a remediation-priority list.

Other files in this skill

• LICENSE
• assets/template.md
• references/standards.md
• scripts/process.py

assets/template.md (verbatim)

HIPAA Security Rule Gap Assessment — Worked Example

Filled example for a small outpatient clinic (covered entity). Replace bracketed content for your own organization.

1. Role & ePHI Scope

• Role: Covered Entity (outpatient provider doing electronic transactions).
• ePHI locations: EHR SaaS, the clinic's clearing workstation, encrypted backups, and a billing vendor (business associate).
• ePHI data map: Patient intake → EHR (SaaS, BAA in place) → claims to billing BA → encrypted backup. Reference diagram ephi-flow-v2.

2. Risk Analysis Summary (feeds Risk Management)

Top risk to ePHI	Likelihood	Impact	Note
Phishing → EHR credential theft	High	High	No MFA on remote EHR access
Lost/stolen laptop with cached ePHI	Moderate	High	Disk encryption not enforced fleet-wide
Billing BA mishandles ePHI	Low	High	BAA present; vendor safeguards unverified

The risk analysis is dated and documented — this is the first artifact OCR requests.

3. Safeguard Status

(scored by scripts/process.py; weighted readiness ≈ 62% in this example)

Specification	Section	Requirement	Status	Alt. documented
164.308(a)(1)(ii)(A) Risk Analysis	Administrative	required	gap	—
164.308(a)(1)(ii)(B) Risk Management	Administrative	required	partial	—
164.308(a)(2) Assigned Security Responsibility	Administrative	required	implemented	—
164.310(d)(2)(i) Disposal	Physical	required	implemented	—
164.312(a)(1) Unique User ID	Technical	required	implemented	—
164.312(a)(2)(iv) Encryption/Decryption	Technical	addressable	partial	no
164.312(a)(2)(iii) Automatic Logoff	Technical	addressable	gap	yes (equivalent timeout via MDM documented)

OCR-priority flag: Risk Analysis is a gap → remediate first.

4. BAA Inventory

Business associate	Service	BAA status
EHR SaaS vendor	Records system	Signed, current
Billing vendor	Claims processing	Signed; request SOC 2 / safeguards attestation
Backup provider	Encrypted offsite backup	Signed, current

5. Breach-Notification Readiness (§§164.400–414)

• Detection: EHR + endpoint alerts route to the Security Official.
• Assessment: Documented four-factor procedure to decide whether a breach of unsecured PHI occurred.
• Notification workflow: Individuals within 60 days; HHS (annual log for <500, prompt for 500+); media for 500+ in-jurisdiction.
• Safe harbor: Enforce NIST-standard encryption so lost/stolen encrypted devices are "secured" and exempt from notification.

6. 2025 NPRM Gap View (PROPOSED — not yet final)

Proposed mandate	Current state	Pre-position action
Mandatory MFA	Not enforced	Roll out MFA on all ePHI access
Encryption at rest & in transit	Partial	Enforce full-disk + TLS everywhere
Asset inventory + network map	Informal	Formalize and keep current
Vuln scans every 6 mo / annual pentest	Ad hoc	Schedule recurring scans + annual test
72-hour restoration	Untested	Add RTO target + restore drills
Annual risk-analysis update	Irregular	Calendar annual refresh

These are proposals; comply with the current rule today and treat this column as a readiness runway.

7. Remediation Plan (prioritized)

1. Risk Analysis (164.308(a)(1)(ii)(A)) — required gap, OCR-priority. Complete and date a full SRA (use HHS SRA Tool + NIST 800-30). Owner: Security Official. Due: 30 days.
2. Risk Management (164.308(a)(1)(ii)(B)) — required, partial. Build the remediation plan that flows from the SRA. Due: 45 days.
3. Encryption (164.312(a)(2)(iv)) — addressable, partial. Enforce full-disk + in-transit encryption (also clears NPRM + breach safe harbor). Due: 60 days.
4. Verify the billing BA's safeguards (request SOC 2). Due: 60 days.
5. Re-run the scorer after each fix; target ≥ 95% weighted readiness with zero required gaps.

references/standards.md (verbatim)

HIPAA Security Rule — Standards & Reference

Primary regulation

HIPAA Security Rule — 45 CFR Part 164, Subpart C

• Regulator: U.S. Department of Health and Human Services, Office for Civil Rights (OCR)
• Scope: Security of electronic protected health information (ePHI) held or transmitted by covered entities and business associates.
• Statutory basis: HIPAA (1996) as amended by HITECH (2009).
• eCFR: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C

Rule structure (key sections)

Section	Title
§164.302	Applicability
§164.304	Definitions
§164.306	Security standards: general rules (flexibility, scalability)
§164.308	Administrative safeguards
§164.310	Physical safeguards
§164.312	Technical safeguards
§164.314	Organizational requirements (BAAs, group health plans)
§164.316	Policies, procedures, and documentation (6-year retention)

Breach Notification Rule: 45 CFR §§164.400–414 (Subpart D).

Administrative safeguards (§164.308) — standards

• Security Management Process — Risk Analysis (R), Risk Management (R), Sanction Policy (R), Information System Activity Review (R)
• Assigned Security Responsibility (named Security Official)
• Workforce Security (authorization/supervision, clearance, termination — Addressable)
• Information Access Management (isolating clearinghouse functions (R); access authorization/establishment/modification — Addressable)
• Security Awareness and Training (reminders, malware protection, log-in monitoring, password management — Addressable)
• Security Incident Procedures — Response and Reporting (R)
• Contingency Plan — Data Backup Plan (R), Disaster Recovery Plan (R), Emergency Mode Operation Plan (R), Testing/Revision (A), Applications/Data Criticality Analysis (A)
• Evaluation (periodic)
• Business Associate Contracts (§164.308(b))

Physical safeguards (§164.310) — standards

• Facility Access Controls (contingency operations, facility security plan, access control/validation, maintenance records — all Addressable)
• Workstation Use (R)
• Workstation Security (R)
• Device and Media Controls — Disposal (R), Media Re-use (R), Accountability (A), Data Backup and Storage (A)

Technical safeguards (§164.312) — standards

• Access Control — Unique User Identification (R), Emergency Access Procedure (R), Automatic Logoff (A), Encryption and Decryption (A)
• Audit Controls (R)
• Integrity — Mechanism to Authenticate ePHI (A)
• Person or Entity Authentication (R)
• Transmission Security — Integrity Controls (A), Encryption (A)

(R) = Required, (A) = Addressable, under the current rule.

Required vs Addressable

• Required: must be implemented as specified.
• Addressable: assess whether the specification is reasonable and appropriate; if yes, implement; if no, document why and implement an equivalent alternative measure if reasonable. Addressable is not optional.

Breach Notification (45 CFR §§164.400–414)

• Applies to breaches of unsecured PHI.
• Four-factor risk assessment to determine whether a breach occurred (nature/extent of PHI, who used/received it, whether it was actually acquired/viewed, mitigation).
• Notify individuals without unreasonable delay and within 60 days; notify HHS (annually for <500; without unreasonable delay and within 60 days for 500+); notify media for breaches affecting 500+ residents of a state/jurisdiction.
• Safe harbor: PHI encrypted to HHS/NIST-specified standards is "secured" and not subject to breach notification.

2025 NPRM — PROPOSED changes (NOT yet final)

• Citation: 90 FR 800, RIN 0945-AA22, published January 6, 2025; comment period closed March 7, 2025.
• Status: Proposed only. The current Security Rule remains in force until a final rule is published and becomes effective. Track at https://www.federalregister.gov.
• Notable proposals:
  • Remove the required/addressable distinction — make (nearly) all implementation specifications required.
  • Mandatory multi-factor authentication.
  • Mandatory encryption of ePHI at rest and in transit.
  • Asset inventory and network maps, updated regularly.
  • Vulnerability scans at least every 6 months and penetration testing at least annually.
  • 72-hour restoration of certain systems/data after an incident.
  • Annual risk-analysis updates and written documentation of compliance reviews.
• Typical effective/compliance timing if finalized: effective ~60 days after publication; compliance ~180 days after effective (subject to the final rule).

Supporting NIST guidance

Document	Role
NIST SP 800-66 Rev 2 (2024)	Implementing the HIPAA Security Rule; maps safeguards to SP 800-53 controls.
NIST SP 800-30 Rev 1	Risk-assessment methodology underpinning the required risk analysis.
HHS SRA Tool	Free guided Security Risk Assessment for smaller organizations.

NIST CSF 2.0 alignment

CSF 2.0 ID	Relevance
GV.OC-03	Legal/regulatory (HIPAA) requirements understood.
GV.RM-01	Risk-management objectives established.
ID.RA-01 / ID.RA-05	Vulnerabilities identified; risk informs prioritization (the risk analysis).
PR.DS-01	Data-at-rest protection (encryption of ePHI).
PR.AA-01	Identity/authentication (unique IDs, MFA).
DE.CM-01	Monitoring (audit controls, activity review).

Back to mukul975/Anthropic-Cybersecurity-Skills (817 security skills) or Agent skills.