Do software companies need to be HIPAA compliant?

Software companies must comply with HIPAA if they create, receive, maintain, or transmit protected health information (PHI) on behalf of a covered entity such as a hospital, health plan, or healthcare provider. This makes them business associates under the law. If your software never touches PHI, HIPAA does not apply to you — but the moment a healthcare customer stores patient data in your system, you are subject to HIPAA requirements.

What is a business associate agreement and when is it required?

A business associate agreement (BAA) is a legally binding contract between a covered entity and a business associate that establishes the permitted uses and disclosures of PHI, requires the business associate to implement appropriate safeguards, and defines breach notification obligations. A BAA must be signed before any PHI is shared. Without one, both parties are in violation of HIPAA, regardless of what technical safeguards are in place.

Can you use AWS, Azure, or GCP for HIPAA-compliant hosting?

Yes. AWS, Azure, and GCP all offer BAAs and support HIPAA-compliant workloads, but signing a cloud provider BAA does not make your application compliant. Under the shared responsibility model, the cloud provider secures the infrastructure layer while you remain responsible for configuring services correctly, encrypting data, managing access controls, and securing your application code.

What is the penalty for a HIPAA breach as a business associate?

Penalties for HIPAA violations range from £100 to £50,000 per violation, with annual maximums of £1.5 million per violation category. In cases of wilful neglect, criminal penalties including fines up to £250,000 and imprisonment are possible. Beyond regulatory penalties, breaches carry significant reputational damage and loss of healthcare customer contracts.

Does SOC 2 compliance satisfy HIPAA requirements?

SOC 2 does not satisfy HIPAA on its own, but there is substantial overlap. Organisations with SOC 2 Type 2 reports typically find that 60 to 70 percent of their existing controls map to HIPAA Security Rule requirements. Pursuing both frameworks simultaneously is efficient because you can reuse policies, evidence, and technical controls across both programmes.

How long does it take a SaaS company to become HIPAA compliant?

Most SaaS companies can achieve HIPAA compliance in 2 to 6 months, depending on their existing security posture, infrastructure complexity, and whether they use automation tools to accelerate the process. Companies that already hold SOC 2 certification can often reach HIPAA compliance in 4 to 8 weeks because of the significant control overlap between the two frameworks.

HIPAA Compliance for Software Companies

If your software company is exploring healthcare as a market, HIPAA compliance is almost certainly a prerequisite. Hospitals, health plans, and digital health organisations will not entrust patient data to a platform that cannot demonstrate compliance. Unlike SOC 2, which is market-driven, HIPAA is a federal law with civil and criminal penalties.

HIPAA was written in 1996, long before modern SaaS architectures and continuous deployment pipelines existed. The regulation’s technology-neutral language gives software companies flexibility but also creates ambiguity about what compliance looks like for a company shipping code rather than filing insurance claims.

This guide explains when HIPAA applies to software companies, what your obligations are as a business associate, and how to build a practical compliance programme that satisfies regulators and healthcare customers without derailing your engineering roadmap.

When HIPAA applies to software companies

HIPAA applies when your organisation handles protected health information (PHI) on behalf of a covered entity. Understanding this distinction is the starting point for everything that follows.

Covered entities are health plans, healthcare providers who transmit health information electronically, and healthcare clearinghouses — the organisations directly subject to HIPAA.

Business associates are organisations that create, receive, maintain, or transmit PHI on behalf of a covered entity. If a hospital uses your SaaS platform to manage patient records, you are a business associate. If a digital health company stores clinical data in your database, you are a business associate.

The HITECH Act of 2009 extended HIPAA’s requirements directly to business associates. Business associates are now independently liable for compliance with the HIPAA Security Rule, certain provisions of the Privacy Rule, and breach notification requirements.

Subcontractors count too. If you engage a subcontractor who will access PHI — a cloud hosting provider, a data analytics vendor, a managed database service — that subcontractor is also a business associate and must sign a BAA with you. The chain of accountability extends through every layer of your technology stack.

When HIPAA does not apply. If your software handles only de-identified data (stripped of all 18 HIPAA identifiers), HIPAA does not apply. Similarly, if your product never touches PHI, you have no HIPAA obligations. However, be cautious: many software companies discover they are handling PHI indirectly — through log files that capture patient names, support tickets that include clinical details, or analytics pipelines that process identifiable health data.

