hipaa-risk-analysis-conductor

By Agentman

Conduct HIPAA Security Rule risk analysis as required by 45 CFR 164.308(a)(1). Provides methodology for identifying ePHI assets, assessing threats and vulnerabilities, scoring risks, and developing risk management plans. Use when performing annual risk analysis, after significant changes, or preparing for OCR audit.

Healthcarev50 views5 uses
HIPAAsecurityrisk-analysiscomplianceePHIauditOCRprivacydocumentation

Skill Instructions

# HIPAA Risk Analysis Conductor

## Overview

The HIPAA Security Rule requires covered entities to conduct an accurate and thorough assessment of potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. This skill provides the methodology, frameworks, and documentation templates to execute compliant risk analysis.

## Legal Requirement

```
45 CFR § 164.308(a)(1)(ii)(A) - Risk Analysis (Required)
"Conduct an accurate and thorough assessment of the potential risks 
and vulnerabilities to the confidentiality, integrity, and availability 
of electronic protected health information held by the covered entity 
or business associate."
```

**Key Points:**
- Required, not addressable
- Must be "accurate and thorough"
- Must be documented
- Documentation retained 6 years (45 CFR § 164.316)
- Must be updated when changes occur

## Risk Analysis Workflow

```
┌─────────────────────────────────────────────────────────────────┐
│                    RISK ANALYSIS PROCESS                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  STEP 1         STEP 2         STEP 3         STEP 4           │
│  ────────       ────────       ────────       ────────          │
│  Scope &        Asset          Threat &       Risk              │
│  Inventory      Analysis       Vulnerability  Assessment        │
│                                                                 │
│       │              │              │              │            │
│       ▼              ▼              ▼              ▼            │
│                                                                 │
│  STEP 5         STEP 6         STEP 7         STEP 8           │
│  ────────       ────────       ────────       ────────          │
│  Risk           Risk Mgmt      Document       Review &          │
│  Scoring        Plan           Everything     Monitor           │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
```

## Step 1: Define Scope and ePHI Inventory

### Scope Definition

Document the boundaries of the analysis:

```
SCOPE DOCUMENTATION
───────────────────
Organization: {legal_name}
Locations covered: {list all physical locations}
Systems covered: {all systems that create, receive, maintain, transmit ePHI}
Workforce covered: {all workforce members with ePHI access}
Business associates: {list BAs with ePHI access}
Date of analysis: {date}
Analysis conducted by: {name/title}
```

### ePHI Asset Inventory

Identify ALL locations where ePHI exists:

| Asset Category | Examples | Document |
|----------------|----------|----------|
| **Electronic Systems** | EHR, PM system, lab system, imaging | System name, vendor, location |
| **Workstations** | Desktop, laptop, tablet | Device ID, location, user |
| **Mobile Devices** | Phones, tablets with ePHI access | Device type, owner, MDM status |
| **Servers** | On-premise, cloud-hosted | Location, hosting provider |
| **Network Equipment** | Routers, firewalls, switches | Device, location, config |
| **Removable Media** | USB drives, external drives, CDs | Policy on use |
| **Email** | Email systems with PHI | Provider, encryption status |
| **Backup Systems** | Backup tapes, cloud backup | Location, encryption status |
| **Paper → Electronic** | Scanned documents, faxes | Workflow, storage location |

### Asset Inventory Template

```
ASSET ID: {unique_id}
Asset Name: {name}
Asset Type: {system/device/media/network}
Description: {what it does}
ePHI Types: {what PHI it contains}
Location: {physical/cloud location}
Owner: {responsible person/dept}
Users: {who has access}
Criticality: {High/Medium/Low}
Current Safeguards: {existing protections}
```

## Step 2: Identify Threats and Vulnerabilities

### Threat Categories

| Category | Examples |
|----------|----------|
| **Natural** | Flood, fire, earthquake, tornado, power outage |
| **Human - Intentional** | Hacking, malware, ransomware, social engineering, insider theft |
| **Human - Unintentional** | Misdirected email/fax, lost device, improper disposal, misconfiguration |
| **Environmental** | HVAC failure, water damage, electrical issues |
| **Technical** | System failure, software bugs, hardware failure, network outage |

