On Monday morning your own systems are running as they should, monitoring is green, and there are no cases in the service desk. Even so, three of your customers cannot get what you promised them, because a supplier in the middle of the delivery has shut down its systems. The IT manager refreshes the supplier's status page every fifteen minutes, while sales asks what they are allowed to write to customers. Meanwhile one question is left that nobody has been given: is this our incident?
The incident response plan does not answer it, because it starts in your own systems, while the incident that stops your delivery happens in someone else's. The scenario is invented and is not about any particular supplier.
A supplier incident does not become your incident on its own. Someone has to decide it, and the question is whether you have named that person in advance. The gap is neither about detection nor about tools, but about a decision right.
A current case at the IT supplier Dustin Group
Dustin Group is an IT supplier, and the company's current case is a concrete example of the question above and worth reading soberly, because it shows exactly the window in which the decision has to be made. On Thursday 3 September 2026 Dustin Group stated that it had found unauthorised access to some internal IT systems, and that it regarded the incident as serious. Dustin itself shut down selected systems to limit the consequences. Order flow was running again on 8 September, initially by phone and email, the websites opened on 9 September, and on 10 September Dustin stated in its own updates that all websites and customer portals for placing orders were working normally again.
According to Dustin's update of 10 September the technical investigation of the affected internal and administrative systems is still under way, and Dustin has published nothing since. On 4 September Dustin stated that the cause and extent were being investigated together with external experts, and none of the later updates gives a cause. Dustin has, as controller, filed an initial notification of a possible personal data breach with the Swedish data protection authority, Integritetsskyddsmyndigheten (IMY). On the Skyportal customer portal Dustin states that the personal data that may have been affected is a limited number of categories of non-sensitive, business-related data about contact persons and users at business customers, and that it has no indication that the data is likely to result in a high risk for the individuals concerned. All of the above is what Dustin has published itself, compiled on 14 September 2026.
I am not judging Dustin's handling of the case, and you cannot see more than that from the outside either when it is the supplier and not you that is hit. That is the window in which someone at your company has to decide whether it is also your case.
The question nobody had been given
I have been in a similar situation myself, back when I led the recovery after a ransomware attack at a manufacturer with several factories. There it was the company's own systems that were hit, while the technical work was under control. Recovery was under way and there were people on the job, while production knew what it was waiting for, and IT knew what the next step was.
What had no owner was something else, because sales had customer agreements with clauses about when the customer had to be told. The question came up almost as a passing remark: is this that kind of case, who decides it, and who then has to be told? The room went quiet, since none of us had been given that decision. Meanwhile the deadlines in the customers' contracts kept running.
It should have been easy, because the case was our own, the systems were our own, and there was no doubt that it was an incident, but even so the decision right had not been placed with anyone. When the incident sits outside your own systems but inside your delivery, the same question gets harder still. There is no alarm and no log file that can settle it for you, and the incident response plans I have seen do not cover it when the supplier is down.
The clock that counts is in your customer contracts
The reflex is to look for the deadline in the legislation, but most companies that are hit indirectly through a supplier have no reporting duty of their own to an authority under the Danish NIS2 Act in that situation. If personal data held by the supplier is affected, the data protection rules apply separately. The Danish NIS2 Act (LOV nr 434 af 06/05/2025) places the obligations on the companies that are covered themselves, and section 6 requires among other things that a covered company handles security in its supply chain.
That is the customer's duty, not yours, unless you are covered yourselves. If you are covered yourselves, you also carry a separate duty under section 15 to notify the recipients of your services without undue delay of significant incidents that are likely to adversely affect delivery, whatever the contract says. There too, the same decision has to be made first: is this your incident or not. If you supply a covered customer and are not yourselves one of the supplier types the Act covers directly, for example cloud and data centre services, you meet the requirement through the contract rather than through the law. I have described what that obligation looks like in practice at a covered company here.
The clock that actually binds you is in your own customer agreements. Take out your five largest customer contracts, find the notification clause, and read what triggers it and what deadline it sets. I have seen the wording be broader than the security department thinks, and in those cases it did not say that the incident had to have started with you. In my experience that reading takes an afternoon.
If you manufacture products with digital elements yourselves, there is a separate authority deadline for manufacturers, and I have gone through it in an exercise on CRA reporting. That deadline is not the one that binds you here.
A rule that waits for the supplier's confirmation never triggers
The first question when the supplier is hit is what happened, and that is the wrong basis for a rule. A rule saying that you declare the incident once you know what happened never triggers in time. It depends on information that only the supplier can give, and that the supplier is often waiting for itself. Declaring an incident is not the same as concluding, because it only starts your own process, and the first message to the customer can perfectly well be that you do not yet know the extent.
The thresholds therefore have to be things you can establish from your own side, independently of the supplier's assessment of severity. Is there something you promised a customer that can no longer be delivered? Can the supplier confirm that your data and access are untouched? The absence of a confirmation is a trigger in itself, and so is silence that lasts longer than the limit you set in advance.
The Dustin case shows it, because orders could be placed again five days after Dustin disclosed the incident, and the investigation had not been reported closed when I compiled this. The two timelines do not follow each other, and operations come back long before the explanation. Anyone who waits for the explanation makes no decision in the window where the decision matters.
I have seen the pattern from the inside at a larger private-equity-owned group where I was previously the embedded IT director. The signal sat with security, the customer promise sat with the operations director, and there was no written line between the two, which is why the rule has to name the person who decides.
The declaration rule on one page: who may call it your incident?
What is missing is a declaration rule, namely the written rule for who may declare an incident as your own when it sits outside your own systems but inside your delivery, at what threshold, and who then has to be told. It fits on one page and in my experience takes about half an hour to write.
At your company, one named person may declare a supplier incident your own incident, with one named deputy. That is the person who owns the customer promise, typically the CEO or the operations director, and that person has to be able to make the decision alone, without assembling a group and without the supplier's confirmation. The decision is commercial before it is technical, because the next step is a message to your own customers under their contract. Four things have to be on the page.
- Who may call it. Both the name and the deputy's name have to be in writing, not a job title. The right follows the customer promise, and if the name sits with IT, the decision becomes technical, and then it waits for an explanation the supplier cannot give yet.
- Three thresholds you can see from your own side. Delivery: a supplier incident stops or degrades something you promised a customer, beyond a tolerance you set in advance, measured in working hours and not in a judgement of materiality. If you have not set it yet, start with four working hours and correct it once you have tried it. Data and access: the supplier holds your data or has standing access and cannot confirm that it is untouched. Duration and silence: the supplier is still investigating past the point you set yourselves, without saying anything about the extent. If you have not set that, start with two working days. All three can be settled without the supplier taking part.
- Which customers get told, and under which clause. Make the list in advance from the contract register. Find the customers with a clause that obliges you to inform them and that is broad enough to also catch an incident at a supplier or sub-processor. Write down what triggers the clause, what deadline it sets, and who sends the message. That list is hard to make while the case is running, and only the person who owns the customer relationship can decide to notify early.
- The documentation someone asks for later. Six weeks on, a customer's security officer or auditor calls and asks for the sequence of events: when did you know, who made the decision, on what basis, who did you notify, and when. The answer is one shared note with timestamps, owned by the person who declared the incident. You write it as you go.
The page is the whole job, and it contains no supplier assessment, no risk score and no ranked list of your suppliers. That can be sensible work, but it does not help you on the Monday when the supplier is down and the customer calls. The supplier review itself is a different job, and I have written about what a customer expects to see in supplier documentation here.
One person, one threshold, before the next time
Dustin had order flow running again after five days, and the investigation had not been reported closed when I compiled this. That says nothing about how long you can keep your own customer promises while you wait. If the name and the threshold are written down in advance, you can answer the customer the same day and show afterwards who decided what, while otherwise you spend the first day working out who is even allowed to decide it.
So the next decision is two lines on a piece of paper: the name of the one person who may declare a supplier incident your own, and the one threshold at which that person has to do it, even when the supplier says nothing. If you do not make that decision, you have accepted that the first supplier incident decides it for you. One person, one threshold, this week.