HIPAA for Startups: What Your BAA Actually Requires You to Do

Key Takeaways

• A BAA is a contract documenting your promise to implement safeguards.
• Your cloud provider's BAA covers the cloud provider's ePHI obligations. Your application layer, workforce, risk analysis, and incident response remain your responsibility.
• HIPAA compliance breaks down into technical, process, and people controls.
• The 2025 notice of proposed rulemaking (NPRM) would eliminate the Required/Addressable distinction with limited exceptions. Encryption at rest, multi-factor authentication (MFA), and annual compliance audits would become mandatory. Build toward these now.

A healthcare customer sends over a Business Associate Agreement (BAA) with a 30-day deadline. Many startups sign it, then start working on the security controls the BAA assumed were already running. The trouble shows up months later, when a breach notification goes out to the same customer and ends the relationship.

Signing a BAA, writing policies, and documenting a risk assessment are achievable paper tasks. Deploying encryption on every device, getting Endpoint Detection and Response (EDR) on the full fleet, and putting MFA on every account is where startups stall. Those controls also have to stay running between audits, because device encryption, EDR coverage, MFA, and audit logging drift the moment process and people scaffolding lapses.

A BAA is a contract. When you sign one, you're promising the covered entity that you'll implement the safeguards listed in the Department of Health and Human Services' (HHS) sample provisions, but the actual technical requirements live in the HIPAA Security Rule at 45 CFR § 164.312. Since the HITECH Act, business associates have been directly liable for violations of that rule, and OCR can investigate your organization without going through the covered entity.

Sign your next BAA without holding your breath. Get a quote from Zip and close the gap between what your BAA assumes and what's running.

Your Cloud Provider's BAA Isn't Enough

Startups handling electronic Protected Health Information (ePHI) often sign their cloud provider's BAA and assume HIPAA is handled. AWS, Google Cloud, and Microsoft Azure all offer BAAs, but each one only covers the cloud provider's own ePHI obligations as a business associate to you. Your application, your workforce, and your operations remain your responsibility.

HHS cloud guidance makes the scope clear: a cloud service provider (CSP)'s BAA establishes the CSP's permitted uses and disclosures of ePHI and required safeguards, while the covered entity or business associate customer retains its own HIPAA responsibilities. Your application layer, workforce access policies, risk analysis, incident response procedures, and security awareness training remain your responsibility, and they break into three categories of safeguards that any HIPAA program has to cover. Both covered entities and business associates must conduct their own risk analyses for all ePHI they create, receive, maintain, or transmit.

Three Classes of Safeguards, Starting With Technical

Every compliance standard, including HIPAA, SOC 2, ISO 27001, and GDPR, breaks into three classes of safeguards organizations need to build. A practical operating model separates tool-enforced controls from workflow and workforce controls:

Safeguard type	Typical scope
Technical	Encryption, MFA, device management, endpoint controls, audit logging
Process	Documented workflows, change control, review gates, incident response, risk analysis
People	Background checks, training, role-based access definitions, offboarding procedures

This split maps requirements to tooling, operations, and workforce management.

HIPAA's Security Rule encodes this split directly: § 164.308 covers administrative safeguards (process), § 164.310 covers physical safeguards, and § 164.312 covers technical safeguards.

Most startups can deploy the technical class with the right tooling. Zip is one option for the technical class. Process and people work stays with whoever owns the program: a vCISO, an MSP, or an internal lead. The harder long-term failure mode is the process and people scaffolding that keeps those controls running between reviews and as the team grows. Recent OCR enforcement actions and OCR's Risk Analysis Initiative show recurring attention to risk analysis, with enforcement also addressing access termination procedures and information system activity review.

The Five Technical Safeguards § 164.312 Requires

Required versus Addressable determines how you document implementation decisions. Required means implement. Addressable means assess whether the specification is reasonable in your environment, and then either implement it, implement an equivalent alternative with written documentation, or document why neither is appropriate.

The HHS Security 101 guidance states that addressable specifications still require action and documentation. For startups handling ePHI with remote access and cloud-hosted data, the risk analysis will often show that many addressable specifications are necessary, either as implemented controls or documented equivalent alternatives.

1. Access Control (§ 164.312(a)(1))

Two Required specifications:

• Unique User Identification: assign a unique name and/or number for identifying and tracking user identity.
• Emergency Access Procedure: a documented process for accessing necessary ePHI during an emergency.

Two Addressable specifications:

• Automatic Logoff: session timeouts on systems containing ePHI.
• Encryption and Decryption: implement a mechanism to encrypt and decrypt ePHI. For startups with laptops accessing patient data, the risk analysis will often support implementing device encryption. FileVault on Mac, BitLocker on Windows.

