164.308(a)(3) Workforce security: requirements and evidence

What 164.308(a)(3) workforce security requires and why it is hard

The standard requires written policies and procedures so that every workforce member gets the ePHI access their job needs, and so that anyone without that authorization cannot obtain it. Under 45 CFR 164.308(a)(3), that goal is delivered through information access management in 164.308(a)(4), so the workforce standard and the access authorization and modification specifications must be read together. The rule describes the outcome and leaves the method to the entity, guided by its risk analysis. Its three implementation specifications are all addressable: authorization and/or supervision, workforce clearance procedure, and termination procedures. Addressable does not mean optional. For each one, the entity must assess whether it is reasonable and appropriate in its environment. If it is not, the entity must document why and adopt an equivalent alternative measure if one is reasonable and appropriate (45 CFR 164.306(d)). An assessor will look for that reasoning on paper, so a missing rationale is a finding even when the access controls work.

The three specifications map to three moments in a person's relationship with ePHI. Authorization and supervision governs who may work with ePHI or in places where it can be reached, including maintenance staff, trainees and contractors. Clearance decides, before access is granted, how much screening a role justifies, and the risk analysis is the document that sets that depth. Termination removes access when someone leaves, changes arrangement, or is cleared out of a role. Of the three, termination tends to fail in practice, because access granted over years accumulates across role changes, temporary projects and shared accounts, and no single offboarding ticket covers every system. A departed employee's account may remain active in a billing portal or a legacy imaging viewer that was never connected to the directory.

The hard part is therefore not writing the policy but keeping access current across every system that holds or reaches ePHI. Organizations usually need a single source of truth for identities and group membership, automated provisioning and deprovisioning where applications support it, and a periodic review in which a named owner confirms or revokes each grant. Before committing to a design, confirm with your own assessor and privacy counsel which systems are in scope, who approves exceptions, and how the reasoning behind each addressable choice will be recorded. The detailed tooling options for this work are covered on the sibling topics for access management and access reviews.

Which systems, people and vendors fall under workforce security

Workforce security applies wherever ePHI can be reached, not only where it is stored. The scope decisions below set how many accounts, roles and third parties the procedures must cover, and the risk analysis determines how deep each control goes.

Every system that touches ePHI

Scope starts with an inventory of every system that creates, stores, processes or transmits ePHI, including EHRs, billing platforms, file shares, email, backups, reporting databases and endpoints that cache records. Each system needs a named owner and a list of who can reach it. Check for shadow applications and exports to spreadsheets, because access rules that skip these copies leave gaps the rule still covers.

Identity sources and directories

Most workforce access is granted through a directory, an identity provider or a central access management tool, so these sources define the real scope. Identify each source of truth for user accounts and group membership, then record which applications take their users from it. A system that keeps local accounts outside the directory must be added to the inventory separately.

Employees, contractors and trainees

The standard applies to the whole workforce, which the rule defines to include employees, volunteers, trainees and contractors whose work is under the entity's direct control, whether or not they are paid by it. Each category needs its own rule for who authorizes access, how supervision works and how access ends. Trainees and temporary staff are common gaps because their accounts are often created outside normal onboarding.

Maintenance and facilities staff

Cleaning crews, facilities technicians, equipment vendors and on-site repair staff may not use ePHI systems, yet they can see screens, paper or devices in clinical areas. The authorization and supervision specification covers people who work where ePHI can be accessed, so they need escort rules, badge limits and written expectations. Confirm which areas and devices they touch during the risk analysis.

Third parties with administrative access

Vendors that administer servers, EHR instances, remote support tools or cloud tenants hold privileged access even when they are not on the payroll. Their staff must be covered by the same authorization, clearance and termination logic as internal administrators, and the entity should be able to show who at the vendor holds access and when it was removed. Ask each vendor for its own access records and offboarding process.

Vendor staff under business associate terms

Where a vendor is a business associate, the covered entity or upstream business associate must have satisfactory assurances in a written contract or other arrangement under 164.308(b)(1). Those assurances do not replace the entity's own workforce procedures for vendor personnel with access, so the contract should state how vendor staff are cleared, supervised and removed. Confirm that the arrangement names the controls the vendor must apply.

