Business Associate Agreement

1. Definitions

Terms used in this BAA — including "Protected Health Information," "Covered Entity," "Business Associate," "Subcontractor," "Breach," "Required by Law," and "Unsecured PHI" — have the meanings given in 45 CFR §§ 160.103 and 164.402 (the HIPAA Privacy, Security, and Breach Notification Rules). "Service" means the HASP platform across every product surface — Assistant chat, document workflows, Studio internal apps, the Public API, and the Agent SDK.

2. Scope of the BAA

This BAA governs HASP's handling of PHI on behalf of the Covered Entity in the course of providing the Service. One BAA covers every HASP surface and every paid tier. There is no per-feature or per-app BAA, and there is no PHI surcharge — the bundle is the point.

The BAA covers, without limitation:

• Assistant chat: PHI that appears in user prompts, attachments, and model responses, including PHI detected and tokenized by HASP's redaction pipeline before reaching an inference provider.
• Document workflows: Documents uploaded for extraction, summarization, redaction, or retrieval, including files stored in object storage and embeddings computed against them.
• Studio internal apps: Records created in Studio-built apps, including JSONB rows, attachments, and inter-app data flows.
• Public API: Request and response payloads sent to HASP's HTTP API, including the 30-day developer-console request inspector store described in the DPA.
• Agent SDK and Agent Actions: Actions delegated to agents acting on behalf of a user or service identity, including any PHI passed through agent tool calls and the audit events emitted at each step.

Free Evaluation organizations are out of scope. Do not send PHI to a Free Evaluation org under any circumstances.

3. Permitted Uses and Disclosures

HASP will use and disclose PHI only as follows:

• As necessary to perform the Service for the Covered Entity, including transmission to the inference provider the Covered Entity has routed its workload to.
• For the proper management and administration of HASP, or to carry out HASP's legal responsibilities, provided that any further disclosure is Required by Law or the recipient provides reasonable assurances that the PHI will be held confidentially and any breach is reported.
• To report violations of law to the appropriate Federal or State authorities.
• For Data Aggregation services relating to the health care operations of the Covered Entity, only with prior written consent.

HASP will not use or disclose PHI in a manner that would violate Subpart E of 45 CFR Part 164 if done by the Covered Entity, except for the management, administrative, and legal uses above.

4. Safeguards

HASP implements administrative, physical, and technical safeguards that reasonably and appropriately protect the confidentiality, integrity, and availability of PHI, in accordance with 45 CFR § 164.314(a) and the HIPAA Security Rule. The current control set is summarized on the security page, the HIPAA-specific mapping is on the HIPAA page, and the compliance posture (universal across every paid tier and Free Evaluation) is on the Trust Center. Highlights:

• TLS 1.2+ in transit; AES-256 at rest for OAuth tokens and equivalent for stored PHI.
• Role-based access control with capability-scoped tokens; Enterprise SSO/SAML available on Business and Enterprise tiers.
• PHI detection and redaction performed by HASP's own Microsoft Presidio-based pipeline before content leaves the HASP substrate for any inference provider; PHI handling is not delegated to a third party.
• Dedicated Postgres data plane for Enterprise; row-level isolation on the shared compliance-certified cluster for Solo, Professional, and Business.
• Workforce confidentiality obligations and least-privilege access on the HASP side.

5. Audit Chain and Trust Commitments

HASP maintains an append-only, cryptographically chained audit log for every paid org. Every BAA-relevant event — including the BAA execution itself, every PHI redaction, every inference call, every Agent Action, every PHI-reveal in the developer console — is recorded in the chain with an Ed25519 signature linking it to the previous event.

• Audit and Trust — what the chain captures and how it is exposed to your security and compliance teams.
• Chain verification — independent verification of chain integrity; you can verify the entire chain without trusting HASP.

The executed BAA, the template hash, both signatures, and the signing timestamp are all recorded in the chain. HASP cannot retroactively alter an executed BAA without breaking verification.

6. Subcontractors

HASP will require any Subcontractor that creates, receives, maintains, or transmits PHI on its behalf to enter into a written agreement that imposes the same restrictions and conditions on the Subcontractor as this BAA imposes on HASP, in accordance with 45 CFR § 164.502(e)(1)(ii) and § 164.308(b)(2). The current Subcontractor list is published on the sub-processors page and kept in sync with the DPA sub-processor table.

