A note on who I am and who this guide is for

Before I started doing compliance assessments, I was an EMT for four years. Before that, I studied public health. HIPAA wasn't a regulation I learned about in a training session. It was the framework that shaped how I handled patient information from the back of an ambulance. Years later, I moved into IT, then cybersecurity, then worked my way up to running the security program at a regulated financial institution where I led the organization from near-regulatory intervention to one of the most secure in its peer group.

That dual background, healthcare on one side and regulated cybersecurity on the other, is how I think about HIPAA. Not as paperwork. As a real operational and security practice that protects real patients.

This guide is for small healthcare practices and the business associates who serve them. If you're a solo provider, a small group practice (two to ten providers), a specialty clinic, a billing company, or an IT vendor working with healthcare, this is written for you. Not for hospitals. Not for huge multi-specialty groups. The small practice has different problems, fewer resources, and almost always a different relationship with its IT and security than larger organizations do. The advice below reflects that.

I want to be straightforward with you about something else. I sell expertise, not tools. I don't take kickbacks from vendors. I don't bundle assessments with managed services. That independence is the whole reason I can write a guide like this without it becoming a sales pitch for products. When I say "you probably need to look at this," I have no incentive other than the accuracy of that statement.

Let's get into it.

What HIPAA actually requires

HIPAA is built on three rules. Most small practices know there are rules. Far fewer can name them, and even fewer understand how the rules relate to each other and to the practice's day-to-day operations.

The Privacy Rule governs how Protected Health Information (PHI) can be used and disclosed. This is the rule that defines what counts as PHI, what patients can do with their own records, what notices you have to provide, and what your minimum-necessary obligations are. Most small practices handle the Privacy Rule reasonably well because their lawyers built it into the practice when they opened. Notice of Privacy Practices, signed acknowledgments, basic disclosure rules. These tend to be baked in.

The Security Rule governs how electronic PHI (ePHI) is protected. There are three categories: administrative safeguards (policies, training, sanctions, risk analysis), physical safeguards (facility access, workstation security, device controls), and technical safeguards (access controls, audit logs, integrity, transmission security, encryption). This is where most small practices fall apart, and we'll spend the most time here.

The Breach Notification Rule governs what you do when something goes wrong. When PHI is exposed, lost, stolen, or accessed by someone who shouldn't have had access. This rule sets the timelines, the notification requirements, and the four-factor risk assessment that determines whether an incident counts as a reportable breach. Most small practices haven't thought through this rule at all until they're already in the middle of an incident, which is the worst possible time to start thinking about it.

If I had to rank the three by where small practices most often fall short, in my experience: Security Rule first, Breach Notification Rule a close second, Privacy Rule a distant third. We'll go through each of them. But first, I need to talk about the thing that underlies all of them.

The thing nobody tells small practices

Most small practices outsource the technical work to an IT vendor and then assume HIPAA compliance is handled. It almost never is.

This is the single most important paragraph in this guide. If you read nothing else, read this section.

Here's the pattern I see in every assessment I've done. A small practice hires an IT vendor. Sometimes an MSP, sometimes a one-person shop, sometimes a friend of the office manager. The IT vendor sets up the computers, the email, the EHR connection, maybe some endpoint protection. The practice assumes that since they have an IT vendor handling "the technical stuff," they are compliant. The IT vendor, meanwhile, often outsources their own security tooling to a third party. An MDR provider, a SOC-as-a-service, a security vendor of some kind.

So the practice is now two touch points away from the people actually doing the security work. Nobody at any of the three organizations has a complete view. The IT vendor handles a subset of things. The security vendor handles a subset of things. The EHR handles a subset of things. And somewhere in the gaps between those subsets, the entire risk analysis is missing. Nobody is reviewing access logs. Nobody is testing backups. Nobody has documented an incident response plan. Nobody has reviewed who has access to what, or whether terminated employees still have credentials, or whether there's a BAA in place with every vendor that touches PHI.

