TL;DR
HIPAA is a US law about protected health information. It applies to your MVP if the product handles identifiable health data on behalf of a covered entity: a provider, a health plan, or a clearinghouse. If it does, every vendor that touches that data, including your development team, has to sign a business associate agreement, and the product has to meet a defined set of safeguards.
There is no HIPAA certification. Anyone selling you one is selling you a badge. What exists is a set of requirements, a risk analysis you have to actually do, and documentation that shows you did it.
Compliance adds 15 to 30 percent to an MVP build, almost all of it in infrastructure, access control, audit logging, and the paperwork. It does not change what the product does. It changes how carefully it does it.
What HIPAA-compliant app development actually means
HIPAA-compliant app development is not a different kind of engineering. It is ordinary product engineering with four things made non-negotiable: every access to health data is controlled and logged, the data is encrypted wherever it sits, every vendor in the chain has signed an agreement, and the decisions are written down.
A HIPAA-compliant MVP, then, is the smallest version of your product that meets those four conditions from its first day in front of a real patient record. Not a full product with compliance added. A minimal product with compliance built into the foundations, because the foundations are the expensive part to change later.
The rest of this post is what each of those four conditions requires, what it costs, and where founders get it wrong.
Does HIPAA apply to your MVP?
This is the first question and the one most founders get wrong in one of two directions: assuming it applies to anything health-adjacent, or assuming it does not apply to them because they are small.
The two-part test
HIPAA applies when both of these are true:
- The data is protected health information (PHI). Individually identifiable health information: a name plus a diagnosis, a date of birth plus a prescription, an email address plus an appointment. The identifier and the health fact together.
- You are a covered entity or a business associate of one. Covered entities are healthcare providers, health plans and clearinghouses. A business associate is anyone who handles PHI on a covered entity’s behalf. If a hospital, a clinic, an insurer or a telehealth provider is your customer and your product touches their patients’ data, you are a business associate.
Both. Not one.
Products that are usually in scope
- A telehealth platform used by licensed providers
- A patient portal, scheduling or intake tool sold to clinics
- A remote monitoring product that sends readings to a care team
- A billing or claims tool for practices
- An AI tool that reads clinical notes for a provider
Products that are often out of scope
- A consumer wellness app where the user enters their own data and no provider is involved
- A fitness tracker with no healthcare customer
- A mental health journaling app with no clinician on the other end
- A B2B tool that sells to providers but never touches patient data
The consumer case is the one that surprises founders. A meditation app that stores a user’s self-reported anxiety scores is not a HIPAA product, because no covered entity is involved. It has privacy obligations under state law and the FTC, which are real, but they are a different set.
When you are not sure
Ask one question: who is my customer, and do they have patients? If the answer involves a provider or a plan and your product sees their patients’ data, assume yes and plan for it. Our healthtech MVP guide covers the product side; this post is the compliance side.
The business associate agreement, and why it comes first
What a BAA is
A contract in which a vendor agrees to protect PHI to HIPAA’s standard, report breaches, and let you audit. Your customer, the covered entity, will require one from you. You in turn need one from every vendor that can see the data.
Who needs to sign one with you
Your development team, if they will ever handle real patient data. This is the question to ask before you hire anyone: will you sign a BAA? A team that hesitates has not done healthtech before. Ours signs one as standard, and the wider question of contracting with an offshore team as a US company is in our guide to hiring offshore developers.
Your cloud provider. AWS, Google Cloud and Azure all sign BAAs, but only for specific services on their HIPAA-eligible lists. Using a service that is not on the list means PHI in a place not covered by the agreement.
Every third-party service that sees PHI. Transactional email, SMS, error tracking, analytics, customer support tools, and, increasingly, AI model APIs. Each one either signs a BAA or does not touch PHI. Several popular services will not sign, which is why HIPAA products end up with a shorter, more deliberate vendor list.
The trick that avoids most of it
Build so that most vendors never see PHI. Analytics that receives event names and anonymous IDs does not need a BAA. Error tracking that scrubs request bodies does not either. Design the data flow so that PHI stays in the smallest possible circle, and the BAA list gets short.
Your development team can avoid being in scope entirely if they build and test against synthetic data and never touch production. That is also how a well-run team prefers to work.
What HIPAA actually requires of the product
The Security Rule sets out administrative, physical and technical safeguards. Here is what they mean for an MVP, in the order they cost money.
Access control
Every user has their own account. Roles restrict who sees what. A receptionist does not see clinical notes; a clinician does not see billing. Sessions time out. Passwords meet a standard, and multi-factor authentication is on for anyone with access to PHI.
This is ordinary good engineering, done without exception.
Audit logging
Every access to PHI is logged: who, what record, when, from where. The logs are retained, tamper-evident, and reviewable. Not “we log errors.” A record of every read.
This is the requirement that most often does not exist in a product built without HIPAA in mind, and retrofitting it is expensive.
Encryption
In transit, always, which every modern stack does. At rest, in the database, in backups, in file storage, which most stacks do if configured. Keys managed properly rather than sitting in the codebase.
Integrity and availability
Backups that are tested, not just taken. A plan for what happens when a server goes down. Data that cannot be silently altered.
The administrative side
A written risk analysis. Policies for access, incident response, and breach notification. Workforce training. A named person responsible. This is documentation, and it is where most founders fall behind, because none of it ships a feature.
What it does not require
A specific technology, a specific vendor, or a certificate. HIPAA is a set of outcomes and a requirement that you can show how you meet them. Two teams can meet it with completely different stacks. Our MVP tech stack recommendations work for HIPAA products with the configuration above.
What compliance adds to the build
Founders want a number. Here is the honest shape of one.
| Item | Adds to a standard MVP | Why |
|---|---|---|
| Access control and roles | 5 to 8 percent | Roles and MFA from day one, not bolted on |
| Audit logging | 5 to 10 percent | A read log is a feature nobody sees |
| HIPAA-eligible infrastructure | 2 to 5 percent | Configuration, encryption, key management |
| Vendor selection and BAAs | Time more than money | Fewer options, each one checked |
| Risk analysis and policies | $3k to $15k | Usually a consultant, once |
| Testing against synthetic data | 2 to 5 percent | Building the fake data set |
| Total | 15 to 30 percent | On the build, plus the documents |
On a $60,000 MVP that is $9,000 to $18,000 of engineering, plus the documentation. Set against the cost of a breach notification to every patient, or a customer’s security review finding no audit log, it is not the expensive option.
Where the money goes in a standard build is in what an MVP actually costs; the figures above are the delta.
What founders get wrong
Buying a certification
There is no HIPAA certification from any government body. There are consultants who will assess you and tools that will help you document, and both can be useful. A vendor promising to make you “HIPAA certified” is selling a badge that a customer’s lawyer will not recognize.
Assuming the cloud BAA covers everything
AWS signing a BAA does not make your architecture compliant. It covers the specific services on their eligible list, configured as they specify. PHI in a service not on the list, or in an eligible service configured wrongly, is outside the agreement.
Building first, complying later
Access control, audit logging and encryption at rest are cheap to build in on day one and expensive to add in month six. The retrofit usually gets discovered during a customer’s security review, which is the worst possible time. Scope it in from the start; the MVP scope discipline applies, with compliance as a non-negotiable line item.
Giving the development team real patient data
It puts them in scope for a BAA, it creates a breach risk that did not need to exist, and it is unnecessary. A synthetic data set with realistic edge cases serves development better than real data anyway, because it can include the cases that matter.
Treating the paperwork as optional
The risk analysis and the written policies are what an auditor or a customer asks for first. A product with perfect code and no risk analysis is non-compliant, and the customer’s security team will say so.
How this changes a build, week by week
A HIPAA MVP does not take twice as long. It takes a bit longer and starts differently.
Before week one: scope decision on what PHI the product touches, and design the data flow to keep it minimal. Vendor list drawn up against the BAA question. Synthetic data set specified.
Week one: infrastructure on HIPAA-eligible services, encryption configured, key management set up, audit logging framework in place before any feature is built on it.
Weeks two through six: the product, built with roles and access control as the default rather than an addition. Every feature that reads PHI writes to the audit log.
Final week: the documentation. Risk analysis, policies, the BAA list, the incident response plan. Often with a compliance consultant for a few days.
After launch: the review cycle. The risk analysis is not a one-time document; it is updated when the product changes.
This is the sequence we follow on healthtech MVP builds. The production-ready MVP standard covers most of the technical safeguards on its own; HIPAA adds the audit log, the vendor discipline and the documents.
HIPAA, SOC 2, and which one you need
Founders selling to healthcare often hear both. They are different things.
HIPAA is a law. It applies if you handle PHI for a covered entity, and you have no choice about it.
SOC 2 is a voluntary audit framework about your security controls generally. Enterprise customers ask for it in security reviews, and a hospital system may ask for both.
A healthtech startup usually needs HIPAA from day one and SOC 2 when the first enterprise deal requires it. Doing HIPAA properly gets you most of the way toward SOC 2’s security criteria, which is a good reason to do it properly. We cover the other one in SOC 2 for an MVP.
HIPAA vs HITRUST: when a hospital asks for HITRUST
The second acronym a healthtech founder hears, usually from a large health system’s vendor security team, is HITRUST. The two are not the same kind of thing, and confusing them costs either a deal or a very expensive certification nobody asked for.
HIPAA is a law. It applies to you if you handle protected health information for a covered entity, it has no certification, and there is no body that will stamp you “HIPAA compliant”. You are compliant when you meet the rule and can show it.
HITRUST is a certifiable framework, run by a private organisation (the HITRUST Alliance), that folds HIPAA’s requirements together with NIST, ISO 27001, PCI and others into one control set, then has an approved assessor verify you against it. It exists because large health systems got tired of reviewing every vendor’s homemade HIPAA programme and wanted one certificate they could accept instead.
The three levels, and which one a startup gets asked for
- HITRUST e1 (“essentials”): a small set of foundational controls, roughly forty, verified once, valid for a year. Reachable for a startup in a few months once the HIPAA work in this guide is done. Cost is in the same range as a SOC 2 Type 1.
- HITRUST i1 (“implemented”): a larger set, roughly 180 controls, one-year validity. Comparable in effort to a SOC 2 Type 2 plus a HIPAA programme.
- HITRUST r2 (“risk-based”): the full assessment, hundreds of controls tailored to your risk profile, a two-year certification with an interim check. This is what most people mean when they say “HITRUST certified”, it commonly costs a startup well into six figures once assessor fees, tooling and internal time are counted, and it takes the better part of a year. It is built for established vendors, not for a product with three pilots.
The decision
HIPAA first, because it is the law and you have no choice. SOC 2 second, when the first enterprise deal outside healthcare asks. HITRUST only when a specific contract requires it, and then at the lowest level the contract will accept: an e1 satisfies a surprising number of vendor security teams whose questionnaire says “HITRUST” without specifying, and an i1 satisfies most of the rest. Commit to an r2 only when a signed customer with real revenue makes it a condition, and price the certification into that deal. Whatever level they ask for, the same vendor team will also ask for the date of your last third-party penetration test; penetration testing vs vulnerability scanning covers when a startup needs one.
The build implication is the same one that runs through this whole guide: the technical safeguards you put into the MVP for HIPAA (access control, audit logging, encryption, environment separation) are the bulk of the HITRUST e1 control set. A product built HIPAA-ready is most of the way to an e1 before anyone has said the word. A product that bolted HIPAA on later will have to do the work twice.
Conclusion
HIPAA applies to your MVP if it handles identifiable health data on behalf of a provider, plan or clearinghouse. If it does, every vendor that touches the data signs a BAA, the product meets a defined set of safeguards, and you write the documents that show it. There is no certificate. There is a risk analysis you actually do.
It adds 15 to 30 percent to the build, almost all of it in things that are cheap on day one and expensive in month six. Build it in, keep PHI in the smallest circle possible, and give the development team synthetic data.
We sign a BAA as standard, build against synthetic data by default, and run the sequence above on every healthtech product. If you are not sure whether HIPAA applies to yours, that is the first question on the call. Start here.
*This post is general information for founders, not legal advice. HIPAA obligations depend on your specific facts, and state laws add requirements of their own. Confirm your position with a healthcare attorney before relying on any of it.*
Frequently Asked Questions
Does HIPAA apply to my MVP?
It applies if two things are true: the product handles protected health information, meaning identifiable health data, and you are a covered entity or handle that data on behalf of one, such as a provider, health plan or clearinghouse. A consumer wellness app with no provider involved is usually outside HIPAA, though other privacy laws apply. A tool sold to clinics that sees patient data is inside it.
What is a business associate agreement and who signs it?
A BAA is a contract in which a vendor agrees to protect PHI to HIPAA’s standard, report breaches, and allow audits. Your healthcare customer will require one from you. You need one from every vendor that can access PHI: your development team if they handle real data, your cloud provider, and any third-party service such as email, SMS, analytics or AI APIs that sees the data.
Can I get HIPAA certified?
No. There is no official HIPAA certification from any government body. Consultants can assess you and tools can help you document compliance, but any vendor promising to make you “HIPAA certified” is selling a badge that a customer’s legal team will not recognize. What exists is a set of requirements, a risk analysis, and documentation showing you meet them.
How much does HIPAA compliance add to an MVP build?
Typically 15 to 30 percent of the build, plus a few thousand dollars for the risk analysis and policy documents, usually with a consultant. The engineering cost sits in access control, audit logging, HIPAA-eligible infrastructure and building a synthetic test data set. On a $60,000 MVP that is roughly $9,000 to $18,000 of engineering.
Does my offshore development team need to sign a BAA?
Only if they will handle real protected health information. If they build and test against synthetic data and never access production, they are outside the chain. If they will touch real data, yes, they sign a BAA, and a team that hesitates to sign one has not built healthtech before. Ask on the first call.
Is AWS HIPAA compliant?
AWS will sign a BAA and offers a list of HIPAA-eligible services. Using AWS does not make your product compliant on its own. PHI must stay within eligible services, configured as AWS specifies, and the rest of the safeguards, including access control, audit logging and your documentation, are still your responsibility.
What are the technical requirements for a HIPAA compliant app?
Unique user accounts with role-based access and multi-factor authentication for anyone touching PHI. An audit log of every access to PHI: who, what, when, from where. Encryption in transit and at rest, with proper key management. Tested backups and an availability plan. Data integrity controls. Plus the administrative side: a written risk analysis, policies, training and a named responsible person.
Can I add HIPAA compliance after launching my MVP?
Technically yes, practically expensively. Audit logging and access control cost a few percent of the build to include from day one and far more to retrofit into a product built without them. The retrofit is usually discovered during a customer’s security review. If HIPAA applies, scope it in from the start.
What is the difference between HIPAA and SOC 2?
HIPAA is a US law that applies if you handle protected health information for a covered entity; you have no choice about it. SOC 2 is a voluntary audit framework about your security controls generally, which enterprise customers request in security reviews. A healthtech startup usually needs HIPAA from the start and SOC 2 when an enterprise deal requires it.
Does HIPAA apply to a wellness or mental health app?
Usually not, if the user enters their own data and no healthcare provider or plan is involved. The moment a licensed clinician is on the other end, or the app is sold to a provider who uses it with patients, it is likely in scope. Consumer health apps outside HIPAA still have obligations under state privacy laws and FTC rules, which are a separate set.
What is the difference between HIPAA and HITRUST?
HIPAA is a US law with no certification; you comply with it by meeting the rule. HITRUST is a private, certifiable framework that combines HIPAA with NIST, ISO 27001 and other standards and has an approved assessor verify you against it. Large health systems ask for HITRUST because it gives them one certificate instead of reviewing every vendor’s HIPAA programme. A healthtech startup needs HIPAA from day one and HITRUST only when a specific contract requires it, starting at the e1 or i1 level rather than the full r2.
