Account Provisioning and Deprovisioning

To meet the account provisioning and deprovisioning requirement, you need a formal, auditable process that grants access only from approved requests and removes access quickly when a user changes roles or leaves. Operationally, this means defined request/approval workflows, identity-backed account creation, immediate offboarding actions, and retained evidence across systems. ¹

Key takeaways:

• Provision access only from an approved request tied to a role and a business owner. ¹
• Deprovision access promptly for role changes and terminations across all systems, not just your primary directory. ¹
• Keep artifacts that prove who approved access, what was granted, and when it was revoked. ¹

Account lifecycle control is one of the fastest ways to reduce preventable security and compliance exposure: most real incidents have a “how did they still have access?” moment. HICP Practice 3.4 sets a clear expectation: you must have formal processes to provision and deprovision accounts, and you must revoke access in a timely way when people change roles or depart. ¹

For a Compliance Officer, CCO, or GRC lead, the trap is treating this as “an IT ticketing thing.” Examiners and internal auditors usually test it as a governance capability: documented workflow, consistent execution, complete system coverage, and evidence you can produce without scrambling. Your goal is to make access changes routine, measurable, and reviewable.

This page translates HICP 3.4 into a requirement you can implement quickly: who must be involved, what to standardize, the minimum process steps, what evidence to retain, and where teams commonly fail (especially with shared accounts, third parties, and “shadow IT” SaaS).

Regulatory text

HICP Practice 3.4: “Establish formal processes for provisioning and deprovisioning user accounts, including timely revocation upon role change or termination.” ¹

What the operator must do:

• Define and document an account lifecycle process that covers requesting, approving, creating, changing, disabling, and deleting accounts. ¹
• Ensure provisioning happens based on approved access requests (not informal asks, ad hoc admin actions, or inherited access from a predecessor). ¹
• Ensure deprovisioning happens promptly when the user’s role changes or the user terminates, and that this revocation reaches every relevant system. ¹

Plain-English interpretation (requirement-level)

You must be able to prove three things on demand:

1. Only approved access gets granted. Someone accountable signs off, and the access matches a defined role or justified exception.
2. Access changes follow the person. When job responsibilities change, access changes with them.
3. Departure equals removal. Termination triggers removal or disablement everywhere the identity had access.

HICP does not prescribe a specific tool. It does require the process to be formal, repeatable, and timely for role changes and terminations. ¹

Who this applies to (entity and operational context)

Entity types in scope: Healthcare organizations and health IT vendors. ¹

Operationally, apply it anywhere a “user account” exists, including:

• Workforce identities (employees, clinicians, volunteers, students)
• Privileged administrators (domain admins, cloud admins, EHR admins)
• Third-party identities (contractors, vendor support, consultants)
• Non-human identities you still “provision” (service accounts, API keys where your process governs issuance)

Systems in scope: your directory/SSO, EHR and clinical apps, cloud consoles, SaaS tools, VPN, VDI, endpoint management, database consoles, ticketing/admin portals, and any local accounts on servers or appliances.

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

1) Define the lifecycle “source of truth” and owners

• Pick your system of record for identity (usually HR for employees; a vendor management or procurement intake for third parties).
• Assign control owners:
  • Process owner (IAM, IT Security, or GRC)
  • Access approvers (data/system owners)
  • HR/People Ops (joiner/mover/leaver triggers)
  • IT Helpdesk/IAM engineers (execution)
• Write the RACI for provisioning, modifications, and terminations.

Deliverable: an Access Management / Account Lifecycle SOP that names systems covered and who approves what.

2) Standardize access requests (and stop “side door” provisioning)

Minimum request form fields:

• Requestor and user identity (legal name, unique ID, email)
• System/application
• Requested role/group entitlements
• Business justification and ticket/reference
• Access start date and end date (required for third parties and temporary access)
• Approver (system owner) and any secondary approvals (e.g., privacy/security for sensitive roles)

Control expectation: no ticket, no access. If admins can create accounts directly, you still require a ticket reference in the account metadata or the change record.

