Hipaa Audit

HIPAA Audit — Health Insurance Portability and Accountability Act

HIPAA governs how Protected Health Information (PHI) is handled in the United States healthcare ecosystem. The engineering surface area is large because PHI is broader than people often realize: a calendar entry naming a patient's appointment is PHI; an IP address logged on a portal accessed by a patient may be PHI in combination with a health condition.

The skill is structured around the four HIPAA rules with emphasis on the Security Rule's three safeguard categories (Administrative / Physical / Technical) — that's where engineering work happens. Privacy Rule, Breach Notification Rule, and HITECH layer on top.

Final compliance determinations stay with counsel and your privacy officer; this skill is the technical engineering layer.

Cross-references: privacy-engineering for the GDPR / CCPA-shaped privacy work that often overlaps; iam-audit for access control and authentication; crypto-audit for encryption-at-rest and in-transit detail; secrets-audit for key management; siem-detection for audit-log engineering; incident-triage and security-comms for breach response.

Scope — who is covered and what is PHI

Who must comply

• Covered entity (CE) — health plans, healthcare clearinghouses, healthcare providers who transmit health info electronically in connection with HIPAA-defined transactions
• Business associate (BA) — anyone who creates / receives / maintains / transmits PHI on behalf of a covered entity (cloud hosts holding PHI, SaaS analytics, EHR vendors, billing services, even some attorneys and consultants)
• Subcontractor of a BA — also a BA. The chain extends; every link needs a BAA with the link above

If a system handles PHI for a CE without a BAA, that's a violation regardless of how secure the handling is.

What is PHI / ePHI

PHI = individually identifiable health information held or transmitted by a CE or BA. ePHI = the electronic form.

The 18 HIPAA identifiers (Safe Harbor de-identification list — if all are stripped, data is no longer PHI):

1. Names
2. Geographic subdivisions smaller than state (street, city, county, ZIP — full ZIP if population < 20,000; first 3 digits OK in most cases)
3. Dates more specific than year (DOB, admission, discharge, death) — for individuals over 89, even the year requires aggregation
4. Phone numbers
5. Fax numbers
6. Email addresses
7. Social Security numbers
8. Medical record numbers
9. Health plan beneficiary numbers
10. Account numbers
11. Certificate / license numbers
12. Vehicle identifiers and serial numbers (including license plates)
13. Device identifiers and serial numbers
14. URLs
15. IP addresses
16. Biometric identifiers (finger, voice)
17. Full-face photographs and comparable images
18. Any other unique identifying number, characteristic, or code

Important: removing the 18 identifiers via Safe Harbor is one of two de-identification methods. The other is Expert Determination (statistical analysis confirming low re-identification risk). De-identified data is not PHI; pseudonymized data is still PHI (because the key linking the surrogate back to the individual is still held somewhere).

Scope reduction patterns

The most common scope reductions:

• Limit data classes collected — if you don't need DOB, don't collect it; don't transmit it; don't store it
• Pseudonymize internally where regulators allow, but understand that internal pseudonyms are still ePHI (the linking table is held by the CE / BA)
• Use BA-signed services where possible — AWS, Google Cloud, Azure, Stripe Healthcare, certain analytics vendors sign BAAs; many SaaS tools do not
• Use services that contractually commit to never receive PHI — analytics platforms that scrub on ingest, error reporters with strict PII filtering

Security Rule — the three safeguard categories

Administrative safeguards (program-level)

These are policy and program controls. Engineering teams contribute artifacts; the privacy officer owns the program.

• §164.308(a)(1) Security Management Process — risk analysis (the foundation; redone on material change), risk management, sanction policy, information system activity review
• §164.308(a)(2) Assigned Security Responsibility — a named Security Official
• §164.308(a)(3) Workforce Security — authorization / supervision, termination procedures
• §164.308(a)(4) Information Access Management — access authorization, modification
• §164.308(a)(5) Security Awareness and Training — including security reminders, malicious software protection, log-in monitoring, password management
• §164.308(a)(6) Security Incident Procedures — see incident-triage
• §164.308(a)(7) Contingency Plan — backup, disaster recovery, emergency mode operation, testing
• §164.308(a)(8) Evaluation — periodic technical and non-technical evaluation
• §164.308(b)(1) Business Associate Contracts — BAA with every BA

