Access Control

HIPAA’s Access Control requirement means you must implement technical policies and procedures so systems that create, receive, maintain, or transmit ePHI only allow access to authorized people and authorized software. To operationalize it quickly, you need a complete ePHI system inventory, role-based access rules, strong authentication, joiner/mover/leaver workflows, and audit-ready evidence that access is granted, reviewed, and removed consistently. (45 CFR Parts 160, 162, 164)

Key takeaways:

• Scope first: you cannot control access to ePHI you haven’t identified and mapped. (45 CFR Parts 160, 162, 164)
• Enforce least privilege with technical controls plus governance, not “policy-only” access decisions. (45 CFR Parts 160, 162, 164)
• Evidence wins audits: access requests, approvals, provisioning logs, reviews, and deprovisioning records matter as much as the tools. (45 CFR Parts 160, 162, 164)

Access control is the Security Rule requirement auditors test by sampling real users, real systems, and real access paths to ePHI. If your access model is informal (“ask IT”), inconsistent across apps, or missing review/deprovisioning proof, you will struggle to show that only approved persons and software programs can reach ePHI.

This page translates the HIPAA access control requirement into an operator checklist: what’s in scope, what to configure, what to document, and what artifacts to retain. It also flags common failure points: shared accounts, stale access for terminated users, vendor and third-party support access that bypasses normal approvals, and “shadow” ePHI in file shares and exports.

If you support multiple business units, M&A environments, or heavy third-party workflows, you will need a repeatable process that scales. Many teams manage this through a centralized identity provider, standardized access request/approval workflows, and periodic access reviews tied to job function. Where Daydream fits naturally is keeping the evidence pack current across systems and third parties so you can answer sampling requests fast without scrambling.

Regulatory text

Requirement (quoted excerpt): “Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in § 164.308(a)(4).” (45 CFR Parts 160, 162, 164)

What the operator must do:
You must put technical access controls in place for any electronic information system that maintains ePHI, so access is restricted to authorized users and authorized programs. This is not satisfied by a policy alone; you need enforceable system configuration plus an access governance process that ties authorization to defined roles and management approval. (45 CFR Parts 160, 162, 164)

Plain-English interpretation (what “access control requirement” means in practice)

If a person or software program is not explicitly approved to access ePHI, they must not be able to access it. That applies to:

• Human users (workforce members, contractors, support staff).
• Non-human identities (service accounts, integrations, APIs, batch jobs, RPA bots).
• All access paths (application UI, database query tools, file shares, backups, exports, logs, and admin consoles).

A clean way to explain your program to an auditor: “We know where ePHI lives, we define who needs it and why, we approve access, we enforce it technically, we review it, and we remove it promptly when it’s no longer needed.” (45 CFR Parts 160, 162, 164)

Who it applies to (entity and operational context)

Entity types: Covered Entities and Business Associates. (45 CFR Parts 160, 162, 164)

Operational scope: Any electronic information system that maintains ePHI, including:

• EHR/EMR platforms and patient portals
• Billing, claims, and revenue cycle systems
• Imaging, lab, and pharmacy systems
• Cloud storage (files, object storage), collaboration tools, ticketing systems with ePHI attachments
• Data warehouses/analytics environments that include identifiable patient data
• Endpoint devices and mobile apps that store or sync ePHI
• Third-party hosted solutions where you administer roles or can request role changes

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

Use this sequence to stand up an audit-ready access control program.

1) Define the access control boundary: inventory systems with ePHI

• Build an inventory of systems that create, receive, maintain, or transmit ePHI.
• For each system, record: system owner, where hosted, user populations, authentication method, authorization method (roles/groups), and admin access paths.
• Identify “secondary ePHI stores” (exports to file shares, emailed reports, synced folders, BI extracts).

Deliverable: ePHI system inventory and data flow notes that clearly mark which systems are in scope for access control. (45 CFR Parts 160, 162, 164)

2) Establish an authorization model (roles, least privilege, and separation of duties)

• Define standard roles per system (clinical, billing, customer support, IT admin, auditor/readonly).
• Map each role to permitted actions (view, create, edit, export, delete, admin).
• Implement separation between “can access ePHI” and “can administer access.” Avoid giving broad admin rights to operational users.

Operator tip: If the app only supports coarse roles, control access at the identity provider or network layer to narrow exposure, and document the compensating control. (45 CFR Parts 160, 162, 164)

3) Implement strong identity controls for both humans and software