3) Provisioning: implement a repeatable build pattern

For each system, define the “golden path”:

• Create identity in directory/SSO (or verify it already exists)
• Assign baseline groups based on role (RBAC)
• Add privileged roles only through separate approval
• Enforce MFA and minimum password standards consistent with your policy
• Notify the manager and system owner that access is active (this becomes evidence)

Practical tip: publish a role catalog (even if small) so access isn’t negotiated each time.

4) Movers (role changes): treat internal transfers as a high-risk event

Role change failures are common because people stay employed, so offboarding steps never trigger.

Your mover workflow should:

• Trigger automatically from HR changes or manager request
• Remove access not needed for the new role (especially privileged or sensitive application roles)
• Add new role-based access after approval
• Re-validate any privileged access as a fresh decision, not “keep what they had”

Evidence target: a single ticket or workflow trail showing removal and addition actions, with timestamps and approvals.

5) Leavers (terminations): execute a full revocation playbook

Build a termination checklist that distinguishes:

• Involuntary / immediate (same-day lockout)
• Voluntary / planned (scheduled disablement)
• Third-party end-of-engagement (contract end date driven)

Minimum technical actions:

• Disable directory/SSO account
• Revoke sessions/tokens where your platforms support it
• Remove from groups, especially privileged groups
• Disable or rotate credentials tied to the user (shared admin passwords, service accounts they knew)
• Transfer ownership of resources (mailbox, cloud drives, code repos, dashboards)
• Remove device access (MDM wipe/lock where appropriate)
• Confirm removal in critical downstream apps that do not follow SSO

This is where many programs fail: they disable SSO but forget local accounts, standalone SaaS, and break-glass access paths.

6) Cover third-party access explicitly

Third parties create edge cases:

• Sponsorship model (an internal owner is accountable for the third party identity)
• Time-bounded access by default (end date required)
• Separate approval for remote access/VPN/admin consoles
• Periodic confirmation that the third party still needs access (tie to contract status)

If your third party supports multiple healthcare customers, ensure your tenant-specific access controls prevent cross-customer access.

7) Make it auditable: logging, metrics, and sampling

Even without enforcement cases in your source pack, auditors usually test operation via sampling.

Set up:

• A monthly sample of provisioned accounts to confirm approved requests exist
• A monthly sample of terminated users to confirm revocation across key systems
• Exception tracking (who approved deviations and why)
• A short list of “crown jewel” systems with stricter checks (EHR admin, cloud admin, patient data stores)

If you use Daydream to manage control evidence, map each workflow step to an artifact type (ticket, approval, HR event, IAM log) and keep a standing evidence packet for audits.

Required evidence and artifacts to retain

Keep artifacts that let you reconstruct the lifecycle decision and the technical action:

Governance artifacts

• Account Provisioning/Deprovisioning Policy or Standard
• SOP/runbooks for joiner/mover/leaver
• RACI and list of system owners/approvers
• Role catalog / group-to-role mapping and privileged access criteria

Operational artifacts ¹

• Access request tickets with business justification
• Approval records (system owner approval; security/privacy approval where required)
• IAM/SSO logs showing account creation, group assignment, disablement
• HR termination/transfer record or authoritative trigger evidence
• Downstream system confirmation (screenshots or logs) for systems not integrated with SSO
• Third-party sponsorship attestations and end-date controls
• Exception register (documented, time-bounded, approved)

Retention period is not specified in the provided HICP excerpt; align to your internal retention schedule and other applicable obligations.

Common exam/audit questions and hangups

Auditors tend to ask questions that expose gaps between “policy” and “coverage”:

• Show a terminated user sample and prove access removal in every in-scope system.
• How do you detect and remove accounts that were created outside the formal process?
• What happens when HR is late, the manager forgets, or the termination is urgent?
• How do you handle privileged access provisioning differently from standard access?
• How do you manage third-party accounts, shared accounts, and service accounts?
• Which systems are not connected to SSO, and how do you control them?