How an assessor tests workforce security

This table sets out how an assessor typically tests the workforce security standard, the evidence requested for each test, and the findings that appear most often. Read each row as a test step, then check the evidence column against what your own records can show on request.

Test area	What the assessor does	Evidence requested	Common finding
Written policy and procedures	Reads the workforce security policy and checks that it covers authorization or supervision, clearance and termination, and links to information access management	Current policy, revision history, approval record and the date of the last review	Policy exists but does not name owners, or no record shows it was reviewed after role or system changes
Authorization and supervision	Selects workforce members who work with ePHI or in areas where it can be reached, such as maintenance staff or trainees, and traces who approved their access	Access request tickets, approval records, role descriptions and supervision assignments	Access granted by a manager by email with no record kept, or no supervision rule for contractors and trainees
Workforce clearance decisions	Samples new hires and role changes and checks whether a clearance decision was made before access was granted and whether the depth of screening matches the risk analysis	Screening records or a documented clearance decision for each sampled person, with the date access was enabled	Clearance decision not documented, or access granted before the decision was recorded
Termination timing	Samples leavers and compares the HR end date with the date each account was disabled in directory and application systems	HR separation records, directory and application deprovisioning logs, and the timing rule in the termination procedure	Accounts disabled days after the employee left, or some application accounts never removed
Directory and application reconciliation	Compares the account lists in the directory and key applications against current HR records and contractor rosters	Exported account lists with dates, the HR roster used for comparison and the reconciliation results	Stale or orphaned accounts, shared accounts with no owner, or accounts that exist in an application but not in the directory
Access reviews	Checks that access rights are reviewed on a schedule, that reviewers decide to keep, change or revoke each item, and that changes are carried out	Review campaign records, reviewer sign-offs, revocation tickets and the schedule set by the organization	Review scheduled but not completed, reviewers approve everything without decision, or revocations not carried out
Link to access management	Tests whether access granted under workforce security matches the access authorization and modification rules in 164.308(a)(4)	Access authorization policy, role-to-permission mapping and a sample of accounts traced back to an approved role	Role assignments accumulate over time with no review, so users hold access beyond their current duties
Risk analysis alignment	Checks whether the depth of clearance and the frequency of reviews reflect the risks recorded in the risk analysis	Risk analysis entries for workforce access, and the controls chosen in response	Risk analysis identifies insider or contractor access but no workforce control is tied to it

How to implement workforce security step by step

This sequence turns the workforce security standard into working procedures, with each step producing a document or record an assessor can check against the risk analysis and the identity system.