• Centralize authentication where feasible (SSO) so termination and lockout are consistent.
• Require unique user IDs and prohibit shared accounts for routine operations.
• For service accounts/integrations: ensure ownership, purpose, credential storage method, and rotation expectations are documented.

Decision point: If a third party requires persistent admin access, require named accounts, time-bound access, and logging, and treat it as privileged access. (45 CFR Parts 160, 162, 164)

4) Put an access request and approval workflow in place

• Require a ticket/request that states: system, role, business justification, manager approval, and effective date.
• Assign provisioning to a controlled group (IT/security) with documented completion steps.
• For emergency access, define a break-glass process with after-the-fact review.

Minimum viable control: No access without recorded approval, even if the technical change is a simple group add. (45 CFR Parts 160, 162, 164)

5) Operationalize Joiner/Mover/Leaver (JML)

• Joiner: Access granted based on role template and approved request.
• Mover: Role changes trigger a remove-and-replace review, not an additive “keep old access plus new.”
• Leaver: Termination triggers account disablement and revocation across all ePHI systems, including third-party apps.

Hangup to avoid: HR termination feed covers employees but misses contractors and third-party support accounts. Track non-employee identities separately. (45 CFR Parts 160, 162, 164)

6) Review access on a recurring basis and after material changes

• Perform periodic access reviews for each in-scope system.
• Review privileged/admin access more frequently than standard access as an internal risk practice.
• Trigger off-cycle reviews after incidents, major role redesigns, M&A, or new integrations.

What auditors look for: evidence that reviewers are appropriate (system owner/manager), that exceptions are resolved, and that removals are completed. (45 CFR Parts 160, 162, 164)

7) Log and monitor access control events

• Confirm systems log authentication events, admin role changes, and access grants/revocations.
• Ensure logs are protected from tampering and retained per your internal retention schedule.
• Monitor for obvious red flags: repeated failed logins, access from unexpected locations, creation of new admin accounts, sudden bulk exports.

Practical constraint: If a system cannot produce logs, document the limitation and add compensating controls (restricted admin access, tighter approvals, network segmentation). (45 CFR Parts 160, 162, 164)

Required evidence and artifacts to retain (audit-ready)

Maintain a single evidence folder per system plus an enterprise-level binder:

Enterprise-level artifacts

• Access control policy and procedures for ePHI systems. (45 CFR Parts 160, 162, 164)
• Workforce access governance: role definitions, approval authorities, and JML procedure. (45 CFR Parts 160, 162, 164)
• Inventory of ePHI systems and system owners. (45 CFR Parts 160, 162, 164)

System-level artifacts (for each in-scope application)

• Role/permission matrix (what each role can do). (45 CFR Parts 160, 162, 164)
• Screenshots or exports showing configured roles/groups and admin assignments. (45 CFR Parts 160, 162, 164)
• Access request tickets showing business justification and approvals. (45 CFR Parts 160, 162, 164)
• Provisioning/deprovisioning records (helpdesk logs, IdP group changes, HR termination evidence). (45 CFR Parts 160, 162, 164)
• Access review evidence: reviewer sign-off, findings, remediation tickets, completion proof. (45 CFR Parts 160, 162, 164)
• Service account register: owner, purpose, credential storage, allowed endpoints/scopes. (45 CFR Parts 160, 162, 164)
• Third-party access documentation: named accounts, contract language or support process, and approval records for privileged access. (45 CFR Parts 160, 162, 164)

Where Daydream helps: centralize these artifacts by system and third party, map them to the access control requirement, and keep sampling evidence current so audits don’t become screenshot scavenger hunts.

Common exam/audit questions and hangups

Auditors and assessors tend to ask variations of these:

1. “Show me your systems that store ePHI and how access is controlled in each.”
   Hangup: inventory gaps, especially analytics, file shares, and SaaS exports. (45 CFR Parts 160, 162, 164)

2. “Pick a user. Why do they have access? Who approved it?”
   Hangup: approvals done in chat/email with no durable record. (45 CFR Parts 160, 162, 164)

3. “Pick a terminated user. Prove access was removed.”
   Hangup: deprovisioning works for SSO apps but not for local accounts or third-party portals. (45 CFR Parts 160, 162, 164)

4. “List all admins and service accounts for this system.”
   Hangup: service accounts not inventoried, or admins granted for convenience and never revisited. (45 CFR Parts 160, 162, 164)

