Why redline now — before Rules notify
The Digital Personal Data Protection Act 2023 is enacted. The Rules — which operationalise consent format, breach timing, transfer SCCs, grievance handling, and Significant Data Fiduciary obligations — are expected to notify during 2026. The contract clauses that follow are written to anticipate the draft Rules language as published for consultation; they will be refined when final Rules are notified. Verify with counsel.
For an India-based fiduciary running 200 to 2,000 people in IT services, BPO, KPO, financial services, or healthcare administration, the practical question is when to amend existing contracts. The right answer is now, for three reasons. First, most workforce-AI and SaaS vendor MSAs were drafted for jurisdictions that operate on consent-by-default and broad-purpose processing; they do not allocate DPDP duties to the vendor. Second, once Rules notify, every vendor will be facing simultaneous redline requests from every Indian customer, which weakens your negotiating position. Third, contract renewals on 12-month or multi-year cycles will lag the regulatory window unless they are re-papered ahead of Rules notification.
This template gives the seven must-have clauses, the exact paragraph language, and the vendor pushback playbook. Drop the language into your Data Processing Addendum (DPA). Keep the commercial MSA clean — the DPA is updated as DPDP guidance evolves without re-opening pricing. For the broader DPDP buyer guide and 8-vendor compliance scorecard, see the DPDP Act 2023 Workforce Monitoring — India Buyer's Guide.
The 7 must-have DPDP contract clauses
| # | Clause | DPDP backstop | Negotiation weight |
|---|---|---|---|
| 1 | Data Fiduciary / Data Processor designation | Section 2(i), 8 | Non-negotiable |
| 2 | Granular consent and consent ledger access | Section 6, 7 | Non-negotiable |
| 3 | Purpose limitation and processing instructions | Section 8(2) | Non-negotiable |
| 4 | Breach notification cascade (24-hour vendor-to-fiduciary) | Section 8(6) | Negotiate down from 72-hour vendor default |
| 5 | Cross-border transfer assessment + sub-processor list | Section 16, 8(3) | Standard; 30-day notice on adds |
| 6 | Data principal rights handling (access, correction, erasure) | Section 11, 12, 13 | Standard; SLA negotiable |
| 7 | Exit, data export, and deletion certification | Section 8(7) | Non-negotiable; cap retention to 60 days |
The clauses below are drafted to be added to a DPA referenced by the MSA. They are written in plain commercial English with the legal substance anchored to DPDP statutory sections. Have your counsel review and adapt before use.
Clause 1 — Data Fiduciary / Data Processor designation
This clause is the foundation. Without it, the statutory allocation of duties between the fiduciary and the processor is ambiguous, and the fiduciary retains all the risk by default.
1.1 Designation. The parties acknowledge and agree that, with respect to
all Personal Data of the Customer's employees, contractors, candidates,
and other workforce data principals processed by the Vendor through the
Services, the Customer is the Data Fiduciary and the Vendor is the Data
Processor as those terms are defined under Section 2 of the Digital
Personal Data Protection Act 2023 ("DPDP Act").
1.2 Scope of processing. The Vendor shall process Personal Data only
(a) for the purposes specified in Schedule A (Permitted Purposes), and
(b) on documented instructions from the Customer, except where required
by applicable law. The Vendor shall not determine the purposes of
processing of Personal Data independently of the Customer.
1.3 Compliance support. The Vendor shall, at the Customer's reasonable
request and at no incremental cost during the term, provide such
information and assistance as the Customer requires to demonstrate
compliance with the DPDP Act, including responding to inquiries from
the Data Protection Board and to data principal grievances.
1.4 No re-identification. The Vendor shall not attempt to re-identify
any pseudonymised or anonymised data derived from Personal Data, and
shall not combine Personal Data with other data sources for any purpose
other than the Permitted Purposes.Clause 2 — Granular consent and consent ledger
This clause translates the DPDP consent obligation into an operational requirement on the vendor's product. The consent ledger is the system of record; the contract requires fiduciary access to it.
2.1 Granular consent capture. The Vendor's product shall capture
consent from each data principal at the level of individual processing
purpose, as enumerated in Schedule A. Bundled consent across multiple
purposes is not permitted. Each consent action shall be recorded with
(a) the data principal identifier, (b) the purpose for which consent is
given, (c) the version of the consent text presented, (d) the timestamp
of the consent, and (e) the form of presentation (UI, written, etc.).
2.2 Consent withdrawal. Each consent action shall be independently
withdrawable by the data principal through the Vendor's product, with
withdrawal taking effect within twenty-four (24) hours of the
withdrawal action. Withdrawal of consent for one purpose shall not
disable the data principal's access to other features for which
consent remains valid.
2.3 Consent ledger access. The Vendor shall maintain a Consent Ledger
recording all consent and withdrawal events. The Vendor shall provide
the Customer's Data Protection Officer with API or UI access to the
Consent Ledger, and shall produce a complete ledger extract for any
specified data principal within five (5) business days of a request.
2.4 Retention of the Consent Ledger. The Consent Ledger shall be
retained for the longer of (a) seven (7) years from the date of the
event, or (b) such period as is required under applicable law.Pushback to expect: vendors will resist the 24-hour withdrawal SLA, preferring 7-day windows tied to nightly batch jobs. Hold firm; 24 hours is operationally achievable and DPDP defensible. For the ledger retention period, 7 years tracks Indian commercial-record practice and is broadly acceptable.
Clause 3 — Purpose limitation and processing instructions
This clause prevents scope creep. It is the contractual counterpart to the DPDP Section 8(2) purpose-limitation obligation.
3.1 Permitted Purposes. The Vendor shall process Personal Data only
for the Permitted Purposes enumerated in Schedule A. Processing for
any other purpose, including for the Vendor's own product analytics,
internal training of machine learning models, or marketing, is
prohibited unless the Customer has provided specific written consent
referencing the new purpose.
3.2 Excluded categories. The Vendor shall not perform, and the product
shall not be capable of performing, processing in the following
excluded categories without separate written consent:
(a) inference of emotional state, mood, or sentiment from any input;
(b) inference of physical or mental health status or wellbeing;
(c) inference of political opinion, religious belief, or membership
of a protected class;
(d) scoring of stress, burnout risk, or psychological state;
(e) processing of Personal Data of any individual under 18 years of
age except in compliance with Section 9 of the DPDP Act.
3.3 No scope creep. The Vendor shall not use Personal Data collected
under a Permitted Purpose for any secondary purpose, including but
not limited to performance evaluation, termination decisions,
recruitment screening, or wellbeing programmes, except where each
such secondary purpose has been added to Schedule A with separate
data principal consent recorded in the Consent Ledger.Many vendor MSAs include a broad “product improvement” carve-out that allows the vendor to use customer data for ML training or analytics. Under DPDP, this is processing for a separate purpose and requires separate data principal consent — not just customer consent. Strike the carve-out. The vendor can request anonymised aggregate metrics with a specific separate clause if needed.
Clause 4 — Breach notification cascade
This is where most negotiations stall. The fiduciary has 72 hours under DPDP draft Rules to notify CERT-In and the Data Protection Board (and affected data principals where applicable). The vendor must notify fast enough that the fiduciary can meet that window. 24 hours is the practical target.
4.1 Vendor breach notification SLA. The Vendor shall notify the
Customer in writing of any Personal Data Breach (as that term is
defined under the DPDP Act and applicable Rules) involving Personal
Data processed under this Agreement within twenty-four (24) hours
of the Vendor's discovery or reasonable suspicion of the breach.
4.2 Content of notification. Each breach notification shall include,
at minimum:
(a) the date and time the breach occurred or was discovered;
(b) the categories of Personal Data affected;
(c) the number of data principals affected (estimated if final
figure is not yet available);
(d) the root cause of the breach, to the extent known at the time;
(e) the technical and organisational measures the Vendor has taken
to contain the breach;
(f) the further measures the Vendor proposes to take;
(g) the name and contact details of the Vendor's incident response
lead.
4.3 Continuing duty. The Vendor shall provide updates to the Customer
no less frequently than every twenty-four (24) hours from initial
notification until the breach is fully contained and a final root
cause analysis is delivered.
4.4 Breach drill. The Vendor shall conduct, no less than annually, a
breach response drill simulating the most likely Personal Data Breach
scenarios under the Services. A redacted summary of the most recent
drill shall be made available to the Customer on request.
4.5 No payment for notification. The Vendor shall not condition breach
notification on payment, subscription status, or any other commercial
factor.Clause 5 — Cross-border transfer assessment and sub-processor list
Cross-border transfers are governed under Section 16 of the DPDP Act. The central government may publish a list of permitted destinations (a positive-list approach). Until that list is comprehensive, transfers require contractual safeguards.
5.1 Sub-processor list. The Vendor shall maintain a current list of
all sub-processors used in connection with the Services, including
the country in which each sub-processor processes Personal Data. The
list shall be made available to the Customer on request and shall be
maintained on the Vendor's trust portal at all times.
5.2 New sub-processors. The Vendor shall notify the Customer in
writing at least thirty (30) days in advance of any new sub-processor
addition. The Customer shall have the right to object to the addition
within fifteen (15) days of notification, in which case the parties
shall negotiate in good faith. If no resolution is reached within
thirty (30) days of the objection, the Customer may terminate the
affected portion of the Services without penalty.
5.3 Cross-border transfer assessment. Where Personal Data is
transferred outside India, the Vendor shall execute SCC-equivalent
contract language (or, when published, contract language approved
by the Data Protection Board) with each sub-processor receiving the
transferred data. The Vendor shall provide the Customer with a copy
of the executed agreement on request.
5.4 India-hosting option. On the Customer's written request and at no
incremental cost during the initial term of this Agreement, the
Vendor shall confine processing and storage of Personal Data under
this Agreement to data centres located in India.
5.5 Government access requests. The Vendor shall notify the Customer
within seventy-two (72) hours of any government or law-enforcement
request for Personal Data processed under this Agreement, except
where notification is prohibited by applicable law, in which case
the Vendor shall provide the Customer with a transparency report
no less frequently than quarterly.Clause 6 — Data principal rights handling
This clause requires the vendor to support the fiduciary's response to data principal rights requests under DPDP Sections 11, 12, and 13.
6.1 Rights handling support. The Vendor shall provide the Customer
with the technical means to respond to data principal rights
requests under the DPDP Act, including:
(a) Right of access (Section 11): the Vendor shall produce a complete
extract of all Personal Data of a specified data principal in a
structured, commonly used format, within five (5) business days
of a request.
(b) Right to correction (Section 12): the Vendor's product shall
allow correction of inaccurate Personal Data on data principal
request, with correction taking effect within twenty-four (24)
hours of the request.
(c) Right to erasure (Section 12): the Vendor shall delete all
Personal Data of a specified data principal within thirty (30)
days of an erasure request, except where retention is required
under applicable law or for the limited categories specified in
Schedule B (Erasure Exceptions).
(d) Right to grievance redressal (Section 13): the Vendor shall
designate a Data Protection Officer and shall acknowledge each
grievance within forty-eight (48) hours and resolve it within
thirty (30) days.
6.2 Grievance reporting. The Vendor shall provide the Customer with
a monthly grievance report showing the number of grievances received,
the median resolution time, and the categories of grievances
addressed under this Agreement.Clause 7 — Exit, export, and deletion certification
This is the clause that vendors most often water down. Tight wording protects the fiduciary's ability to switch vendors and discharge its own deletion obligations.
7.1 Data export on exit. On termination of this Agreement for any
reason, the Vendor shall, within thirty (30) days of the termination
effective date, export all Personal Data processed under this
Agreement to the Customer in a structured, commonly used, machine-
readable format (CSV or JSON unless otherwise agreed). The export
shall include the Consent Ledger extract, audit logs, and any
metadata necessary for the Customer to operate the data in a
successor system.
7.2 Deletion within 60 days. Within sixty (60) days of the
termination effective date (or, if later, fifteen (15) days following
delivery of the export), the Vendor shall permanently delete all
copies of Personal Data from production systems, backups, sub-
processor systems, and any other location under the Vendor's
control or its sub-processors' control, except for the limited
retention permitted under Clause 7.4.
7.3 Deletion certificate. Within seventy-five (75) days of the
termination effective date, the Vendor shall deliver to the Customer
a signed Deletion Certificate confirming the deletion required under
Clause 7.2, identifying any data retained under Clause 7.4 and the
basis for such retention, and identifying the personnel responsible
for the deletion process.
7.4 Permitted retention. The Vendor may retain (a) Personal Data
required to be retained under applicable law, for the minimum period
required; (b) aggregated, anonymised metrics from which no data
principal can be re-identified, for the Vendor's product
improvement; and (c) Personal Data subject to an active legal hold,
for the duration of the hold. All other retention is prohibited.
7.5 No commercial conditioning. The Vendor shall not condition data
export or deletion certification on payment of outstanding charges
that are not subject to a bona fide dispute, on subscription
renewal, or on any other commercial factor.Vendor pushback playbook
From procurement teams running DPDP redline negotiations through Q1-Q2 2026, these are the most common vendor objections and the counter-positions that hold.
| Vendor pushback | Typical request | Counter-position |
|---|---|---|
| Breach SLA | 72 hours to fiduciary | 24 hours, with continuing-duty updates every 24h. Fiduciary needs the window to meet its own statutory 72-hour DPB obligation. |
| Sub-processor adds | Notify-only, no objection right | 30-day prior notification + 15-day objection window + good-faith negotiation. Otherwise terminate-without-penalty right on the affected portion. |
| India-hosting | Available “at vendor's prevailing rates” | At no incremental cost during the initial term. Lock the cost at signature if it's a likely future need. |
| Product improvement carve-out | Vendor may use data for ML training and analytics | Strike. Replace with a specific anonymised-aggregate carve-out if needed, with re-identification prohibition. |
| Deletion retention | 120-180 days post-termination for “billing reconciliation” | 60 days, with permitted-retention exceptions listed in Schedule B. |
| Consent ledger access | Vendor produces extracts on request, no API | API or UI access for the fiduciary DPO; 5-business-day SLA on extract requests. |
| Grievance SLA | 30-day acknowledge / 90-day resolve | 48-hour acknowledge / 30-day resolve. DPDP Rules drafts trend in this direction. |
| Audit rights | None, or vendor SOC 2 report only | Annual fiduciary audit right (third party, NDA-bound) plus SOC 2 / ISO 27001 reports. Reasonable cost-sharing. |
DPA schedules — what to attach
The clauses above reference five schedules. Get them right and the contract works; get them generic and the contract is hollow.
Schedule A — Permitted Purposes
Enumerate every specific purpose for which the vendor may process Personal Data. “Productivity intelligence” is too broad. “Time-on-task computation from calendar metadata for purposes of workload visibility” is correct. List 8-15 purposes; one bullet per. Generic schedules collapse purpose limitation. Each item should be reviewable against an actual data flow.
Schedule B — Erasure Exceptions
List the categories of data the vendor may retain post-erasure request and the legal basis. Typical categories: payroll-related records under Indian Income Tax Act retention requirements, audit logs under labour law, contractual dispute records under Limitation Act. Each line should reference the underlying retention requirement.
Schedule C — Sub-processor List
Each sub-processor name, registered office country, the country of processing, and the function performed (hosting, email delivery, CDN, analytics, helpdesk). Keep updated on the trust portal.
Schedule D — Technical and Organisational Measures
The TOMs the vendor commits to: encryption-at-rest, encryption-in-transit, access controls, MFA, network isolation, vulnerability management cadence, employee training cadence, background checks, SOC 2 or ISO 27001 status, India CERT-In notification process. This is the document a future Data Protection Board inquiry will ask for first.
Schedule E — Data Flow Diagram
A one-page diagram showing the categories of Personal Data, the points of capture, the processing stages, the storage locations, the sub-processors involved, and the retention periods. The diagram is the operational view of the legal text in Clauses 1-7. Counsel-friendly and DPB-friendly.
How gStride accepts these redlines
gStride's standard DPA already incorporates the seven clauses above. The key concessions:
- Breach notification SLA. 24 hours from discovery, with structured incident report format and continuing-duty updates.
- Consent ledger API. Per-feature consent capture with API access for fiduciary DPO; 24-hour withdrawal SLA.
- Excluded categories. Emotion inference, stress scoring, and wellbeing prediction excluded by architecture — not by toggle.
- India-hosting option. Available at no incremental cost during the initial term for India-based fiduciaries.
- Sub-processor notification. 30-day prior notification, with 15-day objection window and termination-without-penalty on unresolved objection for the affected portion.
- Deletion certification. 30-day export, 60-day deletion, 75-day signed certificate. No retention carve-out for ML training.
- Audit rights. Annual third-party fiduciary audit right (NDA-bound) plus SOC 2 in progress and DPDP-readiness statement.
Get the DPDP Vendor Risk Assessment scorecard
The companion to this redline template is the free DPDP Vendor Risk Assessment — a 25-question interactive scorecard that scores any vendor against the seven clauses above and produces a board-ready memo. Use it as your shortlist filter before sending out RFPs.
Frequently asked questions
Why do I need DPDP redline language in my vendor RFP?
Most workforce-AI and SaaS vendor standard MSAs are written for jurisdictions where consent-by-default and broad-purpose contracts are acceptable. Under DPDP Act 2023, employer (data fiduciary) liability flows through to the vendor (data processor) only if the contract explicitly allocates obligations. Redline language is how you translate DPDP statutory duties into enforceable contract terms. Without redline, the fiduciary retains all the risk. Verify with counsel.
When should I add DPDP clauses to my contracts?
Now. DPDP Act 2023 is enacted; Rules notification is expected during 2026. Contract renewals, new procurements, and existing high-value SaaS contracts should be re-papered before Rules notification closes the implementation runway. Waiting until Rules notify means renegotiating from a weaker position once vendors are responding to many simultaneous redline requests. Verify with counsel.
What are the 7 must-have DPDP contract clauses?
1. Data fiduciary / processor designation under Section 8. 2. Granular consent and consent ledger access. 3. Purpose limitation and processing instructions. 4. 72-hour breach notification cascade. 5. Cross-border transfer assessment and sub-processor list. 6. Data principal rights handling (access, correction, erasure). 7. Exit clause with data export, retention period, and deletion certification.
What is the typical vendor pushback on DPDP redlines?
Three common pushback areas. First, breach SLA — vendors often resist 24-hour notification, preferring 48-72 hours; the fiduciary needs 24 to meet its own 72-hour statutory obligation. Second, sub-processor pre-approval — vendors want to add sub-processors at will; fiduciary should hold a 30-day prior-notification right. Third, deletion certification — vendors want extended retention windows for billing reconciliation; fiduciary should cap to 60 days post-termination. Counter each with explicit DPDP statutory backstop. Verify with counsel.
Does my contract need a separate DPA or is MSA language enough?
Best practice is a standalone Data Processing Addendum (DPA) referenced by the MSA. The DPA can be updated as DPDP Rules notify and subsequent DPB guidance lands, without re-opening the entire MSA. A DPA also allows vendor-specific data flow descriptions, sub-processor lists, and audit-log schemas to be appended as schedules. The MSA carries the commercial terms; the DPA carries the data terms. Verify with counsel.
What is a consent ledger and what should the contract require?
A consent ledger is the system of record for every consent given and withdrawn by a data principal, with timestamps, version, purpose, and proof artifact. Under DPDP, the data fiduciary must demonstrate proof of consent on demand. The contract should require: (a) per-feature consent capture inside the vendor product, (b) API access to the consent ledger for the fiduciary, (c) consent withdrawal to take effect within an SLA (typically 24 hours), and (d) retention of the ledger for at least 7 years post-termination. Verify with counsel.
Does gStride accept these redline clauses?
Yes. The gStride standard DPA already covers the seven must-have DPDP clauses including 24-hour breach notification SLA, granular consent ledger with API access, India-hosting option, 30-day sub-processor prior-notification, and 60-day deletion certification. The DPA is signed at contract execution; there is no path to deploy without it. Verify with your own counsel before relying on this in a regulatory submission.
Disclaimer. This redline template reflects gStride AI's current interpretation of the Digital Personal Data Protection Act 2023 and the draft Rules in circulation as of May 2026. The clause language is drafted for use as a starting point for negotiation between commercial parties and is not legal advice. Rules notification and subsequent Data Protection Board guidance may change the operational obligations described here. Verify with your own counsel before relying on any clause in a regulatory submission, contract, or board document. Questions about this template: press@gstride.ai.