Removal of Access Rights

“Removal of access rights” is a deceptively simple control that fails in messy places: shadow IT, direct logins outside SSO, orphaned accounts, and third-party access that outlives the contract. HITRUST CSF v11 02.i requires that access rights for employees, contractors, and third-party users be removed when the relationship ends, and adjusted when roles change, in a timely manner ¹.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing this requirement is to (1) define what “access” includes in your environment, (2) define which lifecycle events trigger removal or modification, (3) implement a consistent workflow (preferably automated) that executes deprovisioning across systems, and (4) prove it with reliable artifacts.

This page gives requirement-level implementation guidance you can hand to IAM, IT, Security Operations, HR, and third-party owners. It focuses on building an auditable process that holds up under HITRUST assessment scrutiny and reduces real operational risk from lingering credentials.

Regulatory text

HITRUST CSF v11 02.i states: “The access rights of all employees, contractors, and third-party users to information and information processing facilities shall be removed upon termination of their employment, contract, or agreement, or adjusted upon change. Access rights shall be removed or modified in a timely manner.” ¹

What this means for an operator

• You need a defined, repeatable process that responds to two categories of events:
  1. Termination/contract end: remove access rights.
  2. Change (role change, team change, privilege change, scope change): adjust access rights (often reduction, sometimes addition with proper approval).
• “Access rights” is broader than an Active Directory account. It includes any mechanism that can reach information or systems: application accounts, SSO sessions, VPN, SaaS roles, local accounts, API tokens, SSH keys, service accounts (where tied to a person), and privileged access.

Plain-English interpretation of the requirement

If someone no longer has a valid business relationship with you, they should not be able to log in or use credentials to reach your data or systems. If someone’s job changes, their access must change with it. You must do this quickly enough that a reasonable assessor would agree you are not leaving avoidable windows of access.

Who it applies to (entity and operational context)

Entity scope: All organizations aligning to HITRUST CSF v11. ¹

User populations in scope

• Employees (full-time, part-time, interns)
• Contractors (staff augmentation, consultants)
• Third-party users (vendors, service providers, business partners, offshore support, auditors with login access)

Operational contexts that matter in practice

• Centralized IAM (IdP/SSO) plus separate direct logins to certain systems
• Privileged access (admin roles, break-glass access)
• Third-party remote access (VPN, VDI, jump boxes, support portals)
• Cloud and SaaS sprawl (apps provisioned outside IT)
• M&A / divestitures (identity sources and directories in transition)

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

1) Define “access rights” for your environment (write it down)

Create a control definition that explicitly lists what must be removed/adjusted:

• Identity accounts (IdP, directory services)
• Application accounts (SSO and non-SSO)
• Privileged roles and admin group memberships
• Remote access methods (VPN, VDI, SSH bastions)
• API tokens, personal access tokens, access keys
• Shared accounts (where used) and how ownership changes are handled
• Physical access badges, if they grant entry to areas with information processing facilities

This becomes your assessor-facing boundary and prevents the “we disabled AD, we’re done” misunderstanding.

2) Establish authoritative triggers (the events that start the clock)

Map each population to an authoritative source and trigger:

• Employees: HRIS termination and job-change events
• Contractors: contractor management system, HR vendor feed, or the internal sponsor’s attestation
• Third parties: procurement/TPRM contract end date + third-party owner notification + offboarding checklist

Avoid relying on “manager emails IT” as the trigger. Make it an input, not the system of record.

3) Build a deprovisioning workflow that covers every access path

A workable pattern:

1. Event received (termination or change) in ticketing or IAM workflow tool.
2. Immediate actions (core identity):
   • Disable account in IdP/directory
   • Revoke active sessions
   • Remove from all groups that grant access (especially privileged groups)
3. Downstream actions (applications and infrastructure):
   • Disable/remove accounts in non-SSO apps
   • Revoke API tokens/keys tied to the user
   • Remove SSH keys from authorized_keys and key management systems
   • Remove from PAM vaults and privileged role assignments
4. Third-party specific actions:
   • Disable remote access pathways (VPN accounts, VDI entitlements)
   • Remove access to support portals and shared collaboration spaces containing sensitive data
5. Verification step:
   • Evidence that the account is disabled and entitlements removed (screenshots, system logs, exported reports)
   • Confirmation that downstream systems completed successfully, not just “ticket closed”

For role changes, use a similar workflow but start with access reduction (remove old entitlements), then process additions through standard access request approvals.

4) Define “timely” in an internal standard you can defend

HITRUST requires timeliness but does not set a specific number in the excerpt provided ¹. You still need an internal SLA-style standard so teams execute consistently and you can test against it. Write a policy or standard that differentiates:

• Termination (especially involuntary) vs planned departure
• Privileged vs standard access
• High-risk systems (EHR, claims, financial, production cloud) vs low-risk systems

Keep it realistic for your tooling and staffing, then measure against it.

5) Handle exceptions explicitly (don’t let them float)

Common legitimate exceptions:

• Legal hold or eDiscovery preserving mailbox content (preserve data without preserving login capability)
• Transitional access during internal transfers (documented approvals)
• Shared/service accounts used by automation (should not be tied to a departing individual; migrate ownership)

Require:

• Documented business justification
• Compensating controls (PAM, additional monitoring)
• Expiration date and re-approval

6) Test the control continuously with targeted sampling

Build a recurring test that answers:

