Data Processing Agreement
Version 2026-10-16. Part of the Terms of Service between the Customer and the PipeKeel company for its region (Sangita Enterprise, India; Mukherjee Technology Solutions Ltd., United States / Canada).
1. Roles and scope
The Customer is the controller (or a processor for its own clients) of personal data in Customer Data; PipeKeel is its processor (or sub-processor). This DPA applies whenever PipeKeel processes that personal data to provide the Service. Applicable law includes India's Digital Personal Data Protection Act 2023, Canada's PIPEDA (and provincial laws such as Quebec's Law 25) and US state privacy laws, as they apply to the Customer's data.
| Subject matter | providing the Service: running the Customer's pipelines and workflows, storing their configuration, support |
| Duration | the term of the agreement, plus the deletion period in §8 |
| Nature and purpose | reading, transforming, loading and storing data as the Customer's pipelines define; storing credentials to reach the Customer's systems |
| Personal data | whatever the Customer's pipelines process (decided by the Customer); users' account data |
| Data subjects | the Customer's users; people whose data is in Customer Data (e.g. the Customer's customers or employees) |
2. Instructions
PipeKeel processes personal data only on the Customer's documented instructions — the agreement, the pipelines and settings the Customer configures, and written instructions — unless the law requires otherwise (then PipeKeel will tell the Customer first, where allowed). PipeKeel will say if it believes an instruction breaks the law.
Sovereign execution: queries run in the Customer's Google Cloud project as the Customer's service account; PipeKeel reads job status and statistics, not rows (except where the Customer requests a data preview, which is shown in the browser and not stored, or a data quality check, which returns counts). Express and Relay process rows in PipeKeel's workers in the Customer's home region; Relay keeps them in memory only.
Streams: real-time Pub/Sub streams run as subscriptions in the Customer's Google Cloud project; real-time Kafka streams of Sovereign pipelines run in a worker pool in the Customer's project. Real- time Kafka streams of Express pipelines are read by PipeKeel's stream worker in the United States (Oracle Cloud, Phoenix, Arizona) whatever the home region: records are held in memory for a few seconds while they're transformed and written to the Customer's targets, and are not stored there.
3. Confidentiality
Everyone at PipeKeel or its sub-processors who can access personal data is bound by confidentiality. PipeKeel has no standing access to Customer Data; support access is the minimum needed, logged, and recorded in the Customer's audit log.
4. Security
PipeKeel implements the measures in Annex 1 and keeps them at least as protective during the term.
5. Sub-processors
The Customer authorizes the sub-processors listed in Annex 2. PipeKeel will give at least 30 days' notice of a new sub-processor (in-app and by email to the owner); the Customer may object on reasonable data-protection grounds, and if no solution is found, terminate the affected Service with a pro-rated refund. PipeKeel imposes data-protection terms on each sub-processor at least as protective as this DPA and remains responsible for them.
6. Assistance
PipeKeel helps the Customer, taking into account the nature of the processing, to answer data subjects' requests (the Service lets the Customer find, export and delete its data), with security, and with breach notifications and impact assessments.
7. Personal data breaches
PipeKeel will notify the Customer without undue delay, and in any case within 72 hours, after becoming aware of a breach affecting the Customer's personal data, with what is known (nature, categories and approximate numbers, likely consequences, measures taken) and updates as more is learned, so the Customer can meet its own obligations (for example to the Data Protection Board of India or the Privacy Commissioner of Canada).
8. Return and deletion
The Customer can export its pipelines (YAML / SQL) and audit log at any time. After the agreement ends, PipeKeel deletes the Customer's data within 30 days (backups expire within 35 days), unless the law requires keeping it. Data in the Customer's own cloud (Sovereign) is never held by PipeKeel.
9. Audits
PipeKeel makes available the information needed to show compliance with this DPA — this document, its security measures, and summaries of independent assessments when they exist. The Customer may audit once a year, on 30 days' notice, at its own cost, in a way that doesn't compromise other customers' data or PipeKeel's security.
10. Transfers
Account and configuration data is stored in the United States (Oracle Cloud, Phoenix, Arizona; and Google Cloud, us-central1). Express data is processed and stored in the Customer's home region, except real-time Kafka streams, which pass through the United States in memory (§2). Transfers follow the applicable law (including any countries restricted under India's DPDP Act).
11. Liability
Liability under this DPA is subject to the limits in the Terms.
Annex 1 — Security measures
- Isolation: every record is scoped to its organization at the database layer; automated tests check that one organization can't reach another's data. Per-organization service accounts, storage buckets and datasets.
- Access: two-factor authentication (organization-enforceable), role- and object-level permissions, re-authentication for sensitive actions, IP allow-lists, session timeouts.
- Credentials: stored in Google Secret Manager; the API can write but not read them; only the component running a task can read the secrets that task needs. Customers may keep credentials in their own Secret Manager instead.
- Encryption: TLS in transit; encryption at rest; two-factor secrets encrypted with Cloud KMS.
- Execution: signed, short-lived task instructions; sandboxed, single-tenant worker executions; network egress guarded against internal addresses. The stream worker receives each stream's signed instructions and a one-hour credential for that organization only, allowed to read just that stream's secrets.
- Logging: an append-only, hash-chained audit log per organization; credentials and data values redacted from logs.
- Resilience: encrypted backups in a separate location, regular restore tests.
- Development: code review, automated security scanning of code and dependencies, security review before releases, and an external penetration test before general availability.
- People: least-privilege access to production; incident response procedure.
Annex 2 — Sub-processors
| Sub-processor | Purpose | Location |
|---|---|---|
| Google Cloud (Google LLC / Google Cloud India) | Express and Relay workers, storage, BigQuery, Secret Manager, KMS, backups | the Customer's home region (Express data); United States, us-central1 (platform) |
| Oracle Cloud Infrastructure | PipeKeel's control plane (API, database) and the Express stream worker | United States (Phoenix, Arizona) |
| Cloudflare | edge network: TLS, firewall, DDoS protection | global |
| Hostinger | hosting the website and the web application's static files (no Customer Data) | United States (Phoenix, Arizona) |
| Mailjet (Sinch) | sending service and alert emails | EU |
| Stripe | payments (US / Canada) | US |
| Razorpay | payments (India) | India |
Slack, email recipients, webhooks, APIs, Google Sheets, Pub/Sub topics, Kafka clusters and the stores (e.g. Shopify, WooCommerce) the Customer connects are the Customer's own systems and destinations, not PipeKeel's sub-processors.