HIPAA for Startups: Minimum Viable Compliance

HIPAA for Startups: The Minimum Viable Program You Can Ship This Quarter

TL;DR

• A startup that creates, receives, maintains, or transmits PHI on behalf of a Covered Entity is a Business Associate and must comply with the HIPAA Security Rule (45 CFR §164.308, 164.310, 164.312) and Privacy Rule (45 CFR §164.502).
• The non-negotiable foundation is a documented risk analysis. This is the first thing OCR asks for in an investigation.
• Every vendor, cloud account, and SaaS tool that touches PHI must have a signed BAA (45 CFR §164.504(e)).
• Encryption in transit (TLS 1.2+) and at rest (AES-256 or equivalent) is addressable under the regulation, but no BAA review will pass without it.
• A breach affecting any number of individuals triggers written notification to affected parties within 60 days of discovery (45 CFR §164.404).

Who This Is For

This article is for technical founders and early engineering leads at startups that sell software to hospitals, clinics, telehealth providers, payers, or any other HIPAA Covered Entity. If a customer has asked you to sign a BAA, or procurement has sent you a security questionnaire that mentions HIPAA, this is your starting point.

If you are building a consumer wellness app with no Covered Entity data flows, or if your data is fully de-identified under the 18-identifier Safe Harbor method in 45 CFR §164.514, HIPAA does not apply to you yet. The moment you receive identifiable patient data from a healthcare provider or payer, it does.

This guide focuses on what you must have to ship and sign deals today. For the full readiness plan, see our companion article on HIPAA compliance for SaaS startups.

What "HIPAA Compliance" Actually Means for a Startup

There is no government-issued HIPAA certification. The U.S. Department of Health and Human Services Office for Civil Rights (HHS OCR) enforces the rules and investigates complaints and breaches. Compliance is demonstrated through a documented program that satisfies three rules:

• Privacy Rule, controls on who can use and disclose PHI (45 CFR Part 164, Subpart E)
• Security Rule, administrative, physical, and technical safeguards for electronic PHI
• Breach Notification Rule, notice requirements when PHI is improperly accessed or disclosed

For a startup, the minimum viable program is built around six pieces. Each maps directly to a regulatory requirement.

The Six-Piece Minimum Viable Program

1. Signed BAAs With Every Vendor That Touches PHI

A Business Associate Agreement is a written contract specifying how a vendor may use PHI, requiring safeguards, and obligating breach reporting. The required elements of a BAA are defined in 45 CFR §164.504(e). Under the regulation, a BAA must:

• Establish the permitted and required uses and disclosures of PHI
• Require the business associate to implement safeguards and comply with the Security Rule for electronic PHI
• Require the business associate to report breaches of unsecured PHI to the covered entity
• Require subcontractors to agree to the same restrictions
• Provide for return or destruction of PHI when the contract ends

These are the statutory minimums from 45 CFR §164.504(e)(2). In practice, enterprise BAAs layer additional requirements on top: specific breach notification timelines shorter than the statutory 60-day window, indemnification carve-outs, audit rights clauses, and survival terms governing what happens to PHI if the contract terminates mid-year. The statutory list above is the floor; what a hospital procurement team sends you will be the ceiling.

In practice: AWS, Google Cloud, and Microsoft Azure each offer HIPAA-eligible services and publish their own BAA templates. Sign theirs. For other SaaS tools (Slack, GitHub, analytics platforms, support software), check the vendor's trust portal. If a vendor cannot provide a BAA and the tool receives PHI, do not send it PHI.

Most enterprise healthcare buyers will send you their BAA to sign, not the other way around. Review every incoming BAA with counsel. Audit rights, indemnification floors, and data return timelines vary widely.