Hangup to anticipate: teams can produce tickets but not system logs, or they can show SSO disablement but not removal in standalone apps.

Frequent implementation mistakes (and how to avoid them)

1. SSO-only thinking. Disablement in SSO does not remove access in apps with local accounts. Maintain an “apps not federated” list with explicit offboarding steps.
2. No system owners. If nobody “owns” the application, approvals become rubber stamps. Assign a business owner per system and make approvals their job.
3. Role sprawl. Hundreds of bespoke entitlements lead to manual errors. Start with a small role catalog and require exceptions to be time-bounded.
4. Third-party access without end dates. Make end dates mandatory and require sponsorship renewal.
5. Orphaned privileged access. Require a separate approval path and periodic confirmation for admin roles.
6. Evidence gaps. If you can’t produce proof quickly, the process isn’t operationalized. Build evidence capture into the workflow (ticket templates, IAM exports, standard screenshots).

Enforcement context and risk implications

No public enforcement case sources were provided in your source catalog, so this page does not cite specific actions. Practically, weak provisioning and deprovisioning creates common failure modes: unauthorized access from stale accounts, inappropriate access after a role change, and third-party access persisting after the engagement ends. Those failures can become security incidents and can also undermine your ability to pass audits tied to access management.

Practical execution plan (30/60/90)

Use phased execution so you can show progress quickly without pretending you covered every edge case on day one.

First 30 days (stabilize and define)

• Inventory in-scope systems and identify which follow SSO vs. local accounts.
• Publish the lifecycle SOP (joiner/mover/leaver) and the approval model.
• Implement a standard access request template in your ticketing system.
• Define the termination “rapid disable” procedure for urgent offboarding.
• Start evidence collection with a small sample to confirm you can prove the control works.

Days 31–60 (operationalize and expand coverage)

• Build role/group mappings for common jobs and privileged roles.
• Integrate HR triggers where feasible; otherwise standardize manager notifications.
• Implement third-party sponsorship + end-date requirements.
• Create the “non-federated apps” offboarding checklist and assign owners.
• Begin a recurring QA review (sampling) and track exceptions.

Days 61–90 (harden and audit-ready)

• Reduce manual steps with IAM workflows where possible.
• Add automated alerts for dormant accounts, failed deprovisioning steps, or privileged group changes.
• Run a tabletop test: simulate an urgent termination and document outcomes.
• Prepare an audit packet: policy, SOP, RACI, system list, and recent samples with artifacts.
• If you use Daydream, convert the audit packet into a standing control collection so evidence stays current.

Frequently Asked Questions

Do we need a tool to comply with the account provisioning and deprovisioning requirement?

No specific tool is required by the provided HICP text. You do need a formal process with approvals, execution steps, and evidence you can produce consistently. ¹

What counts as “timely” revocation on termination or role change?

HICP Practice 3.4 requires timely revocation but does not define a specific timeframe in the provided excerpt. Set internal SLAs by risk level (for example, immediate for privileged access) and enforce them with workflow tracking. ¹

How do we handle systems that are not connected to SSO?

Treat them as explicitly in scope and maintain a documented offboarding step for each system. Your evidence needs to show removal/disablement in those systems, not only in the directory. ¹

Do third-party users fall under this requirement?

Yes if they have user accounts in your environment, because the requirement is about provisioning and deprovisioning user accounts. Manage third-party accounts with sponsorship, approvals, and end dates, then revoke access when the engagement ends. ¹

What artifacts should we produce during an audit sample?

For each sampled user, provide the access request, documented approval, and technical evidence of provisioning or deprovisioning (IAM logs or system screenshots for standalone apps). The goal is a traceable chain from request to action. ¹

How do we prevent “re-hiring” from restoring old access?

Require re-hires to follow the same approval-based provisioning workflow as new hires, with roles reassigned based on current job duties. Block copying prior entitlements without a documented justification and approval. ¹

Footnotes

1. HICP 2023 - 405(d) Health Industry Cybersecurity Practices