Termination Responsibilities

“Termination responsibilities requirement” sounds simple until you map it to real operations. People don’t just leave; they change roles, switch teams, move to a new country, become a contractor, or rotate into privileged access. Each change can create orphaned accounts, retained devices, or lingering access paths into sensitive systems and data.

HITRUST CSF v11 02.g focuses on two things: (1) clearly defined and assigned responsibilities, and (2) procedures that properly manage departures or changes, including returning assets and revoking access rights. ¹ That scope explicitly includes employees, contractors, and third-party users, so you need a process that works across HR systems, identity platforms, endpoint management, and application owners.

This page translates the control into an operator-ready playbook: who owns what, the minimum workflow steps, what evidence to keep, and the audit questions you should expect. If you already have an HR offboarding checklist, you’ll likely need to harden it with access-focused controls, closure criteria, and system-of-record evidence.

Regulatory text

HITRUST CSF v11 02.g requires: “Responsibilities for performing employment termination or change of employment shall be clearly defined and assigned. Procedures shall ensure that the departure or change of an employee, contractor, or third-party user is properly managed, including the return of assets and revocation of access rights.” ¹

Operator interpretation:

• You need named roles/teams accountable for offboarding and job changes (not “IT handles it”).
• You need a repeatable procedure (a workflow, not tribal knowledge) that covers:
  • Access revocation across identity, endpoints, SaaS apps, and privileged access
  • Asset return across laptops, badges, tokens, keys, media, and any special equipment
• You must apply it to employees, contractors, and third-party users. ¹

Plain-English requirement

You must be able to answer, with evidence: “When someone leaves or changes roles, who does what, and how do you ensure all access is removed and assets are recovered every time?”

This is a control about accountability + execution quality. Policies alone do not satisfy it. Auditors look for a closed-loop process: trigger → tasks → completion verification → exceptions documented.

Who it applies to

Entity scope: All organizations using HITRUST CSF. ¹

Operational scope (who and what events):

• Users covered: employees, contractors, consultants, temporary staff, interns, and third-party users with access to your systems or facilities. ¹
• Events covered:
  • Termination (voluntary/involuntary)
  • Contract end or disengagement
  • Internal transfer, promotion, demotion
  • Change from employee to contractor (or the reverse)
  • Any change that affects entitlements (especially privileged/admin access)

Systems in scope (typical):

• Identity provider / directory (SSO, AD/Azure AD/Okta equivalents)
• Email and collaboration platforms
• Ticketing/ITSM
• Endpoint management and encryption
• VPN and network access
• SaaS applications and line-of-business systems
• Privileged access management (if present)
• Physical access/badging

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

1) Assign responsibilities (RACI-level clarity)

Create a simple responsibility map that covers, at minimum:

• HR (or People Ops): initiates offboarding/job-change event, confirms last working day, confirms worker type and manager, triggers workflow.
• Hiring manager / sponsor: confirms access needed until last day, identifies unique assets or apps, confirms handoff of work, approves exceptions.
• IT Service Desk / IAM team: executes identity actions (disable accounts, remove groups, reset tokens, revoke sessions where supported).
• Security: defines deprovisioning standards, reviews exceptions, validates closure for high-risk roles.
• App owners: confirm removal from non-SSO apps and specialty systems (where central IAM cannot enforce).
• Facilities: handles badges/keys and physical access.

Make ownership explicit for contractors and third-party users. In practice, this is where gaps hide.

2) Define the offboarding and job-change procedure as a workflow

Write one procedure with two entry paths:

• Termination/offboarding
• Change of employment (role change or employment status change)

Each path should produce trackable tasks with closure criteria. Minimum steps:

A. Trigger and identity correlation

• Trigger comes from HR system, contractor management, or sponsor request.
• Required identifiers: legal name, username(s), email, worker type, manager, last day, locations.
• Confirm whether the user has privileged roles or sensitive system access.

B. Access revocation (core)

• Disable primary identity and block SSO at termination effective time.
• Remove from role-based groups and shared mailbox access.
• Revoke VPN, Wi‑Fi, and remote access.
• For job changes: remove old role entitlements and add new role entitlements based on approved access request.

C. Privileged and high-risk access removal

• Remove admin roles and privileged groups.
• Rotate shared credentials where the departing user knew them (service/team accounts, break-glass processes, local admin passwords, vault access).
• Confirm removal from production systems, security tooling, and cloud consoles if applicable.

D. Application-specific cleanup

• For apps not governed by SSO/group provisioning: assign an app owner task to remove the user and confirm completion.
• Handle external sharing: remove from external collaboration spaces and revoke shared links if your tooling supports it.

E. Asset return and data handling

• Recover laptops, phones, badges, hardware tokens, removable media, keys.
• Confirm device wipe/lock where appropriate and supported by your tooling.
• Capture asset status: returned, wiped, redeployed, lost. Document exceptions and escalation.

F. Closeout and verification

• Verify the ticket has: completed tasks, timestamps, owners, and exception approvals.
• For sensitive roles: require a secondary review (Security or IAM lead) before closure.

3) Define exception handling (because it will happen)

Document how you handle:

• Immediate termination with no notice
• Employees on leave who later separate
• Contractor offboarding where the staffing firm “owns” HR steps
• Lost/unreturned assets
• Legal holds or investigations that require preserving accounts/data

Your procedure should state who can approve an exception, what compensating controls exist (for example, immediate disablement plus later asset recovery), and where the exception record is stored.

4) Operationalize with tooling (keep it auditable)

You need a system of record for offboarding completion. Most teams use an ITSM ticket tied to the HR trigger.

