When Vendor Risk Becomes a Real Event

What the EU Cyber Resilience Act Means for Third-Party Incident Management

Third-party risk management has traditionally focused on assessing vendors before they are appointed and reviewing them periodically thereafter. These assessments remain important, but they only provide a view of a vendor’s risk at a particular point in time.

An incident can change that position immediately.

A cyberattack, compromised software product, service outage or data breach affecting a vendor can quickly become a risk to every organisation that depends on that vendor. This is one of the important lessons reinforced by the European Union’s Cyber Resilience Act. The Act introduces new obligations for reporting certain vulnerabilities and security incidents.

However, its wider significance is the recognition that cybersecurity risk must be managed throughout the lifecycle of a digital product and communicated quickly when something goes wrong. For organisations that rely on third parties, this raises an important question.

If a vendor experiences an incident, will the organisation know early enough to respond?

What the Cyber Resilience Act Changes

The EU Cyber Resilience Act introduces mandatory cybersecurity requirements for products that contain software or connect to a network. These are referred to in the Act as “products with digital elements” and can include software applications, connected devices and other technology products. The Act places obligations on manufacturers to consider cybersecurity throughout the lifecycle of their products. This includes designing products securely, addressing vulnerabilities, providing security updates and reporting certain vulnerabilities and incidents.

From 11 September 2026, manufacturers will be required to report actively exploited vulnerabilities and severe security incidents within defined timeframes. An initial warning must generally be submitted within 24 hours of the manufacturer becoming aware of the matter, followed by more detailed information within 72 hours.

An actively exploited vulnerability is, in simple terms, a weakness in a digital product that attackers are already using. A severe incident is one that affects, or could affect, the product’s ability to protect important information or functions. These reporting timelines recognise that when a digital product is compromised, time matters. The sooner the issue is identified and communicated, the sooner affected parties can assess their exposure and take action.

What This Means for Organisations Using Third-Party Products

The Cyber Resilience Act applies directly to manufacturers and other parties involved in supplying digital products within the EU. It does not automatically apply in the same way to every organisation using those products.

However, its underlying principle is relevant to any organisation that depends on third-party technology. A manufacturer may report an incident to the relevant authorities, but that does not necessarily mean every affected customer will receive the information it needs, when it needs it. Regulatory reporting and customer notification serve related but different purposes. Authorities need information to support regulatory oversight and coordinate a broader cybersecurity response.

Customers need to understand whether they use the affected product, where it is used, what business activities depend on it and what action they should take. An organisation cannot therefore assume that it is adequately protected simply because its vendor has fulfilled a reporting obligation to a regulator. It still needs its own process for receiving, evaluating and managing vendor incidents.

 
Can Third-Party Intelligence Close the Gap?

Some organisations may argue that third-party cyber intelligence services already provide the monitoring needed to identify vendor incidents and emerging threats. These services can provide significant value. They may identify public breach disclosures, exposed systems, security weaknesses, threat activity and other developments affecting a vendor. In some cases, they may alert an organisation before the vendor communicates directly.

However, the visibility provided by external intelligence is not consistent across every vendor. Large and well-known technology providers are more likely to appear in public reporting and commercial intelligence sources. Smaller vendors, privately owned businesses and providers operating in less-covered regions may receive far less attention. This creates a potential blind spot. A smaller vendor may not attract much external coverage, but it may still provide an essential service, process sensitive information or connect directly to important systems. Its size does not determine the level of risk it presents to the organisation.

An incident affecting such a vendor may not generate a public signal. Even when intelligence services identify that an incident has occurred, they may not be able to confirm which products, systems or customer environments are affected. There is also a timing concern. Intelligence services often depend on information becoming observable or publicly available. By that stage, the vendor may already have been investigating the incident for several days. For an organisation facing its own regulatory, contractual or operational responsibilities, that delay may be significant.

Third-party intelligence should therefore be seen as an important supporting control, but not as a replacement for direct vendor reporting.

Direct Reporting and External Intelligence Serve Different Purposes

The most effective approach is not to choose between vendor reporting and third-party intelligence. Each provides a different form of visibility. External intelligence can provide an independent warning that something may have happened. It can help identify public indicators, challenge information received from a vendor and reveal incidents that have not yet been disclosed.

Direct vendor reporting should provide the customer-specific information needed to understand the situation. This may include which products and versions are affected, what information may have been exposed, whether customer environments have been compromised, what corrective action is available and when normal service is expected to resume. An organisation’s own security monitoring provides a further source of information by showing whether suspicious activity or disruption is occurring within its environment. Together, these sources create a stronger early-warning capability.

