If you build software that handles patient data on behalf of a healthcare organization, you are a business associate under HIPAA, and the Security Rule applies to you directly. When you read it like a spec, one word trips almost everyone: addressable.
Every implementation specification in the HIPAA Security Rule is labeled either required or addressable. Engineers tend to map that onto required and optional. That mapping is wrong, and the gap between what people assume and what the rule says is where teams get caught in a customer security review.
What the two labels actually mean
Required is what it sounds like. You implement it. Encryption of ePHI at rest is a common example of the kind of control teams expect to be mandatory, though it is worth reading which specs carry which label rather than assuming.
Addressable is a decision procedure, not a permission slip. For an addressable specification you have to do three things: assess whether it is reasonable and appropriate for your environment, implement it if it is, and if it is not, document why and implement an equivalent alternative measure where one is reasonable. Skipping it silently is not one of the options.
So the honest translation of addressable is: "assess, decide, and write down your reasoning." A decision not to implement something is itself a deliverable. It is the artifact an auditor or a customer's security team asks for, and "we did not think we needed it" delivered verbally is not that artifact.
Why this bites during a customer review
Your healthcare customers are covered entities. Their own Security Risk Analysis is supposed to account for the vendors they send ePHI to, which means you. When their auditor pulls the thread on a third-party relationship, the questions land on you: which specifications did you treat as addressable, what did you decide, and where is the documentation.
A team that implemented reasonable controls but never recorded the addressable decisions looks, on paper, identical to a team that ignored them. The Security Rule is a documentation regime as much as a technical one. The reasoning is part of the deliverable, not a comment you can leave in a ticket.
A practical way to hold it
Treat the addressable specifications like architecture decision records. For each one, capture the specification, the assessment of your environment, the decision, and the alternative measure if you declined the default. Keep it with your Security Risk Analysis, not in a separate doc that goes stale. When a customer's reviewer asks, you produce a file instead of reconstructing a rationale from memory under time pressure.
The rule does not ask you to gold-plate. It asks you to decide deliberately and leave a record. That is a habit engineering teams already have. The Security Rule just wants it applied to the specifications it names, at 45 CFR §164.308, §164.310, and §164.312.
We work with business associates on exactly this, running a Security Risk Analysis that documents the required and addressable decisions in one place, starting at $499 and scaled to the organization. If you want a second read on how your controls map to the Security Rule before a customer does it for you, start a conversation with our team.
Top comments (0)