Define job roles and access tiers
Start by listing every job function that touches ePHI, including clinicians, billing staff, IT administrators, contractors, trainees and maintenance workers. For each role, record the systems, data sets and actions it needs, then group them into a small set of access tiers. The organization's privacy and security leads own this work, with department managers confirming the job content. The output is a role matrix that maps each role to its tier and the minimum ePHI access it requires, which also gives the access authorization policy in 164.308(a)(4) a concrete starting point.
Set authorization and supervision rules
Write the rules that decide who may grant access to ePHI and who must supervise workforce members who work where ePHI can be seen, such as maintenance staff, trainees and temporary workers. Name the approver for each tier and state when supervision replaces a direct grant. Because the specification is addressable, document why each choice is reasonable and appropriate for your environment, and record any equivalent alternative you adopt. The output is a signed authorization and supervision procedure with an approver for every role tier.
Establish the workforce clearance procedure
Decide what checks must pass before a person receives access in each tier, such as identity verification, reference checks, licensing confirmation or background screening. The risk analysis should set how deep screening goes for each tier, so the depth is justified by the ePHI exposure it controls rather than applied uniformly. Assign an owner, typically HR with the security official, and define who signs off on the clearance decision. The output is a clearance checklist per tier, with a record of who approved each clearance and when.
Build termination procedures with defined triggers
Define the events that end access, including resignation, dismissal, end of a contract, transfer out of a role, and a negative clearance determination. For each trigger, name the person who initiates removal, the systems to be cleared and the evidence to be kept. Cover shared credentials, devices, tokens and physical media that hold or reach ePHI, not only directory accounts. Confirm the timing you commit to with your own policy and risk analysis, since the rule does not set a deadline for this step. The output is an offboarding runbook with a checklist and a closure record for each departure.
Connect provisioning and deprovisioning to the identity system
Make the identity system the source of truth so that access follows the role matrix rather than manual requests. Configure group membership to match the access tiers and use automated provisioning to create, change and remove accounts in the applications that hold ePHI. Open-source options such as authentik's SCIM provider, which pushes user and group changes to target applications and deprovisions users who lose access, and FreeIPA, which centralizes users, groups and delegated administration, can support this design. Test each connected application, then confirm which removals are event-driven and which rely on a scheduled sync. The output is a tested integration map showing every ePHI application and how its accounts are created and removed.
Schedule periodic access reviews
Set a recurring review in which designated reviewers confirm, change or revoke each person's access to ePHI and check that it still matches the role matrix. Access tends to accumulate as people move between roles, so the review should look for access that no longer fits a current role. midPoint's access certification campaigns show one way to run this with named reviewers and a decision deadline. Record every decision and every revocation, and reconcile the results with the termination records. The output is a completed review report per cycle, with reviewer sign-offs and evidence of each revocation.
Document and evidence the procedures
Bring the role matrix, authorization rules, clearance checklists, offboarding runbooks, integration map and review reports into one documented set that the security official maintains. Map each artifact to the specification it satisfies so an assessor can trace the requirement to a record. Confirm retention and update practice against the documentation standard in 164.316, and check whether any proposed rule changes would alter the review cadence before you finalize the review schedule. The output is a workforce security evidence binder that can be produced on request.

How identity automation produces termination and access evidence

Identity automation can produce much of the evidence an assessor will ask for under the termination and access review expectations of 164.308(a)(3), but only if the organization decides the policy first and the tools record what they do. A provisioning connector such as the authentik SCIM provider pushes user and group creations, changes and deletions to target applications over SCIM 2.0, and it deprovisions a user from a target application when that user loses access. The termination evidence is the record of that removal: the source event, the time it ran and the target application that was updated. Before relying on it, confirm in your own environment which events trigger deletion, whether a deactivated account is removed or only disabled in each target, and how the connector behaves when a target is unreachable.

A periodic full sync matters because one-time events miss drift. If a change is made directly in a target application, or a connector call fails silently, the source directory and the target no longer agree. The authentik SCIM provider runs a full sync every hour, which bounds how long that disagreement can last, but the interval should be checked against what your risk analysis says is acceptable for your most sensitive systems. Keep the sync logs with the rest of your information system activity records so you can show when an orphaned account was found and corrected.

Automation does not decide who should keep access. Access certification campaigns in midPoom, as described in the midPoint documentation on access certification, assign named reviewers who must decide within a set timeframe whether to keep, change or revoke each access item, such as a role assignment. Each decision is dated and attributed to a reviewer, which gives you a defensible record that workforce access was reviewed and that people with no current need were removed. Define who the reviewers are, how long they have, and what happens to an item nobody decides, in written policy. The organization owns that policy and every decision made under it; the tools only record them.

Evidence that satisfies workforce security

Workforce security under 164.308(a)(3) is proven by records, not intentions. The six artifacts below connect the written policy to the day-to-day decisions about who gets access, who loses it and who reviewed it. Each one needs an owner, a review date and a version history so it still reflects reality when an assessor asks.

Written workforce security policy and procedures

This is the document that states how access to ePHI is authorized, supervised, cleared and terminated. Assessors check that it names an owner, a version and an approval date, and that it covers all three addressable specifications. Keep a revision log with the reason for each change, such as a new hiring workflow or a new identity platform. Confirm with your counsel whether the 12-month policy review in the January 2025 proposal would apply to you, since the proposal is not final. Until then, set your own review cycle and record each review, even when nothing changes.