### Common Healthcare Vulnerabilities

| Vulnerability | Description | Check |
|---------------|-------------|-------|
| **Lack of encryption** | ePHI at rest or in transit unencrypted | □ |
| **Weak access controls** | Shared passwords, no MFA, excessive privileges | □ |
| **No audit logging** | Cannot detect unauthorized access | □ |
| **Unpatched systems** | Known vulnerabilities not remediated | □ |
| **No backup/DR** | Cannot recover from data loss | □ |
| **Physical security gaps** | Unlocked areas, no visitor controls | □ |
| **Workforce training gaps** | Staff unaware of policies/risks | □ |
| **No BAAs** | Vendors accessing PHI without agreements | □ |
| **Improper disposal** | Devices/media not sanitized | □ |
| **Mobile device risks** | Unmanaged devices, no remote wipe | □ |

### Threat-Vulnerability Pairing

For each asset, document applicable threat-vulnerability pairs:

```
ASSET: {asset_name}

THREAT-VULNERABILITY PAIRS:
┌─────────────────────┬──────────────────────┬──────────────────────┐
│ Threat              │ Vulnerability        │ Potential Impact     │
├─────────────────────┼──────────────────────┼──────────────────────┤
│ Ransomware attack   │ Unpatched OS         │ Loss of availability │
│ Lost laptop         │ No encryption        │ Breach of PHI        │
│ Misdirected email   │ No DLP controls      │ Unauthorized access  │
│ Terminated employee │ No access revocation │ Unauthorized access  │
└─────────────────────┴──────────────────────┴──────────────────────┘
```

## Step 3: Assess Current Security Measures

### Security Rule Safeguard Mapping

Evaluate current state against required/addressable safeguards:

#### Administrative Safeguards (§164.308)

| Standard | Implementation | Status | Gap |
|----------|----------------|--------|-----|
| Risk Analysis | 164.308(a)(1)(ii)(A) | {Y/N/Partial} | {gap description} |
| Risk Management | 164.308(a)(1)(ii)(B) | {Y/N/Partial} | {gap description} |
| Sanction Policy | 164.308(a)(1)(ii)(C) | {Y/N/Partial} | {gap description} |
| Info System Activity Review | 164.308(a)(1)(ii)(D) | {Y/N/Partial} | {gap description} |
| Workforce Security | 164.308(a)(3) | {Y/N/Partial} | {gap description} |
| Access Management | 164.308(a)(4) | {Y/N/Partial} | {gap description} |
| Security Awareness Training | 164.308(a)(5) | {Y/N/Partial} | {gap description} |
| Security Incident Procedures | 164.308(a)(6) | {Y/N/Partial} | {gap description} |
| Contingency Plan | 164.308(a)(7) | {Y/N/Partial} | {gap description} |
| Evaluation | 164.308(a)(8) | {Y/N/Partial} | {gap description} |
| BA Contracts | 164.308(b)(1) | {Y/N/Partial} | {gap description} |

#### Physical Safeguards (§164.310)

| Standard | Implementation | Status | Gap |
|----------|----------------|--------|-----|
| Facility Access Controls | 164.310(a)(1) | {Y/N/Partial} | {gap description} |
| Workstation Use | 164.310(b) | {Y/N/Partial} | {gap description} |
| Workstation Security | 164.310(c) | {Y/N/Partial} | {gap description} |
| Device/Media Controls | 164.310(d)(1) | {Y/N/Partial} | {gap description} |

#### Technical Safeguards (§164.312)

| Standard | Implementation | Status | Gap |
|----------|----------------|--------|-----|
| Access Control | 164.312(a)(1) | {Y/N/Partial} | {gap description} |
| Audit Controls | 164.312(b) | {Y/N/Partial} | {gap description} |
| Integrity Controls | 164.312(c)(1) | {Y/N/Partial} | {gap description} |
| Authentication | 164.312(d) | {Y/N/Partial} | {gap description} |
| Transmission Security | 164.312(e)(1) | {Y/N/Partial} | {gap description} |

## Step 4: Determine Likelihood and Impact

### Likelihood Scale

| Rating | Score | Definition |
|--------|-------|------------|
| **High** | 3 | Threat source is highly motivated and capable; controls are ineffective |
| **Medium** | 2 | Threat source is motivated but controls partially effective |
| **Low** | 1 | Threat source lacks motivation or capability; controls are effective |

