Kantyra
Kantyra
Kantyra · 25-07-2026 · 11 min leestijd
For years, supplier management in information security was the register you filled in for the auditor and then left untouched until the next audit. The numbers show how unwise that has become. When the European Union Agency for Cybersecurity (ENISA) dissected twenty-four supply chain attacks in 2021, 62 per cent of them turned out to abuse the trust the customer placed in their supplier. The attacker walks in through the very party you deliberately let in. With the NIS2 directive and the Digital Operational Resilience Act (DORA), the era of non-commitment is also legally over, because both set requirements for how you control your chain. Time, then, to organise the subject properly. But that is where the confusion starts, because "supplier management" means three different things in three parts of the organisation, and a fourth term, third party risk management (TPRM), hovers above them. This article puts them side by side.
Take an organisation that has outsourced its payroll. With that single supplier, three entirely different conversations are running, and each conversation has its own owner, its own rhythm and its own register.
The first conversation belongs to procurement. It is about the contract, the price, the term, the delivery conditions and the question of whether the organisation gets what it pays for. This craft is called contract management or vendor management, it lives in a contract register, and it has its own moments, namely the tender, the renewal and the negotiation. The question this conversation answers is whether the agreements are right and are being honoured.
The second conversation belongs to the IT department. In the Information Technology Infrastructure Library (ITIL) and ISO/IEC 20000 this is called supplier management, and it is about day-to-day service delivery. Are the agreed availability levels being met, how quickly are incidents picked up, how do changes proceed and who escalates when things go wrong. This conversation lives in the service management environment, next to the configuration management database (CMDB), and its rhythm is that of operations, so weekly or monthly. The question here is whether the service does what its users need.
The third conversation is that of information security, and it asks a fundamentally different question. What risk does our information run because this supplier can access it, processes it or hosts it? What happens to the confidentiality, integrity and availability of our data if this party is compromised, fails or goes bankrupt? ISO/IEC 27001 devotes four controls to it, 5.19 through 5.22, from policy and contractual agreements to monitoring changes at the supplier. This conversation belongs in your information security management system (ISMS), with the chief information security officer (CISO) guiding the process and an owner per supplier.
The three conversations resemble each other because they concern the same party, but they differ in everything that matters. Squeeze them into one register and you get a list that almost works for everyone, which means it works for no one. Let them exist entirely apart and you miss the connections, because a contract renewal is exactly the moment to enforce security requirements, and a series of operational incidents is often the first signal that something structural is wrong at the supplier. The art is to let three registers do their own work and to connect the moments.
Many CISOs struggle with the question of whether third party risk management is a separate discipline they still need to set up on top of everything else. The short answer is no. TPRM is the Anglo-Saxon name for the same field of work, with two differences in emphasis worth knowing.
The first difference is in the word "third party". That is broader than "supplier", because it also covers parties that never send an invoice, such as chain partners, franchisees, intermediaries and free services your data flows through. For your risk picture that distinction is real: the sector platform you exchange data with is not a supplier, but it deserves the same assessment.
The second difference is in the breadth of the risk concept. TPRM programmes at large organisations look beyond information security at the continuity, compliance, financial health and reputation of the third party. Security supplier management is, in that view, the information security core of TPRM, and that core is what ISO 27001 and NIS2 ask of you. DORA takes a slightly different position. The regulation confines itself to ICT service providers, but within that group it asks for more than information security alone, because continuity, concentration risk and an exit strategy are explicitly part of it. Only reputation remains a voluntary addition under DORA as well.
The practical conclusion is the same as for the assets in an earlier article in this series. Do not set up two processes. Keep one supplier register at risk level, give every party an owner and a criticality, and attach to each line the attributes each framework asks for. Whether you then call the whole TPRM or supplier management is a matter of house style, not of substance.
Supplier risk is one of the areas where the economics of information security explains more than the technology does. Kunreuther and Heal showed in 2003 what happens when your safety depends on the investments of others, a situation they called interdependent security. Their game-theoretic analysis contains equilibria in which nobody invests, because the protection you buy is worth little as long as your neighbours do nothing. Anderson and Moore set out in Science why information security so often fails economically rather than technically, because whoever secures bears the costs while part of the damage lands elsewhere. Together those two insights explain why supply chain security could remain neglected for decades, and why the legislator is shifting the incentives with NIS2 and DORA: the duty of care makes your supplier's risk your demonstrable responsibility.
The field itself is young. Boyson, drawing on a multi-year research programme for the US National Institute of Standards and Technology (NIST), described cyber supply chain risk management in 2014 as a discipline under construction, in which most organisations still operated ad hoc. Ghadge and colleagues reached a similar conclusion in their systematic literature review, because research into cyber risk between organisations turned out to be scarce compared with research within an organisation's own walls, while it is precisely the interfaces that carry the risk.
The most practice-oriented research is recent. Slapničar, Vidmar and Tsen built a process theory of supplier cyber risk assessment from 33 interviews and a survey of 53 security experts. Two findings deserve attention. First, the process works, because a structured assessment does distinguish risky suppliers from less risky ones. Second, it only works when the depth of the assessment moves with the criticality of the supplier, because nobody has the capacity to assess every party equally heavily. Sending questionnaires without differentiation produces stacks of unanswered forms and no risk picture.
A sober note about certificates belongs here. Lins, Schneider and Sunyaev showed that a certificate is a snapshot, because between two audits reality at a cloud service can shift considerably. An ISO 27001 certificate from your supplier is therefore a sensible requirement and a good starting point, but it does not replace your own assessment, and for your most critical suppliers you will want additional evidence, such as recent penetration test results or an assurance report.
The NIS2 directive names supply chain security in so many words as a mandatory part of the duty of care, including the security aspects of the relationships with direct suppliers and service providers. The measures must be proportionate to the risk, which makes the criticality rating of your suppliers not an administrative luxury but the substantiation of your proportionality. The management body approves the measures and is accountable for them.
DORA goes considerably further for financial entities, though solely for third parties that provide ICT services; non-ICT outsourcing falls under the separate guidelines of the European supervisory authorities. Chapter V regulates the management of ICT third-party risk down to contract level, with prescribed contractual provisions, a dedicated article on concentration risk, an exit strategy that also covers the failure or decline of the provider, and the register of information on all contractual arrangements with ICT service providers, which goes to the supervisor on request. Within its scope, DORA thus explicitly asks for more than information security alone, because continuity and substitutability weigh just as heavily. The most critical ICT service providers moreover come under direct European oversight. If you fall under DORA, supplier management can no longer be limited to an annual review, because the register itself becomes a supervisory product.
In Kantyra, security supplier management is a continuous cycle of six steps, and the image sums it up.
The order is deliberately risk-driven, exactly as the research of Slapničar and colleagues advises: the criticality from steps 1 and 2 determines how heavy steps 3 and 4 turn out, so that your capacity lands with the suppliers that genuinely matter.
The six steps thereby pass through all four phases of the model behind Kantyra. Registering and linking are Detect, because that is where you record the facts. Testing, surveying and reviewing together form the Assess phase, in which the verdict on the supplier takes shape. The monitoring step belongs to Resolve and Demonstrate: the automatic tasks and signals ensure agreements are kept, and the recorded surveys, reviews and history are precisely the evidence an auditor or supervisor wants to see. Supplier management is therefore not register maintenance in the detection phase, but a cycle through the entire model.
If you are reading this without a working process, you do not need to start with a complete register of two hundred parties. Start with the ten suppliers whose compromise or failure would hit your primary process directly, and walk those ten through the six steps. After that, the register grows naturally with every purchase and every data protection impact assessment (DPIA) that brings a new processor to light. The difference between a neglected register and a working process is not the size of the list, but whether someone with a name feels responsible for every line on it.
Normative sources, directly consultable:
Academic literature:
In een demo van 30 minuten lopen we het model door aan de hand van jouw situatie.
Plan een demoThe risk matrix is the most widely used instrument in risk management, and the science is remarkably critical of it. What exactly is that criticism, what survives it, and how do you work with a matrix responsibly despite its limitations?
The spreadsheet with the NIS2 framework suggests everything is sorted, until someone asks whether you can prove it. Why that spreadsheet has value, which questions it leaves unanswered, and how to move from filling in to demonstrating in three steps.