Third-party risk for organisations without a TPRM team

Third-Party Risk Management, or TPRM for short, is the function that maps the risk posed by ICT suppliers and other third parties, anchors it contractually and verifies it periodically. It is not a tool, not a department, not a maturity score. It is a working habit: knowing which third parties have access to which processes and data, knowing what can go wrong if they fail or are compromised, and being able to demonstrate that you keep sight of it. An organisation without that working habit carries the risk of its suppliers without being able to substantiate it, and that is precisely what NIS2 and DORA no longer allow.

This piece explains how to set up that function if you have no TPRM team, no vendor risk manager, no four specialists with spreadsheets. It is written for the operations manager who does the work in practice and who has to make the internal case for why a minimum set is needed now, and what that minimum set is. Not an ideal, but a workable floor.

What is TPRM, and why does it now land structurally on the operations portfolio?

TPRM describes the discipline of managing third-party risk as a continuous process, not as a one-off assessment before or after signing a contract. ISO/IEC 27036, the international standard for information-security relationships with suppliers, breaks it down into three layers: the general framework for supplier relationships (part 1), the supplier agreement itself (part 2), and the specific requirements for ICT supply chains (part 3). That structure is useful because it removes the misconception that TPRM is "contracting carefully". Contracting is a single moment. TPRM is the whole span of time before, during and after it.

The reason the function now lands on the operations portfolio and no longer on a procurement department alone is legislation. NIS2 Article 21(2)(d) requires entities in scope to factor supply chain security into their risk-management measures, including the security aspects of the relationship with direct suppliers and service providers. DORA, Chapter V of Regulation 2022/2554, goes further for financial entities and requires a register of ICT third-party agreements, a classification of critical functions held by third parties, contractual minimum requirements, an exit strategy and periodic reporting to the supervisory authority. Both frameworks demand demonstrability. Not "we believe we have sight of this", but a document, a list, a date, an agreed interval.

In organisations without a vendor-management department, that work ends up with the people who actually see the suppliers operate: the operations side. Not because it is ideal, but because there is no one else who knows who logs in, who has logical access, who does the patching, who runs the back-ups, and which party grinds to a halt when a specific supplier goes down. The Dutch National Cyber Security Centre stresses in its guidance on supply chain security that visibility of suppliers starts with who they concretely are and what they concretely do, not with an abstract policy. That visibility sits on the shop floor, and that is where the function has to start too.

What exactly does a TPRM function do, regardless of who carries it out?

Four things, and it is useful to get each of them clear one by one, because many organisations already do one or two of them and think they are there.

The first is identifying and classifying. Who are your ICT third parties, what do they do, and how critical are they. An external SOC provider delivering 24/7 detection is something other than a design agency that supplies a PowerPoint template once a quarter. Both are third parties, but the second falls outside any meaningful TPRM scope. Classification is not an administrative box-ticking exercise, it is the filter you prioritise with later. In its publications on supply chain security, ENISA works with categories such as access to data, access to systems, dependency in the event of an outage and presence in critical processes. Those four questions together give a workable classification.

The second is contractually anchoring what needs to be agreed. That is not "signing an NDA". It is a set of provisions that differs by category: notification periods for incidents, the right to conduct audits or request audit reports, sub-outsourcing restrictions, security standards the supplier commits to, exit provisions and data return. DORA Article 30 sets out literally, for financial entities, what an ICT third-party agreement must contain as a minimum. An organisation outside DORA scope can still use that list as a framework, because it is in essence what a reasonable buyer would agree to.

The third is verifying periodically. A supplier that met the requirements at signing does not automatically still meet them two years later. Verification means: requesting valid certifications, requesting or commissioning a current assurance report (ISAE 3402, SOC 2, ISO 27001 certificate), and for highly critical suppliers a check of your own or a joint exercise. ISO 27036-3 calls this "ongoing assurance" and it is exactly where most organisations fall short: they have built up a file at moment T and then do nothing more with it until moment T plus four years.

The fourth is knowing an exit path before you need it. What happens if this supplier goes bankrupt tomorrow, is acquired by a party you do not trust, or suffers a data breach that makes it unusable. Who then takes over which task, within what timeframe, at what cost. DORA Article 28 makes this a mandatory exit strategy per critical supplier for financial entities. For everyone else it is common sense. A TPRM function without a thought about exit is a file that does not work at the moment it needs to work.

What does a lightweight TPRM function look like when you have no team?

This is the dividing line between what textbooks prescribe and what a mid-market organisation can bear. The textbooks describe an ideal TPRM organisation with roles, tooling, annual cycles and integrated dashboards. That ideal form is achievable for few organisations and unnecessary for most. What is needed is a minimum set that can handle the law and that holds up under a reasonable audit. The rest is a matter of degree.

