What HITRUST 11 Access Control asks for and why it scores low
If a customer or contract requires HITRUST, Access Control is one of the domains you must pass. Access Control covers identity, authorization, account management, account lockout and privileged access, meaning how people and systems are given access, how that access is limited to what each role needs, how it is reviewed and removed, and how privileged accounts are controlled. It is one of the 19 assessment domains HITRUST uses to group CSF requirement statements and score e1, i1 and r2 reports, so weak results here affect the overall score of your assessment. The domain scores low for a practical reason: the controls depend on ongoing operational discipline rather than a one-time setup. According to the HITRUST 2025 Trust Report, Access Control was the lowest scoring e1 domain in both 2023 and 2024. Three of the top 10 requirements needing corrective action plans in 2024 sat in this domain, covering account lockout, reviewing access when a person changes role or leaves employment, and at least annual review of accounts and privileges. Those three gaps usually come from processes that exist on paper but do not run consistently across every system in scope.
Before you start readiness work, confirm with your assessor and HITRUST's current CSF materials exactly which requirement statements apply to your scope and assessment type, and whether your AI security certification adds statements in this domain. Then check your own environment against the three recurring gaps: whether lockout settings are enforced in every in-scope application and directory, whether role changes and terminations trigger access removal within a documented window, and whether an owner reviews accounts and privileges at least once a year with records that show what was decided. These checks are a sensible place to start, but the requirement statements themselves are proprietary to HITRUST, so this page describes the domain at a general level and your assessor will confirm the detailed expectations.
Which systems, accounts and teams fall inside the access control scope
Access control scope is usually set by where identities are created, where they authenticate and which accounts can change the environment. The cards below cover the decisions that most often expand or shrink the work before an assessor begins testing.
In-scope applications and infrastructure
Every application, database, administrative console and cloud tenant that stores or processes in-scope data needs an access model that can be explained and tested. Confirm which systems authenticate through the central directory and which keep local user tables, because each local store becomes a separate set of provisioning, lockout and review evidence. Document the boundary in the scope statement before you collect any samples.
The corporate directory as source of truth
The corporate directory is where most joiner, mover and leaver evidence originates, so assessors will ask whether it is the authoritative record for application access. Check whether applications sign in through the directory or keep their own accounts, and whether role changes flow through automatically. A directory that is not connected to applications produces access that never gets reviewed.
Service and privileged accounts
Service accounts, break-glass accounts, database owners and shared administrator logins often sit outside normal provisioning and rarely appear in access reviews. List each one with its owner, purpose, credential storage and who can use it. Privileged accounts are the ones most likely to be pulled into scope during testing, so an incomplete inventory is a common source of findings.
Third-party and contractor accounts
Vendor support staff, contractors and managed service providers with access to in-scope systems are part of the access control population even when they are not employees. Confirm how their accounts are created, time-limited, approved and removed, and whether the provider's own access reviews cover them. Where a provider's controls are relied upon, the boundary between your evidence and theirs needs to be written down.
Access certification campaigns and segregation of duties
Reviews of who holds which role need a defined population, named reviewers and a record of each decision to keep, change or revoke access. Scope the campaigns to the systems and roles you listed above, not only the systems that are easy to export. Check that reviewers are not reviewing their own access, since that weakens the segregation the review is meant to show.
AI security requirement statements
HITRUST's AI Security Assessment places AI security requirement statements in this domain, so an e1, i1 or r2 with that certification adds access requirements. Confirm which AI services, model endpoints, agent identities and tool credentials are in scope, and who approves their access. Ask HITRUST or your assessor to confirm the exact statements that apply to your certification type before you size the work.
How an assessor tests access control in a validated assessment
The assessor begins by selecting a sample of accounts and asking how each one was created, approved and removed. They compare the request, the approval and the system record for each sampled identity, and they look for accounts that exist without a matching business reason. The sample is drawn from the population the organization gives them, so a complete and current user listing from the source systems matters more than any single record.
- Request and approval pairs: A ticket or workflow record showing who asked for access, who approved it and when, matched to the account creation event.
- Role alignment: Evidence that the granted permissions match the approved role rather than a broader set copied from another user.
- Deprovisioning timing: Termination or transfer records compared with the date the account was disabled or changed.
- Orphaned accounts: Accounts with no owner, no recent login or no link to an employee or service record.
- Population completeness: An export from the directory or identity provider that the assessor can reconcile against HR and application lists.
Before fieldwork, confirm with your assessor which population and sample method they will use, and reconcile your own account listing against your source systems first.
Assessors test whether access reviews happen at the required frequency, whether the reviewer had enough information to decide, and whether the decisions were carried out. They ask for campaign records across the period under review and then trace a sample of reviewed items to the systems where the change should appear. A review that is signed off but never acted on is a common finding.
- Campaign schedule: Records showing that reviews ran at the frequency your own policy and the assessment require, including the annual review of accounts and privileges.
- Reviewer assignment: Evidence that the named reviewer owned the application or role under review.
- Decision evidence: Keep, change or revoke decisions with dates, and the context the reviewer saw.
- Follow-through: Tickets or system changes showing that revoked access was removed.
- Role change triggers: Reviews or access changes that followed a transfer or change in employment status.
If your reviews are run in a tool such as midPoint, export the campaign reports and the remediation log together so the assessor can follow each decision to its result.
Assessors inspect configuration directly, usually by screen share, exported settings or a sample of system output. They check account lockout thresholds, lockout durations and reset behavior, then examine privileged accounts separately because they carry higher risk. Lockout was one of the three access control items among the ten most frequent corrective action plans in 2024, so the configuration should be verifiable and consistent across systems.
- Lockout settings: The threshold, observation window and lockout duration for each in-scope directory and application.
- Coverage gaps: Systems that use local accounts or separate logins outside the central policy.
- Privileged inventory: A list of administrative and service accounts with their owners and purposes.
- Privileged activity: Records showing elevated access is granted for a stated need and removed afterward.
- Shared or generic admin accounts: Any such accounts, with the compensating controls and the list of who uses them.
Before the assessor arrives, export the lockout policy from every in-scope system and confirm no application sits outside it.
In a walkthrough, the assessor watches how a user signs in, how sessions expire and how applications accept identity from a central source. They are checking that authentication is enforced where the organization says it is, and that applications do not maintain separate credential stores that bypass policy. Walkthroughs usually follow one representative user and one administrator through the in-scope systems.
- Central sign-in: Applications delegating authentication to a single identity provider, such as authentik through OAuth2, OpenID Connect or SAML, or Keycloak federating an existing LDAP or Active Directory server.
- Single sign-on for Linux: Where used, evidence such as FreeIPA Kerberos configuration for Linux and UNIX hosts.
- Session behavior: Timeouts and re-authentication for privileged sessions.
- Local fallback accounts: Any application login that bypasses the central provider, with its justification.
- Live demonstration: A sign-in that the assessor can observe end to end, with the logs that show it.
Prepare a short diagram of identity flows for each in-scope application so the walkthrough follows your documentation rather than discovery during the session.
Most access control findings are not missing tools. They are gaps between written policy and what the records show. HITRUST's 2025 Trust Report named Access Control as the lowest scoring e1 domain in both 2023 and 2024, and three of the ten most frequent corrective action plans in 2024 fell in this domain. The findings below recur because they are easy to overlook between assessments.
- Late deprovisioning: Accounts left active after a role change or departure.
- Missing annual reviews: Privileges never reviewed at least once a year.
- Reviews without action: Decisions recorded but not carried out.
- Inconsistent lockout settings: Different thresholds across systems that the policy says should match.
- AI-related access: For organizations pursuing the AI security assessment, access to models, prompts and agent tools, which HITRUST places in this domain.
Ask your assessor to share the findings they saw in similar environments, and test your own sample against these points before fieldwork.
Implementing access control in the order an assessor will check it
The sequence below moves from knowing which accounts exist, to a single identity source, to rules for who gets what, to automated lifecycle handling, to protective settings and finally to recurring review. Each step leaves a record that an assessor can trace back to the next.
Inventory accounts and entitlements in scope
Start by listing every account, service identity and group that can reach the in-scope systems, including applications, databases, cloud consoles, network devices and shared administrative accounts. Record who owns each account, what it can do and where it is authenticated. The organization owns this inventory, and an implementation partner can help collect it from directories, application admin panels and cloud IAM exports. The step is done when every in-scope system has an owner-assigned account list that someone has reconciled against the directory. That list is the baseline every later step is measured against, so assessors often ask for it first.
Establish a single source of identity
Choose one authoritative directory for human identities, such as an existing corporate directory, and decide which systems will authenticate against it. Applications that cannot integrate directly can be routed through a federation or identity provider layer. Self-hosted options include authentik for OAuth2, OpenID Connect, SAML, LDAP and proxy-based sign-in, FreeIPA for single sign-on in Linux and UNIX environments, and Keycloak for federating users from existing LDAP or Active Directory servers. Confirm each product's current capabilities against its documentation in your own environment before you commit. Done means each in-scope application has a documented authentication path back to the chosen source, with local accounts listed as exceptions.
Define role-based access and least privilege
Translate job functions into a role catalog that states which entitlements each role grants, who approves it and which combinations are prohibited. Keep roles narrow enough that a typical user receives only what the job requires, and document exceptions with a named approver and a reason. The catalog is the output of this step, and it should be version-controlled and reviewed by system owners. An assessor will compare granted access against the catalog, so unmapped entitlements, broad administrator roles assigned to general staff and roles without owners are the usual findings to resolve before testing starts.
Automate joiner, mover and leaver processing
Connect the authoritative source to provisioning so that new hires receive roles from the catalog, role changes remove prior access, and terminations disable accounts across connected systems. Where automation is not yet possible, use a ticketed manual workflow with a named approver and a completion record. The provisioning record, meaning the request, approval, change and removal timestamps, is the evidence that this step works. Ask your team to confirm which target systems can be deprovisioned automatically, because some legacy applications will still need manual steps documented as compensating controls.
Configure lockout and privileged access controls
Set account lockout thresholds, session timeouts and re-authentication rules in the identity provider and in applications that keep local credentials. Separate privileged accounts from everyday accounts, require stronger authentication for administrative sessions, and record who holds privileged roles and why. The lockout configuration export, a list of privileged accounts with approvals, and sample logs showing lockouts and elevated sessions form the evidence set. Confirm the exact policy values with your security policy owner, since assessors compare configured settings against the documented standard rather than against a default.
Run recurring access review campaigns
Schedule access certification campaigns in which designated reviewers decide whether each entitlement should be kept, changed or revoked within a set timeframe. midPoint is one self-hosted option for running such campaigns over role assignments and counteracting access accumulation. Reviewers should be managers or system owners who are not the recipients of the access they review. The campaign record shows the population reviewed, reviewer identities, decisions, revocations and evidence that revocations were carried out. Confirm the review frequency your assessment scope requires, since assessors check that reviews happen on time and that a role change or termination triggers a review rather than waiting for the next cycle.
Evidence that satisfies access control and how to keep it current
Access control is the domain where assessors most often test history, not just current state. Each artifact below must show that the control operated across the whole look-back period, so the organization should keep them current as work happens rather than rebuilding them before fieldwork.
Provisioning and removal tickets
Approved tickets for every account creation, role change and termination in scope are the simplest proof that access was granted on authority. Assessors typically sample tickets and compare the approval date, the granted entitlements and the completion date against the HR event. Check that leavers' removal tickets close within the timeframe your own policy sets, and that no sampled account exists without a matching request.
Role and entitlement catalog
A current catalog of roles, the entitlements each role carries and the owner who approves it lets an assessor judge whether least privilege was designed in. Keep the catalog under version control so that a change in one quarter can be traced to a dated approval. Reconcile it against what the directory and applications actually grant, because a catalog that describes a model the systems do not follow will fail testing.
Directory and single sign-on configuration exports
Exports of identity provider, federation and directory settings show which applications delegate sign-in and which accounts they trust. Export them on a schedule and retain each dated copy, so the configuration in force on any sampled date can be shown. Confirm that the platform's own admin changes are logged and that applications cannot bypass the central sign-in path.
Lockout and session settings
Account lockout thresholds, lockout duration and session timeout values are configuration facts that assessors check against the stated policy. Capture them from the running system, not only from the design document, and record the date of each capture. Note any exceptions, such as service accounts, and the approval behind each one. The HITRUST 2025 Trust Report links account lockout to corrective action plans, so this evidence deserves particular attention.
Privileged account register
A register of every privileged, administrative and service account, with its owner, purpose, approving authority and last review date, is what assessors use to test privileged access. Reconcile the register against directory and system exports each cycle to find accounts that exist without a record. Remove or re-approve dormant accounts and keep the removal record.
Signed access review records
Review records show who checked which accounts and entitlements, when, what they decided to keep, change or revoke, and how each revocation was completed. The HITRUST 2025 Trust Report names reviews on role or employment change and at least annual reviews of accounts and privileges among the top corrective action plan items in 2024, so both need dated records. Keep every review cycle, including the follow-up tickets for revoked access, for the full look-back period.
How a central identity layer produces access control evidence
An assessor testing 11 Access Control looks for one connected record of who can reach what, and a central identity layer is the simplest way to keep that record in one place. In practice three components share the work. The corporate directory remains the source of truth for people and their roles. An identity provider sits in front of applications so that each application delegates sign-in instead of keeping its own user store. An access certification tool then holds periodic review campaigns in which designated reviewers record whether each access item is kept, changed or revoked. Each component produces a different kind of evidence, and the assessor will expect the three to agree.
Consider a simple illustrative case. A claims application is configured to hand sign-in to an identity provider such as authentik, which supports OAuth2 and OpenID Connect, SAML, LDAP and proxy providers. Accounts for that application are drawn from an existing LDAP or Active Directory server, either through Keycloak user federation or through the identity provider's own directory integration. When a person changes role, the directory change should flow through to application access, and the review campaign should show that a reviewer confirmed or removed the affected role assignments. Before relying on this design, confirm with your vendor exactly which synchronization and deprovisioning behavior each product supports in your version, and document the gap if a step still depends on a manual ticket.
The decision to make early is where the authoritative record lives and who owns each step of the review. Map each application to its system of record, decide which team approves access changes, and set the review cadence that your own policy and the 11 Access Control requirements call for. Then run a dry review on one application and check that the reviewer's decision appears in the tool, that the revocation reaches the application, and that the event is retained as evidence. Whether an external assessor accepts this design is a judgment made on the validated assessment, and only the assessor can make it.
What meeting access control costs in money and effort
This table lists the cost components of meeting the Access Control domain, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request, since no dollar figure or duration is supplied for this domain and the real numbers depend on your environment. The main takeaway is that open-source identity tools remove license spend, but integration, role design and review labor stay.
| Cost component | Who is paid or who spends effort | One-time or recurring | Main cost drivers |
|---|---|---|---|
| Identity tooling or licenses | Software vendor if commercial; none for self-hosted open source (authentik, FreeIPA, Keycloak, midPoint are open-source) | License is recurring if commercial; open-source removes license spend | Commercial licensing model, number of identities, hosting capacity |
| Hosting and operations of identity services | Your infrastructure team or a managed provider | Recurring | Number of directories and applications, high-availability design, backup scope |
| Integration engineering | Internal engineers or an implementation partner under a written scope | One-time, with later changes | Number of applications, protocols in use (OIDC, SAML, LDAP, RADIUS), legacy systems without modern sign-in |
| Role design and entitlement mapping | Identity architects, application owners and business role owners | One-time, then recurring on role changes | Number of roles, degree of role overlap, how many systems grant access locally |
| Access review effort by reviewers | Named reviewers in each business unit and system owners | Recurring | Review frequency, number of accounts and privileges, size of reviewer population, campaign tooling |
| Evidence upkeep | Compliance lead and system administrators | Recurring | Number of systems in scope, log retention, how often lockout and role-change evidence is pulled |
| External readiness review | Independent consultant or readiness provider, paid by quote | One-time before assessment, sometimes repeated | Scope size, how many access control gaps were found in earlier reviews, internal readiness |
| Assessor fieldwork | Authorized HITRUST External Assessor organization | Recurring at each assessment cycle | Sample size, number of systems tested, quality of prepared evidence; fieldwork window is at most 90 days per the Assessment Handbook |
| Privileged access handling | Security and platform engineers | One-time setup, recurring administration | Number of privileged accounts, approval workflow, session recording needs |
Who owns access control, who can help and what the auditor decides
Your organization owns every access control in the assessed scope. HITRUST scores what you do, not what a vendor installs, so the policies, approvals and periodic reviews must be run by staff who are accountable for them. Identity and access management is a management responsibility as much as a technical one, and an assessor will ask who signs off each decision and how that sign-off is recorded.
- Access policy and ownership: Name an owner for each system and each access tier, and document who may request, approve and revoke access.
- Joiner, mover and leaver process: Run provisioning and removal from a documented workflow, with dated tickets that show when role changes and terminations were actioned.
- Periodic access reviews: Schedule reviews of accounts and privileged rights, perform them yourselves, and retain the signed results.
- Lockout and privileged access rules: Decide the thresholds and approval paths for privileged roles, then monitor that they operate as written.
Before any assessment, confirm that your staff can produce these records for a sample of users without relying on a partner to reconstruct them.
An implementation partner such as DeployOpen can plan, configure and integrate the self-hosted platforms that enforce access control and generate its evidence. The partner works inside your cloud accounts, data centers or networks under a fixed-scope written agreement that sets the deliverables and timeline before work begins. The partner does not own the controls, approve access, issue reports or certify anything.
- Identity platform configuration: Set up identity providers, single sign-on and directory federation so applications authenticate against the source of truth you specify.
- Access certification tooling: Build review campaigns and reports that your reviewers use to keep, change or revoke access.
- Evidence preparation: Export logs, configuration baselines and review records in a form your team and assessor can read.
- Documentation and runbooks: Write the operating procedures your staff follow after handover.
Ask for a written statement of which tasks are the partner's, which remain with your staff, and that DeployOpen does not issue audit reports, attestations or certifications. Confirm that the partner has no role in the assessment itself.
Only an Authorized HITRUST External Assessor organization may perform a validated assessment submitted for certification, and HITRUST performs central quality assurance before reports are issued. The assessor selects samples, tests the access control requirement statements against evidence, scores each domain and documents findings. The fieldwork window for an e1, i1 or r2 validated assessment is at most 90 days.
- Independence: The assessor must be independent of the implementation work. Do not hire the same firm to build your access controls and then certify them.
- Sampling and testing: Expect the assessor to pull user samples, privileged account lists and review records for their own testing.
- Scoring: Access Control contributes to domain scores that the e1 and i1 require to average at least 83 and the r2 requires to average at least 62 per domain.
- HITRUST quality assurance: Reports are reviewed centrally by HITRUST before they are issued to you.
Confirm the assessor's status on HITRUST's Find an External Assessor page before signing an engagement.
Where access control assessments usually fail and how to close each gap
Access control is one of the domains where HITRUST corrective action plans cluster, and it has been the lowest scoring e1 domain in both 2023 and 2024. The gaps below share a root cause: access is granted during onboarding but not checked again as people, roles and accounts change.
No account lockout standard
Assessors look for a written, enforced rule for how many failed sign-in attempts lock an account, how long the lock lasts and who can release it. Many environments have a policy on paper but different settings in each application. Check every in-scope login path, including admin consoles and VPN, against one documented standard, and keep the configuration exports as evidence. Lockout was one of the three access control items in the 2024 top 10 corrective action plans.
Access not reviewed after role changes
When someone moves teams or leaves, their old entitlements often stay behind. Assessors test whether access is changed when a role or employment status changes, which requires a trigger from HR or the directory to the systems that grant access. Map each joiner, mover and leaver event to a ticket or automated action, and sample it the way an assessor would. Confirm the trigger fires for contractors as well as employees.
Missing annual review of accounts
A recurring review of every account and privilege, signed off by a named owner, is a distinct requirement from the change-driven reviews above. Many teams run reviews ad hoc, or only for administrators, so the assessor finds no record for the period. Schedule a full review at least once a year, record the reviewer, the decision for each item and the follow-up, and keep the completed campaign as evidence. Certification campaigns in midPoint can produce that record.
Orphaned contractor accounts
Contractor and vendor accounts often outlive their contracts because nobody owns their end date. Each one is an active credential with no matching employee record, which assessors flag quickly. Require an end date and a sponsoring employee for every non-employee identity at creation, and disable accounts automatically when the contract ends. Reconcile the directory against the active contractor list at each review.
Shared privileged accounts
Shared administrator logins, such as a generic root or domain admin account used by several engineers, make it impossible to attribute actions to a person. Assessors expect named privileged accounts, a documented way to request elevated rights and logs that tie each action to an individual. Replace shared credentials with named accounts and a privileged access process, and confirm that break-glass accounts are sealed, logged and reviewed.
Access evidence not retained
Assessors test a look-back period, and access reviews, approvals and lockout settings from the start of that period must still be available. Teams that keep reviews in email or spreadsheets often cannot reproduce them later. Store review records, approval tickets and identity provider configuration exports in a system with retention and access controls, and confirm with your assessor how far back evidence must reach for your scope.
How much access control work does HITRUST require from our team?
How much work does HITRUST access control take compared with other domains?
Access control is one of the heaviest domains in practice because it touches almost every system in scope. HITRUST groups its requirement statements into 19 assessment domains and scores each one, and Access Control is one of them. The HITRUST 2025 Trust Report names Access Control as the lowest scoring e1 domain in both 2023 and 2024, and three of the ten most common corrective action plans in 2024 fell here. The workload comes from the number of accounts, roles and systems you must prove are governed, not from any single control. Expect your team to spend most of its effort on evidence that is consistent across every system in the assessed scope, and confirm the exact requirement statements for your assessment type in MyCSF or with your assessor.
What drives the cost of access control work for a HITRUST assessment?
Four factors move the cost most: the number of systems and identity sources in scope, how many accounts and roles exist, how mature your provisioning process already is, and how many access reviews you must document. Costs fall into one-time work (designing the joinery between HR, the directory and applications, cleaning up existing accounts and writing procedures) and recurring work (quarterly or periodic reviews, leaver processing, and privileged access reviews). Your assessor fee is paid separately to an Authorized HITRUST External Assessor, and HITRUST charges for MyCSF use. Ask any provider for a quote that lists systems in scope, identity sources, the review cadence they assume and which items are one-time versus recurring.
Can our internal team handle HITRUST access control work without outside help?
Many teams can do this work in-house if they have an identity owner, a clear inventory of systems and someone who understands what evidence an assessor will sample. The workload is manageable when identity, HR and application owners already have documented procedures. It becomes harder when accounts are created by hand across many applications, when leavers are not reliably removed, or when no one runs periodic access reviews. Your internal team owns the controls and their evidence. An implementation partner can prepare systems, configuration and evidence, but only an independent assessor issues the report. Decide early which parts your staff will own and which you will hand to a partner under a written scope.
How long can the HITRUST fieldwork window for access control testing last?
The assessor's validated assessment fieldwork window is at most 90 days for e1, i1 and r2 assessments, according to the Assessment Handbook. That limit applies to the whole fieldwork, so access control evidence must be ready and consistent before the assessor arrives. Access reviews, leaver records and privileged account reports should already exist for the sample period, because you cannot create several months of review history during fieldwork. Plan your evidence calendar well before the assessment starts, and confirm the sample period and current fieldwork rules with your assessor, since the handbook governs both.
What do system owners and HR need to provide for access control evidence?
System owners must confirm who holds access to their applications, approve changes, and take part in periodic reviews of accounts and privileges. HR must supply timely notice of joiners, movers and leavers, because the HITRUST 2025 Trust Report links three top corrective action plans in 2024 to access reviews on role or employment changes and to account lockout. Your identity team must keep the authoritative account and role records, and security must sample those records against what the systems actually show. Agree on these responsibilities in writing and set a named owner for each application.
Does HITRUST AI security certification add access control requirements?
Yes. HITRUST's AI Security Assessment help page places AI security requirement statements in the Access Control domain, so adding the AI security certification to an e1, i1 or r2 adds requirements here. Practically, this means you must govern access to AI systems, models, data pipelines and agent identities the same way you govern other systems. Confirm the exact statements that apply to your scope in the current CSF version, because the requirement set changes between releases. Teams running AI tools should inventory those identities early, since they are often missing from existing access reviews.
When should we bring in an implementation partner for access control?
Bring in a partner when your access control gaps are broad, when several identity sources must be connected, or when your internal team lacks time to build and run the evidence cycle before the assessment. A partner can plan and implement open-source identity tooling inside your own infrastructure, document procedures and prepare evidence. DeployOpen prepares systems, controls and evidence and does not issue assessment reports or certifications. Most engagements are fixed-scope, with scope and deliverables agreed in writing before work starts. Ask for a written scope listing systems, identity sources, deliverables and what your staff must still do.