Business associate agreements: what they are and why they matter

A business associate agreement (BAA) is the legal instrument that governs the relationship between a covered entity and a business associate. No BAA, no PHI — that is the rule. Sharing PHI without a signed BAA in place is itself a HIPAA violation, regardless of what technical safeguards exist.

Key terms every BAA must include

HIPAA regulations specify required provisions for BAAs. Every agreement must address:

Permitted uses and disclosures of PHI, limited to what is necessary to perform the services described in the agreement.
Safeguards the business associate will implement to prevent unauthorised use or disclosure of PHI.
Breach notification obligations, including the timeframe and process for reporting security incidents to the covered entity.
Subcontractor requirements, ensuring that any downstream entities that access PHI are bound by the same obligations.
Return or destruction of PHI upon termination of the agreement, where feasible.
Access to records by the Department of Health and Human Services (HHS) for compliance investigations.
Individual rights support, including the ability to provide access to PHI and make amendments when requested by individuals through the covered entity.

Who signs BAAs

In a typical SaaS arrangement, the covered entity (or another business associate upstream) signs a BAA with your company. You then sign BAAs with your own subcontractors — your cloud provider, your managed database service, your email delivery platform if it handles PHI.

Most major cloud providers and SaaS tools offer standardised BAAs. AWS, Azure, and GCP all provide BAAs as part of their enterprise or healthcare-specific agreements. However, not every service within those platforms is covered by the BAA. AWS, for instance, publishes a specific list of HIPAA-eligible services. Using a non-eligible service to process PHI puts you out of compliance even if you have signed the AWS BAA.

Cloud infrastructure and HIPAA

The shared responsibility model is the single most important concept for software companies to understand when running HIPAA workloads in the cloud.

How shared responsibility works

Your cloud provider is responsible for the security of the cloud — physical data centres, hypervisors, and networking fabric. You are responsible for security in the cloud — your application code, data encryption, access controls, network configuration, and operating system patches.

Signing a BAA with AWS does not make your application HIPAA compliant. It means AWS will uphold its obligations for the infrastructure layer. Your obligations for the application layer remain entirely your own.

Practical cloud configuration requirements

To run HIPAA-compliant workloads in the cloud, software companies must ensure:

Encryption at rest is enabled for all PHI data stores — databases, object storage, backups, and snapshots. Use AES-256 and manage keys through your provider’s key management service (AWS KMS, Azure Key Vault, GCP Cloud KMS).
Encryption in transit is enforced via TLS 1.2 or higher for all API communications, database connections, and inter-service traffic carrying PHI.
Network segmentation isolates PHI workloads from non-PHI workloads using VPCs, security groups, and network ACLs.
Logging and monitoring captures all access to PHI. Enable cloud-native audit logging (CloudTrail, Azure Monitor, GCP Audit Logs) and ensure logs are tamper-proof and retained for six years.
Backup and disaster recovery procedures are documented and tested. Backups must be encrypted and access-controlled.

Technical controls software companies need

Beyond cloud configuration, your application itself must implement controls that satisfy the HIPAA Security Rule’s administrative, physical, and technical safeguard requirements.

Encryption

Encrypt PHI at rest and in transit without exception. At the application layer, this means encrypting sensitive database fields, ensuring PHI is never written to unencrypted temporary files or logs, and verifying that all API endpoints enforce TLS. Consider field-level encryption for particularly sensitive data elements, ensuring that even database administrators cannot access raw PHI without decryption keys.

Access controls

Implement role-based access control (RBAC) that enforces the minimum necessary standard — users and systems should only access the PHI they need to perform their specific function. This includes:

Unique user identification for every individual who accesses systems containing PHI. No shared accounts.
Multi-factor authentication (MFA) for all access to systems that store or process PHI.
Automatic session timeouts that terminate inactive sessions after a defined period.
Emergency access procedures that allow authorised personnel to access PHI during system outages or emergencies.
Quarterly access reviews to verify that access rights remain appropriate and that former employees or contractors have been deprovisioned.

Audit logging

