164.308(a)(3)(ii)(A) Authorization and/or supervision: evidence

What 164.308(a)(3)(ii)(A) authorization and supervision requires

A compliance lead is usually asked two questions here: who is allowed to touch electronic protected health information, and who watches the people who cannot be given routine access to it. 45 CFR 164.308(a)(3)(ii)(A) asks the organization to have procedures for authorizing and/or supervising workforce members who work with ePHI or in locations where it might be accessed. The workforce is broad. It includes employees, but it also covers maintenance and facilities staff who enter server rooms, trainees who shadow clinicians at workstations, and contractors who troubleshoot a system that holds patient records. Each of these people can see ePHI without ever being given a clinical role, so the rule expects a deliberate answer for each group.

The specification is addressable, which is often misread as optional. Under 45 CFR 164.306(d)(3), the organization must first assess whether the procedure is reasonable and appropriate for its environment. If it is, the organization implements it. If it is not, the organization must document why and put in place an equivalent alternative measure, if that is reasonable and appropriate. Either way, the outcome has to be written down. For a hospital with a large contractor population, the decision might be escorted access for every vendor, with a named staff member logging entry. For a small practice that uses no outside technicians, the decision might be documented as not reasonable, paired with a rule that outside personnel never work unattended on systems that hold ePHI. Both choices can satisfy the standard if the reasoning is recorded.

Informal supervision is what makes this hard. Staff often assume a manager is nearby or that a technician will be watched, but nothing is written down, so the assessor finds no procedure, no assignment and no record of who approved access. NIST SP 800-66 Rev. 2 pairs this specification with establishing clear job descriptions and responsibilities, which gives the reader a practical starting point: tie each role that touches ePHI to a stated purpose and a named supervisor. Confirm with your own risk analysis which locations and roles are in scope, then keep the authorization and supervision records with the rest of your workforce security documentation so they can be produced on request.

Which workers, locations and vendors fall under authorization and supervision

The addressable specification in 164.308(a)(3)(ii)(A) reaches further than employees with a login. Each group below touches ePHI directly or can reach the places where it sits, so the covered entity or business associate must decide how each one is authorized or supervised and record that decision in its risk analysis.

Employees with ePHI access

Clinical, billing, scheduling and administrative staff who open, create or transmit ePHI are the core of this specification. Authorization should name the systems, roles and approval path for each job, so access follows the job description rather than individual requests. Check that the approver is documented and that managers review access when duties change.

Facilities and IT maintenance staff

Electricians, HVAC technicians, network cabling crews and hardware repair technicians often have no reason to view ePHI but may stand near screens, printers or servers that hold it. Supervision is the usual control: escort them, log their visits and confirm that the work order names the areas they may enter. Ask whether the organization's own staff or a contractor performs the escort.

Trainees and students

Residents, nursing students, interns and volunteers may treat patients and record ePHI while they are not yet workforce members in the usual sense. Define which tasks they may perform, who supervises each task and how their accounts are provisioned and removed. Shadowing without system access still needs a documented supervision rule.

Cleaning and building contractors

Night cleaners and building staff generally need physical access to offices and records rooms rather than system access. The control question is whether they can reach unattended screens, paper charts or media containers. Document the access they hold, the areas they are kept out of and who checks that rule, and cover these arrangements in the contracts with their employers.

Vendors working on site

On-site vendors such as medical device technicians, equipment installers and auditors need supervision that matches their access. Ask each vendor for its own workforce list and confirm which individuals hold badges or credentials. Vendor staff who have system access are also covered by business associate terms where they handle ePHI.

Workstations, servers and remote sessions

A scoping decision changes the work. A workstation in a clinic is an ePHI location if ePHI is displayed or stored there, and a server room is one if ePHI is stored there or reachable through its network. Remote support sessions are also in scope: record who connects, which account they use, what they can view and who approves the session. Confirm these choices against the organization's own risk analysis.

How the addressable decision works under 164.306(d)