Role and job description matrix

This matrix links each job role to the ePHI systems and access levels it needs. It is the baseline that makes later authorization and access reviews meaningful, because a reviewer can compare a grant against the role it was meant to support. Build it with department heads and the security official, then record the date and approver on each row. Update it when roles change, and check that contractors and trainees appear with their own entries rather than being absorbed into staff roles.

Signed authorization and supervision records

These records show who approved a workforce member's access to ePHI or assigned supervision for work near it, such as maintenance staff, trainees or temporary workers. Each record should name the requester, the approver, the systems covered and the effective date. Keep them in a system where they cannot be edited silently after signing. Check that every active account traces back to a record, because an access grant without an authorization record is the gap assessors look for first.

Clearance records

Clearance records document the decision that a workforce member's access is appropriate before it is granted. They may include background screening results, training completion and confirmation of licensure where relevant. The depth of screening should follow the risk analysis, so the record should cite the screening tier applied to that role. Store the record with the least personal data needed to show the decision, and restrict who can open it, since these files often contain sensitive personal information.

Termination tickets with timestamps

A termination ticket proves that access was removed when a person left or when a clearance decision required it. The ticket should record the request time, the time each account was disabled across every system holding ePHI, and the person who confirmed completion. Compare the disable timestamp with the employment end date in HR records, since a gap between them is an exposure. Test the trail by pulling a sample of leavers each quarter and tracing their accounts, rather than waiting for an audit to find the gaps.

Access review reports with reviewer decisions

Access review reports list each user's current access and record whether a designated reviewer kept, changed or revoked it within a set period. They show that access does not quietly accumulate across role changes. Open-source identity governance tools such as midPoint can run these campaigns and keep the reviewer decisions as data. Record who reviewed, when the campaign opened and closed, and what was revoked as a result. Retain the completed reports with the policy version that governed them so the evidence stays tied to its rules.

What meeting workforce security costs in money and effort

This table breaks down the cost components of meeting 164.308(a)(3) across tooling, integration, HR and IT process time, evidence upkeep and external review. Read each row for who is paid, whether the cost is one-time or recurring, and what moves it up or down. No fee figures were published for these items, so use the last column to scope a quote.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Identity and directory licenses	Software vendor under a commercial license, or none if the directory is self-hosted open source	Recurring (per user or per seat under most commercial terms)	Headcount and number of identities, including contractors and service accounts; open-source directories such as FreeIPA can remove this line item, with support costs moving elsewhere
Identity platform setup	Implementation partner or internal platform team	One-time, with later changes	Number of directory sources, existing group structure, and how much role design is done before go-live
Application integration engineering	Internal engineers or an implementation partner connecting each EHR, billing, email or file system to the identity provider	One-time per application, plus rework after upgrades	Number of applications that handle ePHI, whether they support SCIM 2.0 or need custom connectors, and vendor cooperation
Clearance and onboarding process time	HR, the business owner who approves access, and IT who provisions it	Recurring with every hire, role change and contractor start	Workforce churn, number of access tiers, and whether approvals are routed through a workflow instead of email
Termination and offboarding process time	HR, IT and managers who confirm departures and remove access	Recurring with every departure	Turnover rate, number of systems that hold separate local accounts, and whether deprovisioning is automated
Access review and evidence upkeep	Access reviewers, system owners and the security official	Recurring, usually on a set cycle chosen by the organization	Number of applications and roles to review, and whether review campaigns and their records are produced by tooling; open-source governance tools such as midPoint can support this
Vendor and third-party access	Vendor managers, IT and the business owner sponsoring the vendor account	Recurring while the vendor relationship lasts	Number of external parties, whether they use their own identity systems, and how often their access is renewed or ended
External review	Independent assessor or consultant, if the organization chooses one	Periodic, tied to the scope and timing set in the engagement letter	Scope of the review and number of systems sampled. Ask whether the third party tests access controls against 164.308(a)(3) or only prepares documents, because no HIPAA certification exists

Which open-source identity tools support workforce security evidence

