Access Establishment and Modification

To meet HIPAA’s Access Establishment and Modification requirement, you must run a controlled access lifecycle: formally grant access based on written authorization rules, document the decision, periodically review it, and promptly change or remove access when roles or relationships change. This applies to every system, workstation, and process that touches ePHI. (45 CFR Parts 160, 162, 164)

Key takeaways:

• Build a single, auditable joiner/mover/leaver process for all ePHI access requests and changes. (45 CFR Parts 160, 162, 164)
• Tie access decisions to defined roles and minimum necessary access, then document approvals and the implemented access. (45 CFR Parts 160, 162, 164)
• Prove ongoing control with access reviews, change logs, and deprovision evidence, including for third-party workforce access. (45 CFR Parts 160, 162, 164)

“Access Establishment and Modification” is the HIPAA Security Rule requirement that turns access control from an IT task into a governed compliance process. The rule expects you to consistently (1) establish access, (2) document what was granted and why, (3) review access over time, and (4) modify access when job duties or relationships change. (45 CFR Parts 160, 162, 164)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as a lifecycle control with defined triggers: onboarding, role change, transfer, leave of absence, termination, and third-party engagement start/end. Examiners and auditors typically test whether you can show a complete story for a sample of users: request → approval → provisioning → periodic review → modification/removal, plus evidence that the access aligns to your authorization policy. (45 CFR Parts 160, 162, 164)

This page gives requirement-level implementation guidance you can hand to IAM, IT, HR, Security Operations, and application owners. You will leave with a step-by-step operating model, a list of required artifacts, and the audit questions you should be ready to answer.

Regulatory text

45 CFR § 164.308(a)(4)(ii)(C) requires you to “implement policies and procedures that, based upon the covered entity’s or the business associate’s access authorization policies, establish, document, review, and modify a user’s right of access to a workstation, transaction, program, or process.” (45 CFR Parts 160, 162, 164)

Operator translation (what you must do):

• Establish access through a defined request and approval path tied to your access authorization policy. (45 CFR Parts 160, 162, 164)
• Document the access decision and what was provisioned (systems, roles, groups, privileges). (45 CFR Parts 160, 162, 164)
• Review access periodically and when risk changes, so access stays aligned to role and minimum necessary access. (45 CFR Parts 160, 162, 164)
• Modify access promptly when a person’s job changes or a third party’s engagement ends, including removals and privilege reductions. (45 CFR Parts 160, 162, 164)

Plain-English interpretation

You need a repeatable way to answer three questions for any user who can touch ePHI:

1. Why do they have access? (role-based justification and approval)
2. What exactly do they have access to? (systems and privileges)
3. How do you keep it accurate over time? (reviews and change control)

This requirement is not satisfied by “we have passwords” or “IT creates accounts.” It expects governance: documented rules for who gets access, proof that the rules were followed, and proof you remove or change access as people move around. (45 CFR Parts 160, 162, 164)

Who it applies to

Entity scope

• Covered Entities and Business Associates. (45 CFR Parts 160, 162, 164)

Operational scope (where it shows up)

• Any workforce member (employees, contractors, temps, trainees) with access to systems that create, receive, maintain, or transmit ePHI. (45 CFR Parts 160, 162, 164)
• Any third party with logical access to your environment that can expose ePHI (hosted EHR access, managed IT, billing platforms with admin access, call centers with portal access). (45 CFR Parts 160, 162, 164)
• “Workstation, transaction, program, or process” means this is broader than EHR logins. Include VPN, VDI, file shares, ticketing systems containing ePHI, integrations, and administrative consoles. (45 CFR Parts 160, 162, 164)

What you actually need to do (step-by-step)

1) Define your access authorization policy inputs

You cannot operationalize this requirement without clear decision rules.

• Create/confirm role definitions for ePHI-touching functions (clinical staff, billing, HIM, IT admins, developers with production access, support desk). (45 CFR Parts 160, 162, 164)
• Map roles to access packages (applications + privilege sets). Keep packages small enough to support minimum necessary access. (45 CFR Parts 160, 162, 164)
• Set approval authority by access risk:
  • standard user access: manager + app owner
  • elevated/admin access: system owner + Security (and add time limits when feasible)
  • third-party access: contract owner + Security + app owner (and ensure engagement dates drive removal)

Deliverable: an access matrix (role → systems → entitlements → approvers).

2) Standardize request, approval, and provisioning (Joiner)

Build one intake path, even if provisioning occurs in multiple tools.