### Impact Scale

| Rating | Score | Definition |
|--------|-------|------------|
| **High** | 3 | Major breach, significant harm to individuals, regulatory penalties, major operational disruption |
| **Medium** | 2 | Limited breach, moderate harm, potential penalties, moderate disruption |
| **Low** | 1 | Minor incident, minimal harm, no penalties expected, minimal disruption |

### Impact Factors to Consider

- Number of individuals affected
- Sensitivity of PHI involved
- Financial harm to individuals
- Reputational harm to organization
- Regulatory/legal consequences
- Operational disruption

## Step 5: Calculate Risk Scores

### Risk Scoring Matrix

```
RISK SCORE = LIKELIHOOD × IMPACT

              │ Impact                        │
              │ Low (1)  Medium (2)  High (3) │
──────────────┼──────────────────────────────│
Likelihood    │                              │
  High (3)    │   3         6          9     │
  Medium (2)  │   2         4          6     │
  Low (1)     │   1         2          3     │
──────────────┴──────────────────────────────┘
```

### Risk Level Classification

| Score | Risk Level | Response Required |
|-------|------------|-------------------|
| 7-9 | **Critical** | Immediate action required |
| 5-6 | **High** | Action required within 30 days |
| 3-4 | **Medium** | Action required within 90 days |
| 1-2 | **Low** | Accept or address within 12 months |

### Risk Register Entry

```
RISK ID: R-{number}
Asset: {asset_name}
Threat: {threat_description}
Vulnerability: {vulnerability_description}
Existing Controls: {current_safeguards}
Likelihood: {H/M/L} ({score})
Impact: {H/M/L} ({score})
Risk Score: {calculated_score}
Risk Level: {Critical/High/Medium/Low}
Risk Response: {Mitigate/Accept/Transfer/Avoid}
Remediation Plan: {description}
Target Date: {date}
Owner: {responsible_person}
Status: {Open/In Progress/Closed}
```

## Step 6: Develop Risk Management Plan

### Risk Response Options

| Response | When to Use | Example |
|----------|-------------|---------|
| **Mitigate** | Reduce likelihood or impact | Implement encryption, add MFA |
| **Accept** | Risk is low, cost exceeds benefit | Document acceptance and rationale |
| **Transfer** | Shift risk to third party | Cyber insurance, BA agreement |
| **Avoid** | Eliminate the risk source | Stop using risky technology |

### Risk Management Plan Template

```
RISK MANAGEMENT PLAN
────────────────────

For each identified risk:

RISK ID: {id}
Risk Description: {description}
Current Risk Level: {level}
Response: {Mitigate/Accept/Transfer/Avoid}

MITIGATION ACTIONS (if mitigating):
┌────────────────────┬──────────┬───────────┬────────────┐
│ Action             │ Owner    │ Due Date  │ Status     │
├────────────────────┼──────────┼───────────┼────────────┤
│ {action_1}         │ {name}   │ {date}    │ {status}   │
│ {action_2}         │ {name}   │ {date}    │ {status}   │
└────────────────────┴──────────┴───────────┴────────────┘

ACCEPTANCE RATIONALE (if accepting):
{documented_rationale}
Approved by: {name/title}
Date: {date}

RESIDUAL RISK LEVEL: {level after mitigation}
NEXT REVIEW DATE: {date}
```

## Step 7: Document Everything

### Required Documentation

| Document | Contents | Retention |
|----------|----------|-----------|
| **Scope Document** | Boundaries, locations, systems covered | 6 years |
| **Asset Inventory** | All ePHI assets and attributes | 6 years |
| **Threat Assessment** | Identified threats by category | 6 years |
| **Vulnerability Assessment** | Identified vulnerabilities | 6 years |
| **Risk Register** | All risks with scores and responses | 6 years |
| **Risk Management Plan** | Remediation actions and timeline | 6 years |
| **Approval/Sign-off** | Management approval of analysis | 6 years |

### Documentation Best Practices

