Your Processor Got Breached. You Just Don't Know It Yet

Most third-party risk management programmes can tell you which processors they use. Very few can tell you which of those processors is compromised right now. That second question is the harder one, and under the DPDP Act it is the one the penalties are written around. A Data Fiduciary remains accountable for personal data after handing it to a processor, which means the breach most likely to hurt you is not the one inside your own perimeter. It is the one happening inside a company you do not control, on a network you cannot see, discovered on a timeline you do not set.

Consider how fiduciaries actually find out. Rarely from the processor. The usual sequence runs in the other direction: a researcher posts samples, a journalist calls for comment, customers start reporting phishing built from details only one vendor ever held, and then, days later, the processor's carefully lawyered notification arrives. This is not an Indian peculiarity or a small-vendor problem. When the MOVEit file transfer tool was exploited in 2023, more than 2,700 organisations were ultimately affected, many of them several links removed from the vendor they had actually contracted, and a large share learned they were victims from an extortion site before their own supply chain had finished working out who was exposed.

The gap between a processor being breached and a fiduciary knowing about it is where everything compounds: regulatory exposure, fraud losses, and the reputational bill that always lands on the brand the customer recognises, never on the vendor they have never heard of. Closing that gap is the entire purpose of third-party breach monitoring. And almost nothing in a conventional third-party risk management stack is built to close it, because the conventional stack treats breach discovery as a disclosure problem. It is not. It is an observation problem, and every instrument that treats it as disclosure inherits the same blind spot, no matter how thorough the paperwork.

Before walking through those instruments, it is worth being precise about the stakes, because the regulatory design is far less forgiving than most outsourcing arrangements assume.

The 72-Hour Clock Doesn't Care Where the Breach Happened

The DPDP Act settles the accountability question in its opening moves. Section 8(1) makes the Data Fiduciary responsible for compliance in respect of any processing done on its behalf by a Data Processor, irrespective of any agreement to the contrary. Read that phrase again, because it does the opposite of what most outsourcing contracts are drafted to do. Your agreement can allocate blame, indemnities, and costs. It cannot reallocate accountability. The Data Protection Board's questions come to you.

The breach provisions then attach clocks to that accountability:

• On becoming aware of a personal data breach, the fiduciary must intimate every affected Data Principal without delay, in plain language, describing the breach, its likely consequences, and what is being done about it
• The Board must be informed without delay as well, followed by a detailed report within seventy-two hours
• Unlike GDPR, the Indian regime carries no materiality threshold; there is no filter for breaches deemed unlikely to cause harm; every personal data breach is notifiable

These obligations arrive on the phased schedule notified under the DPDP Rules, which makes the current window preparation time rather than immunity. Older clocks are already running: CERT-In's directions require specified incidents, including data breaches, to be reported within six hours of noticing them. Regulated entities carry the RBI's long-standing position that outsourcing an activity never outsources accountability for it. Listed entities add SEBI's disclosure regime on top. The penalty schedule prices the downside: up to ₹250 crore for failing to maintain reasonable security safeguards, and up to ₹200 crore for failing to notify.

Now notice what none of these obligations mention: where the breach happened. The trigger is your awareness, not your infrastructure, and not the processor's honesty. If you learn about a processor breach from a leak forum, you have learned about it, and the machinery you owe the regulator has to start moving.

The clock does not ask where the breach happened. It asks when you knew and what you did next.

Which means the single most consequential variable in your breach response — the moment of knowing is governed by someone else's detection capability and someone else's candour, unless you build otherwise. With the stakes established, walk through the three instruments most TPRM programmes rely on to learn about processor breaches, in order of increasing sophistication, and where each one breaks.

Instrument 1: Contract Clauses - Trusting the Processor to Report on Itself

The baseline instrument is the breach notification clause: the paragraph in the data processing agreement obliging the processor to notify you within twenty-four, forty-eight, or seventy-two hours of becoming aware of an incident. The clause is necessary. Section 8(2) requires processors to be engaged under a valid contract, and the clause is where the notification duty lives. It is also enforceable afterwards, in the way contract remedies are always afterwards.

As a way of finding out, it has a fatal limitation. A clause is a promise, not a sensor.

Before a notification clause produces a single byte of information, three gates must open in sequence:

1. The processor must detect the intrusion; industry dwell times remain stubbornly long; attackers routinely sit inside environments for weeks or months before anyone notices
2. The processor must scope what happened; scoping takes time even in good faith
3. The processor must decide the event meets the clause's definition of a notifiable incident  a decision made with lawyers in the room and every incentive pointing toward caution, because notifying customers invites contract terminations, indemnity claims, and awkward questions from other clients

