Access management

The access management requirement under HHS 405(d) HICP (HICP-03) expects you to control and periodically review user and system access to sensitive systems so only authorized identities have the minimum access needed. To operationalize it fast, define “sensitive systems,” standardize joiner/mover/leaver access flows, enforce MFA and least privilege, and run documented access recertifications with remediation tracking ¹.

Key takeaways:

• Scope first: clearly list sensitive systems and authoritative identity sources, then map access paths.
• Make access repeatable: role-based access, approvals, MFA, and automated deprovisioning where possible.
• Prove it: retain tickets, access review outputs, exception approvals, and remediation evidence ¹.

Access management fails in predictable places: shared accounts that never got cleaned up, privileged access granted “temporarily” that became permanent, and access reviews that happen but leave no audit trail. HICP-03 is short, but the operational expectation is not: you must be able to demonstrate control over who (and what systems) can access sensitive systems, and you must be able to show you review that access and correct issues ¹.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat access management as a closed-loop process with three outputs: (1) a clear scope of sensitive systems and identity sources, (2) standardized provisioning/deprovisioning and privileged access controls, and (3) periodic access reviews with tracked remediation and exceptions. If you can produce those artifacts on demand, you can usually satisfy examiner/auditor scrutiny even in complex healthcare environments with EHRs, imaging systems, revenue cycle platforms, cloud infrastructure, and third-party managed services.

This page focuses on requirement-level implementation guidance you can hand to IT, Security, and application owners and then verify through evidence.

Regulatory text

HICP-03 (Access management): “Control and review user/system access to sensitive systems.” ¹

Operator interpretation (what this means in practice):

• “Control” means access is authorized, provisioned through a defined process, limited by least privilege, and protected with strong authentication (commonly MFA for interactive access) for sensitive systems ¹.
• “Review” means you periodically validate access is still appropriate, remove what is no longer needed, and can prove you did it through retained evidence ¹.
• “User/system access” includes human users, service accounts, integrations, APIs, bots/RPA, and managed service provider accounts ¹.
• “Sensitive systems” must be defined by you. In healthcare, this typically includes systems that store, process, or transmit regulated or confidential data, or that can materially affect clinical operations if misused ¹.

Plain-English requirement

You need a reliable way to ensure only the right identities have the right access to the systems that matter most, and you need to regularly confirm that access remains correct. If access is granted outside your process, if you cannot show who approved it, or if you cannot show reviews and clean-up actions, you will struggle to demonstrate conformance to the access management requirement ¹.

Who it applies to (entity + operational context)

Entity types: Healthcare organizations ¹.

Operational scope you should assume:

• Corporate IT (directory services, email, endpoint management, VPN/remote access).
• Clinical systems (EHR/EMR, PACS/RIS, lab systems).
• Business systems (ERP, HRIS, billing, CRM).
• Cloud platforms and identity providers.
• Third-party managed systems where your workforce or the third party’s workforce has administrative or data access ¹.

Common scoping decision: define “sensitive systems” as any system that (a) contains PHI or other confidential data, (b) provides privileged administrative capability, or (c) supports critical clinical/business operations where misuse would create safety, availability, or fraud risk ¹.

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

1) Define and publish scope: “sensitive systems” inventory

1. Build a list of sensitive systems and owners (application owner + technical owner).
2. For each system, record:
   • Data types and criticality (why it is sensitive).
   • Authentication method (IdP, local accounts, shared accounts).
   • Privileged roles/groups.
   • How access is requested and granted today.
3. Freeze a baseline: this becomes the control population for access reviews ¹.

Practical tip: Start with your EHR, identity provider, VPN/remote access, cloud console, finance systems, and any system with administrative access. Expand after you have a working review cycle.

2) Establish an authoritative identity source and “one way in”

1. Identify the authoritative sources for identities:
   • Workforce: typically HRIS for employees, plus a contractor onboarding source.
   • Non-human identities: service account registry or CMDB entry requirement.
2. Route access requests through a single mechanism (ticketing/workflow tool or an IAM request portal):
   • Require requestor identity, business justification, and access level requested.
   • Require documented approvals (manager + system owner; add security for privileged access).
3. Prohibit direct grants outside workflow except for emergency break-glass, and make break-glass time-bound with after-the-fact review ¹.

3) Implement least privilege and role-based access where feasible