For 164.308(a)(3)(ii)(A), the entity has to make a decision it can later defend: is authorization and/or supervision of workforce members who touch ePHI, or who work where ePHI can be reached, reasonable and appropriate for this organization? If the answer is yes, the entity implements it. If the answer is no, the entity must write down why, and then put in place an equivalent alternative measure if one is reasonable and appropriate. Silence is not an option. An assessor will look for the decision itself, not just the outcome, so the file needs to show that the question was asked and answered for this specification.

The risk analysis is the input that makes the decision defensible. Start with the workforce roles that can reach ePHI: clinical staff, billing, help desk, building maintenance, cleaning contractors, interns and trainees. For each role, record where ePHI is stored or displayed, what the person can do with it, and whether anyone reviews that access. A role with broad system rights and no supervision points to implementation. A role that is physically present in a clinic area but never touches a system, such as a visiting electrician escorted by staff, may support a documented alternative, such as escort rules and screen lock requirements. Where the risk analysis is thin, the rationale will be thin too, so update the decision whenever roles, systems or locations change.

A sound written rationale names the specification, the roles it covers, the risk finding it relates to, and the reasoning for the choice made. If the entity declines full authorization or supervision, the rationale should state the specific limitation, the alternative measure, who approves it, how the alternative is checked, and when the decision is reviewed. Ask your security official to confirm that the alternative addresses the same risk, not just a different one. Confirm that the record is retained and reviewed with the rest of your Security Rule documentation, since OCR will judge the decision against what the entity actually does day to day.

How an assessor tests authorization and supervision

This table sets out how an assessor typically tests 164.308(a)(3)(ii)(A), what evidence they request for each step, and the findings that appear most often. Read it as a checklist for your own pre-assessment review, since the assessor's depth will depend on your risk analysis and the size of your workforce.

Test area	What the assessor does	Evidence requested	Common finding
Written authorization procedures	Reads the policy and procedure for granting, approving and recording access to ePHI and to locations where it can be reached	Current signed policy, version history, and the owner who approved it	Procedure exists but does not name who authorizes access for maintenance staff, trainees or contractors
Supervision rules for non-employees	Checks how maintenance crews, cleaning staff, trainees and vendors are escorted or supervised in areas with ePHI	Visitor and escort logs, facility access rules, supervision assignments for a sample of visits	Supervision is assumed rather than documented, so no one can show who was responsible on a given day
Sampling access grants	Selects a sample of workforce members and traces each grant back to an approval	Access request tickets, approver sign-off, role or group membership, date of grant	Access granted by a manager with no record of approval or the business need
Sampling maintenance and on-site visits	Selects recorded visits to systems or rooms and asks who authorized each one and who watched the work	Work orders, sign-in sheets, camera or badge records where used, vendor authorization letters	Visit occurred but no authorization or supervising person is recorded
Interviews with staff and supervisors	Asks staff how they request access and supervisors how they supervise people without standing access	Consistent answers that match the written procedure and the records sampled	Supervisors describe an informal practice that differs from the written procedure
Role and responsibility alignment	Compares job descriptions and responsibilities with the access actually held	Job descriptions, role matrix, access reviews showing alignment	Access exceeds what the job description supports and no one has reviewed the gap
Addressable decision record	Checks whether the entity assessed the specification as reasonable and appropriate and documented the outcome	Documented decision with reasoning, risk analysis reference, and the date it was made	No record that the addressable decision was made at all
Alternative measure for skipped specifications	Where the entity chose not to implement a supervision or authorization step, checks for a documented equivalent measure	Written rationale and description of the compensating control, with evidence it operates	Specification skipped with no reason recorded and no alternative measure in place

How to implement authorization and supervision step by step

This sequence turns the addressable authorization and supervision procedure into a documented, testable process that links who may touch ePHI to the access actually granted in your systems.