The practice thinks they're covered. The IT vendor thinks the parts they don't handle are someone else's problem. The security vendor thinks they're just providing the specific tool they were hired for. Everyone is operating in good faith, and the result is that nobody is actually responsible for HIPAA compliance.

When I do an assessment, I'm often the first person who has ever looked at the full picture. That's not a brag. It's a structural problem in how small healthcare practices buy IT and security services.

The fix is not to insource everything. Most small practices can't afford to and shouldn't try. The fix is to hold your vendors accountable with defined roles, written agreements, and regular reporting. You need to know what your IT vendor is responsible for. You need to know what they're explicitly not responsible for. You need someone, internal or external, who is responsible for looking at the seams between vendors and making sure things aren't falling through them.

The Security Rule, in plain language

The Security Rule has three categories of safeguards: administrative, physical, and technical. I'll go through each in the order I look at them during an assessment.

Administrative safeguards

These are the safeguards that exist on paper and in process. They are the most commonly missing, and they are also the most heavily weighted by OCR when they investigate.

The cornerstone administrative safeguard is the risk analysis. The Security Rule requires every covered entity to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI. It is not optional. It is not a one-time event. It has to be conducted, documented, and updated on an ongoing basis.

In every assessment I've done, this has been the first major gap. Practices either have never conducted a risk analysis at all, conducted one years ago and never updated it, confused a vulnerability scan with a risk analysis, or bought a template online and treated filling it out as the work itself.

A vulnerability scan is a technical scan of systems for known weaknesses. A risk analysis is much broader. It examines administrative, technical, and physical safeguards together. It looks at how data flows through the organization, where it's stored, who has access to it, what threats apply to your specific operation, and what the likelihood and impact of each threat would be if it materialized. A PDF from a scanning tool is not a HIPAA risk analysis. If OCR comes asking, that distinction matters.

Other critical administrative safeguards include:

Many of these are missing in small practices, or exist as a document nobody has read in three years.

Physical safeguards

These get the least attention in my work because small practices are usually reasonable on this front. Locked offices, badge access to back areas, workstation positioning away from public view, secured paper records. The basics are usually in place.

Where I do see gaps in physical safeguards: device controls. Specifically, the laptops and mobile devices that leave the office. If a provider takes a laptop home and that laptop isn't encrypted, you have a Security Rule problem and a Breach Notification Rule problem the moment that laptop is stolen from a car. Encryption of portable devices is one of the highest-impact, lowest-cost controls in the entire framework, and it's surprisingly often not in place.

Technical safeguards

This is where most small practices believe they're protected because they have an IT vendor. Sometimes they are protected. Often they aren't.

The Security Rule requires:

I will tell you what I almost always find: shared accounts and inadequate access controls. Front desk staff using the same login. Clinicians using a single credential to access the EHR. Administrative users with access far beyond what their role requires. No multi-factor authentication on any system. No audit log review, and often no awareness that audit logs exist or are required.

The risk this creates is operational as much as compliance. If one person can access everything, one person can cause records to be lost, deleted, or stolen without anyone else noticing. When there are no logs, there's no way to investigate. When there are no defined roles, there's no segregation of duties. The practice has built a situation where a single bad actor, internal or external, can do enormous damage with no detection.

When this goes wrong: a story I've seen play out

I was called in to help with the response to a security incident at a small specialty practice. They had IT services from an outside vendor. They had endpoint protection. They had a backup, or at least they thought they did.

What they did not have: a risk analysis. A tested incident response plan. Documented procedures for what to do when something went wrong. Evidence that their backups had ever been tested to confirm they would actually restore. Clear definition of what their IT vendor was responsible for versus what was the practice's responsibility.

When the incident hit, the response was essentially: "Everything is lost. Let's rebuild." Patient records were inaccessible for an extended period. Some records could not be recovered at all. The practice spent weeks rebuilding their data and their reputation. They had to notify patients. They ended up on the HHS public breach reporting portal, where their incident remained visible for two years as required.

