> ## Documentation Index > Fetch the complete documentation index at: https://docs.usehasp.com/llms.txt > Use this file to discover all available pages before exploring further. # Compliance Posture > HIPAA, HITRUST, SOC 2, GDPR, CCPA, and PIPEDA — how HASP satisfies each framework simultaneously. HASP's compliance scope is **six frameworks satisfied by a single set of controls**: HIPAA, HITRUST e1, SOC 2 Type II, GDPR, CCPA/CPRA, and PIPEDA. None is deferred, and none is gated to a higher tier — every paid Solo, Professional, Business, and Enterprise customer gets the same application-layer controls. ## 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 `DELETE` operation 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. This single-control-set principle is what makes six frameworks affordable: the controls are paid for once and documented against multiple frameworks. ## 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. ## Compliance is orthogonal to residency **Residency** is which physical region the data lives in. **Compliance** is which legal framework's controls govern how it is handled. These are decoupled: the default residency posture is US-only, and EU/UK customers are served from the US under the EU-US Data Privacy Framework, which is sufficient for baseline GDPR. A regional deployment is a deployment decision, not a compliance redesign. ## What HASP does not claim DEA recordkeeping (21 CFR Part 1304) and EPCS (Part 1311) are explicitly **not** in the V1 framework set. HASP does not represent itself as a DEA EPCS-compliant service. Any framework not listed above is out of scope until a successor decision adds it.