- Date all documents
- Version control (track changes over time)
- Identify authors and approvers
- Store securely (it's sensitive information)
- Make retrievable for audits

## Step 8: Review and Update Triggers

### Mandatory Review Triggers

| Trigger | Action |
|---------|--------|
| **Annual review** | Full review and update of risk analysis |
| **New technology** | Assess risks of new system/device |
| **Security incident** | Reassess related risks |
| **Regulatory change** | Evaluate impact on risk profile |
| **Significant operational change** | New location, new service, M&A |
| **Vulnerability discovered** | Update threat-vulnerability pairs |
| **Failed audit/assessment** | Address findings, update analysis |

### Continuous Monitoring

```
ONGOING ACTIVITIES:
□ Monitor security alerts and incidents
□ Track remediation progress
□ Update asset inventory as changes occur
□ Review access logs periodically
□ Test backup/recovery procedures
□ Assess new vendor risks before onboarding
□ Evaluate changes before implementation
```

## OCR Audit Preparation

### What OCR Looks For

| Evidence | Have It? |
|----------|----------|
| Documented risk analysis methodology | □ |
| Complete ePHI asset inventory | □ |
| Threat and vulnerability identification | □ |
| Risk scoring with documented rationale | □ |
| Risk management plan with timelines | □ |
| Evidence of remediation activities | □ |
| Management sign-off | □ |
| Regular review/update evidence | □ |
| 6-year retention of documentation | □ |

### Common OCR Findings

| Finding | How to Avoid |
|---------|--------------|
| No risk analysis conducted | Do the analysis, document it |
| Analysis not "thorough" | Include all assets, all threats |
| No risk management plan | Document how you'll address risks |
| Not updated after changes | Re-analyze when changes occur |
| Cannot produce documentation | Retain and organize documents |

## Resources

### references/
- **security-rule-checklist.md** — Full §164.308-312 safeguard checklist
- **threat-vulnerability-catalog.md** — Common healthcare threats and vulnerabilities
- **risk-analysis-template.md** — Fillable risk analysis document

### scripts/
- **risk-calculator.py** — Calculates risk scores from inputs

### assets/
- **risk-register-template.xlsx** — Excel risk register template
- **risk-analysis-report-template.docx** — Final report template

Included Files

  • SKILL.md(16.3 KB)
  • _archive/skill-package.zip(6.1 KB)

Related Skills

billing-compliance-auditor

Conduct internal billing and coding compliance audits to ensure accurate claims submission and prevent fraud/abuse. Provides audit methodology for E/M leveling, modifier use, medical necessity, and documentation. Use for monthly/quarterly chart audits, pre-billing reviews, or responding to payer audits.

breach-incident-responder

Respond to potential HIPAA breaches and security incidents following required procedures. Provides breach determination methodology, risk assessment framework, notification requirements, and documentation templates. Use when a potential breach is discovered or security incident reported.

clinical-trial-protocol

Generate clinical trial protocols for medical devices or drugs. This skill should be used when users say "Create a clinical trial protocol", "Generate protocol for [device/drug]", "Help me design a clinical study", "Research similar trials for [intervention]", or when developing FDA submission documentation for investigational products.

coverage-verification-checker

Verify patient insurance coverage with deterministic yes/no checks. Validates active coverage, effective dates, provider network status, PCP assignment, referral requirements, and authorization needs. Use when confirming a patient can be seen for a service before the appointment.

denial-management-playbook

Classify healthcare claim denials by CARC/RARC codes and execute appropriate response workflows. Provides denial code lookups, action decisioning logic, appeal letter templates, and payer-specific rules. Use when processing denied claims, generating appeals, or analyzing denial patterns for RCM automation.

fhir-developer

FHIR API development guide for building healthcare endpoints. Use when: (1) Creating FHIR REST endpoints (Patient, Observation, Encounter, Condition, MedicationRequest), (2) Validating FHIR resources and returning proper HTTP status codes and error responses, (3) Implementing SMART on FHIR authorization and OAuth scopes, (4) Working with Bundles, transactions, batch operations, or search pagination. Covers FHIR R4 resource structures, required fields, value sets (status codes, gender, intent), coding systems (LOINC, SNOMED, RxNorm, ICD-10), and OperationOutcome error handling.

Ready to use this skill?

Try it now in your favorite AI, or set up MCP for persistent access.