The Complete Guide to HIPAA Compliance for Tech Companies

Does HIPAA Even Apply to Your Tech Company?

This is the first question, and getting it wrong is expensive in both directions — over-investing in unnecessary compliance, or ignoring obligations and facing penalties up to $2.13 million per violation category per year.

HIPAA applies to you if:

You're a covered entity (healthcare provider, health plan, or healthcare clearinghouse) or — far more commonly for tech companies — a business associate: any organization that creates, receives, maintains, or transmits Protected Health Information (PHI) on behalf of a covered entity.

Common scenarios where tech companies become business associates:

Your SaaS product stores or processes patient data

Your cloud platform hosts healthcare applications

Your analytics tool processes data that includes health information

Your communication platform is used for clinical conversations

Your billing system handles healthcare payment information

Your CRM stores patient contact information for a healthcare client

Your AI/ML model processes health data for clinical insights

HIPAA probably doesn't apply if:

You sell a consumer health app that doesn't interact with covered entities (though FTC Health Breach Notification Rule may apply)

Your product handles de-identified health data (properly de-identified per HIPAA Safe Harbor or Expert Determination methods)

Your customers are wellness companies, not covered entities

The gray area: If you're not sure, ask your healthcare customers. If they want a Business Associate Agreement (BAA), that's your answer.

HIPAA Fundamentals for Tech Leaders

Protected Health Information (PHI)

PHI is any individually identifiable health information. It's broader than people think. The 18 HIPAA identifiers include obvious ones (name, SSN, medical record numbers) and less obvious ones:

IP addresses — Yes, an IP address combined with health data is PHI

Email addresses — Combined with the fact that someone is a patient = PHI

Dates — Admission dates, discharge dates, birth dates (except year)

Geographic data — Anything more specific than state-level

Device identifiers — Serial numbers, MAC addresses

URLs — If they can be linked to an individual

Biometric identifiers — Fingerprints, voiceprints, retinal scans

Full-face photographs

The key principle: It's not just "health data" — it's health data + any identifier that could link it to a person. If your system stores a medical condition alongside an email address, that's PHI. Electronic PHI (ePHI) is PHI in electronic form — which, for tech companies, is virtually all of it.

The HIPAA Rules

Three rules matter most:

Privacy Rule: Governs how PHI can be used and disclosed. Establishes patient rights (access, amendment, accounting of disclosures). Primarily applies to covered entities, but business associates have obligations too. Security Rule: Requires administrative, physical, and technical safeguards for ePHI. This is where tech companies spend most of their compliance effort. Breach Notification Rule: Requires notification to individuals, HHS, and sometimes media when unsecured PHI is breached.

Business Associate Agreements (BAAs)

A BAA is the legal contract that makes you a business associate. It's not optional — HIPAA requires it before a covered entity can share PHI with you.

Your BAA must include:

Permitted and required uses/disclosures of PHI

Agreement not to use or disclose PHI beyond what's permitted

Appropriate safeguards commitment

Reporting obligations for unauthorized uses, disclosures, and breaches

Ensuring sub-contractors agree to the same restrictions (sub-BAAs)

Making PHI available to fulfill individuals' access rights

Making PHI available to HHS for compliance investigations

Return or destruction of PHI at contract termination

Critical downstream requirement: Every vendor you use that could access PHI needs a BAA too. This includes:

Cloud providers (AWS, GCP, Azure — all offer BAAs)

Database services (if managed, they need BAAs)

Monitoring and logging tools (Datadog, New Relic, Splunk — if they could ingest PHI)

Email services (if PHI might be in email content or subject lines)

Backup services

Customer support tools (if support agents can access PHI in tickets)

AI/ML services (if they process PHI for model training or inference)

Pro tip: Maintain a BAA tracker — vendor name, BAA status, effective date, renewal date, PHI categories covered. PrivaBase's vendor management automates this tracking and alerts you when BAAs need renewal or new vendors need assessment.

The HIPAA Security Rule: What Tech Companies Actually Need

The Security Rule has three safeguard categories. Here's what each means in practice for tech companies.

Administrative Safeguards

These are the policies, procedures, and people controls:

