45 CFR 164.308(a)(1): the HIPAA Security Management Process

45 CFR § 164.308(a)(1) is the standard behind most OCR risk-analysis settlements. Here are its four required specifications and what a defensible record looks like.

By CoreFolio

Published July 1, 2026Verified July 1, 20267-minute read

If you have searched the Code of Federal Regulations (CFR) for “164.308(a)(1),” you have landed on the single most consequential sentence in the HIPAA Security Rule for a small practice. This is the standard that the U.S. Department of Health and Human Services (HHS) Office for Civil Rights (OCR) cites more than any other, in settlement after settlement, against practices of every size.¹ It is not obscure and it is not new — it has been in force since the Security Rule took effect in 2005. What trips practices up is that it is really four separate obligations wearing one citation, and each one has to be documented on its own.

This article breaks down what § 164.308(a)(1) requires, what its four required specifications mean in plain English, and what a defensible record looks like. It is educational, not legal advice — the output is meant for your internal review, and to share with your privacy officer or counsel.

What § 164.308(a)(1) actually says

The standard itself is one sentence:

45 CFR § 164.308(a)(1)(i) — Standard: Security management process. Implement policies and procedures to prevent, detect, contain, and correct security violations.²

That is the whole standard. The work lives in the four implementation specifications that follow it, at § 164.308(a)(1)(ii)(A) through (D). What makes this standard unusual among the administrative safeguards is that all four of its specifications are “required,” not “addressable.” There is no reasonable-alternative path and no documented-rationale-for-skipping path. Each of the four must be implemented and each must be documented.

The distinction matters because most of § 164.308 mixes required and addressable specifications, and practices often assume they have latitude they do not have. Under § 164.308(a)(1), they have none.

The four required implementation specifications

Risk analysis — § 164.308(a)(1)(ii)(A)

The regulation requires the covered entity to “conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity.”² This is the specification OCR cites most often. “Accurate and thorough” means the analysis has to cover all electronic protected health information (ePHI) — not only the electronic health record (EHR), but email, cloud storage, portable devices, telehealth platforms, and any other system that creates, receives, maintains, or transmits ePHI. A narrow scope is the most common way this specification fails on paper.

Risk management — § 164.308(a)(1)(ii)(B)

The regulation requires the entity to “implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with § 164.306(a).”² This is the response to the analysis: a documented plan with specific actions, responsible parties, and timelines. A risk analysis without a matching risk management plan is itself a gap — OCR requires both, and a risk management plan is a mandated step in every corrective action plan OCR issues for a risk-analysis failure.¹ The reference to § 164.306(a) matters: it is the flexibility-of-approach standard that lets a small practice scale its measures to its size and risk, but it does not let the practice skip the plan.³

Sanction policy — § 164.308(a)(1)(ii)(C)

The regulation requires the entity to “apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures of the covered entity or business associate.”² In practice this is a written policy that states the consequences for a security-policy violation and is applied consistently. It is short, but it must exist in writing, and OCR does ask for it.

Information system activity review — § 164.308(a)(1)(ii)(D)

The regulation requires the entity to “implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.”² Most EHR and cloud systems generate these logs automatically. The requirement is not to generate them — it is to review them on a documented schedule and record that the review happened. A log nobody reads does not satisfy the specification.

Why this one standard drives most enforcement

OCR's 2016–2017 industry audit found that only about 14 percent of covered entities were substantially meeting their risk analysis obligations — one of the lowest compliance rates of any provision audited.⁴ That gap is exactly what OCR is now enforcing.

In late 2024, OCR launched its Risk Analysis Initiative, a deliberate enforcement focus that investigates the § 164.308(a)(1)(ii)(A) failure as a standalone violation rather than as one finding buried in a larger breach case. As of April 23, 2026, OCR reported 13 completed investigations under the Initiative, with settlements ranging from $5,000 to $375,000 and corrective action plans running one to three years.¹ The pattern is consistent: an incident brings OCR to the door, the investigation expands to foundational compliance, and the missing or inadequate § 164.308(a)(1) record becomes the cited violation that drives the settlement.

The takeaway is not that OCR expects perfection. It is that OCR expects documentation — a current, thorough risk analysis; a written risk management plan; a sanction policy; and a records-review schedule that someone actually follows.

The structure of a defensible security management process

You are producing four linked records, not one document. Use this as a skeleton — the structure is known; the content is specific to your practice.

Risk analysis (the assessment):

[FILL: Every system, device, and vendor that touches ePHI]
[FILL: Threats and vulnerabilities named specifically — ransomware, lost laptop, phishing, misconfigured cloud share]
[FILL: Likelihood and impact rating for each threat-vulnerability pair]
[FILL: The methodology you used, dated and signed]

Risk management plan (the response):

[FILL: Each significant risk from the analysis]
[FILL: The specific measure that reduces it]
[FILL: Who owns it and by when]

Sanction policy:

[FILL: The consequences for a security-policy violation]
[FILL: How the policy is applied consistently]

Information system activity review:

[FILL: Which logs are reviewed]
[FILL: How often, and who signs off]

