If you are a healthcare company CEO researching HIPAA for the first time, you have probably already seen the word “certified” attached to it somewhere: a vendor’s marketing page, a competitor’s website, maybe a sales engineer on a call last week. That word is doing a lot of misleading work. HIPAA is not something you get certified in. It is a federal law, and understanding that distinction changes almost every decision you will make about your infrastructure, your vendor contracts, and your timeline.
This guide covers what HIPAA actually is, whether it applies to your company at all, what it requires in plain terms, and what changes once you decide to run PHI-touching workloads on AWS. None of it requires a law degree to follow, and most of it comes down to documentation discipline more than exotic security engineering.
HIPAA Was Never Built to Be a Certification
The Health Insurance Portability and Accountability Act became law in 1996. It splits into three operational rules that matter to you: the Privacy Rule, which governs how protected health information (PHI) can be used and disclosed, the Security Rule, which sets safeguards for electronic PHI specifically, and the Breach Notification Rule, which sets the clock on what happens after something goes wrong. There is no fourth rule that hands you a certificate.
No government agency issues a HIPAA compliance certificate. No auditor signs off and gives you a report to forward to prospects. There is no passing grade. What exists instead is an enforcement body, the Department of Health and Human Services’ Office for Civil Rights (OCR), that investigates after a breach report or a complaint and decides whether your safeguards held up.
That enforcement is not theoretical. OCR resolved 21 settlements and civil monetary penalties in 2025, the second highest annual total on record, collecting $8,330,066 in the process, and the deficiency that keeps showing up across nearly every one of those cases is the same: an incomplete or missing risk analysis. Not a missing firewall. Not an unencrypted database, though that shows up too. A missing risk analysis, meaning the organization never sat down and documented where its ePHI lives, what threatens it, and what it did about that.
This matters for how you plan. You are not working toward an exam date. You are building a posture you have to be able to defend if OCR ever asks, which could be next month or five years from now, triggered by a breach, a patient complaint, or an audit of a business partner.
It also changes what “we are HIPAA compliant” should mean inside your own company. It is not a status you flip on after a project sprint. It is an ongoing claim about your current systems, your current vendors, and your current documentation, and it needs to stay true continuously, not just on the day a prospect asks for it in a security questionnaire.
The Question That Actually Matters: Covered Entity or Business Associate
Before you spend a dollar on infrastructure changes, answer one question honestly: are you a covered entity, a business associate, or neither?
A covered entity is a healthcare provider, health plan, or healthcare clearinghouse. Most healthtech startups are not this. A business associate is any company that creates, receives, maintains, or transmits PHI on behalf of a covered entity. This is the category almost every B2B healthtech startup falls into, and it catches founders in both directions.
Some founders assume HIPAA does not apply to them because they think of themselves as a software company, not a healthcare company. That framing does not matter to OCR. The moment your product processes patient data for a hospital, clinic, health plan, or another covered entity, you are a business associate, and you are required to sign a Business Associate Agreement (BAA) with that customer before any PHI moves. Signing that first hospital system deal is often the exact moment startups discover they were not ready.
The reverse mistake happens too. A direct-to-consumer wellness app used outside a covered entity relationship may fall outside HIPAA scope entirely, even though it deals with health-adjacent data, though other privacy laws can still apply. Assuming HIPAA automatically covers anything with a health angle leads teams to over-build a compliance program for a product that does not need one, and under-build the actual product.
Run this check before your first PHI-touching contract, not after:
| If your product… | You are likely a… | What that triggers |
|---|---|---|
| Stores, processes, or transmits PHI on behalf of a hospital, clinic, payer, or other covered entity | Business associate | BAA required before any PHI moves, full Security Rule obligations apply |
| Sells directly to consumers with no covered entity in the data path | Likely outside HIPAA scope | Other privacy laws may still apply (state health data laws, FTC Act) |
| Is itself a healthcare provider billing electronically | Covered entity | Full HIPAA obligations, plus you now need BAAs with your own vendors |
Get this determination wrong in a due diligence call with an enterprise health system and it stalls the deal. Get it wrong internally and you either burn engineering time on compliance you do not need, or ship a product that is not ready for the data it is about to receive.
What HIPAA Actually Requires
Once you know you are in scope, the three rules translate into concrete obligations. Here is what each one means in practice, not in statute language.
The Privacy Rule
The Privacy Rule governs who can see PHI and why. It gives patients rights: to access their own records, to request corrections, to get an accounting of who their data was disclosed to. For a startup, the practical implication is usually about your product’s access model. If a support engineer can pull up any patient’s record without a documented, role-based reason tied to that patient’s care or your contract with the covered entity, that access itself can become a Privacy Rule problem, independent of whether any data actually leaked.
The Security Rule
The Security Rule is where your engineering team lives. It groups safeguards into three categories: administrative (policies, workforce training, designated security officer), physical (facility access, device controls, this mostly resolves itself once you are running on a cloud provider), and technical (encryption, access control, audit logging, transmission security). All three sit on top of one foundational obligation: a documented, thorough risk analysis that identifies where ePHI lives, what could compromise it, and what you have done to reduce that risk. Everything else gets evaluated against whether it addresses risks your analysis actually found. Skipping the analysis and jumping straight to “we encrypt everything” is backwards from how OCR evaluates you, and it is also how teams end up over-engineering controls for risks that were never actually present in their architecture.
The Breach Notification Rule
This rule sets deadlines. If ePHI is compromised, you generally have 60 days to notify affected individuals, and covered entities must notify HHS, with additional media notification requirements for breaches affecting more than 500 people. The consequences of getting this wrong are not abstract. OCR’s April 2026 settlement with Star Group’s self-funded health plan followed a ransomware attack, and the finding was not a sophisticated failure: the plan had not identified where its own electronic health data was stored and had no documented risk analysis process at all. A $245,000 settlement followed. The technology failure was almost secondary to the documentation failure.
Eligible on AWS Doesn’t Mean Compliant
If you already run on AWS, the infrastructure conversation starts with two things: the Business Associate Addendum and the HIPAA eligible services list. Neither one alone gets you to HIPAA-compliant AWS infrastructure, and conflating the two is where most engineering teams lose time.
AWS will sign a Business Associate Addendum with you, accepted self-service through AWS Artifact in the console. Once accepted, it covers every AWS service on AWS’s published HIPAA Eligible Services Reference, a list that now runs past 150 services, including foundational components like Amazon Bedrock and Amazon Bedrock AgentCore. That list updates roughly monthly, so treat it as something you check before deploying anything new into a PHI-touching account, not something you memorize once.
Two myths worth killing early. First, dedicated tenancy: AWS removed the dedicated tenancy requirement for HIPAA workloads back in 2017, so standard shared tenancy EC2 instances are fully eligible. Teams still budget for dedicated hosts assuming HIPAA requires it, and that assumption costs real money for no compliance benefit. Second, eligibility itself: a service being on the list means AWS will cover it under the BAA if PHI touches it. It does not mean your specific deployment is configured correctly. You still own encryption at rest and in transit, IAM access control scoped to least privilege, audit logging through CloudTrail, and log retention for six years under 45 CFR 164.316(b)(2)(i). That is the actual work of building HIPAA-compliant AWS infrastructure, and none of it happens automatically because you accepted a BAA.
The mistake I see most often has nothing to do with EC2 or S3. It is the analytics stack. A team gets HIPAA-compliant AWS infrastructure right for the core application, then wires up Segment, Sentry, Intercom, or Mixpanel for product analytics or support tooling, and PHI ends up in event payloads flowing to a vendor that never signed a BAA. None of those tools are on the AWS eligible list because they are not AWS services, and none of them are automatically covered by anything you did on AWS. Every third-party tool that touches your application needs its own BAA check before it goes near production data, full stop.
The Rule You’re Building Against Might Not Be Final
One thing worth knowing before you lock in a compliance roadmap: the Security Rule itself is mid-revision. HHS published a Notice of Proposed Rulemaking in January 2025 aimed at the first major update to the Security Rule since 2013, covering mandatory encryption, required multi-factor authentication for ePHI access, and network segmentation requirements that do not explicitly exist in the current rule. It has not been finalized. HHS’s most recent Unified Agenda moved the proposal to its Long Term Actions list and now targets July 2027 for final action, slipping from an earlier spring 2026 target, and that date is not binding either.
Until it finalizes, the current 2013 Security Rule remains the one OCR enforces, in full. But AWS is not waiting for finalization to publish guidance. Its July 2026 implementation guide for HIPAA Security Rule technical safeguards already maps out how to meet the proposed changes, encryption, MFA, segmentation, on top of what the current rule requires.
For a growth stage company building now, the practical move is to build toward that direction rather than the bare minimum of the current rule. Multi-factor authentication for anyone touching ePHI, network segmentation between PHI and non-PHI workloads, and encryption without exceptions are all things a reasonable security program should already have. Building them in now means the eventual final rule, whenever it lands, is a documentation update rather than a re-architecture.
None of this needs to happen in one sprint, and it does not need to happen before you sign your first healthcare customer either. It needs to happen in the right order: confirm your business associate status, run the risk analysis, put safeguards in place against what that analysis actually found, and treat your AWS BAA and eligible services list as the starting point for infrastructure decisions rather than the finish line for compliance ones.