The bad PR was severe. Patients who trust you with their health information do not respond well to learning their records were exposed because the practice hadn't tested their backups or their incident response plan. Some of those patients found another provider. The financial cost of the incident was real. The reputational cost was larger and longer-lasting.

The gaps that caused this incident were not exotic. They were not advanced cybersecurity failures. They were missing fundamentals. The same fundamentals OCR looks for first when they investigate.

The Breach Notification Rule, in plain language

Most small practices don't think about breach notification until they're in the middle of an incident. That's the wrong time. The Breach Notification Rule defines what counts as a breach, when you have to notify, who you have to notify, and how.

The core mechanic: when there's an impermissible use or disclosure of unsecured PHI, you have to conduct a four-factor risk assessment to determine whether the incident is a reportable breach.

The four factors are:

  1. The nature and extent of the PHI involved. What kind of information, how identifiable.
  2. The unauthorized person who used or received the PHI. Were they a covered entity, a stranger, a bad actor.
  3. Whether the PHI was actually acquired or viewed. Or was it just exposed in a way that may or may not have been accessed.
  4. The extent to which the risk has been mitigated. What you've done to reduce ongoing exposure.

If your assessment concludes there's a low probability of compromise, you may not need to notify. If the assessment concludes otherwise, or if you can't credibly demonstrate low probability, you have to notify. Affected individuals within 60 days. HHS within 60 days for breaches affecting 500 or more individuals (annually for smaller breaches). In some cases, the media.

A few things small practices commonly get wrong.

Ransomware is presumed to be a breach. OCR guidance treats ransomware incidents as presumptive breaches unless the organization can demonstrate a low probability of PHI compromise. You don't get to assume it wasn't a breach because the attackers said they didn't read the data.

Lost or stolen unencrypted devices are presumed to be breaches. A laptop with PHI on it that disappears from someone's car is a breach unless you can prove the device was encrypted. Encryption matters here more than anywhere else.

Documentation is required even for incidents you decide aren't reportable. If you conduct the four-factor analysis and conclude an incident isn't a breach, you have to document that analysis. "We talked about it and decided it was fine" is not adequate documentation if OCR asks.

The HHS public breach reporting portal, sometimes called the Wall of Shame, is real and lasting. Breaches affecting 500 or more individuals are published publicly and remain on the portal for the duration of the investigation. Patients can look up your practice. Local media can find you there. Two years of public visibility is a lot of reputational risk.

The vendor problem: BAAs and what they actually do

A Business Associate Agreement (BAA) is a contract between a covered entity (your practice) and a vendor that handles PHI on your behalf. The BAA establishes that the vendor will safeguard the PHI they receive, restrict use to the purposes you've authorized, and notify you if they have an incident.

A BAA is not optional. If a vendor creates, receives, maintains, or transmits PHI on your behalf, you need a BAA in place before that vendor touches the data.

In every assessment I've done, I've found BAA gaps. They take several forms.

Missing BAAs with obvious vendors. The IT provider has a BAA. The EHR has a BAA. But the cloud backup provider doesn't. Or the email provider doesn't. Or the e-fax service doesn't.

Missing BAAs with non-obvious vendors. This is the bigger problem. Vendors that touch PHI but the practice doesn't think of as healthcare vendors include:

Each of these can be receiving or storing PHI. Each needs a BAA. Many practices don't have them and don't know they should.

BAAs nobody has read. Even when BAAs exist, the practice typically signed them without reading them. They don't know what's in them. They don't know what services are covered (a BAA with a vendor might only cover certain products or plans). They don't know the breach notification timeline they're entitled to. They don't know whether subcontractors are addressed.

The misunderstanding about what a BAA does. A BAA does not transfer liability. The practice remains responsible for HIPAA compliance even when a vendor causes the incident. OCR can still investigate the practice. A BAA gives you contractual recourse against the vendor and establishes the vendor's obligations, but it does not get you off the hook with regulators.