Without unique user IDs, you can't reconstruct who touched what during a breach investigation. OCR will ask, and "we use shared accounts" is the end of the conversation.

2. Audit Controls (§ 164.312(b))

Audit Controls is fully Required. You must implement mechanisms that record and examine activity in systems containing ePHI. The operative word is "examine."

HHS technical safeguards guidance and § 164.308(a)(1)(ii)(D) support a documented log review process. Per § 164.316(b)(2), documentation must be retained for six years from the date of creation or the date it was last in effect, whichever is later.

Logging without review leaves the requirement incomplete.

3. Integrity (§ 164.312(c))

Required standard with an Addressable implementation specification: a mechanism to authenticate ePHI and confirm it hasn't been improperly altered. HHS technical safeguards guidance discusses electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner; in practice this can include checksums, hash validation, or digital signatures, typically at the application or database layer.

This requirement often sits outside endpoint tools and has to be addressed deliberately.

4. Person or Entity Authentication (§ 164.312(d))

This standard is fully Required. Implement procedures to verify that a person or entity seeking access to ePHI is the one claimed. NIST SP 800-66 Rev. 2 discusses authentication options as part of HIPAA Security Rule implementation guidance and explicitly recommends MFA for ePHI access. For startups with remote workforce access to ePHI, the risk analysis may support implementing MFA as a reasonable and appropriate safeguard today.

For most startups, this is one of the clearest places where the risk analysis points to implementation.

5. Transmission Security (§ 164.312(e))

Addressable implementation specifications for integrity controls and encryption in transit. The breach-notification safe harbor under 45 CFR § 164.402 applies to properly encrypted data: if ePHI is rendered unusable, unreadable, or indecipherable to unauthorized persons, it doesn't trigger breach notification obligations. Encrypting data in transit reduces breach risk and reporting obligations, and breach reports can trigger an OCR investigation.

Treat transmission encryption as a practical default.

How Endpoint and Identity Tools Map to § 164.312

You need a clear mapping between the regulations and the tools that satisfy them. Mobile Device Management (MDM) and Identity and Access Management (IAM) cover most of the technical safeguards, with EDR completing the endpoint side. That mapping is what lets a lean team implement the requirements.

HIPAA Requirement	Citation	R/A	MDM (Jamf/Microsoft Intune)	EDR (CrowdStrike)	IAM (Okta)
Unique User ID	§ 164.312(a)(2)(i)	R	Partial (device identity)	N/A	✅ Primary
Emergency Access	§ 164.312(a)(2)(ii)	R	N/A	N/A	Break-glass accounts
Automatic Logoff	§ 164.312(a)(2)(iii)	A	✅ Screen lock/timeout	N/A	Session timeout
Encryption at Rest	§ 164.312(a)(2)(iv)	A	✅ FileVault/BitLocker	N/A	N/A
Audit Controls	§ 164.312(b)	R	Device compliance logs	✅ Endpoint telemetry	✅ Auth event logs
ePHI Integrity	§ 164.312(c)(2)	A	N/A	Detective (tamper alerts)	N/A
Authentication	§ 164.312(d)	R	✅ Device certificates	N/A	✅ MFA/single sign-on (SSO)/FIDO2
Transmission Encryption	§ 164.312(e)(2)(ii)	A	VPN enforcement	N/A	TLS for app access

Each tool does its job in its own console. Zip runs the three together so a missed Okta offboard tightens the Jamf policy and a CrowdStrike detection ends the Okta session. § 164.312 operates as a connected control set rather than three parallel ones.

Three HIPAA requirements sit outside the scope of endpoint and identity tooling. They're written into the Security Rule, but no MDM, EDR, or IAM platform satisfies them on its own. Each one needs a documented process and a human accountable for it.

Gap	What must be owned
Risk analysis (§ 164.308(a)(1))	HIPAA requires a documented risk analysis process and written output; automated tools may assist, but the requirement is for an accurate and thorough assessment and documentation.
Security incident procedures (§ 164.308(a)(6))	EDR can detect endpoint incidents, but § 164.308(a)(6) separately requires documented security incident procedures to identify and respond to suspected or known incidents, mitigate harmful effects to the extent practicable, and document incidents and their outcomes.
ePHI integrity mechanisms (§ 164.312(c)(2))	Covered entities must implement electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner; these mechanisms may be implemented at the application, database, system, transmission, or EHR layers.

Each of these requirements has a process or documentation component that an auditor can ask for. OCR enforcement actions over the past two years have concentrated on exactly the same areas.

Where Startups Actually Fail: Risk Analysis