The minimum set consists of four components that any organisation can set up with the people already in place, provided someone takes ownership of it:

A supplier register. One list, one source, no shadow lists in inboxes. Record per supplier: name, internal contract owner, type of service, access to which systems or data, criticality classification, contract end date, date of the latest assurance document, owner at the supplier. A spreadsheet is enough, provided it is kept up to date. Better a working spreadsheet than a dead TPRM platform.

A classification matrix with three or four levels. Critical, high, medium, low. The criteria made explicit: which data, which system access, which dependency in the event of an outage, which presence in critical business processes. The classification determines the controls placed on that supplier. A critical supplier gets annual verification and an exit plan. A low one gets a contract check and nothing more. Without that filter every supplier is treated the same and nothing happens with any of them.

A set of standard contractual clauses. Not renegotiating for every supplier, but one set that forms the basis: an obligation to report incidents within 24 or 48 hours, the right to audit reports or certifications, sub-outsourcing consent, security standards, data return and deletion on termination, exit cooperation. Supplement or strengthen per classification. This set is a one-off effort and after that a copy-and-paste exercise. DORA Article 30 is the strictest list you can take; for anyone outside DORA it is excessive but usable as an upper bound.

A verification cycle per classification. For critical suppliers: request an assurance document each year, hold a conversation, renew the exit plan. For high: every two years. For medium: at contract renewal. For low: only register and run a contract check at renewal. Record who does what and when, in the same list as the register. A cycle without an owner is not a cycle, it is a good intention.

Four components, one owner, one list. That is the floor. An organisation with this in place can demonstrate under NIS2 and DORA that its supply chain is managed. Anyone who wants more can add tooling, organise joint exercises with critical suppliers or set up a security-questionnaire flow. But that expansion is added value, not a precondition. The precondition is that the minimum set is running.

Where does this get stuck in practice, and how do you prevent it?

We see three patterns recur, and they all have to do with the difference between "we have set this up" and "this works".

The first pattern is ownership that floats between procurement, IT and security. Procurement says it is about risk, so security. Security says it is about contracts, so procurement. IT says the suppliers work fine, so what would it have to do with them. The result: no one keeps the register up to date, no one sends the verification reminders, no one watches over the exit plans. The solution is not a reorganisation, it is a name. One person on the list, with the authority to ask procurement and IT for what they need, and with a half-yearly review with their manager. In organisations without a TPRM team, that name often sits with the operations function, because the visibility already sits there.

The second pattern is the register that is a snapshot. An external party carries out a supplier assessment, delivers a report, and the report is stored on a SharePoint. Two years later there is a NIS2 supervisory query, and the report turns out to cover suppliers that in part no longer exist, in part have carried on under a different name, and in part have been supplemented through sub-outsourcing with parties that do not appear in the report. The report is correct on the day it was delivered, and irrelevant on every day after. The solution is for the register to be a living document that moves with every contract change, not a document issued once per project.

The third pattern is contractual clauses that are never tested. The clauses are in every contract, the suppliers sign them. Until an incident occurs and it turns out that the 48-hour reporting obligation landed on the desk of an account manager who was on holiday, that the audit right was refused in practice, or that sub-outsourcing had long since taken place without notification. A contractual clause that is not tested even once per cycle is a paper agreement. The solution is simply to ask critical suppliers, each year or every two years, for evidence that the clauses are being complied with: send us your incident-reporting process, send us your list of sub-contractors, send us your latest audit. Asking the question often brings more to the surface than the answer itself.

What does this mean for the conversation that operations leadership has?

The message upward does not have to be a cautionary tale about what NIS2 or DORA might cost. It is simpler: there is a working habit around suppliers that is currently assigned to no one, that legislation and reasonable audits are going to require of us, and that can be set up with four components and one owner without adding a department. The choice is not "set up a TPRM team or nothing". The choice is who watches over the minimum set, and how much time that takes per month.

The operations manager who already informally performs part of this function is in effect having two conversations internally at once. One is about recognition: make it visible that the work is happening and who does it, otherwise it stays unseen and vulnerable to falling away during holidays or on departure. The other is about the framework: set down what the minimum set is, so that the work neither expands to every small supplier nor shrinks under workload. Both conversations cost little, provided the framework and the owner are explicit.

Choosing a lightweight function is not a compromise on quality. It is a recognition that the law asks for demonstrability, not maximum maturity. A working floor that is kept up to date stands stronger than an ambitious framework that dilutes. An organisation that gets the minimum set in order this year has the room to build it out next year. Anyone who waits until there is a team waits in practice until the first incident or the first supervisory letter, and then the discussion shifts from setting up to accounting for. That order is the most expensive.