What this means for your situation: When a covered entity sends you a BAA, three provisions carry the most operational weight for a startup: (1) the audit rights clause, some covered entities reserve the right to audit your security controls on notice periods as short as 5 business days, which can be disruptive if you are not prepared; (2) the indemnification clause, a broad indemnification that covers the covered entity's regulatory fines (OCR civil money penalties) is a material liability you are accepting, and these fines can reach $1,919,173 per violation category per year (the inflation-adjusted annual cap under 42 U.S.C. § 1320d-5, as updated by HHS in the Federal Register); (3) the data return or destruction timeline on termination, some enterprise BAAs require certified destruction within 30 days of contract end, which requires an operational process for purging ePHI from backups and audit logs across every vendor in your stack. Identifying these clauses before signing and flagging them for legal review is faster and cheaper than discovering them after an incident.

See our full walkthrough of HIPAA business associate agreements for the clauses that matter most.

2. A Documented Risk Analysis

The risk analysis requirement in 45 CFR §164.308(a)(1) is the most consistently cited deficiency in OCR enforcement actions (confirmed by HHS OCR enforcement highlights, which show risk analysis as the predominant cited failure across settled cases). The regulation calls for "an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information."

For a startup, a defensible risk analysis fits in a spreadsheet or lightweight GRC tool and contains:

• A current inventory of every system that holds or processes ePHI: cloud provider accounts, managed databases, SaaS tools, internal apps, developer laptops
• A threat and vulnerability catalog per asset
• Likelihood and impact ratings for each risk
• The control implemented to address the risk, or a documented risk acceptance decision
• A review schedule (quarterly is the practitioner standard at the startup stage, the regulation says "periodic," which is undefined; quarterly is the cadence most BAA auditors expect)

HHS publishes a free Security Risk Assessment (SRA) Tool, available at hhs.gov/hipaa/for-professionals/security/guidance/security-risk-assessment-tool. It is designed for small and medium healthcare organizations and small business associates. Use it.

The SRA Tool output is sufficient for early-stage startups. As you grow past 50 employees or add multiple product lines, a GRC platform gives you better audit trails. (The 50-employee threshold is a practitioner rule of thumb, not a regulatory trigger, the real driver is audit trail complexity, not headcount.)

3. Written Policies That Describe What Your Team Does

The Security Rule requires written policies covering specific areas. Under 45 CFR §164.308 and 164.316, required policy areas include:

• Access authorization and management (who can access what PHI, how it is granted and revoked)
• Information system activity review (audit log monitoring procedures)
• Security awareness and training (including periodic updates, malicious software detection, password management)
• Incident response procedures
• Contingency planning (data backup, disaster recovery, emergency access)
• Evaluation (periodic review of the security program)
• Device and media controls

These do not need to be long. A policy that describes what the team actually does and is reviewed annually is more defensible than a 50-page document that does not match practice. Keep each policy focused on a single topic.

Under 45 CFR §164.310, physical safeguard policies are also required: workstation use rules, device disposal procedures, and media re-use procedures. For a cloud-native startup with no physical servers, the device and laptop policies cover most of this.

4. Encryption in Transit and at Rest

Under 45 CFR §164.312(a)(2)(iv), encryption for stored ePHI is classified as "addressable," meaning it must be implemented unless the entity documents a specific reason why it is not reasonable and appropriate and implements an equivalent alternative. For any startup seeking to sign BAAs with healthcare enterprises, "addressable" means "do it."

Under 45 CFR §164.312(e)(2)(ii), encryption for ePHI in transit carries the same addressable classification.

In practice, verify:

• Managed databases (RDS, Cloud SQL, Aurora) have encryption at rest enabled, this is the default on major cloud providers but confirm it in your account settings
• S3 buckets or equivalent object storage have default encryption enabled and no public access permissions
• Backups are encrypted with access-controlled keys
• All internal and external API endpoints use TLS 1.2 or higher; TLS 1.0 and 1.1 should be disabled
• Employee laptops use full-disk encryption (FileVault on macOS, BitLocker on Windows)

5. Access Controls With Unique User IDs and MFA

45 CFR §164.312(a)(2)(i) requires assigning a unique name or number to each user for tracking. 45 CFR §164.312(d) requires procedures to verify that a person seeking access to ePHI is who they claim to be. Multi-factor authentication is the standard implementation of that requirement.

Minimum access controls for a startup:

