SUPPLIER SECURITY · QUICK GUIDE

Supplier or cloud provider reports a security issue – what now?

A software vendor reports a critical vulnerability. A cloud provider reports a cyber incident. A supplier points to an affected component.

Does this affect us specifically? What do we know for certain? What information is missing? And who needs to take ownership now?

Seven questions at a glance

This guide structures initial intake. It does not replace technical incident response, legal advice or a case-specific CRA, NIS2, data protection or reporting assessment.

Initial intake

Seven questions for the first steps

QUESTION 01

What exactly was reported?

Capture the date and time, sender, supplier, notification type, advisory ID, ticket or CVE, stated urgency and original source. Be able to trace later what was received and what was derived internally.

QUESTION 02

Which service, product or component is affected?

Connect a general warning to the actual product, service, platform, component, version, build, firmware, environment or tenant.

QUESTION 03

Where do we use it?

Check the application or business process, own product, site, customer, data, interfaces, connected systems and critical function that could be affected.

QUESTION 04

What is confirmed – and what is still unclear?

Confirmed facts

Known versions, released patches, affected services or confirmed unaffected variants.

Open information

Unclear exploitability, subcontractors, data or time period, provider update or closure information.

Rule of thumb: Missing information is not positive security evidence.

QUESTION 05

What information do we still need from the provider?

Depending on use and criticality, request exact affected products and versions, technical description, timing, exploitation status, patches or mitigation, impact, affected data/services, subcontractors, SBOM/VEX, next update and closure information.

QUESTION 06

Who needs to take ownership internally?

Involve the relevant functions such as IT/information security, product security/development, procurement, data protection, quality/compliance, incident management, product owners and the appropriate approval authority. Assign one clear owner.

QUESTION 07

What do we need to document – and when do we review again?

Document the incoming signal, provider and affected service or component, own dependency, facts, gaps, requested information, owner, immediate measures, decision or escalation, next review date and closure information.

Initial intake

Compact working block

Event / notification
Supplier / provider and affected service / product / component
Our use / dependency and confirmed facts
Open questions / missing evidence and immediate measures
Owner and next review