Administrative safeguards: what 45 CFR 164.308 actually requires

If the technical safeguards are the locks, the administrative safeguards are the household: who gets a key, who checks the locks, what happens when someone moves out, and what the family does when the basement floods. It is the largest of the three safeguard families, more than half of the Security Rule by volume, and it is where enforcement actually happens, because its very first requirement is the risk analysis, the most cited failure in OCR’s history.

Nine standards (45 CFR 164.308, read against the general rules). Here is each one, what it demands, and what it looks like in a clinic whose workforce turns over at RBT speed.

Security management process

45 CFR 164.308(a)(1). Implement policies and procedures to prevent, detect, contain, and correct security violations.

This is the engine room, and all four of its implementation specifications are required. No addressable anywhere in it.

Risk analysis (Required, 164.308(a)(1)(ii)(A)). The accurate and thorough assessment of risks to your ePHI. It is the foundation of the entire rule, the subject of a dedicated OCR enforcement initiative, and it has its own page, because it deserves one.

Risk management (Required, 164.308(a)(1)(ii)(B)). Implement security measures sufficient to reduce the risks you found to a reasonable and appropriate level. The follow-through. An analysis whose findings sit untouched satisfies (A) and violates (B), and OCR has said plainly that this is where its enforcement attention is heading next.

Sanction policy (Required, 164.308(a)(1)(ii)(C)). Apply appropriate sanctions against workforce members who fail to comply with your security policies. Note the verb: apply, not possess. A sanction policy that has never once been applied, in a clinic where violations have certainly occurred, is a document contradicting itself. It does not need to be draconian. It needs to be real, graduated, and actually used, including when the violator is a supervisor.

Information system activity review (Required, 164.308(a)(1)(ii)(D)). Regularly review records of system activity: audit logs, access reports, incident tracking. This is the human half of audit controls (45 CFR 164.312(b)): the logs exist so that someone reads them. “Regularly” is yours to define and defend, and a calendar entry with a named owner is the difference between a practice and an intention.

Assigned security responsibility

45 CFR 164.308(a)(2). Identify the security official who is responsible for developing and implementing the policies and procedures.

No implementation specifications, and the wording matters: the official, singular. One named human being, not a committee, not “the practice manager generally,” not the IT vendor. In a small clinic this person also runs intake and payroll, and that is fine. What the rule will not accept is the answer OCR hears constantly: everyone is responsible, which means no one is.

Workforce security

45 CFR 164.308(a)(3). Ensure that workforce members have appropriate access to ePHI, and prevent those who should not have access from getting it.

Three addressable specifications: authorization and supervision procedures (164.308(a)(3)(ii)(A)), a workforce clearance procedure (164.308(a)(3)(ii)(B)), and termination procedures (164.308(a)(3)(ii)(C)).

Addressable, and now run the honest assessment the label requires. The ABA staffing model is high-turnover, part-time, and field-based. People join mid-month, work three cases, and leave for graduate school. Every departure is a set of credentials that either dies that day or becomes a standing hole. In this environment, termination procedures are not a hypothetical to assess; they are the single most frequently exercised security process you have. The assessment that concludes “not reasonable for us” does not exist. The real question is speed: access ends when the employment ends, same day, on a checklist, with the date recorded, not whenever someone remembers.

Information access management

45 CFR 164.308(a)(4). Implement policies and procedures for authorizing access to ePHI.

This is where you decide who may see what; the technical safeguards then enforce the decision (45 CFR 164.312(a)(1)). One required specification applies only to health care clearinghouses inside larger organizations (164.308(a)(4)(ii)(A)), which is not you. The two that are yours are addressable: access authorization (164.308(a)(4)(ii)(B)) and access establishment and modification (164.308(a)(4)(ii)(C)).

The honest version for a clinic is role-based and boring, and boring is the point. RBTs see their assigned clients. BCBAs see their caseload and supervisees. Billing sees billing. The office manager does not see session videos. Write the roles down, grant by role, and review the grants when roles change, because the quiet failure here is not the new hire with too little access. It is the five-year employee who has changed jobs twice and still carries every permission from every job.

Security awareness and training

45 CFR 164.308(a)(5). Implement a security awareness and training program for all members of the workforce, including management.

