164.308(a)(4)(ii)(C) Access establishment and modification

164.308(a)(4)(ii)(C) Access establishment and modification: what it asks for and why it is hard

An auditor or customer questionnaire that asks how ePHI access is granted, changed and reviewed is asking about 45 CFR 164.308(a)(4)(ii)(C). The specification calls for policies and procedures that, based on the entity's access authorization policies, establish, document, review and modify each user's right of access to a workstation, transaction, program or process. In practice, that means you need a documented answer for each path into ePHI: how a new hire receives a role, who approves it, where the approval is recorded, how a role change replaces old rights, and how you know the rights in the system still match the approved policy. The specification is addressable, not optional. Under 45 CFR 164.306(d)(3), you must assess whether each addressable specification is reasonable and appropriate for your environment, implement it if it is, and if it is not, document why and implement an equivalent alternative measure that is reasonable and appropriate.

The hard part is the review. Access rarely shrinks on its own. People change teams, take on temporary projects, and keep rights they no longer need, and service accounts and integrations pick up permissions that nobody revisits. Establishing access at onboarding is comparatively simple to document. Showing that the rights on a given day still match the access authorization policy, across the EHR, file shares, databases, cloud consoles and remote access tools, takes a recurring review with named reviewers, a defined cadence and recorded decisions to keep, change or revoke. Confirm with your risk analysis how often reviews should run for each ePHI system, and ask your identity vendor or platform team whether the review output can be exported as evidence that an assessor can sample.

Which systems, accounts and third parties fall under access establishment and modification

Access establishment and modification applies wherever a user's right to reach ePHI is granted, changed or withdrawn. The scope is set by the organization's own risk analysis and access authorization policy, so the decisions below should be made explicitly and documented.

Workstations and applications that hold or reach ePHI

Start with an inventory of every workstation, server and application where ePHI is stored, processed or displayed, including those reached through a remote desktop or a browser. The specification covers the right of access to each workstation, transaction, program or process, so each one needs a named access owner and a rule for who may be granted it. Check whether shared workstations, kiosks and browser-based tools that cache data are inside the inventory.

Transactions and programs with access rules

Some access is granted per function rather than per system, such as the ability to view billing records, release lab results or export a patient list. These transaction-level and program-level rights are where minimum necessary access is most often too broad. Document each function that touches ePHI, the role allowed to perform it, and the approval needed before a modification is made.

Directory and identity systems that issue access

The directory or identity provider is often the place where access is actually established, so changes made there propagate to every connected application. Confirm which directories, single sign-on providers and group memberships feed each ePHI system, and who can change them. Modifications made in one system but not propagated to others are a common gap that a review should test directly.

Service accounts and automated processes

Service accounts, API tokens, integration jobs and scheduled scripts can read or change ePHI without a person signing in. Decide whether your access policy counts them, and if so, assign each one an owner, a documented purpose and a review date. Confirm whether the risk analysis treats credentials that never expire or are shared between jobs as a higher risk.

Vendor and contractor accounts

Vendors, contractors, consultants and business associate personnel may hold accounts for support, maintenance or implementation. Their access must be authorized, reviewed and removed on the same basis as workforce access, and their arrangements must be documented under the business associate standard. Ask each vendor which of its staff hold accounts, how those accounts are approved and how quickly they are closed when the engagement ends.

How an assessor tests access establishment and modification

This table compares what an assessor does, what evidence they ask for and where organizations usually fall short when testing 164.308(a)(4)(ii)(C). Read each row as one test step: the approach, the records it requires, and the findings that tend to appear. The main takeaway is that the written policy only counts if grants, changes and reviews can be traced to it in the live systems.

