Processor instructions under the DPDP Act

Processor instructions are where vague vendor comfort goes to become paperwork.

For Indian organisations using SaaS platforms, payroll providers, cloud services, support tools or implementation partners, processor instructions should do more than repeat the contract. They should tell the processor what personal data may be handled, for which purpose, under whose authority, with which safeguards and with what evidence. Under the DPDP framework, the Data Fiduciary remains accountable for processing carried out on its behalf. That makes processor instructions an operating control, not a procurement attachment.

What to review

Start with the processing purpose. The instruction should identify the business process, data categories, systems, users and permitted actions. If the vendor is only meant to host, support or analyse limited data, write that boundary plainly. A processor cannot follow instructions that live only in a sales deck or an internal assumption.

Review access and security expectations. The instruction set should cover role-based access, administrator approvals, logging, encryption, incident escalation, testing environments, deletion, backups and subcontractor controls. Security schedules are useful, but the instruction should connect them to the actual service being used.

Review change control. Vendors often add features, subprocessors, AI functions, analytics modules or support workflows during the contract term. The instruction should say when those changes need notice, approval or a fresh privacy assessment before personal data is used differently.

Finally, review evidence. A good processor instruction creates records the business can inspect: access reviews, incident tickets, deletion confirmations, subprocessor notices, audit summaries and remediation closure proof.

Also review whether the processor has any direct route to individuals, customers or employees. A support vendor that sends emails, runs surveys or handles complaints may need approved scripts, escalation paths and limits on what it may say about privacy requests or incidents.

Implementation steps

Create a short processor-instruction schedule for each material vendor. Do not rely only on a broad data processing clause. The schedule should name the service, authorised purposes, data categories, retention expectation, security evidence, breach notice path and business owner.

Translate the instruction into operational tickets. For example, procurement may own contract language, security may review controls, privacy may approve purpose limits, and the system owner may confirm whether production data is used in support or testing. Each owner should know what evidence closes the item.

Build a review trigger. Processor instructions should be refreshed when data categories change, a new subprocessor is added, the vendor launches an AI feature, support access expands, or the business starts using the tool in another country or function.

Keep the instruction understandable. If the vendor operations team cannot tell what is allowed after reading it, the document is too abstract. Use tables, permitted-use lists and escalation contacts where possible.

Link the instruction to breach readiness. Vendors should know where to report suspected unauthorised access, what early facts to provide, which logs to preserve and how often to update the customer. The instruction should support a fast first assessment, even when every fact is not yet confirmed.

Close the loop with renewal and offboarding. Before renewal, confirm whether the instruction still reflects actual use. At offboarding, require deletion or return evidence, removal of support accounts and confirmation that backup handling matches the agreed retention position.

Common mistakes

• Treating processor instructions as a single contract clause that no operational owner ever reviews.
• Allowing vendor feature changes without checking whether the original purpose and safeguards still fit.
• Asking for security evidence at onboarding but never linking it to renewal, incident or deletion reviews.

How DataNuance can help

DataNuance helps Indian organisations convert vendor contracts into working processor instructions, evidence registers, review triggers and escalation playbooks. For a practical processor-control review, contact DataNuance.

FAQs

Are processor instructions the same as a data processing agreement?

No. The agreement creates legal obligations. The instructions translate those obligations into service-specific limits, workflows and evidence that business, privacy, security and vendor teams can use.

Who should own processor instructions internally?

Privacy or legal can own the standard, but the system owner should own service-specific accuracy. Security, procurement and vendor management should contribute to controls, contract terms and review cadence.

When should instructions be updated?

Update them when the vendor, feature set, subprocessor list, data categories, support model, retention position or business purpose changes. Renewal and incident reviews are also useful trigger points.

What evidence should be requested from processors?

Request evidence proportionate to the service: access reviews, audit reports, security summaries, subprocessor notices, deletion certificates, incident updates and remediation closure records.

Sources

• Digital Personal Data Protection Act, 2023, India Code.
• Digital Personal Data Protection Rules, 2025, Ministry of Electronics and Information Technology.