Data Processing Agreement — draft

Provided here in English for convenience — the French version is the legally relevant text.

This is not a document ready to sign.

Two things must be true before this can become a real, binding DPA: (1) it must be reviewed by a lawyer — this page is a standard-shape template listing this product's actual sub-processors, not a legal opinion; and (2) the publisher (see the legal notice) is not yet formally registered as a business — a DPA is a contract between two legal entities, and that registration has to exist first. Contact assyamekhanteur@gmail.com to discuss where things stand before relying on this for a procurement decision.

1. Parties and definitions

This Data Processing Agreement ("DPA") forms part of the agreement between the customer using Vetora's service (the "Controller") and Vetora's publisher (the "Processor", see the legal notice for identity), governing the Processor's processing of personal data on the Controller's behalf. Terms not defined here have the meaning given to them by the GDPR (Regulation (EU) 2016/679).

2. Subject matter and duration

The Processor processes personal data on the Controller's behalf for the duration of the Controller's use of the Service (free scan, paid report, or Continuous Monitoring / Team plan subscription), and until deletion under Section 9.

3. Nature, purpose, and categories of data

The Service is a black-box security scanner for web applications. Depending on which features the Controller uses, the Processor may process:

  • Contact details of the Controller's own account holders and organization members (email address, authentication data)
  • The URL(s) submitted for scanning, and the scan results (security findings) derived from what is already publicly reachable at that URL
  • API request metadata for the CI/API integration (IP address, timestamps, API key usage)
  • Billing data processed via Stripe (see sub-processors below) — Vetora itself never stores full card numbers
  • Slack workspace/channel identifiers, only if the Controller explicitly connects Slack alerts for an organization

The Service does not access the Controller's source code or server infrastructure — only what is already reachable by a normal visitor over HTTP(S) (see the methodology page).

4. Categories of data subjects

  • The Controller's own account holders and organization members
  • Individuals whose personal data may incidentally appear in a scanned page's public content or in a detected finding (e.g. an email address hardcoded in exposed source, if the Controller's own site leaks one) — the Processor does not seek this data out, it is a byproduct of scanning what the Controller's site itself exposes

5. Processor obligations

The Processor commits to:

  • Process personal data only on the Controller's documented instructions (operating the Service as described), unless required otherwise by EU or member-state law
  • Ensure staff/contributors with access to personal data are bound by confidentiality
  • Implement appropriate technical and organizational security measures (see Section 6)
  • Assist the Controller in responding to data subject rights requests and, where applicable, data protection impact assessments
  • Notify the Controller without undue delay after becoming aware of a personal data breach
  • Not engage a new sub-processor without informing the Controller (see Section 7)

6. Security measures

Measures currently in place, described accurately rather than exhaustively:

  • Row Level Security (RLS) enabled on every database table, with write access to sensitive tables gated by an application-layer role check, not RLS alone
  • Secrets (API keys, management/session tokens) stored as one-way hashes, never in plain text
  • Optional multi-factor authentication (TOTP) for account holders, enforceable per organization
  • Per-endpoint rate limiting to bound abuse
  • An internal audit log of sensitive actions (key creation/revocation, membership changes, payments, active-check consent)
  • TLS in transit for every connection to the Service

This list will need to be reviewed and formalized (ideally against ISO 27001 / SOC 2-style control categories) as part of the legal review this page itself calls for.

7. Sub-processors

The Processor currently uses the following sub-processors, strictly for operating the Service:

Sub-processorPurposeLocation
Supabase Inc.Database hosting, authenticationProject region to be confirmed — check the Supabase project dashboard
Stripe Payments Europe, Ltd.Payment and subscription processingEU (Ireland) + US, per Stripe's own DPA
Resend, Inc.Transactional email (alerts, management links)United States
Functional Software, Inc. (Sentry)Error monitoringUnited States
Vercel Inc.Application hosting, traffic measurementUnited States
PostHog Inc.Product usage analytics — server-side events only, no cookie or browser scriptUnited States (self-hosted or EU-region PostHog Cloud possible, depending on configuration)
Slack Technologies, LLCOptional alert delivery — only if the Controller connects it for an organizationUnited States

Several of these are established, or process data, outside the European Union. The specific safeguards each relies on (standard contractual clauses, adequacy decisions) have not yet been individually verified and documented here — part of the pre-review work this page calls out.

8. Data subject rights

The Controller is responsible for responding to its own data subjects' GDPR rights requests. Where a request concerns data the Processor holds on the Controller's behalf, the Processor will provide reasonable assistance. Account holders can also exercise their own rights directly — see account settings for self-service export and deletion.

9. Data retention and deletion

On termination of the Controller's use of the Service, the Processor deletes or anonymizes personal data processed on the Controller's behalf within a reasonable time, except where a longer legal retention obligation applies (notably billing records). See the privacy policy for the current retention specifics.

10. Audit

The Processor will make available information reasonably necessary to demonstrate compliance with this DPA and allow for audits, including inspections, conducted by the Controller or an auditor mandated by the Controller, subject to reasonable notice and confidentiality.

Signatures

Not applicable until the two conditions in the notice above are met. Placeholder fields (Controller name, Processor legal name once registered, date, signatures) would go here in a finalized version.