# HIPAA Breach Response Plan
## Kinometric Balance Assessment Platform

**Effective Date:** February 2026
**Review Frequency:** Annual
**Version:** 1.0

---

## 1. Purpose

This plan establishes procedures for identifying, responding to, and reporting breaches of unsecured Protected Health Information (PHI) as required by the HIPAA Breach Notification Rule (45 CFR 164.400-414).

---

## 2. Definitions

- **Breach**: Unauthorized acquisition, access, use, or disclosure of PHI that compromises its security or privacy.
- **Unsecured PHI**: PHI not rendered unusable, unreadable, or indecipherable to unauthorized persons (i.e., not encrypted to NIST standards).
- **Security Incident**: Attempted or successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations.

---

## 3. Breach Response Team

| Role | Responsibility |
|------|---------------|
| **Security Officer** | Leads investigation, makes breach determination, coordinates notifications |
| **System Administrator** | Contains technical threats, preserves evidence, restores systems |
| **Practice Administrator** | Coordinates patient notifications, manages public communications |

---

## 4. Incident Detection

### 4.1 Detection Sources

| Source | What It Detects | Location |
|--------|----------------|----------|
| HIPAA audit log | Unauthorized athenaOne API access | `logs/athena_hipaa_audit.log` |
| Auth log | Failed login attempts, suspicious patterns | `test/logs/auth.log` |
| Error logs | API errors, unusual access patterns | `logs/` directory |
| Server monitoring | Unauthorized SSH access, system changes | System logs, UFW logs |
| User reports | Suspicious activity, lost devices, phishing | Direct communication |
| Automated security audit | Configuration drift, exposed credentials | `test/monthlyAuditScripts/` |

### 4.2 Indicators of Potential Breach

- Multiple failed login attempts from unknown IPs
- Database queries for patients outside a provider's practice
- Unauthorized access to CSV files or backup files
- Unexpected changes to user accounts or permissions
- Reports of phishing emails targeting staff
- Lost or stolen device that accessed the application
- Unauthorized third-party access to server

---

## 5. Response Procedure

### Step 1: Contain (Immediate — within 1 hour)

- [ ] Identify the scope of the incident (what systems, what data)
- [ ] Disable compromised user accounts: `UPDATE users SET encryptionkey = NULL WHERE user_id = X`
- [ ] Block suspicious IP addresses: `sudo ufw deny from X.X.X.X`
- [ ] If server compromised: change all passwords, rotate API keys, revoke OAuth tokens
- [ ] If device lost: the app has no cached PHI (in-memory only), but revoke user's encryption key
- [ ] Preserve evidence: do NOT delete logs; copy them to secure location

### Step 2: Investigate (Within 24 hours)

- [ ] Review HIPAA audit log for unauthorized access patterns
- [ ] Review auth logs for the time period in question
- [ ] Identify which patients' PHI was potentially exposed
- [ ] Determine how the breach occurred (vulnerability, credential theft, insider)
- [ ] Document the number of individuals affected
- [ ] Determine what types of PHI were involved (names, DOB, test results, etc.)

### Step 3: Assess (Within 48 hours)

Apply the four-factor risk assessment required by HIPAA:

1. **Nature and extent of PHI involved**: What identifiers? Clinical data? Financial data?
2. **Unauthorized person who accessed PHI**: Known or unknown? Internal or external?
3. **Whether PHI was actually acquired or viewed**: Access logs show what was retrieved
4. **Extent of mitigation**: Was the risk reduced by immediate containment?

**Determination**: If the assessment shows a low probability that PHI was compromised, document the analysis and retain for 6 years. No notification required.

If a breach IS confirmed, proceed to Step 4.

### Step 4: Notify (Within required timeframes)

| Who | When | How |
|-----|------|-----|
| **Affected individuals** | Within 60 days of discovery | Written notice (first-class mail) or email if consented |
| **HHS (Office for Civil Rights)** | Within 60 days if 500+ affected; annually if <500 | Via HHS breach portal: https://ocrportal.hhs.gov/ocr/breach/wizard_breach.jsf |
| **Media** | Within 60 days if 500+ in a state/jurisdiction | Press release to prominent media outlets |
| **Business Associates** | Immediately upon discovery | Written notice per BAA terms |

#### Individual Notification Must Include:

1. Description of the breach (what happened, date)
2. Types of PHI involved (names, DOB, test results)
3. Steps individuals should take to protect themselves
4. What Kinometric is doing to investigate and mitigate
5. Contact information for questions (phone number, email)

### Step 5: Remediate (Ongoing)

- [ ] Fix the vulnerability that caused the breach
- [ ] Update security controls as needed
- [ ] Retrain workforce on security procedures
- [ ] Update this breach response plan with lessons learned
- [ ] Document all actions taken and retain for 6 years

---

## 6. Breach Scenarios and Specific Actions

### Scenario A: Server Compromised

1. Take server offline if active attack in progress
2. Restore from encrypted backup (latest clean backup)
3. Rotate ALL credentials: database password, API keys, user passwords
4. Review all files for unauthorized modifications
5. Engage forensic analysis if needed

### Scenario B: Lost/Stolen Mobile Device

1. Verify: Kinometric app stores no PHI on device (in-memory only)
2. Revoke user's encryption key in database
3. If device had other PHI apps: follow their breach procedures
4. Low breach risk due to no-cache architecture

### Scenario C: Unauthorized Database Access

1. Identify which records were accessed (audit logs)
2. Change database credentials immediately
3. Review pg_hba.conf for unauthorized access rules
4. Verify database is bound to localhost only
5. Count affected patient records

### Scenario D: Credential Theft (Phishing)

1. Disable compromised user account immediately
2. Force password reset for all users as precaution
3. Review audit logs for unauthorized actions during exposure window
4. Enable 2FA for all accounts

### Scenario E: Business Associate Breach

1. Receive notification from BA (Linode, Anthropic, Microsoft, athenahealth)
2. Determine if Kinometric data was affected
3. Follow BA's guidance on scope and remediation
4. Notify affected individuals if PHI was exposed

---

## 7. Documentation Requirements

Retain all breach-related documentation for **6 years** from the date of the incident or the date of last action taken, whichever is later:

- Incident detection report (who found it, when, how)
- Investigation findings and timeline
- Four-factor risk assessment
- Breach determination (breach vs. non-breach)
- Notification letters sent (copies)
- Remediation actions taken
- Post-incident review and policy updates

---

## 8. Contact Information

| Contact | Purpose | Details |
|---------|---------|---------|
| HHS Office for Civil Rights | Breach reporting | https://ocrportal.hhs.gov |
| HHS Breach Portal | Online submission | https://ocrportal.hhs.gov/ocr/breach/wizard_breach.jsf |
| HHS Phone | Questions | 1-800-368-1019 |

---

## 9. Approval

| Role | Name | Signature | Date |
|------|------|-----------|------|
| Security Officer | _________________ | _________________ | ________ |
| Practice Administrator | _________________ | _________________ | ________ |

---

*This plan satisfies the requirements of 45 CFR 164.308(a)(6) (Security Incident Procedures) and 45 CFR 164.400-414 (Breach Notification Rule). Review annually or after any breach incident.*