Define who must be authorized
Start by listing every role that works with ePHI or in places where it can be accessed, including clinical staff, billing, IT administrators, maintenance and facilities contractors, trainees and temporary workers. Use your risk analysis and data inventory to mark which roles touch ePHI directly and which only sit near it. The owner is usually the security official with HR and department managers. The output is a role list that names each role, the systems or locations it covers, and whether it needs supervision. Confirm the list against your current systems, because roles missed here will not be governed later.
Write the authorization and supervision procedure
Draft a written procedure that states who may grant authorization, what criteria apply, how supervision is arranged for workforce members who are not authorized for independent access, and how exceptions are handled. NIST SP 800-66 Rev. 2 pairs this specification with clear job descriptions and responsibilities, so tie each role in the list to the duties and access it permits. Managers and the security official review the draft, and leadership approves it. The output is a signed policy and procedure document with an owner and a revision date.
Document the addressable decision
Because this specification is addressable, record whether implementing it as written is reasonable and appropriate for your organization. If it is, document how it will be implemented. If it is not, record the reason and the equivalent alternative measure you chose, and confirm that the alternative is reasonable and appropriate. The output is a dated decision record in your Security Rule documentation, linked to the risk analysis entry that supports it. Ask your assessor or counsel to confirm the reasoning if the decision is contested.
Assign supervisors and their responsibilities
For each supervised role, name a supervisor who is accountable for observing the work, approving exceptions and confirming that the workforce member has completed required training before handling ePHI. Record the supervisor's duties in the job description so the responsibility is enforceable. The output is a supervisor assignment register that maps each supervised workforce member to a named supervisor and a backup. Keep the register current when reporting lines change.
Tie approvals to access provisioning
Connect the authorization decision to the system that grants access. Approval should be a recorded event that triggers account creation, group membership or role assignment, not a verbal instruction to an administrator. Directory and identity tools can enforce this: for example, authentik's SCIM provider pushes user and group changes to target applications and deprovisions users when they lose access, and FreeIPA centralizes users and groups with delegated administration. Confirm each tool's behavior in your own environment before relying on it. The output is a provisioning workflow where every grant of ePHI access traces back to an approval record.
Log approvals and supervision activity
Capture the approval record for each authorization, including who approved it, the role, the systems covered and the date, and keep supervision notes or logs for supervised workforce members. Store these records where the security official and auditors can retrieve them. Your information system activity review and audit logs can show whether access matched an approval. The output is a retrievable approval record set and a supervision log that a reviewer can sample against the role list.
Schedule periodic review and reconciliation
Set a recurring review in which the security official or managers compare the role list, approval records and live access rights, then correct mismatches. Review again after reorganizations, new systems, new vendors or new maintenance contracts. The access establishment and modification specification supports this reconciliation. Confirm the review interval with your risk analysis, since the rule does not set one for this specification. The output is a signed review record listing findings, corrections and the date of the next review.

Evidence that proves authorization and supervision works

Authorization and supervision is only as credible as the records behind it. The artifacts below show who was allowed to touch ePHI, who approved it, and who watched people who lacked standing access, and each one needs a refresh rhythm so it still matches reality when an assessor asks.

Written authorization and supervision procedure

This is the policy that defines who may approve access, how supervision of maintenance staff, visitors and trainees works, and what counts as sufficient oversight. Under 45 CFR 164.316, it must be written, kept current and retained. Check that it names roles rather than individuals, that it matches what staff actually do, and that its revision history shows a review after each material change to systems or staffing. Confirm the retention period with your counsel.

Job descriptions tied to access levels

NIST SP 800-66 Rev. 2 pairs this specification with clear job descriptions and responsibilities. For each role, record which ePHI systems and data classes it may reach and the approval level required. A useful check is whether a sample of current accounts traces back to a role description, and whether role changes trigger a documented access review. Refresh these when org charts or system inventories change.

Access approval tickets

Each grant or change of ePHI access should leave a ticket showing the requester, the approver, the justification, the system and the approved scope. Assessors often sample these and compare them against live accounts in the directory. Check that approvals come from someone authorized under the procedure, not the requester, and that tickets close only after the access change is verified in the system.

Visitor and maintenance escort logs

Where maintenance staff, vendors or visitors can reach places where ePHI might be accessed, logs should show arrival, the named escort, the areas visited and departure. These records show supervision in practice. Reconcile logs against facility access records and vendor work orders, and confirm escorts were themselves authorized for the areas they accompanied.