OCR enforcement actions hit business associates and covered entities of all sizes. Four recent cases show the pattern:

• Health Fitness Corporation (BA, $227,816): Filed four breach reports for a server misconfiguration. OCR found the company's first HIPAA-compliant risk analysis was conducted in January 2024, years after the breaches.
• USR Holdings (BA, $337,750): An unauthorized third party accessed and deleted ePHI for 2,903 individuals across three covered entity clients. OCR's corrective action plan required USR to conduct a risk analysis, implement a risk management plan, and establish backup procedures for ePHI, none of which were in place at the time of the breach.
• Gulf Coast Pain Consultants (covered entity, $1,190,000 civil money penalty): One of the violations OCR identified was failure to implement access termination policies.
• Virtual Private Network Solutions (BA, $90,000): A ransomware attack encrypted covered entity data across 12 clients. OCR cited failure to conduct a complete and accurate risk analysis.

Risk analysis failures keep appearing in enforcement.

Recent OCR statements and enforcement actions suggest that risk analysis failures are a recurring HIPAA problem. OCR has noted that organizations under investigation will often have deficient risk analysis practices, with common deficiencies including lacking a risk analysis entirely or failing to update existing risk analyses when implementing new technologies or expanding operations that affect the security of ePHI.

Recent enforcement examples also show that investigation timelines can run for years. Health Fitness Corporation's breach occurred in 2018; the settlement came in 2025. Decisions about risk analysis, access controls, and documentation can be evaluated well into the 2030s.

Point-in-Time Audits Don't Satisfy the Security Rule

HHS guidance on risk analysis states the process "should be ongoing." Three regulatory provisions establish this: § 164.306(e) requires security measures to be "reviewed and modified as needed," § 164.308(a)(8) requires periodic evaluation in response to environmental or operational changes, and documentation updates are required under § 164.316(b)(2)(iii).

Between audits, four types of drift create violations:

• Configuration drift: Encryption gets silently disabled after an OS update.
• Shadow devices: An employee's new laptop accesses ePHI before MDM enrollment.
• Incomplete offboarding: A departing employee's primary account is deactivated, but their access persists on secondary systems.
• Silently failing EDR agents: CrowdStrike coverage appears complete on the dashboard while an agent on one device stopped reporting after an OS update.

According to Zip Security's 2026 Security Survey, 64.5% of companies had discovered unsecured devices they thought were covered. If MDM isn't fully enrolled or CrowdStrike isn't on every device, the dashboard still says compliant. The control either runs continuously or the BAA is fiction.

Zip, a Built and Managed Security Platform (BMSP), enforces the underlying controls so encryption, MFA, EDR coverage, and access management stay running between audits. When a device falls out of encryption compliance or an EDR agent goes silent, Zip catches it. Licenses sit in the customer's name.

What the 2025 NPRM Means for Startups Today

The HIPAA Security Rule has not had a substantial update in over two decades. HHS cites a 102% increase in large breach reports between 2018 and 2023, a 1,002% increase in affected individuals over the same period, and the same compliance deficiencies (risk analysis, access termination, activity review) that appear in nearly every enforcement action. The HHS Notice of Proposed Rulemaking published on January 6, 2025 responds by eliminating the Required/Addressable distinction with limited exceptions. If finalized, the rule would establish the following mandates:

• Encryption of ePHI at rest and in transit: mandatory, limited exceptions
• MFA: mandatory, limited exceptions
• Workforce termination within one hour of separation, with 24-hour notification to other regulated entities where the worker had ePHI access
• Vulnerability scanning: at least every six months
• Penetration testing: at least annually
• Critical vulnerability remediation within 15 days; high-severity within 30 days
• Compliance audits: at least annually
• BA technical safeguard verification (written analysis and certification): at least annually
• BA contingency plan notification to covered entities: within 24 hours of activation

The NPRM has not been finalized. Per the HHS factsheet, the comment period closed March 7, 2025, and the rule remains in the rulemaking process. For startups, the proposed mandates align with what OCR already enforces under the current Security Rule. Build toward them now.

Start With Risk Analysis and Access Controls

Not every HIPAA control carries the same enforcement weight. Required specifications come first because OCR cites them in nearly every settlement; Addressable specifications follow because your risk analysis will support most of them in a startup environment. Every item below has to keep running between audits, which is where most startups lose their compliance posture.

Required Specifications with Highest Exposure

These eight items appear in nearly every OCR enforcement action against business associates. Stand them up first.

