HIPAA compliance checklists expose the access governance gap

At a glance

What this is: This is a 2026 HIPAA compliance checklist that translates regulatory obligations into access, network, training, incident response, and business associate controls for organisations handling PHI.

Why it matters: It matters because HIPAA compliance depends on identity governance as much as policy text, and practitioners must align human access, third-party access, and lifecycle controls to reduce PHI exposure.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.

👉 Read Zluri's HIPAA compliance checklist for 2026

Context

HIPAA compliance is a governance problem as much as a documentation problem. The checklist in this article centres on PHI access, network safeguards, workforce training, incident response, and business associate oversight, which are the operational controls that determine whether regulated data stays protected.

For identity teams, the key issue is that PHI protection depends on who and what can access systems, how that access is monitored, and whether access changes when roles, vendors, or incidents change. That makes the checklist relevant to human access governance, service account oversight, and third-party lifecycle control, not just audit paperwork.

Key questions

Q: How should organisations implement HIPAA access controls for PHI?

A: Start by mapping PHI access to job function, not broad department membership. Enforce role-based access, MFA, logging, and periodic access reviews so entitlements reflect actual work. The key is to remove standing access that is no longer needed and to verify that reviews produce revocation, not just documentation.

Q: Why do business associate relationships increase PHI governance risk?

A: Because external access can outlive the business need if ownership, monitoring, and offboarding are unclear. A signed agreement is not enough on its own. Organisations need lifecycle control over third-party access, including approval, review, and revocation, or PHI exposure can continue after the relationship changes.

Q: How do you know if HIPAA audit controls are actually working?

A: Look for evidence that access reviews remove unnecessary PHI access, logs support investigations, and incident plans can be executed against real identity events. If policies exist but no one can prove who accessed PHI or how exceptions were closed, the programme is not operating as intended.

Q: Who is accountable when PHI is exposed through weak access governance?

A: The covered entity or business associate remains accountable, even when a vendor, contractor, or internal team member caused the exposure. HIPAA does not shift responsibility away from the organisation handling PHI. Accountability must therefore be backed by ownership, evidence, and enforceable offboarding.

Technical breakdown

HIPAA access controls for PHI

HIPAA access controls are the practical layer that decides which users can reach protected health information and under what conditions. The article emphasises role-based access control, multi-factor authentication, access monitoring, and periodic access reviews. In identity terms, that means matching entitlement scope to job function, checking privileged access for drift, and making sure access changes when staff move roles or leave. This is not only a human IAM issue. Service accounts, shared accounts, and delegated access paths can also create PHI exposure when they outlive the purpose they were granted for.

Practical implication: review PHI entitlements for standing access, stale role assignments, and unmanaged delegated accounts.

HIPAA business associate agreements and third-party access

Business associate agreements are the control boundary for external parties that handle PHI on behalf of a covered entity. The article treats due diligence, contract review, monitoring, and enforcement as part of compliance, which is the right lens because third-party access is often where policy stops and operational risk begins. In identity terms, the agreement is only useful if the associated access can be provisioned, monitored, and revoked across the full relationship lifecycle. Without that, PHI exposure persists after the business need changes.

Practical implication: tie every BAA to explicit access ownership, monitoring, and offboarding triggers.

Audit logs, encryption, and incident response for PHI

HIPAA expects organisations to prove they can detect, contain, and recover from PHI exposure, not just promise that protection exists. The checklist calls out encryption, logging, and incident response planning, which work together: encryption limits readability, logs provide evidence, and response plans define containment and recovery actions. In practice, this is where many programmes stall, because controls exist in isolation but are not operationally connected. If logs do not support investigations or response steps do not map to actual identity events, the control set will not survive an audit or an incident.

Practical implication: test whether your logs, encryption posture, and response playbooks support the same PHI containment workflow.

Threat narrative

Attacker objective: The objective is to reach protected health information without effective identity, logging, or lifecycle controls that would limit misuse or prove accountability.

1. Entry occurs when access to PHI or connected systems is granted without enough restriction, monitoring, or role separation to prevent misuse.
2. Credential or account abuse then becomes possible when access reviews, MFA enforcement, or third-party revocation controls do not keep pace with role changes or vendor changes.
3. Impact follows when PHI can be read, shared, or retained without authorisation, forcing audit action, corrective plans, and possible penalties.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

HIPAA compliance fails when PHI access is treated as a documentation exercise rather than an identity control problem. The article correctly places access controls, monitoring, and reviews at the centre of compliance, but the deeper lesson is that regulatory intent only becomes real when entitlements are continuously matched to role, function, and business need. Covered entities and business associates should treat PHI access as a governed identity surface, not a checklist item.