1. Define standard roles for each sensitive system:
   • Base user role(s).
   • Elevated roles (admin, super-user, billing admin, security admin).
2. Map roles to job functions (HR titles are a starting point, not a control).
3. Use groups to assign access rather than direct user entitlements where the platform supports it.
4. Document exceptions:
   • Why the user needs out-of-role access.
   • Who approved it.
   • When it expires or will be revalidated ¹.

Decision point: If a system cannot support roles/groups, require compensating controls: tighter approvals, more frequent review cadence for that system, and stronger logging.

4) Enforce MFA for sensitive systems and high-risk access paths

1. Require MFA for:
   • Remote access (VPN, VDI, remote support tools).
   • Cloud consoles and administrative portals.
   • Privileged users where supported.
2. Control MFA exceptions:
   • Document why MFA is not feasible.
   • Require compensating controls (restrict source IPs, device certificates, jump hosts, session recording, or tighter monitoring) ¹.

5) Control privileged access (people and service accounts)

1. Separate admin accounts from standard user accounts for administrators.
2. Implement a controlled method for privileged access:
   • Privileged Access Management (PAM) tool, or
   • Managed “admin workstations” + check-out credentials + strict logging, if PAM is not yet available.
3. Inventory service accounts:
   • Owner, purpose, systems accessed, credentials storage method, rotation approach.
4. Eliminate shared accounts where possible; if a shared account must exist, require compensating controls (named checkout, strong authentication where feasible, and robust logs) ¹.

6) Run periodic access reviews (recertification) and close the loop

1. Define review populations:
   • All privileged access (highest priority).
   • All access to selected sensitive systems.
   • Third-party access to your environment (MSP, support vendors, hosted admin access).
2. Define review mechanics:
   • System owner attests that each listed user/service account still needs access.
   • Security/GRC tracks completion, exceptions, and removals.
3. Require remediation tracking:
   • Remove unapproved access.
   • Fix role mapping or workflow gaps that caused the issue.
4. Retain proof:
   • Review export, owner sign-off, ticket IDs for removals, and exception approvals ¹.

How to make reviews survivable: keep the first cycle small and high-risk (privileged + EHR + remote access). Expand scope after owners see the process is manageable.

7) Build monitoring and response hooks

1. Log authentication and authorization events for sensitive systems where possible.
2. Alert on:
   • Privilege escalations.
   • New admin accounts or new privileged group membership.
   • Dormant accounts reactivated.
3. Tie alerts to incident response workflows ¹.

Required evidence and artifacts to retain

Keep artifacts in a form you can hand to an auditor without rework:

Core documents

• Access Management Policy and supporting standards (least privilege, MFA, privileged access, service accounts) ¹.
• Sensitive systems inventory with owners and access model.
• Access request/approval workflow documentation (SOPs, screenshots, forms).
• Joiner/Mover/Leaver procedures (HR-triggered provisioning and deprovisioning steps).

Operational records

• Sample access tickets showing request, approval, implementation, and closure.
• MFA enforcement configuration evidence (IdP policies, conditional access rules).
• Privileged access evidence (admin account inventory, PAM reports, vault logs).
• Access review packages:
  • User/access listing used for the review.
  • Reviewer attestation (system owner sign-off).
  • Findings log and remediation tickets.
  • Exceptions register with approval and expiration/revalidation approach ¹.

Third-party access

• List of third parties with network or administrative access.
• Contractual/security requirements for access controls where applicable.
• Access reviews that include third-party accounts ¹.

Common exam/audit questions and hangups

Use these to pre-brief system owners and IT:

1. “Define ‘sensitive systems.’ Where is the list, and who owns it?” Hangup: a vague definition with no inventory.
2. “Show me how access is granted to System X, including approvals.” Hangup: admins grant access by email/Teams with no ticket.
3. “How do you remove access when someone leaves or changes roles?” Hangup: deprovisioning is manual and inconsistent across apps.
4. “Show your most recent access review and evidence of remediation.” Hangup: reviews exist as spreadsheets without sign-off or follow-through.
5. “How do you control privileged access and service accounts?” Hangup: shared admin credentials, unknown service account owners ¹.

Frequent implementation mistakes and how to avoid them

