One control set, many frameworks
The frameworks differ in what they require be possible; the implementation surface for those requirements is largely the same. The same operation satisfies an obligation in several frameworks at once:- An Article 17 erasure (GDPR) is the same
DELETEoperation as a HIPAA-driven data-removal request, the same SOC 2 Confidentiality control, and the same HITRUST data-disposal expectation. - An Article 30 sub-processor record (GDPR) satisfies a HITRUST vendor-management control and a SOC 2 vendor-management control simultaneously.
- The audit chain serves all six frameworks with one set of events.
What each framework gates
| Framework | Primary obligation surface | How HASP satisfies it |
|---|---|---|
| HIPAA | Privacy, Security, and Breach Notification Rules (§164.308 / §164.310 / §164.312 / §164.410). | Substrate-inherited technical safeguards + logical data-plane isolation + signed audit chain + AI Gateway PHI guard + customer BAA + breach workflow. |
| HITRUST e1 | CSF e1 control set (the entry-level HITRUST tier). | Application-layer controls (audit, access, change management, incident response) owned and attested by HASP; substrate-layer controls documented through the substrate provider’s reports. |
| SOC 2 Type II | Trust Services Criteria — Security (mandatory) plus Availability, Confidentiality, Processing Integrity, and Privacy as scoped. | Substrate inheritance + application-layer controls + HASP’s own Type II report. |
| GDPR | Articles 13, 17, 20, 30. | DELETE endpoints (Art. 17), entity-level exports (Art. 20), sub-processor register + DPA (Art. 30), transparency via published Trust Center + DPA. |
| CCPA / CPRA | Rights to know / delete / port / opt out; ADM role boundary. | Same data-rights endpoints as GDPR. HASP is a processor, not an automated-decision-maker — model output is presented to a human who decides. |
| PIPEDA | The ten fair-information principles (Schedule 1); cross-border transfer accountability under §4.1.3. | The same controls as GDPR; cross-border accountability discharged through contractual clauses in the DPA. |
Substrate-inherited vs. HASP-owned controls
Compliance posture has two layers:- Inherited from the compliance substrate. HIPAA Security Rule technical safeguards (encryption at rest and in transit, access controls, transmission security, audit-log infrastructure) and SOC 2 controls covering the environmental, monitoring, and change-management surface are inherited from Aptible’s Production plan from day one. HITRUST CSF inheritable controls require Aptible’s Enterprise plan and are tier-1-deal-gated.
- Owned by HASP. The application layer — HIPAA Privacy and Breach Notification application, BAA enforcement at the org boundary, the end-to-end verifiable audit chain, GDPR/CCPA data-rights endpoints, and the application-layer HITRUST and SOC 2 controls — is HASP’s own responsibility.
Attestation status
SOC 2 Type II and HITRUST e1 are the two formal audit engagements HASP owns directly. They are pursued through a stacked-audit platform (Vanta or Drata) starting on funding close — one control framework mapped to two report outputs. Until those reports issue, the honest customer-facing posture is: HITRUST and SOC 2 are inherited from the compliance substrate; HASP’s own attestations are in flight. HITRUST r2 is not in committed scope; it becomes a successor decision only if a specific contract genuinely requires it.