• Intake: require requester, user identity, role, systems requested, justification, start date, end date (required for third parties and temporary elevated access). (45 CFR Parts 160, 162, 164)
• Approval: capture explicit approval(s) tied to your access matrix. Avoid “verbal approvals” and inbox-only approvals that cannot be retained. (45 CFR Parts 160, 162, 164)
• Provisioning: IT/IAM implements access exactly as approved; no “extra” entitlements “to save time.” (45 CFR Parts 160, 162, 164)
• Validation: confirm access works and matches the request (ticket closure requires evidence). (45 CFR Parts 160, 162, 164)

Practical control: require a provisioning checklist in the ticket that lists the exact groups/roles added.

3) Handle changes cleanly (Mover)

Role changes create the most access drift.

• Trigger events: HR job change, department transfer, change in duties, project-based production access, return from leave. (45 CFR Parts 160, 162, 164)
• Process rule: remove old role access before adding new access when feasible, or document why dual access is required and set an end date. (45 CFR Parts 160, 162, 164)
• High-risk access: for admin privileges, require re-approval on role change even if the person is already employed. (45 CFR Parts 160, 162, 164)

4) Remove access promptly (Leaver)

Termination and contract end are where auditors look for gaps.

• Identity disablement: disable network/SSO identity and remote access pathways. (45 CFR Parts 160, 162, 164)
• App access removal: remove direct accounts in systems not integrated with central IAM. Track exceptions explicitly. (45 CFR Parts 160, 162, 164)
• Third-party offboarding: tie deprovision to contract end date and ticket it as a required exit step for the engagement owner. (45 CFR Parts 160, 162, 164)

5) Conduct access reviews (Review)

“Review” must be more than “we trust managers.”

• Choose review owners: application owners validate entitlements; managers validate business need; Security validates privileged access lists. (45 CFR Parts 160, 162, 164)
• Define review scope: start with systems that store or administer ePHI, then expand to adjacent systems that can expose it (file shares, integration platforms). (45 CFR Parts 160, 162, 164)
• Make reviewers attest to action: approve, remove, or change, with comments for exceptions. (45 CFR Parts 160, 162, 164)
• Close the loop: create remediation tickets and retain evidence of completion. (45 CFR Parts 160, 162, 164)

6) Put access changes under change control for sensitive systems

For changes to access models (new roles, new admin groups, break-glass accounts), treat them as controlled changes:

• documented request
• review by system owner and Security
• tested implementation
• backout plan when relevant (especially for shared clinical workflows)

7) Operationalize with tooling (keep it auditable)

If your evidence is scattered across email, chat, and tribal knowledge, audits will be painful.

• Centralize: tickets for every access event; a system of record for entitlements; exports for reviews. (45 CFR Parts 160, 162, 164)
• Daydream fit (practical): use Daydream to standardize evidence collection for access reviews and access change workflows across apps, so you can answer auditor samples without rebuilding proof each time.

Required evidence and artifacts to retain

Retain evidence that tells the lifecycle story for each sampled user:

Policies & standards

• Access authorization policy (or equivalent) that defines who can approve what. (45 CFR Parts 160, 162, 164)
• Procedure for establishing, documenting, reviewing, and modifying access. (45 CFR Parts 160, 162, 164)

Operational records

• Access request tickets (new access, changes, removals), including justification and approver identity. (45 CFR Parts 160, 162, 164)
• Provisioning logs or screenshots showing groups/roles assigned. (45 CFR Parts 160, 162, 164)
• Termination/offboarding tickets and proof of disablement/removal. (45 CFR Parts 160, 162, 164)
• Access review packets: population list, reviewer assignments, reviewer attestations, exception notes, remediation tickets, closure evidence. (45 CFR Parts 160, 162, 164)

Control monitoring

• Lists of privileged accounts and break-glass access with approvals and review outcomes. (45 CFR Parts 160, 162, 164)
• Exception register for systems not integrated with centralized IAM, with compensating controls and ownership. (45 CFR Parts 160, 162, 164)

Common exam/audit questions and hangups

Expect auditors to ask for samples that test joiner/mover/leaver and reviews:

• “Show me how access is approved for a new hire who needs EHR and billing system access.” (45 CFR Parts 160, 162, 164)
• “Pick two users who changed roles. Show removal of prior access and approval for new access.” (45 CFR Parts 160, 162, 164)
• “Pick two terminated users (including a contractor). Show deprovision evidence across all ePHI systems.” (45 CFR Parts 160, 162, 164)
• “Provide your last access review for System X and evidence you completed removals found in the review.” (45 CFR Parts 160, 162, 164)
• Hangup: “We can show SSO disablement, but not direct app accounts.” If that’s true, create the exception register and start integrating or implementing compensating reviews. (45 CFR Parts 160, 162, 164)

