HIPAA Security Program
The Security Rule asks for a named person and a program that exists. Most companies have neither, and find out when somebody asks.
HIPAA does not ask whether you take security seriously. It asks who your security official is, what your risk analysis says, which policies you have, and what evidence supports them. Those are answerable questions with checkable answers, which is what makes the gap so visible when an auditor, an enterprise customer or a regulator finally asks.
The common position is not negligence. It is a company that bought the right tools, signed the right agreements, and never had anybody whose job it was to hold the program together.
What this covers
The named security official
The Security Rule requires one. Not a committee, not the MSP, and not whoever has the most time. On a fractional arrangement that is me; on a project I help you decide who it should be and give them something they can actually hold.
Risk analysis that would survive being read
An accurate and thorough assessment of risk to electronic protected health information everywhere it lives, moves and is backed up, with the reasoning written down. This is the control most often cited in enforcement, and the one most often satisfied with a questionnaire.
Policies people can follow
A policy set matched to how your company actually works. Policies nobody follows are worse than missing ones, because they document a standard you are provably not meeting.
Workforce and access controls
Who can reach what, how that is granted and removed, and how you would show it. Access review is where diligence questions land hardest and where organic growth does the most damage.
Business associates in both directions
The agreements you hold with vendors, and the ones your customers hold with you. Being a business associate carries direct liability, not just contractual exposure.
The architecture underneath
Tenant separation, authorization on every request, encryption in transit and at rest, and audit logging that exists before somebody asks for it. A program whose claims the system does not support is the failure mode worth avoiding.
This is not SOC 2 or ISO 27001 certification, and I do not do either. HIPAA is a regulation with specific implementation specifications; those are attestations against criteria agreed with an auditor. Work done here supports them, but they are different purchases and you should buy them from somebody who does them.
What usually brings people here
An enterprise customer has sent a security questionnaire that asks who your security official is.
You are a business associate and a covered entity has started asking harder questions than the agreement did.
Something happened, it is contained, and the remediation record has to be written to a standard.
You have the tools but nobody can say what the program is or where it is documented.
How the engagement runs
This runs either as a fixed-price project that stands the program up, or as part of an ongoing fractional CISO arrangement where I hold the role.
The project version produces the risk analysis, the policy set, the access and vendor documentation, and a remediation plan for whatever the analysis surfaces. The ongoing version keeps all of it current, which is the part that decays fastest and the part an auditor checks.
This sits inside the fractional CISO side of the practice. If what you need is ongoing ownership rather than a defined piece of work, start there instead.
Questions I get asked first
Does HIPAA actually require a named security officer?
Yes. The Security Rule requires a covered entity or business associate to identify a security official responsible for developing and implementing its policies and procedures. It is one named person, not a committee and not a vendor, and the name is the first thing an auditor or an enterprise customer asks for.
Can our MSP be the security officer?
They can hold controls; they should not hold the role. A large part of the job is deciding what your providers must achieve and verifying that they did, which does not work when the provider is also the one being assessed. Most MSP contracts are uptime and support, and the Security Rule obligations sit outside them either way.
What does the risk analysis actually have to be?
An accurate and thorough assessment of the risks to electronic protected health information across everywhere it lives, moves and is backed up, with the reasoning written down. It is the control most often cited in enforcement, usually because what exists is a questionnaire somebody filled in once rather than an analysis anybody could defend.
We are a business associate, not a covered entity. Does this apply?
Yes. Business associates are directly liable for Security Rule compliance, not only through the agreement you signed. In practice your customers enforce it harder than anyone, because their diligence is what surfaces it.
Is this the same as SOC 2?
No, and I do not do SOC 2. HIPAA is a regulation with specific required and addressable implementation specifications; SOC 2 is an attestation against criteria chosen with an auditor. Work done for one supports the other, but they are not the same obligation and I would rather be clear about which one I am helping with.
Written on this
Start with a conversation
Tell me what’s going on. If this is the right piece of work I will scope it. If it is not, I will say what is.
Bring your FDA letter, pen test report, audit deadline, or security questionnaire.
Not ready for a call? Send a message instead.
For companies looking to engage BATO. Vendors, please email.