The letter from the Office for Civil Rights gives the practice 30 days to produce its security risk analysis. The administrator finds it: a PDF from 14 months ago, filed the week after last year’s assessment and never opened since. It is thorough. It is also why the practice is now in trouble, because a risk analysis that gets filed and forgotten is just another document.

Three beliefs put practices in that spot, and each one costs money. The first is that the analysis is a once-a-year form. The second is that a vendor’s signed attestation covers the practice. The third, and the most expensive, is that finishing the assessment was the point.

It wasn’t. The rule that requires the analysis is blunt about how far it reaches: it covers all electronic protected health information the practice creates, receives, maintains, or transmits, and the analysis is only the first step toward reducing what threatens it.¹ What the practice does next is what makes patients any safer.

What the assessment is supposed to answer

A security risk analysis (SRA) examines confidentiality, integrity and availability risks affecting ePHI in a specific environment. A generic vulnerability scan does not meet the requirement on its own. Neither does a vendor attestation or a template that describes a practice other than yours.

Six questions define a useful assessment. What ePHI and connected assets are in scope? Where does that information live, move, get stored and get transmitted? What threats are realistic in this environment? What vulnerabilities make those threats likelier or more damaging? What safeguards exist already, and how reliable are they in daily use? Which risks need action now, and which can be monitored, transferred or accepted?

ASTP/ONC and OCR maintain a Security Risk Assessment Tool built to help smaller organizations conduct and document the analysis.² It structures the work well. It cannot define your scope, convene the right people or act on the findings.

Start with complete scope

A first-pass inventory often centers on the EHR and practice management system. Then ask where else patient information lives: email folders, scanned documents awaiting indexing, remote access sessions, cloud file shares, payer portals, backup systems, mobile devices, the telehealth platform, an analytics tool someone in quality configured, the transcription vendor, or a spreadsheet a manager maintains because the report she needs does not exist.

A defensible scope starts from OCR's standard — all ePHI created, received, maintained, or transmitted1 — and works outward through five asset categories:

• Core systems: EHR, practice management, patient portal, e-prescribing, document management, billing and revenue cycle platforms
• Endpoints: desktops, laptops, tablets, smartphones, printers, scanners, removable media
• Infrastructure: firewalls, servers, switches, wireless, backups, remote access, cloud environments, identity management
• Exchange pathways: lab, imaging, HIE, clearinghouse, payer, e-prescribing, API and referral connections
• External dependencies: hosted vendors, managed service providers, outsourced billing or transcription, analytics platforms, record-destruction vendors, and their subcontractors

A fast way to build the inventory: ask each department where patient information is stored, sent or temporarily held outside the EHR. The discussion often surfaces email folders, scanner queues, shared drives, payer dashboards and vendor portals that were absent from the original asset list.

Common threats imitate routine work

The threat environment facing a medical group is familiar and repetitive. Many attacks succeed through inconsistent controls rather than technical novelty.

Phishing succeeds because it imitates normal work — a document-sharing link, a spoofed voicemail notice, a message that looks like it came from a payer or from the administrator. Ransomware can stop scheduling, prescribing, documentation, claims and portal access at once; CISA's guidance emphasizes preparation and reporting because the disruption is so broad.³ Credential compromise may require no technical exploit where passwords are reused, authentication is weak or accounts are shared. A lost device triggers incident response and, depending on encryption status and the breach risk assessment, may require notification analysis. Insider misuse can look like ordinary access in the moment, which is why access review and audit-log monitoring exist.

Vendor exposure deserves separate weight. A hosted EHR, clearinghouse, imaging partner, cloud service or managed IT provider can become a single point of operational failure for a practice that was never itself breached. The 2024 Change Healthcare cyberattack disrupted pharmacy transactions, medical claims and payment infrastructure, while CMS urged payers to consider flexibility around prior authorization and other requirements.⁴

Small practices are not protected by obscurity. Automated attacks do not check provider count. Smaller organizations may also have fewer formal controls and less internal security capacity, particularly where staffing is thin and technology has accumulated through piecemeal purchasing.

Convert findings into a working register

