In scope
Providers with ePHI
Health care providers that transmit health information in electronic form in connection with a covered transaction, and that hold ePHI in an EHR, a practice-management system, imaging, messaging, or backups.
DSE Cybersecurity · Regulated readiness lane
Your obligation. Our working hands.
45 CFR 164.308(a)(1)(ii)(A) requires a covered entity or business associate to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the electronic protected health information it holds. It is a Required implementation specification, not an addressable one. The obligation stays yours. We do the assessment work, build the evidence, and hand your security official a documented risk analysis with the method, the sources, and the dates recorded, so the reasoning behind every conclusion is traceable rather than asserted. Whether it satisfies your obligation is a determination for your security official, your counsel, and ultimately the Department.
For covered entities and business associates that create, receive, maintain, or transmit ePHI. Readiness and advisory work. Not legal advice, not an audit, not a certification.
Entity scope
Who this is for, and who it is not for.
45 CFR 164.308(a) opens with "a covered entity or business associate must," and subpart C of part 164 is the Security Rule that governs electronic protected health information. The obligation attaches to that status and to the presence of ePHI. It does not attach to being in healthcare generally.
In scope
Health plans and clearinghouses
Health plans and health care clearinghouses, including the isolation requirements 45 CFR 164.308(a)(4)(ii)(A) places on a clearinghouse that sits inside a larger organization.
In scope
Business associates
Vendors that create, receive, maintain, or transmit ePHI on behalf of a covered entity. The Security Rule text at 45 CFR 164.308 names business associates directly; the risk analysis obligation is yours, not borrowed from your customer.
In scope
Subcontractors
Downstream subcontractors that handle ePHI on behalf of a business associate, who are themselves business associates and carry the same Security Rule duties.
In scope
Health tech and SaaS
Software, analytics, billing, transcription, and hosting companies that touch ePHI under a business associate agreement, including teams adding AI features on top of records they already hold.
In scope
Firms with a stale analysis
Organizations whose last risk analysis is a spreadsheet of a questionnaire, predates a material system change, or cannot be traced back to the systems that actually hold ePHI today.
This lane is not for you if: your organization neither creates, receives, maintains, nor transmits electronic protected health information, in which case 45 CFR 164 subpart C does not reach you; you hold only de-identified data with no ePHI in scope; you are an employer looking at your own employment records, which are treated differently from PHI and are a question for your counsel; you want a HIPAA certification or a compliance attestation, because HIPAA has no certification regime and no consultancy can issue one; or you want us to serve as your security official under 45 CFR 164.308(a)(2), which is your appointment to make. Business associate agreement terms, including whether one is required and what it says, are a separate legal matter for counsel on both sides. We do not draft, negotiate, or opine on BAA terms. We do not claim the Security Rule applies universally. If the facts you describe in the diagnostic call suggest the Security Rule may not reach your business, we will say that we are not the right engagement for you and point you to your counsel — that is a qualification decision about our own scope, not a legal opinion about yours.
Whether your organization is a covered entity or a business associate is a legal determination. Your counsel and privacy officer make it. We scope the work to the status they confirm.
Current requirements
What the Security Rule requires right now.
Everything in this section is current, in-force regulation text at 45 CFR part 164 subpart C. We work the rule as it stands today.
§164.308(a)(1)(ii)(A)
Risk analysis (Required)
"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 or business associate." Required, not addressable. This is the obligation this lane supports.
§164.308(a)(1)(ii)(B)
Risk management (Required)
Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to comply with 45 CFR 164.306(a). A risk analysis with no risk-management output is half a control, which is why our deliverable set ends in a plan and not a report.
§164.308(a)(1)(ii)(C)-(D)
Sanctions and activity review
A sanction policy for workforce members who fail to comply, and procedures to regularly review records of information system activity such as audit logs, access reports, and security incident tracking reports. Both are Required specifications inside the same security management process standard.
§164.308(a)(2)
Assigned security responsibility
Identify the security official responsible for developing and implementing the subpart's policies and procedures. A named, current, internal owner. We build to that person; we do not become them.
§164.306(d)
Required versus addressable
The Security Rule distinguishes Required specifications from Addressable ones, and an addressable specification still demands a documented decision and, where the specification is not implemented, a documented rationale and an equivalent alternative where reasonable and appropriate. Addressable is not optional.
§164.308(a)(3)-(4)
Workforce and access management
Workforce security and information access management, including authorization and supervision, workforce clearance, and termination procedures. These are the specifications a risk analysis most often finds undocumented rather than absent.
The scope of the analysis is the scope of your ePHI. Not the scope of your EHR. We work from an ePHI inventory that includes the systems nobody lists: shared drives, mail, messaging, imaging, backups and their retention, endpoints, remote-access paths, vendor-hosted environments, and any AI or analytics feature that reads records you already hold.
Current versus proposed
There is a proposal. It is not the rule.
We separate what binds you today from what has been proposed, and we plan the engagement around the former. Confusing the two is how organizations spend money on the wrong control at the wrong time.
The table scrolls horizontally on smaller screens. Keyboard users can focus the labeled table region and use horizontal navigation.
| Item | Citation | Status | How we treat it |
|---|---|---|---|
| Security Rule, subpart C of 45 CFR part 164, including the Required risk analysis specification | 45 CFR 164.308(a)(1)(ii)(A) | Current, in force | This is the obligation the engagement is built on. Every finding maps to a citation in the current rule text. |
| HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information | 90 FR 898, FR document 2024-30983 | Proposed rule, published January 6, 2025; comment period closed March 7, 2025. As of this page's last review date it has not been finalized, has no compliance date, and the Department's regulatory agenda lists it under long-term actions with a projected final action later than this page's review cycle. Nothing at the proposal stage binds you. | Flagged as a watch item in the roadmap only. We do not describe it as a requirement, we do not price work against it, and we do not tell you to build to it. |
If that proposal is finalized, the compliance obligations and dates will come from the final rule text, not from commentary about the proposal. We re-verify this page's status against the Federal Register at each review.
Deliverables
A risk analysis with the work shown.
01
ePHI inventory and data-flow map
Where ePHI is created, received, maintained, and transmitted, including the systems, vendors, backups, endpoints, and access paths that hold it. Scope statements, exclusions, and the reason for each exclusion are recorded.
02
Threat and vulnerability register
Reasonably anticipated threats and vulnerabilities per asset and per data flow, with the evidence source, the date observed, and the confidence level recorded against each.
03
Risk determination and rating
Likelihood, impact, and resulting risk level for each identified risk, with the rating method stated in the document so the reasoning is reproducible rather than asserted.
04
Safeguard determination record
Administrative, physical, and technical safeguard status against subpart C, with each Addressable specification carrying an implemented, alternative-implemented, or not-reasonable-and-appropriate decision plus the documented rationale 45 CFR 164.306(d) expects.
05
Risk management plan
The 45 CFR 164.308(a)(1)(ii)(B) output: prioritized measures, accountable owners, target dates, and the residual-risk position leadership is accepting, written for your security official to adopt and sign.
06
Evidence pack and refresh cadence
The supporting artifacts organized so the method, the evidence, and the dates behind each conclusion can be reconstructed later, plus a written trigger list for when the analysis must be revisited: material system change, new vendor with ePHI, merger, incident, or elapsed review period.
Typical timebox: 3 to 5 weeks after kickoff and timely evidence access. Multi-site providers, multi-entity groups, and complex vendor estates are scoped separately. Fees are scoped after the diagnostic and confirmed in writing before work begins. This lane rides on the same evidence method as the cybersecurity risk assessment; organizations that also need response mechanics tested pair it with incident response and ransomware readiness. Where remediation implementation follows the readiness cycle, it is scoped separately in writing and may be delivered by a disclosed qualified specialist from DSE's expert network. DSE remains accountable for scope, quality, and integration.
Primary sources
Every claim traces to the rule text.
We cite the regulation and the rulemaking record. The current-rule citations below are the primary eCFR text of the Security Rule itself.
- eCFR: 45 CFR part 164 subpart C, Security Standards for the Protection of Electronic Protected Health Information ↗
- eCFR: 45 CFR 164.308, administrative safeguards, including the Required risk analysis specification ↗
- eCFR: 45 CFR 160.103, definitions including covered entity and business associate ↗
- Federal Register: 90 FR 898, HIPAA Security Rule notice of proposed rulemaking — a proposal, not a requirement ↗
- NIST Cybersecurity Framework 2.0, used as a supporting organizing structure ↗
We do not publish OCR enforcement counts, average settlement figures, or breach statistics. If a number cannot be traced to a primary source, it does not appear on this page. NIST CSF 2.0 is used to organize evidence; it is not a HIPAA compliance determination and using it does not make the assessment a NIST audit.
Clear boundaries
Support for your obligation, not assurance.
This is point-in-time support for the client's own Security Risk Analysis obligation under 45 CFR 164.308(a)(1)(ii)(A), covering the systems, people, documentation, and evidence in the agreed scope. It is not legal advice, not an audit, not a certification, not an attestation, not a regulatory examination, and not a regulatory investigation. HIPAA has no certification regime, and DSE is not a covered entity's compliance authority. It does not guarantee compliance, an enforcement outcome, insurance coverage, a contract award, or eligibility for anything. It does not make your organization secure and does not prevent, detect, or reduce the likelihood of any security incident; it documents risk against a defined scope at a point in time. DSE does not operate a security operations center, does not provide continuous monitoring or managed detection and response, does not perform live incident response or digital forensics and incident response (DFIR), and does not run penetration tests. Where you need any of those, we help you scope the requirement and select a provider you contract directly. Remediation implementation is the one item on this list DSE will perform, and only where it is separately scoped in writing. Business associate agreement terms are a separate legal matter between the parties and their counsel. Your security official under 45 CFR 164.308(a)(2), your privacy officer, your counsel, your auditors, and your carriers retain their respective roles. Where an engagement would give DSE access to ePHI, DSE is your business associate for that work under 45 CFR 160.103, and a Business Associate Agreement is executed before work starts. That is separate from the BAA point above: we sign the BAA that governs our own access, and we do not draft, negotiate, or opine on the BAAs between you and your other vendors or your customers.