None of these gates is malicious. All of them are delays.

And notice the quiet trap in the clause's own wording: it fires when the processor becomes aware. A processor that never detects the breach never violates the clause, while your data circulates through criminal markets in full compliance with the contract. A notification clause tells you what the processor is prepared to admit, on the day its counsel is prepared to admit it. For a fiduciary whose own clocks key on awareness however it arrives, that is not a detection mechanism. It is a paper trail for the dispute afterwards.

Instrument 2: Questionnaires and Assessments, Photographs of a Moving Target

The next step up is assessment: the annual third-party risk assessment, the two-hundred-question security spreadsheet, the ISO 27001 certificate, the SOC 2 report. This is real work with real value. Assessments test whether a processor's controls exist and are sensibly designed. They are how you decide whether to extend trust in the first place.

What they cannot do is tell you that the trust has already been broken — because everything about their construction points the other way.

The structural limitations of assessments:

• Self-reported: Records the processor's assertions about itself; the failure mode is rarely dishonesty it is ignorance; the security team that filled in the questionnaire genuinely may not know about the engineer whose personal laptop, infected by an infostealer last Tuesday, carries a browser profile full of saved corporate passwords
• Point-in-time: A vendor that truthfully answered "MFA enforced everywhere" in March can have that engineer's credentials and live session cookies packaged for sale by July; nothing in the March answer was false, everything about the July reality is invisible to it
• Certificate-shaped: An auditor verified that processes existed during an audit window; a certificate valid until 2028 says precisely nothing about a credential dump posted yesterday

An assessment is a photograph. Compromise is a video.

Gartner's third-party risk research reports that incidents originating at third parties doubled from fifteen per cent in 2024 to thirty per cent in 2025, and that buyers are shifting from point-in-time due diligence toward continuous monitoring for exactly this reason. Questionnaires are how you decide whether to trust a processor. They were never going to be how you find out that the trust has failed.

Instrument 3: Security Ratings, Better Visibility, Same Ceiling

The most sophisticated conventional layer drops reliance on the processor's word entirely. Security ratings platforms scan a vendor's internet-facing surface from the outside, continuously: open ports, patching cadence, certificate hygiene, mail server configuration, and they grade the result. This is a genuine improvement. It is independent, ongoing, and requires no cooperation from the processor at all.

It still hits a ceiling, because it measures the wrong thing.

The fundamental mismatch:

• A rating tells you how breachable a processor looks
• It does not tell you whether the processor has been breached
• Those are different questions in kind, not in degree: one estimates probability from posture, the other confirms an event from evidence
• A processor can hold a spotless rating on the very day forty of its employees' credential sets are compiled into a fresh stealer log, because the rating scanned the perimeter while the evidence sits in a criminal marketplace the scanner never visits
• Perimeter hygiene also says nothing about the layer where most real intrusions begin: the phished inbox, the reused password, the personal device that quietly syncs corporate credentials

People do not show up in a port scan.

The visibility is better than anything the processor volunteers. The layer being observed is still the wrong one.

The Common Thread: All Three Measure the Story, Not the Breach

Step back, and the three instruments that make up a conventional TPRM stack stop looking like three different solutions.

• Notification clauses wait for the processor to speak
• Questionnaires record what the processor attests
• Certificates preserve what the processor once showed an auditor
• Ratings observe the surface the processor presents to the internet

Every one of them, in other words, examines some representation of the processor: promised, self-declared, audited, or projected. None of them looks at the place where evidence of an actual breach appears first. And the breach that creates your DPDP liability is, by definition, the one that no representation has caught up with yet. If the processor knew and had told you, it would already be in your incident register. The blind spot is not at the edge of these instruments. It is built into what they choose to look at.

Where Breach Evidence Actually Surfaces First

There is a different place to look, and it exists because a modern breach is not an event that stays inside the victim. It is a supply chain. Stolen data is inventory, and inventory that never moves is worthless.

The evidence classes that surface independently of the processor's cooperation:

• Infostealer logs: harvested from infected employee devices, packaged and sold in bulk; carry corporate credentials, browser-saved passwords, and authenticated session data
• Credential combination lists: compiled from multiple sources and traded across forums and messaging channels
• Live session cookies: sold to whoever wants an authenticated seat; bypass MFA because the authentication already happened
• Ransomware leak site postings: crews publish victim names publicly, because publication is the extortion mechanism
• Leaked API keys and service account tokens:  surface in public code repositories and paste sites
• Lookalike domain registrations:  appear in DNS as phishing campaigns are staged against a company's customers