• Single sign-on as the identity provider. All production systems authenticate through one IdP (Google Workspace, Okta, Microsoft Entra, or equivalent). No shared passwords or service accounts used by humans.
• MFA enforced across all production systems. This includes cloud consoles, code repositories, and any SaaS tool that can reach PHI.
• Least-privilege access. Engineers do not have standing access to production PHI in bulk. Access is scoped to what each role requires.
• Quarterly access reviews. A list of who has access to what, reviewed by a manager, with sign-off. This is the documentation an auditor or BAA review will ask for.
• Immediate offboarding. A written checklist to deactivate access when a workforce member leaves.

45 CFR §164.308(a)(3) covers workforce security, including procedures for authorizing and supervising access. Your onboarding and offboarding checklists satisfy this requirement.

6. Breach Notification Procedures

45 CFR §164.404 requires covered entities (and business associates by extension, via BAA) to notify individuals of a breach of unsecured PHI. The timeline is notification "without unreasonable delay and in no case later than 60 calendar days after discovery."

Notification must include a description of what happened, the types of PHI involved, steps individuals should take to protect themselves, what you are doing in response, and contact information.

For breaches affecting 500 or more individuals, HHS requires concurrent notification to the media in the affected geographic area and immediate submission to the HHS breach notification portal. Breaches affecting fewer than 500 individuals can be logged and submitted to HHS annually, no later than 60 days after the end of the calendar year.

Your breach response procedures need to address:

• How you detect and confirm a breach (incident response plan)
• The 4-factor harm assessment for determining whether a breach notification is required (nature of PHI, who accessed it, whether it was actually acquired, extent to which risk has been mitigated)
• Who prepares the notice (legal counsel should review before any notice goes out)
• How you log breach events and submission dates for the HHS annual log

What this means for your situation, state law overlays: The 60-day HIPAA timeline is a federal floor, not a ceiling. Multiple states impose stricter requirements that apply independently and concurrently. California's Confidentiality of Medical Information Act (CMIA) imposes stricter notification obligations than HIPAA's 60-day window. Licensed healthcare facilities in California must notify patients within 15 business days of detecting a breach under California Health and Safety Code §1280.15. For contractors and business associates operating under the CMIA (Civil Code §56.101), the obligation is to notify "without delay" consistent with applicable breach notification requirements. The practical result is that any CMIA-covered entity or contractor with California data subjects should build its incident response plan around a timeline significantly shorter than 60 days; consult counsel on the specific timeline that applies to your entity type. New York's SHIELD Act and Texas's Health & Safety Code §181.154 impose their own notification obligations for health data breaches. If your startup has users or data subjects in any of these states, the state law deadline will govern in practice because it is the shorter of the two. Build your incident response plan around the shortest applicable deadline in your customer base, not HIPAA's federal ceiling. A startup with customers across multiple states should map state breach notification requirements at the same time it builds its HIPAA breach log, they share the same underlying incident facts and can largely be handled in one process with legal counsel reviewing jurisdiction-specific notice requirements for each event.

What You Can Responsibly Defer

These items are real HIPAA requirements, but they are not what will block a deal or trigger enforcement at the startup stage:

A dedicated full-time Compliance Officer. A named, accountable individual with authority to enforce the program is required. At the startup stage, a technical co-founder or head of engineering can fill this role. HIPAA does not specify a minimum FTE level.

Penetration testing on a six-month cycle. Annual testing is the practitioner norm for most startup-stage BAAs, six-month cadences appear in enterprise BAAs but are typically a negotiated requirement, not a default expectation at the seed or Series A stage. Our pen testing vs vulnerability assessment guide explains what each contract type requires.

ISO 27001 or full NIST 800-53 mapping. SOC 2 Type II with a HIPAA overlay is what most enterprise healthcare buyers request. You do not need ISO 27001 to close deals.

A 24/7 security operations function. Documented business-hours incident response with a clear escalation path is acceptable at the startup stage. Buyers know you are small; they want to see that someone is accountable, not that you have a staff of analysts.

The guiding principle: build what the law requires and what your actual customer contracts require. Do not build what enterprise competitors have if it is not yet in your contracts.

