164.308(a)(3)(ii)(C) termination procedures: evidence

164.308(a)(3)(ii)(C) termination procedures ask one question: how fast does access end when someone leaves?

A compliance lead or engineer who must show that leavers, contractors and people denied clearance lose access to ePHI needs to answer one question with records: when an arrangement ends, how quickly does every route into ePHI close? The termination specification in 45 CFR 164.308(a)(3)(ii)(C) calls for procedures that end a workforce member's access when their employment or other arrangement ends, or when a workforce clearance determination says access should stop. The risk it addresses is familiar: a former employee or contractor who still holds a login to an EHR, a file share, a billing portal or a cloud application can reach ePHI long after the business relationship has ended. The specification is addressable, which means the organization must assess whether it is reasonable and appropriate, implement it if so, and otherwise document why not and adopt an equivalent alternative measure if one is reasonable and appropriate, as set out in 45 CFR 164.306. Most organizations will implement it, so the practical work is writing the procedure and proving it runs.

The difficulty is rarely the written procedure. It is the number of places an account can exist. A single person may have directory credentials, VPN access, admin consoles, a medical imaging viewer, a SaaS scheduling tool that nobody in IT approved, and a local account on a workstation. HR events often reach IT late, or as a resignation email with no effective time, so the clock starts after access should already have ended. The reader should confirm three things: which systems hold ePHI, which of them authenticate through a central identity source, and which do not. Systems outside central identity are where termination fails most often, and they belong in the risk analysis. NIST SP 800-66 Rev. 2 treats establishing termination procedures as a key workforce security activity and terminating access when it is no longer required as a key activity of access control, so an assessor will expect both.

No HIPAA certification exists, so the evidence is the organization's own records. Keep the termination procedure, the access authorization list it draws on, and a dated record for each leaver showing the request time, the time each account was disabled and the person who confirmed it. Sample a set of recent departures and compare HR end dates with account disable times. Document the decision on the addressable status, including any alternative measure such as manual review of unmanaged applications. Ask any implementation partner for a written scope that names the systems in the sample, and remember that the partner prepares this evidence while the organization remains responsible for it.

Which people, accounts and systems does termination cover?

Termination procedures only work if the scope is right from the start. The people, triggers and systems below are the decisions that change how much offboarding work an organization has, and the risk analysis is what tells you which systems hold ePHI.

Workforce members under direct control

The standard reaches workforce members, meaning employees and others whose conduct the organization directly controls, including trainees and volunteers who touch ePHI. Contractors working under the organization's direct control belong in scope too. Build a roster from HR records and from the sponsoring managers of trainees and volunteers, because those people often sit outside the HR system. Ask who owns each population and how their end dates reach IT.

Triggers that start termination

The rule ties termination to three events: employment ends, another arrangement ends, or a workforce clearance determination says access should stop. Each trigger needs a named owner and a time standard. A clearance decision that is not wired to the same workflow as a departure is a common gap. Confirm that a role change, a leave of absence and a contract expiry each have a defined path.

Identity providers and directories

The identity provider or directory is usually the control point that removes access everywhere else. Systems such as FreeIPA, Keycloak, Zitadel or authentik can disable an account once and propagate that change to connected applications. Confirm which applications still hold local accounts that bypass central sign-in, because those accounts will survive a disabled directory entry.

Clinical, email and file systems

EHRs, email, shared file stores and collaboration tools are the systems where ePHI is most often found in practice. Map each one to its account store and note whether access is granted through group membership or per-user rights. Check that removing a user also revokes mailbox delegation, shared drive permissions and API tokens tied to that person.

Admin consoles, backups and remote access

Administrator accounts, hypervisor and cloud consoles, backup software, VPN and remote desktop gateways can reach ePHI without passing through the normal application path. Treat each as in scope and list who holds privileged roles. Backup copies outlive the live system, so confirm who can still restore data after a departure and how that access is removed.

Shared, service and business associate accounts