The misunderstanding about what a BAA does for security. A BAA is a contract, not a security assessment. A vendor can sign a BAA and still have terrible security practices. Having a BAA does not mean the vendor is secure. It means the vendor has agreed to certain obligations. Whether they meet those obligations is a separate question, and one the practice has a responsibility to evaluate.

What an OCR investigation actually looks like

Most small practices have a vague fear of OCR audits that doesn't match what investigations actually look like. Let me try to give you the realistic picture.

The Office for Civil Rights (OCR) is the HHS division that enforces HIPAA. They have two main ways of looking at your practice. The first is a proactive audit program, which is rare and selective. The second, and far more common, is an investigation triggered by an incident or a complaint.

Triggers for OCR investigations include:

When an OCR investigation starts, it usually does not start with regulators arriving onsite. It usually starts with a letter. The letter requests documentation, typically the same documentation the Security Rule already requires you to maintain.

OCR will want to see:

The phrase that matters most here is: undocumented is effectively nonexistent. If you trained staff but didn't document it, OCR will not credit you with training. If you reviewed access but didn't record the review, OCR will not credit you with reviewing access. If you conducted a risk analysis but can't produce it, you didn't conduct a risk analysis.

What OCR is generally looking for is whether reasonable safeguards existed, whether you were negligent, and whether you're taking corrective action. Small practices imagine OCR is evaluating them against Fortune 500 standards. Usually, they're evaluating against foundational maturity, and what they find when they look at small practices is often that the foundations are missing.

Penalties are more likely when OCR finds systemic neglect: no risk analysis, no policies, ignored warnings, repeated failures. Penalties are less likely when OCR finds a practice that took reasonable steps, documented those steps, and responded appropriately when something went wrong.

The point isn't to be afraid of OCR. The point is to have the documentation that demonstrates you took compliance seriously, before you need it.

What practices fear that they shouldn't, and what they should fear that they don't

Small practices regularly worry about the wrong things. Here are the most common misallocations of compliance attention I see.

Over-fears

Under-fears

The things small practices should worry about more, the things that actually drive incidents, investigations, and patient harm, are far less glamorous than the over-fears.

A lot of practices spend energy trying not to technically violate HIPAA in small ways while ignoring the operational and cybersecurity weaknesses that lead to actual breaches, actual investigations, actual downtime, and actual liability. Reallocate.

The most dangerous misconception of all

Here's a sentence I want you to read carefully:

HIPAA compliance is a baseline, not a modern cybersecurity standard.

A practice can technically satisfy many HIPAA administrative requirements while still having weak cybersecurity. The Security Rule was last meaningfully updated long before ransomware was the threat it is today. HIPAA does not explicitly require modern controls like EDR/MDR, advanced email security, zero trust architecture, SIEM, or 24/7 SOC monitoring. But those controls are increasingly important in real-world defense.

The practice that focuses only on checking HIPAA boxes will be technically compliant and still wide open to the attacks that actually happen. The practice that focuses on real security will exceed HIPAA's baseline naturally. The right framing is to use HIPAA as a floor, not a ceiling, and to build a security program that genuinely protects PHI, not just one that survives a documentation review.

The other version of this misconception runs in reverse: practices believe that because they've never had an incident, they don't need to worry about compliance. The absence of prior incidents tells you nothing about whether your safeguards exist. OCR investigations frequently surface gaps that existed quietly for years, sometimes a decade or more, before a triggering event finally exposed them. The fact that nothing has gone wrong yet is not evidence that your controls are working. It might just mean you haven't been targeted yet.

In healthcare, the question isn't if. It's when.

On templates, checklists, and DIY compliance

You can find HIPAA compliance templates and checklists online for free or for a few hundred dollars. Some of them are decent. Most of them are decent enough to give you a false sense of completion while leaving the actual work undone.

The honest take on DIY compliance: it can give you a quick understanding of where you stand. That's genuinely useful. A free checklist might help you discover you're missing a risk analysis, or that you don't have BAAs with several vendors that need them. As a starting point, fine.

