An OCR data request letter is usually two pages long, and the second page is the one that hurts. It asks for your most recent risk analysis, your risk management plan, the name of your designated security official, your sanction policy, your workforce training records, your termination checklist, and a complete list of business associates with executed agreements. Every one of those items sits inside the HIPAA administrative safeguards at 45 CFR 164.308. If you are a practice owner, privacy officer, or compliance lead, this article tells you which nine standards you owe, who inside your organization owns each one, and what the paper trail has to look like when someone asks.

The technical safeguards get the budget. The administrative safeguards get the citations.

What Are the HIPAA Administrative Safeguards?

The HIPAA administrative safeguards are the nine standards in the Security Rule at 45 CFR 164.308 that govern how your organization manages people, policies, and process around electronic protected health information. They are:

  1. Security Management Process — risk analysis, risk management, sanction policy, information system activity review
  2. Assigned Security Responsibility — one named security official
  3. Workforce Security — authorization, clearance, and termination procedures
  4. Information Access Management — how access is granted, modified, and scoped
  5. Security Awareness and Training — reminders, malware protection, log-in monitoring, password management
  6. Security Incident Procedures — response and reporting
  7. Contingency Plan — backup, disaster recovery, emergency mode operation, testing, criticality analysis
  8. Evaluation — periodic reassessment of whether your safeguards still work
  9. Business Associate Contracts and Other Arrangements — written agreements with every vendor that touches ePHI

They apply to every covered entity and every business associate, regardless of size. A three-provider dermatology practice owes the same nine standards as a hospital system — the implementation just looks different.

Required vs. Addressable Is Not Optional vs. Optional

Inside those nine standards sit implementation specifications marked either required or addressable. Required means you do it. Addressable means you assess whether the specification is reasonable and appropriate in your environment, and then either implement it, implement an equivalent alternative, or document why neither is reasonable.

"Addressable" is where practices get into trouble. Skipping an addressable specification without writing down the analysis is the same as skipping it entirely, from an enforcement standpoint. If you decide not to implement automatic log-in monitoring because your EHR vendor handles it, that sentence needs to live in a document with a date and a signature.

Note that OCR published a proposed rule in January 2025 that would substantially revise the Security Rule, including removing the addressable/required distinction and making most specifications mandatory. As of this writing it has not been finalized. Track it through the HHS Security Rule page rather than secondhand summaries, and do not restructure your program around a proposal.

Standard 1: The Security Management Process Is Where Enforcement Starts

Four implementation specifications, and the first two are the most-cited findings in Security Rule enforcement history.

Risk Analysis (Required)

An accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of all ePHI your practice creates, receives, maintains, or transmits. That last clause matters: it includes the ePHI on the billing manager's laptop, in the fax-to-email inbox, in the appointment-reminder platform, and on the backup drive in the storage closet.

A vendor security questionnaire is not a risk analysis. A penetration test is not a risk analysis. The analysis must inventory systems and data flows, identify threats and vulnerabilities, assess likelihood and impact, and produce a risk level for each finding. NIST SP 800-66 Revision 2 is the free, authoritative walkthrough of how to structure one. The HHS/ONC Security Risk Assessment Tool is free and built for small and mid-size practices.

Owner: Security official, with input from whoever administers your EHR and network. Cadence: Annually, and after any material change — new location, new EHR, new imaging modality, a merger, or a breach.

Risk Management (Required)

The remediation plan that follows the analysis. Each finding gets an owner, a target date, and a disposition. Findings you accept rather than fix need a written acceptance rationale signed by someone with authority to accept risk — usually the practice owner, not the office manager.

If your risk analysis from March still shows twelve open high-risk findings in December with no activity, you have created evidence against yourself. Investigators read the remediation column.

Sanction Policy (Required)

A written policy describing consequences for workforce members who violate your security policies, and evidence that you apply it. Tiered is fine: verbal counseling for a first-time unattended workstation, written warning for password sharing, termination for snooping in a coworker's chart. What matters is that when the incident happens, you document what tier you applied and why.

Information System Activity Review (Required)

Regular review of audit logs, access reports, and security incident tracking. Most practices have the logs and never look at them. Pick a cadence you will actually hold — monthly is defensible for a small practice — and produce a one-page memo each cycle: who reviewed, what systems, what anomalies, what action. Sign it. File it.

Standards 2 Through 5: The People Standards

Assigned Security Responsibility (§164.308(a)(2))

One named individual, in writing. Not "the IT company." Not "management." A person, with a job description that includes the responsibility and a date of appointment. This is the single easiest standard to satisfy and one of the most common gaps in small practices.

Workforce Security (§164.308(a)(3))

Authorization and supervision, workforce clearance, and termination procedures. The termination piece deserves a worked example.

A medical assistant gives notice on a Monday and her last shift is Friday at 5 p.m. By Friday at 5:30, your checklist should show: EHR account disabled, email disabled, clearinghouse and lab portal logins revoked, VPN certificate removed, badge and keys collected, mobile device wiped or MDM profile removed, e-prescribing credentials deactivated, and shared passwords she knew rotated. Each line initialed with a timestamp. That checklist, retained, is your evidence.

Terminations that happen on a Friday afternoon and get processed the following Wednesday show up in breach investigations more often than you would expect.

Information Access Management (§164.308(a)(4))

How access gets granted and modified. In practice this means role-based access templates: front desk sees scheduling and demographics, billing sees claims and coverage, clinical staff see charts for patients in their care. Write down the role matrix, then run a quarterly access review comparing active EHR accounts against your current roster.

