Why these mistakes keep happening
Your team conducts a thorough risk analysis, documents every vulnerability, and files the report. You think you're done. Then OCR asks: "What did you do about the risks you found?"
That's the shift happening in 2026. OCR's enforcement initiative on the risk analysis provision of the HIPAA Security Rule is expanding to cover risk management. More than 50 settlements and civil monetary penalties have come from the Rights of Access initiative alone. Now OCR wants proof you've managed and reduced identified risks to an acceptable level.
The mistakes that trip up compliance teams aren't about ignorance. They stem from treating risk analysis as a documentation exercise rather than a continuous security practice. Here's what breaks, why it happens, and how to fix it.
Mistake 1: You inventory systems but not their actual state
Why it happens: Your IT asset inventory lists every server, workstation, and networked device. But it doesn't track what's running on them, the operating system versions, installed software, enabled services, or default accounts that shipped with the hardware.
The consequence: You can't identify vulnerabilities you don't know exist. When OCR asks for documentation showing you've addressed unpatched software risks, you discover your inventory tells you where systems are, not what state they're in. Vulnerability scanners run against an incomplete picture.
The fix: Build an asset inventory that tracks configuration state, not just device existence. For each system that creates, receives, maintains, or transmits ePHI, document:
- Operating system and current patch level
- Installed applications and versions
- Enabled services and protocols
- Active user accounts and privilege levels
- Network connectivity and segmentation
Update this inventory whenever you deploy new systems, retire old ones, or make configuration changes. Your risk analysis should reference this living document, not a static spreadsheet from last year's audit.
Mistake 2: You patch critical systems but ignore the periphery
Why it happens: Your patch management policy prioritizes servers hosting electronic health record systems and databases. Workstations running clinical software get scheduled updates. But the network printer in radiology? The smart TV in the waiting room? The conference room tablet? Those get forgotten.
The consequence: Unused networked devices and unpatched peripherals create entry points. OCR's guidance explicitly calls out laptops, smartphones, and unused accounts as attack surfaces that should be disabled or removed. When a breach investigation traces the initial compromise to an unpatched IoT device, your documentation showing you patched the EHR won't matter.
The fix: Treat every networked device as part of your attack surface. Sign up for vulnerability alerts from every manufacturer and vendor whose products touch your network. Monitor CISA's Known Exploited Vulnerability Catalog for your entire technology stack, not just your core clinical systems.
When patches aren't available, implement mitigations: network segmentation, access restrictions, or disabling the device until a patch ships. Document these decisions in your risk management records.
Mistake 3: You remove unnecessary software but leave default accounts active
Why it happens: Your system hardening checklist includes uninstalling games, social media apps, and utilities that ship with operating systems. You disable unused services. But the default administrator accounts and service accounts created during installation? Those stay active with their factory passwords because "we might need them someday."
The consequence: Default credentials are the first thing attackers try. OCR's guidance notes that operating systems and software often create accounts during installation that have default passwords. If you've documented removing unnecessary software but left default accounts enabled, you've addressed half the problem.
The fix: Audit every system for default accounts created during OS or application installation. For accounts you must keep, change default passwords to strong, unique credentials and document the change. For accounts you don't need, disable or delete them.
This applies to service accounts, too. If an application installer created a SQL service account with "Password123," either change it or remove the application.
Mistake 4: You configure security measures once and never verify they're still working
Why it happens: You enable encryption for data at rest. You configure audit logging. You set authentication requirements. The security measures required by the HIPAA Security Rule get implemented during your initial compliance push, then you move on to other priorities.
The consequence: Configurations drift. A system update resets logging parameters. A new administrator disables a security feature to troubleshoot an issue and forgets to re-enable it. OCR emphasizes that evaluating the ongoing effectiveness of security measures is required; system hardening isn't a one-time exercise.
The fix: Schedule periodic verification of your security configurations. For access controls, encryption, audit controls, and authentication:
- Test that the control still functions as designed
- Review configuration settings against your baseline
- Document the verification date and results
- Investigate and remediate any drift
Quarterly reviews catch most drift before it becomes a compliance gap. Critical systems warrant monthly checks.
Mistake 5: You document vulnerabilities but not your management decisions
Why it happens: Your vulnerability scans generate reports listing every CVE affecting your environment. You prioritize them by severity score, patch what you can, and move on. But you don't document why you accepted certain risks, what compensating controls you implemented, or when you plan to revisit deferred issues.
The consequence: OCR will require documentation demonstrating that identified risks have been managed and reduced to an acceptable level. A list of vulnerabilities you found isn't enough. You need records showing what you did about each one and why your decisions were reasonable.
The fix: Create a risk management log that tracks every identified vulnerability through its lifecycle:
- Vulnerability description and affected systems
- Risk assessment (likelihood and impact)
- Management decision (patch, mitigate, accept, or transfer)
- Justification for the decision
- Implementation date and verification
- Review schedule for accepted risks
When you accept a risk because patching would break clinical functionality, document that trade-off. When you implement network segmentation as a compensating control, record the implementation and test results.
Prevention checklist
Before your next risk analysis cycle:
- Update your IT asset inventory to include configuration state, not just device names
- Verify you're monitoring vulnerability alerts for every vendor and manufacturer in your environment
- Sign up for CISA's Known Exploited Vulnerability Catalog alerts
- Audit all systems for default accounts and credentials
- Schedule quarterly verification tests for access controls, encryption, audit logging, and authentication
- Review your network for unused devices, accounts, and services that should be disabled
- Create a risk management log template that captures decisions and justifications
- Document your patch management process for situations where patches aren't yet available
- Test that your vulnerability scanning covers your entire network perimeter, not just core systems
- Establish a review cycle for accepted risks (at minimum, annually)
OCR's 2026 enforcement priorities make one thing clear: finding vulnerabilities is table stakes. Managing them is what keeps you compliant.