The problem is when the checklist becomes the destination instead of the starting point. Checking boxes someone else wrote, without the experience to know what the boxes actually mean or which gaps are most dangerous, leads to a compliance program that exists on paper and nowhere else. And when OCR comes asking, or worse, when an incident hits, the checklist won't help you.

There's a second, less obvious problem with DIY compliance, which is the reputational signal it sends. If a patient learns their data was exposed because the practice handled HIPAA with a downloaded template and an assistant filling in blanks, they have a fair question: what else are we cutting corners on? In a service like healthcare, where trust is the entire foundation of the relationship, that signal matters.

I think of an assessment the way you'd think of a second opinion from another physician. It isn't that you can't read your own X-rays. It's that a second set of trained eyes catches things you wouldn't, and the cost of being wrong is high enough that the second opinion is cheap insurance. Hiring an outside assessor, not just me, anyone qualified and genuinely independent, is the same principle. You may have someone on staff who's bright and motivated and willing to work on this. You may even have someone with relevant credentials. Hire them. And then also have someone external look at the work. It's how you make sure the controls you think you have are actually doing what you think they're doing.

How I approach this work, briefly

I want to describe my actual process, partly because it explains what an assessment looks like and partly because the specifics matter.

I start every engagement by walking the practice through what the process will involve. There are no surprises. Then I send an intake form. When the intake comes back, I review it carefully and prepare a document request, listing the specific evidence I need to see based on what the intake reveals about the practice's operations and current state.

The practice sends me the documents. I review them. I prepare questions and identify the configurations I'll need to see live during our call. We do a virtual call where we go through findings, and where I have the practice share their screen to confirm certain settings and configurations. After the call, I write a comprehensive written report. The report includes findings, severity ratings, and a risk-prioritized remediation roadmap.

I deliver the report on another virtual call. We spend 30 to 60 minutes going through the findings and the roadmap together. The practice walks away with a defensible written report they can produce if asked, and a clear sense of what to fix first and what can wait.

After the engagement closes, I'm available for 30 days of advisory support at no additional charge. Questions about the report, help interpreting findings, clarifications about remediation steps. After that 30-day window, ongoing advisory is available at standard rates. The full report stays available to the practice through a secure client portal for three years.

Most engagements complete in two to four weeks from kickoff to delivered report.

I don't sell tools. I don't take commissions from vendors. When practices ask me which MDR or email security or backup vendor they should use, I tell them honestly based on what I've evaluated. Sometimes the answer is the vendor they already have. Sometimes it isn't. Either way, the advice doesn't change based on what I'd make from it, because I don't make anything from it.

This is what I mean when I describe Complyn as "a true friend to the practice, not a salesman." A salesman's incentive is to find more things to sell you. A friend's incentive is to tell you the truth about what you need.

What I want you to walk away with

If you read only one paragraph of this guide, read this one.

You almost certainly need an independent compliance assessment, because your IT vendor is probably handling some of HIPAA but not all of it, and the gap is wider than you think. Get an assessment from a firm that doesn't sell the tools they recommend. Get a written report you can produce if OCR asks. Get a roadmap that tells you what to fix first. Get ongoing advice as the practice grows and the threats evolve. And get this in place before something goes wrong, because the moment after an incident is the worst possible time to discover that the safeguards you assumed were in place were never there.

Healthcare is critical infrastructure. The practices serving small communities are part of that infrastructure. The patients trusting those practices with their health information deserve providers who take that trust seriously, which means taking HIPAA and cybersecurity seriously, not as a paperwork exercise but as part of the duty of care.

If you choose to kick the can down the road, you're not just risking fines or audits. You're setting yourself up for an incident that will hurt your practice and the people who trusted you with their information.

Be the practice that took it seriously before you had to.

If you've read this far and you're not sure where your practice actually stands, that's the right time to have someone look. Schedule a HIPAA compliance assessment with Complyn. Independent, expert, no upsells.