HIPAA Security Rule Obligations for Technology Vendors

A technology company handling health data on behalf of a hospital, insurer, or clinic is almost certainly a business associate, and business associates carry direct obligations under the HIPAA Security Rule. Not obligations that flow through a customer contract. Direct statutory obligations, enforceable against you, with civil penalties attached.

This surprises vendors regularly, and the surprise usually arrives at the worst moment: during a customer’s security review, or after an incident.

Whether you are a business associate

A business associate is a person or entity that creates, receives, maintains, or transmits protected health information on behalf of a covered entity, in order to perform a function or activity regulated by HIPAA.

Two parts of that definition do a lot of work. "Maintains" means storage counts even without access: a hosting or backup provider holding encrypted PHI is a business associate, and the conduit exception is narrow, covering transmission services rather than storage. And obligations flow down, so a subcontractor that handles PHI on behalf of a business associate is itself a business associate with its own direct obligations.

A business associate agreement is required, and it is a contract rather than a compliance programme. Signing one does not make you compliant, and lacking one does not exempt you. Vendors sometimes treat the executed BAA as the deliverable. It is the beginning of the obligation, not the satisfaction of it.

What the Security Rule actually requires

The Security Rule applies specifically to electronic protected health information and is organised into administrative, physical, and technical safeguards. It is deliberately technology-neutral and scalable, which is both its strength and the source of most confusion about it.

Within the safeguards, implementation specifications are designated either required or addressable. Addressable does not mean optional, and this is the most consequential misreading in the entire rule. For an addressable specification you must assess whether it is reasonable and appropriate in your environment, and then either implement it, or implement an equivalent alternative measure and document why. What you cannot do is skip it silently. An undocumented decision not to implement an addressable specification is a finding.

The obligations that most often go unmet at technology vendors are these:

• ·A risk analysis. An accurate and thorough assessment of risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI you hold. This is the foundational requirement, it is the most frequently cited failure in enforcement actions, and a vulnerability scan is not a substitute for it.
• ·Risk management. Implementing measures sufficient to reduce identified risks to a reasonable and appropriate level. The risk analysis has to lead somewhere.
• ·Workforce security and access management, including granting access appropriately and terminating it promptly.
• ·Audit controls. Mechanisms recording and examining activity in systems containing ePHI.
• ·Contingency planning, including data backup, disaster recovery, and emergency mode operation.
• ·Evaluation. Periodic reassessment of whether your safeguards still meet the rule as your systems change.

The risk analysis point deserves repeating because it is where enforcement concentrates. It must cover all ePHI you create, receive, maintain, or transmit, wherever it lives. Analyses scoped to a single production system while ePHI sits in logs, backups, analytics pipelines, and support tooling are common and do not hold up.

Breach notification

Business associates have obligations under the Breach Notification Rule as well, and the deadlines are short. Following discovery of a breach of unsecured PHI, a business associate must notify the covered entity without unreasonable delay and in no case later than 60 days.

A breach is presumed unless you can demonstrate through a documented risk assessment that there is a low probability the PHI has been compromised. The burden sits with you, which means the assessment has to be performed and recorded, not assumed. Your BAA may impose shorter notification deadlines than the regulation, and most customer-drafted agreements do.

The proposed update, and its actual status

The Office for Civil Rights published a notice of proposed rulemaking on 6 January 2025 proposing the first substantial revision to the Security Rule in over two decades. The comment period closed on 7 March 2025 and drew several thousand comments.

The proposal is significant in ambition. Among other things it would remove the distinction between required and addressable implementation specifications, making the specifications mandatory, and would introduce explicit technical requirements including multi-factor authentication, encryption of ePHI at rest and in transit, network segmentation, and asset inventory and network mapping.

It has not been finalised. As of mid-2026 it remains a proposed rule, and HHS has moved it to its long-term actions agenda with anticipated final action indicated for 2027. Any published timeline for this rule should be treated as provisional.

Two conclusions follow, and they point in the same direction. The existing Security Rule remains fully in force and fully enforceable today, so nothing about the proposal defers a current obligation. And the direction of travel is clear enough that a vendor building its programme now would be unwise to design around addressable specifications it intends to skip, because the proposal’s central move is to remove that flexibility.

What to do about it

Start with data. Establish where ePHI actually is across your environment, including the places it arrives incidentally: application logs, error reporting, analytics, support tickets, developer environments seeded from production. Most vendors underestimate this materially, and every subsequent obligation depends on getting it right.

Then perform a real risk analysis against that inventory, and let it drive a remediation plan with owners and dates. Then close the addressable specifications explicitly, recording the decision and reasoning for each. Then keep the whole thing current, because the evaluation requirement is continuous and because your systems will change faster than any annual review can track.

If your customers are also asking for SOC 2, which is common for vendors in healthcare, note that a great deal of the underlying evidence serves both. The framing differs and the audiences differ, but access control, audit logging, incident response, and vendor management are the same controls proving themselves twice.

Enforcement is real, and it reaches vendors

Civil monetary penalties are tiered by culpability, running from violations where the entity did not know and could not reasonably have known, through reasonable cause, up to wilful neglect. The top tier applies where a violation was due to wilful neglect and was not corrected, and the annual caps for identical violations are substantial. Amounts are adjusted for inflation periodically, so any figure you read should be checked against the current adjusted schedule rather than quoted from an older article.

Two features of enforcement matter more to a vendor than the numbers. Resolution agreements typically include a corrective action plan with monitoring for a period of years, which is a heavier operational burden than the payment. And OCR enforcement actions against business associates have made clear that the direct liability created by the HITECH Act is exercised, not theoretical.

The other exposure is commercial. Your BAA almost certainly contains indemnification, and a breach caused by your failure flows back to you contractually regardless of what any regulator does. For most technology vendors the customer contract is the sharper end of the risk.

Where the Security Rule stops

Vendors sometimes treat HIPAA as a single undifferentiated obligation. It helps to know which parts apply to you and which do not.

The Security Rule, which is where most of your engineering obligation sits, applies to electronic PHI only. Paper records fall under the Privacy Rule, not this one.

The Privacy Rule applies to business associates only in part. You are bound by the uses and disclosures permitted in your BAA, and you are subject to the minimum necessary standard, meaning you should request, use, and disclose only the minimum PHI needed for the purpose. You are not subject to the full set of covered entity obligations such as the notice of privacy practices.

That minimum necessary point has a practical engineering consequence that vendors regularly miss. Pulling an entire patient record when a feature needs two fields is a compliance question, not just an architectural preference, and it is one that shows up in customer security reviews.

Our HIPAA overview sets out what we maintain for technology vendors carrying business associate obligations.