HIPAA reaches healthcare software companies through the business associate relationship. A covered entity is a provider, health plan, or clearinghouse. A vendor that creates, receives, maintains, or transmits ePHI on a covered entity's behalf is that entity's business associate, and since the HITECH Act and the 2013 Omnibus Rule, business associates are directly liable for the Security Rule and for the breach-notification and applicable privacy provisions that apply to them. Whether your product is in scope turns on the data it handles and for whom, so the first task is to establish that clearly rather than assume it.
Business associates carry direct liability, not just contractual risk.
Before HITECH, a business associate's HIPAA obligations flowed only from its contract with the covered entity. The HITECH Act and the Omnibus Rule changed that. A business associate is now directly liable to HHS for compliance with the Security Rule and with the Breach Notification Rule and applicable Privacy Rule provisions, and can be subject to enforcement by the Office for Civil Rights in its own right. For a software company that means the safeguards are your legal responsibility, not just a promise to a customer.
That responsibility runs in both directions along the chain. You sign a business associate agreement with each covered-entity customer whose ePHI your platform handles, and you sign one with every subcontractor that touches that ePHI on your behalf, from your cloud host to a downstream analytics or support service. Cyber One Solutions, supporting your corporate IT and security, is itself a subcontractor business associate and signs a business associate agreement with you. We help you build and evidence the agreements up and down that chain so the requirement is met rather than assumed.
Multi-tenant SaaS and cloud hosting concentrate the risk and split the duty.
A multi-tenant platform holds the ePHI of many provider customers in shared infrastructure, so a single failure of tenant isolation or access control can expose many customers at once. That concentration is why tenant separation, least-privilege access to production, encryption, and audit logging are not niceties but core Security Rule safeguards for your architecture. We help you design and evidence the controls that keep one customer's data walled off from another's.
Hosting on AWS, Azure, or Google Cloud does not move the obligation off your books. The major cloud providers will sign a business associate agreement and secure the physical infrastructure, but under the shared-responsibility model you remain responsible for what you build on top: configuration, identity and access, encryption settings, network controls, and the application itself. A HIPAA-eligible cloud service is a starting point, not compliance. We build and document the controls on your side of that line.
Secure development is where a software vendor's compliance is won or lost.
The Security Rule expects covered entities and business associates to apply reasonable and appropriate safeguards, and for a company whose product is software, that reaches into how the product is built. Access controls, audit logging, encryption, and integrity protections have to be designed into the application, not bolted on, and a vulnerability in your code is a direct path to the ePHI you hold.
We help you fold application security into the development lifecycle: access and secret management, code and dependency scanning, change control, and logging of access to patient data. The goal is a platform where the technical safeguards are part of the build and the evidence is produced as you ship, rather than reconstructed under the pressure of a customer audit.
Customer security reviews, SOC 2, and HITRUST are readiness we build, not attestations we issue.
Provider and health-plan customers increasingly gate procurement on a security questionnaire and, past a certain size, a SOC 2 report or HITRUST certification before they will trust a vendor with patient data. These are issued by third parties: a licensed CPA firm performs a SOC 2 examination, and HITRUST certifies against its CSF through an authorized assessor. Cyber One Solutions does not issue either one.
What we do is build the readiness. We map your controls to the Security Rule and to the SOC 2 Trust Services Criteria or the HITRUST CSF, close the gaps, and assemble the policies, evidence, and answers so you walk into a customer review or a third-party assessment prepared rather than scrambling. The same underlying control set answers the HIPAA obligation and the customer's questionnaire at once.