Test area	Test approach	Evidence requested	Common findings
Written access authorization policy	Read the policy and confirm it states who approves access to ePHI, on what basis, and how grants, role changes and reviews are carried out	Current signed policy, version history, procedures for establishing, modifying and reviewing access	Policy names no approver, or procedures exist only in an administrator's head
Link between policy and procedures	Check that establishment, modification and periodic review procedures reference the same approval roles and access categories as the policy	Procedure documents, approval matrix, role or access category definitions	Procedures use role names that do not exist in the directory or ticketing system
Sample of new access grants	Select a sample of recently created accounts and trace each to a documented request and approval made before access was provisioned	Access request tickets, approval records with dates, account creation logs, group membership at creation	Undocumented approvals, approvals dated after the account was created, or verbal requests with no record
Sample of role changes	Select users who moved departments or roles and compare their previous and current access against the approval for the change	Transfer or role-change requests, approvals, before and after group or permission snapshots	Access accumulated from earlier roles and never removed after a transfer
Sample of periodic access reviews	Confirm reviews happened at the frequency the organization set, were performed by an appropriate reviewer, and covered the in-scope systems	Review campaign records, reviewer assignments, completion dates, population exported for each review	Reviews not completed on schedule, reviewers approving their own access, or systems missing from the review scope
Outcomes of access reviews	Check that changes or revocations decided in a review were carried out in the target systems and recorded	Review decisions, change tickets, system logs showing removals or modifications after the decision	Decisions recorded as revoke but access still present in the application
Documented decisions versus live systems	Compare the directory, identity provider and application permissions against the approval records for a sample of accounts	Directory or identity provider exports, application role lists, matching approval records	Accounts in target applications with no matching approval, or group membership that differs from the record
Access left in place after a role change or leaving	Look for accounts whose owners changed role or left, and check whether the old rights were removed in a timely way	HR change feed or termination records, deprovisioning logs, last-login data	Former staff or contractors with active access, or old role permissions kept after reassignment

Implementing access establishment and modification in six steps

This sequence turns the access authorization policy into a repeatable cycle of granting, changing, reviewing and recording each user's access to ePHI, so you can show an assessor how rights were set and kept current.

Confirm the access authorization policy and its owners
Start by confirming the written access authorization policy that states who may approve access to ePHI, to which workstations, transactions, programs and processes, and on what basis. Name a policy owner, usually the security official with input from data owners and HR, and record who signs off. The output is an approved, dated policy that every later step can cite. Confirm that it matches the outcome of your risk analysis, since the rule expects access decisions to rest on the entity's own authorization policies.
Define the access request and approval path
Build a request template that captures the requester, the user, the ePHI systems or data involved, the business reason, the role requested and the approver. Map an approval path for each system class so that the data owner or manager approves access and the security team checks it against the policy. The output is a request form or ticket template and a written approval matrix. Test the path once with a sample request to confirm that nothing is granted without an approval record.
Set modification triggers for role and department changes
Create a trigger list of events that require access to be changed, such as a transfer between departments, a change in job role, a new project assignment, or a clearance decision that narrows access. Connect each trigger to a named owner who starts the change request, and decide how HR or managers notify IT. The output is a documented trigger list linked to the request workflow. Reviewing this list after organizational changes keeps modifications from depending on memory.
Set the review cadence and assign reviewers
Choose how often access rights are reviewed and who reviews them, based on the risk analysis and the sensitivity of each system. Assign a reviewer for each application or group, who should be someone who knows the business need but is not the person who granted the access. Certification tools can run these reviews as campaigns in which reviewers keep, change or revoke each access item within a set timeframe. The output is a review schedule, a reviewer assignment list and a record of the first completed review.
Connect the identity source to target applications
Connect the authoritative identity source, such as a directory or identity provider, to the ePHI applications so that granting, changing and removing access flows from one place. Open-source options include authentik, whose SCIM provider pushes user and group changes to target applications and deprovisions users when they lose access, and FreeIPA, which stores users, groups and access control centrally. Confirm each target application supports the chosen protocol and the sync behavior you need, because provisioning depends on the application. The output is a provisioning configuration and a test log showing a grant, a change and a removal reaching each target.
Retain records of each step
Keep the evidence that shows each access decision was made under the policy: the approved request, the approver, the provisioning event, the modification record, the review result and any revocation. Store these records so they can be retrieved for an assessor or OCR inquiry, and align retention with your documentation policy under 164.316. Confirm with counsel how long records must be kept, since the Security Rule's documentation requirements are separate from access logs. The output is a retained access log linked to request IDs, reviewer decisions and provisioning events.

Evidence that proves access establishment and modification

Access establishment and modification is proven by records that show a request was authorized, access was granted or changed as approved, and rights were reviewed over time. The cards below cover the artifacts an assessor is most likely to sample, and each one is owned and maintained by your organization, not by an implementation partner or auditor.

Written access establishment policy

This is the documented rule set that says who may establish, change or remove access to ePHI systems, and on what basis. It should tie each role to the access authorization policy referenced under 164.308(a)(4)(ii)(B), so an assessor can trace a single user's rights back to an approved standard. Check that the policy names an owner, an effective date and a review date, and that prior versions are retained. Your organization writes and approves this policy.