• Were terminated users removed/disabled per your standard?
• Were role changes followed by entitlement updates (especially removals)?
• Do any orphaned accounts exist in key systems?
• Do third-party accounts remain active after contract end?

A practical approach is to sample across populations (employee/contractor/third party) and across system types (IdP, SaaS, infrastructure, PAM).

7) Make it auditable with clean ownership

Assign accountable owners:

• HR/People Ops: event accuracy and timing
• IAM/Security: workflow and enforcement
• App/system owners: downstream deprovision completion for non-SSO systems
• Third-party relationship owners: contract-end offboarding initiation

If you need a system to coordinate this, Daydream can centralize the requirement, map systems in scope, assign owners, and collect evidence artifacts so you are not assembling proof manually during the assessment.

Required evidence and artifacts to retain

Keep evidence that shows trigger → action → completion:

Foundational documents

• Access control / IAM policy section covering removal and adjustment of access ¹
• Procedure or runbook for offboarding (employee, contractor, third party)
• RACI / ownership matrix for deprovisioning steps

Operational records (the audit gold)

• Termination/job-change report extract from HRIS (or equivalent) for sampled users
• Tickets/workflow records showing:
  • timestamp of trigger
  • actions taken (disable, group removal, token revocation)
  • completion timestamps
  • approvals for role changes
• System logs or admin reports proving:
  • account disabled in IdP/directory
  • entitlements removed in key applications
  • privileged access removed in PAM
• Exception register with approvals and expiry tracking
• Access recertification results (if you use them to catch drift)

Avoid “screenshots only” evidence if you can export reports or logs that show timestamps and identifiers.

Common exam/audit questions and hangups

Expect assessors to press on these points:

• “Show me three terminated users and prove their access was removed across all relevant systems.”
• “How do you remove third-party access when procurement ends a contract but the sponsor forgets?”
• “What does ‘timely’ mean here, and how do you measure it?”
• “Which systems are outside SSO, and how do you ensure deprovisioning there?”
• “How do you handle privileged access and break-glass accounts?”

Hangups usually come from incomplete system inventories, missing downstream evidence, and relying on manual emails.

Frequent implementation mistakes and how to avoid them

1. Disabling the directory account but leaving SaaS accounts active.
   Fix: maintain a list of non-SSO systems and require system owner confirmation for offboarding completion.

2. No control over third-party account sprawl.
   Fix: require third-party identity records (named individuals) and an owner; tie access to contract dates and periodic attestations.

3. Role changes add access but never remove it.
   Fix: implement “remove-first” change workflow and require manager attestation that old access is no longer needed.

4. Exceptions handled informally.
   Fix: create an exception workflow with documented justification and expiration, then test exceptions like any other control.

5. Service accounts owned by a person.
   Fix: assign service accounts to an application owner group, store credentials in PAM, and document rotation and usage monitoring.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Operationally, stale access is a direct path to unauthorized access after termination, third-party relationship changes, or internal job moves. The business impact is usually disproportionate to the effort required to fix the process: one missed deprovisioning can invalidate multiple “strong IAM” claims during an assessment.

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Publish a written standard defining “access rights,” in-scope systems, triggers, and owners ¹.
• Identify your authoritative sources for termination and change events by population.
• Build a non-SSO system register for applications that require separate deprovision steps.
• Create an exception register and require documented approvals and expirations.

Next 60 days (implement and connect)

• Implement or refine the offboarding workflow in your ticketing/IAM tooling with required fields for evidence.
• Add downstream deprovision tasks for non-SSO apps and privileged access.
• Train HR, IT, and third-party sponsors on triggers and required lead time for planned departures.
• Pilot testing: sample terminations and role changes; record gaps and assign remediation.

By 90 days (prove, measure, and harden)

• Operationalize a recurring control test (sampling + orphan checks for high-risk systems).
• Add metrics that matter operationally: completion vs your internal “timely” standard, exceptions open past expiry, systems with repeated failures.
• Hold system owners accountable for deprovision evidence in their platforms.
• Centralize evidence collection and control status tracking in Daydream to reduce audit scramble and keep artifacts consistent across teams.

Frequently Asked Questions

Does “removal of access rights” mean deleting accounts?

The requirement is to remove or adjust access upon termination or change and do so in a timely manner ¹. Deletion can be acceptable, but many organizations disable accounts first to preserve records, then delete later under a separate retention process.

How do we handle third-party users who share a generic login?

Treat shared accounts as a design exception: document justification, restrict permissions, store credentials in PAM, and rotate secrets when any individual with knowledge of the credentials leaves. Long term, migrate to named accounts so you can remove access per person.

What systems count as “information processing facilities”?

Interpret this as any system that stores, processes, or enables access to organizational information, including infrastructure, SaaS, endpoints, and administrative tooling ¹. Your control should define the specific system categories in scope for your environment.

What’s the minimum evidence an assessor will accept?

For a sample user, you need a clear trigger record (termination/change), proof of deprovision actions across key systems, and timestamps showing the actions occurred promptly relative to the trigger ¹. If you cannot show downstream system evidence, expect a finding.

How should we handle role changes where access must increase?

Process additions through normal access request approvals, but also remove prior entitlements tied to the old role. Keep an auditable record showing what changed, who approved it, and what was removed.

We rely on SSO. Do we still need app-by-app offboarding?

Yes for any system that permits direct login, maintains local roles, or has API tokens/keys that persist beyond SSO session revocation. Maintain a register of these systems and require explicit deprovision confirmation.

Footnotes

1. HITRUST CSF v11 Control Reference