The authentik SCIM provider pushes user and group creations, changes and deletions from authentik to target applications over SCIM 2.0. Its main value for workforce security is termination and access modification: when a user loses access to an application in authentik, the provider deprovisions that user in the target application, so removal does not depend on someone remembering each downstream account. The provider also runs a full sync every hour, which gives a recurring check that target applications still match the source. The tool is licensed under the MIT license.

Termination evidence: Sync and deprovisioning logs can show that a departing user's access to connected applications was removed, and when.
Modification evidence: Group changes that propagate to target applications support the access establishment and modification specification.
Hourly full sync: The recurring full sync can show that drift between the source and targets is corrected on a schedule.
Coverage limits: Only applications connected through a SCIM provider are covered. Local accounts and applications without SCIM need separate removal steps.
License: Confirm the MIT license terms and any dependencies with your counsel before adopting the tool in a regulated environment.

Before relying on this tool, check which target applications hold ePHI, confirm deprovisioning works for each one, and keep a documented list of applications that sit outside the sync.

Where workforce security programs usually fall short

Most workforce security failures under 164.308(a)(3) are not missing policies. They are gaps between the policy and the daily work of hiring, moving, offboarding and reviewing people. The cards below describe the gaps assessors most often find and the closing step for each.

Terminations handled by email

When a manager emails IT that someone has left, access often stays open for days because the request sits in an inbox and nobody owns the deadline. The termination procedure in 164.308(a)(3)(ii)(C) should name who starts offboarding, which systems must be disabled, and how fast. Close it by routing every leaver through one ticketed workflow tied to HR status changes, and keep the timestamped ticket as evidence.

Contractors missing from offboarding

Contractors, consultants, temps and vendor staff often hold accounts that sit outside the HR system, so they never appear on a leaver list. They still reach ePHI through VPNs, shared applications and service desks. Close it by giving every non-employee identity an end date and a named internal sponsor, so access expires automatically unless the sponsor renews it.

Access accumulating after transfers

When someone changes role, new access is added but old access is rarely removed. Over time a clinician or billing employee holds permissions far beyond the job, which undercuts the minimum necessary approach that the authorization specifications in 164.308(a)(4) expect. Close it by defining role-based access so a transfer replaces permissions rather than stacking them, and by recording the approver for each change.

No documented clearance criteria

Many organizations screen some roles and not others, with no written rule for which roles get which checks. An assessor asking how the workforce clearance procedure decides access will get an answer that depends on who is asked. The risk analysis should set how deep screening goes by role and data sensitivity. Close it by writing a short matrix of roles, required checks and the approver who signs off before access is granted.

Access reviews that never happen

Periodic access reviews are common in policy and rare in practice. Without a review, orphaned accounts and excess rights persist unnoticed, and the team cannot show that the authorization policy is applied. An access certification campaign, where a named reviewer keeps, changes or revokes each access item within a set period, creates the record an assessor will ask for. Close it by scheduling a campaign, assigning reviewers by system owner, and filing the revocations as evidence.

Shared accounts with no owner

Shared logins for clinic workstations, reporting tools or service mailboxes make it impossible to tie an action to a person. When one employee leaves, the password is never changed because no one knows who else has it. Close it by assigning every shared account a named owner, recording who holds access, and replacing shared logins with individual accounts or a managed credential vault where the application allows it.

Workforce security questions buyers ask before hiring help

How much effort does it take to put workforce security controls in place?

Effort depends on how many systems hold ePHI, how many people hold access, and whether access is managed centrally or application by application. Most of the work falls into three groups: writing the authorization, clearance and termination procedures, mapping who currently has access to what, and then wiring the joinerand-leaver steps into the systems that grant access. Organizations with one directory and a few applications need far less effort than those with dozens of standalone logins. Ask any provider to break its estimate into these three groups so you can see where the hours go and which parts your own staff must supply.

How long does workforce security implementation usually take?

