Guide To Managing PHI In Your CRM
How To Handle PHI in Your CRM
When your CRM becomes the source of truth for your organization it'll likely get jam packed with all sorts of data. And, if you're a healthcare org, 9 times out of 10 that information pertains to something deeply personal about a person's health. Thus, you'll need to build in safeguards to protect the privacy of your patients and your organization from being fined to death. As a CRM Solutions Architect with roughly a decade of experience working with healthcare organizations, here's how I handle PHI in CRMs.
Ensure People Only Have Access to The Minimum Amount of Data
This may sound counterintuitive given how we tend to think more data = 'better', but when it comes to securing data, less is actually more. If you have a CRM like Salesforce, SuiteCRM, or Super Easy CRM you can utilize permission/security groups to accomplish this. Make sure people can only access the modules and features that they absolutely need to do their job. Don't get in the habit of granting access to sensitive data for people just in case they need it.
Here's how I create permission groups:
- Start with job functions: I used to build permission groups by department but found out that in most places access levels vary wildly, even within the same department. Roles are a better grouping mechanism.
- Enable field level permissions: If your CRM allows for field level permissions, enable them. It's better to lock down single fields like SSN or Diagnosis than removing access to entire modules.
- Conduct thorough data inventory: You'll want to define what fields have the sensitive information you're trying to protect. This is important to prevent anyone inheriting access that they don't need or shouldn't have.
- Use descriptive names: Use names like document chaser, eligibility verification, etc for permission groups names. In most cases you can add more than one role per user, so don't worry about creating an all encompassing permission group.
Note: Terms like modules, objects, and permission groups vary from platform to platform but the Principle of Least Privilege remains the same.
This isn't just best practice or common sense, but a legal requirement. HIPAA regulations require RBAC (role based access), unique user identification, and access controls. Failing to adhere to these provisions can result in a hefty fine.
What To Do If People Want More Access
If anyone needs additional access first figure out how long they'll need it and then get them to submit an access request through your ticketing system. From there, you'll want a manager or HR to approve the access within the ticketing system so you have a paper trail of who permitted new access to sensitive information. It's going to annoy your users but failing to do so could lead to the collapse of the organization as a whole...and unemployment is way worse than creating a ticket.
Not only does your access request ticket keep things organized, it also provides you with the paper trail you'll need in the event of an audit.
Keep the System Admins to a Minimum: More Chefs in the Kitchen = More Leaks
I've worked at organizations that handed out admin access like appetizers at a cocktail party. Not only was it dangerous from a compliance perspective but it provided employees with the ability to wreck an entire system should they have the inclination. Designate only a couple, ideally three or less admins for your CRM.
And, all should undergo regular training and while they don't need to be developers they should have a decent understanding of CRM software before getting the keys to the kingdom. Finding out what a button does could spell disaster for the entire organization. Regularly review access levels and adjust accordingly. I try and perform this task at least once a month, if not sooner. It should also be done whenever a person changes roles.
Ensure Users Don't Keep Access When Roles/Duties Change
When people change roles or switch departments they will likely no longer need access to applications they once had. When role changes occur, you'll need to remove access to any area of the CRM they don't need anymore. I remember one case where a user bounced from Accounting to Marketing then to Compliance all the while collecting access like Infinity Stones. Accounts were lying dormant and the organization's attack surface kept increasing.
This is why regular audits, while boring, are so crucial to the success of your CRM strategy and business overall.
Only Use Admin Accounts When Doing Admin Work
Your CRM Admin and developers should not be performing regular activities like resolving tickets, running reports, and updating records with their admin accounts. They should have a standard account for everyday tasks. When anyone is in the CRM as an admin they are essentially in God mode and can bypass nearly every safeguard the system has in place to protect PHI and maintain data integrity.
Obfuscate Data Where Possible
Social Security numbers should not be plain text and viewable by anyone, not even admins. There is seldom a valid reason for a system admin to view such a field, unless troubleshooting a very, very, very specific issue. Salesforce, vTiger, Microsoft Dynamics 365, and others all offer this configuration for the UI of individual records. If your CRM has this, use it! If it doesn't do your best to collapse it or make it togglable. Here's a little cheat code I picked up, should your CRM not offer this security feature.
- Set dependent logic
- Choose a field that will serve as the parent/trigger
- Ensure only the necessary permission groups have access to this field
- Name the field something like SSN Toggle
- Set the field to display the SSN field when checked
SugarCRM, SuiteCRM, and a ton of others have this functionality and while it isn't as clean as true data obfuscation, it does technically obscure it from view. And, you don't have to pay any custom development fees or go up a tier to use it.
The Report Loophole - How PHI Can Be Leaked Due to Page Layouts
One can't rely on page layouts alone to prevent PHI from getting in front of the wrong eyes. While it's true that you can prevent an unauthorized user from seeing a field with sensitive info by using a role based view, they may be able to see it anyway if they can export the record or run a report. When users have access to an object like a contact record, they can also export the data within it, unless you restrict them.
Sure, the data won't be as pretty but the csv they now have access to can be just as dangerous as if it were in the UI. For this reason, it's important to use FLS (field level security).
When in doubt, lock it down
There is a fine line between usability and security. The latter is something that most view as an inconvenience, not a necessity. But, a secure CRM can certainly be a user friendly one if you follow the tips outlined in this article. Make sure your permissions are in alignment with the actual job functions the users perform. Follow the action, not the title, and things are more likely to flow smoothly.
Keep the practice of least privilege at the forefront of your application configuration and be sure to obscure any sensitive information from your UI, if at all possible. And, if you ever get stuck, feel free to drop us an email at contact@supereasycrm.com. If you're on LinkedIn, feel free to drop me a DM using the link below.
Posted by: Matt Irving on 01/13/2026