Why an RFP-shaped DPDP question set, not a vendor scorecard
There are two procurement moments. The first is when the buyer puts the requirement to the market and asks vendors what they can do — that is the RFP. The second is when the vendor responses come back and the buyer ranks them — that is the scorecard. The two moments need different artefacts.
A scorecard is closed-form: a checklist of clauses scored RED, AMBER, GREEN against a fixed rubric. An RFP is open-form: a structured set of questions that surfaces the vendor's actual compliance architecture, not just a yes/no answer. The mistake most India buyers make is using the scorecard format in the RFP and missing the architectural disclosures that only come out when the vendor has to write paragraphs.
This article is the RFP-question artefact. It pairs with the scoring artefact (the DPDP Vendor Risk Assessment Worksheet) and the contract artefact (the DPDP Vendor RFP Redline Template). Use the questions to draft your RFP. Use the worksheet to score the vendor responses. Use the redline template to bake the accepted responses into the contract.
The 15 questions cluster into five DPDP themes. Each question lists: the question text suitable for paste into your RFP, the DPDP Section it anchors against, the GDPR Article 28 parallel (so EU customer questionnaires can be answered from the same response), the RED / AMBER / GREEN response patterns, and the follow-up probe to use if the vendor's response is too thin. All references are written under the DPDP Act 2023 as enacted; Rules notification is still expected and may change operational specifics — verify with counsel.
Cluster 1 — Fiduciary roles and processing scope (DPDP Sections 2, 4, 10)
The first cluster establishes who is processing whose data for what. Get this wrong and every subsequent clause sits on sand. Three questions.
Q1. Define the role you take under the DPDP Act 2023 when processing our employee personal data, and confirm the equivalent role under GDPR Article 28 for our EU-domiciled workforce.
Why it matters. Under DPDP Section 2, the data fiduciary determines the purposes and means of processing; the data processor processes on behalf of the fiduciary. A vendor that resists naming the role is reserving the right to argue both positions when convenient. The role determines who notifies the Data Protection Board, who maintains the consent record, and who bears the Section 33 penalty exposure.
Follow-up probe. List every product feature where you take a controller or fiduciary role and the legal basis for that role.
Q2. Confirm Significant Data Fiduciary (SDF) readiness posture, including obligations you will take on if the central government notifies your customer as an SDF.
Why it matters. Section 10 SDF designation triggers additional obligations: DPIA, periodic audit, data protection officer (DPO) accessibility. Indian IT services firms with 5,000 plus employees and large public-sector deployments are realistic SDF candidates. The vendor must be ready to support DPIA evidence and audit access if the customer is designated SDF after contracting. A vendor whose architecture cannot produce audit-grade artefacts on demand makes the customer's SDF obligation unbearable.
Follow-up probe. Share a redacted DPIA you have completed for a comparable India deployment.
Q3. Enumerate every category of employee personal data the product captures by default in our intended deployment, and confirm whether any category falls within the sensitivity surface (emotion, stress, wellbeing, political, religious, biometric).
Why it matters. DPDP does not yet have a separate sensitive-personal-data classification in the way GDPR Article 9 does, but Section 8(2) purpose limitation means that any sensitivity-adjacent inference must be tied to a specific consented purpose. A vendor that captures emotion or stress signals as part of broad-spectrum monitoring is creating purpose-limitation exposure for the fiduciary. The architectural answer is exclusion, not toggle.
Follow-up probe. If a future admin in our org enables a sensitivity inference, what consent recapture flow runs automatically?
Cluster 2 — Notice and consent architecture (DPDP Sections 5, 6, 7)
Cluster two is where most procurement files fail under inquiry. Bundled employment-contract consent does not survive the DPDP standard. Three questions force the consent architecture into the light.
Q4. Provide the notice template you serve to data principals at the point of consent, in English and at least one Indian language, and confirm whether the notice is per-feature or bundled.
Why it matters. Section 5 requires clear, accessible notice in English and any of the languages in the Eighth Schedule. Bundled notice that hides screenshot capture inside “productivity tracking” does not meet the “specific” requirement of Section 6(1). The notice template is the first artefact the Data Protection Board will request after a complaint.
Follow-up probe. How does the data principal see the notice again when consent is re-required (e.g. new feature enabled)?
Q5. Describe the consent ledger architecture including per-feature granularity, withdrawal SLA, retention period, and API access exposed to our DPO.
Why it matters. Sections 6 and 7 require that consent be free, specific, informed, unconditional, and unambiguous, with proof retrievable on demand. The consent ledger is the proof. Without it, the fiduciary cannot defend against a complaint. Vendors without a native consent ledger force the customer's IT team into building one externally, which is fragile, expensive, and not legally watertight.
Follow-up probe. Show the consent ledger UI screenshot a data principal sees and the API endpoint a DPO uses to extract for a specific principal.
Q6. Describe the consent withdrawal flow available to data principals, the time-to-effect SLA, and the partial-withdrawal capability per feature.
Why it matters. Section 6(2) requires that withdrawing consent be as easy as giving it. A vendor where the only withdrawal path is “uninstall the agent” has not built consent withdrawal in the legal sense; the data principal cannot withdraw consent for screenshots while still consenting to time tracking. Partial withdrawal is the granular requirement.
Follow-up probe. Provide a screen recording of an employee withdrawing screenshot consent while keeping time tracking on.
Cluster 3 — Purpose limitation, DPIA, data minimisation (DPDP Sections 8, 10)
Cluster three pins down whether the product is architecturally bounded or merely admin-configurable. Three questions.
Q7. State the purposes for which employee personal data is processed in the product, and confirm whether each purpose can be unilaterally extended by a customer admin without triggering re-consent.
Why it matters. Purpose limitation under DPDP Section 8(2) means processing must stay within the consented purpose. If a customer admin can enable a new monitoring feature without triggering re-consent, the original consent is stale for the new purpose. The architectural answer is forced re-consent on purpose change.
Follow-up probe. Walk through what happens technically when an admin toggles on a new feature: does data flow before or after the principal's new consent?
Q8. Describe data minimisation in the product, including signal aggregation, redaction of personally identifying details from logs, and worker-level vs cohort-level reporting toggles.
Why it matters. Section 8(3) requires processing only what is necessary. A product that ships individual employee dashboards to every line manager fails minimisation when team-level cohort reporting would suffice. Worker-level identifiability should be a deliberate toggle gated to a defined role with audit logging, not a default.
Follow-up probe. Provide a redacted manager dashboard from a comparable India deployment showing cohort-level signals.
Q9. Provide your DPIA template for a typical India deployment of 1,000 employees, and confirm whether you support customer DPIA execution as a contract obligation.
Why it matters. SDF customers must conduct DPIA under Section 10(2)(c); EU AI Act Article 27 adds a fundamental rights impact assessment for high-risk workforce systems. The vendor's DPIA template signals whether the vendor has done the work or expects the customer to start from a blank page.
Follow-up probe. List the architectural exclusions your DPIA can rely on (sensitivity inferences excluded by design).
Cluster 4 — Data principal rights (DPDP Sections 11-14)
Cluster four covers the rights the data principal can exercise and the product mechanics for honouring them. Three questions.
Q10. Describe the data access request workflow including SLA, format of the export, scope (consent ledger, signals, derived inferences), and DPO routing.
Why it matters. Section 11 is the right to access. The fiduciary must respond within a timeline that the Rules will set (likely 30 days, verify with counsel). The vendor's role is to make the data extractable. A vendor without a defined extraction workflow forces the customer's HR or DPO into manual export, which is operationally brittle.
Follow-up probe. Provide a sample export from a comparable India deployment with redacted PII.
Q11. Describe correction and erasure mechanics in the product, including handling of derived inferences and signal aggregates that include the principal's data.
Why it matters. Section 12 is the right to correction and erasure. Erasing raw signals is the easy part; what happens to the productivity score that was derived from those signals, and to the team cohort report that included the principal? The vendor must show the cascade.
Follow-up probe. After a Section 12 erasure, what signals can a future audit reconstruct about the principal?
Q12. Describe the grievance redressal route, including escalation path from product support to vendor DPO, response SLA, and the customer DPO touchpoint.
Why it matters. Section 13 is the right to grievance redressal. The vendor must designate a grievance officer or DPO who is responsive to the customer's DPO. A vendor whose DPO is unnamed or whose escalation is “email support” is operationally exposed.
Follow-up probe. Provide a sanitised grievance log from the last 12 months including resolution times.
Cluster 5 — Breach SLA, cross-border, exit (DPDP Sections 8, 16; Rules)
Cluster five is where contract language meets operational reality. Three questions.
Q13. State the vendor-to-fiduciary breach notification SLA in hours, the contents of the structured notification, and the continuing-duty cadence.
Why it matters. The fiduciary's 72-hour clock to the Data Protection Board starts when the fiduciary knows or ought to know. A vendor SLA of 24 hours from breach detection gives the fiduciary 48 hours to assess and notify. A vendor SLA of 48 plus hours collapses the fiduciary's response window.
Follow-up probe. Provide the breach notification template and the last 24 months of breach drill summaries.
Q14. State the data processing locations, India region availability, and your cross-border transfer position if the central government restricts transfers after contracting.
Why it matters. Section 16 reserves to the government the right to restrict cross-border transfers. A vendor with no India region forces the customer into a position where a government notification can break the contract or force unplanned migration. India hosting at no incremental cost is the strongest answer.
Follow-up probe. If the government notifies tomorrow that workforce data cannot leave India, how many calendar days to migrate our deployment?
Q15. State the data export, deletion, and deletion certification process at contract termination including timelines, format, and any commercial conditioning.
Why it matters. Section 8(7) requires erasure on consent withdrawal or contract end unless retention is legally required. Exit terms that allow the vendor to retain data “for billing reconciliation” for 120-180 days create processing without consent post-termination. The customer's own Section 8(7) compliance depends on the vendor's exit machinery being tight.
Follow-up probe. List every entity (sub-processor, backup vendor, archive vendor) that must confirm deletion before you sign the certificate, and their median response time.
How to score the responses
Once vendor responses are in, three steps move from response pile to procurement decision.
Step one. Tag each of the 15 answers RED, AMBER, or GREEN using the band patterns above. RED on any of Q1, Q5, Q13, Q14, Q15 is usually a hard disqualification for a regulated-India deployment; AMBER on three or more questions is a yellow flag that needs vendor-side rework before signing.
Step two. Run the vendor's responses through the free DPDP Vendor Risk Assessment Worksheet for an independent verdict band. The worksheet treats Q1 through Q15 as inputs and lands one of four outcomes: Audit-Ready, Process-Led, Tool-Led, Risk-Acceptance. Audit-Ready and Process-Led are the procurement-eligible bands for SDF-track customers.
Step three. Convert every GREEN answer into a numbered contract schedule attached to the data processing addendum. The schedules become the artefacts the Data Protection Board, your customer's auditor, and your internal audit committee will request during inquiry. Loose email attachments are a procurement-file failure.
Bidding mechanics — how to run the RFP without leaking your hand
Three operating-level decisions shape whether the RFP gives you procurement-grade signal or vendor-marketing-grade noise.
Time the window to architecture, not licence cost
Five to ten business days is the operational window for compliance-architecture answers. A vendor whose internal compliance is operational can produce DPA pre-aligned, consent ledger architecture, and breach SLA in that window. A vendor that asks for more than ten days for these answers is signalling either a DPDP architecture gap or no assigned compliance owner. Either way it is a procurement signal.
Demand written responses with named author and date
Every answer should be a paragraph or longer with named author and date stamp, not a yes/no with marketing fluff. The named author becomes the named DPO contact under Q12; the date stamp becomes the audit trail. Anonymous answers from sales reps are not procurement evidence.
Require evidence artefacts
For each answer where the vendor claims a capability (consent ledger, India region, breach SLA), require an evidence artefact: screenshot, redacted DPIA, audit-pack sample. Capabilities without evidence are commitments without proof.
The “mature MSA covers this” deflection. Some vendors will respond to several of the 15 questions with “our standard MSA addresses this.” This is not an answer. The whole point of an RFP-question artefact is to surface the architecture before contract negotiation, not after. Reject any answer that defers to the MSA without producing the relevant clause text and the operational architecture behind it.
How this differs from the NASSCOM-aligned vendor scorecard
This RFP-question artefact pairs with the NASSCOM-aligned DPDP Vendor Assessment Checklist published earlier in this lane. The split:
| Artefact | Purpose | Use moment | Output |
|---|---|---|---|
| This article (15 RFP questions) | Author the RFP before vendors respond | Pre-RFP issue | Open-form questions for paste into RFP document |
| NASSCOM Vendor Assessment Checklist | Score the vendor responses against fixed rubric | Post-RFP responses | 12-criterion score matrix, vendor-by-vendor |
| DPDP Vendor Risk Assessment Worksheet (free interactive) | Independent verdict-band check on any single vendor | Shortlist validation | Audit-Ready / Process-Led / Tool-Led / Risk-Acceptance band |
| DPDP Vendor RFP Redline Template | Convert accepted responses into contract schedules | Contract negotiation | 7 must-have DPA clauses with pre-drafted language |
Together, the four artefacts cover the procurement lifecycle: write the RFP, score responses, validate the shortlist, contract the winner. Skipping any one creates a documented gap in the procurement file. Verify with counsel.
What writing the RFP this way buys the India CISO
Three outcomes that the generic SaaS questionnaire does not deliver.
One. Procurement-file completeness. Every clause of the contract that the Data Protection Board or your customer's auditor will probe is anchored to an RFP question with a written vendor answer. There is no “we assumed” gap.
Two. Architecture surfacing. The 15 questions force the vendor to disclose architectural decisions (consent ledger granularity, sensitivity exclusions, breach SLA mechanics) that do not surface in feature-led demos. Two vendors with identical demos can have very different procurement risk; the RFP reveals it.
Three. Dual GDPR + DPDP coverage. Because every question maps to its GDPR Article 28 parallel, one vendor response stack satisfies both your DPDP procurement file and your EU customer's Article 28 security questionnaire. The same artefact lands in two regulatory files. For India IT services exporters serving EU customers, that economy is structural.
Validate the vendor responses in 14 questions
Free interactive worksheet. Paste in the answers to the 15 RFP questions, get a verdict band in under three minutes. Email-gated only at PDF download; the score itself is free.
Frequently asked questions
What are the must-ask DPDP Act RFP questions for a workforce-AI vendor in India?
The minimum set is 15 questions across five clusters: data fiduciary designation and roles (DPDP Section 2 and 4), granular consent and notice architecture (Sections 5 to 7), purpose limitation and DPIA (Sections 8 and 10), data principal rights (Sections 11 to 14), breach SLA and cross-border posture (Sections 8 and 16). Each question should require a written response and a contract schedule reference. Verify with counsel.
What is the difference between writing a DPDP RFP and scoring a vendor under DPDP?
Writing the RFP defines the procurement requirements before vendors respond — this article addresses that step. Scoring a vendor uses a checklist against a finalised vendor response — that is the next step and the free DPDP Vendor Risk Assessment Worksheet on gstride.ai is built for it. Use this RFP question set first, then score responses with the worksheet.
Should the DPDP RFP also cover GDPR Article 28 if my customers are in the EU?
Yes. India IT services exporters with EU customers face a dual obligation. The RFP should map each DPDP question to its GDPR Article 28 parallel so a single vendor response satisfies both your DPDP procurement file and your EU customer security questionnaire. The 15-question set in this article shows the parallel mapping for each question. Verify with counsel.
What is a RED, AMBER, and GREEN response in a DPDP RFP?
RED is a response that indicates a structural DPDP gap that cannot be redlined into compliance without re-architecture by the vendor. AMBER is a response that needs further written commitment, a contract schedule, or an architecture diagram before it can be accepted. GREEN is a response that is contractually binding, schedule-backed, and operationally testable. Treat AMBER and RED responses as procurement risks and capture them in the scoring file.
How long should I give vendors to respond to a DPDP RFP?
Five to ten business days is the operational window for compliance-architecture answers. A vendor whose internal compliance is operational can produce DPA pre-aligned, consent ledger architecture, and breach SLA inside five days. A vendor needing more than ten days for these answers is either flagging a DPDP architecture gap or has not assigned a compliance owner — both are procurement signals.
Do I need to ask all 15 questions for every workforce vendor in the shortlist?
Yes for any vendor processing personal data of employees inside India. The 15 questions cover the substantive DPDP procurement gates and skipping any one creates a documented gap in the procurement file. Vendors processing only metadata that is not personal data may answer subset, but the burden is on the vendor to demonstrate the carve-out in writing. Verify with counsel.
Where should the vendor answers live after the RFP closes?
The accepted responses become contract schedules attached to the master services agreement and the data processing addendum. The schedules are the artefacts the Data Protection Board and your customer auditors will request during inquiry. Storing them as loose email attachments is a procurement-file failure. Mirror them into your vendor management system with named ownership.
Disclaimer. This RFP question set reflects the DPDP Act 2023 as enacted; Rules notification is expected during 2026 and may change operational specifics including SLAs, retention windows, and consent mechanics. Penalty figures referenced elsewhere on gstride.ai are statutory ceilings, not expected enforcement values. The GDPR Article 28 parallels are written for India IT services exporters with EU customers and do not replace EU counsel review. Verify all clauses with your own legal counsel before issuing the RFP, signing the contract, or relying on any output in a regulatory submission. Questions: hello@gstride.ai.