• Map where PHI lives. (process) Identify every system, integration, and workflow where Protected Health Information (PHI) enters, lives, or leaves.
• Risk analysis. (process) Conduct and document using the HHS SRA Tool.
• Security Official. (people) Designate under § 164.308(a)(2).
• Unique user IDs. (technical) No shared accounts on any system touching ePHI.
• Audit logging. (technical) Enable on all ePHI systems and retain related HIPAA-required documentation for six years.
• Incident response plan. (process) Implement policies and procedures to address security incidents, including identifying and responding to suspected or known incidents, mitigating harmful effects where practicable, and documenting incidents and their outcomes under § 164.308(a)(6).
• BAAs. (process) Execute with every covered entity and subcontractor handling ePHI.
• Backup and disaster recovery. (process) Written plans under § 164.308(a)(7).

Those controls make the rest of the program credible.

Addressable Specifications Your Risk Analysis Will Require

Your risk analysis will support implementing every one of these in a typical startup environment.

• Encrypt ePHI at rest. (technical) FileVault via Jamf, BitLocker via Microsoft Intune.
• Encrypt ePHI in transit. (technical) TLS everywhere, VPN where appropriate.
• MFA on all ePHI system access. (technical) Through an IAM platform like Okta, Microsoft Entra ID, or Google Workspace.
• Automatic session timeouts. (technical) Device screen lock and application session policies.
• Workforce termination procedures. (process + people) Documented and enforced.

Each control closes a specific attack path that the Required specifications can't close alone: a stolen laptop, a phished credential, an offboarded employee with lingering access.

Ongoing Obligations Between Audits

Compliance posture decays without recurring work. These four practices are the minimum cadence the Security Rule expects.

• Regular audit log review
• Annual risk analysis re-evaluation
• Periodic workforce training with documented attendance
• Six-year policy retention

Skip any of these and the program collapses back into point-in-time work, which is exactly what the Security Rule rejects.

After You Sign the BAA

Breaches affecting 500 or more individuals are publicly listed on the HHS OCR Breach Portal. For a startup, that listing can end customer relationships and block future enterprise deals. Staying off it depends on two things: controls that actually run, and evidence ready when a covered entity asks for it.

Evidence means a security overview, an incident response process, a list of subprocessors, and live data from your compliance dashboard. Annual vendor reviews and one-off security questionnaires both ask for the same set, and a BAA signed today is only as durable as your ability to produce that set on demand twelve months from now.

Signing a BAA commits you to safeguards that have to actually run on Monday morning rather than exist as a policy PDF. Zip closes that gap on the technical side by enrolling laptops in Jamf or Microsoft Intune, deploying CrowdStrike across the fleet, and configuring Okta with the joiner-mover-leaver workflows that recurring OCR settlements have flagged. Licenses sit in the client's name. Drift on encryption, MFA, or EDR coverage surfaces in one place rather than three.

Pine Park Health runs this configuration with a mobile clinical workforce and no security specialists on staff. Zip's secure defaults handle the configuration so the team focuses on patient care.

Fractional CISOs managing healthcare portfolios face the same problem at scale. Zip executes the security program the fractional CISO designs across every client in the book, with licenses held in the client's name and the advisory relationship intact.

Get a quote from Zip and close the gap between your BAA and your actual security controls.

FAQs About HIPAA for Startups

Does Signing a BAA Make My Startup HIPAA Compliant?

A BAA is a contract documenting your promise to implement safeguards. The HITECH Act made business associates directly liable for Security Rule compliance. OCR can investigate and penalize your startup directly. The controls satisfy the promise.

What Triggers an OCR Investigation of a Business Associate?

The most common trigger in documented enforcement actions is a self-reported breach notification. When a breach report is filed, OCR reviews it and may open an investigation. OCR also accepts OCR complaints and conducts proactive compliance audits under the HITECH Act Audit Program.

Is MFA Required Under HIPAA?

The Person or Entity Authentication standard (§ 164.312(d)) is a required standard with no implementation specifications, and NIST SP 800-66 Rev. 2 provides practical guidance for implementing the HIPAA Security Rule, including advising organizations to consider MFA. For startups with remote workforce access to ePHI, the risk analysis will often support implementing MFA today. The 2025 NPRM would make MFA explicitly mandatory.

What's the Difference Between Required and Addressable Safeguards?

Required means implement. Addressable means assess whether the specification is reasonable, then implement it, implement an equivalent alternative with written justification, or document why neither is appropriate. The 2025 NPRM would eliminate this distinction entirely.

Do I Need HITRUST Certification to Be HIPAA Compliant?

HITRUST is a voluntary framework. Per the HITRUST and HIPAA PDF, HITRUST certification addresses only part of HIPAA obligations. Start with a credible operational security minimum and mature over time.