Shared logins and service accounts are not tied to one person, so a departure does not remove them automatically. Record the owner of each one, rotate credentials that a departing person knew, and review where they are used. Business associate personnel need their own path: confirm in the contract who notifies you when their staff leave, and keep the evidence on your side.

How the termination trigger works in practice

The termination specification is triggered in three ways, and each one has to reach the team that actually changes access. The first is the end of employment or of another arrangement, such as a contractor engagement, a temporary placement or a volunteer role. This event usually starts in HR or in the contracting owner's office, so the termination procedure needs a defined handoff: who notifies the access administrator, how quickly, and through which ticket or workflow. The second trigger is a clearance determination. When the workforce clearance procedure decides that someone's access to ePHI should stop, for example after a failed background check or a change in role that no longer justifies access, the decision has to flow to the same people who remove the access. The third trigger is the one organizations most often miss: a role change that removes ePHI access without any exit. A nurse who moves to billing or an analyst who leaves a project may keep old entitlements for years unless the procedure covers transfers as well as departures.

Because the specification is addressable, the organization first has to decide whether a formal termination procedure is reasonable and appropriate for its environment. The reasoning should be written down, since the decision itself is the evidence an assessor will ask for. If the organization concludes that a documented procedure is not the right route, the rule expects it to document why and to implement an equivalent alternative measure that is reasonable and appropriate. Any alternative must still close the gap between the trigger and the removal of access. Under 45 CFR 164.306(d)(3), the organization has to make this assessment, not defer it to a vendor or an auditor. Before settling on a route, confirm with your own counsel and security official what your HR, contracting and clearance records already produce, because those records determine whether an event-driven process is practical.

In practice, the team should be able to show, for a sample of recent departures and role changes, the date of the trigger event, the date access was removed, and the approval or ticket that connects them. Gaps between those dates, and triggers that never reached the access team, are the findings that matter. Identity platforms can automate the removal step once the trigger is captured. For example, the authentik SCIM provider pushes user deletions to target applications and runs a full sync every hour, so a deactivated account in the identity source can be deprovisioned downstream without manual action. Automation does not settle the addressable decision, though. The organization still has to decide which triggers count, who owns each one, and how the reasoning is recorded. Confirm with your platform team whether each target application supports SCIM deprovisioning or needs a manual or scripted step.

How to implement termination procedures in six steps

This sequence turns the termination requirement into a documented, tested offboarding process that removes ePHI access on time and leaves evidence an assessor can follow from the written procedure to each account.

Inventory every system that holds or reaches ePHI
List each application, database, file share, admin console, backup target and remote access path that stores or reaches ePHI, and record where each one gets its accounts. Note whether accounts come from a central directory, a federated identity provider, or local user tables maintained by hand. The business owner and the security official should both sign off on the list. Done means the auditor can see a system inventory that names every ePHI location and its account source, with no system left unassigned. Systems that appear later, such as a new SaaS tool, must be added to this inventory before go-live.
Define trigger events and step owners
Write down every event that should end access: resignation, termination, end of a contractor or trainee arrangement, transfer out of an ePHI role, and a clearance decision that withdraws access. For each trigger, name the owner who starts the process, the owner who confirms each system is cleared, and the escalation path when the owner is unavailable. HR, IT and the business unit usually share these duties, so the roles need to be explicit. Done means a trigger table exists that maps each event to named roles, and the people on it have acknowledged their part.
Set removal timing in the written procedure
Record the removal timing that applies to each trigger and each system class in the written termination procedure. The rule does not set a timeframe, so the timing comes from your risk analysis and your own policy, and it should be defensible for the most sensitive systems. Ask the security official to confirm that the timing matches what the risk analysis found. Done means the procedure states when access must end for each trigger, and the same document is approved, dated and available to the workforce. Assessors often compare this timing against logged removal dates, so keep the two consistent.
Automate deprovisioning where the system supports it
For systems that accept provisioning through a standard protocol, connect them to the central identity source so that a disabled or removed user is deprovisioned automatically. SCIM is one such protocol. For example, the authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, runs a full sync every hour, and deprovisions users from the target when they lose access. Confirm with each vendor which connectors and events they support, because capabilities differ. Done means a connector configuration export and a test record showing a disabled user lost access in the target system.
Write the manual fallback for systems without automation
For each system that cannot be deprovisioned automatically, write a manual removal procedure with a named checklist: disable the local account, revoke tokens and API keys, remove the user from groups and shared credentials, rotate any shared secrets the person knew, and collect or wipe devices and media. Record who performs each action and where the completion is logged. Done means every manual system has a checklist, a named owner and a completion record template, and the exceptions are listed in the risk analysis so that the residual risk is visible to management.
Run recurring reconciliation against the active roster
On a schedule set in your procedure, compare the accounts in every ePHI system against the current roster from HR and the contractor register. Flag accounts that belong to people who have left, have no owner, or hold more access than their role needs, then remove or justify each one and record the outcome. The first reconciliation report is the key evidence that the procedure works in practice, so keep it with the signed roster and the ticket trail for each removal. Done means a dated report, the exceptions it found, and the closure record for each exception are filed with the procedure.