If you want to reduce manual chase-down, Daydream can help by standardizing the control narrative, mapping the procedure to HITRUST evidence requests, and keeping artifact collection consistent across teams and business units. Keep the process ownership with operators; use Daydream to make audits less disruptive.

Required evidence and artifacts to retain

Auditors typically want evidence in three buckets: governance, execution, and completeness.

Governance (definition of responsibilities)

• Offboarding and job-change policy/procedure document
• RACI or responsibility matrix (even a table in the procedure)
• Role definitions for HR/IT/Security/app owners
• Training or internal communications showing stakeholders know the process (optional but useful)

Execution (proof you ran the process)

For a sample of terminations and job changes:

• HR or sponsor trigger record (HR event, contractor end notice, or request)
• ITSM ticket(s) showing tasks, assignees, timestamps, completion
• Identity system logs/screenshots showing disablement and group removal
• PAM or admin role removal evidence (where applicable)
• App-owner confirmations for non-SSO systems
• Asset return records from asset management or facilities badge system
• Exception approvals and compensating control documentation

Completeness (proving coverage)

• List of systems/apps in scope with ownership (an application inventory slice)
• Joiner/mover/leaver checklist mapped to those systems
• Periodic reconciliation report (for example, comparing active accounts to active workforce list) when you have it available as part of your operating model

Common exam/audit questions and hangups

Expect these lines of inquiry:

• “Show me who is responsible for each offboarding step. Where is that documented?” ¹
• “Provide samples of terminations and internal transfers. Prove access was revoked and assets returned.” ¹
• “How do you handle contractors and third-party users? Who initiates their offboarding?”
• “How do you ensure removal from apps that are not connected to SSO?”
• “What happens if a manager asks to keep access active after the last day?”
• “How do you remove privileged access and rotate shared credentials?”

Hangup that drives findings: you can show disabling the main account, but you cannot show deprovisioning in “long tail” apps or physical access systems.

Frequent implementation mistakes (and how to avoid them)

1. Only covering termination, not role change.
   Fix: treat “mover” events as high risk. Require explicit entitlement removal from the old role and approval-based add for the new role.

2. No single owner for closure.
   Fix: assign a ticket owner (often IAM or Service Desk) accountable for closing only after all tasks are complete.

3. Assuming SSO equals complete deprovisioning.
   Fix: maintain a list of non-SSO apps and route removal tasks to app owners.

4. Ignoring third-party users.
   Fix: require a sponsor for every third-party user and make sponsor-driven offboarding mandatory at contract end.

5. Asset return handled informally.
   Fix: tie asset recovery to the same offboarding workflow and capture status in an asset system or ITSM ticket.

Risk implications (why auditors care)

Failures here translate into:

• Orphaned accounts that remain valid after separation
• Ex-employees retaining remote access paths
• Contractors keeping access beyond the engagement
• Unreturned devices with sensitive data exposure
• Privileged access persistence (highest impact)

Even without a breach, weak termination controls create audit findings because they undermine access control effectiveness across the environment.

A practical 30/60/90-day execution plan

First 30 days (stabilize the basics)

• Publish a single termination + job-change procedure with named owners. ¹
• Implement an ITSM workflow template with required fields and task checklist.
• Build the “systems to deprovision” list for core identity, VPN, email, and your highest-risk apps.
• Start collecting evidence for a small sample set of recent offboarding events to validate you can produce artifacts quickly.

Days 31–60 (close coverage gaps)

• Add non-SSO app deprovisioning tasks with app owner assignments.
• Add contractor/third-party user offboarding triggers via sponsor or procurement/third-party management.
• Define exception paths (lost assets, legal hold, urgent termination) with approval requirements.
• Add privileged access removal and shared credential rotation steps where relevant.

Days 61–90 (make it durable)

• Implement a closure review for sensitive roles (Security/IAM review before ticket closure).
• Add reconciliation checks between workforce lists and active accounts where your systems support it.
• Run a tabletop “urgent termination” test to validate timing, communications, and evidence capture.
• Package artifacts in an audit-ready format (Daydream can help you standardize evidence packets and reduce scramble during HITRUST testing).

Frequently Asked Questions

Do we need separate procedures for termination and internal transfers?

You can use one procedure with two paths, as long as responsibilities are clear and both termination and change-of-employment events drive access changes and asset handling. HITRUST explicitly includes “change of employment.” ¹

What counts as a “third-party user” for this requirement?

Any non-employee who has user-level or administrative access to your systems, apps, or facilities qualifies. That includes contractors, consultants, and partner staff with accounts. ¹

If we disable the SSO account, is that enough to show access revocation?

Often no. SSO disablement is strong evidence for SSO-managed apps, but you still need proof for systems not governed by SSO, direct database accounts, local admin access, and physical access.

How do we handle shared accounts and team credentials during offboarding?

Treat them as a special step: rotate or revoke anything the departing user could still use, and record who approved and completed the change. Put ownership on the system owner or Security, not the departing user’s manager.

What evidence is “good enough” for auditors—screenshots or logs?

Either can work if it’s attributable and shows who/what/when. Many teams use a ticket plus identity system event logs; the key is consistent, repeatable evidence tied to each offboarding event.

How do we operationalize this across many apps without drowning in manual tasks?

Start by ranking apps by risk and access type, then automate provisioning/deprovisioning through your identity platform where possible and assign explicit app owners for the rest. Use Daydream to keep the evidence set consistent across app owners and audit cycles.

Footnotes

1. HITRUST CSF v11 Control Reference