%20Redacto%20logo_New.png)
Data Processors Under the DPDP Act: Roles, Responsibilities & Compliance
A bank may know that its cloud host stores customer records. The harder question is whether anyone can show which data reached that host, why it was shared, which subcontractors can see it and how deletion reaches every copy.
That gap sits with the Data Fiduciary. Section 8(1) of the Digital Personal Data Protection Act, 2023 makes the Data Fiduciary responsible for processing done by it or on its behalf by a Data Processor. Section 8(2) permits that processor relationship only under a valid contract.
For compliance teams, the practical answer is direct: a Data Processor processes digital personal data on a Data Fiduciary’s behalf. The processor needs clear instructions, the service owner needs operating controls, and the fiduciary needs evidence that both work. An invoice and a standard vendor agreement do not provide that evidence.
The substantive duties in Sections 3 to 17 are scheduled to commence on 13 May 2027. MeitY set that phase-in through its official DPDP Act commencement notification, published on 13 November 2025. Enterprises therefore have a defined implementation window, not a reason to defer processor discovery.
TL;DR
The role follows the purpose. A vendor is a Data Processor when it handles records on your organisation’s instructions, but your organisation remains accountable as the fiduciary and needs evidence that the contract, processor register, security route, breach route, rights workflow and erasure process all reach the same vendor chain. Redacto can connect that register to system ownership and review evidence. Legal and security teams retain judgment.
Who counts as a Data Processor under the DPDP Act?
Section 2(k) of the Act defines a Data Processor as any person who processes those records on behalf of a Data Fiduciary. Section 2(i) defines the fiduciary as the person who determines the purpose and means of processing.
The dividing question is who decides why the data is processed. A payroll vendor that calculates salaries on an employer’s instructions will usually act as a processor for that work. If the vendor uses employee records for its own unrelated product research, it is deciding a separate purpose. That processing needs its own role analysis.
One company can hold both roles. A hospital software provider may process patient appointment data for a hospital, while acting as a fiduciary for its own employee records, because the purpose changes between those activities. Classify each processing activity instead of assigning one permanent label to the company.
Common processor relationships include:
- a cloud provider hosting customer records;
- a payroll service calculating employee pay;
- a support platform storing tickets for an ecommerce company;
- a laboratory processing samples for a hospital;
- an email service sending notices on a bank’s instructions.
The register should name the service and purpose. A row marked “IT vendor” is too vague to support a rights request or breach decision.
The fiduciary keeps statutory accountability
Outsourcing processing does not outsource the obligation. Section 8(1) of the Act keeps responsibility with the fiduciary even when a processor performs the work. Section 8(5) also requires safeguards for processing undertaken by the fiduciary or on its behalf.
This allocation matters during an incident. The processor may detect an exposed storage bucket first, but the fiduciary needs the affected fields, the event timeline and containment facts before it can decide what to report. Section 8(6) of the Act places the statutory intimation duty on the fiduciary. The fiduciary therefore needs contract terms and an escalation route that deliver usable facts before its own reporting clock becomes unmanageable.
The Data Processor still carries serious contractual and operational exposure. It may owe indemnities, service credits or remediation costs under the agreement. It may also be a fiduciary for a separate use of the same data. The DPDP role cannot be inferred from the vendor label alone.
7 processor controls that produce evidence
1. Record the processing instruction
Section 8(2) of the Act requires a valid contract before a fiduciary involves a processor for an activity related to offering goods or services to Data Principals.
The contract should turn the processing into testable instructions. Record the purpose, data categories and permitted operations. When the service changes, the owner should compare the new system path, the approved location and the retention trigger with that instruction.
2. Keep a processor and sub-processor register
A procurement list rarely shows the complete chain. The CRM may use a cloud host. That host may rely on a support service with access to logs. When the chain changes, a useful register links each processor to its service owner, its approved purpose, and its sub-processors.
Section 11(1)(b) of the Act gives a Data Principal a route to obtain the identities of Data Fiduciaries and Data Processors with whom personal data has been shared, subject to the statutory exception in Section 11(2). The fiduciary needs a current sharing record to answer accurately once that provision commences.
3. Put minimum security measures into the contract
Rule 6(1)(f) of the Digital Personal Data Protection Rules, 2025 calls for an appropriate contractual provision requiring reasonable security safeguards. Rule 6(1) names measures that include protection such as encryption or masking, access control and logs. It also covers monitoring, backup and organisational measures.
The notified the Rules schedule Rule 6 to commence on 13 May 2027. A contract signed now should still state the control and the evidence expected. “Industry-standard security” cannot be tested during a vendor review.
During review, ask for an access record, an encryption configuration, or an incident exercise result. A certificate can support due diligence, but it does not prove that the contracted data flow uses the assessed controls.
4. Set a breach escalation clock inside the statutory clock
Rule 7(1) of the Rules requires the fiduciary to inform affected Data Principals without delay after becoming aware of a personal data breach. Rule 7(2) requires an initial intimation to the Board without delay. Updated details must follow within 72 hours unless the Board allows more time on written request.
A processor contract needs a shorter internal deadline. It should require the processor to preserve evidence and identify the affected data. The escalation should also state when the incident started, which systems were involved and what containment has occurred. Legal and security teams then decide the statutory response.
Automation can collect this material and route the incident. It cannot own the legal judgment about scope, notice wording or regulator-facing accountability.
5. Make rights requests travel downstream
A Data Principal asks the fiduciary for access, correction or erasure. The answer may depend on records held across a ticketing tool, cloud archive and fulfilment partner.
Sections 11 and 12 of the Act establish access and correction or erasure rights. The processor workflow should accept a scoped request, search the relevant systems and return completion evidence. When a retention exception applies, legal should record its basis, the processor should isolate the affected record, and the request log should show the outcome.
Across each system, use the same request ID, record the processor’s response, and attach any exception approved by legal. That creates a traceable response instead of a collection of email assurances.
6. Reconcile retention with erasure
Section 8(7)(b) of the Act requires a fiduciary to cause its processor to erase personal data when the statutory erasure trigger applies, unless retention is necessary for another law.
Rule 8(3) of the Rules also requires the fiduciary to retain specified records and associated processing logs for at least one year for the purposes in the Seventh Schedule. It then requires erasure unless another law or government notification requires further retention. The Rules give a cloud-hosting example in which the fiduciary has to ensure its processor follows that one-year requirement.
These provisions need a retention decision, not a blanket “delete on termination” clause. Map each data set to its trigger and legal exception. Then test deletion across live storage, replicas and queued jobs. Backup handling needs a documented path as well.
7. Collect exit evidence
The end of a contract can leave service accounts, exports and support attachments behind. Close those paths through a defined exit runbook.
The evidence pack should contain:
- a final inventory of data locations;
- an export or return record where required;
- deletion results tied to system IDs;
- revoked account and integration records;
- an approved note for any retained data.
At exit, the service owner confirms completion, security checks access removal, and legal approves any retention exception. The processor supplies evidence, while the fiduciary owns the final determination.
What belongs in a DPDP processor contract?
The Act does not provide a long statutory template for processor clauses. The contract still needs enough detail to let the fiduciary meet its own duties.
At minimum, cover:
- Scope: the purpose, data categories and permitted operations.
- Instructions: the channel for issuing and changing documented directions.
- Security: the measures required by Rule 6 of the Rules.
- Incidents: escalation timing, required facts and evidence preservation.
- Rights support: search, correction and erasure response procedures.
- Sub-processors: disclosure, change control and flow-down obligations.
- Retention: triggers, legal holds and deletion evidence.
- Assurance: review rights, artifacts and remediation ownership.
Do not treat the agreement as the control itself. Link every important clause to an owner, system event and record. For example, a 12-hour processor notification clause needs an alert route and an on-call owner. Otherwise the deadline exists only on paper.
Where processor compliance usually breaks
An incomplete processor register hides the chain
Discovery comes first. Procurement may see only the main vendor, even though engineering has added integrations and the processor has introduced subcontractors that receive the same records under a service path nobody has reconciled. A processor register exposes this gap when it cannot link the service to every downstream recipient and approved purpose.
A stale role assessment misses purpose drift
Purpose can move. A service that began as instructed hosting may later introduce analytics that use client records for a separate objective, leaving the original role assessment out of step with the live system path and current decision rights. The recorded purpose exposes the mismatch.
Missing access reviews create evidence lag
Questionnaires age quickly. An annual response may say controls exist, yet the latest access review or deletion test cannot be produced when an auditor asks who approved it, which system was checked and whether the resulting remediation was closed. Collect evidence when the control runs.
An empty exit record leaves copies behind
Termination is a control event. When nobody owns deletion from backups or exported support files, the exit record should reconcile returned data, deletion results and revoked access before the service owner closes the relationship. Closure needs proof.
How Redacto supports processor oversight
Redacto’s Vendor Risk Management can hold one processor record for the service owner, approved purpose and risk tier, while Redacto’s AI-Driven Data Discovery & Mapping links a newly discovered system and its records back to that same relationship.
The review owner can then request an access review, attach the resulting evidence, assign remediation and preserve the decision without rebuilding the context in email.
A breach handoff uses the same record. Redacto can keep the processor contact and affected systems beside the review history, while Audit & Reporting preserves the alert, evidence request and remediation owner, so the DPO can inspect the complete sequence from vendor detection through internal escalation, evidence collection, assigned response and closure before making any legal decision, with enough history to reconstruct the event without searching disconnected tickets or asking the vendor to restate it.
Redacto prepares the material. It does not decide whether notification is required.
Contract interpretation and risk acceptance remain with DPO, legal and security teams. They decide the processor’s role, approve exceptions, and own regulator-facing action. Redacto is India and DPDPA-first, so a multinational seeking deep multi-regulation coverage may prefer a global privacy suite. Redacto pricing is license-based; contact Redacto.
Start with one high-risk processor this Monday
Pick the processor that holds your highest-risk personal data. For a hospital, that may be the patient communication platform. For a bank, it may be the cloud environment supporting digital onboarding.
Trace one data flow from collection to deletion. Confirm the purpose, contract owner and approved sub-processors. Then request one current security artifact and one deletion record. Any missing record becomes a named remediation task with an owner and due date.
The point is whether the workflow produces evidence. One completed trace will show you more than another generic vendor questionnaire.