The written report explains what the assessment found. The register is what turns it into work that gets done.

Every row carries a decision, and the decision is one of four: mitigate through new controls, transfer partly through insurance or contract terms, accept after leadership understands the residual exposure, or avoid by discontinuing the tool or relationship. Acceptance is legitimate — it is a real option, not a failure — provided someone wrote it down, dated it and put a name against it.

Likelihood and impact scoring should stay simple enough to apply consistently; three or five levels is plenty. The scores are estimates, not precise measurements, and they are useful mainly for comparison. They exist to help leadership decide whether multifactor authentication comes before a convenience tool, whether backup restore testing outranks a cosmetic upgrade, or whether a vendor relationship needs contract changes and a contingency plan.

NIST SP 800-66 Rev. 2 connects Security Rule requirements to risk-management activity and is the current reference for regulated entities.⁵ For translating a register into a prioritized control roadmap, HHS 405(d) Health Industry Cybersecurity Practices offer healthcare-specific guidance with a volume aimed at small organizations,⁶ and CIS Critical Security Controls v8.1 provides a prioritized implementation structure that maps well onto a practice deciding what to fund first.⁷

Where most practices start

Findings will vary, but the first round of fixes in many practices includes multifactor authentication for email, remote access and privileged accounts; patch and vulnerability management; backup restoration testing; provisioning, role-change and termination workflows; business associate and critical vendor inventory; endpoint encryption; security awareness training; remote-access controls; and incident response and downtime planning.

Where a risk cannot be corrected quickly, name an interim control rather than letting the item age silently. High-impact, easily exploited risks that remain open without explanation will be difficult to defend during an investigation, audit or post-incident review.

Refresh it when the environment changes

HIPAA does not prescribe an annual interval for risk analysis. Many practices adopt an annual review as their minimum policy cadence, supplemented by reassessment whenever technology, operations, ownership, vendors, locations or material threats change.¹ Triggers include a new EHR, a cloud migration, a merger, a new site, a major vendor change, expanded remote work, a serious incident, or any new workflow that relocates where ePHI lives. An assessment stops describing the environment when the environment moves.

Work the register through the year, not just when the annual assessment comes due. Open items should surface in leadership, compliance or operations meetings often enough that aging risks stay visible. Training should follow identified weaknesses. Budget requests should point back to register line items. Vendor review should concentrate on the dependencies carrying the most exposure.

Close an item only when the practice can show the risk was reduced, transferred, avoided or knowingly accepted. A finding without an owner, a date and a verification step is likely to reappear in the next assessment.

If the only person who can say where the practice's patient data actually lives works for the outside IT vendor, that is a control problem already — one that exists before any breach ever happens.

Notes

1. U.S. Department of Health and Human Services, Office for Civil Rights, "Guidance on Risk Analysis." https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html  
2. Assistant Secretary for Technology Policy / Office of the National Coordinator for Health Information Technology and Office for Civil Rights, "Security Risk Assessment Tool." https://healthit.gov/privacy-security-and-hipaa/security-risk-assessment-tool/ 
3. Cybersecurity and Infrastructure Security Agency, "Stop Ransomware." https://www.cisa.gov/stopransomware
4. UnitedHealth Group, "Update on Change Healthcare Cyberattack," March 7, 2024, https://www.unitedhealthgroup.com/newsroom/2024/2024-03-07-uhg-update-change-healthcare-cyberattack.html and Centers for Medicare & Medicaid Services, "Addressing Impacts Related to the Cyberattack on Change Healthcare," March 6, 2024. https://www.cms.gov/files/document/hpmsmemoonchangehealthcarecyberattack03062024.pdf
5. National Institute of Standards and Technology, SP 800-66 Rev. 2, Implementing the HIPAA Security Rule: A Cybersecurity Resource Guide. https://csrc.nist.gov/pubs/sp/800/66/r2/final
6. U.S. Department of Health and Human Services, 405(d) Program, Health Industry Cybersecurity Practices. https://405d.hhs.gov/cornerstone/hicp
7. Center for Internet Security, "CIS Critical Security Controls v8.1." https://www.cisecurity.org/controls/v8-1