Every organization outsources something under normal business cloud hosting, payment processing, HR software, customer support tools. What’s less obvious is that when one of those vendors gets breached, the regulatory fallout often lands on you, not them. Regulators across the EU and India have made it increasingly clear: outsourcing a function does not outsource your accountability.
This is the uncomfortable truth buried in three major regulations, the EU’s Digital Operational Resilience Act (DORA), the General Data Protection Regulation (GDPR), and India’s Digital Personal Data Protection Act (DPDPA). Each treats vendor risk differently, but all three converge on one principle: you can delegate the work, but not the responsibility.
The Old Excuse No Longer Works
For years, “it was our vendor’s fault” was a reasonable first line of defense after a breach. That defense has steadily eroded. Regulators now expect organizations to have vetted their vendors before onboarding, monitored them continuously, and built contracts that make security obligations explicit and enforceable. If a vendor breach exposes your customers’ data and you can’t demonstrate this level of oversight, the liability doesn’t stay with the vendor, it flows back to you.
This is exactly the gap that structured Third-Party Risk Management is designed to close: mapping vendor relationships, assessing their security posture before and during the relationship, and keeping contracts aligned with regulatory expectations rather than generic boilerplate.
DORA: Financial Entities Own the ICT Chain
DORA, which has applied across the EU since January 2025, is the most direct of the three when it comes to vendor accountability. It was built specifically because regulators recognized that financial institutions were increasingly dependent on a small number of technology providers, cloud platforms, data centers, and software vendors, and that a failure at one provider could ripple across the entire financial system.
Under DORA, financial entities such as banks, insurance companies, and investment firms are required to withstand, respond to, and recover from disruptions or threats involving their information and communication technology, and the regulation extends this obligation to cover their relationships with ICT third parties. In practice, this means a bank cannot simply point to a cloud provider’s outage or breach as an excuse. The bank is expected to have assessed that provider’s resilience beforehand, built exit strategies in case the relationship fails, and reported material ICT incidents within strict timelines, regardless of where in the supply chain the incident originated.
DORA also introduces direct oversight of providers designated as “critical,” meaning the largest cloud and IT vendors serving the financial sector now answer to EU supervisors directly. But for the financial entities themselves, the message is unambiguous: your ICT risk management framework must account for every vendor touching a critical or important function. You can read the full regulatory text on EUR-Lex for the exact obligations by article.
GDPR: Controllers Answer for Their Processors
GDPR took a similar stance years earlier, and it remains the reference point most compliance teams are already familiar with. Under GDPR, the organization that determines why and how personal data is processed, the controller, retains responsibility even when it hands the actual processing to a vendor, or processor.
That responsibility isn’t just moral; it’s contractual and financial. GDPR requires a written agreement (an Article 28 processing contract) that binds the vendor to specific security and breach-notification obligations. If the vendor suffers a breach and the controller never verified those obligations were in place or worse, never had a contract addressing them at all, regulators treat that as the controller’s own compliance failure, not just the vendors. Fines can still reach the well-known thresholds of up to 4% of global annual turnover, and it’s the controller who typically faces the regulator first, then seeks recourse from the vendor separately.
This is why a GDPR compliance program has to extend past internal systems and into every vendor contract, data flow, and sub-processor arrangement, because a chain is only as defensible as its weakest, least-scrutinized link.
DPDPA: India’s Newer Law, the Same Underlying Logic
India’s DPDPA, enacted in 2023 and now moving through phased enforcement following the notification of its rules in late 2025, follows a comparable structure using its own vocabulary. Under the Act, the organization that decides the purpose and means of processing personal data is the “Data Fiduciary,” and it remains accountable for how that data is handled even when processing is delegated to a “Data Processor.” The full text of the Act is available through India’s Ministry of Electronics and Information Technology, in the official Digital Personal Data Protection Act, 2023 document.
The DPDPA gives the Data Protection Board of India authority to investigate and penalize failures to implement reasonable security safeguards and a Data Fiduciary cannot simply argue that a vendor caused the breach if the fiduciary never verified the vendor’s safeguards or built breach-notification requirements into the relationship. As the substantive provisions of the Act phase in, Indian and multinational organizations processing Indian residents’ data should expect the same expectation that regulators in the EU already enforce oversight of vendors is not optional, and ignorance of a processor’s practices is not a defense.
Where the Three Laws Diverge and Where They Don’t
The mechanics differ. DORA is sector-specific and laser-focused on operational resilience and ICT incident reporting for finance. GDPR is broad, covering any organization processing EU residents’ personal data, with detailed rules on lawful processing and data subject rights. DPDPA is newer, narrower in some respects, and still being operationalized through its rules and enforcement timelines.
But the underlying logic is identical across all three: liability follows the data and the decision-making authority, not the org chart. If you decided to use a vendor, you’re expected to have assessed the risk of that decision and to keep assessing it for as long as the relationship lasts.
What This Means in Practice
- Turning this principle into a defensible program usually comes down to a few concrete steps:
- Inventory every vendor that touches personal data, critical systems, or regulated functions you can’t manage risk you haven’t mapped.
- Build security and breach-notification obligations into contracts, not just service-level agreements about uptime.
- Monitor vendors continuously, not just at onboarding a vendor’s risk profile in January can look very different by year-end.
- Rehearse the incident response process with vendors included, so a breach on their side doesn’t catch your team flat-footed. This is where structured incident response planning makes the difference between a controlled response and a scramble.
- Document everything, because when a regulator asks what oversight you exercised, “we trusted them” is not an answer that holds up.
The Bottom Line
DORA, GDPR, and DPDPA all reject the idea that outsourcing a function outsources the risk. A vendor breach becomes your legal liability the moment you can’t show you took reasonable, documented steps to prevent it, catch it early, and respond to it properly. Building that evidence trail before an incident happens is the difference between a manageable regulatory conversation and a costly one.
If you’re not confident your vendor ecosystem could withstand that scrutiny today, that’s a conversation worth having before a regulator forces it.
Is your third-party risk program regulator-ready?
| Connect with our experts to strengthen vendor governance, ensure continuous compliance, and protect your business from costly third-party breaches. |
Enjoyed reading this blog? Stay updated with our latest exclusive content by following us on Twitter and LinkedIn.
