DPDP ActPrivacy LawVendor failure is not a defence for a Data Fiduciary under DPDP Act.

Vendor Failure Is Not a Defence: Why a Data Fiduciary Stays Accountable When Its Technology Partners Fail

 

The question every breach eventually asks

When personal data is exposed because a programming language, a hosting platform, a certificate authority or a software package failed, the first instinct inside the organisation is to point outward: “It was our vendor’s fault.” Under India’s Digital Personal Data Protection Act, 2023, that instinct is understandable but legally unavailable. The Data Fiduciary answers to the Data Principal and to the Data Protection Board, whoever caused the failure.

This article explains why, what regulators are likely to ask when the failure is upstream, and how a Data Fiduciary can protect itself.

The core principle: accountability cannot be outsourced

The Data Fiduciary is the entity that decides why and how personal data is processed. It chooses the technology stack, selects the vendors and benefits from the processing. The Data Principal has no say in any of that and often does not know who the vendors are. The Act therefore keeps responsibility with the one party the individual can identify and hold to account.

• Section 8(1): the fiduciary is responsible for compliance irrespective of any agreement with a processor.
• Section 8(2): a processor may be engaged only under a valid contract, and only for the fiduciary’s purposes.
• Section 8(5): the fiduciary must take reasonable security safeguards to prevent a personal data breach. This covers data in its possession or under its control, including data handled by its processors.
• Section 8(6) and Rule 7: the fiduciary must notify the Board and each affected Data Principal of a breach.
• Rule 6: sets the technical baseline, including encryption or masking, access control, logging and monitoring, backups, one-year log retention and security terms in processor contracts.
• Section 33: penalties run up to Rs 250 crore for failing to take reasonable security safeguards and up to Rs 200 crore for failing to notify a breach.

The Act imposes no direct penalty on a processor, and an open-source project or technology provider has no statutory duty under it at all. A vendor’s failure may give the fiduciary a contractual claim, but it does not reduce the fiduciary’s own exposure. The two questions run on separate tracks: who is accountable to the regulator, and who bears the cost between the parties.

Figure 1: Accountability stays with the Data Fiduciary; vendors face contractual claims only

What “reasonable safeguards” means when the failure is upstream

The standard is reasonable and proportionate safeguards, not immunity from every zero-day. That standard helps a fiduciary who did the right things and still suffered a failure it could not have foreseen. It does not help one that never looked.

Section 33(2) directs the Board to weigh the nature, gravity and duration of the breach, the type of personal data involved, the steps taken to mitigate harm, and proportionality. In an upstream failure, expect questions such as:

• Did you know which technologies and vendors touched personal data?
• Did you monitor security advisories for them?
• Once a flaw or a patch was public, how quickly did you act, and where is the record?
• If no patch existed, what compensating controls did you apply?
• What due diligence did you do on the vendor before onboarding, and since?
• What did your contract require of the vendor, and did you enforce it?
• How quickly did you detect the incident, and how quickly did you notify?

A fiduciary that can answer these with documents is in a very different position from one that can only say its vendor let it down.

On timing: the operational obligations, including Rules 6 and 7, are phased in under the DPDP Rules, 2025. Until they take effect, CERT-In’s Directions (including six-hour incident reporting), sectoral regulators and SEBI’s disclosure rules for listed entities already apply. Waiting for the deadline is a poor strategy, because the evidence of diligence has to exist before the incident, not after it.

Five ways someone else’s failure becomes your liability

Recent incidents involving widely used web technologies, development tooling, a certificate authority, a cloud hosting platform, an AI gateway package and a large public-sector bank show the pattern. They fall into five categories.