Engineering audit input: evidence packages for risk analysis (asset inventory, threat model, controls list), workforce-security records (access reviews, joiner/mover/leaver evidence), training completion records.

Physical safeguards (data center / facility)

For modern SaaS, most physical safeguards are inherited from the cloud provider's compliance posture (covered by the cloud's BAA). Verify:

• §164.310(a) Facility Access Controls — for any office space where ePHI is processed
• §164.310(b) Workstation Use — policies for workstations that access ePHI
• §164.310(c) Workstation Security — physical security of those workstations
• §164.310(d) Device and Media Controls — disposal, media re-use, accountability, data backup and storage

Engineering audit input: confirm cloud provider's BAA covers the relevant physical-safeguard obligations; confirm workstation disk encryption and remote-wipe for any employee laptop touching ePHI.

Technical safeguards (where engineering audits)

This is where this skill spends its time.

§164.312(a) Access Control

• Unique user identification — required. Every individual accessing ePHI has a unique ID. No shared accounts
• Emergency access procedure — break-glass path for emergency PHI access, logged
• Automatic logoff — addressable; idle session termination
• Encryption and decryption — addressable; encrypt ePHI at rest (in practice, treat as required; OCR enforcement strongly suggests this)

Audit grep patterns:

• Shared service-account access to PHI tables: SELECT.*patient, SELECT.*encounter from non-individual accounts
• Lack of session timeout: search for session config without explicit timeout
• Unencrypted ePHI at rest: confirm DB-level + bucket-level encryption per data store

§164.312(b) Audit Controls

• Hardware, software, and procedural mechanisms that record and examine activity in systems containing ePHI

In practice: every read, every write, every access decision involving ePHI logged. Logs preserved for at least 6 years (HIPAA's general document-retention period). See siem-detection for the engineering implementation.

§164.312(c) Integrity

• Mechanisms to authenticate ePHI — verify ePHI has not been altered or destroyed in unauthorized manner
• Addressable in practice — hash / signature controls on critical ePHI records, immutable log storage

§164.312(d) Person or Entity Authentication

• Verify identity of person or entity accessing ePHI
• MFA is not explicitly required by Security Rule text — but post-2013 enforcement and HHS guidance strongly recommend MFA for any remote access to ePHI; treat as effectively required. New HHS guidance (2024+) is moving MFA toward explicit requirement

See iam-audit for implementation.

§164.312(e) Transmission Security

• Integrity controls — addressable; protect ePHI in transit from improper modification
• Encryption — addressable in text but treat as required; TLS 1.2+ for any ePHI traversing networks

See crypto-audit.

Privacy Rule — what can be done with PHI

The Privacy Rule sets the rules for how PHI is used and disclosed. The Security Rule says "protect it"; the Privacy Rule says "you can only use it for these specific purposes."

Engineering-relevant slices:

• Minimum Necessary Standard — when using or disclosing PHI for purposes other than treatment, use or disclose only the minimum necessary. The engineering implementation: role-based access, query-level scoping (don't SELECT * from patient tables), API contracts that return only the fields the caller needs
• TPO exception — Treatment, Payment, and Healthcare Operations do not require authorization. Most other uses do
• Individual rights — right to access (similar to GDPR DSAR — 30-day delivery), right to amend, accounting of disclosures
• Notice of Privacy Practices — published, presented at first interaction

Audit grep patterns:

• Over-broad PHI queries: SELECT \*.*patient, SELECT \*.*encounter, SELECT \*.*observation — almost always a minimum-necessary violation
• API endpoints returning full patient records when callers only need specific fields
• Analytics platforms / monitoring tools receiving PHI without a TPO basis