How an assessor tests termination procedures

This table compares what an assessor does, what they ask you to produce, and where termination procedures most often fail under 164.308(a)(3)(ii)(C). Read each row as a step in one test: the written procedure comes first, then the chain from HR action to account removal, then samples and reconciliations that show the procedure works in practice.

Test area	What the assessor does	Evidence requested	Common findings
Written procedure	Reads the termination procedure and checks it names who starts offboarding, which systems are covered, and who confirms removal	Current termination procedure, version history, and the owner who approved it	Procedure is generic, predates current systems, or omits SaaS apps and shared accounts
HR-to-access chain	Walks through a real exit from the HR notice to the last account disabled, noting each handoff	HR separation notice, ticket or workflow record, and the identity provider change log	Manual handoffs with no owner, so the account stays live after the employee leaves
Leaver sample	Selects recent leavers and traces each one to the disabled directory, application and device accounts	Sample of leaver tickets, deprovisioning timestamps, and confirmation from each system owner	Accounts still active after exit, or removal recorded but not confirmed in the application
Active account reconciliation	Compares the list of active accounts with the current workforce roster and contractor list	Export of active accounts from directory and key applications, plus the roster on the same date	Accounts with no matching person, including contractors whose arrangement ended
Ownership of SaaS and shared apps	Asks who is accountable for removing access in each application outside the central directory	Application inventory with a named owner and documented offboarding step for each	No owner for SaaS apps, so removal depends on someone remembering to act
Clearance denials	Reviews cases where clearance was denied or revoked and checks access was stopped as required	Clearance decision records and matching access removal tickets with dates	Denied or revoked individuals keep access because the clearance outcome never reached the access team
Addressable decision record	Checks whether the entity assessed the specification, and if it chose an alternative, whether the reasoning and the alternative are documented	Risk analysis entry, decision memo, and description of any equivalent measure	No documented reasoning for an addressable decision, or the risk analysis does not mention termination
Timing evidence	Checks that the procedure sets a target for removal and that actual removals are measured against it	Timing metrics or log extracts showing when access ended relative to the exit date	No evidence of timing, so the assessor cannot tell whether removal was prompt

Which evidence shows that termination worked

An assessor will not accept a written termination policy on its own. The artifacts below show that the procedure ran for real people, on real dates, across every system that holds ePHI. Each one should be exported on a schedule and reviewed by a named owner so the file is current when an assessment starts.

Written termination procedure with owners

The procedure states who starts a termination, who disables access in each system, how fast each step must happen, and who signs off. Check that it names roles rather than individuals, lists every system holding ePHI, and covers contractors, trainees and anyone whose arrangement ends, not only employees. Version it and record the approval date, since the procedure is the baseline every other artifact is tested against.

Addressable decision record for manual steps