The recurring finding here is the departed provider whose account is still active, and the per-diem nurse who has full administrative rights because someone cloned the wrong template two years ago.

Security Awareness and Training (§164.308(a)(5))

Training is a Security Rule standard and a separate Privacy Rule obligation at §164.530(b), which requires training for all workforce members on privacy policies relevant to their functions, within a reasonable time after hire and after material policy changes.

Your evidence is a roster with names, dates, module titles, and completion attestations — retained for six years. Annual training plus periodic security reminders (a phishing simulation, a short email about a new scam targeting medical offices) satisfies the addressable reminder specification and gives you dated artifacts.

Standards 6 Through 8: Incidents, Continuity, and Reassessment

Security Incident Procedures (§164.308(a)(6))

Written response and reporting procedures, and a log of every security incident — not just reportable breaches. A stolen unencrypted phone, a phishing click, a misdirected fax: log it, assess it, document the risk assessment that determined whether it was a breach under §164.402, and record the disposition.

Remember the deadlines that attach downstream. Breach notification to affected individuals is required without unreasonable delay and no later than 60 days from discovery (§164.404). Breaches affecting 500 or more individuals go to HHS within that same 60-day window; smaller breaches are reported annually within 60 days of year-end. Browse the OCR breach portal and you will see how many entries in any given month are small practices with a hacking or email incident.

Contingency Plan (§164.308(a)(7))

Three required specifications — data backup plan, disaster recovery plan, emergency mode operation plan — plus two addressable ones, testing and criticality analysis.

Emergency mode operation is the one clinics under-build. If your EHR is down at 8 a.m. Monday, what does the front desk do? Where are the downtime encounter forms? Who calls the answering service? Who authorizes emergency chart access and how is it logged afterward? Write that down, run a tabletop once a year, and keep the after-action notes.

Test your restores, not just your backups. A backup you have never restored is a hypothesis.

Evaluation (§164.308(a)(8))

A periodic technical and nontechnical evaluation of whether your safeguards still meet the rule's requirements. This is the standard that catches drift — the new telehealth platform nobody ran through the risk process, the scanner that started emailing PDFs to a personal address, the location you opened in June.

Standard 9: Business Associate Contracts (§164.308(b))

Every vendor that creates, receives, maintains, or transmits ePHI on your behalf needs a written business associate agreement with the terms required at §164.504(e), executed before they touch data. Your billing company, your transcription service, your IT managed service provider, your cloud backup vendor, your answering service, your shredding company, your patient-communication platform.

Two failure patterns dominate. First, no signed agreement at all — usually with a small local vendor onboarded by an office manager who did not know to ask. Second, an agreement signed in 2017 that never got updated and cannot be located when requested.

Build the vendor inventory first: name, service, data touched, agreement status, execution date, renewal date, and the internal owner of the relationship. Then close the gaps. If you need to paper a vendor quickly and correctly, you can generate a signature-ready business associate agreement through a six-step wizard and export it as PDF or DOCX — one-time purchase, no subscription, which matters when you are cleaning up eleven vendors in a week rather than buying a platform.

Keep every executed BAA for at least six years from the date it was last in effect.

The Six-Year Rule Nobody Budgets For

Section 164.316(b)(2)(i) requires you to retain your Security Rule documentation — policies, procedures, and any action, activity, or assessment the rule requires you to document — for six years from creation or from the date it was last in effect, whichever is later. The Privacy Rule imposes a parallel six-year requirement at §164.530(j).

That means superseded policy versions, old training rosters, prior years' risk analyses, and expired BAAs stay in the file. A practice that overwrites its policy document every year and keeps only the current version has destroyed its own evidence.

A 90-Day Sequence If You Are Starting Cold

Days 1–15. Name the security official in writing. Build the system and vendor inventory — every application, device, and third party that touches ePHI. This is unglamorous and takes longer than you think.

Days 16–45. Complete the risk analysis against that inventory. Produce a risk register with owners and target dates. Get the practice owner's signature on the risk acceptances.

Days 46–70. Write or refresh the policy set covering all nine administrative standards, plus physical and technical safeguards. Close BAA gaps. Build the termination checklist and the access review template. Practices that would rather not draft twenty policies from a blank page can automate the risk analysis report and the supporting document set and spend the saved time on remediation instead.

Days 71–90. Train the workforce and capture attestations. Run one tabletop of the emergency mode plan. Run the first information system activity review. File everything in a single indexed evidence folder — because the HIPAA administrative safeguards are judged on what you can produce, not what you believe you do.

Where the Documentation Usually Falls Apart

  • The risk analysis covers the EHR and nothing else — no fax server, no backup drive, no personal devices under a BYOD arrangement.
  • Policies exist as a purchased template with another organization's name still in the footer, and no evidence of adoption.
  • Training rosters are unsigned spreadsheets with no module names or dates.
  • Access reviews happen verbally and leave no artifact.
  • The BAA list is a memory, not a document.

Every one of those is fixable in a quarter with disciplined attention and no capital spend.

Start With the Vendor List

If you do one thing this week, pull every vendor that touches patient data and confirm you have a current, executed agreement for each. That single exercise usually surfaces gaps across three or four other administrative standards at the same time. When you find the missing ones, build the agreements you need in a few minutes each, file the executed copies with your risk analysis, and check one of the nine standards off with real evidence behind it.