It depends on scope. The number of systems in scope, the state of existing access records, the number of approvals your process requires, and how quickly your HR and IT teams can supply information are the main drivers. A scope limited to one directory and two clinical applications moves faster than an enterprise rollout across several business units. Because the Security Rule expects procedures to match your actual workforce, plan for a discovery phase before any technical change. Ask for a timeline tied to the written scope, with the dependencies on your side listed as separate milestones.

Can a small practice handle workforce security without outside help?

Yes, a small practice can write and follow its own procedures, but the work still has to be done and documented. The security official, often the practice owner or office manager, can draft authorization, clearance and termination steps, keep a current list of who can reach ePHI, and record each offboarding. Outside help is most useful for the technical part: setting up a central identity source, removing shared logins, and producing access reports that show the procedures working. Confirm whether your practice management and EHR vendors support the account changes you need, because those settings often decide how hard the work is.

What does workforce security require from HR and IT?

HR owns the events that start access changes: hiring, role changes, leave, contractor end dates and resignations. IT owns the accounts, groups and application permissions that carry out those changes. The two teams need a shared written trigger for each event, a named owner for each step, and a deadline for removing access after a departure. Contractors, trainees and maintenance staff need the same path even though they do not appear in payroll. Without this handoff, accounts remain active after people leave, which is the gap an assessor is most likely to test.

Does automation remove the need for a written workforce security policy?

No. Automation enforces decisions, but the Security Rule still requires written policies and procedures, and someone must decide who approves access, how screening depth is set, and when access stops. An identity platform can push account creations and removals to connected applications and run access reviews, yet it cannot decide that a contractor should be cleared for a particular system. Write the policy first, then configure the tools to match it. Keep the policy, the configuration and the review records together so an assessor can trace each decision.

Will the auditor design our workforce security controls?

No. An independent auditor or assessor tests the controls you own and reports what it finds. It does not design them. DeployOpen prepares systems, configurations and evidence to support that testing, but the organization remains responsible for its policies, its risk decisions and its workforce. HHS also states that no Security Rule standard requires certification, so any third-party assessment is a review of your controls rather than an official HIPAA stamp. Ask any assessor to state in writing what it will test and what it will not.

What should a quote for workforce security work include?

A quote should follow from a written scope and list each deliverable separately. Ask for the systems in scope, the procedures to be written or reviewed, the integrations to be built, the evidence to be produced, and the testing to be performed. Each item should show who does the work, what the organization must supply, and what is one-time versus recurring, such as access reviews or support retainers. Ask how changes to scope are priced and how long the agreed scope remains valid. DeployOpen does not publish a price list, and a quote follows from the written scope.

What the proposed rule would add to workforce security

The January 2025 proposed rule would add a recurring review obligation to the workforce security standard. As proposed, covered entities and business associates would have to review and test their written workforce security policies and procedures at least once every 12 months. This would sit alongside the existing rule, which requires policies and procedures for authorization and supervision, workforce clearance and termination but does not set a review cycle for them. The proposal is published at 90 FR 898 under RIN 0945-AA22, with comments that closed March 7, 2025. As of October 2026, no final rule has been published, and the latest Unified Agenda lists the rulemaking under Long-Term Actions with final action projected for July 2027. Until a final rule issues, the annual review is not a legal requirement, and the current text should remain the governing standard for your program.

The practical question is which workforce security artifacts the review would cover. Expect the review to touch the written rules for authorizing and supervising staff who can reach ePHI, the criteria used for workforce clearance, and the steps that remove access at termination. A reviewer would also want to see evidence that the policies were tested, not only signed. Confirm the exact scope of the testing requirement against the proposed text before you design your evidence, since the Federal Register document is the authoritative source for what was proposed.

Building the annual review now is sound practice, regardless of when or whether the rule is finalized. Assign an owner, set a fixed review date, and record what changed, who approved it and which access reviews or offboarding tests supported the conclusion. Identity lifecycle tooling can supply much of that evidence. For example, a deprovisioning test in a self-hosted identity platform can show whether a removed account lost access to connected applications within the expected window. Document the results in the same cycle, so the annual record is ready if OCR asks for it under its existing authority.

164.308(a)(3) Workforce security