As a software company, you increasingly receive a security questionnaire from a customer who falls under the Cybersecurity Act. The same duty of care that your customer imposes on you also requires something of you: assessing which of your own suppliers have an impact on the security of what you build and deliver. A supplier policy is the way to make that assessment repeatable, instead of having to decide who you actually trust each time.
Short answer: you start with an overview of who is in your development pipeline and in your delivered software, you categorise those suppliers by the risk they pose, and you set out per category what requirements you impose and how you verify them. That overview and categorisation together form the supplier policy.
Two types of suppliers, one blind spot
In software development, two chains run through each other, which makes a supplier policy more complex than for a company that only purchases physical goods.
The first chain is your development pipeline: the source code repository, the CI/CD pipeline, the cloud environment you build on, the tools for testing and deployment. A weak point there affects your own business operations in the first place.
The second chain is what ends up in your product: open source libraries, third-party APIs, purchased components. A weak point there affects not only you, but also every customer who uses your software. That distinction is exactly where much supplier policy falls short: attention goes to the first chain because it is visible in day-to-day work, while the second chain often only becomes visible when something goes wrong.
Inventory: start with what is already running
A supplier policy does not start with a template, but with a list. For software development, that means at minimum: which cloud providers you use, which package managers and registries your build process retrieves, which external APIs your product calls, and which of those parties can access code, secrets or production data.
For each supplier, the question is not only what they do, but what happens if they fail or are compromised. A package manager from which hundreds of dependencies come carries different weight than an invoicing package that operates separately from the development pipeline.
Risk categorisation: not every supplier deserves the same attention
After the inventory comes a categorisation, usually at two or three levels. Suppliers with access to source code, secrets or production environments call for the most stringent requirements: strong authentication, logging, a dedicated point of contact for incidents. Suppliers who only work indirectly, such as a project planning tool, require less.
The directive and the national law do not prescribe a fixed categorisation; supervisors look at whether the measures are proportionate to the risk. That means the categorisation you choose must be explainable: why this supplier falls into the heavy category and that one does not.
What you ask, and what you yourself already answer
A supplier policy works in two directions. Externally, you use it to ask questions of your own suppliers: how do they handle vulnerabilities, do they have a multi-factor authentication process, how quickly do they report an incident to you. Internally, it forms the basis for what you yourself answer to questionnaires from your customers, because a customer who assesses you often wants to know whether you have your own chain in view.
These two aspects are interconnected: a supplier policy that you write only for yourselves typically does not align with the questions you receive from customers. If you set up the policy from the outset with an eye to what a customer asks, you won't have to rewrite it later.
Recording: from policy to evidence
A policy that exists only in a text document is difficult to substantiate when a customer or regulator asks about it. More practical is a living overview: for each supplier the risk category, the most recent assessment, the evidence such as a declaration, a certificate or an answer to your own questionnaire, and who within your organisation monitors that supplier.
Such an overview does not need to be large to be useful. For a software company with a handful of critical suppliers, a table with a few columns is often sufficient, provided it is kept current when a supplier changes or a contract is renewed.
Do you first want to know whether your organisation itself falls under the duty of care, or is it only affected through your customers? take the free check in a few questions and read on the page covering all topics how supplier assessment relates to the other obligations. Curious where the information on this platform comes from and how current it is? That is explained on the page about how it works. If you want to convert the overview of suppliers into a dossier with evidence and owners, you will find on the page with subscriptions what is needed for that.