For the risk analysis itself, OCR's 2010 guidance maps the requirement to a seven-step process based on National Institute of Standards and Technology (NIST) Special Publication 800-30: define scope, gather data, identify threats, identify vulnerabilities, assess current controls, determine likelihood and impact, and document.⁵⁶ OCR does not mandate NIST, but naming a recognized methodology is one of the things that separates a defensible analysis from a vague one — investigators ask “how did you arrive at this rating?”

One forward note: the proposed 2026 Security Rule (90 Fed. Reg. 898) would tie the risk analysis to an explicit annual cadence and remove the addressable/required distinction across the rule. It has not been finalized as of July 2026, and the current rule remains in effect — but the direction of travel is toward more prescriptive, not less.⁷

What to do this month

If your practice has not looked at § 164.308(a)(1) in more than twelve months, three preparatory steps are reasonable to take now, without spending money.

Inventory where ePHI lives. Write down every system, device, and vendor that creates, receives, maintains, or transmits ePHI — including the shadow systems (a personal phone, a shared drive, a legacy billing platform). Scope is where the risk analysis specification most often fails.
Locate your four records. Find your most recent risk analysis, risk management plan, sanction policy, and activity-review schedule. Note the date on each. If any does not exist, that absence is itself a finding worth recording.
Block the time. The analysis is a project, not a between-patients task. Reserve a couple of uninterrupted hours in the next month to produce the linked records rather than a single skimmed document.

None of this requires outside counsel or enterprise software. It requires structure, specificity, and a commitment to keeping the four records current.

Sources

Last verified: July 1, 2026. Sources current as of that date.

U.S. Department of Health and Human Services, Office for Civil Rights. Risk Analysis Initiative enforcement actions and resolution agreements, October 2024–April 2026. Resolution agreements at https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/agreements/ and OCR newsroom at https://www.hhs.gov/about/news/index.html ↩ ↩² ↩³
45 CFR § 164.308(a)(1) (Security management process standard and its four required implementation specifications). Current text at the Electronic Code of Federal Regulations: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308 ↩ ↩² ↩³ ↩⁴ ↩⁵
45 CFR § 164.306(a) (Security standards: general rules — flexibility of approach). Current text at the Electronic Code of Federal Regulations: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.306 ↩
U.S. Department of Health and Human Services, Office for Civil Rights. 2016–2017 HIPAA Audits Industry Report (December 2020). https://www.hhs.gov/sites/default/files/hipaa-audits-industry-report.pdf ↩
U.S. Department of Health and Human Services, Office for Civil Rights. Guidance on Risk Analysis Requirements under the HIPAA Security Rule (2010). https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html ↩
National Institute of Standards and Technology. Special Publication 800-30 Revision 1, Guide for Conducting Risk Assessments (September 2012). https://csrc.nist.gov/pubs/sp/800/30/r1/final ↩
HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information, 90 Fed. Reg. 898 (January 6, 2025). https://www.federalregister.gov/documents/2025/01/06/2024-30983/hipaa-security-rule-to-strengthen-the-cybersecurity-of-electronic-protected-health-information ↩

FAQ

Common questions

What is 45 CFR § 164.308(a)(1)?

It is the Security Management Process standard of the HIPAA Security Rule — the first administrative safeguard. It requires a covered entity or business associate to implement policies and procedures to prevent, detect, contain, and correct security violations. It contains four required implementation specifications: risk analysis, risk management, a sanction policy, and information system activity review.

Are the implementation specifications under § 164.308(a)(1) required or addressable?

All four are required. Unlike many administrative safeguards, § 164.308(a)(1) has no addressable specifications — risk analysis, risk management, sanction policy, and information system activity review must each be implemented and documented. There is no reasonable-alternative path.

What is the difference between risk analysis and risk management under § 164.308(a)(1)?

Risk analysis, under § 164.308(a)(1)(ii)(A), is the assessment: identifying the risks and vulnerabilities to your electronic protected health information. Risk management, under § 164.308(a)(1)(ii)(B), is the response: the documented plan to reduce those risks to a reasonable and appropriate level. Both are separate required specifications, and OCR expects to see both.

Why is § 164.308(a)(1) cited so often in OCR settlements?

Because the risk analysis specification within it is the single most commonly cited finding in OCR enforcement, and OCR's Risk Analysis Initiative now investigates that failure as a standalone violation. A practice can have strong technical controls and still be cited under § 164.308(a)(1) if it cannot produce a current, thorough risk analysis and a matching risk management plan.

Keep learning

How-to
How to do a HIPAA risk analysis yourself: a step-by-step guide for small practices
The Security Rule requires every covered entity to conduct an accurate, thorough risk analysis. Here is what that actually means, what it has to contain, and how to do it yourself — or prepare for a focused consultant review.
May 14, 20266-minute read
How-to
What goes in a HIPAA risk management plan
The risk analysis gets all the attention, but OCR requires the risk management plan too. Here is what it needs to contain, how it relates to the risk analysis, and what a defensible plan looks like.
May 11, 20265-minute read
Enforcement
What OCR actually wants in a risk analysis
HHS's Office for Civil Rights has now settled with dozens of practices for risk analysis failures. The pattern in their investigation letters and resolution agreements tells you exactly what they are looking for.
May 13, 20265-minute read