Security-First Compliance
Platform for HIPAA

Four things, and the platform produces all of them as you go rather than the week you are asked. A trust portal page you send as a link, carrying the frameworks you run, your posture, and the documents you have chosen to publish. An audit binder, where every policy version, document, test result and written determination is pinned at the moment it was current, exported as a packet or opened through a magic link so a reviewer works in their own portal instead of inside your tenant. A current risk analysis carrying a dated management approval. And the population records a reviewer samples from: training completions per person, policy acknowledgments per person, and Business Associate Agreements per vendor. Most healthcare buyers ask for a SOC 2 report alongside it, which the same evidence base produces.

The Security Rule (45 CFR Part 164, Subparts A and C) is the control program: 18 standards and 36 implementation specifications across the Administrative, Physical, and Technical Safeguards, plus the organizational requirements at §164.314 and the documentation requirements at §164.316. Breach notification (§164.400 to §164.414) is a seeded control set too, not merely a policy: the notification duties, the four-factor breach risk assessment that decides whether you notify at all, and the log of breaches affecting fewer than 500 individuals each carry their own control and their own evidence. Note that the individual notice is due without unreasonable delay and no later than 60 calendar days after discovery, which is a deadline rather than a grace period. The Privacy Rule (minimum necessary, notice of privacy practices, accounting of disclosures) is advisory here: the AI vCISO answers on it, but it is not run as a control program. Which of these are yours depends on what you are. A business associate, which is what most health technology companies are, owes the Security Rule, the breach notification duties, and its own subcontractor agreements. A covered entity owes all of that plus the Privacy Rule administrative requirements at §164.530: a privacy official, privacy training, a sanctions policy, and a complaints process. Those stay yours to run.

An implementation specification marked Addressable is not optional, and it is never simply not applicable. You assess whether it is reasonable and appropriate for your environment, and where it is not, you document why in writing and implement an equivalent alternative measure if one is reasonable and appropriate. §164.306(d)(3) requires that written rationale, and §164.316(b)(2)(i) requires you to keep it for six years from creation or from the date it was last in effect, whichever is later. Comply keeps that determination as a versioned document on the same review cycle as your policies, so the decision is still retrievable years later instead of living in one person's memory. Encryption is the specification this comes up on most: §164.312(a)(2)(iv) and §164.312(e)(2)(ii) are both Addressable rather than Required, which surprises people. It is still the one to implement anyway, because ePHI encrypted to HHS guidance, where the key was not compromised, is not a reportable breach at all.

Yes, and it is most of the work. The Technical Safeguards at §164.312 overlap heavily with SOC 2 CC6 and CC7 and ISO 27001 Annex A 8.x: the same encryption, access control, and audit logging tests satisfy all three, collected once. Cross-framework mapping means one control set sits behind every framework, so adding HIPAA to a running SOC 2 program is largely a scoping and documentation exercise rather than a second evidence collection.