1. Definitions
This DPA is intended to address Sigbot's processing of personal data of individuals connected to the United Kingdom, European Economic Area, Canada, and United States. Region-specific terms are set out in the Annexes below.
- "Applicable Data Protection Law" means all data protection and privacy laws applicable to the processing under this DPA, including the UK GDPR and Data Protection Act 2018; the EU GDPR; Canada's PIPEDA and applicable provincial legislation; and applicable US state privacy laws including the CCPA/CPRA.
- "Controller" (= "Business" under the CCPA, "Organization" under PIPEDA) determines the purposes and means of processing. "Processor" (= "Service Provider" under the CCPA) processes on the Controller's behalf.
- "Customer Data" means the personal data Sigbot processes on Customer's behalf, principally contact and signature information extracted from Customer's connected email accounts.
- "Standard Contractual Clauses" / "SCCs" means the European Commission's Standard Contractual Clauses (Decision (EU) 2021/914); "UK Addendum" means the ICO's International Data Transfer Addendum to the SCCs.
- "Subprocessor" means any third party engaged by Sigbot to process Customer Data.
2. Roles of the Parties
Customer is the Controller of Customer Data; Sigbot is the Processor acting on Customer's documented instructions, as set out in the Terms of Service, this DPA, and Customer's ordinary configuration of the Services. If Sigbot believes an instruction infringes Applicable Data Protection Law, it will inform Customer and may suspend that instruction pending clarification.
3. Subject Matter and Details of Processing
4. Sigbot's Obligations
- Process Customer Data only on documented instructions, including regarding international transfers;
- Ensure personnel are bound by confidentiality obligations;
- Implement the security measures described in Section 8;
- Assist Customer in responding to data subject rights requests (Section 7);
- Assist Customer with its own obligations around security, breach notification, and impact assessments;
- Delete or return Customer Data at the end of the relationship (Section 10); and
- Make information available to demonstrate compliance and support audits (Section 9).
5. Subprocessing
Customer provides a general authorisation for Sigbot to engage the Subprocessors below. Sigbot will give at least 14 days' notice before adding or replacing a Subprocessor, during which Customer may object on reasonable data-protection grounds.
The same list, with the data each Subprocessor receives, is published at sigbot.co/legal/subprocessors.html, where Customer can also ask to be emailed each notice.
PostHog, Inc. (product analytics, PostHog EU Cloud) is added to the list below with effect from 14 October 2026. PostHog receives usage events from the Sigbot web app — for example, that a scan finished and how many contacts it filed — keyed by a pseudonymous account id. It receives no contact records, email content or email addresses, and is set to discard IP addresses. To object, write to legal@sigbot.co before 14 October 2026.
| Subprocessor | Purpose | Location / Transfer Mechanism |
|---|---|---|
| Google Cloud Platform (Google LLC) | Cloud hosting & infrastructure: database (Cloud Firestore), Cloud Functions, secrets management, logging and monitoring | Customer Data stored in the EU (Firestore eur3) and processed in the UK (europe-west2, London); application logs in europe-west2; mandatory audit logs not pinned to a region (see Section 6) — SCCs & UK Addendum for UK/EEA-originating data |
| Firebase (Google LLC) | Application backend and authentication (Firebase Authentication holds account sign-in data: email address, password hash, sign-in providers) | Not pinned to a region; Google states that Firebase Authentication runs from data centres in the United States — SCCs & UK Addendum for UK/EEA-originating data |
| Google Cloud Vision (Google LLC) | Optical character recognition for business-card scanning; images are processed in memory and are not kept by Google or by Sigbot | European Union (Cloud Vision EU endpoint, which processes data only in the EU) — no restricted transfer for UK/EEA-originating data |
| Anthropic PBC | AI-assisted parsing of the text of an email signature block (at most 4,000 characters per message) into contact fields, and classification of a company's sector from the text of its public website — only while AI parsing is switched on for the account and, for a team scan, for the team. Under Anthropic's commercial terms, Anthropic does not use these inputs or outputs to train its models and deletes them within 30 days, unless its safety systems flag them (then kept for up to 2 years) or the law requires longer. | US — Anthropic's data processing addendum, with SCCs & UK Addendum for UK/EEA-originating data |
| Vercel Inc. | Web application hosting & content delivery (processes request metadata such as IP addresses and logs) | US-based, global edge network — SCCs & UK IDTA addendum for UK/EEA-originating data |
| Paddle.com Market Ltd | Payment processing, billing and tax as merchant of record. Paddle is an independent controller for payment data. | UK/EU/US — Paddle's SCCs for UK/EEA-originating data |
| Resend, Inc. | Transactional email — email verification, password reset, team invitations, team notices, and order and service emails (processes the recipient's address and the message content) | US — SCCs & UK Addendum for UK/EEA-originating data |
| PostHog, Inc. (from 14 October 2026) | Product analytics for the web app: usage events keyed by a pseudonymous account id; no contact records, email content or email addresses; IP addresses discarded | EU (PostHog EU Cloud, Frankfurt, Germany); PostHog's staff and some of its own subprocessors may access data from outside the UK/EEA — PostHog's DPA, with SCCs, the UK Addendum and the EU-US Data Privacy Framework |
| OpenStreetMap Foundation (Nominatim) | Geocoding of contact postal addresses for the map view. The request is sent from the user's browser or phone, so the provider receives the address text and that device's IP address. | UK / EU — no restricted transfer for UK/EEA-originating data |
| komoot GmbH (Photon) | Fallback geocoding of contact postal addresses for the map view. The request is sent from the user's browser or phone, so the provider receives the address text and that device's IP address. | Germany (EU) — no restricted transfer for UK/EEA-originating data |
6. International Data Transfers
Customer Data is stored in the European Union (Google Cloud Firestore, multi-region eur3) and processed by Sigbot's Cloud Functions in the United Kingdom (Google Cloud europe-west2, London). Business-card images are read by Google Cloud Vision's EU endpoint, which processes them only in the European Union. Sigbot's application and request logs — which can hold IP addresses, account ids and contact email addresses in redacted form (first character and domain only) — are stored in Google Cloud Logging in europe-west2 (London), as is the separate security log described in Annex D. Log entries written before 28 September 2026 are held in Google's global location until they expire, no later than 28 October 2026.
Two Google services that Sigbot relies on are not pinned to a region: Firebase Authentication, which holds account sign-in data (email address, password hash and sign-in providers) and which Google states runs from data centres in the United States; and Google Cloud's mandatory audit logs (the _Required log bucket, kept 400 days), which record administrative changes to Sigbot's cloud project and are held in Google's global location.
A restricted transfer therefore arises for those two Google services; for the Subprocessors in Section 5 located in the United States (Anthropic, Vercel and Resend); and for PostHog, which stores data in the EU but whose staff and subprocessors may access it from outside the UK/EEA. Transfers out of the UK/EEA rely on: an adequacy decision (Canada's federal regime under PIPEDA currently benefits from UK/EU adequacy findings for PIPEDA-covered organisations, and the UK and the EU recognise each other as adequate); the SCCs and UK Addendum for transfers to the United States or other non-adequate jurisdictions; or another valid transfer mechanism, such as the EU-US Data Privacy Framework and its UK Extension for a certified recipient. For data collected in Canada, Sigbot ensures Subprocessors outside Canada provide comparable protection as required under PIPEDA.
7. Data Subject Rights
Sigbot will assist Customer, insofar as reasonably possible, in responding to requests from data subjects exercising their rights (access, rectification, erasure, restriction, portability, objection). If Sigbot receives a request directly from a data subject, it will not respond substantively without Customer's authorisation and will promptly forward the request to Customer.
8. Security Measures
Sigbot implements technical and organisational measures appropriate to the risk, set out in Annex D and described on our Security Overview page, including encryption in transit and at rest, application-level encryption of mailbox tokens, role-based access controls and a role-based permission matrix per team (see Roles and permissions), OAuth-based authentication where supported, two-step verification rolling out to every account (authenticator app), automatic retention and deletion on the schedule published in the Security Overview, logging and monitoring, and a defined incident response process.
Sigbot will notify Customer of a personal data breach affecting Customer Data without undue delay and in any case within 72 hours of becoming aware of it. The notice will give what is known at the time — the nature of the breach, the categories and approximate numbers of people and records concerned, the likely consequences, and the measures taken or proposed — and Sigbot will add to it as more becomes known, so that Customer can meet its own notification obligations.
9. Audit Rights
Sigbot will make information available to demonstrate compliance and allow audits by Customer or its mandated auditor, no more than once per year absent a regulatory requirement or breach, on 30 days' notice, during business hours, with Customer bearing its own audit costs.
10. Deletion and Return of Data
Customer Data that Customer deletes through the Services is erased on the schedule published on the Security Overview: individual records after a 30-day restore window (or at once when Customer chooses "Delete permanently"), and everything held for an account at once when Customer deletes the account. Copies in backups age out within 14 days of erasure. On termination or Customer's written request, Sigbot will delete or return all remaining Customer Data within 30 days, except where retention is required by law, in which case that data is isolated and protected from further processing.
United Kingdom / European Economic Area
Applies where Customer Data is subject to the UK GDPR, UK Data Protection Act 2018, and/or EU GDPR.
- Sigbot processes Customer Data as a Processor under Article 28 UK/EU GDPR, per Sections 1–10 above.
- Transfers to non-adequate jurisdictions (including the United States) rely on the SCCs and, where applicable, the UK Addendum.
- Customer may request a standalone SCCs/UK Addendum document by contacting legal@sigbot.co.
- Breach-notification obligations to the ICO / relevant EU supervisory authority remain with Customer as Controller; Sigbot provides the assistance described in Section 8.
Canada
Applies where Customer Data is subject to PIPEDA or substantially similar provincial law (e.g. Quebec's Law 25, BC's PIPA, Alberta's PIPA).
- Sigbot acts as a service provider processing Personal Information on behalf of Customer (the accountable organization under PIPEDA).
- Security safeguards appropriate to the sensitivity of the Personal Information are maintained, per Section 8.
- In the event of a breach of security safeguards creating a real risk of significant harm, Sigbot will notify Customer without unreasonable delay, with sufficient information for Customer to meet its own notification obligations to the Privacy Commissioner of Canada and affected individuals.
- Sigbot assists with access and correction requests, and — for Customers subject to Quebec's Law 25 — with information needed for a privacy impact assessment before any disclosure outside Quebec.
United States
Applies where Customer Data is "Personal Information" of a "Consumer" under the CCPA, or subject to a comparable state law (Virginia CDPA, Colorado CPA, Connecticut CTDPA, Utah UCPA, and similar).
- Sigbot is a "Service Provider" (not a "Third Party") receiving Personal Information from Customer, a "Business," for the business purpose of providing the Services.
- Sigbot will not sell or share Customer Data; will not retain, use, or disclose it outside the business purpose of performing the Services or the direct business relationship; and will not combine it with data from other sources except as permitted under the CCPA.
- Sigbot certifies it understands and will comply with these restrictions.
- Sigbot provides reasonable cooperation for verifiable consumer requests to know, delete, correct, or opt out.
Technical and Organisational Measures
This Annex sets out the measures Sigbot applies to Customer Data under Section 8, as they stand on the date at the top of this DPA. Statements that begin "Sigbot requires" or "Sigbot's policy is" are rules Sigbot holds itself to; the rest describe how the Services are built. Sigbot may change these measures, provided the overall level of protection is not reduced. The Security Overview has more detail, and the retention periods in its section 9 form part of this Annex.
1. Encryption
- Connections to the web app, Sigbot's backend and Sigbot's providers use TLS. The web app (
sigbot.app) sends HTTP Strict Transport Security for two years, including subdomains, and the whole.appdomain is on browsers' built-in HTTPS-only list. - Data at rest in Google Cloud is encrypted by Google's default at-rest encryption.
- Mailbox access and refresh tokens are additionally encrypted by Sigbot with AES-256-GCM, under a key held in Google Secret Manager.
- API keys and other credentials are held in Google Secret Manager, not in source code.
2. Access control — customers and their users
- Passwords must be at least 8 characters with a lower-case letter, an upper-case letter and a number, enforced by the authentication service.
- Account holders can turn on two-step verification with an authenticator app (TOTP) in the web app, and a team owner can require it for admin actions.
- An account's email address must be verified, by a link sent to it or by the sign-in provider, before Sigbot will scan a mailbox for it. Accounts opened before 9 September 2026 have until 1 November 2026 to verify.
- Deleting an account and signing out other devices require a recent sign-in. Email-enumeration protection is switched on in the sign-in service.
- Scans, mailbox connections and other sensitive calls are rate-limited per account.
3. Access control — data
- Database security rules limit each account to its own records and, in a team, to what the member's role allows. Mailbox tokens, website enquiries and other server-only records cannot be read or written from any app or browser; only Sigbot's backend reaches them.
- In a team, every action is checked on the server against the member's role, folder grants and the team's permission matrix (see Roles and permissions). Contacts marked private are masked for other members, and a team's audit log is written only by the server.
- Mailboxes are connected by OAuth with read-only scopes (
Mail.Read,User.Read,offline_accessfor Microsoft). Sigbot never receives the mailbox password, and disconnecting a mailbox deletes its tokens. Microsoft Outlook, connected this way, is the only mailbox connection Sigbot's apps offer.
4. Data minimisation
- Email bodies, subjects, recipients and headers are read in memory to find the signature and are not stored; attachments are never downloaded. Only a SHA-256 hash of each message id is kept, for 180 days, so a message is not scanned twice.
- When AI parsing is on, only the signature block of an email (at most 4,000 characters) is sent to the AI provider, never the rest of the message, and during a mailbox scan only when Sigbot's built-in parser is unsure of its result. AI parsing can be switched off per account and per team.
- Business-card images are not stored.
- Sigbot's code redacts email addresses in application logs to the first character and the domain.
- Product analytics carry a pseudonymous account id, never an email address or contact data.
5. Retention and deletion
- Retention is enforced automatically, by database time-to-live policies and a daily purge, on the schedule in the Security Overview (section 9).
- Deleted contacts stay in Trash for 30 days, then are erased; Delete permanently erases at once. Deleting an account erases the Customer Data in it at once, except records already shared into a team, which stay with the team. Backups age out within 14 days, and logs on the schedule in item 7 of this Annex.
- Account holders can export their data at any time (Download my data, contact exports) and can erase every record for an address or domain, and stop it being collected again, with a scan rule.
6. Availability and resilience
- The database is Google Cloud Firestore in the
eur3multi-region, which Google replicates across more than one European region. - Point-in-time recovery (7 days) and daily backups (kept 14 days) are enabled, and the database has deletion protection. Restoring from backup was last rehearsed on 27 September 2026.
7. Logging, monitoring and incident response
- Application logs are kept for 30 days, as is the authentication service's request log of sign-ins, sign-ups and account changes (the email address used, the IP address and the outcome). A separate security log, drawn from them, keeps refused and failed sign-ins, sign-ups and requests, failed mailbox connections, reads of stored secrets, and staff and administrative actions for 400 days. Google Cloud admin-activity audit logs are kept for 400 days. The locations are given in Section 6.
- Alerts notify Sigbot of scan and mailbox-connection failures, server errors, payment-webhook failures and outages, and a nightly job reconciles billing records with Paddle.
- Sigbot has a written incident response plan covering detection, containment, evidence, and notice to customers under Section 8 and to regulators and individuals where Sigbot is controller.
8. People and internal access
- Sigbot's policy is that staff reach production systems and Customer Data only to operate, support or secure the Services, or to carry out a done-for-you build the Customer has ordered. For a build, staff see the contact records the scan produced, never email content (which Sigbot does not store).
- Sigbot's policy is that every staff account with access to production systems uses multi-factor authentication. Sigbot keeps a register of that access, reviews it quarterly, and is completing the roll-out of multi-factor authentication across its service providers.
- Sigbot requires everyone with access to Customer Data to be bound by confidentiality obligations.
- Sigbot has a privacy lead, reachable at legal@sigbot.co, and a security contact at security@sigbot.co.
9. Development and vulnerability management
- Sigbot's policy is that code changes are type-checked and tested before they are deployed to production. An automated check scans code for personal data before it is committed.
- Security reports are handled under the Vulnerability Disclosure Policy. No independent penetration test has been carried out yet; the Security Overview will publish the date and a summary once one has.
10. Infrastructure and Subprocessors
- Sigbot runs no servers of its own. Physical and environmental security of the infrastructure is provided by Google Cloud and, for delivering the web app, Vercel.
- Each Subprocessor in Section 5 processes Customer Data under a data protection agreement with Sigbot, except the public geocoding services (Nominatim and Photon), which receive an address lookup directly from the user's device and handle it under their own published privacy policies. Sigbot gives 14 days' notice of any addition or replacement.