164.312(a)(1) Access control: requirements and evidence

What 164.312(a)(1) access control requires and why it is hard to prove

The standard asks you to show that only granted users and software can reach ePHI. Under 45 CFR 164.312(a)(1), systems that maintain electronic protected health information must have technical policies and procedures that allow only persons or software programs granted access rights to get to it. Those rights come from the information access management standard in 164.308(a)(4), so the technical control has to enforce a decision that the organization has already made on paper. The rule defines access in 45 CFR 164.304 broadly: the ability or means to read, write, modify or communicate data, or otherwise use any system resource. A database role that can export records counts as access just as much as a screen that displays them. The risk the standard targets is unauthorized viewing or alteration of ePHI, whether by a former employee, a compromised account or a tool that was never meant to touch patient records.

The difficulty is that access rarely stays where it was granted. Employees accumulate roles as they change teams, and nobody removes the old ones. Shared logins for clinical workstations, reporting tools or vendor support make it impossible to tie a read of a chart to one person. Service accounts, API keys and batch jobs often hold broad database rights and sit outside the identity provider, so no joiner, mover or leaver process touches them. Systems that were bought before central sign-in existed may keep local accounts indefinitely. To prove the control, you need an inventory of every system that holds ePHI, the access each account has in each one, and evidence that someone reviewed and changed that access. Confirm with your own environment which systems hold ePHI before you scope the proof, because the systems you forgot are the ones an assessor finds.

The standard has two required and two addressable implementation specifications, and the required ones are where proof usually fails. Unique user identification and an emergency access procedure must both be in place, so every person has an individual account and there is a documented way to reach ePHI during an outage without shared credentials. Automatic logoff and encryption and decryption are addressable, which means you must assess whether each is reasonable and appropriate and document the result, including any equivalent measure you choose instead. Decide early who owns that assessment, what evidence it produces and how it is kept current, because an addressable specification left undocumented is treated as a gap even when the technology exists.

Which systems, identities and third parties fall under access control for ePHI

Access control under 164.312(a)(1) applies wherever ePHI can be read, written, modified or communicated, so scope starts with the systems and identities that touch it. The entity's own risk analysis and asset inventory decide where the boundary sits, and the cards below cover the decisions that change the work most.

Systems that maintain ePHI

Start with every information system that stores or processes ePHI, including the EHR, billing and practice management applications, databases, file shares and scanned-document repositories. Backup consoles, replication targets and admin tooling count too, because a person who can restore or administer those systems can reach the data. Check the asset inventory against the data flow map so that no copy of ePHI sits outside the boundary by accident.

Human user accounts

Workforce members who need ePHI to do their jobs each need an account tied to a single person. Access follows the access rights the entity grants under the workforce access management standard in 164.308(a)(4), so the scope includes clinicians, billing staff, contractors on payroll and anyone with elevated privileges. Confirm which accounts exist in each system, not only those in the central directory, since local accounts often persist outside it.

Service accounts and API clients

Scheduled jobs, interfaces, reporting tools and integration engines often read ePHI under non-human identities. The rule covers software programs as well as people, so each service account and API client needs a named owner, a documented purpose and a credential that can be rotated. Look for shared passwords embedded in scripts and integrations that outlive the project that created them.

Workforce changes and access accumulation

Hires, transfers and departures change who needs ePHI, and the access record often lags behind. Map each joiner, mover and leaver process to the systems in scope, and check whether access is removed when a role ends. Periodic access reviews, such as the certification campaigns in midPoint, help catch access that built up over time and was never revoked.

Vendor and business associate access

Support vendors, managed IT providers, billing companies and other business associates may log in remotely to systems holding ePHI. Their accounts belong in scope even though a third party controls the credential. Confirm which vendor accounts exist, how they are approved and time-limited, and whether the business associate agreement describes the access they are permitted to have.

How an assessor tests access control and what they ask to see

This table compares what an assessor does for each part of 164.312(a)(1), what they ask you to produce, and where organizations usually fall short. Read each row as a question the assessor will put to your access control records, with the evidence that answers it. The main takeaway is that the rule is tested through documented decisions and sampled records, not through a single configuration setting.

