HIPAA Compliance for Tech Companies: What You Need to Know

If your software touches health information in any way - whether you are building a telehealth platform, a health data analytics tool, a patient scheduling system, or even a CRM used by healthcare providers - HIPAA applies to you. The Health Insurance Portability and Accountability Act is not limited to hospitals and insurance companies. Any technology company that creates, receives, maintains, or transmits protected health information (PHI) on behalf of a covered entity is classified as a business associate and must comply.

The penalties for non-compliance are severe. Fines range from $100 to $50,000 per violation, with a maximum of $1.5 million per violation category per year. Beyond fines, a HIPAA breach can destroy customer trust and end partnerships overnight. This guide gives technology companies a practical understanding of what HIPAA requires and how to achieve compliance.

Understanding PHI and Your Obligations

Protected Health Information (PHI) is any individually identifiable health information. This includes obvious data like medical records and diagnoses, but it also includes less obvious information when combined with health context.

The 18 HIPAA identifiers include:

• Names, addresses, dates (birth, admission, discharge, death)
• Phone numbers, email addresses, Social Security numbers
• Medical record numbers, health plan beneficiary numbers
• Account numbers, certificate/license numbers
• Device identifiers and serial numbers
• Web URLs, IP addresses, biometric identifiers
• Full-face photographs and any other unique identifying number

If your system stores any of these identifiers alongside health-related data, you are handling PHI. Even metadata can constitute PHI - an IP address logged alongside a request to a mental health API endpoint could be considered protected information.

Your role determines your obligations:

• Covered Entity - Health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically. Most tech companies are not covered entities.
• Business Associate - Any organization that performs functions or activities involving PHI on behalf of a covered entity. This is where most tech companies fall.
• Subcontractor - A business associate of a business associate. If you provide services to a company that handles PHI for a hospital, you are a subcontractor and still subject to HIPAA.

The Business Associate Agreement

Before handling any PHI, you must have a signed Business Associate Agreement (BAA) with every covered entity or business associate you work with. This is a legal requirement, not a best practice.

A BAA must specify:

• What PHI the business associate is permitted to access
• How the business associate will safeguard the PHI
• Requirements to report breaches and security incidents
• Obligations upon termination (return or destroy PHI)
• Restrictions on subcontracting and further disclosure
• The business associate's obligation to comply with applicable HIPAA requirements

Critical BAA considerations for tech companies:

• You also need BAAs with your subcontractors - your cloud provider, your email service provider, your logging platform, and any other vendor that may access PHI
• AWS, Azure, and GCP all offer BAAs, but you must explicitly execute them (they are not automatic)
• Not all services from a cloud provider are covered under their BAA - verify that the specific services you use are included
• Your monitoring and logging tools must also be covered if they ingest PHI data

Technical Safeguards You Must Implement

HIPAA's Security Rule requires administrative, physical, and technical safeguards. For technology companies, the technical safeguards typically require the most engineering effort.

Access Controls

• Implement unique user identification - every user must have a unique identifier
• Establish emergency access procedures for PHI systems
• Implement automatic logoff after periods of inactivity
• Use role-based access control (RBAC) to limit PHI access to the minimum necessary
• Enforce multi-factor authentication for all access to systems containing PHI
• Implement and regularly review access control lists

Encryption

• Encrypt PHI at rest using AES-256 or equivalent
• Encrypt PHI in transit using TLS 1.2 or higher
• Manage encryption keys securely using a key management service (AWS KMS, Azure Key Vault, GCP Cloud KMS)
• Encrypt database backups, snapshots, and any copies of PHI
• Consider field-level encryption for particularly sensitive data elements

HIPAA technically labels encryption as an "addressable" requirement rather than "required," but this does not mean it is optional. Addressable means you must implement it or document an equivalent alternative measure that provides equal protection. In practice, there is no reasonable alternative to encryption for technology companies.

Audit Controls

• Log all access to PHI - who accessed what data, when, and from where
• Log all modifications to PHI with before and after values
• Log authentication events (successful and failed)
• Retain audit logs for a minimum of six years (HIPAA's retention requirement)
• Protect audit logs from tampering (use write-once storage or log integrity verification)
• Review audit logs regularly for unauthorized access patterns

Integrity Controls

• Implement mechanisms to verify that PHI has not been altered or destroyed improperly
• Use checksums or digital signatures for PHI data in transit
• Implement database integrity constraints for PHI records
• Maintain verified backups with regular restoration testing

Transmission Security

• Use TLS 1.2+ for all API communications involving PHI
• Encrypt email containing PHI (standard SMTP is not sufficient)
• Secure file transfers using SFTP or encrypted channels
• Do not transmit PHI via SMS unless using an encrypted messaging platform

Common Compliance Pitfalls for Tech Companies

These are the mistakes we see most frequently when technology companies attempt HIPAA compliance.

Development and Testing with Real PHI

Using production PHI in development or testing environments is one of the most common violations. Development environments rarely have the same security controls as production.

Solutions:

• Use synthetic data generators that produce realistic but fake health data
• Implement data de-identification following HIPAA Safe Harbor or Expert Determination methods
• If real data is absolutely necessary for testing, apply the same security controls to test environments as production
• Never use PHI in local development environments

Inadequate Logging Practices

Many companies either log too much (including PHI in application logs) or too little (no audit trail of PHI access).

Best practices:

• Never log raw PHI in application logs - log references (record IDs) instead
• Ensure your logging infrastructure is covered under a BAA
• Implement structured logging that captures access events without capturing PHI values
• Set up alerting for suspicious access patterns

Overlooking the Minimum Necessary Rule

HIPAA requires that you limit PHI access, use, and disclosure to the minimum amount necessary to accomplish the intended purpose. This applies to your application design as well.

• API endpoints should return only the PHI fields needed for the specific use case
• Internal services should only have access to the PHI they need to function
• User roles should be scoped to the minimum PHI necessary for each job function
• Database queries should select specific columns, not entire records

Ignoring the Breach Notification Rule

If a breach of unsecured PHI occurs, you are required to notify:

• The covered entity (your customer) without unreasonable delay, no later than 60 days from discovery
• If you are the covered entity: affected individuals within 60 days, HHS, and potentially the media (for breaches affecting 500+ individuals)

Many tech companies do not have breach notification procedures in place. Build these before you need them.

Risk Assessment: The Foundation of HIPAA Compliance

HIPAA requires a thorough risk assessment - and it is the first thing auditors and investigators look for.

Your risk assessment should:

• Identify all systems that create, receive, maintain, or transmit PHI
• Identify threats and vulnerabilities for each system
• Assess the likelihood and impact of each threat exploiting each vulnerability
• Document current security measures and their effectiveness
• Determine residual risk levels and create a risk management plan
• Be updated annually and whenever significant changes occur

The risk assessment is not a one-time exercise. It is a living document that drives your security priorities and demonstrates to regulators that you take compliance seriously.