Where a manual step replaces automated deprovisioning, the entity must document why the automated approach is not reasonable and appropriate and what equivalent measure it uses instead. Keep this record with the risk analysis entry for the affected system. Review it whenever the system changes, because a decision that was sound for a small application may not hold after it starts storing more ePHI.

Leaver tickets traced to disabled accounts

Take a sample of leavers across the review period and trace each ticket to the account disable event in every system where that person held access. Gaps usually appear in the second or third system, such as a legacy clinical application or a shared file store that was never connected to the identity provider. Record the time between the leaving date and each disable event, and investigate any account that remained active.

Identity provider and application deprovisioning logs

Logs from the identity provider and each connected application show when access was removed and by which process. With a SCIM-based connector, confirm that deletions and deactivations propagate to target applications and that the sync runs on a stated schedule. Retain the logs for the period your documentation policy requires, and test that a deprovisioning event can be found quickly by user name and date.

Roster-to-account reconciliation with closed exceptions

Compare the current HR roster or contractor register against active accounts in each system, then list every mismatch as an exception with an owner and a closure date. A recurring export with a named reviewer turns this from a one-time check into a control. Keep the exception log even after closure, because an assessor will look at how quickly exceptions were resolved and whether the same type of gap keeps returning.

Clearance denials linked to access removal

When a workforce clearance decision says access should not be granted or should stop, the denial record should point to the account change that followed. This linkage matters because a clearance decision that never reaches the directory leaves access in place despite the decision. Confirm that each denial ticket references the accounts affected and that the disable event can be matched to it by date and identity.

What meeting termination procedures costs

This table breaks the cost of removing ePHI access at exit into its components, showing who is paid, whether each cost is one-time or recurring, what drives it up, and how to reduce it. Read it to see where spend concentrates before requesting a written scope quote. No fee or duration figures are supplied for this topic, so the amounts depend on your own environment.

Cost component	One-time or recurring, and who is paid	What drives it up	How to reduce it
Identity and deprovisioning tooling or licenses	Recurring for commercial identity platforms; one-time for setup. Paid to the software vendor or, for self-hosted open source, no license fee but hosting and staff time	Number of applications, identity sources and tenants; commercial per-user licensing if chosen	Use a central identity provider with SSO so one disablement covers many applications; open-source options such as Keycloak, Zitadel, authentik or FreeIPA remove license spend, though operating them still costs staff time
Engineering time to build connectors and scripts	One-time build, then recurring maintenance. Paid to internal engineers or an implementation partner under a fixed-scope agreement	Number of target applications without SCIM or federation support; custom APIs; frequency of application upgrades that break connectors	Prefer SCIM 2.0 provisioning and deprovisioning where the application supports it; limit custom scripts to applications that cannot federate
HR and access team time per exit	Recurring, paid through internal payroll. Scales with each departure, transfer and contract end	Turnover rate, number of contractors and temporary workers, and whether HR notifies access teams late or informally	Trigger deprovisioning from the HR system of record; define a single exit checklist with owners and deadlines in the written termination procedure
Evidence upkeep (exports, reconciliations, ticket sampling)	Recurring. Internal staff time, sometimes with reporting tooling	Number of systems holding ePHI, count of local accounts outside central identity, and whether logs are stored in several places	Keep one source of truth for accounts and entitlements; schedule automated access exports and reconcile them against HR leaver lists on a fixed cadence
External review or testing	Recurring or periodic. Paid to an independent assessor or a security testing firm, scoped in writing	Number of in-scope systems, number of exits sampled, and whether the entity needs a formal third-party assessment rather than internal review	Define scope narrowly around systems that hold ePHI; ask whether the proposed review covers account disablement in each system and not only policy existence
Auditor or assessor sampling time	Recurring per assessment cycle. Paid to the independent assessor, which issues the findings	Number of leavers in the sample period, quality of exit tickets, and gaps between HR exit dates and access removal timestamps	Keep timestamped records for each exit and each removal; make sure tickets link the HR event, the disablement action and the reviewer's sign-off
Fewer local accounts and shared credentials	One-time cleanup, then recurring discipline. Internal staff time, sometimes with partner support	Number of standalone application databases, shared administrator accounts and service accounts with no owner	Move local accounts into central directory or federation; assign a named owner to every service and shared account so each has a deprovisioning path