All. The RBT who started Tuesday, the practicum student, the owner. Four addressable specifications name the minimum topics worth covering: periodic security reminders (164.308(a)(5)(ii)(A)), protection from malicious software (164.308(a)(5)(ii)(B)), log-in monitoring (164.308(a)(5)(ii)(C)), and password management (164.308(a)(5)(ii)(D)).

Two honest observations. First, the rule requires a program, not a certificate: an annual video with a quiz, purchased once and forgotten, is to training what a downloaded template is to risk analysis. Second, in a clinic your program has to run at hiring speed. If onboarding happens twice a month, training happens twice a month, and the record of who was trained and when is part of your required documentation (45 CFR 164.316(b)). Phishing deserves the center of the curriculum, because stolen credentials are how most healthcare intrusions begin, and your people are the surface.

Security incident procedures

45 CFR 164.308(a)(6). Implement policies and procedures to address security incidents.

One specification, required: identify and respond to suspected or known incidents, mitigate their harmful effects to the extent practicable, and document the incidents and their outcomes (164.308(a)(6)(ii)).

Remember how broad “security incident” is defined: attempted or successful unauthorized access, use, disclosure, modification, destruction, or interference (45 CFR 164.304). The phishing email an RBT reported is an incident. The procedure answers three questions in advance: who does staff tell, who decides what it is, and where is it written down. The documentation matters twice over, because if the incident turns out to be a breach, the clock and the evidence trail both started at discovery.

Contingency plan

45 CFR 164.308(a)(7). Establish policies and procedures for responding to an emergency or other occurrence that damages systems containing ePHI.

Five specifications, and the split is telling. Required: a data backup plan (164.308(a)(7)(ii)(A)), a disaster recovery plan (164.308(a)(7)(ii)(B)), and an emergency mode operation plan (164.308(a)(7)(ii)(C)). Addressable: testing and revision procedures (164.308(a)(7)(ii)(D)) and an applications and data criticality analysis (164.308(a)(7)(ii)(E)).

The cloud has not made this standard obsolete; it has changed its shape. Your practice management vendor going down for two days is your contingency event, even though the servers are theirs. The plan answers: what data do we have exact, retrievable copies of (backup), how do we get systems back (recovery), and how does the clinic keep treating children safely in the meantime (emergency mode), on paper if necessary. And the addressable testing specification is where honesty bites: a backup that has never been restored is a hope, not a plan. The assessment that concludes testing is unreasonable for you will be a strange document to write.

Evaluation

45 CFR 164.308(a)(8). Perform a periodic technical and nontechnical evaluation that establishes the extent to which your policies and procedures meet the requirements of the rule, in response to environmental or operational changes affecting the security of ePHI.

No implementation specifications, and the most forgotten standard in the family. It is the rule’s answer to entropy: the program that was true when you wrote it stops being true as the clinic changes. New location, new EHR, telehealth program, the AI notetaker someone adopted. Each of those is the trigger this standard names. A reasonable cadence is annual plus after material changes, documented like everything else.

Business associate contracts

45 CFR 164.308(b). You may permit a business associate to create, receive, maintain, or transmit ePHI on your behalf only if you obtain satisfactory assurances that it will appropriately safeguard the information, and those assurances must be documented in a written contract (164.308(b)(3)) whose required contents live at 45 CFR 164.314(a).

For a clinic this is a list question: every vendor that touches ePHI, each with a signed BAA, reviewed when vendors change. The practice management system, the data collection app, the telehealth platform, the billing service, the cloud storage, the email provider if PHI moves through it, and the AI tools your clinicians are quietly trying. The full treatment of who needs one and how to get it is coming in its own article.

What may change

The January 2025 proposed rule (90 FR 800) would harden this family considerably: every addressable specification above would become required, workforce access changes would carry explicit deadlines, incident response plans would gain required testing, and compliance would require annual audits. It is a proposal, not law, with final action currently shown for mid 2027 and genuine uncertainty about its fate. The practical note is the same one as everywhere else: the addressable items above already survive an honest assessment in almost every clinic, so the proposal mostly mandates what honesty already concluded.

“It is a name, a date, and a record: who does this, when it was last done, and where that is written down.”

Where clinics actually fail

The pattern in this family is not ignorance. It is drift. A program was set up once, and then the clinic kept moving: staff turned over faster than access reviews, training lagged hiring, the incident procedure lived in the departed office manager’s head, and nobody has been the security official since she left. Every standard above has the same antidote, and it is not technology. It is a name, a date, and a record: who does this, when it was last done, and where that is written down.