6 min reading
Wed Nov 10 2021

Assessing the risks of your third parties, part 2: setting up a third party risk management process (TPRM)


This is the second of introductory articles on third party risk management and the difficulties managing them. You'll find the first article here.

We could spend a lot of time and articles on the difficulties on managing a third party risk management program. There are a lot of common issues for most practitioners out there, managing the questionnaires, sending out and keeping track of those, assessing the results as objectively as possible, etc ... There are also a lot of issues individual organisations are struggling with which are not so common, think about managing the database of suppliers, determining which supplier is more or less critical, or even how to adapt current legal agreements to encompass the use of questionnaires. If you'd like to delve deeper into one such topic, or have another topic, don't hesitate to let me know.

Regardless of these common or individual issues, a good third party risk management program (TPRM) starts with a basic process. This process should describe what the TPRM is about, who are the stakeholders, what are their roles and responsibilities, but also; how to execute the process. I'll enumerate some must-have elements to include in your process.

1 Describe the types of risk you want to assess with your TPRM

Working with third parties will introduce multiple types of risks including;

  • Operational Risk; Risk of loss when an internal process, system, or people fail.
  • Transaction Risk; Risks introduced when services or deliveries fail.
  • Compliance Risk; Risks introduced from violations of regulations, rules, governing laws, or otherwise non-compliance to (internal) standards, policies, or procedures.
  • Information Security Risk; Risks introduced from unauthorized access, use, disclosure, disruption, modification, inspection, or destruction of information and/or underlying systems.
  • Reputation Risk; Risks introduced from third party relations that result in dissatisfied customers, negative public opinion, inappropriate recommendations, security breaches, disclosure of confidential data, violations of laws and regulations (think GDPR), etc ...
  • Strategic Risk; Risks introduced from averse or untimely business decisions, or decisions inconsistent with stated strategic goals.
  • Financial Risk; Risks arising from a potential financial backslash of working with a third party. Examples are losses from theft, lower quality, or introduced by risks above.

The number of risks monitored, how to monitor them and how detailed the information you require is all dependent on your organisation's risk appetite. You can start monitoring against all of the risks above, or you could select some of the most important and start small. Over time, when your TPRM program matures, you'll start segmenting your suppliers into critical and non-critical suppliers and suppliers more or less prone to any of the above-stated risks.

2 Define roles and responsibilities

Each process will have different stakeholders. With regards of TPRM we can at least enumerate the following roles, depending on your organisation or the granularity of the process you're developing there might be more or less;

  • Procurement & Legal; mainly involved in onboarding new suppliers, discussing new terms with existing suppliers, or terminating existing contracts (i.e. as a potential outcome of your TPRM process).
  • Business Owner; the person or department in charge of managing the business relationship of the supplier. Depending on how you set up your roles and responsibilities he or she could also be the accountable in case a risk manifests. Therefore this role also ought to be the risk owner when a risk is identified.
  • Risk Manager; this role could be split up into different smaller roles depending on the size of the TPRM program, but this is the role that determines how to evaluate the risk (create the questionnaire, send it out, and assess and interpret the results, and follow up on risk mitigation).
  • CISO/CIO/COO/CFO; depending on the type of risk, and the severity thereof, this role will play a major role in the risk mitigation process. Think about accepting high-severity risks, or escalating when a critical mass of risks has been accumulated over time or when a risk mitigation process can not be achieved for whatever reason.

3 Define the actual process

Obviously the process document should describe the overal process. Overall a TPRM process will encompass these different steps;

  1. Identify: identify which suppliers need to be evaluated, for which risks and how. Send out the questionnaires or other means of evaluation.
  2. Assess & Evaluate: the risk manager will assess and evaluate the outcome of the risk identification phase together with the other stakeholders (i.e. the business owner to place the outcome in his or her context).
  3. Monitor & Follow-up: next phase is the monitoring and follow-up phase. Follow-up is where we work with the supplier to mitigate the identified risks. Monitor is where we set up a continuous monitoring loop to re-assess the discovered risks if needed, and determine the process of how, and when, to evaluate the same supplier again.
  4. Escalation & Termination; When working with the supplier, or internal stakeholders, doesn't yield the expected results (i.e. a proper management of the identified risks), it's time to either escalate to a higher level, or to consider terminating the relationship with the supplier.

4 Design a system, supported by appropriate tooling, to support your TPRM program.

Your process document should describe how you can ensure to iterate your process on a consistent basis, objectively evaluate the supplier responses or evaluation outcomes, and properly follow up on all outstanding risks. Ultimately organisations should move away from using spreadsheets to manage their questionnaires and email from sending out and following up on assessments. A centralised tool or software package should be able to;

  • Create a centralised list of suppliers, their completed and assessed questionnaires, any evidence provided so far, and their latest status on open risks.
  • Allow you to quickly and easily create new questionnaires, by adding to questions or choosing from existing questions in a library or starting from a list of existing questionnaires based on ISO, NIST, NIS, CyberEssentials, or any other standard, framework, or best practice list.
  • Include a system to assist you in following up on open actions and unmitigated risks.
  • Be completely end to end, the software should enable you to move away from a collection of spreadsheets, emails, documents, and headaches.

5 Ongoing monitoring

Current TPRM programs at organisations rely heavily on sending out questionnaires. While we can fine-tune the questionnaires to the type of risk monitored and the severity level of the supplier, they still have a huge impact on the workload of not only internal teams, but on those of the supplier as well. Consequently, a questionnaire is sent out either only once, when the supplier is onboarded, or at best, once per year.

But there are other means to evaluate a supplier in between. Going from friendly in-between calls to follow up on open risks, performing vulnerability scans and penetration tests on delivered projects (don't forget to link those with your TPRM outcome!), but also by using automated security rating scans.


Running a full-featured TPRM program can be quite cumbersome and needlessly increase overhead on already thinly stretched teams. However implementing a sound TPRM process, adequate tooling, and properly described and enforced roles and responsibilities will greatly help in lowering the overhead and costs of running a TPRM program as well as increasing the value and return on investment.

Jimmy pommerenke Ceeyu

Jimmy Pommerenke


Jimmy is the founder, CEO and CTO of Ceeyu. Prior to founding Ceeyu, Jimmy was responsible for cybersecurity programs at large financial institutions and consulting company EY. Jimmy started his career as a security engineer. His duties included installing and managing firewalls, scanning infrastructure for vulnerabilities, and performing pen testing and ethical hacking.

Other Blogposts

Ceeyu UI

NIS2: Essential entities vs Important entities, what’s the difference?

The impact of NIS2 for essential and important entities is not much different when it comes to implementing controls to comply, as they are ...

December 11, 2023


The EU DORA regulation and third party risk

With the DORA regulation that the EU aims to strengthen the IT security of financial services and industries. This means banks, insurance co...

July 17, 2022


How to manage the third party risks posed by your critical suppliers

This blog post walks you through some ideas on how to navigate the complex web of third-party risks, focusing on critical suppliers.

June 27, 2022