Frequent implementation mistakes and how to avoid them

• Mistake: approvals happen in email. Fix: require approvals in the ticketing/IAM workflow so evidence is retained and searchable. (45 CFR Parts 160, 162, 164)
• Mistake: role definitions are vague (“operations user”). Fix: tighten roles to real job functions and map them to specific entitlements. (45 CFR Parts 160, 162, 164)
• Mistake: access reviews are check-the-box. Fix: require action outcomes and remediation tracking; audit for completion. (45 CFR Parts 160, 162, 164)
• Mistake: third-party access is not time-bound. Fix: require start/end dates and automate disablement reminders; at minimum, review third-party accounts as a distinct population. (45 CFR Parts 160, 162, 164)
• Mistake: privileged access is treated like normal access. Fix: add extra approval, separate review lists, and tighter documentation. (45 CFR Parts 160, 162, 164)

Enforcement context and risk implications

No public enforcement case references were provided in the approved source catalog for this page, so do not treat the absence of examples as low risk. Operationally, weak access governance creates predictable failure modes: orphaned accounts, excessive privileges, and untracked third-party access to ePHI-bearing systems. Those conditions increase the likelihood that a single compromised credential results in broad ePHI exposure, and they make incident response harder because you cannot quickly answer “who had access to what.” (45 CFR Parts 160, 162, 164)

Practical execution plan (30/60/90)

Use this as an execution checklist, not a calendar promise.

First 30 days (Immediate stabilization)

• Inventory ePHI systems and identify which have direct accounts versus SSO-managed access. (45 CFR Parts 160, 162, 164)
• Publish an interim access request standard: every access grant/change/removal requires a ticket with approval and implemented entitlements recorded. (45 CFR Parts 160, 162, 164)
• Build an initial privileged access roster and require explicit approvals for any new admin grants. (45 CFR Parts 160, 162, 164)
• Start an exceptions register for systems you cannot yet review or deprovision cleanly. Assign owners. (45 CFR Parts 160, 162, 164)

By 60 days (Operational consistency)

• Finalize the role-to-access matrix for the highest-risk systems (EHR, data repositories, admin consoles). (45 CFR Parts 160, 162, 164)
• Implement a mover process tied to HR triggers (role change requires access revalidation). (45 CFR Parts 160, 162, 164)
• Run your first documented access review for one critical system and remediate findings with tickets. (45 CFR Parts 160, 162, 164)
• Formalize third-party access onboarding/offboarding steps in procurement or contract intake. (45 CFR Parts 160, 162, 164)

By 90 days (Audit-ready evidence)

• Expand access reviews to additional ePHI systems and separate privileged access review populations. (45 CFR Parts 160, 162, 164)
• Reduce exceptions by integrating key apps into IAM/SSO or documenting compensating controls where integration is not feasible. (45 CFR Parts 160, 162, 164)
• Standardize evidence packs for auditor sampling (joiner/mover/leaver and review). Daydream can help you assemble these packs consistently across systems. (45 CFR Parts 160, 162, 164)

Frequently Asked Questions

Does this requirement apply to business associates or just covered entities?

It applies to both covered entities and business associates under 45 CFR § 164.308(a)(4)(ii)(C). (45 CFR Parts 160, 162, 164)

What counts as “document” for access establishment?

Documentation should show the request, the approval authority, and the exact access granted (roles/groups/privileges) for the workstation, program, transaction, or process. Keep it in a system where you can retrieve it for audits. (45 CFR Parts 160, 162, 164)

Do we need periodic access reviews even if we have SSO?

Yes. SSO helps centralize authentication, but the requirement includes reviewing and modifying access rights over time, which still requires evidence of periodic validation and remediation. (45 CFR Parts 160, 162, 164)

How do we handle access for third parties like billing services or IT contractors?

Treat third-party access as workforce access for control purposes: ticketed request, documented approvals, scoped entitlements, and time-bounded access with documented offboarding. Track third-party accounts as a distinct review population. (45 CFR Parts 160, 162, 164)

Our EHR has shared accounts for certain workflows. Is that compatible with this requirement?

Shared accounts create documentation and accountability gaps because you cannot establish and review access by individual user. If shared accounts exist, document the business rationale, restrict them tightly, and create compensating monitoring and review steps while you work toward named-user access. (45 CFR Parts 160, 162, 164)

What evidence do auditors ask for most often?

They usually request samples that show the full lifecycle: joiner approvals and provisioning evidence, mover changes with removal of old access, leaver deprovision across systems, and completed access reviews with remediation proof. (45 CFR Parts 160, 162, 164)