All insights
ChecklistVendor governance

Vendor offboarding and personal data deletion under DPDP

How Indian businesses can close vendor relationships cleanly, evidence deletion and reduce residual personal-data risk under the DPDP Act.

Data>Nuance

Vendor offboarding is where old access badges go to test everyone's optimism.

What to review

Vendor privacy risk does not end when the purchase order closes. If a vendor has received personal data, hosted an integration, stored backups, managed support tickets or accessed production systems, the offboarding process should confirm what happens to that data and who can prove it. Under the DPDP Act, a Data Fiduciary should be able to show that personal data is handled for the approved purpose, protected with reasonable safeguards and not allowed to linger without a business reason.

Start with the vendor register. Identify the systems used, personal data shared, subprocessors involved, retention commitments, contract deletion clause, business owner, technical owner and final service date. Then separate commercial closure from privacy closure. Finance may be finished when the invoice is settled; privacy is not finished until access, data, records and evidence have been dealt with.

Implementation steps

Create an offboarding ticket as soon as termination, non-renewal or migration is confirmed. The ticket should include the contract reference, tool owner, systems connected, data categories, required return or deletion steps, and the person who will accept final evidence. Where the vendor provides a standard deletion certificate, check whether it covers backups, subprocessors, logs, support attachments and sandbox data.

Remove access in layers. Disable user accounts, revoke API keys, rotate credentials, disconnect single sign-on groups, remove integrations and close shared workspaces. If the vendor had access to production support channels, confirm whether any exported files or ticket attachments remain in the vendor environment.

Handle data return before deletion when the business needs a retained copy. The retained copy should move to an approved internal location with its own retention owner. Do not let the vendor remain a shadow archive simply because the team forgot where historical reports should live.

Record evidence. Useful evidence may include deletion confirmation, export logs, access revocation screenshots, subprocessor confirmation, backup deletion timelines, and the date the internal owner accepted closure. For higher-risk vendors, legal, security and privacy should all sign off before the offboarding ticket is closed.

Offboarding should also cover people who managed the vendor internally. Remove shared inbox forwarding rules, transfer administrator ownership, archive approval records and confirm that former project members no longer hold local exports. Where the vendor supported a regulated or customer-facing service, keep the closure evidence with the contract file so future audits do not depend on memory.

If the relationship is ending because of an incident, dispute or failed security review, do not use the ordinary low-risk closure path. Preserve relevant logs, escalation notes and communications before deletion begins. The deletion plan should be coordinated with legal and security so useful evidence is not destroyed while unnecessary personal data is still removed.

Where the vendor supports multiple business units, require each owner to confirm closure for their own data set. One central tick mark can miss regional folders, old exports or separate administrator accounts.

Common mistakes

  • Closing the commercial contract while leaving integrations, API keys or shared drives active.
  • Accepting a generic deletion statement without checking backups, subprocessors, support tickets and test environments.
  • Retaining exported vendor data internally without assigning a lawful purpose, retention period and business owner.

How DataNuance can help

DataNuance helps teams design vendor offboarding controls that procurement, IT, security and legal can actually run. The work usually includes a practical checklist, contract fallback language, evidence templates and a risk-tiering model for high-volume processors. To tighten vendor deletion and offboarding records, contact DataNuance through the /contact page.

FAQs

Is a deletion certificate always required?

It is not always required in the same form, but deletion evidence is useful whenever the vendor processed meaningful personal data. For low-risk tools, a system confirmation may be enough. For higher-risk processors, ask for clearer written confirmation.

What if the vendor keeps backup copies?

Backup retention should be understood before approval and checked again at exit. If backups cannot be immediately deleted, the vendor should explain the retention period, access restrictions and restoration controls that apply until the backup cycle expires.

Who should own vendor offboarding?

The business owner should remain accountable for closure, with IT handling access removal, security reviewing technical risk, procurement managing commercial steps and legal or privacy checking contract and evidence requirements.

Should old vendors stay in the vendor register?

Yes, at least as archived records. Keeping an offboarded vendor record helps show when data sharing ended, what deletion evidence was received, and who accepted closure. The register should distinguish active vendors from closed ones.

This publication is general information and is not legal advice for a specific organisation or matter.

Continue reading

Sector readiness

DPDP readiness for SaaS companies in India

A practical DPDP readiness guide for SaaS companies aligning product, support, analytics, vendors and customer contracts in India.

Read insight

Vendor governance

International SaaS tools and DPDP vendor risk

A practical checklist for Indian teams reviewing international SaaS tools before personal data is shared under the DPDP Act.

Read insight

Start with context

Book a focused DPDP Act consultation.

Bring an upcoming launch, notice review, data mapping question, incident readiness issue or implementation deadline. We will help identify the right next step.