HASP and the GDPR
HASP operates as a processor under Article 28 of the General Data Protection Regulation. Our DPA is published before signature, the Standard Contractual Clauses are pre-incorporated, data subject rights are served by in-product tooling, and personal data breach notification is committed at 72 hours. This page is written for the DPO, privacy counsel, or procurement lead evaluating HASP's GDPR posture as a vendor.
HASP is your processor. You remain the controller.
For personal data that flows through the HASP platform — end-user accounts, structured application records, uploaded files, AI prompts and model outputs, audit-log payloads — the customer is the controller and HASP is the processor. HASP processes that data only on the customer's documented instructions, which are the configuration choices made inside the platform and the terms of the Agreement itself. The instructions extend to everything the Service does in normal operation: authenticating end users, storing records, evaluating policy, scanning content for PHI before it leaves your tenant, routing inference requests to an approved provider, and emitting an Ed25519-signed audit event for every step.
For data HASP collects to run its own business — billing contacts, marketing prospects, website visitors who opt in to analytics — HASP is the controller. That processing is governed by the Privacy Policy, not the DPA. The two roles are kept separate by design so a DPO can map each flow to the right legal instrument without guessing.
A DPA that's signed before you sign.
The HASP DPA is published at usehasp.com/legal/dpa and incorporated by reference into the Terms of Service. Every customer — Solo, Professional, Business, Enterprise, and Free Evaluation — is covered without a separate negotiation. There is no "DPA available on request" friction and no tier gate. The published DPA is the production instrument; Enterprise customers requiring a countersigned execution copy or a customer-paper redline can engage [email protected].
What the DPA commits to
- Processing only on documented controller instructions (Article 28(3)(a))
- Confidentiality obligations on all authorized HASP personnel
- Technical and organizational security measures (Article 32)
- Assistance with data subject requests (Article 28(3)(e))
- Assistance with DPIAs and prior consultation (Article 28(3)(f))
- 72-hour breach notification (Article 33)
- Sub-processor flow-down, with 30-day advance notice on changes
- Return or deletion of personal data on termination, at the controller's choice
- Audit and information rights necessary to demonstrate compliance
Annexes you can rely on
- Annex I.A — list of parties (controller details captured at signature; processor details fixed).
- Annex I.B — description of processing: categories of data subjects, categories of personal data, special category data (where the customer has executed a BAA), retention periods.
- Annex I.C — competent supervisory authority for SCC purposes, identified per controller establishment.
- Annex II — technical and organizational measures: encryption, access control, isolation, audit chain, PHI scanning, vulnerability management.
- Annex III — sub-processor register, kept in sync with the live sub-processor list.
Rights served by tooling, not tickets.
A processor is obligated under Article 28(3)(e) to assist the controller in responding to requests from data subjects. HASP goes further: most rights are served by self-service in-product tooling so the controller does not need to open a support thread to honour a statutory deadline.
End users can export their own account data and the records they own from Settings → Privacy & Data. Org admins can export org-wide data sets. Output is structured JSON plus original file attachments.
In-product profile editing. Application-record rectification is performed by the controller using the same CRUD primitives the rest of the platform is built on — no special path needed.
Account deletion triggers a 30-day offboarding window. After the window, personal data is removed from primary storage; the audit log retains a redacted record of the deletion event itself as required for accountability.
Controllers can suspend a member or freeze an app, halting all processing without destroying data — useful when a request is contested or pending verification.
The same export that serves Article 15 is machine-readable JSON, suitable for transfer to another controller or another vendor. Original file attachments are exported in their uploaded format.
Routed to the controller for substantive response; HASP will pause processing of an individual record on documented controller instruction. HASP does not perform decision-making with legal or similarly significant effect on data subjects on its own behalf (Article 22 inapplicable to HASP's processor role).
HASP maintains the Article 30(2) processor record. Enterprise customers can request an extract for their own Article 30(1) record at [email protected].
SCCs pre-incorporated. Supplementary measures documented.
HASP's default compliance substrate operates in United States regions on compliance- certified managed infrastructure. For personal data transferred from the EEA, the United Kingdom, or Switzerland to the United States, HASP relies on the European Commission's Standard Contractual Clauses (Implementing Decision (EU) 2021/914) with Module 2 (controller-to-processor), incorporated as Annex II of the DPA. The UK International Data Transfer Addendum and Swiss adequacy considerations are addressed in the same annex. Where a relevant sub-processor is certified under the EU–US Data Privacy Framework, HASP also relies on that adequacy mechanism in parallel.
Following Schrems II, SCCs are not enough on their own — supplementary technical and organizational measures must address foreseeable government access risk in the importer's jurisdiction. HASP's supplementary measures are listed in Annex II of the DPA and include: TLS 1.2+ enforced end-to-end, AES-256 encryption at rest, customer-controlled access revocation, role-based access control with optional SSO enforcement, HASP-owned PHI scanning before any inference provider is invoked, an Ed25519-signed audit chain, and a commitment to challenge any government access request that exceeds what applicable law strictly requires. A Transfer Impact Assessment template is available to Enterprise customers on request.
Default substrate
Solo, Professional, and Business tiers run on HASP's shared multi-tenant substrate in US regions, with row-level isolation and a SOC 2 Type II infrastructure layer inherited from the compliance substrate. Personal data residency on these tiers is "United States."
Enterprise residency options
Enterprise customers receive a dedicated data plane on dedicated managed infrastructure. Residency posture — US-only or EU-only (Frankfurt or Dublin region) — is captured in Annex I of the DPA before signature. Inference provider routing is similarly constrained where the customer requires it.
A live register and a 30-day notice commitment.
Our sub-processors page is mirrored in Annex III of the DPA. It includes infrastructure providers, edge/CDN providers, inference providers under direct integration, and operational providers (payment processor, transactional email provider, SSO provider, error-tracking provider, and analytics provider). For each entry the register names the purpose of processing and the region in which the sub-processor operates the relevant service.
HASP will notify customers at least 30 days before adding a new direct sub-processor or making a material change to an existing one. Customers may object during the notice period by writing to [email protected]. HASP will work with the customer in good faith to address objections, including by ceasing use of the affected sub-processor or, where no acceptable alternative exists, terminating the affected portion of the Service. For inference providers, customers on Business and Enterprise tiers can also restrict provider routing at the org level via inference policy, independent of the register-level commitment.
72 hours to you, written into the DPA.
On becoming aware of a personal data breach affecting customer data, HASP will notify the affected customer (as controller) without undue delay and in any event within 72 hours. The notification includes the nature of the breach, the categories and approximate number of data subjects affected, the categories and approximate number of personal data records affected, likely consequences, and the measures taken or proposed to address it — the elements a controller needs to satisfy its own Article 33 notification to the supervisory authority. Customer-impacting incidents are additionally posted to HASP's public status page and emailed to org owners promptly upon confirmation.
Every tier, every org, every Free Evaluation.
HASP's compliance substrate is universal — it is the product, not an upsell. The signed audit chain runs on every paid plan. The DPA covers every customer including Free Evaluation. PHI handling, when activated for healthcare-bound orgs, runs on the same HASP-owned infrastructure regardless of tier. The only attributes that scale with tier are dedicated-cluster isolation, audit-log retention windows, and the availability of named residency in Annex I. A single control set is engineered to satisfy GDPR, HIPAA, HITRUST, SOC 2, and CCPA / CPRA together, so a smaller customer is not paying for a weaker posture.
GDPR FAQ.
Is HASP GDPR compliant?
Yes. HASP operates as a processor under Article 28 of the GDPR for all personal data customers send through the platform. Our Data Processing Agreement is published and available before signature, our sub-processor register is public, data subject rights (Articles 15–21) are supported by self-service tooling, international transfers rely on the European Commission's Standard Contractual Clauses, and we commit to a 72-hour personal data breach notification SLA aligned with Article 33. GDPR posture applies to every paid tier and to Free Evaluation — there is no GDPR-gated upsell.
Is HASP a processor or a controller under GDPR?
For data customers send through the HASP platform — end-user accounts, application records, file attachments, AI prompts and outputs — HASP acts as a processor and the customer is the controller. For data HASP collects directly to run the business (billing contacts, marketing prospects, website analytics), HASP acts as the controller. The DPA covers the processor role; the Privacy Policy covers the controller role.
Does HASP sign a Data Processing Agreement (DPA)?
Yes. The DPA is published at usehasp.com/legal/dpa and incorporated by reference into the Terms of Service — every customer is covered, including Free Evaluation, with no separate negotiation required. Enterprise customers who require a countersigned copy or a customer-paper DPA review can contact [email protected]. The DPA includes the Standard Contractual Clauses (Module 2: controller-to-processor) as Annex II for transfers from the EEA, UK, and Switzerland.
What is the lawful basis for HASP's processing?
HASP processes personal data on documented instructions from the customer, who is the controller and is responsible for establishing a lawful basis under Article 6 — typically performance of a contract (Article 6(1)(b)) for end-user account data, or legitimate interests (Article 6(1)(f)) for workflow data. Where customers process special category data (including health data under Article 9), the customer is responsible for establishing an Article 9 condition and, for PHI under HIPAA, executing the separate BAA.
How does HASP support data subject rights under Articles 15–21?
Self-service tooling covers the common cases. Article 15 (access) and Article 20 (portability) are served by machine-readable data export in Settings → Privacy & Data. Article 16 (rectification) is served by in-product profile editing. Article 17 (erasure) is served by account deletion, which triggers a 30-day offboarding cascade that removes personal data from primary storage. Article 18 (restriction) and Article 21 (objection) are served by org-admin tooling plus a [email protected] escalation path. HASP also assists customers responding to their own data subject requests under Article 28(3)(e).
Where is data stored? Can EU customers get EU residency?
HASP's default compliance substrate runs in US regions. A global edge network handles request routing, but origin storage stays in the customer's chosen region. Enterprise customers who require a specific residency posture (US-only, or EU-only via dedicated EU-region cluster) can have that locked in writing as Annex I of the DPA before signature. Solo, Professional, and Business tiers run on the default US substrate.
How does HASP handle international transfers and Schrems II?
Transfers of personal data from the EEA, UK, or Switzerland to the United States rely on the European Commission's Standard Contractual Clauses (Implementing Decision (EU) 2021/914, Module 2). We supplement the SCCs with the technical and organizational measures listed in Annex II of the DPA — TLS 1.2+ in transit, AES-256 at rest, RBAC, signed audit chain, and PHI scanning before any inference provider is invoked. HASP also relies on the EU–US Data Privacy Framework where the relevant sub-processor is certified. Enterprise customers requiring a Transfer Impact Assessment package can request one from [email protected].
How are sub-processor changes communicated?
HASP commits to 30 days' advance notice before adding a new direct sub-processor or making a material change to an existing one. The live register is published at usehasp.com/sub-processors and mirrored in the DPA. Customers may object during the notice period by emailing [email protected]; HASP will work in good faith to address objections, including by ceasing use of the affected sub-processor or, where no acceptable alternative exists, terminating the affected portion of the Service.
What is HASP's personal data breach notification SLA?
HASP notifies affected customers (as controllers) without undue delay, and in any event within 72 hours of becoming aware of a personal data breach, in alignment with Article 33. Notification includes the nature of the breach, categories and approximate number of data subjects affected, likely consequences, and measures taken or proposed. Customer-impacting incidents are also surfaced on the public status page and by email promptly upon confirmation.
Does HASP keep an Article 30 record of processing activities?
Yes. HASP maintains an Article 30(2) record of processing carried out on behalf of controllers, covering categories of processing, transfer destinations, and the technical and organizational measures applied. Enterprise customers can request an extract for their own Article 30(1) record by emailing [email protected].