Data processing agreement

This data processing agreement ("DPA") is between the customer that accepted the DebugGo terms of service ("Customer", "you") and DebugGo, run by its founder as a sole proprietor (an individual, not a registered company) based in California, United States ("DebugGo", "we"). It applies whenever DebugGo processes personal data on your behalf while providing the DebugGo service: the embeddable widget, the dashboard, the agent API and the command-line tool (together, the "Service").

This DPA takes effect when you accept the terms of service and does not need a signature. If you need a countersigned copy, write to support@debuggo.dev.

• Customer Data means all data submitted to the Service through your installation of the widget, your dashboard, your secret keys or your review links, including the personal data in it.
• Account Data means the data DebugGo holds about you as its customer: sign-in details, organization and project settings, billing records and support correspondence. Account Data is covered by the privacy policy, not this DPA.
• Data Protection Laws means the laws that apply to the processing of personal data under this DPA, including the EU and UK General Data Protection Regulation, the Swiss Federal Act on Data Protection, and the California Consumer Privacy Act as amended, where applicable.
• Sub-processor means a third party DebugGo engages to process Customer Data.
• Security Incident means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Data.
• "Controller", "processor", "data subject", "personal data" and "processing" have the meanings given in Data Protection Laws.

For Customer Data, you are the controller (or a processor acting for your own customers) and DebugGo is your processor. DebugGo processes Customer Data only to provide the Service and only on your documented instructions.

For Account Data, DebugGo is an independent controller. The privacy policy explains that processing.

The widget data sheet is the technical description of this processing and forms part of this DPA.

Your documented instructions are: the terms of service, this DPA, the settings you choose in the dashboard (visibility, capture mode, retention period, connected repository, digest addresses), and the requests your team makes through the dashboard, the agent API and the CLI. DebugGo will not process Customer Data for any other purpose, and will not sell it, share it for advertising, or use it to train models.

If DebugGo believes an instruction infringes Data Protection Laws, it will tell you before acting on it, and may suspend that instruction until the matter is resolved.

• You are responsible for having a lawful basis for the data your installation collects, and for the notices your visitors and reviewers receive. Paste-ready text is on the text for your privacy policy page.
• Where the law that applies to your visitors requires consent for loading a third-party script or for capturing console and network activity, you obtain it before the widget loads or captures. The consent page shows how.
• You do not use the Service to collect special categories of personal data, payment card data, government identifiers or data about children, and you do not install an "everyone" widget on pages where such data is likely to appear in the console.
• You keep review links private, disable them when a review ends, and treat anyone who holds one as able to read the project's review comments.
• You set the diagnostics retention period and delete submissions when you no longer need them or when a data subject asks you to.

DebugGo maintains the following measures. They describe the Service as built; see the security page for detail.

• All traffic between browsers, the widget, the dashboard and DebugGo uses TLS.
• Data is encrypted at rest by the database and storage provider, Supabase.
• Every database row belongs to an organization and row-level security policies in the database enforce that members of one organization cannot read another's data.
• Dashboard sign-in uses Supabase Auth with hashed passwords, or GitHub or Google sign-in. Sessions are cookie-based and expire.
• Agent secret keys are stored only as SHA-256 hashes, shown once at creation, and can be revoked at any time. The public widget key grants no read access.
• Screenshots and review attachments are stored in private buckets and served through short-lived signed URLs; nothing in storage is publicly listable.
• Submissions are validated and size-capped, rate-limited per project and per reviewer, and pass through a redactor that removes email addresses, tokens, credentials, card numbers and long key-like strings before storage.
• No IP addresses are stored in the database. Infrastructure request logs are held by the providers for their standard retention period.
• Console messages, failed-request logs, browser strings and bug-report screenshots are deleted automatically after the project's retention period, 30 days by default.
• Any submission can be permanently deleted from the dashboard, the agent API or the CLI.
• Production access is limited to one person, the founder, with multi-factor authentication on the provider accounts.
• Backups are taken by Supabase and retained for 7 days.
• Supabase and Vercel publish their own security certifications (including SOC 2 Type II reports) on their trust pages. DebugGo itself has not commissioned an independent penetration test.

You give DebugGo general authorisation to engage the sub-processors listed on the sub-processors page. At the date of this DPA they are: Supabase, Vercel, Resend, Stripe (only when you buy a paid plan), GitHub (only when you connect a repository or sign in with github).

DebugGo gives each sub-processor data protection obligations no less protective than this DPA and remains responsible for their performance. Before a new sub-processor processes Customer Data, DebugGo updates the page and emails the owners of each organization at least 30 days in advance. If you object on reasonable data protection grounds and the parties cannot resolve it, you may terminate the affected Service and receive a pro-rata refund of prepaid fees.

DebugGo limits access to Customer Data to people who need it to provide the Service or support you, and binds them to confidentiality obligations that survive the end of their engagement.

The Service lets you answer most requests yourself: the dashboard, agent API and CLI can find a submission by email address, reviewer name, page or project, read it in full, export it and delete it permanently. If a data subject contacts DebugGo directly about Customer Data, DebugGo forwards the request to you within 5 business days and does not respond on its own except to confirm it has been forwarded, unless the law requires otherwise. DebugGo provides further reasonable assistance at your request, at its then-current rates where the assistance goes beyond what the Service provides.

DebugGo notifies you of a Security Incident affecting Customer Data without undue delay and no later than 72 hours after becoming aware of it. The notice describes what is known about the nature of the incident, the data and data subjects affected, the likely consequences and the measures taken, and is updated as the investigation continues. DebugGo cooperates with your own notifications to authorities and data subjects.

During the term you can export Customer Data through the agent API and CLI and delete any submission permanently from the dashboard, the agent API or the CLI. Diagnostics are deleted automatically after the project's retention period.

When the terms of service end, you have 30 days to export Customer Data. After that, or sooner if you ask, DebugGo deletes Customer Data within 30 days, except for copies held in backups, which expire on the schedule in clause 7, and data DebugGo must keep by law. DebugGo confirms deletion in writing on request.

Taking into account the nature of the processing, DebugGo helps you meet your obligations on security, incident notification, data protection impact assessments and prior consultation with authorities. The data sheet, the security page and this DPA are intended to answer most assessment questions without a separate request.

DebugGo makes available the information needed to demonstrate compliance with this DPA: the published documentation, the sub-processors' own audit reports where DebugGo may share them, and written answers to reasonable questions. If that is not enough to meet a legal requirement, you may audit DebugGo's compliance once in any twelve-month period, on at least 30 days' notice, during business hours, at your own cost, under confidentiality, and without disrupting the Service.

Customer Data is stored and processed in the locations listed on the sub-processors page. Where Data Protection Laws restrict a transfer of Customer Data to one of those locations, the parties rely on the EU Standard Contractual Clauses (Module 2, controller to processor, and Module 3 where you act as processor) with the UK International Data Transfer Addendum and the Swiss amendments. The clauses are incorporated by reference and prevail over this DPA in case of conflict.

Each party's liability under this DPA is subject to the limitations and exclusions in the terms of service, except where Data Protection Laws do not allow a liability to be limited.

This DPA lasts for as long as DebugGo processes Customer Data. If it conflicts with the terms of service on a data protection matter, this DPA prevails; if it conflicts with the standard contractual clauses, the clauses prevail. Changes to this DPA are made the same way as changes to the terms of service.

Questions about this DPA: support@debuggo.dev.