Security Management Process Risk analysis — Comprehensive assessment of risks to ePHI. Must cover all systems, processes, and personnel that interact with ePHI. Required at least annually and whenever significant changes occur Risk management plan — Documented measures to reduce identified risks to a reasonable and appropriate level Sanction policy — Consequences for workforce members who violate HIPAA policies Information system activity review — Regular review of audit logs, access reports, and security incident tracking Workforce Security Authorization procedures — Process for determining which workforce members need access to ePHI Workforce clearance — Background checks and clearance for personnel who access ePHI Termination procedures — Revoke all access to ePHI immediately upon separation. Recover all devices and credentials Information Access Management Access authorization policy — How access to ePHI is granted based on role and minimum necessary principle Access establishment and modification — Procedures for creating, modifying, and reviewing access Separation of duties — Where appropriate, separate roles to prevent unauthorized access Security Awareness and Training Security reminders — Periodic security updates to workforce (can be email newsletters, Slack messages, or brief updates) Protection from malware — Endpoint protection and awareness about malicious software Login monitoring — Alert on and review failed login attempts Password management — Training on creating and protecting passwords (or modern authentication) Security Incident Procedures Incident response plan — Documented procedures for identifying, responding to, and mitigating security incidents Incident tracking — Log all security incidents, including those that don't result in a breach Contingency Plan Data backup plan — Regular backups of ePHI, tested restoration Disaster recovery plan — Procedures to restore systems and data after an emergency Emergency mode operation plan — How to continue critical processes during a crisis Testing and revision — Regular testing of contingency plans (at least annually) Applications and data criticality analysis — Identify which systems are critical for ePHI access Evaluation Periodic technical and non-technical evaluation — Assess whether your security measures still meet the Security Rule requirements. Required after operational changes

Physical Safeguards

For tech companies, physical safeguards primarily apply to offices and employee workstations. Cloud data center security is covered by your cloud provider's BAA.

Facility access controls — Badge access, visitor logs for areas where ePHI is accessible Workstation use — Policies for how workstations that access ePHI are used (privacy screens, clean desk) Workstation security — Physical security of workstations (locked offices, cable locks for laptops) Device and media controls — Policies for hardware disposal (wiping drives), media reuse, and device tracking

Technical Safeguards

This is where tech companies typically focus — and where your engineering choices matter most.

Access Controls Unique user identification — Every user who accesses ePHI has a unique ID. No shared accounts Emergency access procedure — How to access ePHI during an emergency when normal access procedures might fail Automatic logoff — Sessions expire after a period of inactivity Encryption and decryption — ePHI is encrypted at rest using AES-256 or equivalent Audit Controls Audit logging — Record who accessed ePHI, when, from where, and what they did Log integrity — Ensure audit logs can't be tampered with (immutable logging, write-once storage) Log retention — Retain audit logs for at least 6 years Regular log review — Analyze logs for unauthorized access or anomalies Integrity Controls Data integrity mechanisms — Electronic measures to confirm ePHI hasn't been improperly altered or destroyed Authentication of ePHI — Methods to verify that ePHI received has not been altered in transit (checksums, digital signatures) Transmission Security Encryption in transit — All ePHI transmitted over networks is encrypted (TLS 1.2+ minimum, TLS 1.3 preferred) Integrity controls for transmission — Mechanisms to ensure data isn't modified in transit

Architecture Patterns for HIPAA-Compliant Tech

Multi-Tenant vs. Single-Tenant

Single-tenant (dedicated infrastructure per healthcare customer):

Strongest isolation, simplest compliance story

Most expensive, hardest to scale

Best for: Enterprise healthcare customers, highest-sensitivity data

Multi-tenant with logical isolation:

Shared infrastructure with strict logical separation

Row-level security, separate encryption keys per tenant, isolated compute where needed

Best for: Most SaaS companies serving healthcare customers

Hybrid:

Shared infrastructure for most processing, dedicated components for ePHI storage and processing

Separate, encrypted database or schema for PHI

Shared application layer with strict access controls

Best for: Companies transitioning into healthcare compliance

The Minimum Necessary Principle

HIPAA's "minimum necessary" principle requires you to limit ePHI access to the minimum needed for any given purpose. In practice:

API design: Don't return full patient records when a subset of fields suffices

Database access: Application accounts should only have SELECT on tables they need, not broad access

Logging: Scrub ePHI from application logs. Log the event, not the data

Development: Use synthetic or de-identified data in non-production environments

Support: Build tools that let support staff help customers without seeing raw ePHI

Encryption Strategy

At rest:

Database-level encryption (RDS encryption, Cloud SQL encryption) — baseline

Application-level encryption for PHI fields — additional layer

Customer-managed encryption keys (CMEK) — strongest, gives customers key control

Backup encryption — don't forget this

In transit:

TLS 1.2+ for all external communications

TLS for internal service-to-service communication (even within your VPC)

API gateway enforcement — reject non-TLS connections

Email encryption if sending ePHI via email (avoid this if possible)

Key management:

Use cloud KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault)

Rotate keys regularly (at least annually)

Separate keys for different data classifications

Consider envelope encryption for application-level encryption

Breach Response and Notification

When Is It a Breach?

A breach is the acquisition, access, use, or disclosure of unsecured PHI in a manner not permitted by the Privacy Rule. There's a presumption that any impermissible use or disclosure is a breach unless you can demonstrate a low probability that PHI was compromised, based on:

Nature and extent of PHI involved

Who accessed or received the PHI

Whether PHI was actually acquired or viewed

Extent to which the risk has been mitigated

Notification Requirements

To the covered entity (your customer):

Your BAA specifies the timeline (typically 24-72 hours)

Include: nature of the breach, types of PHI involved, steps taken, mitigation measures

The covered entity then handles:

Individual notification (without unreasonable delay, no later than 60 days)

