# When a vendor's breach becomes your legal deadline > A vendor breach still starts your own notification clock. Under GDPR, UK, Australian and US state rules, here is what needs to be ready before it rings. - Author: Marlon Trettin - Published: 2026-10-20 ยท Updated: 2026-10-20 - Language: en - Canonical: https://yowpi.com/en/blog/when-a-vendors-breach-becomes-your-legal-deadline --- When the breach starts at a vendor, you have less time than you think. Under GDPR and UK GDPR, a vendor must tell you about a breach "without undue delay," a phrase with no fixed hour count, while your own deadline to the regulator is 72 hours from when you become aware. Australia and the US set different clocks again, and the gap between them is where the exposure sits. ## TL;DR - Under GDPR and UK GDPR, a processor's duty to notify you is "without undue delay," with no fixed number of hours attached. Your own deadline to the supervisory authority is 72 hours from when you become aware ([Article 33](https://gdpr-info.eu/art-33-gdpr/), [ICO guidance](https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breaches-a-guide/)). - In Australia, once you suspect a breach you get up to 30 calendar days just to assess it, and when a vendor and your business jointly hold the data, the one with the closest relationship to the people affected is usually best placed to notify ([OAIC](https://www.oaic.gov.au/privacy/notifiable-data-breaches/quick-reference-guide-for-responding-to-data-breaches)). - The US has no single federal deadline. All 50 states, plus DC, Guam, Puerto Rico and the US Virgin Islands, run their own breach notification statutes, each with different timing rules ([NCSL](https://www.ncsl.org/technology-and-communication/security-breach-notification-laws)). - A breach that starts at a business partner or vendor adds roughly [$227,000 above the global average breach cost](https://cycode.com/blog/ibm-cost-of-data-breach-2026/), more than any other single factor, and it is also tied for the longest to find and contain, per IBM and Ponemon's [2026 study](https://www.helpnetsecurity.com/2026/07/30/ibm-cost-of-a-data-breach-2026/) of more than 600 breached organizations. IBM sells security software, so treat the dollar figure as an order of magnitude, not gospel. The mechanism it describes, that vendor breaches surface later, is the part that holds regardless. ## Why does "without undue delay" not mean anything specific? Because the law splits the clock in two on purpose. The deadline that has teeth belongs to you, the business with the direct relationship to the people whose data is at risk. The deadline your vendor faces is written to be flexible, not fast. [GDPR Article 33](https://gdpr-info.eu/art-33-gdpr/) says the controller, meaning your company, must notify the supervisory authority "without undue delay and, where feasible, not later than 72 hours" after becoming aware of a breach. Article 33(2) covers the vendor, the processor: it "shall notify the controller without undue delay after becoming aware," full stop. No hour count. Put the two rules together and the gap is plain: your 72-hour clock runs from when you become aware, and when the breach sits with a vendor, becoming aware depends on the vendor telling you. The answer in [the UK ICO's guidance](https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breaches-a-guide/) is to detail breach reporting requirements in the contract with your processor, under Article 28. Most vendor agreements never do. A support ticket, a status page update, an email from the vendor's legal team once its own investigation wraps up: none of that is illegal, because "without undue delay" allows for all of it. The 72 hours only ever count from the moment you found out, and most contracts never pin that moment down. ## What do Australia and the US actually require? Something looser still, in different directions. Australia's [Notifiable Data Breaches scheme](https://www.oaic.gov.au/privacy/notifiable-data-breaches/quick-reference-guide-for-responding-to-data-breaches) covers businesses with turnover above AUD 3 million, along with some smaller ones handling sensitive categories of data. Once you suspect an eligible breach, you get up to 30 calendar days just for the assessment phase, before notification even starts. When your business and a vendor jointly hold the same data, the OAIC's guidance says only one of you needs to notify, usually whichever party has the more direct relationship with the people affected. That is a judgment call your team has to be ready to make, not a form the vendor fills out for you. The US skips a single federal standard altogether. According to the [National Conference of State Legislatures](https://www.ncsl.org/technology-and-communication/security-breach-notification-laws), all 50 states, plus DC, Guam, Puerto Rico and the US Virgin Islands, require businesses to notify people affected by a security breach, and each statute sets its own timing rules. A company selling into a dozen states is working against a dozen different clocks at once, and a vendor breach means finding out which ones started before you knew there was a fire. None of this lets a company outside Europe ignore GDPR. [Article 3](https://gdpr-info.eu/art-3-gdpr/) applies the regulation to any organization, wherever it is based, that offers goods or services to people in the EU. A US retailer with EU customers answers to the same 72-hour clock as a business headquartered in Berlin. ## Why do vendor breaches take the longest to surface? Because nobody on your side is watching the vendor's systems, and the vendor has its own incident before it has a reason to think about yours. In IBM and Ponemon's [2026 Cost of a Data Breach Report](https://www.helpnetsecurity.com/2026/07/30/ibm-cost-of-a-data-breach-2026/), based on interviews at more than 600 breached organizations between March 2025 and February 2026, the average breach took 247 days to identify and contain, reversing five years of steady improvement. Supply chain and business-partner compromise stood out inside that number: a breakdown of the same research by [Cycode](https://cycode.com/blog/ibm-cost-of-data-breach-2026/) puts its cost premium at roughly $227,000 above the global average, more than any other single factor tracked, and its detection time at 258 days, tied for the longest of any breach type in the study. A breach inside your own walls gets found by your own monitoring. A breach inside a vendor's systems waits on the vendor's monitoring and schedule, and reaches you only after that. That is the real cost driver behind the deadlines above. A 72-hour clock that starts on discovery is only as fast as discovery itself, and discovery of a vendor incident routinely takes months, not hours. ## What should change on your side before the next incident? None of this is a compliance problem at its root. It is an architecture problem: whether you can answer, without calling the vendor, what data they hold and how fast their contract owes you an answer. Four decisions get you there, and none of them require becoming a law firm. The first is an inventory. Know which vendor holds which category of your data, updated the day you add a new tool, not once a year when someone remembers to check. A [shadow IT](/en/blog/shadow-it-when-every-department-picks-a-tool) subscription that a department bought on its own card is invisible to this inventory until someone writes it down, and a vendor nobody can name is a clock nobody can start. The second is the contract. Turn "without undue delay" into an actual number of hours, written into the processor contract, which is where the ICO says breach reporting requirements belong. Vendors negotiate this more often than buyers expect; it rarely happens only because nobody asks. The third is counting capacity. When a vendor tells you people were affected, can your own systems produce the exact number and identities, or do you have to wait for the vendor's dashboard to tell you who they are? [Access control](/en/blog/access-control-who-sees-what) that tracks who can see what inside your own systems is the same discipline, pointed at a different question: who is in the data you handed someone else. The fourth is ownership. Name, in writing, who inside the company owns the event "a vendor told us about a breach," with a defined next step. Without an owner, the notice from the vendor sits in a shared inbox until someone happens to open it, and the clock you cannot control keeps running while the clock you do control has not even started. ## An example of how this plays out The scenario below is hypothetical, meant to show the mechanism rather than report a real measurement. Picture a 45-person outdoor gear retailer based in Australia, selling online across Australia, the UK and the EU, well past the AUD 3 million line that brings it inside the NDB scheme, and squarely inside GDPR's reach for its European customers under Article 3. Its checkout and customer-account platform runs on a payments vendor based in another country. The vendor discovers unusual activity on a Friday, spends the weekend confirming it is a breach, and emails a notice the following Wednesday, five days after its own discovery. The retailer's 72-hour clock only starts on Wednesday, so it is not late by GDPR's letter. But it has no internal record of which customer data categories that vendor holds, so the first two days go to confirming that with the vendor's support team instead of drafting the notice. Under the NDB scheme, it also has to work out whether it or the vendor has the more direct relationship to the affected customers, a question its contract never answered. Nobody here knowingly broke a rule. The delay came from an inventory question nobody answered before the breach happened. ## Frequently asked questions **We're a small company outside the EU. Does any of this actually apply to us?** If you have customers, users or employees in the EU or UK, GDPR and UK GDPR can apply to you regardless of where your business is based. In Australia, the NDB scheme applies once turnover passes AUD 3 million. In the US, all 50 states have their own breach notification laws, each with its own rules. The question is not whether a law applies to your size of company; it is which one, and on what clock. **We don't have a security team. How do we even start a vendor data inventory?** Start with a list, not a security program: every vendor with access to customer or employee data, what category of data they hold, and where that list lives. Most companies can build this in a spreadsheet in an afternoon by going through billing and admin access, not by hiring anyone first. The point is not to be exhaustive on day one; it is to have an answer ready before you need it under pressure. **Our vendor contracts don't mention breach notification timing. Is that normal?** It is common, and it is exactly the gap this article describes. Most standard SaaS agreements rely on the default legal language, "without undue delay," because nobody asked for anything more specific. Raising it at renewal, rather than mid-incident, is the difference between negotiating from a position of choice and negotiating from a position of panic. ## The next step If you cannot currently list which vendors hold which category of your data or how fast each one is contractually required to tell you about a breach, the Operational Architecture Diagnostic is a 30-minute conversation to map that inventory with you and point out where the gaps sit: [book it through our contact page](/en/contact).