Third-party PHI risk is a lifecycle problem, not just a contract problem. Business associate agreements matter, but the operational failure mode is access that continues after the relationship or work scope changes. That is the governance gap the article points toward: external access without disciplined provisioning, review, and revocation. Practitioners should read this as a warning that contractual language does not remove entitlement persistence.

Audit readiness depends on whether identity events can be proved, not whether policies exist on paper. HIPAA audit evidence lives in logs, reviews, incident records, and remediation trails. If an organisation cannot show who accessed PHI, why access was allowed, and how access was removed after changes, the control environment is weak regardless of written procedures. The practical conclusion is that evidence quality is part of the control, not an afterthought.

PHI governance should be built as one control plane across human users, service accounts, and vendors. The article spans workforce training, access reviews, and business associate oversight, which is exactly where identity programmes fragment in practice. A single programme view is needed because PHI exposure often emerges when human approvals, non-human credentials, and third-party access are managed in different workflows. Practitioners should align them under one governance model.

Access review cadence is the named concept that matters here: PHI protection depends on review timing that matches role change velocity. Annual reviews may satisfy a basic governance ritual, but they can still leave PHI exposed for months after movers, leavers, or vendor changes. The implication is that compliance teams need to treat review latency as a risk variable, not an administrative schedule.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• Another finding from the same research shows enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
• For a broader control lens, see NHI Lifecycle Management Guide for how lifecycle governance reduces standing exposure across identity types.

What this signals

Access review latency is the signal to watch. HIPAA programmes often look mature on paper while still leaving PHI reachable through stale role memberships, contractor accounts, and forgotten integrations. That is why lifecycle governance matters: if review cadence does not match the speed of access change, the control is already behind the risk.

The next maturity step is to treat audit evidence as an operational output of identity governance, not a compliance afterthought. Organisations that can prove who had PHI access, when it changed, and how revocation happened will have less friction in both regulatory reviews and incident response.

For practitioners expanding beyond human access, the same governance logic should be applied to service accounts and third-party credentials that touch PHI. The problem is not only who can log in, but which non-human identities can still reach sensitive data after the original business purpose has ended.

For practitioners

• Map PHI entitlements to role and business need Inventory who can access PHI, which applications expose it, and which entitlements are standing rather than task-scoped. Reconcile administrative, clinical, and IT access separately so reviews reflect real data handling patterns.
• Tie business associate agreements to revocation triggers For every third party that handles PHI, define who owns access approval, what conditions end access, and how revocation is verified. Do not let contract terms exist without an operational offboarding path.
• Test audit evidence for actual identity events Validate that logs, access reviews, incident records, and remediation trails can show who accessed PHI, when access changed, and how exceptions were handled. If evidence cannot answer those questions, the control is incomplete.
• Separate workforce training by PHI exposure path Train front-office, clinical, and IT staff on the specific PHI access behaviours they perform, including escalation rules, secure handling, and incident reporting. Generic awareness is not enough when duties and exposure levels differ.

Key takeaways

• HIPAA compliance breaks down when PHI access is governed like paperwork instead of a live identity surface.
• The article’s checklist points to the real control issue: access, logging, training, and offboarding only work when they are linked operationally.
• Practitioners should treat review latency, third-party revocation, and audit evidence quality as core PHI risk indicators.

Key terms

• Protected Health Information: Protected Health Information, or PHI, is health data that can identify an individual and is regulated under HIPAA. It includes records, communications, and metadata when those assets are linked to a person. Governance must cover where the data lives, who can reach it, and how access is proven and removed.
• Business Associate Agreement: A Business Associate Agreement is the contract that defines how a third party may handle PHI on behalf of a covered entity. In practice, it should map to specific access ownership, security obligations, breach notification duties, and offboarding requirements. Without operational enforcement, the agreement exists on paper only.
• Access Review: An access review is a formal check of who has access to systems or data and whether that access is still justified. For PHI environments, the review must verify role fit, revoke excess permissions, and cover human, contractor, and non-human identities that can touch sensitive records.
• Audit Evidence: Audit evidence is the proof that security and compliance controls actually operated as intended. In HIPAA programmes, that includes logs, approvals, exception records, remediation trails, and training records. Strong evidence shows not only that a policy existed, but that identity events were handled correctly.

Deepen your knowledge

HIPAA access control, review cadence, and third-party offboarding are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme touches PHI, it is a practical way to tighten governance across human and non-human identities.

This post draws on content published by Zluri: The HIPAA Compliance Checklist for 2026. Read the original.