HHS notification (within 60 days for breaches affecting 500+ individuals; annual report for smaller breaches)

Media notification (for breaches affecting 500+ individuals in a state or jurisdiction)

Building Your Incident Response Plan

Detection and initial assessment — How you identify potential breaches (monitoring, employee reports, customer reports)

Containment — Steps to stop the breach from expanding

Investigation — Determine scope, affected individuals, data involved

Risk assessment — Apply the four-factor test to determine if notification is required

Notification — Notify affected covered entities per BAA timelines

Remediation — Fix the root cause, implement preventive measures

Documentation — Record everything — the investigation, decisions, actions, and outcomes

Post-incident review — What went wrong, what went right, what changes are needed

HIPAA Compliance Costs for Tech Companies

Initial Setup Costs

Ongoing Annual Costs

Cost Reduction Strategies

Use a compliance platform with HIPAA support — PrivaBase covers HIPAA alongside GDPR, SOC 2, and CCPA, so you're not buying separate tools for each framework

Leverage cloud provider compliance — AWS, GCP, and Azure are HIPAA-eligible and handle physical security, infrastructure encryption, and many technical controls

Start narrow — Scope your HIPAA compliance to only the systems that handle ePHI, not your entire infrastructure

Share controls across frameworks — If you're also pursuing SOC 2 or ISO 27001, many controls overlap. PrivaBase maps controls across frameworks to eliminate duplicate work

Automate evidence collection — Manual evidence collection for HIPAA audits is a massive time sink. Automation reduces annual audit prep from weeks to days

Common HIPAA Mistakes in Tech Companies

1. Not Knowing PHI Is in Your System

This happens more than you'd think. A customer starts putting patient notes in a "comments" field. An integration pulls in data with embedded health information. A support ticket contains ePHI.

Fix: Implement data discovery and classification. PrivaBase's data mapping can help identify where personal and health data lives across your systems.

2. Missing BAAs with Vendors

You signed a BAA with AWS, but what about your monitoring tool? Your error tracking service? Your CI/CD platform if it processes ePHI in tests?

Fix: Maintain a comprehensive vendor inventory with BAA status. Review every vendor that could access production systems or data.

3. Logging PHI in Application Logs

Your application logs probably contain request bodies, error details, and debug information. If any of that includes ePHI, your logging infrastructure needs HIPAA compliance.

Fix: Implement log scrubbing for PHI. Log transaction IDs and metadata, not data values. Ensure logging tools have BAAs.

4. Using Production PHI in Development

Developers copying production data to local machines or staging environments for testing is a violation.

Fix: Create synthetic test data or properly de-identify production data for non-production use. Never copy real ePHI outside the production environment.

5. Inadequate De-Identification

"We just removed the names" isn't sufficient. HIPAA defines two de-identification methods:

Safe Harbor: Remove all 18 identifier types. No residual information that could identify individuals

Expert Determination: A qualified statistical expert confirms re-identification risk is very small

Fix: Use the Safe Harbor method unless you have a qualified expert. When in doubt, treat data as PHI.

6. Ignoring Mobile and Remote Work

Workforce members accessing ePHI from personal devices, home networks, or public Wi-Fi creates risk.

Fix: MDM for company devices, VPN requirements for remote access, MFA everywhere, remote wipe capability for lost devices.

Building a Sustainable HIPAA Program

HIPAA compliance isn't a project — it's an ongoing program. Here's how to make it sustainable:

Embed Compliance in Development

Security by design — Consider HIPAA implications during feature design, not after deployment

Compliance as code — Automated security checks in CI/CD pipelines

Threat modeling — Evaluate new features for ePHI risks before building them

Secure defaults — Systems default to the most restrictive access, not the most permissive

Automate What You Can

Evidence collection — Automated snapshots of security configurations, access lists, and encryption status

Access reviews — Automated reports of who has access to what, with approval workflows

Training tracking — Automated assignment, reminders, and completion records

Risk assessment — Automated scanning for new risks and configuration drift

Monitoring — Continuous alerting on compliance-relevant events

PrivaBase automates these core HIPAA compliance activities, reducing the ongoing burden from dedicated headcount to a manageable part-time effort for smaller teams.

Review Cycles

Getting Started

If HIPAA compliance feels overwhelming, remember: you don't need to do everything at once. Start with the highest-impact items:

Determine if HIPAA applies — Do you handle PHI? Do customers want BAAs?

Scope your compliance — Which systems actually touch ePHI?

Conduct a risk assessment — PrivaBase can automate the initial discovery

Address critical gaps — Encryption, access controls, BAAs, and logging

Document your policies — Even simple policies are better than none

Scan your current posture — Free assessment to identify immediate compliance gaps

HIPAA compliance is a journey. The important thing is to start — deliberately, systematically, and with the right tools to make it sustainable.

Ready to begin?

Free compliance scan — Instant assessment of your current posture

Explore PrivaBase features — See how we simplify HIPAA compliance

View pricing — Plans designed for tech companies of every size

Create your account — Free tier, no credit card required