1. Core technology flaws. A critical vulnerability in a programming language, runtime or development platform sits beneath your application. Secure application code cannot save you. Your exposure turns on how fast you find affected assets and patch them. End-of-life versions that no longer receive fixes are the hardest case, because the only real remedy is migration.
2. Trust-anchor failure. Certificates underpin “this is really the bank’s website”. When a certificate authority’s keys prove weak, encryption and identity checks you rely on can be undermined even though your own certificates were never touched. Apparent Rule 6 compliance (“we encrypt in transit”) can be hollow if the trust chain beneath it fails.
3. Secret custody at a platform. Many teams keep API keys and database credentials in a vendor’s environment-variable store. If the vendor is breached, the exposure flows to your downstream systems and to the personal data they unlock.
4. Software supply chain compromise. An attacker who takes over a package’s release pipeline does not need to change the source code. Anyone who automatically pulled the latest version installed the malware. Your build and dependency process is part of your security perimeter.
5. Detection failure. Learning of an exposure from outsiders, after the data is already circulating, raises a different question under Section 8(5): were your monitoring and response arrangements reasonable?

In none of these categories does the fiduciary’s own code have to be at fault for the fiduciary to face scrutiny.

How a Data Fiduciary can protect itself

 

Know what you run. Keep a live inventory of applications, runtimes, libraries and third-party services, including the unglamorous ones such as CMS plugins, CI tools, hosting platforms and AI gateways. When an advisory lands, you should be able to say within hours whether you are affected.

Patch with a policy, and prove it.

• Set written patch timelines by severity, with an emergency path for critical internet-facing issues.
• Record the evidence of each action: who, what, when.
• For end-of-life systems, document compensating controls (WAF rules, segmentation, reduced exposure) and a funded migration plan. These are interim measures, not substitutes for a supported, patched system.

Design for the vendor failing.

• Secrets: keep them in a dedicated vault, rotate them regularly, scope them narrowly and make rotation a routine drill.
• Pipelines: pin dependency versions, use short cooldowns before adopting new releases, restrict who can trigger release workflows and protect developer tokens.
• Certificates: track every certificate authority and certificate in use and be able to replace them quickly.
• Data: minimise the personal data that sits in internet-exposed systems, so a failure exposes less.

Contract like a regulator will read it. Vendor agreements should cover security standards mapped to Rule 6, breach notice in hours rather than days, audit and evidence rights, sub-processor disclosure, cooperation in investigations, indemnity and liability caps that match the risk, and exit and data-return terms. Contracts allocate cost between the parties. They do not transfer statutory accountability and they do not replace controls.

Detect and respond. Centralise logging and monitoring, and retain logs for at least a year. Maintain an incident response plan that integrates CERT-In, sectoral regulators, the Data Protection Board and affected individuals. Run tabletop exercises that begin with “our vendor has just announced a breach”.

Build the evidence file. Keep risk assessments, vendor due diligence, patch records, board minutes and drill reports. This is what turns “we did our best” into “here is what we did”. Consider whether a voluntary undertaking under Section 32 would suit a given incident.

Govern it at board level. Third-party cyber risk belongs on the board agenda, with named owners and metrics. Significant Data Fiduciaries should plan early for data protection impact assessments and independent audits.

A practical starting checklist

1. Map every vendor and technology that touches personal data.
2. Review each vendor contract for security standards, breach-notice timelines, audit rights and indemnity.
3. Set and document patch timelines, and identify any end-of-life systems with a migration plan.
4. Move secrets into a vault and rehearse rotation.
5. Run a tabletop exercise on a vendor-originated breach.
6. Start the evidence file now.

Conclusion

Technology will keep failing in places you do not control. The law does not ask whether your vendor failed. It asks whether you took reasonable, proportionate and documented steps to prevent harm and to respond promptly when harm occurred. A vendor’s failure may explain how a breach happened, but it never answers the question of who is accountable. The Data Fiduciary that can show its working is the one best placed when the Board comes asking.

By Ajay Sharma, Advocate and Techno Legal Advisor, CorpoTech Legal

This article is for general information and is not legal advice. Statutory references are to the Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025, and should be checked against the current text before reliance.