None of this requires the processor's cooperation, because none of it belongs to the processor. It belongs to the attacker's business model, and the business model forces the evidence into the open. A ransomware crew cannot extort quietly. A credential broker cannot sell without listing. For the breach classes that dominate third-party incidents, monetisation and visibility are the same step.

The 2024 campaign against Snowflake customer environments made the point at scale. Attackers walked into around 165 organisations' data environments using credentials harvested by infostealers from employee and contractor devices, some credentials years old, none of the accounts protected by MFA. The evidence had been circulating in stealer logs long before any affected company disclosed anything. The breach announcements were the final chapter of a story the criminal markets had been telling for months.

This is the layer a fiduciary can observe without anyone's permission. The processor controls its logs, its questionnaire answers, and its perimeter. It does not control the marketplace where its stolen credentials get listed. Watching that layer changes the question from "what has the processor represented to us?" to "what has actually surfaced?”

What Continuous Third-Party Monitoring Actually Looks Like Under DPDP

Continuous monitoring, concretely, is standing observation of those evidence classes resolved against your live processor inventory running all the time rather than on assessment anniversaries. But the raw feed is not the capability. Interpretation is, because unfiltered breach intelligence produces two failure modes nearly as damaging as blindness.

The two failure modes of uninterpreted feeds:

• Alert fatigue -  the finding that matters drowns among the ones that do not
• False clocks - every dark web rumour gets treated as a notifiable event, and the compliance function burns itself out chasing ghosts

A signal only becomes a finding after it survives four questions:

Attribution: Whose credential, whose device? A processor employee's corporate login is one thing. A random consumer's account on the processor's public website is another. Your own employee's infected laptop is a third, and that one is your hygiene failure, not the processor's.

Relevance: Does this processor actually hold your personal data, and which categories? The same stealer hit means different things at your KYC processor versus your stationery supplier.

Mitigation: A leaked password behind enforced MFA is a contained liability. A live session cookie has already bypassed MFA. A machine identity never had MFA to begin with. One headline, three severity classes.

Obligation: What does this finding trigger: verification with the processor, a safeguards review, or, if personal data is confirmed compromised, the notification sequence itself?

That last question carries a legal subtlety worth stating precisely. A marketplace listing is evidence that a processor's environment may be compromised. It is not yet known that personal data has been breached. Interpreted properly, continuous monitoring does not start your seventy-two-hour clock early. It buys you the interval before the clock starts: time to verify with the processor, scope the exposure against what that processor actually holds, and prepare notifications as a procedure rather than a panic. The fiduciaries that struggle with breach timelines are never the ones who knew too early. They are the ones who found out last.

How Privy's TPRM Module Is Built for This

Privy's TPRM module treats external breach evidence as a first-class input to processor risk, sitting alongside assessments and contracts rather than replacing them. It monitors the evidence classes continuously, runs every signal through attribution, relevance, and mitigation before it becomes a finding, and reads each finding from the only point of view that matters: the Data Fiduciaries. Walk through the failure cases that defeat the conventional third-party risk management stack, and the difference shows in each one.

The processor that does not know yet: An infostealer log surfaces carrying corporate credentials of a processor's employees. The processor has detected nothing, so the notification clause is silent and the last questionnaire is still true as far as anyone who filled it in knew. Privy surfaces the listing, attributes the credentials, checks the mitigation context, and opens a verification workflow with the processor. An unrepresented compromise becomes a finding instead of a silence.

The processor that is still drafting the email: A processor's name appears on a ransomware leak site. From that moment, the contractual notification window is really a countdown of the processor's legal review. Privy flags the posting the day it appears, so your scoping starts on day one rather than on the day the letter arrives.

The compromise between assessments: The March assessment was green in every cell, and the July evidence is not. Because findings feed the processor's trust score directly, the score moves when the evidence moves, not when the calendar does, and reassessment is triggered by facts instead of anniversaries.

The credential that opens your door: Processor employees frequently hold access into your environment's VPN accounts, SFTP logins, API keys, and service identities. When one of those appears in a stealer log, it is not a reputational data point about a vendor. It is a live attack path into you, and it is triaged as one: rotate, revoke sessions, then investigate. Because the platform already maps which categories of personal data each processor receives, every finding arrives pre-scoped against your actual exposure, with a severity, a remediation owner, and the specific obligation it touches attached.

One honest boundary worth stating plainly: external monitoring sees the breaches that surface in criminal infrastructure and markets. That covers the classes that dominate third-party incidents, but not all of them. An intrusion that never monetises, run by an actor content to sit quietly, will not appear in any feed. Timing is imperfect too: the date evidence appears in a feed is the date the market saw it, not the date the compromise happened. Monitoring narrows the gap between breach and knowledge. Nothing closes it entirely, which is exactly why contracts and assessments stay in place. They are how accountability is constructed. Monitoring is how you learn, independently of anyone's promise, that the accountability is being tested.