Every access to PHI must be logged — reads, writes, modifications, deletions, and failed access attempts. Logs must capture the user or system identity, timestamp, action performed, and data accessed. Store logs in append-only storage or a dedicated SIEM to ensure they are tamper-proof.

Audit logging is not only a regulatory requirement; it is your primary investigative tool during a breach. Without comprehensive logs, you cannot determine what data was accessed, by whom, or when — which makes breach notification and remediation significantly harder.

Backup and recovery

The HIPAA Security Rule requires organisations to establish procedures for creating and maintaining retrievable exact copies of electronic PHI. Your backup strategy must include regular automated backups, encryption of backup data, access controls on backup storage, documented restoration procedures, and periodic restoration testing to verify that backups are functional.

Development practices for HIPAA compliance

The Security Rule’s requirements have direct implications for how your engineering team builds and deploys software.

Secure software development lifecycle (SDLC)

Formalise your development practices into a documented secure SDLC:

Design phase: Conduct threat modelling for features that involve PHI. Identify data flows, trust boundaries, and potential attack vectors before writing code.
Development phase: Enforce secure coding standards. Prohibit hardcoded credentials, ensure input validation, prevent SQL injection and cross-site scripting, and never log PHI in application logs unless those logs are encrypted and access-controlled.
Code review: Require peer review for all code changes that affect PHI handling, access controls, or authentication. Reviewers should specifically check for PHI leakage into logs, error messages, or client-side responses.
Testing phase: Include security testing in your CI/CD pipeline. Run static application security testing (SAST) and dynamic application security testing (DAST) tools on every build. Conduct manual penetration testing at least annually, and after any significant architectural change.

Penetration testing and change management

Annual penetration testing is a best practice that most healthcare customers will expect. Engage a qualified third-party firm to test your application, infrastructure, and APIs for vulnerabilities. Remediate critical findings before deploying to production, and retain reports as compliance evidence.

Alongside testing, document a formal change management process that includes peer review, approval workflows, and rollback procedures. Every change to production systems handling PHI should be traceable — who made the change, what was changed, when it was deployed, and who approved it.

Common mistakes software companies make

Software companies entering healthcare frequently stumble on the same set of issues. Recognising these patterns early can save months of remediation.

Assuming the cloud provider handles everything. Signing a BAA with AWS is step one, not the finish line. The shared responsibility model means your application-layer controls, access management, and data handling practices are entirely your responsibility. Many companies sign a cloud BAA and assume they are compliant, only to discover significant gaps during a customer audit.

Neglecting PHI in non-obvious places. PHI leaks into application logs, error messages, support ticket systems, analytics platforms, and Slack channels. Audit every system your team uses to determine whether PHI could flow into it, and implement data minimisation practices accordingly.

Treating HIPAA as a one-time project. Policies must be reviewed annually, risk assessments updated, workforce training repeated, and technical controls continuously monitored. Companies that treat HIPAA as a checkbox inevitably fall out of compliance.

Overlooking workforce training. Every team member who could access PHI must receive HIPAA-specific training covering your organisation’s policies, PHI handling procedures, and the consequences of non-compliance. A generic security awareness programme does not satisfy this requirement.

Failing to conduct a risk assessment. HHS considers the risk assessment the foundation of HIPAA compliance, and its absence is one of the most frequently cited findings in enforcement actions. Many software companies skip this step or conduct a superficial assessment that does not meet the standard.

Ignoring mobile and remote access. If your team accesses PHI from laptops, mobile devices, or home networks, your controls must account for these scenarios — device encryption, remote wipe capabilities, VPN requirements, and mobile device management (MDM).

HIPAA and SOC 2 overlap

Software companies that already hold SOC 2 certification have a significant head start on HIPAA compliance. The two frameworks share substantial overlap:

Access controls: SOC 2’s Common Criteria (CC6.1 through CC6.8) map closely to HIPAA’s technical safeguards for access control and unique user identification.
Encryption: SOC 2’s confidentiality criteria align with HIPAA’s encryption requirements for ePHI.
Audit logging: SOC 2’s monitoring requirements (CC7.1 through CC7.4) parallel HIPAA’s audit control requirements.
Incident response: SOC 2’s incident management criteria overlap with HIPAA’s breach notification procedures.
Risk management: Both frameworks require formal risk assessments and ongoing risk monitoring.
Vendor management: SOC 2’s vendor risk requirements align with HIPAA’s business associate management obligations.

