HIPAA 2.0 represents the biggest overhaul of healthcare privacy regulations in over two decades, and nowhere is this more evident than in the enhanced requirements for Security Risk Assessments (SRA). As we covered in our comprehensive guide to HIPAA 2.0 for Salesforce, these new requirements transform security from a checkbox exercise into an ongoing program of protection.
The Security Risk Assessment sits at the heart of these changes. It’s no longer enough to simply have Salesforce Shield or check a few security settings — you need a comprehensive, documented assessment of your entire security posture. If you’re using Salesforce to handle protected health information (ePHI), here’s exactly how to complete your SRA under HIPAA 2.0’s enhanced requirements.

Step 1: Get the Right Tool
Head to HealthIT.gov’s Security Risk Assessment Tool page. You have two options:
- Download the Windows desktop application
- Use the Excel workbook version (great if you’re on Mac or prefer spreadsheets)
Step 2: Work Through the Seven Sections

The tool breaks down your assessment into seven key areas. For each section, you’ll need to:
- Answer questions about your security practices
- Evaluate specific threats and vulnerabilities
- Assess likelihood and impact of each risk
Here’s how to translate these for your Salesforce org:
Section 1: SRA Basics
- Document where all your ePHI lives in Salesforce
- Map out which objects, fields, and reports contain protected data
- List all integrated systems that touch ePHI
Section 2: Security Policies
- Document your Salesforce security settings
- Include profile and permission set configurations
- Detail your password policies and session settings
Section 3: Security & Workforce
- List all users with access to ePHI
- Document your training procedures
- Outline access review processes
Section 4: Security & Data
- Detail your encryption settings
- Document backup procedures
- List data retention policies
Section 5: Security & the Practice
- Map your Salesforce integrations
- Document authentication methods
- List physical security controls
Section 6: Security & Business Associates
- List all AppExchange packages handling ePHI
- Document vendor agreements
- Detail integration security measures
Section 7: Contingency Planning
- Document your backup procedures
- Detail your disaster recovery plan
- List emergency access procedures
Step 3: Assess Threats and Vulnerabilities
For each section, you’ll evaluate specific threats. Rate each for:
- Likelihood (Low, Medium, High)
- Impact (Low, Medium, High)
- Overall Risk Level (based on the combination)
Step 4: Create Your Risk Register
Compile all identified risks into a prioritized list including:
- Risk description
- Current controls
- Risk level
- Recommended actions
- Priority level
Step 5: Develop Your Risk Mitigation Plan
Create an action plan that:
- Prioritizes high-risk items
- Sets realistic timelines
- Assigns responsibility
- Includes follow-up dates
- Plans for the next assessment
Common Pitfalls When Conducting Your SRA
Before diving into your first Security Risk Assessment, be aware of these common mistakes that often trip up Salesforce teams:
1. Focusing Only on Built-in Salesforce Features
Many teams only assess standard Salesforce security features while overlooking integrated systems, AppExchange packages, and custom code that handles ePHI. Your SRA needs to cover your entire Salesforce ecosystem, not just the platform itself.
2. Incomplete ePHI Mapping
It’s easy to miss places where ePHI lurks in your Salesforce org. Teams often forget to check:
- Custom Objects and Fields
- Email Templates
- Chatter and Collaboration Features
- Reports and Dashboards
- Sandbox Environments
- Integration Middleware
3. Overlooking User Permissions
Many organizations focus on technical controls while neglecting to thoroughly assess who has access to what. Your SRA must include a comprehensive review of:
- Profile Permissions
- Permission Sets
- Sharing Rules
- Role Hierarchies
- Public Groups
- Manual Sharing
4. Insufficient Documentation
Simply having security controls isn’t enough — you must document them. Common documentation gaps include:
- Configuration Change Logs
- Security Setting Justifications
- Risk Assessment Methodologies
- Mitigation Strategies
- Testing Procedures
5. Treating the SRA as a One-Time Project
Some organizations complete their SRA and file it away, never to be seen again. The SRA should be a living document that’s:
- Updated when new features are implemented
- Reviewed when integrations are added
- Revised after security incidents
- Reassessed during major Salesforce releases
Conclusion
The Security Risk Assessment requirement in HIPAA 2.0 fundamentally changes how healthcare organizations must approach security in Salesforce. Gone are the days of annual checkups and basic security reviews. Instead, we’re entering an era of continuous assessment and improvement, where your SRA becomes a living document that evolves with your organization.
While the requirements may seem daunting, the HHS Security Risk Assessment Tool provides a clear path forward. Whether you’re just starting your HIPAA 2.0 compliance journey or updating your existing processes, the key is to approach it systematically and thoroughly. Remember, this isn’t just about checking boxes — it’s about building a robust security program that protects your patients’ data and your organization’s future.
Next Steps
- Visit HealthIT.gov’s SRA Tool page now
- Download either the Windows application or Excel workbook
- Block time on your calendar — this isn’t a quick process
- Gather your Salesforce documentation
- Start working through the sections
Remember: The SRA isn’t a one-time task. Plan to review and update it regularly, especially when making significant changes to your Salesforce org.
Need help? The tool includes detailed guidance for each section, but consider working with a qualified HIPAA compliance consultant for your first assessment. And don’t forget to bookmark our complete HIPAA 2.0 Guide for Salesforce for ongoing updates and guidance.