A supplier policy for ICT services is an overview of every party that has access on your behalf or alongside you to systems, data, or infrastructure of your customers, with specifications for each party regarding what they may do, what has been agreed, and when this was last reviewed. You establish it because the due diligence obligation imposed on contracting entities requires them to also assess your security — and because you in turn rely on subcontractors, remote management software, and cloud providers that deserve the same assessment.
The core is simple: anyone who can reach your customer's environment should be in your overview. This applies to the party hosting your ticketing system, to the freelancer who rolls out patches at night, and to the tool with which you remotely observe a workstation. A supplier policy is not a formality for show; it is the answer to the question your own customer will one day ask you: who else can access my data, and how do you know they do it properly.
Who belongs in the overview
Start broad and trim afterward. The overview should include subcontractors who take over work from you, software vendors whose tools have access to customer environments, cloud providers where you store customer data, and independent specialists who contribute occasionally. The question you ask yourself about each party is not whether they are important for your business operations, but whether they — directly or indirectly — can access customer systems or data. A supplier of office supplies does not belong; a party hosting your monitoring software does.
It is tempting to include only the large, visible parties and skip smaller subcontractors because the relationship is informal. That is precisely where things often go wrong: an informal agreement with a freelancer who works at a customer site using your credentials is no less risky for the customer than a contract with a large party. Those uncertain whether their own organization itself falls under the due diligence obligation and thus is required to maintain this overview can have that clarified in a few questions.
What you document per supplier
For each supplier, a limited set of data is usually sufficient: what type of access the party has (read, write, administrative rights), to which systems or data, whether there is a contract with security agreements, who is your contact person, and when you last asked whether anything has changed. This last point is often forgotten: a supplier assessed two years ago and not revisited since counts in practice as unassessed. Setting a fixed moment each year to review the list prevents this.
The concepts that appear in such overviews — due diligence, supply chain, materiality — become clearer if you first look them up separately from your own situation; the knowledge base by topic provides a brief, verifiable answer for each concept.
Subcontractors: a special focus point
Subcontractors deserve extra attention because the customer often does not know they exist. If you outsource work to a third party that thereby accesses customer systems, it is customary to notify the customer and document what that third party may do. Some contracts with contracting entities prohibit subcontracting without prior consent; reviewing this is part of developing the policy, not part of the next discussion with the customer.
Remote management as a separate category
Software for remote management — remote management, monitoring, ticketing with screen-sharing capability — deserves a separate place in the overview, even though it is not a "supplier" in the ordinary sense. These tools typically have broad access to many customer environments simultaneously, making them attractive as an attack vector. Documenting who can access these tools, with what rights and with what verification, is therefore one of the first things a client asks about as soon as the conversation turns to your own security.
From overview to answer
A supplier policy that exists only on paper does not help if a client sends you a questionnaire tomorrow. The overview becomes usable only when it is linked to evidence for each supplier and to an owner who keeps it up to date. How such a living register looks in practice and where the corresponding answers to questionnaires come from is explained on the page that shows how the platform works.
Would you first like to see whether your organisation itself falls under the NIS2 duty of care or is only affected through the supply chain? Do the free check or browse through the topics — both can be consulted without an account and immediately provide a next step that suits your situation.