Trainee supervision assignments

For students, residents or other trainees, record the supervising workforce member, the systems and data the trainee may use, and the period covered. Assignments should be dated and signed off by the supervisor. Check whether any trainee account exists without a matching assignment, and whether supervision ends when the training period does.

Addressable decision memo

Because this specification is addressable, the file must show whether supervision and authorization procedures are reasonable and appropriate. Where they are not, 45 CFR 164.306(d)(3) requires documentation of why and an equivalent alternative measure. Keep the memo dated, signed by the security official, and linked to the risk analysis. Review it whenever the risk analysis is updated.

How identity tooling makes authorization evidence repeatable

Authorization evidence is only as strong as the record behind it. For 164.308(a)(3)(ii)(A), the record should show who approved a workforce member's access to ePHI or to a location where it can be reached, and that group membership in the systems matches that approval. A central directory makes this traceable. In FreeIPA, which uses 389 Directory Server as a multi-master LDAPv3 directory, users, groups and hosts sit in one place, and access control and delegated administration are managed through its web UI and command line tools. Delegation lets a named role, such as a clinical application owner, maintain its own group without holding broad administrative rights. The approval decision itself stays with the organization: the security official, data owner or manager who signs off on the role. The directory only records and enforces that decision.

Provisioning closes the gap between an approved role and the applications that hold ePHI. 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. Read the record this produces as evidence: an approved group change should appear in the source directory, then in the target application within the sync window, and a removal should follow the same path. Confirm in your own environment which applications are connected, whether each one supports SCIM deprovisioning, and how the hourly sync behaves when a target is unavailable. Test with a sample account, keep the sync and audit logs, and compare them against your approval tickets, since an assessor will ask for the trail, not the tool.

Before relying on this in an assessment, decide which applications are in scope, who can change group membership, and how exceptions such as trainees, maintenance staff or temporary contractors are approved and time-limited. Tooling cannot tell whether a supervisor's approval was appropriate, so document the supervision rules separately and check that the identity records reflect them. The NIST SP 800-66 Rev. 2 guidance pairs this specification with clear job descriptions and responsibilities, which give the approval decisions a basis. Ask any implementation partner to show the approval-to-access trail for a sample of workforce members, and confirm with your auditor what format of evidence they will accept.

What authorization and supervision costs to meet

This table breaks down the cost components of meeting 164.308(a)(3)(ii)(A) and shows who is paid for each, whether the cost is one-time or recurring, and what pushes it up or down. No prices are published here, so use the drivers column to shape the questions you put to any quote. The main takeaway is that most of the recurring cost comes from people and evidence upkeep, not from software licenses.

Cost component	Who is paid	One-time or recurring	What drives it
Policy writing and legal review	Internal security or HR staff, outside counsel or consultant	One-time to draft, recurring to review	Number of workforce roles, state or sector rules, and how often policy changes
Engineering time to link approvals to provisioning	Internal identity or platform engineers, or an implementation partner	One-time build, recurring maintenance	Number of systems that need access, whether an identity provider already exists, and integration complexity
Supervision staffing time	Internal managers and supervisors who approve or oversee maintenance staff, contractors and trainees	Recurring	Volume of visitors, contractors and trainees, and how many sites or systems they touch
Evidence upkeep	Internal compliance or security staff, sometimes an implementation partner	Recurring	Frequency of access reviews, number of approval records retained, and how easily records can be exported
Vendor and workforce churn	Internal HR and IT, plus any vendor that manages accounts	Recurring	Staff turnover, contractor rotation and the number of third-party tools that hold accounts
Assessor sampling	Independent auditor or assessor, paid by the organization	Recurring at each assessment	Sample size the assessor chooses and how quickly your records can be produced
Open-source identity and directory tooling	No license fee for the software itself. Hosting, staff and support still apply	One-time setup, recurring operation	Infrastructure choice, in-house skills and whether support is bought separately

Who owns authorization and supervision, and what a partner can prepare

