Data Processing Agreement (DPA)
Contents
1. Definitions
"Act" means the Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023). "Rules" means the Digital Personal Data Protection Rules, 2025 issued under the Act. "Data Fiduciary", "Data Processor", "Data Principal", "personal data" and "personal data breach" have the meanings given in Section 2 of the Act.
"Customer Personal Data" means the personal data of the Customer's end-users (Data Principals) that the Customer routes through DPDP Bridge APIs and SDK, including consent grants, withdrawals, erasure requests, breach records, grievance tickets, dpToken claims, and audit-log entries derived from these items. It does not include the Customer's tenant administrator account data.
2. Layered roles
Layer A — Processor (this DPA)
Subject: Customer Personal Data routed by the Customer through DPDP Bridge.
Customer = Data Fiduciary. The Customer determines the purpose and means.
DPDP Bridge = Data Processor. We process only on the Customer's documented instructions, set out in this DPA, in the API documentation, and in the configuration the Customer selects in the dashboard.
Layer B — Fiduciary (Privacy Notice)
Subject: Tenant administrator data — emails, hashed passwords, billing identifiers, audit metadata about who pressed which admin button.
DPDP Bridge = Data Fiduciary. We determine the purpose and means.
Governed by the Privacy Notice. Section 8 obligations apply directly to us in this layer.
Customers occasionally ask whether DPDP Bridge is "indirectly" the Data Fiduciary for the routed end-user data because we determine technical means (HMAC, TLS, retention defaults). The answer is no. The purpose — serving the Customer's product to its end-users — is determined entirely by the Customer; technical means delivered through configurable defaults remain the Processor's territory. We document this position in the audit log so a Board inquiry has a clean factual record.
3. Processor obligations
As Processor we will:
- Process Customer Personal Data only on the Customer's documented instructions, including transfers, unless required by Indian law (in which case we will inform the Customer of that legal requirement before processing, unless the law prohibits notification).
- Ensure that personnel with access to Customer Personal Data are bound by confidentiality obligations.
- Implement the technical and organisational measures listed in §4 (Schedule III TOM checklist).
- Engage sub-processors only as listed in §5; notify the Customer at least 30 days in advance of any new sub-processor with a right of objection.
- Assist the Customer in responding to Data Principal requests under Sections 11–14 (see §7).
- Notify the Customer of a personal data breach without undue delay and in any event within 72 hours of discovery (see §8).
- Make available all information necessary to demonstrate compliance with this DPA and allow for audits (see §9).
- At the choice of the Customer, delete or return all Customer Personal Data after the end of the provision of services (see §10).
4. Technical and organisational measures (Rules 2025 Schedule III)
The following table maps each Schedule III item to the corresponding DPDP Bridge control. Schedule III enumerates "reasonable security safeguards" expected of Data Fiduciaries; we adopt the same baseline as Processor so the Customer can rely on the controls without an independent gap analysis.
| Schedule III item | DPDP Bridge control | Status |
|---|---|---|
| Encryption / masking / virtual tokens | TLS 1.2+ in transit; AES-256 at rest (provider-managed keys, KMS); HMAC-SHA256 on dpToken; bcrypt on tenant passwords | In place |
| Access controls and access review | Per-tenant API keys; role-based admin access; quarterly engineering access review; production access requires MFA | In place |
| Logs / monitoring / detection | Append-only audit_log retained 7 years; Sentry error monitoring; rate limiter at the edge with 429 audit signal | In place |
| Continuity safeguards (backups, BCP) | Daily automated SQLite/Postgres snapshots; 30-day backup retention; documented runbook | In place |
| Maintain logs to detect and remediate breach | Audit ledger + Sentry integration + breach module (POST /breach/incident) start the Section 8(6) clock automatically | In place |
| Reasonable measures by sub-processors (back-to-back) | Each sub-processor in §5 contractually bound to equivalent or stronger controls (AWS DPA, Stripe DPA, Sentry DPA, Resend DPA on file) | In place |
5. Sub-processors
Current sub-processor list (effective 2026-05-08):
| Sub-processor | Purpose | Region | DPA on file |
|---|---|---|---|
| Amazon Web Services, Inc. | Compute, storage, networking | India (Mumbai, ap-south-1) | Yes (AWS Service Terms + DPA) |
| Stripe Payments India Pvt Ltd | Subscription billing, invoicing | Global (Stripe processes Indian transactions through its India entity) | Yes (Stripe DPA) |
| Sentry (Functional Software, Inc.) | Error monitoring, no PII payloads | United States | Yes (Sentry DPA) |
| Resend Inc. | Transactional email delivery | United States, with EU peering | Yes (Resend DPA) |
Notification of new sub-processors will be sent at least 30 days in advance to the email on the tenant account, with a right to object. If the Customer objects on reasonable data-protection grounds we will either decline the change or, if we proceed, give the Customer the right to terminate the affected service for convenience without penalty.
6. Cross-border transfer (Section 16)
The Indian government may, by notification under Section 16(1), restrict the transfer of personal data to a particular country or territory. As of the effective date no country has been restricted. Sentry and Resend currently process data in the United States; the AWS region is India (Mumbai). If a sub-processor's region is later notified as restricted, we will, within 30 days of the notification, migrate the affected processing to a permitted region and notify Customers in writing.
7. Data Principal requests
The Customer remains the Data Fiduciary and is responsible for responding to Sections 11–14 requests directly to the Data Principal. As Processor we provide tooling for the Customer to honour the request:
- Access (Section 11) — the Customer can export Data Principal data via
GET /consent/:externalIdand the audit-log endpoint. - Correction / Erasure (Section 12) —
POST /erasure/requestwith a dpToken creates a tracked erasure request that fires webhooks to the Customer's downstream systems. - Grievance (Section 13) — the Customer's DPO console surfaces a 30-day SLA timer (Rule 14).
- Nominate (Section 14) — the Customer manages nomination flows in its product; we do not store nomination data on the Customer's behalf.
8. Personal data breach — notification timetable
On discovery of a personal data breach affecting Customer Personal Data we will, in this order:
- Notify the Customer within 72 hours of discovery via the contact email on the tenant account, with the information set out in Rule 7(2): nature of the breach, categories and approximate number of Data Principals, likely consequences, mitigations applied, and a single point of contact for follow-up.
- If DPDP Bridge is itself the breached Data Fiduciary for tenant administrator data (Layer B), we will, in addition, notify the Data Protection Board directly within 72 hours via the form prescribed in Rule 7(1), and notify the affected tenants as soon as practicable.
- Where the Customer is a Significant Data Fiduciary (SDF), we will treat the 72-hour clock as a hard deadline irrespective of the Customer's own internal triage cadence, because Section 10 creates additional Board-reporting obligations on the SDF that depend on prompt Processor notice. Customers may elect a 24-hour Processor notification SLA for an additional fee.
9. Audit rights
The Customer may, on 14 days' written notice and at its own cost, audit our compliance with this DPA once per calendar year, or more frequently if required by an enforceable Board direction. The audit may take the form of a desk review of the SOC 2 Type II report (when available) or, by mutual agreement, an on-site visit limited to information-security controls relevant to Customer Personal Data. We will not be obligated to disclose information about other customers, internal cost data, or trade-secret implementation details.
10. Termination and deletion
On termination of the Customer's subscription we will, at the Customer's choice expressed within 30 days of termination, return Customer Personal Data in JSON or delete it. After 30 days we delete it automatically subject to a 7-year retention of the compliance audit ledger (which contains no Data Principal personal data, only event metadata and identifiers). Backups are deleted on the next 30-day rolling cycle.
11. Liability
The liability cap in Section 8 of the Terms of Service applies to this DPA. Nothing in this DPA limits liability for fraud, gross negligence, wilful misconduct, or any liability that cannot be excluded under applicable law including a Board penalty arising directly from our breach of this DPA.
12. Governing law & precedence
This DPA is governed by the laws of India and follows the dispute resolution mechanism of the Terms of Service (Mumbai-seated MCIA arbitration). In the event of conflict between this DPA and the Terms of Service in respect of Customer Personal Data, this DPA prevails.
Schedule A — Acceptance
This DPA is incorporated by reference when the Customer accepts the Terms of Service or executes an Order Form. Customers requiring a counter-signed copy on company paper may request one at hi@dpdp-bridge.com — we will turn around within 5 business days at no extra fee.