How self-hosted open-source identity tools support termination evidence

Termination procedures are only as good as the identity layer that removes access. The four tools below sit at different points in that layer, from directory and provisioning to single sign-on and brokering. Each one can produce some offboarding evidence, and none of them removes accounts in every application on its own.

authentik SCIM provisioning

The authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, and runs a full sync every hour. When a workforce member loses access to an application, authentik deprovisions that user in the target. Keep the sync logs and the deprovisioning events as dated evidence. Confirm that each target application actually supports SCIM deletes and that a full sync removes accounts the source no longer grants, not only disables them.

FreeIPA central directory

FreeIPA uses 389 Directory Server as a multi-master LDAPv3 directory that stores users, groups, hosts and other network objects. Centralized access control and delegated administration let you show who can change accounts and who approved a removal. Disabling a user in the directory is a single recorded action, but it reaches only systems that authenticate against it. Map which hosts and applications bind to FreeIPA before you rely on it for termination.

Keycloak single sign-on

Keycloak lets users authenticate once rather than in each application, over OpenID Connect, OAuth 2.0 and SAML 2.0, and can broker logins to existing identity providers. Disabling a Keycloak user blocks new sign-ins through Keycloak, which gives you a clear control point and an admin event trail. Single sign-on does not by itself remove accounts in downstream applications, and sessions or tokens already issued may need separate revocation. Confirm each application's local account and token behavior.

Zitadel identity brokering

Zitadel acts as a central identity broker, so users sign in through external providers such as Google, Microsoft Entra ID or Okta over OpenID Connect, SAML 2.0 or LDAP, without each application trusting each provider separately. Removing a user in the upstream provider stops access only if Zitadel no longer accepts that login. Record which upstream provider is the source of truth for each user. Zitadel is licensed under AGPL-3.0-only, which carries network-use obligations for modified versions, so review that license with counsel before modifying it.

Who owns termination: your team, a partner, and the auditor

Your organization owns the termination procedure itself. The Security Rule places the duty on the covered entity or business associate, so no vendor can take it over. Your team decides what counts as the end of a workforce member's employment or other arrangement, which systems are in scope, and how fast access must stop. It also owns the HR trigger that starts offboarding, and it approves any exception, such as a retained account for a contractor on a fixed-term project. Reconciliation stays internal too: someone accountable must compare the identity directory against the list of active people and check that departed users no longer hold ePHI access.

Procedure ownership: Name an accountable owner for the written termination procedure and keep it aligned with the risk analysis.
HR trigger: Define which HR event (resignation, termination, contract end, clearance revocation) starts access removal, and who is notified.
Exception approval: Decide who may approve a delayed or partial removal, and record the reason and expiry date.
Ongoing reconciliation: Schedule periodic comparisons of active accounts against current staff and contractor lists.
Manual systems: Decide which applications cannot be reached by automation and accept or mitigate that risk in writing.

Confirm that your procedure states who approves each exit and where those approvals are stored, because an assessor will ask for them first.

Questions buyers ask about termination procedures

How much effort does HIPAA termination work take, and what drives it?

The effort depends on how many systems hold or can reach ePHI, how many of them still require manual account removal, and how often people leave. A workforce with few systems and a single identity source can close an account in one pass. A workforce with many applications, shared accounts, local logins on workstations and contractor access spread across several tools needs more steps and more checking. Turnover matters because every departure repeats the same chain of actions, so a high-turnover organization carries recurring effort even when each individual removal is simple. Ask any provider to break the work into systems, manual steps and reconciliation checks before agreeing on a figure.

Can we run HIPAA termination procedures without an outside partner?

