Vendor due diligence is most useful when it produces an operational decision, not merely a completed questionnaire. A team needs to know what service is being bought, which data will move, who can access it, how incidents will be handled, and what happens when the relationship ends. Those questions are relevant whether the reviewer sits in privacy, security, procurement, product, HR, finance, or legal.
Under India’s digital personal data framework, labels should follow the actual processing activity. A supplier may process personal data on behalf of another organisation for one service while acting differently for another activity. This guide does not assign a statutory role to any organisation. It offers a role-neutral way to collect facts, record decisions, and preserve evidence.
What should a DPDP vendor intake establish first?
Begin with a short intake that a business owner can answer without translating a long legal questionnaire. The aim is to define the proposed use before reviewers examine controls.
| Intake field | Practical question | Useful evidence |
|---|---|---|
| Service and purpose | What outcome will the service support? | Order form, scope, product description |
| Data | What digital personal data could enter the service? | Data-flow sketch, sample fields |
| People | Whose data may be involved? | User or workforce categories |
| Access | Which supplier personnel and subprocessors may access it? | Access model, subprocessor list |
| Location | Where is data stored, backed up, and remotely accessed? | Hosting statement, architecture |
| Term | How long will the service and data use continue? | Contract term, retention statement |
| Owner | Who accepts and monitors the relationship? | Named business and control owners |
Ask the owner to distinguish required data from convenient data. A proposed integration may request every available field even though the service needs only a few. Record the minimised design before configuration begins. Link the approved intake to the system inventory and processing record, rather than copying details into disconnected files.
The Digital Personal Data Protection Act, 2023 is the starting primary source. Teams should also monitor MeitY’s data protection materials and official Gazette publications because commencement and subordinate requirements depend on current notifications. Do not convert a draft, summary, or vendor blog into a legal control without checking the official text.
How can teams tier vendors without pretending risk is a single score?
Triage should decide the depth and urgency of review. It should not hide important facts behind an unexplained number. A transparent tiering rule can consider data sensitivity, scale, criticality, access, connectivity, geography, children’s data, and the difficulty of replacing the service.
A practical flow is:
- The requester completes the intake before purchase or integration.
- A coordinator checks whether personal data is involved and whether an existing approved service covers the need.
- Relevant reviewers are assigned based on disclosed facts.
- The team records evidence, open questions, and proposed safeguards.
- An authorised owner accepts, rejects, or conditionally approves the use.
- Procurement prevents activation until required conditions are complete.
- The register receives a review date and change triggers.
Avoid calling a vendor “low risk” merely because spend is low. A free browser extension may receive sensitive text, while an expensive facilities contract may receive no digital personal data. Preserve the factors and rationale that produced the route.
Which evidence should a processor or vendor provide?
Request evidence proportionate to the service. A team does not need every certificate from every supplier, but it needs enough reliable material to test the claims relevant to its use.
- a current service description and architecture or data-flow explanation;
- security ownership, access-control, encryption, logging, backup, and vulnerability practices;
- incident detection, escalation, customer notification, and cooperation procedures;
- a current subprocessor list and change process;
- data-location, remote-access, transfer, retention, deletion, and return details;
- business continuity and recovery information for critical services;
- independent assurance reports where available and relevant;
- privacy request assistance and identity-handling procedures;
- product settings that allow the customer to limit collection, access, and retention; and
- a clear account of model training or secondary use where an AI-enabled service is involved.
Evidence has a date and scope. Record both. A certificate for one hosting environment may not cover the product being purchased. A policy describes intention, while a test report, configuration export, or demonstration can show operation. If the supplier cannot disclose a sensitive report, consider a supervised review, executive summary, contractual representation, or another proportionate method.
For a security-control vocabulary, the NIST Cybersecurity Framework 2.0 can help organise questions. It is not a substitute for Indian law and should not be presented as DPDP certification. For reportable cyber incidents and log-retention operations, compare the service process with the official CERT-In directions where those directions apply.
What should reviewers test beyond the questionnaire?
A questionnaire can reveal facts, but demonstrations often expose operational gaps. Ask a supplier to show how an administrator restricts access, exports a record, changes retention, reviews an audit log, disables an account, and deletes customer data. Use a safe test tenant and non-production data.
Reviewers can work through four questions for every material control:
| Test | Meaning |
|---|---|
| Designed? | Is there a documented process or technical feature? |
| Enabled? | Is it configured for the proposed customer environment? |
| Operated? | Is there dated evidence that people use or test it? |
| Verifiable? | Can the customer obtain proof or meaningful assurance? |
Document limitations plainly. “Encryption available” differs from “encryption enabled for stored customer content.” “Deletion supported” differs from a tested deletion that covers live systems, replicas, backups, support exports, and subprocessors. An honest exception with an owner and treatment date is more useful than a fully green dashboard built from assumptions.
How should the contract connect to the operating workflow?
Contract review should use the approved data flow and due diligence record. Otherwise, negotiated language may describe a service that the product team does not actually configure.
Depending on the facts and counsel’s interpretation, the contract may address documented processing scope, confidentiality, access, security measures, incidents, cooperation, subprocessors, audit or assurance, data location, return, deletion, continuity, change notification, and allocation of responsibilities. The business owner should understand which promises require internal action.
Turn negotiated terms into tasks. If the contract requires notice before a subprocessor change, identify who receives the notice and how objections are assessed. If deletion must occur after termination, schedule the request, evidence collection, and verification. If the customer must configure a retention period, make configuration a launch condition.
The broader DPDP compliance software guide explains how a control register can connect owners, evidence, and approvals. Teams can also review Gotham’s security approach, privacy information, and workflow overview when considering how legal operations tooling fits their own control environment.
How should incidents involving a vendor be rehearsed?
Do not wait for an incident to discover the contact route. Maintain operational and after-hours contacts, expected information fields, secure communication channels, and internal escalation paths. Rehearse a scenario in which the first vendor message is incomplete.
The initial record can capture discovery time, affected service, suspected data, affected environments, containment, preservation steps, known individuals or systems, customer actions, and the next update time. Keep observed facts separate from estimates. Preserve versions because early details commonly change.
A tabletop exercise should test whether the vendor can provide logs, explain subprocessor involvement, preserve evidence, coordinate public communications, and support the organisation’s time-sensitive assessment. Legal conclusions and external notifications require the current law, facts, and authorised decision-makers. The workflow’s job is to get reliable information to those decision-makers.
What does continuous monitoring look like in practice?
Annual review alone misses the events most likely to alter the decision. Create change triggers for a new product feature, new data category, material integration, subprocessor change, hosting relocation, security incident, acquisition, significant assurance finding, contract renewal, or service termination.
Use a monitoring checklist:
- confirm the business owner and purpose remain current;
- compare actual integrations and permissions with the approved design;
- review open conditions and overdue remediation;
- collect current evidence appropriate to the tier;
- check subprocessor and data-location changes;
- examine incidents, outages, and material control changes;
- verify retention and deletion configuration; and
- record a dated decision, next review, and trigger owners.
Do not silently overwrite old assessments. Keep a review history so a later reviewer can see what changed and why the relationship continued.
How should offboarding prove return and deletion?
Offboarding begins before termination. Identify records that must be returned, retained under an authorised schedule, migrated, or deleted. Disable integrations, credentials, API keys, support accounts, and data feeds in a controlled order so evidence and business records are not accidentally lost.
Request deletion confirmation that identifies scope, date, exceptions, backups, and subprocessors. Test what the customer can still access. Close only when the owner confirms that contractual, technical, inventory, and financial steps are complete. An unresolved backup period should remain visible with an owner and expected completion date.
The result is a defensible operating record: the organisation knew why it used the service, reviewed evidence, made a bounded decision, monitored material changes, and completed exit steps. To explore a structured approach for your own privacy operations, talk to Gotham or review the broader practice areas. This article remains educational and is not legal advice.