The gaps SOC 2 does not cover include HIPAA-specific requirements around PHI handling, individual rights (access and amendment requests), breach notification to HHS, and workforce training specifically addressing PHI. These are meaningful additions but represent a fraction of the overall effort if your SOC 2 programme is mature.

A GRC platform like Prova enables you to map controls across both frameworks simultaneously, eliminating duplicate evidence collection and providing a unified compliance view.

Breach notification for business associates

The HIPAA Breach Notification Rule imposes specific obligations on business associates when a breach of unsecured PHI occurs.

Notification to covered entities. Business associates must notify each affected covered entity without unreasonable delay, and no later than 60 days after discovering the breach. The notification must include the nature of the PHI involved, the individuals affected, the steps taken to investigate and mitigate, and contact information.

What constitutes a breach. A breach is any impermissible acquisition, access, use, or disclosure of PHI that compromises its security or privacy. There is a presumption that any impermissible use or disclosure is a breach unless you can demonstrate a low probability that the PHI was compromised, based on a four-factor risk assessment considering: the nature of the PHI involved, who accessed it, whether it was actually acquired or viewed, and the extent to which risk has been mitigated.

Documentation. Even incidents that do not rise to the level of a reportable breach must be documented. Maintain an incident log recording every security event involving PHI, your risk assessment, and the breach determination. Retain these records for six years.

Practical compliance roadmap for a SaaS startup

If you are a SaaS company preparing to enter the healthcare market, the following roadmap provides a practical path to HIPAA compliance.

Weeks 1 to 2: Foundation

Appoint a HIPAA Security Officer responsible for overseeing the compliance programme. In a startup, this may be a CTO, VP of Engineering, or Head of Security wearing an additional hat.
Conduct a formal risk assessment that identifies all systems that store, process, or transmit PHI, the threats and vulnerabilities to those systems, and the current controls in place.
Identify your PHI data flows by mapping how patient data enters your system, where it is stored, how it moves between services, and where it exits.

Weeks 3 to 4: Policies and agreements

Draft your HIPAA policies and procedures, covering access control, encryption, audit logging, incident response, breach notification, workforce training, device management, and data retention.
Execute BAAs with all subcontractors that will access PHI — your cloud provider, database hosting service, email provider, monitoring tools, and any other vendor in the PHI data flow.
Review and update your BAA template for use with your own healthcare customers.

Weeks 5 to 8: Technical implementation

Implement encryption at rest and in transit for all PHI data stores and communication channels.
Deploy access controls including RBAC, MFA, unique user IDs, automatic session timeouts, and emergency access procedures.
Configure audit logging across your application, infrastructure, and cloud environment. Ensure logs are tamper-proof and retained for six years.
Harden your cloud environment by enabling only HIPAA-eligible services, configuring network segmentation, and ensuring backups are encrypted.
Integrate security testing into your CI/CD pipeline, including SAST, DAST, and dependency scanning.

Weeks 9 to 10: Training and testing

Conduct workforce training for all employees who will access PHI. Document attendance and comprehension.
Perform a penetration test against your application and infrastructure. Remediate critical findings.
Test your incident response plan with a tabletop exercise simulating a PHI breach.
Test backup restoration to verify that PHI is recoverable.

Weeks 11 to 12: Validation and go-live

Conduct an internal audit against the HIPAA Security Rule to verify that all required controls are implemented and operating.
Remediate any remaining gaps identified during the internal audit.
Document your compliance programme in a format suitable for sharing with healthcare customers during due diligence.
Establish ongoing monitoring procedures, including continuous control monitoring, quarterly access reviews, annual risk assessments, and annual workforce training refreshers.

This timeline assumes a SaaS company with a reasonably mature security posture. Companies starting from scratch should expect the process to take 4 to 6 months. Using a GRC platform like Prova to automate evidence collection, track control implementation, and manage policies can compress the timeline significantly.

HIPAA compliance is not a destination but an ongoing programme. Healthcare customers will expect annual evidence of compliance, and HHS enforcement actions frequently target organisations whose programmes have deteriorated after initial implementation.