Area	Test approach	Evidence requested	Common findings
Unique user identification (required)	Sample user accounts across ePHI systems and check that each maps to one named person or a documented software identity	Account list export, HR linkage for sampled users, written rule on shared and generic accounts	Shared logins for clinical or billing systems, service accounts with no owner, accounts that survive role changes
Emergency access procedure (required)	Walk through the documented procedure and ask for a recent use or a test of the break-glass path	Written emergency access procedure, list of emergency accounts, approval and usage logs, post-event review records	Procedure exists on paper but no one knows how to invoke it, emergency accounts never reviewed, no logging of use
Automatic logoff (addressable)	Read the risk analysis entry for session timeouts, then test a sample of systems to confirm the configured timeout matches the decision	Risk analysis decision, system configuration screenshots or exports, documented reason if logoff is not used	No documented decision, timeout set on one system but not others, justification that does not match the configuration
Encryption and decryption (addressable)	Confirm the risk analysis addresses encryption of stored ePHI, then verify encryption on sampled devices and databases	Risk analysis decision, encryption status reports, key management records, written equivalent measure where encryption is not used	Decision to not encrypt with no reasoning, laptops or backups unencrypted, equivalent measure described but not implemented
Access control policy and role definitions	Check that the policy ties access to information access management and that role definitions map to job functions	Access control policy, role catalog, role-to-system matrix, approval authority list	Policy is generic, roles are undefined or duplicated, no owner for role approval
Provisioning samples	Select recent new hires or transfers and trace each access grant back to an approved request and a defined role	Request tickets, approvals, role assignments and dates for sampled users	Access granted before approval, direct grants outside roles, missing approval evidence
Termination samples	Select recent leavers and compare their removal dates with their last working day across ePHI systems	Termination tickets, deactivation timestamps, lists of systems checked per leaver	Accounts active weeks after departure, contractor accounts missed, manual removal with no check
Access reviews	Ask for the most recent review of ePHI system access and check that reviewers acted on the findings	Review campaign records, reviewer sign-off, revoked or changed items, dates of completion	Reviews not performed, rubber-stamp approvals, no evidence that revocations were carried out

How to implement access control for ePHI systems in sequence

This sequence turns the access control standard into a working set of identities, roles, emergency procedures and removal steps that you can show an assessor for each system holding ePHI. The order matters because each step depends on the inventory and decisions made before it.

Inventory systems and workloads that touch ePHI
Start by listing every application, database, server, endpoint and integration that creates, stores, reads, modifies or transmits ePHI, along with how users and software reach each one. Your security official and system owners do this together, usually by tracing data flows from intake to disposal. The output is a system inventory that names the data each system holds, its owner and its access paths. You know the step is done when a reviewer can pick any ePHI record and find every system it passes through.
Identify technical access control capabilities per system
For each system in the inventory, record what access control features it actually provides, such as local accounts, directory integration, role-based permissions, session timeouts, audit logging and key management. Engineers and vendors should confirm these capabilities in writing, because a feature that exists in a product may be disabled or unavailable in your edition or deployment. Where a system cannot meet the standard, note the gap and the compensating option. The output is a capability matrix tied to the system inventory.
Assign unique identifiers to every user and process
Create one identity for each workforce member, contractor and service that needs ePHI, and retire shared logins for ePHI access. Where software acts on ePHI, give each service account its own identifier and a named owner. An identity provider such as authentik or a directory such as FreeIPA can serve as the source of these identifiers for applications that support federated sign-in or Kerberos. The output is an identity register that links each identifier to a person or service, and you know it is complete when no system in the inventory relies on a shared account.
Write the access control policy and role catalog
Document who may access which ePHI, at what level and under which approval, and translate that into a role catalog with defined permissions. The policy should connect to the information access management decisions required by the administrative safeguards, so the rights you grant trace back to a documented business need. Compliance and system owners approve the policy, and the security official signs off on the roles. The output is a written policy and a role catalog that maps each role to systems and data types.
Implement access procedures and role assignments
Configure each system so that the role catalog is enforced, with access granted through approved requests and removed through the same workflow. Use group membership, directory attributes or identity provider policies where the system supports them, and test that a user without a role cannot reach the ePHI. Keep the configuration in version control where possible so changes can be reviewed. The output is tested configuration evidence, such as exported role mappings and screenshots or test logs showing denied and permitted access.
Establish and test the emergency access procedure
Define how authorized staff obtain ePHI during an outage, such as a break-glass account or a documented override, and state who may invoke it, under what conditions and with what logging. Store emergency credentials under strict custody controls and set an alert whenever they are used. Test the procedure on a schedule your risk analysis supports, and record the results. The output is a written runbook and test records showing that the procedure works and that each use is reviewed afterward.
Set automatic logoff and encryption decisions
For each system, decide the inactivity timeout that the risk analysis supports, configure it, and document the reason if a system cannot enforce one. Record your encryption decision for ePHI at rest in each system, because this specification is addressable: if you do not encrypt, document why and what equivalent measure you use. Ask vendors to confirm which settings are available and whether they are enabled by default. The output is a decision record per system covering the timeout value, encryption status and rationale, approved by the security official.
Review access and terminate it when no longer required
Schedule periodic access reviews in which a designated reviewer confirms, changes or revokes each assignment, and run removal promptly when someone changes role or leaves. Tools such as midPoint support certification campaigns that give reviewers a set timeframe to decide, which helps counter access build-up over time. Link terminations to HR and contractor offboarding so that accounts, roles and emergency credentials are removed together. The output is review records, a termination log and evidence that removed identities no longer authenticate to any ePHI system.

