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. Your approved process has to say who may decide and on what basis. The gap is neither about detection nor tools, but about decision rights.

A dated example from Dustin Group

Dustin Group's published updates from 3 to 10 September 2026 illustrate the decision window. This dated example does not establish the incident's current status.

In its 10 September update, Dustin said the technical investigation of affected internal and administrative systems was still under way. The cited updates do not establish what happened after 10 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.

Customer contract deadlines often matter

A supplier incident does not by itself create a Danish NIS2 reporting duty for an entity that is otherwise outside scope. 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 obligations on the entities it covers, and section 6 requires those entities to address security in their supply chains.

If you are outside the Danish Act's scope, the customer's duties do not become your own merely because you supply it. If you are covered yourselves, section 15 creates a separate duty to notify the recipients of your services without undue delay of significant incidents likely to affect delivery adversely, independently of the contract. An out-of-scope supplier may still receive evidence or notification requirements through a customer contract. I have described what the operating work can look like at a covered company here.

For an otherwise out-of-scope supplier, the relevant customer-notification clock will often come from its contracts, subject to separate legal duties. Review the applicable customer contracts, identify what triggers each notification clause and record the deadline it sets.

If you manufacture products with digital elements yourselves, separate CRA reporting duties may also apply. I have gone through that route in an exercise on CRA reporting. Assess it separately from the customer contract.

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.

Use thresholds you can assess from your own side, independently of the supplier's final explanation. Relevant signals can include a customer promise that can no longer be met, uncertainty about data or access, and supplier silence beyond a preset limit. Decide in the approved process whether those signals trigger review or action, taking account of contracts, legal duties and service tolerances.

In the dated updates cited here, Dustin said order flow was working again while the technical investigation was still under way. This illustrates that operational recovery and investigative closure can follow different timelines.

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.

Use your approved authority matrix to name who may declare a supplier incident your own and who acts as deputy. The owner of the customer promise should be involved, together with security, legal and contract owners where your process requires it. The authorised decision-makers should be able to act on available facts without waiting for the supplier's final explanation. Four things belong on the page.

  1. Who may call it. Record the authorised role or person and a deputy in the approved authority matrix. The owner of the customer promise should be involved with security, legal and contract owners where your process requires it. The decision-makers must be able to act on available facts without waiting for the supplier's final explanation.
  2. Thresholds you can see from your own side. Set and test operational thresholds against customer contracts, legal duties and service tolerances. Useful signals can include service disruption beyond an agreed tolerance, inability to confirm whether data or access is unaffected, or silence beyond a preset limit. Four working hours and two working days may be used as exercise assumptions. They are not default deadlines.
  3. Which customers get told, and under which clause. Make the list in advance from the contract register. Record what triggers each notification clause, what deadline it sets and who may send the message. Record who may decide on early customer notification under the approved authority matrix and applicable contracts. The customer-relationship owner should contribute but is not automatically the sole decision-maker.
  4. 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.

Clear authority and tested thresholds before the next time

A supplier's operational recovery does not decide how long you can keep your own customer promises while you wait. When authority and thresholds are written down in advance, the responsible owner can state what is known, what remains uncertain and who owns the next decision.

The next decision is to record who may declare a supplier incident your own and which observable thresholds trigger review or action, even when the supplier says nothing. Test that rule against your contracts and separate legal duties before the next incident.