Access request and approval records

Each grant, change or extension of access should have a request that names the user, the system or application, the requested role and the approver. Assessors sample these records to confirm that approval happened before provisioning, not after. Keep tickets or workflow exports in a system that cannot be edited silently, and confirm that the approver is authorized by the policy for that resource.

Provisioning and deprovisioning logs

Directory and identity system logs show when an account was created, when group or role membership changed, and when access was removed. Compare these timestamps against the approved request to find access granted without approval or removed late. Confirm that your identity platform retains these logs for a period you set in your own retention policy, and that someone reviews them rather than only storing them.

Periodic access review records

Periodic reviews show that a reviewer looked at each user's current rights and decided whether to keep, change or revoke them. Each record should list the reviewer, the decision and its timestamp, and the follow-up change made. Export campaign results at the close of each cycle and store them with the review schedule so the history survives platform upgrades. Ask your platform team to confirm which review features your tooling supports before you commit to a process.

Documented exceptions and alternative measures

Where a specification such as this one is addressable and the organization decides it is not reasonable and appropriate as written, the rule requires documentation of why and an equivalent alternative measure. Each exception should name the affected system, the reason, the compensating control, the approver and a date for reassessment. Assessors look for exceptions that were reviewed on a schedule, not ones recorded once and forgotten.

Review schedule and cadence record

The schedule itself is evidence that reviews are planned rather than ad hoc. It should set the review frequency for each system tier, name the responsible owner for each campaign, and show completion dates for past cycles. Keep it with the policy and update it whenever the risk analysis changes the priority of a system. The organization sets the cadence based on its own risk analysis, so confirm the interval with your security official and compliance lead.

How authentik, FreeIPA and midPoint produce access establishment evidence

Three self-hosted open-source tools can generate much of the evidence an assessor asks for under 164.308(a)(4)(ii)(C), but each covers a different part of the workflow. authentik, licensed under MIT, handles provisioning into the applications that hold ePHI. Its 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 a user from the target when that user loses access to the application. The provisioning log and the group membership state are the records to pull when an assessor asks who was granted access to a given application, when, and on whose approval. Confirm that each target application you depend on supports SCIM 2.0 and that the hourly full sync interval meets your own access change requirements, because a removal that waits up to an hour may not be acceptable for every ePHI system.

FreeIPA, licensed under GPL-3.0-or-later, provides the central identity store that many of those decisions reference. It uses 389 Directory Server as a multi-master LDAPv3 directory that holds users, groups, hosts and other network objects, with centralized access control and delegated administration through its web UI and command line tools. Delegation matters for evidence: it lets you show that only named administrators can change access rules, and that help desk staff can reset passwords without being able to alter group membership for ePHI systems. Confirm that the delegated roles you define match the access authorization policy you wrote, and that the directory's audit trail is retained long enough for your own record retention rules.

midPoint, licensed under EUPL-1.2+, supplies the review step that most organizations struggle to evidence. Its access certification campaigns assign designated reviewers who must decide within a set timeframe whether to keep, change or revoke access items such as role assignments. Each campaign produces a record of who reviewed what and what they decided, which is the strongest direct evidence for the periodic review the specification calls for. The decisions still belong to your managers and data owners, and no tool can judge whether an access right is appropriate. Tools also do not make an organization compliant on their own. Before relying on any of the three, confirm that each one meets your own technical, security and support requirements, and have your security official and an independent assessor review how the records fit your documented policies.

What meeting access establishment and modification costs

This table compares the cost components of meeting 164.308(a)(4)(ii)(C), showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for building a written quote. No fee or duration figures are supplied for this topic, so the costs are described by driver rather than by amount.

