General awareness
The biggest mistake organisations make when outsourcing processing
- Does using a processor transfer your liability?
- No. You can outsource the processing, but you cannot outsource the accountability. Section 8 keeps the Data Fiduciary responsible for processing carried out on its behalf, and the Data Principal's rights still point at you.
- Who this affects
- Any organisation using vendors, cloud providers or agencies.
- What to do about it
- Engage a processor only under a valid contract, and oversee it actively. Our vendor handles that is not a defence.
The most common mistake I see when organisations outsource processing is treating the vendor contract as a transfer of liability. "We use a processor for that, so it is their problem now." Under the DPDP Act, it is not.
You can outsource the processing. You cannot outsource the accountability.
The accountability stays with you
Section 8 keeps the Data Fiduciary responsible for complying with the Act in respect of processing carried out on its behalf by a Data Processor. The Data Principal's rights, and the Board's attention, still point to you. A Data Processor may be engaged only under a valid contract. The Act does not hand you a template of clauses, but a contract that is silent on security and on breach cooperation leaves you exposed, because you remain the one who has to answer.
What this means in practice
It is sharper than it first sounds.
- A breach at your processor is, for the Data Principal, a breach by you. You are the one who has to intimate the Board and the affected individuals. "Our vendor was hacked" is an explanation, not a defence.
- If a processor uses the data beyond your instructions, for its own analytics or model training, it may itself become a Data Fiduciary for that use. That does not rescue you. It usually means your oversight and your safeguards had already failed.
- Sub processors extend the chain. The Act keeps accountability with you, so a downstream party you cannot see is a risk you still carry, even where the letter of the Rules does not spell out flow down.
The contract is not a shield
The contract matters, but not as a shield. It matters because it is the instrument through which you keep control of data you remain answerable for. Signing it is the start of the obligation, not the end of it.
Before signing with any vendor that touches personal data, ask a different question.
If this vendor suffered a breach next week, what would we owe the Data Principal and the Board, and do our contract and our oversight actually let us meet it?
If you cannot answer that, the exposure is already yours, whatever the contract says.
Where do you see this going wrong most often: contracts that never mention security or breach cooperation, no oversight after signing, or sub processors nobody has visibility into?