Which evidence passes an access control audit and how to keep it current

An assessor testing 164.312(a)(1) will ask whether access is granted under a documented process, tied to individual identities, revoked on time and reviewed. The six artifacts below show that chain, and each one goes stale unless someone maintains it between audits.

Documented access control policy and procedures

The written technical policy states which systems hold ePHI, who may grant access under the information access management process in 164.308(a)(4), and how identifiers, roles and emergency access are handled. Assessors compare it against what the systems actually do, so every statement should name a system or role. Keep it current by reviewing it at a fixed interval and after any new system, identity provider or major role change. Confirm with the client which systems are in scope from their own risk analysis.

User and role inventories with unique IDs

An export from each identity source showing every account that can reach ePHI, its unique user identifier, its roles and its status. Shared or generic accounts found in this export are a direct finding under the unique user identification specification. Keep the inventory current by generating it from the directory rather than maintaining a spreadsheet by hand. Confirm with the client whether service accounts and software programs with ePHI access appear in the same inventory.

Provisioning and termination tickets

Each grant and removal of ePHI access should trace to a ticket that records the requester, the approver, the role granted and the date. Assessors sample leavers and movers and check that access ended when it was no longer needed. Tie the ticket workflow to HR events so terminations open automatically. Confirm with the client how contractors and business associate personnel are onboarded and offboarded, since those records often sit outside the employee HR system.

Emergency access runbook with test records

The emergency access procedure should name who may invoke break-glass access, where credentials are stored, how use is logged and how the account is disabled afterward. A runbook alone does not pass; assessors ask for dated records showing the procedure was exercised or tested and that each use was reviewed. Keep it current by scheduling tests and recording the outcome. Confirm with the client that break-glass credentials are excluded from routine logins and rotated after each use.

Automatic logoff and encryption configuration

Session timeout and encryption settings are addressable specifications, so the evidence is the configuration plus the documented reasoning. Keep exported settings from each system and a risk analysis entry that explains the chosen timeout and any decision not to encrypt stored ePHI, along with the alternative measure. Re-check the settings after upgrades, since defaults can change. Confirm with the client the timeout values and encryption status of every ePHI system from their own configuration, not from vendor defaults.

Periodic access review records with decisions

Access reviews show that someone checked whether existing grants were still needed. Records should list each item reviewed, the reviewer, the deadline and the decision to keep, change or revoke, plus evidence that revocations were carried out. Access certification tooling can generate these campaigns, but the reviewer decisions must be recorded as the organization's own. Keep reviews on a fixed schedule and after role changes. Confirm with the client who is designated as reviewer for each system holding ePHI.

What meeting access control costs in money and effort

This table breaks down the cost of meeting 164.312(a)(1) in money and staff effort, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to scope a quote and to see where open-source platforms cut license spend while labor remains. No dollar figures or durations are given because none are supported by researched facts, so request them in writing from each vendor or partner.