Cost component	One-time or recurring	What drives it up	What keeps it down
Policy and procedure drafting for access authorization and review	One-time, with periodic revision	Number of user populations, workstations and programs in scope, and how many approval paths exist	Reusing existing access policies and mapping them to the specification's required elements
Identity system setup and directory consolidation	One-time	Number of identity sources, inconsistent user records and nested group structures	A single authoritative directory already in use across target systems
Integration and provisioning connectors for target applications	One-time per application, plus upkeep	Number of target applications, custom APIs and applications without standard provisioning support	Applications that support standard provisioning protocols, or a small, stable application set
Role design and access model work	One-time, revisited on role changes	Role complexity, exceptions to standard roles and frequent organizational restructuring	Clear job-based roles agreed with business owners before build starts
Review campaign setup and manager time	Recurring, per review cycle	Review frequency, number of reviewers, volume of access items and reviewer turnover	Scheduled campaigns with clear decision deadlines and reviewers grouped by manager
Engineering time for access change requests and modifications	Recurring	Volume of joiners, movers and leavers, and manual approval steps	Automated provisioning driven by directory attributes and documented change workflows
Evidence collection and retention	Recurring	Number of systems producing evidence and the level of manual export work	Central logging of approvals, provisioning events and review decisions
External review or testing of the access model	Periodic, as scoped	Depth of the review, number of systems tested and remediation rounds	A written scope limited to the systems and records the risk analysis identifies
Assessor sampling of access records	Engagement-specific	Sample sizes the assessor selects, the number of populations and missing or inconsistent records	Complete, retrievable approval and review records kept in a consistent format

Who owns access establishment, who prepares evidence and who assesses it

Your organization owns the decisions this specification asks for. The Security Rule requires policies and procedures that establish, document, review and modify a user's right of access based on your access authorization policy, so the policy itself, the approvers who grant access and the reviewers who confirm continued need must be your people. No implementation partner or assessor can make those decisions on your behalf.

Access authorization policy: Define who may approve access to each system, on what basis, and at what level of privilege. This policy is the reference point every later access decision is tested against.
Approval workflow: Name the approvers for each application or group and decide whether approval is recorded in a ticket, an identity workflow or both.
Periodic access reviews: Set the review cadence, the reviewers for each population and the rule for what happens to access that is not confirmed.
Modification and removal decisions: Decide how role changes, transfers and leavers are handled and who signs off on exceptions.

Confirm that each of these items has a named owner and a written record of who approved what.

Where access establishment and modification usually breaks down

Access establishment and modification fails less often in policy than in practice: the approval is informal, the review is planned but not finished, or the account falls outside the process entirely. The cards below cover the gaps assessors most often find, with the evidence that closes each one.

Access granted by email only

Access is often approved in a chat message or email thread that is never linked to the account record. The specification expects access to be established based on the entity's access authorization policies, so the approval must name the user, the system or workstation, the role and the approver. Check that every active account traces back to a stored request and approval, and that the approver is the owner set in your policy. Keep the approval in the ticketing or identity system, not in an inbox.

Reviews planned but not completed

Teams often schedule access reviews on a calendar and then skip or half finish them without a record. The specification requires that access be reviewed and modified, so a missing review is a gap even when the policy is sound. Check for a dated review record for each system holding ePHI, the list of accounts reviewed, the decision made on each one and the follow-up tickets raised. Ask who is accountable when a reviewer does not respond.

Access kept after role changes

Access tends to accumulate when people move between teams, because new rights are added and old ones are never removed. Each change of role should trigger a fresh authorization decision, not just an addition. Check whether the identity system records group and role membership over time, and whether a role change produces a review task for the previous access. Access accumulation is the pattern that access certification campaigns are designed to surface.

Shared and service accounts outside review

Shared logins, break-glass accounts and service accounts often sit outside the joiner, mover and leaver process, so nobody reviews who can use them. The specification covers access to any workstation, transaction, program or process, which includes these accounts. Confirm that each shared or service account has a named owner, a documented purpose, a list of who can use it, and inclusion in the periodic review. Confirm with your own environment which accounts your directory can enumerate.

No documented equivalent alternative

Where an addressable step is not implemented, such as a formal approval for a small team, the rule requires a written reason and an equivalent measure if one is reasonable. Many organizations skip the documentation and simply operate without the step. Check for a decision record for each addressable access step that was not adopted, the reasoning from the risk analysis, and the compensating control that replaces it. Without that record, an assessor sees a gap rather than a decision.

Reviewers approving their own access

When the manager who approves access is also a user of the system, or the reviewer reviews their own entitlements, the review does not test anything. Segregation between the person who requests or holds access and the person who approves it is a basic check. Check that review campaigns exclude self-review, that approvers are recorded for each decision, and that the reviewer list is reconciled against the directory. Confirm that your identity platform can enforce this rule rather than relying on reviewers to avoid it.

Frequently asked questions about 164.308(a)(4)(ii)(C)

Is 164.308(a)(4)(ii)(C) required or addressable, and what does that change?

