Identity Governance Framework

HICP Practice 6.1 requires you to establish an identity governance framework: documented policies and operating routines that control the full identity lifecycle (create, change, suspend, delete) across every system, not just your EHR. Operationalize it by defining ownership, standard lifecycle events, authoritative sources, access rules, and evidence that provisioning and deprovisioning happen consistently. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Key takeaways:

• Your framework must cover the entire identity lifecycle across all systems, including third parties and non-human identities. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Auditors will test whether your written policies match actual joiner/mover/leaver outcomes in system logs and tickets.
• “Across all systems” is the hard part; success requires an inventory, authoritative sources, and a repeatable workflow.

An identity governance framework is the control plane for who gets access, why they have it, and how you prove it was granted and removed correctly. HICP Practice 6.1 is explicit: you must establish a framework that defines policies for identity lifecycle management across all systems. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices) For a Compliance Officer, CCO, or GRC lead, the fastest path is to turn that sentence into a small set of enforceable policy statements, assign control owners, and connect them to day-to-day operations (HR onboarding, contractor intake, privileged access, and termination).

This page focuses on requirement-level implementation. It is not a generic IAM overview. The goal is to help you produce (1) a governance model, (2) lifecycle standards that systems and teams can follow, and (3) durable evidence. You will also see common audit hangups: “we have SSO” without lifecycle controls, systems missing from scope, and contractor offboarding gaps.

HICP is a cybersecurity practices framework for healthcare; treat this requirement as a baseline expectation that supports HIPAA-aligned security outcomes, even when a regulator does not “mandate HICP” by name. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Regulatory text

Excerpt (requirement): “Establish an identity governance framework defining policies for identity lifecycle management across all systems.” (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Operator interpretation: You need documented governance (who owns decisions, how exceptions work, what gets reviewed) plus lifecycle policies (how identities are created, modified, suspended, and deleted) that apply to every system in scope. “Across all systems” means you cannot stop at your directory, SSO, or EHR; you must include clinical apps, SaaS, infrastructure, endpoint tools, data platforms, and relevant third-party administered systems where your workforce gains access. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Plain-English requirement

Create a single, organization-wide way to manage identities from cradle to grave. That includes:

• Who counts as an identity: employees, clinicians, temps, contractors, students/trainees, volunteers, break-glass users, service accounts, APIs, bots, and system-to-system accounts where applicable.
• What “lifecycle” means: request/approval, provisioning, role change, privilege elevation, periodic validation, suspension (leave of absence), termination, and cleanup.
• How you prove it: tickets, approvals, system logs, access reviews, exception registers, and an inventory that shows coverage.

Who it applies to (entity and operational context)

Entity types: healthcare organizations and health IT vendors. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Operational contexts that trigger the requirement:

• You manage access to ePHI-adjacent systems, clinical systems, revenue cycle systems, patient engagement portals, analytics platforms, or infrastructure that supports them.
• You onboard/offboard workforce members or contractors.
• You have privileged administrators (system admins, cloud admins, database admins) or outsourced IT operations.
• You run multiple identity stores (AD, Entra ID, app-local accounts) and need consistent controls.

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

1) Define governance and scope in writing

Create a short Identity Governance Framework document (or charter) that answers:

• Scope: “all systems” definition, including SaaS and legacy apps, and how you handle systems you cannot integrate yet. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Roles and decision rights: IAM owner, HR owner (authoritative data), IT app owners, security, compliance, and business approvers.
• Policy hierarchy: lifecycle policy, access request/approval policy, privileged access policy, service account policy, exception policy.
• Enforcement model: what is mandatory vs. transitional, and what evidence is required for each lifecycle event.

Practical tip: Write “minimum controls for any system before go-live” (for example, unique IDs, documented owner, offboarding path, and logging). Keep it short enough that app owners will read it.

2) Standardize identity lifecycle events (JML + beyond)

Document a single lifecycle standard that every system must map to:

• Joiner: identity creation tied to an approved request and an authoritative source (commonly HR for employees, vendor management/procurement for contractors, or a clinical credentialing process).
• Mover: role changes that add/remove entitlements; define who can approve and what triggers revalidation.
• Leaver: termination and contract end; define required timelines qualitatively (for example, “promptly upon termination”) if you cannot cite exact numbers from an authoritative source.
• Suspension: leave of absence, disciplinary hold, seasonal workforce.
• Emergency access: break-glass controls with logging and post-event review.

Your framework should also address non-human identities:

• Service accounts: ownership, purpose, credential storage, rotation approach, and disablement procedure.
• API keys and app tokens: issuance, storage, and revocation.
• Shared accounts: define as prohibited except for documented exceptions, then track those exceptions.

3) Establish authoritative sources and system inventory

You cannot manage “across all systems” without two inventories:

1. Authoritative identity sources: where identity truth originates for each population (workforce, contractors, affiliates).
2. Access surface inventory: each system that has authentication and authorization, its owner, and how accounts are created/removed.

Minimum fields for the access surface inventory:

• System name, owner, data sensitivity (at least “ePHI involved: yes/no”), auth method (SSO/local), provisioning method (manual/automated), deprovisioning method, and logging location.

4) Implement consistent provisioning/deprovisioning workflows

Pick a workflow pattern you can enforce:

• Centralized request intake: service desk portal, GRC workflow, or ITSM. Require manager + system owner approval for access.
• Provisioning execution: IAM team or system admin completes request; automation where possible, manual with evidence where not.
• Deprovisioning execution: triggered by HR event, contract end date, or termination ticket; validate completion with system reports.

Where tools exist, define how they connect:

• Directory/SSO for authentication, with app role assignment tied to group membership.
• Privileged access process for admin roles (separate approvals, session controls if available).
• Access reviews for high-risk systems and privileged groups.

If you are using Daydream for third-party risk and due diligence workflows, treat identity governance as a “proof-ready” control area: store the framework, map systems to lifecycle methods, and attach evidence from tickets, access reviews, and app owner attestations so audits do not turn into spreadsheet archaeology.

5) Build the evidence loop: access reviews + exceptions

Your framework should require periodic validation of access for:

• Privileged admin roles
• High-risk clinical or data systems
• Remote access pathways
• Third-party administered access (MSPs, hosted EHR support, billing vendors)

Maintain an exception register that captures:

• What policy is being excepted (for example, “no shared accounts”)
• Business justification
• Compensating controls (logging, MFA, enhanced monitoring)
• Approval and expiration criteria

6) Test operating effectiveness with sampling

Before an audit does it for you, sample real lifecycle events:

• A joiner: show request, approval, provisioning steps, and first login.
• A mover: show role change approvals and removal of old entitlements.
• A leaver: show termination trigger and evidence of account disablement across key systems.
• A contractor: show contract end date and corresponding access removal.

Make failures actionable: update the workflow, fix the inventory, or tighten policy.

Required evidence and artifacts to retain

Keep evidence in a way you can produce quickly:

