Your software vendor reports a vulnerability
Does the notification affect a version, component or service that we actually use?Clarify what is affected, where it is used, what is confirmed and what is still missing.
SUPPLIER · SOFTWARE · SAAS · CLOUD
Cybersecurity does not stop at your company boundary
A supplier reports a vulnerability. A cloud provider informs you about a cyber incident. A SaaS provider changes a subcontractor. A critical supplier cannot provide the requested security evidence.
The event happens outside your company. Its effects can still reach your systems, processes, products, data or customers.
Typical starting situations
Which of these situations do you recognise?
Your cloud or SaaS provider reports a cyber incident
What could the incident mean for our data, processes, access paths or critical services?An incident at a provider should not simply be filed away as the provider’s problem.
A supplier says: “We are secure”
What reliable information or evidence do we need for our specific service and usage context?Certificates and self-assessments can help, but do not answer every specific question.
You receive an SBOM or VEX statement
What does this information mean for the software or components we actually use?Link components and versions, known vulnerabilities and the current assessment status.
A critical supplier changes a subcontractor, service or technical component
Do we need to reassess our previous decision or existing evidence?Changes can create new risks, information needs or reassessment triggers.
A critical provider fails or ends support
Do we have a viable path for transition, replacement or exit?Cybersecurity and resilience meet where external dependency becomes a single point of failure.
Structured supplier cybersecurity
What belongs to a controlled working process?
- make external dependencies and criticality visible
- assess supplier information and evidence
- build security requirements into procurement and contracts
- connect software, component, SBOM and VEX information
- bring vulnerabilities and supplier incidents into internal processes
- monitor suppliers and services across their lifecycle
- document decisions and evidence status
From notification to a traceable case
When a security notification arrives, do not let it end in an inbox
1
Capture the original notification
Record what was reported, by whom and when.
2
Connect it to your own dependency
Identify the supplier, service, component, version and your actual use.
3
Separate confirmed facts from gaps
Keep assumptions and missing information visible.
4
Assign ownership and the next review
Route the case into the right internal assessment and decision process.
Operational dependency is the main issue
For SaaS, cloud, software or external service provider situations, assess the impact on your own systems, processes and data.
Open the 7-question Quick Guide →The affected component is part of your own product
When the component is part of a product with digital elements, product and version relevance, vulnerability assessment and possible reporting need to be connected.
Go to the Cyber Resilience Act →Structured work
Assess and document supplier cybersecurity in a structured way
The Supplier Cybersecurity Practice Kit supports the path from criticality and supplier assessment through contractual security requirements, SBOM/VEX and vulnerabilities to incidents, monitoring, measures, approvals and evidence.
- 13 editable work tools
- SCMS Cockpit and 9 AI assistants
- Guidance, worked example and documentation
7
Supplier Security Issue
Questions for the first steps after an external security notification.
Free Quick Guide
Supplier or cloud provider reports a security issue – what now?
The free Quick Guide structures the initial intake: notification, own dependency, confirmed facts, information gaps, internal ownership and the next review point.
FAQ
Frequently asked questions
What does supplier cybersecurity mean?
It covers cyber risks arising from suppliers, software vendors, cloud and SaaS services and other external service providers.
What should we do when a supplier reports a vulnerability?
Clarify the supplier, service, component and version, your actual use, confirmed facts, missing information, ownership and the next review point.
Does an incident at a cloud provider automatically become our own incident?
No. First determine which data, services, processes or systems may be affected and whether this triggers your own process.
When does a supplier issue become a CRA issue?
When affected software, firmware or a component is part of your own product with digital elements, the CRA product perspective may also be relevant.
Official sources and information status
Directive (EU) 2022/2555 (NIS2) – EUR-Lex, in particular Article 21
Commission Implementing Regulation (EU) 2024/2690 – EUR-Lex, where applicable
Regulation (EU) 2024/2847 (Cyber Resilience Act) – EUR-Lex, where own products are affected
ENISA resources on supply chain cybersecurity
Information status: September 2026.
Directive (EU) 2022/2555 (NIS2) – EUR-Lex, in particular Article 21
Commission Implementing Regulation (EU) 2024/2690 – EUR-Lex, where applicable
Regulation (EU) 2024/2847 (Cyber Resilience Act) – EUR-Lex, where own products are affected
ENISA resources on supply chain cybersecurity
Information status: September 2026.