Your organization owns the authorization decisions. Someone with the authority to grant or deny access to ePHI must decide who may work with it, who may supervise maintenance staff or trainees in areas where ePHI can be seen, and what conditions apply. The Security Rule makes this a covered entity or business associate obligation, so no vendor can take it over. Ownership sits with named roles, usually the security official working with department heads and HR.

Approval authority: Name the roles that approve access to ePHI systems and physical areas, and record the basis for each approval.
Supervision assignments: Decide who supervises contractors, visitors, maintenance staff and trainees, and how far that supervision extends.
Job descriptions: Tie each role to the ePHI it needs, the way NIST SP 800-66 Rev. 2 pairs authorization with clear job descriptions and responsibilities.
Exception handling: Define who can approve temporary or emergency access and how it expires.
Documentation: Keep the written procedure and the approvals that show it was followed.

Before any partner starts, confirm internally who holds each approval role and where those decisions are currently recorded.

Common gaps in workforce authorization and how to close them

Most authorization failures are not missing policies. They are informal grants, unrecorded people and undocumented decisions that leave no trail an assessor can follow. Each card below names one gap, what it looks like in practice and the step that closes it under 164.308(a)(3)(ii)(A).

Access granted by verbal request

When a manager asks the IT desk by phone or chat to open a shared folder or EHR role, the grant has no approver, no defined scope and no record. The addressable specification expects authorization and/or supervision procedures that a reviewer can follow from request to grant. Close it by routing every ePHI access request through a ticket that names the requester, the approver, the system and the role, and by checking a sample of tickets against live accounts each quarter.

Contractors and trainees missing from records

Temporary staff, students, contractors and vendor technicians often receive logins from a shared account or a sponsor's personal request, so they never appear in the workforce roster. The rule covers workforce members in locations where ePHI might be accessed, so these people are in scope. Close it by defining workforce membership in policy, requiring a sponsor for each non-employee, and reconciling directory accounts against the roster and sponsor list on a set schedule.

No supervision rule for maintenance staff

Facilities crews, biomedical technicians and outside maintenance vendors often enter server rooms, imaging suites or clinical areas where screens and paper records are visible, with no escort or log. The specification explicitly reaches people working in places where ePHI can be accessed, not only people with system accounts. Close it by writing a supervision rule that sets when an escort is required, who provides it, and how the visit is logged, then tying that rule to the facility access controls.

Addressable decision never documented

Organizations often adopt a supervision or authorization practice without recording why it is reasonable, or they decide it is not reasonable and never write down the alternative. Under 164.306(d), an addressable specification requires either implementation or a documented reason plus an equivalent measure. Close it by recording each decision in the risk analysis file with the assessed reasoning, the chosen measure, the owner and the review date.

Role definitions that drift from job duties

Access rights stay attached to job titles that no longer describe the work, so staff keep access they no longer need. NIST SP 800-66 Rev. 2 pairs authorization with clear job descriptions and responsibilities, so the two must match. Close it by writing each role's ePHI access against a job description, approving changes through the same authorization path, and recertifying roles when duties change.

Directory groups with no delegated owner

Central identity groups are often granted broadly and managed by a single administrator, which makes it unclear who may approve membership in a group that unlocks ePHI. Delegated administration in a directory lets you assign approval rights per group, but only if someone configures it. Close it by naming an owner for each ePHI-bearing group, limiting who can add members, and logging membership changes for review.

Questions buyers ask about authorization and supervision

How much effort does authorization and supervision take to put in place?

The effort depends mostly on how many workforce roles touch ePHI and how many systems those roles reach. A small practice with a handful of staff and one electronic health record may need a short written procedure, a list of who may approve access, and a simple record of supervision for maintenance staff and trainees. A health system with contractors, rotating residents and many clinical applications needs a broader procedure, role definitions tied to job functions, and recurring checks. The risk analysis is the input that sets how much detail is proportionate, so the effort scales with the findings rather than with a fixed template.

Can our team handle this specification without outside help?