Cost component	One-time or recurring, who is paid	What drives it up or down
Identity tooling or licenses	Recurring for commercial products, paid to the vendor. Self-hosted open-source identity providers such as authentik or FreeIPA carry no license fee, but hosting still costs money.	Number of users, number of applications, and whether premium features are needed. Open-source choice removes license spend but not labor.
Engineering time to integrate systems	One-time, paid to internal staff or an implementation partner under a written scope.	Number of applications needing federation, protocol support (OIDC, SAML, LDAP, RADIUS), and how many systems hold ePHI.
Configuration and hardening	One-time, paid to internal staff or a partner, with some recurring tuning.	Legacy systems that cannot delegate sign-in, the number of distinct role and access policies, and the baseline hardening standard applied.
Emergency access testing	Recurring, paid to internal staff for each test cycle, with optional external review.	Number of break-glass accounts, how many systems they reach, and how often the procedure is exercised to show it works.
Access review effort	Recurring, paid mainly to system owners and reviewers who certify access.	Staff turnover, number of role assignments, and whether reviews are tool-driven (for example, midPoint certification campaigns) or manual spreadsheets.
Evidence upkeep	Recurring, paid to internal staff, often the security official or compliance lead.	Whether logs, provisioning records and review decisions are exported automatically, and how many systems must be documented.
External testing or review	Recurring or periodic, paid to an independent assessor or security testing firm if used.	Scope of the test, number of systems in scope, and whether the test is a one-time review or ongoing validation. OCR does not require certification.
Auditor or assessor sampling	Periodic, paid to the assessor or auditor engaged by the organization.	Number of users and systems sampled, quality of documented evidence, and how many exceptions surface in sampling.

Which self-hosted open-source tools support access control evidence

Access control under 164.312(a)(1) is proven with records of who was granted access, how sign-in is verified, and whether rights are reviewed and removed. The tools below each produce one part of that record, and none of them makes a system compliant on its own. The organization owns the access decisions, and an independent assessor decides whether the evidence is sufficient.

authentik identity provider

authentik is an identity provider that applications use for sign-in through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, so each ePHI application delegates authentication to one place. That central point produces the list of who can sign in to which system and when access was granted or changed. Check that every ePHI application is actually routed through it, and that local accounts that bypass it are documented, restricted and reviewed. Confirm the license terms (MIT) with your counsel before building it into a product you distribute.

FreeIPA single sign-on

FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos key distribution center, so server and workstation logins trace back to a central directory. This supports unique user identification and a clear record of which hosts a person could reach. Confirm that service accounts and host access rules are documented, since they often sit outside normal user review. FreeIPA is licensed under GPL-3.0-or-later, so review the obligations that apply if you modify or redistribute it.

midPoint access certification

midPoint runs access certification campaigns in which designated reviewers decide within a set timeframe whether to keep, change or revoke items such as role assignments. The completed campaign records are the periodic review evidence that a risk analysis and the access management specification expect. Set the review timeframe, reviewer list and escalation path in writing before the first campaign, and retain each decision. midPoint is licensed under EUPL-1.2+, so confirm its obligations with counsel before deployment.

Emergency access and logging gaps

No tool listed above supplies the emergency access procedure or the activity logs that show access in use. The organization must still define break-glass accounts, approval rules, how each use is recorded and who reviews it afterward. Automatic logoff timeouts also need a documented value tied to the risk analysis. Ask any implementation partner to write these procedures and test them with sample events, and confirm that your audit logs capture every sign-in and privilege change for ePHI systems.

Who owns access control, who implements it and what the auditor checks

The organization owns the access control policy and every decision that gives a person or software program the right to reach ePHI. Under 45 CFR 164.308(a)(4), information access management is an administrative standard that feeds directly into the technical control in 164.312(a)(1), so the people who approve access must be named in the organization's own records. Security and compliance staff, together with the system owners and the HIPAA security official, decide which roles exist, who holds them, and when access is removed.

Role definitions: Decide which job functions need which ePHI, and document the minimum access each role requires.
Access approvals: Authorize each grant, including emergency and temporary access, and record who approved it and why.
Review decisions: Conduct periodic access reviews and decide whether each item is kept, changed or revoked.
Termination timing: Set the rule for removing access when employment, contracts or job duties end.
Policy and documentation: Write the procedures that the auditor will ask to see and keep them current.

Before engaging any partner, confirm that someone inside the organization can sign off on access decisions without relying on the vendor.

Where access control programs fall short for ePHI and how to close each gap

Most access control failures under 164.312(a)(1) are not missing tools. They are shared identities, standing privileges, untested emergency paths and access that drifts after people change roles. Each card names one gap, the action that closes it and the record an assessor would ask to see.