The PHI-touching Subcontractors that flow down under this BAA include — non-exhaustively — Anthropic, OpenAI, and Aptible (compliance substrate for compute, database, and network). HASP holds direct Business Associate Agreements with each. You do not need separate BAAs with these parties — that is the entire point of routing through HASP's substrate.

HASP will give at least 30 days advance notice before adding a new direct Subcontractor that may handle PHI, or making a material change to an existing one. Customer may object during the notice period by contacting [email protected]. On Business and Enterprise tiers, Customer may also restrict specific inference-provider routing for its own workloads via Customer-configurable inference policy at the org level.

7. Breach Notification

HASP will report to Covered Entity any use or disclosure of PHI not permitted by this BAA, and any Security Incident or Breach of Unsecured PHI of which it becomes aware, without unreasonable delay and in no event later than 72 hours after discovery, in accordance with 45 CFR §§ 164.314(a)(2)(i)(C) and 164.410. The notification will include, to the extent then known:

• The nature of the Breach, including the date of the incident and the date of discovery.
• The categories and approximate number of individuals affected.
• The types of PHI involved.
• The identification of each individual whose Unsecured PHI was or is reasonably believed to have been involved.
• The likely consequences of the Breach.
• The mitigation and corrective actions HASP has taken or proposes to take.

Unsuccessful Security Incidents — such as routine port scans, blocked authentication attempts, and other events that do not result in any unauthorized access, use, disclosure, modification, or destruction of PHI — are reported in aggregate via the Trust workspace rather than per-event.

8. Individual Rights and Access

HASP supports Covered Entity's obligations to fulfill Individual rights under HIPAA:

• Access: Self-service data export from the in-product Privacy & Data settings; structured export of records and attachments for the Individual's PHI.
• Amendment: Record-edit tooling in-product, with every amendment recorded in the audit chain.
• Accounting of Disclosures: The audit chain provides a complete record of disclosures of PHI made by HASP's Service, exportable on request.
• Restriction and Confidential Communications: Customer-configurable policies at the org and workspace level, escalated to [email protected] when the standard tools are insufficient.

9. Term and Termination

This BAA is effective on countersignature inside the Service and continues for the term of the underlying Agreement. Either party may terminate this BAA upon written notice if the other party has materially breached and failed to cure within thirty (30) days, in accordance with 45 CFR § 164.504(e)(2)(iii). Termination of the BAA terminates the Covered Entity's right to send PHI through the Service.

10. Return or Destruction of PHI

Upon termination of the BAA, HASP will, with respect to PHI it still maintains in any form and that is feasible to return or destroy: (a) return the PHI to Covered Entity via the in-product data export, or (b) destroy the PHI on Covered Entity's election. Where return or destruction is infeasible, HASP will extend the protections of this BAA to the PHI and limit further uses and disclosures to those purposes that make return or destruction infeasible, for as long as it is retained.

Audit log records that reference PHI by integrity-chain hash rather than by clear-text content may be retained beyond termination as required to preserve chain integrity and as required by law; their retention does not constitute continued processing of the PHI itself.

11. Modifications and Notice

HASP may modify this BAA from time to time. Customers with active BAAs will be notified at least 30 days before a material change takes effect. The diff between the prior and new template is published in-product alongside the re-countersignature prompt; the prior executed BAA remains in the audit chain as a tamper-evident historical record. Continued use of the Service after the effective date constitutes acceptance of the modified BAA, subject to the Customer's right to terminate under Section 9.

12. Execution

The BAA is countersigned inside the HASP platform during signup or upgrade to a paid plan. The signing flow captures Customer's authorized signer, binds HASP's signature at the same timestamp, generates an executed PDF, and writes the execution event to the integrity-chained audit log. The executed PDF is available from your organization's Trust workspace at any time.

Enterprise customers requiring custom redlines, an MSA, or a separately countersigned PDF should contact [email protected] to begin negotiation before signup.

Frequently asked questions

Related

• HIPAA page — HIPAA control mapping and the HASP posture in plain English.
• Data Processing Agreement — GDPR / CCPA companion to this BAA.
• Sub-processors — Full list of HASP-direct sub-processor BAAs.
• Trust Center — Compliance posture, framework attestations, verification.
• Security — Security controls.
• Audit and Trust — How the integrity-chained audit log works.