March 16, 2026 · Ken Armstrong
45 CFR 164.312(a)(1) sets the expectation for access control. The text is brief; the evidence it implies is not, and the difference between the two is where most remediation time goes.
Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in § 164.308(a)(4).
That is the operative language of 45 CFR 164.312(a)(1). Read it closely: it describes an outcome to achieve, not a product to buy, which is why two practices of the same size can satisfy it in different ways and both be right.
This is a standard, and standards are required in full. 45 CFR 164.306(d)(1) applies to every covered entity and business associate regardless of size.
This is a TECHNICAL standard. The policies and procedures it asks for govern what a system permits, not what a person is told to do, so the evidence is configuration and entitlement records rather than a signed acknowledgment. Workforce joining and leaving is a different requirement (45 CFR 164.308(a)(3)), and offering an offboarding checklist here is the commonest way this one is answered wrongly.
In an assessment, 45 CFR 164.312(a)(1) is not one question. It resolves into several, and each one is really asking for a different artifact:
Ownership usually sits with the security official, though the evidence is often produced by someone else, which is where the trail breaks. A control that works but has no owner tends to stop working the month the person who quietly maintained it changes roles.
Every covered entity and every business associate, at any size. 45 CFR 164.306(b) allows flexibility of approach, so a two-provider practice and a hospital system may implement this differently and both comply. What flexibility does not allow is skipping the decision: the smaller the organization, the more the written reasoning carries the weight, because there is no scale of operation to make the control self-evident.
The sequence below is the order that produces evidence as a by-product rather than as a separate documentation exercise:
The same evidence answers more than one framework. The questions behind 45 CFR 164.312(a)(1) also map to NIST CSF PR.AA-03, PR.AA-05, PR.PS-01; ISO 27001 A.5.18, A.8.2, A.8.22; SOC 2 CC6.1, CC6.2, CC6.3; NIST 800-53 AC-17, AC-2, AC-3; CIS v8 12.2, 12.7, 3.12; HITRUST 01.c, 01.j, 01.m. That matters for scoping: if you are working toward SOC 2 or an ISO certification alongside HIPAA, this control is one piece of work and several answers, provided the artifact is written once and referenced rather than rewritten per framework.
For this requirement the artifact types that satisfy it are configuration, inventory, log, and procedure. The distinction matters more than it looks: a policy states what you intend to do, a procedure states how, and a record proves it happened on a date. Auditors ask for all three, and a practice that has written the first two often has nothing for the third.
Date every artifact and keep the superseded versions. 45 CFR 164.316(b)(2)(i) requires documentation be retained for six years from the date of its creation or the date when it last was in effect, whichever is later, so a policy you replaced two years ago is still part of the record.
This requirement carries critical weight in an assessment, which means a gap here tends to surface as a high finding rather than an observation. The usual cause is drift: the control was implemented once, the environment changed, and nothing re-checked it. A dated review on a fixed cadence is cheaper than the remediation.
Work backward from the evidence. Decide what artifact would prove access control to someone who does not already trust you, then build the control that produces it. Programs built in that order tend to stay current, because the artifact goes stale visibly.