Drippa Data Processing Agreement
Last updated: 8 October 2026
This Data Processing Agreement ("DPA") forms part of the Terms of Service, or any other agreement for Drippa, between Drippa, Inc. ("Drippa") and the customer ("Customer") (together, the "Agreement"). It applies whenever Drippa processes personal data for Customer. By accepting the Agreement, Customer accepts this DPA. A countersigned copy is available on request from privacy@drippa.ai.
1. Definitions
- Data Protection Laws: the GDPR, UK GDPR, Swiss FADP, the Norwegian Personal Data Act, the CCPA and other laws on personal data that apply to the processing.
- Personal Data: any information relating to an identified or identifiable person that Drippa processes for Customer under the Agreement.
- Sub-processor: a third party Drippa engages to process Personal Data.
- Security Incident: a confirmed breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Personal Data.
- SCCs: the standard contractual clauses approved by the European Commission in Decision (EU) 2021/914.
Other terms such as controller, processor, processing and data subject have the meanings given in the GDPR.
2. Roles
Customer is the controller of Personal Data, and Drippa is its processor. Where Customer is itself a processor for its own customers, Drippa is a sub-processor. Annex 1 describes the processing.
For the CCPA, Drippa is a service provider. Drippa will not sell or share Personal Data, will not keep, use or disclose it outside the business purpose of providing the service, and will not combine it with personal data from other sources except as the CCPA allows.
3. Customer's obligations
Customer confirms that it has a lawful basis for the processing, has given any notices and obtained any consents required, and is entitled to connect its tools and environments to Drippa. Customer will not send Drippa special categories of personal data unless agreed in writing.
4. Drippa's obligations
Drippa will:
- process Personal Data only on Customer's documented instructions, which are the Agreement and Customer's use of the service, unless the law requires otherwise (in which case Drippa will tell Customer first, unless the law forbids it);
- tell Customer if it believes an instruction breaks Data Protection Laws;
- make sure anyone who processes Personal Data is bound by confidentiality;
- maintain the security measures in Annex 3;
- help Customer, taking into account the nature of the processing, to respond to data subject requests and with impact assessments and consultations with authorities;
- tell Customer about any legally binding request from an authority for Personal Data, unless the law forbids it, and challenge requests that are not lawful.
5. Sub-processors
5.1 Customer gives Drippa general authorization to use Sub-processors. The current list is in Annex 2 and on the Trust Center.
5.2 Drippa will give at least 30 days' notice by email to the account owner before adding or replacing a Sub-processor.
5.3 Customer may object on reasonable data protection grounds within 15 days of the notice. The parties will try in good faith to resolve it. If they cannot within 30 days, Customer may end the affected service and receive a refund of prepaid fees for the unused term.
5.4 Drippa will bind each Sub-processor to data protection terms at least as protective as this DPA, and remains liable for its Sub-processors.
6. Security Incidents
6.1 Drippa will notify Customer without undue delay, and within 72 hours, after becoming aware of a Security Incident.
6.2 The notice will include, as far as known: what happened, the types and rough number of people and records affected, the likely consequences, what Drippa has done or plans to do, and a contact person. Drippa will send more information as it becomes available.
6.3 Drippa will cooperate with Customer to investigate and limit the incident. Notifying data subjects and authorities is Customer's decision. Drippa will not contact them directly unless Customer asks or the law requires it.
6.4 A notice is not an admission of fault or liability.
7. Return and deletion
7.1 Customer can ask for an export of its data within 30 days after the Agreement ends.
7.2 Drippa will then delete Personal Data: workspace data (including connected tool content, review outputs and recordings) within 30 days, and account data within 90 days. Copies in backups are removed as the backups expire, within 30 days. Copies of source code in review sandboxes expire 7 days after last use.
7.3 Drippa may keep invoices and billing records as the law requires. On request, Drippa will confirm deletion in writing.
8. International transfers
8.1 Where Personal Data is transferred from the EEA to a country without an adequacy decision, the SCCs apply and are incorporated by reference: Module 2 where Customer is a controller, and Module 3 where Customer is a processor. For the SCCs: clause 7 (docking) applies; under clause 9 Drippa has general authorization with the notice period in section 5.2; clause 11's optional wording does not apply; the supervisory authority is the one competent for Customer; clauses 17 and 18 refer to the law and courts of Ireland. Annexes 1 to 3 of this DPA complete the SCC annexes.
8.2 For the UK, the UK International Data Transfer Addendum applies. For Switzerland, the SCCs apply with references to the GDPR read as the FADP and the Swiss FDPIC as the authority.
8.3 Where a Sub-processor is certified under the EU-US Data Privacy Framework, transfers to it may also rely on that framework.
9. Audits
9.1 On reasonable written request, Drippa will give Customer the information needed to show compliance with this DPA.
9.2 Drippa will share its SOC 2 Type II report once issued, and Customer agrees to rely on it where it covers Customer's questions.
9.3 If this is not enough, or a regulator requires it, Customer may audit once a year, at its own cost, with 30 days' notice, during business hours and under confidentiality.
10. Liability and order of precedence
Each party's liability under this DPA is subject to the limits in the Agreement, unless Data Protection Laws do not allow this. For Personal Data, this DPA wins over the rest of the Agreement, and the SCCs win over this DPA. This DPA lasts as long as Drippa processes Personal Data for Customer.
Annex 1: Details of processing
| Item | Detail |
|---|---|
| Parties | Data exporter: Customer (controller or processor). Data importer: Drippa, Inc. (processor or sub-processor), contact privacy@drippa.ai |
| Subject matter and purpose | Providing the Drippa service: turning product intent into structured work, reviewing whether shipped changes match intent, and generating outputs such as reviews, test steps, walkthrough recordings, summaries and suggested tickets |
| Nature of processing | Collecting, storing, analyzing and deleting data from connected tools; running review agents in Customer's environments with credentials Customer provides; processing source code in isolated sandboxes; sending task data to AI models |
| Data subjects | Customer's employees and contractors, and any people named in Customer's connected tools or shown in its test environments |
| Types of Personal Data | Names, user IDs and emails of users; numeric author IDs from GitHub (login, avatar and email are dropped on receipt); free text that may contain names, such as pull request descriptions, tickets, Slack threads and meeting notes; personal data in source code; screenshots and recordings of Customer's environments, which may show test-user data |
| Special categories | None intended. Customer will not send them unless agreed in writing |
| Frequency | Continuous, while the service is in use |
| Duration and retention | For the term of the Agreement, then deleted as set out in section 7. Recordings are kept for the life of the account. Source code in review sandboxes expires 7 days after last use and is not copied into Drippa's database |
Annex 2: Sub-processors
| Sub-processor | Purpose | Location |
|---|---|---|
| Vercel | Application hosting and isolated code review sandboxes | EU (Stockholm, Sweden) |
| Supabase | Database, authentication and file storage | EU (Stockholm, Sweden) |
| Anthropic | AI model processing | United States |
| TypeSafe AI | AI model processing (Jev) | United States |
| Google (Workspace) | Email and support communication | United States |
| Stripe | Payment processing (billing contacts only) | United States |
The current list is always on the Trust Center.
Annex 3: Security measures
- Encryption: AES-256 at rest, TLS 1.2 or higher in transit, with keys managed under a written key management policy.
- Access control: least-privilege access to production, multi-factor authentication on critical systems, and access removed promptly when people leave.
- Tenant separation: all customer data is scoped by organization, with role-based access in the app.
- Credentials for Customer systems: stored encrypted, scoped by Customer, used only to provide the service, and revocable by Customer at any time.
- Code isolation: source code is processed in isolated sandboxes with no network access, which expire 7 days after last use.
- Data minimization: GitHub identity fields are replaced with opaque IDs on receipt.
- Logging and monitoring: audit logs of data changes with actor context, application tracing and automatic alerts.
- Secure development: peer-reviewed changes under a change management policy, automated dependency scanning, and a yearly external penetration test.
- Incident response: a written incident management procedure, with Customer notice within 72 hours as set out in section 6.
- Resilience: managed cloud infrastructure, daily database backups, and a disaster recovery plan tested every year.
- Vendors: sub-processors are reviewed before onboarding and every year after.
- People: confidentiality obligations and yearly security awareness training for everyone with access.
- Assurance: Drippa's controls are being audited against SOC 2 Type II.