To understand how third-party risk management fits into the broader DPDP compliance programme for 2026, and how processor oversight connects to breach response timelines, the incident management guide covers the downstream obligations that fire once a processor breach becomes confirmed. For enterprises building their TPRM programme from the ground up, the vendor onboarding risk guide covers the assessment layer that sits alongside continuous monitoring.

The Right Question for Evaluators

If you are evaluating a TPRM platform, the instinct is to ask how many assessment templates it ships with, how configurable the questionnaires are, how elegantly the risk register rolls up. These are reasonable questions about the wrong moment. All of them concern the day you decide to trust a processor. Your exposure is decided on a different day: the day that trust quietly fails.

Ask the simpler question instead: when one of your processors is breached, what tells you first: the processor, the newspaper, or your platform?

A stack built from clauses, questionnaires, and ratings will answer with one of the first two, every time, because each instrument observes only what the processor chose or managed to reveal. Under the DPDP Act, that is not a tolerable answer. The accountability never left your building even though the data did. Finding out is not a courtesy your processor extends to you. It is an obligation you carry. The only real choice is whether you build for that moment before the clock starts, or discover what it costs after.

Conclusion

Third-party risk management (TPRM) under DPDP is an observation problem before it is a process problem. The three dominant instruments notification clauses, assessments, and security ratings share the same structural limitation: they all observe representations of the processor, not evidence of actual compromise. The breach that creates your liability is, by definition, the one no representation has caught up with yet.

Continuous external monitoring changes the observation layer. It watches where breach evidence surfaces first in criminal infrastructure, not in vendor inboxes, and delivers findings that are pre-scoped, attributed, and tied to specific DPDP obligations before they reach the compliance team. To see how Privy's by IDfy’s TPRM module handles processor breach monitoring in your environment, write to shivani@idfy.com to book a walkthrough.

FAQ’s

Why does a processor breach become the Data Fiduciary's problem under the DPDP Act?

Section 8(1) of the DPDP Act makes the Data Fiduciary responsible for compliance in respect of any processing done on its behalf by a Data Processor, irrespective of any contractual agreement to the contrary. A contract can allocate indemnities and costs between the parties. It cannot reassign statutory accountability. The breach notification obligations, the Data Principal intimation requirements, the seventy-two-hour Board reporting window all of these run to the fiduciary regardless of where the breach originated.

What is wrong with relying on a contractual notification clause to learn about processor breaches?

A notification clause is a promise, not a sensor. Before it fires, three gates must open: the processor must detect the intrusion, scope the incident, and decide it meets the clause's definition of a notifiable event. Attackers typically maintain access for weeks or months before detection. Scoping takes additional time. Legal review adds more. A processor that never detects a breach never violates the clause, while the fiduciary's data circulates through criminal markets. The clause creates an enforceable obligation and a paper trail. It does not produce timely awareness, and timely awareness is what the DPDP clock runs on.

What does dark web monitoring actually detect in the context of third-party risk?

Dark web monitoring, as applied to TPRM, involves standing observation of criminal forums, marketplaces, stealer log repositories, ransomware leak sites, and paste sites for evidence associated with your processor inventory. Concretely, this means watching for infostealer logs carrying processor employee credentials, credential combination lists compiled from processor environments, live session cookies from processor systems, ransomware victim announcements naming your processors, and leaked API keys or service identities. None of this evidence belongs to the processor; it belongs to the criminal marketplace. A processor cannot choose not to appear there once it has been compromised.

How does continuous monitoring relate to the seventy-two-hour DPDP notification clock?

Continuous monitoring does not start the clock early. A marketplace listing is evidence that a processor's environment may be compromised, not confirmation that personal data has been breached. Properly interpreted, monitoring buys the interval before the clock starts: time to verify with the processor, scope the specific exposure against what that processor holds, and prepare the notification workflow as a structured procedure rather than an emergency. The clock starts on confirmed awareness of a personal data breach. Monitoring gives you lead time before that confirmation, which is exactly when the value is highest.

What is the difference between third-party risk assessment and continuous third-party breach monitoring?

A third-party risk assessment tests whether a processor's security controls exist and are sensibly designed. It answers the question "should we trust this processor?" at a point in time. Continuous breach monitoring observes whether the trust is still intact right now, by watching for evidence of compromise in the places where that evidence surfaces first independently of the processor's own detection and disclosure. Both are necessary: assessment is how accountability is constructed, monitoring is how you learn, independently of anyone's promise, that the accountability is being tested