Shared or generic clinical accounts

Workstations and ePHI applications often run under a single login used by a ward, a front desk or an admin team. Because activity cannot be tied to one person, the unique user identification specification under 164.312(a)(2)(i) is not met. Close it by issuing one identity per person in the identity provider, retiring generic accounts and requiring sign-in through that identity. Evidence: a list of active accounts matched to named staff, and a report showing that no ePHI application accepts a shared login.

Service accounts with standing broad rights

Integration jobs, interfaces and backup agents often hold database or file rights far wider than their task needs, and their passwords rarely rotate. Access to ePHI then depends on credentials no one reviews. Close it by giving each service its own identity, limiting rights to the tables or paths it reads, and storing secrets in a managed vault. Evidence: an inventory of service identities with owner, purpose and granted rights, plus rotation records.

Emergency access never tested

The emergency access procedure is required, but many organizations write one and never exercise it. When a clinician cannot reach a record during an outage, the workaround is often an unmanaged admin login. Close it by defining a break-glass account, sealing its credential, specifying who may invoke it and logging each use. Evidence: the written procedure, a dated test showing ePHI was retrieved under it, and a review of the logged use.

Undocumented automatic logoff decisions

Automatic logoff is addressable, so the rule leaves the timeout to the entity's risk analysis. Where systems use default timeouts, or none, the organization has made a decision without recording it. Close it by setting timeouts per system class, such as shared workstations and remote sessions, and recording the reasoning in the risk analysis. Evidence: the configuration settings for each system and the signed decision record that links them to the risk analysis.

Access accumulation after role changes

When staff move between departments, old rights often remain, so each person gathers permissions over time. Access then exceeds what the current role requires. Close it by removing prior role assignments when a transfer is processed and running periodic certification campaigns in which designated reviewers keep, change or revoke each item. The midPoint documentation describes this model. Evidence: completed review campaigns, the revocations they produced and the timestamps of transfer deprovisioning.

Applications outside the identity provider

Some clinical and reporting applications keep their own user stores, so disabling a person in the directory does not remove their ePHI access. Each local store becomes a separate place where access must be granted and removed. Close it by inventorying every application that holds ePHI, connecting each one to a central identity provider through a supported protocol, and disabling local accounts. Evidence: the application inventory showing the sign-in method for each, and a test where a disabled user is denied access everywhere.

How long access control takes and whether the team can do it alone

How much effort does it take to get access control in place for ePHI?

The effort depends on how many systems hold or touch ePHI, how many user populations exist, and how much access is currently managed by hand. Most of the work is not technical installation. It is inventorying systems, mapping who needs what under the access management rules in 164.308(a)(4), writing the access control policy, and then configuring each application to use unique identifiers, role-based grants and session controls. NIST SP 800-66 Rev. 2 breaks the standard into key activities, including analyzing workloads, assigning unique identifiers, establishing an emergency access procedure and terminating access when it is no longer required. Each of those activities consumes staff time that scales with the number of applications. No duration is given here because none has been supplied for this work. Ask any provider to estimate effort per application and per user population in writing.

How long does an access control project take to finish?

Timing is driven by five factors: the number of ePHI systems in scope, whether identity sources are already centralized, how many applications can delegate sign-in to a common identity provider, the state of existing role definitions, and how quickly the organization can make decisions about who owns each access grant. An environment with one directory and a handful of applications moves far faster than one with local accounts on dozens of clinical and billing systems. Vendor and application change windows also set the pace, because some systems need maintenance periods to change authentication settings. No timeline is stated on this page. Ask for a schedule that lists each system, its dependencies and the client decisions needed before work begins.

What does the access control work need from our own staff?

The work needs decisions and access to people who own the business process, not just administrators. Your team must name a security official or accountable owner, confirm which roles should see which ePHI, approve the emergency access procedure, and agree how access reviews will be run and who signs them off. Application owners must supply configuration details, test accounts and maintenance windows. Human resources or the workforce owner must provide joiner, mover and leaver events so access can be removed when it is no longer required. If these inputs are slow, the project slows, regardless of the technical plan. Ask the provider to list each client role by name in the scope document before the project starts.

Can an in-house team implement HIPAA access control without outside help?