5. “How do you prevent or detect shared accounts?”
   Hangup: clinical workflows and shared workstations without compensating controls documented. (45 CFR Parts 160, 162, 164)

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Better approach
Treating access control as a policy-only control	Systems still allow excessive access	Enforce roles/groups in the app/IdP and test with real accounts. (45 CFR Parts 160, 162, 164)
“Add-only” access over time	Privilege accumulates as people change jobs	Move to role replacement on job change, with owner review. (45 CFR Parts 160, 162, 164)
Ignoring non-human identities	Service accounts often have broad access	Maintain a service account register with ownership and scoped permissions. (45 CFR Parts 160, 162, 164)
No proof of removal	Terminations become audit findings	Tie HR/contractor offboarding to disablement evidence across systems. (45 CFR Parts 160, 162, 164)
Third-party support bypass	Remote admin accounts create hidden risk	Require named accounts, approval, time limits where feasible, and logging. (45 CFR Parts 160, 162, 164)

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog, so this page focuses on operational expectations implied by the HIPAA Security Rule text and common audit sampling patterns. The risk is straightforward: weak access control increases the chance of unauthorized access to ePHI through excessive privileges, stale accounts, or uncontrolled integrations. (45 CFR Parts 160, 162, 164)

Practical 30/60/90-day execution plan

Because no time-based benchmarks were provided in the source catalog, treat this as a sequencing plan rather than a promise of completion by specific dates.

First phase (Immediate): stop obvious access leaks

• Freeze shared account creation for ePHI systems; require named accounts going forward. (45 CFR Parts 160, 162, 164)
• Identify top ePHI systems by volume/criticality and confirm who the system owner is. (45 CFR Parts 160, 162, 164)
• Export current user/admin lists for those systems and flag: inactive users, unknown accounts, generic accounts, and third-party accounts. (45 CFR Parts 160, 162, 164)
• Stand up a basic access request workflow with required fields (system, role, justification, approver). (45 CFR Parts 160, 162, 164)

Second phase (Near-term): standardize authorization and reviews

• Create role matrices for priority systems and align with job functions. (45 CFR Parts 160, 162, 164)
• Implement JML steps: joiner templates, mover role replacement, leaver revocation checklist. (45 CFR Parts 160, 162, 164)
• Establish an access review cadence by system owner; run the first review and close findings with tickets. (45 CFR Parts 160, 162, 164)
• Build the service account register and validate each account has an owner and a purpose. (45 CFR Parts 160, 162, 164)

Third phase (Ongoing): mature monitoring and third-party controls

• Expand the system inventory to capture secondary ePHI stores and data pipelines. (45 CFR Parts 160, 162, 164)
• Improve logging coverage and operational monitoring for access changes and privileged activity. (45 CFR Parts 160, 162, 164)
• Formalize third-party access paths (support portals, remote admin tools, managed services) with documented approvals and periodic review. (45 CFR Parts 160, 162, 164)
• Use Daydream to keep evidence continuously audit-ready across systems and third parties, so access reviews and sampling requests don’t stall operations.

Frequently Asked Questions

Does HIPAA access control apply to cloud SaaS tools like ticketing or file storage if staff sometimes attach patient info?

Yes if the system maintains ePHI, even if ePHI is “incidental” in attachments or exports, the access control requirement applies to that system. Start by identifying where ePHI lands and then enforce role-based access and approvals. (45 CFR Parts 160, 162, 164)

Are service accounts and integrations in scope for “persons or software programs”?

Yes. You should treat integrations, APIs, and service accounts as software programs that must be explicitly granted access rights, with defined scope and ownership. Maintain a register and require change control for permissions. (45 CFR Parts 160, 162, 164)

What’s the minimum evidence I need to prove access is “only authorized”?

Keep the system’s role/permission configuration, a list of current users/admins, and records showing access was requested, approved, and provisioned. Add access review sign-offs and deprovisioning proof for departures. (45 CFR Parts 160, 162, 164)

Can we rely on SSO alone to meet the access control requirement?

SSO helps with authentication and centralized disablement, but you still need authorization controls (roles/permissions) inside each ePHI system and evidence that access is approved and reviewed. SSO without role governance usually leaves privilege creep. (45 CFR Parts 160, 162, 164)

How do we handle third-party support access to an EHR or hosted billing platform?

Require named accounts where the platform supports it, document the business justification, and make access time-bound or ticket-based when feasible. Retain evidence of approvals and keep an admin list that includes third-party identities. (45 CFR Parts 160, 162, 164)

What do we do if a legacy system can’t support granular roles?

Document the limitation and narrow access through compensating controls such as restricted network access, a smaller approved user group, and stronger approvals with more frequent reviews. Record the decision and keep evidence of the compensating controls. (45 CFR Parts 160, 162, 164)