• Mistake: treating MFA as “done” because it’s on VPN. Fix: cover cloud admin, EHR administrative access paths, and remote support tools; document exceptions ¹.
• Mistake: access reviews that don’t remove access. Fix: require a remediation ticket for each removal and track closure to completion.
• Mistake: no service-account governance. Fix: require an owner and purpose for every non-human identity; review these accounts with privileged access reviews.
• Mistake: scoping too broadly on day one. Fix: start with the systems most likely to cause harm if compromised; expand iteratively.
• Mistake: “rubber-stamp” approvals by managers who don’t understand system roles. Fix: add system owner approval for sensitive systems, and provide role descriptions in the request form ¹.

Enforcement context and risk implications

HICP is HHS 405(d) cybersecurity practice guidance rather than a penalty schedule in the provided source material ¹. Operationally, weak access management increases the likelihood and blast radius of common events: unauthorized access to sensitive data, misuse of privileged accounts, and operational disruption from compromised admin credentials. Your risk posture improves most when you can prove access is (a) intentional, (b) minimal, and (c) periodically revalidated with removals documented.

Practical 30/60/90-day execution plan

Days 1–30: Define scope and stop the bleeding

• Assign owners: IAM owner, privileged access owner, and GRC control owner.
• Publish a first-pass sensitive systems list and owners.
• Require tickets for all new access to sensitive systems (even if fulfillment remains manual).
• Turn on MFA for the highest-risk access paths you control quickly (IdP/VPN/admin portals); document any exceptions and compensating controls.
• Inventory privileged groups and admin accounts in directory services and your top sensitive systems ¹.

Deliverables: sensitive systems inventory v1, access request workflow, MFA policy/config evidence, privileged identity inventory.

Days 31–60: Standardize and begin recertification

• Define role/group models for the top systems; migrate ad-hoc grants to groups where possible.
• Implement joiner/mover/leaver triggers with HR and IT; test deprovisioning end-to-end.
• Launch your first access review:
  • Privileged accounts across core systems
  • Third-party accounts with admin or network access
• Create an exceptions register with approvals and review dates ¹.

Deliverables: first access review package with sign-off, remediation tickets, exceptions register.

Days 61–90: Expand coverage and make it repeatable

• Expand access reviews to additional sensitive systems based on your inventory.
• Formalize service account governance (owner, purpose, credential storage/rotation approach).
• Add monitoring for privilege changes and new admin accounts; route alerts to incident response.
• Run a tabletop audit: pick one sensitive system and walk an auditor through request, approval, provisioning evidence, MFA enforcement, access review, and a completed removal ¹.

Deliverables: access review cadence calendar, service account registry, alerting evidence, audit walkthrough packet.

Where Daydream fits (earned, operational)

Most access management programs fail on evidence assembly and recertification follow-through. Daydream can help you keep the sensitive systems inventory, access review cycles, exceptions, and remediation tickets organized in one control narrative so you can answer audit questions without rebuilding context each quarter. Use it as the system of record for “what we reviewed, what we found, what we fixed,” aligned to HICP-03 language ¹.

Frequently Asked Questions

What counts as a “sensitive system” for HICP access management?

Start with any system that stores or processes PHI, any system with administrative control over infrastructure, and any system whose disruption would materially impact clinical or revenue operations. Document your definition and keep a living inventory with clear ownership ¹.

Do service accounts and integrations fall under the access management requirement?

Yes. The text covers “user/system access,” so non-human identities need ownership, purpose, and review just like human accounts. Include them in privileged access inventories and recertifications ¹.

How often should we perform access recertification?

HICP-03 requires that you “review” access but does not prescribe a cadence in the provided source material ¹. Set a risk-based schedule, prioritize privileged access and your highest-impact systems, and be consistent.

What evidence is most persuasive to auditors for access management?

Completed access reviews with system owner sign-off plus proof of removals (tickets closed, group membership changes, account disables) usually carry the most weight. Pair that with MFA policy configuration and a clear inventory of sensitive systems ¹.

We rely on a third party to administer a hosted clinical app. Are we still responsible for access?

You are responsible for controlling and reviewing access paths you govern (your workforce accounts, SSO roles, and any administrative access you can grant). For third-party administrator access, require contractual/access terms where possible and include their accounts in your access review population if they touch your environment ¹.

What if a legacy system cannot support MFA or role-based access control?

Document the limitation, restrict access as much as the system allows, add compensating controls (network segmentation, jump hosts, tighter approvals, enhanced logging), and increase review rigor for that system. Track the modernization plan as a risk treatment item ¹.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. HHS 405(d) HICP, 2026