Why supply chain cyber risk has become a board topic
Supply chain cyber risk covers everything that can reach your organisation through a third party: a software vendor whose update is compromised, a managed service provider holding administrator access, a subcontractor processing your data, a cloud host whose outage stops your applications. The risk is not new, but its scale has changed. Most organisations have outsourced a large part of their information system, and every outsourcing decision opens an access path or creates a dependency that your own security controls do not cover. For an attacker, the least protected provider is often the shortest route in. The topic has also moved up the organisation chart. NIS2 requires management bodies to approve cybersecurity risk management measures and oversee their implementation, and DORA gives the management body ultimate responsibility for managing ICT risk. Third parties are fully part of that scope.
NIS2, DORA and EBIOS RM: what the texts expect on supply chain security
NIS2 explicitly lists supply chain security among the measures in its article 21, including the security aspects of the relationships between each entity and its direct suppliers or service providers. The same article asks entities to take into account the vulnerabilities specific to each direct supplier, the overall quality of its products and its cybersecurity practices, including its secure development procedures. DORA goes further for financial entities: a whole chapter covers the management of ICT third-party risk. It requires a register of information listing all contractual arrangements for ICT services, sets minimum content for those contracts, and demands exit strategies for services that support critical or important functions. EBIOS RM, finally, devotes its workshop 3 to the ecosystem: that is where you identify the critical stakeholders and the strategic scenarios that run through them. All three converge: know your third parties, assess them, be able to prove it.
Mapping critical third parties from business processes
Most supplier inventories start from accounting or procurement. They list who gets paid, not who is plugged in. For vendor risk management, the useful order is the reverse. Start from the essential business processes, the ones whose interruption or compromise really costs money, then work down to the supporting assets that carry them: applications, databases, infrastructure, administration workstations. For each supporting asset, ask four questions. Who hosts it? Who runs or maintains it? Who accesses it remotely? Who supplies the software or service it depends on? The answers reveal third parties missing from the procurement list: a vendor that was acquired, an integrator still providing support, a subcontractor of your cloud host. Record those fourth parties too, which contracts rarely mention but which sometimes share access to your data. The result is a dependency graph, not just a table of suppliers.
How a supplier risk propagates to a business function
Take a fictional example. A retail company collects customer payments through an in-house application hosted by a cloud provider. The application calls an external payment service provider and relies on a database managed by the host. The business process, payment collection, appears in no contract. Yet three events at third parties are enough to stop it: a regional outage at the host, a compromise of the cloud console administrator account, or an incident at the payment provider. The second scenario is the most severe, because it goes beyond unavailability: an attacker who controls the console can copy the database, change the configuration or delete backups stored in the same place. So the right question is not whether this host is secure in the abstract. It is what the business loses if this third party is unavailable or compromised, and how long it can hold out without it. That answer sets the assessment effort.
Prioritising third parties by criticality rather than volume
Assessing every supplier with the same depth exhausts the team and dilutes attention. Three or four tiers are enough, provided the criteria are explicit. The most useful ones are the criticality of the business process supported, the type of access (network, data, administrator rights), the sensitivity of the data entrusted, how hard the third party would be to replace, and concentration, when several functions depend on the same supplier. EBIOS RM offers a similar grid in workshop 3: dependency and penetration raise a stakeholder's threat level, while its cyber maturity and the trust you place in it lower it. DORA follows the same logic with the notion of a critical or important function, which triggers stronger contractual requirements. The tier then drives everything else: questionnaire depth, evidence required, clauses, review frequency. A low criticality third party gets a simple declaration; a critical one gets a full assessment and regular follow-up.
What to ask suppliers: questionnaires and security assurance plans
The security questionnaire remains the basic tool, but its value depends on what it asks. Avoid hundreds of generic questions that suppliers answer yes to out of habit. Focus on what matters for the service delivered: access to your data, separation between customers, backup and restore, vulnerability management, incident notification, use of subcontractors. For every important answer, ask for evidence: the exact scope of a certification, a summary of a recent penetration test, the incident management procedure. For critical third parties, a security assurance plan (in French practice, the Plan d'Assurance Sécurité or PAS) goes further. Annexed to the contract, it describes the measures the provider commits to apply for this specific service, each party's responsibilities and how compliance will be checked. A good security assurance plan is written from your requirements and your risk analysis, not from the supplier's standard template. It should be reviewed whenever the service changes significantly.
The contract clauses that actually protect you
A questionnaire describes a situation; a contract creates obligations. Security clauses are negotiated before signature, not after an incident, which means bringing procurement and legal in as soon as the provider is chosen. The key ones are well known: incident notification deadline and content, audit and information access rights, data location, control of subcontracting with prior notice or approval, service levels, reversibility and return of data at the end of the contract, and termination rights in case of breach. For financial entities, DORA sets a minimum list of contractual provisions for ICT services, strengthened when the service supports a critical or important function, notably with exit strategies. For entities in scope of NIS2, the security of supplier relationships is part of the expected measures, and the contract is its most solid evidence. Finally, check what was actually signed: older contracts renewed by tacit agreement often have none of these clauses.
Continuous monitoring versus one-off declarations
An annual questionnaire takes a snapshot of the supplier on a given date. Between two campaigns, it changes host, acquires a company, suffers an incident, lets a certification lapse or brings in a new subcontractor. If your assessment ignores this, it describes a third party that no longer exists. Continuous monitoring does not mean watching everything all the time. It means defining the events that trigger a review: an incident reported by the supplier or made public, a critical vulnerability in a product you use, a change of subcontractor or data location, a contract renewal, a change in the service. Some organisations add external signals, such as the internet exposure of the supplier's services, to be read with care because they only show part of the picture. What matters is linking each signal to the third-party register and the processes involved, so you know at once which business function is affected and which risk scenario needs a review.
The mistakes that weaken third-party cyber risk management
Five mistakes come up often. Treating third parties as a procurement topic: the register is then complete on amounts and silent on access. Sending the same questionnaire to every supplier, which buries critical third parties in the crowd and wears out the others. Settling for declarations without evidence, then discovering during an incident that the announced certification did not cover the service in question. Forgetting fourth parties, especially the cloud services used by your own providers. And isolating supplier assessment from risk analysis: a third party's score is useless if it changes neither a scenario, nor a control, nor a decision. What these mistakes share is the missing link between the third party, the supporting asset and the business process. Without that link, you know a supplier is fragile, but not what that fragility costs your organisation.
Key takeaways on supply chain cyber risk
Supply chain cyber risk is managed in a set order: start from business processes, identify the third parties behind their supporting assets, tier them by criticality, then scale questionnaires, evidence, clauses and follow-up accordingly. NIS2, DORA and EBIOS RM workshop 3 ask for the same thing in different forms: know who you depend on and be able to show it. In Vailor, the third-party register is available today and linked to your organisation and assets, and EBIOS RM workshop 3 is run in the risk management module. Planned next: AI-analysed questionnaires, a security assurance plan that AI helps draft and review, and real-time scoring. As everywhere in Vailor, the AI proposes and your experts decide. Book 30 minutes: we listen to your context and tell you concretely how Vailor addresses it.