The Sequencing That Works

Build in this order. Each step creates input for the next.

Week 1-2: Data flow mapping. Map every place ePHI enters, moves through, and exits your systems. This becomes your asset inventory for the risk analysis. Identify every vendor that touches PHI and check each for a BAA.

Week 3-4: Risk analysis. Run the HHS SRA Tool against your asset inventory. Document every gap. This output drives your control implementation list.

Week 5-8: Close highest-risk gaps. Typical priorities in this order: MFA enforcement, encryption at rest verification, BAA execution with all active vendors, and incident response plan drafted.

Week 9-12: Write the policies. Seven core policies (access control, audit log review, workforce training, incident response, contingency plan, device/media controls, sanctions) plus a BAA template. Put everything in version-controlled storage.

Week 13-16: Workforce rollout. Train every employee with PHI access. Record completion. Schedule the first quarterly review.

This order avoids the common mistake of buying a compliance tool first and then mapping its requirements to your environment. The risk analysis tells you what you actually need; the tool should support that program, not define it.

30-Day MVP Checklist

Use this to track your first sprint from zero to a defensible program. Each item maps to a specific regulatory requirement.

Mini-FAQ

Can a startup sign a BAA without having a full program behind it?

Technically yes, but it creates significant liability. A signed BAA is a contract in which you represent that you will implement appropriate safeguards. Signing one without a functioning program means you have documented your acceptance of obligations you cannot fulfill. In an enforcement action, that is worse than having no BAA at all. Build the minimum program first.

Is encryption "required" or just "addressable" under HIPAA?

Both the stored ePHI encryption standard (164.312(a)(2)(iv)) and the transmission security encryption standard (164.312(e)(2)(ii)) are classified as "addressable." Addressable means you must either implement the specification or document why it is not reasonable and appropriate and implement an equivalent alternative. In practice, any healthcare enterprise buyer will verify encryption before signing a BAA. Document that you have implemented it.

Does HIPAA apply if our customers are healthcare companies but we only see metadata?

If the metadata can identify an individual's health status or be combined with other information to do so, it is likely PHI. The de-identification standard under 45 CFR §164.514 requires removing 18 specific identifiers and having no actual knowledge that the remaining data could re-identify anyone. If you have not formally applied either the Safe Harbor or Expert Determination method to your data, treat it as PHI.

How long does the minimum viable program take to build?

A focused startup with a single product and cloud-native infrastructure can reach a defensible first-generation program in 8 to 16 weeks (practitioner estimate, no regulatory timeline exists for standing up a program). The primary variable is how much PHI is already flowing through systems that do not yet have BAAs. Retroactive vendor BAA execution and policy documentation are typically the longest steps.

Do we need HIPAA and SOC 2?

If you sell to healthcare customers, expect to need both. Enterprise healthcare buyers typically require a BAA (HIPAA) and a SOC 2 Type II report. A unified compliance program maps controls to both frameworks simultaneously, which is more efficient than treating them as separate tracks. See our HIPAA compliance for SaaS startups guide for the control overlap.

Sources used

1. 45 CFR §164.308, accessed 2026-05-12
2. 164.310, accessed 2026-05-12
3. 164.312, accessed 2026-05-12
4. 45 CFR §164.502, accessed 2026-05-12
5. 45 CFR §164.504(e), accessed 2026-05-12
6. 45 CFR §164.404, accessed 2026-05-12
7. 45 CFR §164.514, accessed 2026-05-12
8. HHS OCR, accessed 2026-05-12
9. 45 CFR Part 164, Subpart E, accessed 2026-05-12
10. hhs.gov/hipaa/for-professionals/security/guidance/security-risk-assessment-tool, accessed 2026-05-12
11. 164.316, accessed 2026-05-12
12. 42 U.S.C. § 1320d-5, HIPAA civil money penalties, accessed 2026-05-12
13. HHS Federal Register, Civil Monetary Penalties Inflation Adjustments (Jan 2023), accessed 2026-05-12
14. HHS OCR Enforcement Highlights, accessed 2026-05-12

Last reviewed: 2026-05-12. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.