Yes, provided the organization owns the work. The Security Rule places the obligation on the covered entity or business associate, not on a vendor. You can do it in-house if you keep a current inventory of every system that holds ePHI, a documented offboarding checklist tied to HR events, and a routine reconciliation that compares active accounts against the current workforce list. Many organizations struggle less with the removal itself than with discovering the accounts they forgot existed, such as local administrator accounts, service credentials or old vendor logins. A partner can help build those records, but the reconciliation habit has to remain yours.

How long does a termination procedure project take?

No reliable duration can be given without knowing the scope. The timeline depends on the number of systems in scope, whether identity is already centralized, how many applications need automated deprovisioning, and how much of the offboarding path depends on people completing manual steps. Ask for a scoped plan that lists systems, deliverables, dependencies on system owners and the testing you will see before go-live. Fixed-scope engagements have their scope, deliverables and timelines agreed in writing before work starts, so a written plan is the right document to request rather than a generic estimate.

What does the organization need to provide for termination work?

The work depends on four inputs from your side:

An authoritative HR feed or ticketing event that signals when employment, contract or clearance status ends.
Named system owners who can confirm which applications hold ePHI and approve changes to their access settings.
Administrative access to the identity provider and target systems, so that changes can be tested and then applied.
A named reviewer who signs off on reconciliation results and keeps the evidence.

If any of these is missing, the project usually stalls at the point where an account is found but nobody can confirm whether it should be removed. Agree these roles before scoping begins.

Can a partner make us HIPAA compliant or certify our termination controls?

No. HHS states that no Security Rule standard requires certification and that it does not endorse or recognize private certifications, so there is no HIPAA certificate to obtain. The covered entity or business associate owns its controls and its compliance. A partner can prepare systems, configure deprovisioning, document procedures and gather evidence. Only an independent assessor can test and report on the control, and a third-party assessment does not prevent HHS from later finding a violation. Treat any vendor that promises certification as a warning sign.

What would the 2025 proposed rule change about termination procedures?

HHS proposed a major revision of the Security Rule on January 6, 2025 (90 FR 898), which includes termination and notification procedures within a revised workforce security standard. The proposal is not final. As of October 2026 no final rule has been published, and the latest Unified Agenda lists the rule under Long-Term Actions with final action projected for July 2027. Until a final rule issues, the current addressable specification in 164.308(a)(3)(ii)(C) governs. Plan your procedures so they can be adjusted to new wording, and confirm the status of the rulemaking directly on the Federal Register and reginfo.gov before making contract commitments that depend on it.

How DeployOpen scopes and prepares termination evidence

DeployOpen plans and implements self-hosted open-source identity and access platforms inside your own infrastructure, so that access removal for departing workforce members can be carried out and recorded consistently. We prepare the systems, procedures and evidence; your organization owns the termination policy and the decision to rely on it, and an independent assessor forms any opinion on it.

How we scope

The written scope lists every system holding or reaching ePHI that termination procedures must cover, such as directories, single sign-on and key applications.
We agree which termination triggers apply, including employment end, contract end and clearance determinations, before any configuration begins.
Engagements are fixed-scope, with deliverables and timelines agreed in writing; ongoing support is available as a retainer.

How we build

We configure the identity source so that disabling an account in the authoritative system propagates to connected applications.
Where a target application supports SCIM 2.0 provisioning, we set up automated deprovisioning and confirm it removes users from that application.
We test removal end to end with dated sample leavers and record the results, including any application that still requires manual steps.

How we hand over

We document the offboarding runbook, named owners for each step and the expected timing agreed with your security official.
We deliver exportable logs of account disablement, group removal and session revocation, mapped to each system in scope.
We list residual manual steps, such as hardware return or shared credentials, and the compensating procedure recorded for each one.

How we support

We can run periodic access reviews and sample offboarding tests under a retainer so that evidence stays current after handover.
Upgrades to identity platforms and connected applications are planned and retested so that termination flows keep working.
Ask your assessor which evidence formats they accept before we finalize the export design, since that choice shapes the work.

164.308(a)(3)(ii)(C) Termination procedures