What 164.308(a)(4) information access management requires
The standard requires written policies and procedures for authorizing access to electronic protected health information, and those policies must be consistent with the Privacy Rule in Subpart E of Part 164. If an audit, a new platform rollout or a customer questionnaire asks how you control who can reach ePHI, this standard is the first place an assessor looks for the decision record. It has three implementation specifications: one required and two addressable. The required one, isolating health care clearinghouse functions, applies only if a clearinghouse sits inside a larger organization, and then the clearinghouse's ePHI must be shielded from the rest of that organization. Confirm early whether this applies to you, because many organizations that run billing or claims processing for others do not realize it counts. The two addressable specifications carry most of the work. Access authorization asks you to define who approves access to a workstation, transaction, program or process and on what basis. Access establishment and modification asks you to set up, document, review and change each user's rights against that authorization policy. Addressable does not mean optional: you must assess whether each specification is reasonable and appropriate for your environment, and if you decline one, document why and adopt an equivalent measure. Ask yourself who can approve a grant, what evidence proves the approval happened, and how a change in job role triggers a change in access. This standard is hard in practice for three recurring reasons. Access accumulates as people move between teams and nobody removes the old grants. Approvers are unclear, so requests are granted by whoever answers first. Stale grants survive offboarding and role changes because no one reviews them on a schedule. The standard is the policy layer. The technical access control standard in 164.312(a)(1) is what enforces these rights inside systems, so an assessor will expect the written policy and the system configuration to match. Identity tools such as authentik or FreeIPA can enforce grants, and access certification campaigns in midPoint can produce the periodic review evidence, but you must confirm each capability against your own environment before relying on it.
Which systems, teams and vendors fall under access authorization
Access authorization under 164.308(a)(4) reaches further than the EHR. Before writing policy, map every place ePHI is stored, processed or reachable, every person and vendor who needs a path to it, and every identity service that grants that path. The cards below mark the decisions that most change the size of the work.
Applications and databases holding ePHI
Start with the systems that store or process ePHI: the EHR or practice management system, billing platforms, reporting databases, file shares, and backups. Record which application roles can read, change or export records, and which database accounts sit behind those applications. Service accounts and batch jobs count too, because they hold access that no person reviews unless someone lists them. Confirm each one against the risk analysis inventory so no system with ePHI is left out.
Workstations and admin consoles
Workstations that open ePHI, shared clinical terminals, and the administrative consoles that control servers, hypervisors and cloud accounts all reach ePHI, even when the consoles do not display it. Administrators can usually read the data they manage, so privileged access belongs in scope from the start. Ask which consoles can export, restore or snapshot systems holding ePHI, since those paths can bypass application-level controls.
Workforce roles and contractors
Access authorization should follow job functions, so list each role that needs ePHI and the minimum it requires under the Privacy Rule's minimum necessary standard. Contractors, locum staff, trainees, and maintenance or IT vendors need the same treatment as employees, with their own authorization records and end dates. Confirm who approves each grant and whether contractor accounts expire automatically when their engagement ends.
Clearinghouse functions inside a larger organization
The isolation specification applies only when a health care clearinghouse operates inside a larger organization. If your organization converts nonstandard data into standard transactions or the reverse, ask counsel whether that unit is a clearinghouse, then confirm that its ePHI and staff are separated from the rest of the organization. Shared network segments, shared domain administrators, and shared reporting databases are the usual gaps to check.
Identity providers and single sign-on
Your identity provider decides who can sign in to each application, so it is part of the access authorization chain even when it is not an ePHI system. Directory services, single sign-on brokers, and multifactor services should appear in the inventory with their admin roles, group mappings and logging. Open-source options such as authentik and FreeIPA can host this layer inside your own infrastructure, which keeps the access records under your control.
Vendor-hosted tools that touch ePHI
SaaS scheduling, telehealth, transcription, analytics and ticketing tools often receive ePHI, sometimes without anyone listing them as systems. Each one needs its own access list, administrator accounts, and a check of whether the vendor is a business associate that has signed an agreement. Ask each vendor how it provisions and removes users, and whether it supports single sign-on and audit logs for those accounts.
How an assessor tests access authorization
This specification applies only when a health care clearinghouse sits inside a larger organization. An assessor first confirms whether the entity has a clearinghouse function at all. If it does not, the specification is not applicable and the file should say so with a short rationale. If it does, the assessor reviews the boundary between the clearinghouse and the rest of the organization, looking at how ePHI is kept apart from the parent's systems, staff and data stores. Testing is mostly a walkthrough of architecture and access groups, followed by sampling of who can reach clearinghouse data.
- Organization chart and data flow diagram: Shows which units perform clearinghouse functions and where their ePHI is stored and processed.
- Directory and group structure: Exports showing whether clearinghouse systems use separate groups, roles or tenants from the parent organization.
- Sampled access grants: Staff outside the clearinghouse who hold access to its data, with the approval behind each one.
- Network and application segmentation: Firewall rules, VLANs or application permissions that enforce the separation.
- Common findings: Shared administrator accounts across both units, shared file shares, and separation that exists on paper but not in the directory.
Before an assessment, confirm in writing whether the organization performs clearinghouse functions, and be ready to show the boundary in configuration, not only in an org chart.
This addressable specification asks whether the organization has policies and procedures that define who may grant access to ePHI and on what basis, such as access to a workstation, transaction, program or process. The assessor reads the written policy first, then checks whether practice follows it. A policy that names roles but does not say who approves each role, or that is never followed, is a common finding. Testing usually combines a policy read with a sample of recent access grants traced back to an approval record.
- Written authorization policy: Defines the approvers, the criteria for each access level and the process for exceptions.
- Approval records: Tickets or signed requests showing that a named authorizer approved each sampled grant before it took effect.
- Role definitions: Mapping of job functions to the ePHI they need, consistent with the minimum necessary approach.
- Access sampling: Assessor selects accounts and checks each grant against its approval and the policy in force at the time.
- Common findings: Grants made by help desk staff without approval, roles that do not match any written definition, and policies that were never updated after staff changes.
Check that the approval trail is retained and that the policy reflects how access is granted in practice, not an idealized version of it.
This specification asks whether the organization has procedures to establish, document, review and change each user's access rights in line with the authorization policy. It is the specification behind periodic access reviews. An assessor looks for evidence that access was set up correctly when someone joined, changed role or moved within the organization, and that it was reviewed afterward. Testing often compares the current access of a sample of users against their documented role and the approval on file, then checks whether reviews were actually performed.
- Access review records: Dated reviews showing who reviewed which accounts, what they decided, and what changes followed.
- Change logs: Directory or identity provider logs showing when rights were added, changed or removed.
- Role change samples: Users who moved between roles, with evidence that old rights were removed as well as new ones granted.
- Access accumulation checks: Users holding combined rights that no single role was meant to allow.
- Common findings: Reviews that were scheduled but never signed off, access that carried over after a transfer, and no record of who made a change.
Confirm the review frequency with your own risk analysis, since the rule does not set an interval, and keep the reviewer's decision records for the retention period your documentation policy requires.
How to implement access authorization in order
This sequence turns the access authorization standard into working controls: it defines who holds ePHI, who approves access and how grants are provisioned, changed and reviewed, so the organization can show each step to an assessor.
Inventory ePHI systems and job roles
Identify every system, application, database, file share and backup location that stores, processes or transmits ePHI, then list the job roles that touch it. Compare this inventory with the risk analysis so no ePHI location is missing. The security official and system owners do this work, and the output is a system inventory paired with a list of roles and the data each role needs. The step is done when every ePHI system has a named business owner and every role has a documented purpose.
Approve the access authorization policy
Write the policy that states who may authorize access to ePHI, on what basis and for which workstations, transactions, programs or processes. It should reflect the Privacy Rule's minimum necessary approach, so each role receives only the ePHI it needs for its function. Leadership and the privacy and security officials approve the policy, and the signed approval with its effective date is the output. Confirm the approval chain with your own counsel and compliance lead, since the Privacy Rule details vary by organization.
Build the role-to-access matrix
Translate the approved policy into a matrix that maps each role to the systems, data sets and permission levels it may hold, and names the approver for each mapping. Owners review the matrix against the inventory to remove access that exceeds the role's function. The output is a role matrix with an approver field for every row and a record of the owner sign-off. Keep the matrix under version control so later changes leave a trail.
Isolate clearinghouse functions where applicable
If the organization includes a health care clearinghouse operating within a larger entity, separate its ePHI and its systems from the rest of the organization so that unauthorized workforce members cannot reach them. This required specification applies only when the clearinghouse exists. Enforce the separation through identity and network controls, and confirm it with the owners of both the clearinghouse and the affected systems. The output is a documented separation design and test evidence showing that blocked access works. Organizations without a clearinghouse record that the specification does not apply.
Establish provisioning and modification workflows
Create a documented workflow for requesting, approving, granting, changing and removing access, with each step tied to the matrix. Identity tools can enforce the workflow: for example, an identity provider such as authentik can delegate sign-in for applications, and FreeIPA can provide single sign-on for Linux and UNIX environments, so that group membership reflects the approved matrix. Confirm each platform's capabilities against its current documentation before relying on them. The output is a provisioning workflow, its tickets or logs for sample requests, and a rule that no access is granted outside it.
Schedule and record periodic access reviews
Set a recurring review in which designated reviewers confirm, change or revoke each user's access against the matrix. Access certification campaigns, such as those in midPoint, let reviewers decide within a set timeframe and help catch access that has accumulated over time or conflicts with segregation of duties. Choose the review interval from your risk analysis, since the rule sets no fixed frequency. The output is a signed review record for each cycle, listing decisions, revocations and the owner who approved them, which also feeds the evaluation standard.
Evidence that proves access is authorized and reviewed
Auditors testing information access management ask for a paper trail that connects a policy to a grant, a grant to a reviewer decision, and a decision to a removed account. The cards below cover the artifacts that form that chain and how to keep each one current between assessments.
Written access authorization policy
This is the policy the standard requires: procedures for authorizing access to ePHI that are consistent with the Privacy Rule's minimum necessary approach. It should name who may approve access to each system, on what basis, and which access requests are refused. Review it on a fixed schedule and after any change to the risk analysis, the systems in scope or the organization's structure. Check that the version history shows who approved each revision and when.
Role-to-access matrix
A matrix maps each job role to the applications, data sets and administrative functions it may use. It turns the policy into something an assessor can test against a sample of accounts. Keep it in version control or a managed register, and tie each role change to an approval. Mismatches between the matrix and live group memberships are the most common finding an assessor will raise, so compare them before every review cycle.
Approval records for grants and changes
Each access grant, elevation or change needs a record showing the requester, the approver, the access granted and the justification. Records should exist for both new access and modifications, because the specification covers establishing and modifying access rights. Ask whether approvals happen in the ticketing system or in the identity platform, and confirm that approvers cannot approve their own requests.
Provisioning and deprovisioning tickets
Provisioning and removal tickets show that access is created and withdrawn on the authorized path. Track the time between a role change or departure and the removal of access, and keep the timestamps from the directory or identity provider alongside the ticket. Gaps between HR events and access changes often point to weak procedures, so sample them during internal checks and document the reasons for any exceptions.
Periodic access review records
Access reviews show that someone checked whether existing rights still fit the policy. Each review should list the accounts or roles examined, the designated reviewer, the decision for each item (keep, change or revoke), and the date the revocations were completed. Open-source access certification tooling such as midPoint can run these campaigns with recorded reviewer decisions, but confirm the reviewer, timeframe and retention settings against your own procedure before relying on them.
Isolation documentation for clearinghouses
Where a health care clearinghouse operates inside a larger organization, the required isolation specification needs documentation of the separation. Include network diagrams, directory and database boundaries, the accounts permitted to cross them, and the review of those cross-boundary accounts. If no clearinghouse function exists, record that determination with the date and the person who made it, since assessors will ask.
What meeting 164.308(a)(4) costs in money and effort
This table breaks down the cost components of meeting information access management, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to scope internal effort against outside help, and to know what to request in a written quote. No dollar figures are shown because none are supplied for this standard.
| Cost component | Who pays or does the work | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Access authorization policy and role design | Security official, privacy officer and business owners, with optional outside consultant time | One-time to build, recurring to revise | Number of systems holding ePHI, number of distinct job roles, and how often roles change |
| Identity tooling and licenses | Organization, if commercial; none for self-hosted open-source identity platforms such as authentik, FreeIPA or midPoint | Commercial licenses recur; open-source software carries no license fee but still needs hosting | Commercial per-user pricing, user count, and whether existing directory services can be reused |
| Engineering to integrate applications with the identity provider | Internal platform or IT engineers, or an implementation partner under a fixed-scope agreement | One-time per application, plus recurring work when apps change | Count and age of applications, support for standard protocols such as OIDC, SAML or LDAP, and custom legacy software |
| Access establishment and modification workflow | IT service desk and application owners approving requests | Recurring with each joiner, mover and change request | Request volume, whether approvals are automated, and how precisely access is mapped to roles |
| Periodic access review by managers | Managers and designated reviewers, supported by IT to produce access lists | Recurring on the review cycle the organization sets | Number of access items per reviewer, quality of role data, and whether review campaigns are tooled rather than run by spreadsheet |
| Clearinghouse isolation, if applicable | Engineering and network staff for separation of ePHI systems | Mostly one-time, with recurring checks | Whether a clearinghouse function sits inside a larger organization and how many shared systems must be separated |
| Evidence upkeep | Compliance lead and system owners who keep access records, approvals and review sign-offs | Recurring, usually tied to each review cycle | Retention needs, log export quality, and whether evidence is generated automatically |
| External review or assessment | Independent assessor or auditor; an implementation partner prepares evidence but does not attest | Recurring if assessments are scheduled, one-time for remediation | Assessment scope, number of systems in scope, and readiness of evidence before the assessor arrives |
Who owns access decisions and who prepares the evidence
Under 164.308(a)(4), the covered entity or business associate must set the policies and procedures for authorizing access to ePHI, and those policies must align with the Privacy Rule's minimum necessary approach. Deciding who may see which systems, transactions or data sets is a management and compliance decision that depends on the organization's own risk analysis and workforce structure. It cannot be delegated to a vendor or auditor without losing the accountability the rule assigns.
- Access policy: Defining the roles, the approval basis for each role and the clearinghouse isolation decision, if one applies.
- Approvals: Named managers or data owners who approve access requests and document the reason.
- Periodic reviews: Deciding who reviews access, how often, and what happens to access that is no longer justified.
- Exceptions: Accepting or rejecting any deviation from policy, with a documented rationale.
Confirm that your named access owners can show their approval history for a sample of accounts, because that history is what the assessor will ask for first.
An implementation partner such as DeployOpen can plan, integrate and document the technical side of access management in the organization's own infrastructure. The partner configures the identity and access systems that carry out the organization's decisions, and it prepares the records that show those systems work as described. The partner does not decide who should have access, and it does not approve access requests.
- Integration: Connecting applications to a self-hosted identity provider such as authentik, or to a directory service such as FreeIPA, so sign-in and group membership follow one source.
- Review tooling: Setting up access certification campaigns in a tool such as midPoint, with reviewers named by the organization.
- Evidence preparation: Exporting group membership, approval records, review outcomes and configuration baselines in a format the assessor can sample.
- Documentation: Writing the system descriptions and runbooks that explain how each control is operated.
Agree in writing which of these tasks are in scope, and confirm who holds the administrator credentials after handover.
An independent auditor, assessor or certification body tests the access controls and reaches its own conclusions. HHS states that no Security Rule standard requires a certification, and it does not recognize private certifications, so the assessor's work is evidence for the organization's own compliance position rather than a HIPAA certificate. The assessor must stay independent of the people who designed and operated the controls, which is why the partner's role stops at preparing evidence.
- Sampling: Selecting accounts and approvals at random or by risk, then checking them against the organization's policy.
- Walkthroughs: Observing how access is requested, approved, provisioned and removed.
- Testing: Confirming that system settings match the documented configuration.
- Conclusions: Issuing findings and, where the engagement calls for it, a formal report that only the assessor can sign.
Do not let the implementation partner write the assessor's conclusions or present the partner's preparation work as the assessor's test results.
The line between roles is what keeps the evidence usable. Partners and internal teams may prepare, explain and rehearse the evidence, but the assessor must be able to test it without relying on the preparer's word. Outsourcing that crosses this line, such as a vendor approving its own access or writing the conclusions of the test, weakens the result for regulators and for any customer who relies on it.
- Permitted preparation: Gap checks, mock sampling and evidence packaging before the assessor arrives.
- Not permitted: A partner approving access, signing review outcomes as the organization's decision or acting as the assessor.
- Records of decisions: Keeping the organization's approvals in its own system, not only in a partner's ticket queue.
- Access to evidence: Giving the assessor direct, read-only access to logs and configurations where practical.
- Scope statements: Writing down which systems and processes the partner touched and which the organization ran itself.
Ask any outside party to state in writing what it will decide, what it will prepare and what it will not do.
Where access authorization programs usually fall short
Most access problems under 164.308(a)(4) are not missing tools. They are missing decisions: who approves access, what is recorded, and whether anyone looks again later. The gaps below are the ones assessors and OCR reviewers tend to find first, each with a closing action your team can check this quarter.
No documented authorization policy
Access is often granted by habit, so no written rule says who may approve access to ePHI, to which workstations, transactions, programs or processes, and on what basis. The standard requires policies and procedures for authorizing access that are consistent with the Privacy Rule's minimum necessary approach. Action: write one authorization policy that names approvers and the access criteria for each role, then get it signed off by the security official.
Access grants without approver records
Teams often grant access through chat messages or tickets that do not record who approved the request or why. Without that record, an assessor cannot tie an access right back to the authorization policy, and the addressable access authorization specification is hard to show as implemented. Action: require a ticket for every grant that captures requester, approver, role, systems and business justification, and sample a set of grants against it.
Access accumulation after role changes
When people change jobs, new access is added but old access is rarely removed, so staff end up holding rights from every past role. This is the drift that the access establishment and modification specification is meant to prevent, since it calls for rights to be modified based on the authorization policy. Action: tie each role change to a documented removal step, and check a sample of movers for rights their new role does not need.
Access reviews that rubber-stamp
Periodic reviews often list access items without context, and reviewers approve everything to finish quickly. A review that never removes anything gives little evidence that access is being evaluated. Campaign tools can require reviewers to keep, change or revoke each item within a set timeframe, which makes the decision visible. Action: require a reviewer decision on every item, record revocations, and confirm the reviewer is not the person who holds the access.
Clearinghouse data reachable by the parent
Where a health care clearinghouse sits inside a larger organization, the required isolation specification means the parent's staff and systems should not reach the clearinghouse's ePHI without authorization. Shared file shares, shared databases and broad domain groups are common ways this fails. Action: map every system that stores clearinghouse data, then test whether accounts outside the clearinghouse can read it.
Local accounts outside the identity provider
Applications with their own local user tables fall outside central access decisions, so a leaver can keep working in one system after the directory account is disabled. Routing sign-in through a central identity provider lets one authorization decision apply everywhere, and the technical access control standard depends on this enforcement. Action: inventory local accounts in each ePHI application, move sign-in to the central provider where the application supports it, and document any exceptions with compensating checks.
Questions buyers ask about access authorization before hiring help
How much effort does access authorization work take?
The effort depends mainly on how many systems hold ePHI, how many roles exist, and how much access is granted by exception today. The work has three parts: writing the access authorization policy, mapping who may reach which workstations, transactions, programs and processes, and then setting up the process to establish, review and change access over time. The policy and role mapping are one-time work. Periodic access reviews, onboarding and offboarding requests, and exception handling recur for as long as the organization holds ePHI. Ask any consultant or implementation partner to break its quote into these parts so you can see which costs are one-time and which will continue in your own staff time.
Can we do access authorization in-house without outside help?
Yes, a covered entity or business associate can write and run this standard with its own staff, and the rule does not require an outside firm. The usual gap is capacity and independence rather than permission. Teams often lack time to inventory every system that touches ePHI, or the same people who grant access are the ones checking it. If you bring in help, the organization still owns the policy, the approvals and the decisions. An implementation partner can prepare systems, role models and review records, while your security official and business owners keep control of who gets access.
What do we need from our own staff for this work?
Expect to supply four kinds of input:
- The system owner for each application or data store that holds ePHI, who can confirm what access exists and why.
- A business owner who can define each role and approve who may hold it.
- Your security official, who signs off on the authorization policy and the review cycle.
- Your HR or workforce team, who provides joiner, mover and leaver events so access changes follow real employment changes.
Without these inputs, access records will reflect what systems say rather than what the business intended. Ask the provider to list the specific people and hours it needs from each group before work starts.
How long does access authorization take to implement?
The duration depends on scope: the number of systems in play, the state of existing role definitions, and how many approval steps your organization requires. Fixed-scope engagements have their timeline agreed in writing before work starts, and that schedule is the one to rely on. Do not accept an informal estimate that is not tied to a written scope. Ask the provider which dependencies could extend the timeline, such as system owners who are slow to confirm access or identity systems that need changes before roles can be enforced.
Is there a HIPAA certificate for access authorization?
No. There is no HIPAA certification, and HHS does not endorse or recognize certifications offered by private organizations. HHS has also stated that no Security Rule standard requires an entity to certify compliance, and a private certificate does not stop HHS from later finding a violation. What you can provide is evidence: a written authorization policy, role definitions, approval records, periodic access review results and offboarding records. An independent assessor may test that evidence and report on it, but the assessor's report is not a HIPAA certificate. Be cautious with any vendor that offers one.
Can we skip the addressable access specifications?
You may not skip them silently. Access authorization and access establishment and modification are addressable, which means you must assess whether each one is reasonable and appropriate for your environment. If it is not, you must document why and implement an equivalent alternative measure that is reasonable and appropriate. Document the assessment, the reasoning and the alternative in your risk analysis and policy set. An undocumented decision not to implement an addressable specification is the weakest position in an OCR review. Your security official should own that decision, and counsel should review it where the choice is significant.
How does access authorization connect to access control under 164.312(a)(1)?
This standard decides who should have access to ePHI, and the technical access control standard in 164.312(a)(1) makes systems enforce those decisions. In practice, the policies and role definitions from this standard are configured in identity and access systems, such as identity providers, directory services and access certification tools, so that technical controls reflect the approved rights. Engineers should check that every role in the policy maps to an enforced setting in each system, and that changes made in the policy flow through to the systems. Open-source identity tools such as authentik, FreeIPA and midPoint can support parts of this chain, but confirm each capability against your own environment before relying on it.
How DeployOpen scopes and prepares access authorization evidence
DeployOpen starts with a written scope agreed before any work begins. For 164.308(a)(4), that scope names the systems that hold or broker ePHI, the applications that rely on identity delegation, the clearinghouse functions (if any) that must be isolated, and the roles that approve and review access. Most engagements are fixed-scope, so deliverables and timelines are set in writing, and a quote follows from that scope. Ask for the scope document to list each access decision point, who owns it, and which of the three implementation specifications it supports. DeployOpen does not issue audit reports or certifications. Your organization owns its access policies, and an independent assessor decides whether the evidence meets the standard.
Implementation runs inside your own cloud accounts, data centers or air-gapped network. Depending on the scope, that can include an identity provider such as authentik, which delegates sign-in to applications through OAuth2, OpenID Connect, SAML, LDAP or proxy providers, and a directory and Kerberos layer such as FreeIPA for Linux and UNIX hosts. A single authoritative source for identities and group membership is the decision that matters most, because every access rule downstream depends on it. Access certification campaigns in midPoint can be configured so designated reviewers keep, change or revoke role assignments within a set timeframe, which supports the periodic review that access establishment and modification requires. Confirm each connector and feature against current vendor documentation before it is written into the design.
The evidence package is prepared for your assessor, not written on your behalf. Typical deliverables include the access authorization policy and its approval workflow, the configuration exports that show group-to-application mappings, records from completed access reviews, the clearinghouse isolation design and its access restrictions, and the procedure for changing access. Each item should be traceable to the policy it implements and dated. Your security official and compliance lead should confirm which artifacts your assessor will request and how long they must be retained. The organization stays responsible for running the reviews, making the decisions and keeping the records current after handover, and ongoing support or retainer work can be scoped separately if you want help with that operation.