Relying only on third-party intelligence may leave gaps where a vendor is too small, too private or outside the intelligence provider’s coverage. Relying only on the vendor creates the risk that information may be delayed, incomplete or never disclosed. A mature third-party risk management program should bring these sources together. The objective is not simply to know that an incident has occurred. It is to identify it early, understand how the business may be affected and coordinate an appropriate response.

Vendor Notification Should Be Part of the TPRM Program

Vendor incident reporting should be treated as a core part of third-party risk management rather than as a separate cybersecurity activity. The program should establish what vendors are expected to report, how quickly they must report it and what information they must provide. These expectations should be reflected in contracts, onboarding requirements and ongoing vendor reviews.

The requirement should not be limited to confirmed data breaches. Depending on the service and its importance to the organisation, it may need to cover cyberattacks, system outages, exploited vulnerabilities, ransomware events, loss of critical information and incidents affecting the vendor’s own subcontractors. The appropriate reporting timeframe should be based on the importance of the vendor and the possible business impact. An organisation that depends on a vendor for a critical service cannot afford to wait several days for an informal update.

The aim is not simply to copy the CRA’s reporting timeframes into every vendor contract. The organisation should define notification requirements that give it sufficient time to assess the incident and meet its own operational, contractual and regulatory responsibilities. Receiving the notification, however, is only the beginning. The organisation also needs a clear process for determining what the incident means for the business.

Understanding the Business Impact

When a vendor reports an incident, the first question is often: “How serious is it?”

That question cannot be answered by relying only on the vendor’s severity rating. The same incident may have very different consequences for different customers. A software vulnerability may present limited risk where the product supports a non-critical activity. The same vulnerability could be serious where the product processes sensitive information, supports customer transactions or connects to several important systems.

The organisation therefore needs to understand where the vendor and its products fit into its operations. It should be able to identify the business services, processes, systems, information and integrations that depend on them. This dependency context allows the organisation to determine whether operations may be disrupted, whether information may have been exposed, whether a workaround is available and whether customers or regulators need to be informed. Instead of focusing only on how serious the incident is for the vendor, the organisation can determine how serious it is for the business.

Managing the Incident Through to Resolution

Vendor incidents are often managed through emails, telephone calls and meetings. These may support the immediate response, but they do not provide a reliable way to manage the matter through to completion. A structured third-party incident management process should create a central record of what happened, which vendor and services were affected, what decisions were made and which actions remain outstanding.

Responsibility for those actions should be assigned to the appropriate internal teams and, where necessary, to the vendor. Progress should then be monitored until the immediate incident has been contained and the underlying risks have been addressed. This is important because closing the incident does not always mean that the risk has been resolved. An incident may reveal inadequate security controls, weak recovery arrangements, poor communication or an unmanaged dependency on a subcontractor.

These issues should be recorded in the organisation’s risk register and managed through an agreed improvement plan. The record of the incident, decisions, evidence and corrective actions also provides an audit trail. This allows the organisation to demonstrate that it understood the event, assessed the potential impact and took reasonable steps to protect the business.

Moving Beyond Periodic Vendor Assessments

Periodic assessments provide valuable assurance, but they cannot show how a vendor’s risk position changes between reviews. A vendor may have demonstrated appropriate controls during its last assessment and still experience a serious incident several months later. If the organisation has no defined reporting process, it may remain unaware that its exposure has changed.

Vendor incident reporting provides the link between periodic assessment and continuous oversight. It enables the third-party risk management program to respond when an actual event changes the level of risk. It also connects third-party risk management with cybersecurity, privacy, compliance, business continuity and operational resilience. These functions should not respond to a vendor incident in isolation. They need a shared understanding of what happened, where the organisation is exposed and what action is required.

The Wider Lesson from the Cyber Resilience Act

The Cyber Resilience Act reinforces a broader shift in how organisations are expected to manage risk across the digital supply chain. Cybersecurity responsibility does not end when a product is purchased or a service is outsourced. Manufacturers must manage vulnerabilities in their products. Vendors must communicate incidents that could affect their customers. Customers must understand their dependencies and be prepared to respond.

Third-party intelligence can strengthen this capability, but it cannot provide complete visibility across every vendor, product and region. Direct vendor reporting remains essential because it provides the information needed to understand the organisation’s specific exposure and take appropriate action.

For organisations reviewing their third-party risk management programs, the question is therefore not only whether vendors are assessed or externally monitored. It is whether the organisation will know when a vendor incident occurs, understand how that incident affects the business and be able to manage the response through to resolution.

An assessment can provide confidence in how a vendor manages risk at a particular point in time. Effective vendor incident reporting and management help protect the organisation when that risk becomes a real event.