Many organizations write the procedure in-house, since the specification asks for procedures the entity can define itself. The work that is harder to do alone is aligning the procedure with real system roles, configuring identity tools so approvals and removals are enforced rather than only documented, and producing clean evidence. Staff who own HR, IT and clinical operations need to agree on who authorizes what. An implementation partner can prepare systems and evidence, such as role mappings and access records, but the covered entity or business associate owns the decision and the policy. Only an independent assessor can give an opinion on whether the safeguard is adequate.

How long does this work usually take?

No duration for this specification is set in the researched sources, so no reliable timeline can be given here. The schedule depends on the size of the workforce, how many systems hold or can reach ePHI, whether roles are already defined, and whether identity systems need to be deployed or extended. Ask any provider to break the timeline into discovery, role definition, procedure writing, system configuration and evidence collection, and to tie each phase to a written, fixed scope before work starts.

What does this work need from our internal staff?

The work needs named owners from several functions. Compliance or the security official typically defines the policy and approval rules. HR confirms job descriptions and changes in role. Department managers confirm which functions their staff need and who supervises maintenance workers, contractors and trainees. IT administers the accounts and records. Each owner should expect to review proposed roles, sign off on the procedure and answer questions during configuration. Without these inputs, the procedure tends to describe roles that do not match how work is actually done.

Will an auditor test this specification separately?

Assessors and OCR investigators usually examine workforce security together with the rest of the Security Rule, because authorization, clearance and termination depend on each other. An auditor may ask for the written procedure, evidence that it was followed for specific people, and records showing supervision of non-workforce individuals such as maintenance staff or trainees. Because the specification is addressable, the auditor will also look for the documented assessment of whether it is reasonable and appropriate, and for any equivalent measure adopted in its place. Confirm with your assessor which samples they will request.

Does a HIPAA certification exist that would prove we meet this requirement?

No. HHS states that no Security Rule standard requires an entity to certify compliance, and that it does not endorse or recognize private organizations' certifications. HHS has also said such certifications would not prevent it from later finding a violation. Any vendor offering a HIPAA certificate should be asked what independent assessment sits behind it and what the document actually covers. Evidence that the authorization and supervision procedure works is what matters to OCR, whatever a third party may call its report.

How does a self-hosted open-source identity platform help with this specification?

Identity tools can enforce the authorization decisions the procedure describes. For example, authentik's 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 to the application. FreeIPA, licensed under GPL-3.0-or-later, stores users and groups in a multi-master LDAPv3 directory with centralized access control and delegated administration through its web UI and command line tools. Confirm that a chosen platform supports the specific applications, approval workflow and audit records you need, because this specification is a policy requirement and no tool satisfies it alone.

How DeployOpen prepares authorization and supervision evidence

DeployOpen's part in this specification is to prepare the systems and records that show who may approve access to ePHI and how supervision of maintenance staff, trainees and other non-employees works in practice. The scope is agreed in writing before work starts, and it names the workforce roles, systems and approval paths in play. The organization keeps ownership of its authorization policy and of every approval decision. DeployOpen does not issue audit reports or certifications. Independent assessors do that work, and HHS does not recognize any private HIPAA certification.

In a typical engagement, DeployOpen integrates self-hosted identity tooling inside the client's own infrastructure. For example, the authentik SCIM provider can push user and group creations, changes and deletions to target applications over SCIM 2.0, and it can deprovision users when they lose access. FreeIPA, which uses 389 Directory Server, can hold users, groups and hosts in one directory with delegated administration, so the people who approve access are not the same people who grant it. Those configurations are the raw material for the authorization record. The client should confirm each feature against the versions it deploys, because capabilities differ between releases.

The evidence a reviewer expects is a written authorization procedure, group and role definitions that match the job descriptions, an approval record for each grant, and proof that supervised workers such as contractors or trainees were limited to the systems their supervisor approved. DeployOpen can help draft these procedures and set up the logs that capture approvals and changes, but the client must decide who supervises whom and must sign off on the policy. Before the engagement starts, ask the partner which records the chosen tools write, where they are retained, and how a reviewer would pull them.

164.308(a)(3)(ii)(A) Authorization and/or supervision