Yes, a capable internal team can implement access control without an outside partner, provided it has time, engineering skills across identity, infrastructure and application administration, and someone accountable for HIPAA risk decisions. The Security Rule does not require a specific vendor or outside firm. The practical question is capacity. Teams that already run a directory service, manage application integrations and perform routine access reviews typically have the foundation. Teams that have never done a structured role analysis, or that must integrate many legacy systems at once, often benefit from outside help with design and configuration. Assess the gap against the NIST SP 800-66 activities, then decide which parts to keep internal. Document the decision, because the rule expects the entity to reason through its own choices.

Will a partner make our access control pass a HIPAA audit?

No. A partner can prepare systems, configurations and evidence, but only an independent assessor or auditor issues findings, and HHS does not certify organizations for Security Rule compliance. HHS has stated that no standard requires certification and that it does not endorse private certifications. OCR may review compliance through complaint investigations, compliance reviews and audits, and it can find violations regardless of any third-party assessment. Your organization remains responsible for its controls. A sound engagement produces working access controls, documented procedures, role definitions and review records that your own compliance function and any independent reviewer can examine. Do not accept any statement that a provider guarantees a result.

How do we scope a fixed-scope access control engagement?

A fixed-scope engagement lists the systems, user populations, identity sources, deliverables and client responsibilities in writing before work starts. Start with an inventory of every system that can read, write, modify or communicate ePHI, using the regulatory definition of access in 45 CFR 164.304. Then define which systems are in scope for integration with a central identity provider, which will stay local with documented exceptions, and which will be retired. State whether the work includes role analysis, emergency access design, automatic logoff settings, encryption decisions and a review campaign design. Name the acceptance criteria for each deliverable. DeployOpen plans and implements most work on this basis, and pricing follows from the written scope rather than a published list. Ask for the scope, assumptions and exclusions in one document.

Are open-source identity tools acceptable for HIPAA access control?

The Security Rule does not name approved products, so open-source identity tools can be used if they meet the standard's requirements and the entity can show they are reasonable and appropriate. authentik can act as an identity provider for applications through OAuth2 and OpenID Connect, SAML, LDAP, RADIUS and proxy providers, which lets applications delegate sign-in to a single point. FreeIPA provides single sign-on for Linux and UNIX environments through an MIT Kerberos KDC. midPoint supports access certification campaigns in which designated reviewers decide whether to keep, change or revoke access items, which supports the periodic review expected in access management. Confirm each product's supported protocols and features against its current documentation before you rely on it, and record the evidence of configuration and review in your risk analysis.

What should we ask a provider about access control costs before signing?

Ask for a quote that separates one-time work from recurring work, because the two cost components behave differently. One-time costs include discovery, role design, integration, configuration, testing and documentation. Recurring costs include access reviews, joiner and leaver operations, patching identity components, handling emergency access events and responding to changes in applications. Ask who pays for each licence or subscription, whether the open-source components will be deployed in your cloud account or data center, and what the provider will hand over at the end. Ask for the assumptions behind the estimate, such as the number of applications and identity sources. Compare quotes on the same scope rather than on headline totals.

How DeployOpen scopes, implements and prepares access control evidence

DeployOpen plans, implements and documents the access control systems that govern ePHI inside your own infrastructure, including cloud accounts, data centers or air-gapped networks. The organization keeps ownership of its access decisions and HIPAA compliance, while DeployOpen prepares the systems and evidence an independent assessor can review.

How we scope

We map every system that holds or touches ePHI and record which ones must enforce access control under 164.312(a)(1).
The written scope names the identity provider, directory, applications and workloads covered, agreed before any work starts.
Engagements are fixed-scope, and the scope document states which access control specifications are in and out of the work.

How we build

We deploy identity providers such as authentik or FreeIPA so applications delegate sign-in rather than keeping local accounts.
We configure unique user identifiers, a documented emergency access procedure and automatic logoff settings that match the risk analysis your organization approves.
We test each configured control, including attempts to use shared or default accounts, and record the results for review.

How we hand over

We deliver configuration records, access policy drafts, account inventories and test results mapped to each specification.
We document who owns each access decision, so the organization can show how access rights were granted under 164.308(a)(4).
We walk your security official and assessors through where each piece of evidence lives and how to retrieve it.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover periodic access reviews, such as access certification campaigns run with midPoint, and updates to the evidence pack.
Confirm with DeployOpen in the written scope which review cadence, response terms and upgrade coverage apply to your environment.