Short answer: HIPAA administrative safeguards are the nine standards in 45 CFR 164.308 that govern how you manage security: risk analysis and management, a named security official, workforce and access controls, training, incident response, contingency planning, evaluation and business associate contracts. Each standard needs an owner, a cadence and written evidence kept for six years.
Related guides:
- HIPAA risk assessment
- How to create and manage HIPAA policies and procedures
- Top 5 HIPAA compliance training requirements
Key takeaways
- Nine standards, 21 implementation specifications. Eight standards sit in 164.308(a) and one, business associate contracts, in 164.308(b).
- Addressable is not optional. You must assess each addressable specification and either implement it or document why not and what you did instead.
- Risk analysis drives everything else. HHS calls it the first step in Security Rule compliance, and it feeds access, training, contingency and evaluation decisions.
- Run it as a calendar, not a project. Give each standard an owner, a cadence and a named evidence artifact.
- Keep the paper trail for six years. Policies, assessments and records of required activities must be retained under 164.316.
What are the HIPAA administrative safeguards?
The administrative safeguards are the management-level standards in the HIPAA Security Rule that say how a covered entity or business associate must govern the protection of electronic protected health information (ePHI).
They are set out in 45 CFR 164.308. Eight standards sit in paragraph (a), from the security management process at (a)(1) to evaluation at (a)(8), and business associate contracts sit in paragraph (b).
Technical safeguards such as access control and audit controls sit in 164.312, which our HIPAA Security Rule guide covers. For a small HealthTech team, most ongoing Security Rule work lives in the administrative safeguards.
Required vs addressable: what is the difference?
A required specification must be implemented as written, while an addressable one must be assessed and then either implemented or replaced by a documented, reasoned alternative.
The rule for addressable specifications is in 45 CFR 164.306(d)(3). You must assess whether the specification is reasonable and appropriate in your environment. If it is, implement it. If it is not, document why and implement an equivalent alternative measure if that is reasonable and appropriate.
In practice, treat addressable as "implement unless you can write down a good reason," and keep that written decision record. 164.306(e) also requires you to review and modify security measures as needed and update their documentation, so decisions are not one-and-done.
What does each standard mean, and who should own it?
Each standard below has a plain-English meaning, its implementation specifications marked (R) required or (A) addressable exactly as 164.308 marks them, and a suggested owner for a team of roughly 5 to 50 people.
| Standard | Implementation specifications | Plain-English meaning | Suggested owner |
|---|---|---|---|
| (a)(1) Security management process | Risk analysis (R); Risk management (R); Sanction policy (R); Information system activity review (R) | Find your risks to ePHI, reduce them, discipline people who break the rules and regularly look at logs | Security official |
| (a)(2) Assigned security responsibility | None listed (the standard itself applies) | Name one security official responsible for the policies and procedures | CEO appoints |
| (a)(3) Workforce security | Authorization and/or supervision (A); Workforce clearance procedure (A); Termination procedures (A) | Only the right people get ePHI access, and access ends when they leave | People ops with engineering |
| (a)(4) Information access management | Isolating health care clearinghouse functions (R); Access authorization (A); Access establishment and modification (A) | Grant, change and approve access on a least-privilege basis | Engineering lead |
| (a)(5) Security awareness and training | Security reminders (A); Protection from malicious software (A); Log-in monitoring (A); Password management (A) | Train everyone, including management, and keep reminding them | Security official |
| (a)(6) Security incident procedures | Response and reporting (R) | Identify, respond to, mitigate and document security incidents | Incident lead |
| (a)(7) Contingency plan | Data backup plan (R); Disaster recovery plan (R); Emergency mode operation plan (R); Testing and revision procedures (A); Applications and data criticality analysis (A) | Be able to restore ePHI and keep critical processes running in an emergency | Engineering lead |
| (a)(8) Evaluation | None listed (the standard itself applies) | Periodically check that your safeguards still meet the rule | Security official |
| (b) Business associate contracts | Written contract or other arrangement (R) | Get written assurances from vendors and subcontractors that handle ePHI | Operations or legal |
A few notes for HealthTech teams:
- Clearinghouse isolation only applies if part of your organization is a health care clearinghouse. Most SaaS vendors record it as not applicable, with the reason.
- Information system activity review names audit logs, access reports and security incident tracking reports as examples of what to review.
- Business associate contracts must meet 45 CFR 164.314(a), including subcontractor flow-down and reporting security incidents, including breaches of unsecured PHI. Our HIPAA incident response plan guide covers reporting.
What cadence should a small HealthTech team run?
Run a small number of recurring activities on a fixed calendar so every standard produces evidence throughout the year, not just before an audit.
The Security Rule mostly says "periodic" or "regular." HHS's guidance on risk analysis says the rule does not specify how often to perform risk analysis, that the process should be ongoing, and that entities may perform it annually or as needed. The cadences below are our suggested defaults, not regulatory deadlines.
| Activity | Standard | Suggested cadence | Responsible | Accountable |
|---|---|---|---|---|
| Review audit logs and access reports | (a)(1) | Monthly, plus alert-driven | Engineering lead | Security official |
| Offboarding access removal check | (a)(3) | Every departure, reconciled monthly | People ops | Security official |
| Access reviews for ePHI systems | (a)(4) | Quarterly | System owners | Security official |
| Security reminders | (a)(5) | Quarterly | Security official | Security official |
| Vendor and BAA register review | (b) | Quarterly, and before any new vendor touches ePHI | Operations | Security official |
| Risk analysis refresh and risk register update | (a)(1) | Annually and after major changes | Security official | CEO |
| Workforce training and attestation | (a)(5) | At onboarding and annually | Security official | CEO |
| Contingency plan test (backup restore) | (a)(7) | Annually at minimum | Engineering lead | Security official |
| Incident response tabletop | (a)(6) | Annually | Incident lead | Security official |
| Evaluation of all safeguards | (a)(8) | Annually and after environmental or operational changes | Security official | CEO |
| Sanction policy review | (a)(1) | Annually, applied as needed | People ops | CEO |
Spread the "Responsible" work so the cadence survives busy quarters. Because 164.308(a)(8) calls for evaluations in response to environmental or operational changes, a new cloud provider or product line should trigger an off-cycle check.
How do you roll out administrative safeguards in 90 days?
Spend the first 30 days on governance and risk, the next 30 on access, people and vendors, and the last 30 on resilience and evaluation, so that by day 90 every standard has an owner and at least one piece of evidence.
Days 1 to 30: govern and assess
- Appoint the security official in writing and publish the owner list for all nine standards.
- Inventory systems, data stores and vendors that create, receive, maintain or transmit ePHI.
- Complete a risk analysis and open a risk register with treatment owners.
- Draft or refresh the sanction policy and get leadership sign-off.
- Record a required or addressable decision for every implementation specification.
Days 31 to 60: control access, people and vendors
- Define roles and approval steps for granting and changing ePHI access.
- Run the first access review and remove unneeded access.
- Write onboarding clearance and termination checklists, then test one offboarding end to end.
- Launch workforce training with attestations, including leadership.
- Build a BAA register of customer and subprocessor agreements involving ePHI.
- Turn on log review for production systems that hold ePHI and record the first review.
Days 61 to 90: test and evaluate
- Rank applications and data by criticality and document backup, recovery and emergency mode plans.
- Restore a backup in a test environment and record the result.
- Run an incident response tabletop and log the lessons.
- Hold the first evaluation against all nine standards and file the report.
- Load the recurring cadence into calendars with owners.
What evidence should you keep, and for how long?
Keep written records of every policy, assessment and required activity for six years from creation or from the date last in effect, whichever is later.
That is the documentation rule in 45 CFR 164.316(b). Records may be electronic, must be available to the people who carry out the procedures, and must be reviewed periodically and updated when changes affect ePHI security. Suggested evidence by standard:
- Security management process: risk analysis report, risk register with treatment decisions, sanction records, log review records
- Assigned security responsibility: dated appointment of the security official
- Workforce security: onboarding clearance records, supervision rules, offboarding tickets with access removal timestamps
- Information access management: access request approvals, role definitions, access review sign-offs
- Security awareness and training: training content versions, completion and attestation records, reminder log
- Security incident procedures: incident procedure, incident log, investigation and outcome records
- Contingency plan: backup, disaster recovery and emergency mode plans, criticality analysis, test results
- Evaluation: evaluation report, findings and remediation tracking
- Business associate contracts: signed BAAs and subcontractor agreements, BAA register
- Addressable decisions: the assessment and rationale for each addressable specification
Our best practices for ongoing HIPAA compliance cover how to keep this current between audits.
What would the proposed Security Rule update change?
As of October 2026, HHS has proposed significant changes to the Security Rule, but they are not final and the current rule remains in effect.
The notice of proposed rulemaking was published in the Federal Register on January 6, 2025. HHS's NPRM page states that the current Security Rule remains in effect while the rulemaking proceeds. Among the proposals listed in HHS's fact sheet:
- Removing the distinction between required and addressable implementation specifications.
- Requiring written documentation of all Security Rule policies, procedures, plans and analyses.
- Requiring a technology asset inventory and network map.
- Requiring a compliance audit at least once every 12 months.
None of these are obligations today, but a team that already implements most addressable specifications would have less to change if a final rule resembles the proposal.
How SecureSlate helps
SecureSlate helps HealthTech teams run the administrative safeguards as an ongoing program. Built-in HIPAA support with multi-framework control mapping links 164.308 standards to related SOC 2, ISO 27001 and HITRUST controls, and custom controls capture your required or addressable decisions. Risk management holds your risk register and treatment owners, access reviews support quarterly reviews of ePHI systems, and vendor risk management tracks business associates and subcontractor agreements. Agentless read-only cloud integrations and the device agent help gather evidence, audit management keeps it organized for evaluations and audits, and the trust center and security questionnaire automation help you answer customer security reviews.
FAQ
How many HIPAA administrative safeguards are there?
There are nine standards in 45 CFR 164.308: eight in paragraph (a) and business associate contracts in paragraph (b). Together they contain 21 named implementation specifications.
Can we skip addressable implementation specifications?
No. Under 164.306(d)(3) you must assess each one. If it is not reasonable and appropriate, you must document why and implement an equivalent alternative if that is reasonable and appropriate.
What are some HIPAA administrative safeguards examples?
Examples include an annual risk analysis, a sanction policy, monthly log reviews, quarterly access reviews, annual training, a tested backup restore and signed business associate agreements.
Does a business associate have to implement administrative safeguards?
Yes. The Security Rule applies to business associates as well as covered entities, so a HealthTech vendor handling ePHI for customers needs all nine standards, including written agreements with its own subcontractors.
Disclaimer (legal note)
This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.
Need compliance without the complexity?
SecureSlate automates ISO 27001, SOC 2, GDPR, HIPAA, and more. Built for growing teams. See it in action.
Find compliance gaps in 30 seconds