It is an addressable implementation specification, so it is not optional in the sense of being skipped. The entity must assess whether establishing, documenting, reviewing and modifying access is reasonable and appropriate for its environment. If it is, the entity implements it. If it is not, the entity must document why and put in place an equivalent alternative measure that is reasonable and appropriate. Under 45 CFR 164.306(d)(3), the assessment and the documented decision are the evidence an assessor will ask to see, so the reasoning matters as much as the outcome.

How often must HIPAA access reviews happen?

The Security Rule sets no review interval, so your risk analysis should decide how often access to ePHI is reviewed. A system with broad privileges, frequent role changes or high-risk data will usually justify a shorter cycle than a stable, narrowly scoped one. Whatever interval you choose, document it, follow it, and keep the review records, because an assessor will compare the practice against the policy you wrote. Ask your security official to tie the interval directly to the findings in the risk analysis.

What does implementing access establishment and modification cost, and what drives it?

No fixed price applies, because the cost depends on how many systems hold ePHI, how many identity sources exist, and how much access is currently managed by hand. The main components are staff time to write the access authorization policy and review procedure, engineering time to connect applications to a central identity source, and the recurring effort of running reviews and recording decisions. Ask any quote to list each system in scope, who approves access, which tasks are one-time (design, integration) and which recur (reviews, provisioning support, log retention).

How long does it take to implement, and what must we supply?

Duration depends on scope, so confirm the timeline in a written plan rather than relying on a general estimate. The work moves faster when you already have a documented access authorization policy, a list of ePHI systems, and named owners who can approve access. Expect delays where role definitions do not exist, where applications keep local accounts, or where approvers are unclear. Your team should supply system inventories, current access lists, approver names and the decisions your leadership has already made about who may see which data.

Can our in-house team implement this specification without outside help?

Yes, many organizations do this with internal staff, provided they have people who understand identity management, the systems holding ePHI, and the Security Rule itself. The harder part is usually sustained discipline: keeping the review cycle running, documenting every decision, and removing access promptly when roles change. Open-source identity tools such as authentik, FreeIPA and midPoint can automate provisioning and certification campaigns, but your team must configure them, test them, and own the resulting records. Confirm capacity before committing to a review schedule.

What can a partner do for audit evidence, and what can it not do?

An implementation partner can design the access model, configure identity systems, set up review workflows and prepare the policies, records and screenshots that show the control operating. The covered entity still owns its controls and the decisions behind them. A partner cannot issue an audit report or attestation, and an independent assessor is the party that tests the control and reaches a conclusion. Ask the partner to deliver evidence in a form your assessor can sample, and confirm which assessments, if any, sit outside its written scope.

Does HHS certify that our access controls meet HIPAA?

No. HHS does not certify compliance with the Security Rule, and it does not endorse or recognize private certifications. HHS has stated that no Security Rule standard requires an entity to certify compliance, and that a private certification does not prevent HHS from later finding a violation. What matters to OCR is whether your documented access decisions, reviews and records match what your systems actually do, so treat any vendor or consultant claim of HIPAA certification with caution.

How DeployOpen scopes and prepares access establishment evidence

DeployOpen plans, implements and documents self-hosted open-source identity and access tooling inside your own infrastructure, so access establishment and modification rules are enforced by systems you control. The organization owns its access authorization policy and its decisions, while DeployOpen prepares the systems and records that show how those decisions are carried out.

How we scope

We confirm which systems, applications and ePHI repositories fall within the access establishment and modification scope.
We document who approves access, the authorization policy in force and the review cadence the organization intends to follow.
Engagements are fixed-scope, so deliverables and timelines for the access evidence are agreed in writing before work starts.

How we build

We configure the identity provider and directory so that user and group records are the single source for granting and changing access.
We connect target applications through provisioning connectors, such as SCIM where the application supports it, and test that changes and removals flow through.
We set up access certification campaigns with named reviewers, decision deadlines and records of keep, change or revoke decisions.

How we hand over

We deliver written procedures for establishing, documenting, reviewing and modifying access, mapped to the organization's own policy.
We provide configuration records, test results and sample review reports that show how access changes were approved and carried out.
We confirm with your security official and compliance lead which evidence an independent assessor will ask for, since only the assessor issues conclusions.

How we support

Ongoing support, upgrades and continuous testing of the access tooling are available as retainers.
We can review periodic access review outputs and update connectors when applications or roles change.
Questions about whether a specific platform capability meets your access requirements are confirmed with the vendor before we commit to them.