• Identity Governance Framework document/charter. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Identity lifecycle management policy (JML + suspension + deletion). (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• System inventory showing “all systems” scope, owners, and lifecycle method.
• Authoritative source definition for each identity population.
• Access request and approval records (tickets/workflows) for a representative set of systems.
• Deprovisioning evidence (HR trigger, termination ticket, disablement logs, app account reports).
• Privileged access approvals and logs for admin access changes.
• Access review records (attestations, remediation tickets, completion proof).
• Exception register with approvals and compensating controls.

Common exam/audit questions and hangups

Expect questions that probe coverage and proof:

• “Show me your identity governance framework and who approves exceptions.” (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• “Which systems are in scope, and how do you know the list is complete?”
• “How do you ensure termination removes access from apps that are not on SSO?”
• “How do you govern contractor identities and third-party support accounts?”
• “How do you manage service accounts and API keys?”
• “Show evidence from a recent joiner and leaver event across multiple systems.”

Hangup pattern: the policy says “all systems,” but the inventory excludes departmental SaaS or legacy systems with local accounts. That gap becomes an audit finding because it breaks the “across all systems” requirement. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

Frequent implementation mistakes and how to avoid them

• Mistake: Treating SSO as identity governance. SSO helps authentication, but lifecycle governance requires approval, entitlement control, offboarding, and evidence across systems.

  • Avoid it: require each system owner to document how provisioning and deprovisioning occur, even for local accounts.

• Mistake: Ignoring non-human identities.

  • Avoid it: add service accounts, tokens, and integrations to scope, with an owner and disablement process.

• Mistake: Contractor offboarding is “someone else’s job.”

  • Avoid it: tie contractor access to contract dates and require a sponsor; route end-of-engagement triggers through the same deprovisioning workflow.

• Mistake: No exception discipline.

  • Avoid it: run all exceptions through a register with expiry conditions and periodic review.

• Mistake: No operating tests.

  • Avoid it: periodically sample JML events and track corrective actions to closure.

Enforcement context and risk implications

No public enforcement cases were provided for this specific HICP practice in the source material. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices) Operationally, identity lifecycle failures create predictable risk: orphaned accounts, excessive privileges, and untracked third-party access paths. Those conditions commonly drive audit findings because they are easy to test: auditors can compare HR rosters to active accounts and look for mismatches, or request proof that a terminated user cannot access sensitive systems.

A practical 30/60/90-day execution plan

Because the source materials do not provide time-based implementation requirements, treat the timeline below as a practical rollout pattern, not a regulatory deadline. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

First 30 days (Immediate)

• Assign an executive owner for the identity governance framework and name control owners for HR, IAM, and key system groups.
• Draft and approve the framework/charter and lifecycle policy set. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)
• Build an initial system inventory focusing on high-risk systems and remote access pathways.
• Define authoritative sources for employees and contractors; document triggers for joiner/leaver events.

Days 31–60 (Near-term)

• Standardize access request and approval workflow (ITSM or documented equivalent).
• Implement or tighten deprovisioning triggers from HR and contractor management.
• Stand up an exception register and require it for shared accounts or non-integrated legacy systems.
• Run a first access review for privileged groups and remediate findings.

Days 61–90 (Operationalize and prove)

• Expand inventory coverage to remaining systems, including departmental SaaS and legacy apps.
• Add non-human identity standards (service accounts, tokens) and require ownership and disablement procedures.
• Conduct sampling tests for joiner/mover/leaver events and document corrective actions.
• Package evidence for audit: framework, policies, inventory, sample tickets, review outputs, and exception log.

Frequently Asked Questions

Does “across all systems” mean every single application, including small SaaS tools?

Yes, the requirement text is explicit about lifecycle management across all systems. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices) If you cannot integrate a tool, document the manual lifecycle steps, owner, and evidence you will retain.

We outsource IT to a third party. Are we still accountable for identity lifecycle controls?

You remain accountable for having a framework and for confirming it operates for systems in your environment. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices) Put lifecycle requirements in the contract and collect evidence (tickets, reports, attestations) from the provider.

What is the minimum “framework” an auditor will accept?

A written governance document plus lifecycle policies that define how identities are created, modified, suspended, and deleted, and who approves and reviews access. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices) Auditors then validate it against real events and system evidence.

How do we handle clinical affiliates or rotating residents with complex schedules?

Define a population-specific authoritative source (credentialing/medical education office) and require sponsorship plus end-date tracking. Keep evidence that access is reviewed or removed when rotations end.

Do service accounts and API keys fall under identity lifecycle management?

Treat them as identities with an owner, purpose, issuance method, and disablement process, then keep evidence of reviews and revocations. This is the only practical way to meet “lifecycle” expectations across modern systems. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)

What evidence is most persuasive during audits?

Lifecycle samples that connect the trigger (HR/contractor event) to approvals, provisioning actions, and system logs showing access was granted or removed. Pair that with an inventory showing coverage across systems. (HICP 2023 - 405(d) Health Industry Cybersecurity Practices)