Worked scenarios
Each scenario follows the same pattern: the situation, each team’s question, the decision, the evidence produced, the lesson.
1 — A critical vulnerability hits twelve of your products
Situation. A vulnerability is published in a widely used library. Your platform identifies twelve affected products within ten minutes, four of them in versions still supported at customers.
Legal: is there active exploitation? If so, the 24-hour clock is running. Cyber: exactly which versions, which customers, is the vulnerable code reachable?
Decision. No evidence of active exploitation at this stage → no reporting obligation, but urgent handling within the SLAs, VEX statements for products where the code is unreachable, and heightened watch for signs of exploitation.
Evidence. Register entry justifying the absence of a report, handling log, VEX statements, security advisory once the fix is published.
Lesson. Without a centralised SBOM, the “which products are affected” step would have taken weeks — and the 24-hour deadline would have been missed had exploitation been observed meanwhile.
2 — A researcher reports a flaw on a Friday evening
Situation. An email arrives at the PSIRT address at 7 p.m. on a Friday, describing a remotely exploitable vulnerability with a proof of concept.
Legal: is this active exploitation? A proof of concept supplied by a researcher is not exploitation in the wild. Cyber: is the flaw real, which versions, what immediate workaround?
Decision. Acknowledgement within the CVD policy’s interval, qualification within seven days, no CRA report absent active exploitation, coordination of the publication date with the researcher.
Evidence. CVD register, acknowledgement, correspondence with the researcher, published advisory, credit.
Lesson. The CVD policy absorbs this case without mobilising the on-call rota. Without it the email would have gone unanswered until Monday, and the researcher might have published.
3 — A customer requires your SBOM in a tender
Situation. A large account requires, as a mandatory item, an SBOM in SPDX format for the version to be delivered.
Legal: what does the document reveal, and under what conditions may it be shared? Cyber: your pivot format is CycloneDX; does conversion lose information?
Decision. Supplied under NDA, through the authenticated portal, accompanied by the VEX statements. Documented conversion, with known losses stated.
Evidence. Disclosure decision, contract clause, record of delivery.
Lesson. The disclosure question must be settled before the tender — see Distribution and confidentiality. Handling it under pressure leads to over-promising.
4 — A critical open source component is abandoned
Situation. The sole maintainer of a library present in three of your products announces they are stopping.
Legal: your support periods on those products still run for three years. Cyber: replace, fork, or bring in-house?
Decision. Fork and maintain internally for the remaining support period, with a budget provision; replacement planned for the next major version.
Evidence. Documented decision in the risk register, updated support period register, replacement plan.
Lesson. The “upstream support duration” criterion must be in the diligence grid at integration, not discovered three years later.
5 — You want to embed an AGPL library in an online offering
Situation. A team proposes an AGPL library to speed up development.
Legal: making it available over a network triggers the obligation to provide the derivative work’s source to users of the service. Cyber: does a permissively licensed alternative exist?
Decision. Refused, with an alternative proposed. If none exists: strict isolation in a separate service, or negotiation of a commercial licence with the author.
Evidence. CI block, ticket, decision in the exception register.
Lesson. The licence policy must be enforced by the build chain, not merely published. An automatic block avoids a debate three months later, once the code is written.
6 — You launch a new product: which class?
Situation. A new product includes an access management function and an embedded web rendering engine.
Legal: two Annex III, Part I categories are in play. Cyber: is the rendering engine exposed to untrusted remote content?
Decision. Class I. Two assessment scenarios worked in parallel: self-assessment if harmonised standards are published and cited in time, notified body otherwise — the latter kept as the base case.
Evidence. Co-signed classification sheet, filed with the documentation.
Lesson. Classification happens when development starts, not before market entry: it determines budget and schedule.
7 — An authority asks for the file on a product sold four years ago
Situation. A market surveillance authority in another Member State requests the technical documentation for version 3.1.4, placed on the market four years earlier.
Legal: deadline, single point of contact, evidence freeze. Cyber: find the signed SBOM, verify its signature, produce the VEX statements and the logs of the time.
Decision. Apply the response card, answer within the deadline, with no reconstruction of documents.
Evidence. The file as it stood, plus the register of exchanges.
Lesson. This case is not prepared when it happens. It is prepared through the annual retrieval exercise — see Evidence retention.
8 — A supplier refuses to provide an SBOM
Situation. A commercial component supplier refuses, citing trade secrets.
Legal: your inventory obligation does not disappear; the contract must be renegotiated. Cyber: can you produce the inventory by analysing the delivered artefact?
Decision. Three options, in order: negotiate supply under NDA; failing that, produce an analysed SBOM yourselves and document the limitation; failing that, plan the component’s replacement.
Evidence. Record of the request and refusal, SBOM produced by analysis with a partial completeness declaration, decision in the risk register.
Lesson. The SBOM completeness declaration exists precisely for this: to state honestly what the inventory covers. A partial inventory declared as such beats a partial inventory presented as complete.
9 — What support period for a long-lived embedded product?
Situation. Industrial equipment with an expected physical lifetime of fifteen years.
Legal: the support period must reflect the length of time the product is expected to be in use — potentially fifteen years. Cyber: can you guarantee fixes for fifteen years, on a hardware platform whose chip supplier will stop support before then?
Decision. Analyse the limiting components, negotiate extended support with the platform supplier, and set a justified and documented support period — shorter than the physical lifetime if the components cannot follow, with explicit information to the buyer.
Evidence. Justification in the technical documentation, statement to the buyer, register entry.
Lesson. The support period is not a free commercial decision: it must be justified. And justifying it often reveals that your suppliers cannot keep up.
10 — Exploitation observed at a single customer
Situation. A customer reports consistent indicators of compromise exploiting a vulnerability in your product. No other customer is affected as far as you know.
Legal: exploitation observed at one customer is enough to establish active exploitation. Cyber: verify the indicators, establish the scope, prepare a workaround.
Decision. Report. Early warning within 24 hours, notification of every user of the affected version, workaround published, fix under the emergency SLA.
Evidence. Register, platform acknowledgements, user communication, published advisory.
Lesson. There is no victim-count threshold. One customer is enough. This is the case the on-call team must have in mind, because instinct pushes towards waiting “until you know more”.