Your Systems Are Probably Not as Secure as You Think! PHI Edition

If you work in healthcare then chances are PHI is not only in your EHR or CRM. It's in your team's inboxes, instant messaging platforms like Slack or Teams, stuffed in SharePoint or Google Drive, and in spreadsheets only two or three people know exist.

I've spent enough time in credit union and healthcare systems to know none of that happens because anyone is careless. It happens because the compliant way of doing something is usually slower or clunkier than the easy way, so people quietly drift toward the easy way without ever meaning to put PHI somewhere it shouldn't be. This post is a walk through every place I've personally watched that happen, and what actually closes the gap.

Audit logging looks fine until you actually need it

Don't take a vendor's word that they log activity. I've had a client ask for a report on who accessed a record and when, and discovered the native reporting on their CRM simply couldn't answer that question. It logged that something happened, not who did it or when in any usable way. Test this before you're depending on it, not after a records request lands on your desk.

SSO takes the burden off you

Local accounts mean password policy, login attempt thresholds, and every other piece of account security sits on you and the vendor. Route through SSO and you hand that job to Google or Microsoft, who do it better than most CRM vendors ever will. It also does double duty for access review, since disabling someone in AD locks them out everywhere at once instead of you chasing down every system they had a login for.

Lock down fields, not modules

This is the distinction that trips up a lot of buyers evaluating a new system. Locking an entire module doesn't work when marketing needs to see a contact but has no business seeing a diagnosis field sitting on that same record. Vendors that support field level permissions, Super Easy CRM being one, let you keep the record accessible while walling off the PHI inside it. Module level locking forces you to choose between hiding the whole record or exposing everything in it, and neither one is the right answer.

No BAA, no compliance, full stop

I don't care how good your technical controls are. If you haven't signed a BAA with the vendor, you're not in compliance. This is the one item on this list that has no workaround.

PHI doesn't stay in the system you built for it

This is really the heart of the whole post. PHI leaks sideways into whatever tool your team uses to talk about the patient, and most of those tools have none of the controls your CRM does.

• Ticketing a rep writes "patient's diabetes med refill isn't syncing" as a ticket title in Jira, and now PHI is sitting in a system with no BAA, no field level locking, and full text search available to anyone in the workspace.
• Chat someone pastes a patient detail into Slack or Teams to get a quick second opinion from a coworker, and now it's sitting in a tool with no BAA and permanent searchable history.
• Shadow spreadsheets the CRM is too cumbersome, so PHI ends up in a Google Sheet with none of the containment it was designed to have.

The fix isn't locking the CRM down harder. It's mapping every tool that touches a patient interaction and asking, on purpose, whether PHI is going to end up there. Sometimes that means keeping it out entirely, a ticket template that asks for a patient ID instead of a description does most of the work. Sometimes it means locking down the tool itself with a BAA and restricted fields.

Access review doesn't stop once SSO is set up

SSO handles part of this passively, but permissions still need regular review on their own, and admin access specifically tends to creep. I've worked at orgs where people request elevated access just in case they need it, so they don't have to wait on a ticket. That request feels reasonable in the moment and it's exactly how you end up with a dozen people holding admin rights they touch once a year.

A system too cumbersome to use isn't secure, it's ignored

This is the one that ties the whole thing together. A CRM too cumbersome to update pushes users toward shadow systems, and a spreadsheet full of patient data floating around outside the CRM is far more dangerous than the inconvenience it was solving. The same failure shows up with encrypted email. Legacy plugins like Zix are technically compliant but they crash and slow people down, so people stop using them and route around them entirely. Switching to a lightweight, natively integrated client wins not because it's more secure on paper, but because people actually use it the way it was intended. A control nobody uses isn't a control.

Every automation you build is a chain of handoffs, and PHI rides along on all of them

I love building with n8n and I love what AI agents can do once you wire them into a workflow, but every touchpoint in an automation is a place PHI can leak, and the more systems you chain together the more of those touchpoints you're creating.

I built a provider portal a while back that makes this concrete. The requirements were rigid going in. An on prem SQL database needed to be reachable by Power Automate through an on prem gateway, and that database was being fed by files landing in Google buckets. From there I built middleware in Flask that made API calls to pull down documents containing PHI, then pushed those documents into Dataverse so they'd be accessible to users inside Power Apps. I wrote about the full build here: building the provider portal with Power Pages and SQL Server.

• 01  Google bucket to on prem SQL
• 02  On prem SQL to Power Automate, through the gateway
• 03  Flask middleware calling out to grab the documents
• 04  Flask to Dataverse
• 05  Dataverse to the Power Apps front end

Five contact points, and each one is a place where PHI is in transit, sitting in a log, or passing through a service account that has more access than the person actually using the portal. None of those systems are inherently unsafe. The risk is that nobody usually stops to ask what's exposed at each individual link, they just check that data made it from point A to point Z. Adding an AI agent into a chain like that doesn't remove any of those handoffs, it usually adds one. Same rule as everywhere else in this post: map the touchpoint, ask if PHI is riding through it, and decide on purpose whether that link needs its own controls instead of inheriting whatever the systems on either side of it happen to have.

Network access is the door most people forget is unlocked

Every control on this list falls apart if someone can just log in from their kitchen table on a personal laptop. If it's practical, lock down access to PHI systems by IP so people are only getting in from a managed network, not wherever they happen to be sitting. VPN helps but it's not the same thing as actually restricting where the connection can come from.

The bigger risk isn't even the login itself, it's where the data goes after. I've watched this play out with SharePoint. An org needed to share data with a partner firm, so someone created a folder called "external" and dropped the files in. Made sense at the time. Then six months later every team was using that same "external" folder for anything going outside the company, because the name was right there and nobody thought twice about it. The problem was that first partner firm was only supposed to see one specific population's data. By the time anyone noticed, that folder had turned into a dumping ground with data flowing to a firm that had no business seeing most of what was in there.

It's never the tool that's broken

Zix crashes so people stop encrypting. The CRM is too cumbersome so people build a shadow spreadsheet. A folder gets a convenient name so it becomes the default for everything. Nobody sets out to expose PHI, they just take the route that's in front of them, and if that route wasn't built with PHI in mind, it goes wrong quietly until someone finally asks for a report and realizes there's no way to answer it.

If you take one thing from this, make it the ecosystem map above. Run your actual patient workflow through it, tool by tool, and be honest about where PHI is landing that nobody planned for. That's usually where the real exposure is sitting, not in the system you've already locked down.