TPRM starters guide (1): Capability setup

A 6-step approach is used whereby every step will be an explanatory blog post:

1. Capability setup (this blog post)
2. Requirements overview
3. Third-party catalogue
4. Segmentation
5. Due diligence assessments
6. Risk monitoring & follow-up

We will first start with a definition of third-parties, a short summary of reasons why organisations are ramping up their TPRM capabilities (and why you should also do that), after that we will explore the key elements of any TPRM capability program. This section provides you with a lot of valuable insights and hands-on guidance on how to properly kick-start your own TPRM efforts.

The first key takeaway is that a TPRM capability differs per organisation due to its size, industry, geographical location, compliance requirements or level of dependence on third-parties. There is no one-size-fits-all approach that some of the external consultants want you to believe. But on the other side, you do not have to start from scratch (which also some of the consultants try to sell); there is a standard structure that contains all the critical elements of a successful TPRM implementation.

In this blog post, we will provide and explain these different elements. You can freely use these to explore, tailor and define your own TPRM capability.

What is third-party risk management?

Let's first break down the concept of third-party risk management and start with our definition of third-parties:

Third-parties are all external parties that you do business with or have some formal involvement with. So these all your vendors, suppliers, service providers, business partners, joint ventures, alliances, distributors, resellers, agents, contractors and many more.

Managing the risks at these third-parties is what we call third-party risk management. A specialised risk profession that is completely dedicated to risks and compliance requirements that are associated with third-party relations.

Why do I need to set up a new third-party risk capability?

As previously discussed, there are several reasons why most organisations are these days ramping up their third-party risk management efforts:

• There is an increase in the number of third-party collaborations.
• The level of dependence on third-parties is growing. Organisations used to outsource secondary processes, but nowadays, we do see a strong movement that third-parties are becoming responsible for the core activities of organisations.
• The level of compliance requirements and attention of regulators is shifting. With GDPR and the UK Slavery act, we do see a compliance demand that is enforcing organisations to allocate more efforts to actively investigate and monitor their third-party engagements.
• External events, like the US-China trade conflict and COVID-19, exposed organisations to a new magnitude of third-party risks and incidents. Based on the latest Deloitte research, companies that have a mature third-party risk approach are better in coping and recovering from global events like these.
• Cybercriminals are shifting their focus to third-party/ecosystem attacks, whereby they attack the weakest link in your ecosystem to gain access to your infrastructure.

Core elements of a new third-party risk capability

There is a blueprint for a successful TPRM capability. In the upcoming sections, we will discuss the different elements and conclude with the process steps that you should take.

Lets first start with the high-level structure. if you would like to set up and implement a new (or improve an existing) third-party risk capability, you must cover the following elements:

1. Vision
2. Scope
3. Discipline(s)
4. Risk domain(s)
5. Involved stakeholders
6. Ownership
7. Primary
8. Operational
9. Operating model
10. Mandate
11. Technology

Before you start, it is key to first to assign a single leader of the TPRM implementation program. This person is coordinating the input and mutual agreement of the core elements that we are about to discuss.

1. Vision

The first step of any implementation is to define the vision around third-party risk management within your organisation.

What do you want to achieve with TPRM?

Some supporting questions to ask yourself:

• How does it relate to our corporate strategy?
• Do we foresee an increase in third-party collaborations?
• Do we want to realise a cost reduction on third-party incidents?
• Are we dealing with stricter compliance requirements?
• Do we want to learn from a past third-party incident?
• Do our customers or partners have higher or different expectations?
• Do we foresee a re-prioritisation of TPRM reporting needs and requirements on the senior levels?
• Are there other things we would like to achieve with TPRM?

A clear vision will guide you in the setup and is key for the management buy-in.

2. Scope

After you have formulated a vision, we will start with defining the scope of your TPRM capability; which risk domains will the capability cover (only sustainability, or also security), which internal disciplines are involved, and what are the other internal stakeholders?

2.1 Risk domains

Let's first start with the risk domains that you would like to manage. Third-parties can expose you to different types of risks, e.g.:

• Information security / cybersecurity *
• Anti-bribery and corruption *
• Privacy risks *
• Sustainability risks *
• Strategic risks
• Regulatory/compliance risks
• Subcontractor risks
• Technology risks
• Financial risks
• Continuity risks
• Reputational risks
• Geographical risks
• Political risks
• Supply chain risks

Although there is a common selection of domains (the ones marked with an *), these can differ based on:

The industry that you are active in

Organisations within the chemical industry often have more emphasis on environmental risks.

The geographical location of your third-parties

Certain Asian countries have a higher risk of slavery or sustainability issues.

Level of dependency

If your service or product is heavily depending on subcontractors, you put more focus on continuity risks.

Type of business that you and the third-party are engaging with

If you are outsourcing your payment processing activities, you will have to manage the involved financial and data privacy risks that are the result of this outsourcing decision.

Level of applicable compliance

Some industries, like the health care and financial sector, are more regulated.

Use the provided criteria to select and prioritise the relevant risk domains.

2.2 Involved discipline(s)

After the selection of risk domains, you can identify the involved risk discipline(s), e.g.:

• Risk & Compliance *
• Information security / CISO *
• Privacy *
• Sustainability *
• Procurement *
• Logistics
• Quality
• Regulation and compliance
• Finance
• Legal counsel
• Internal audit
• Supply chain/logistics

Or do you proceed with a multidisciplinary / organisation-wide third-party risk team * ?

* = Typical departments to start with.

Use your risk domains (section 2.1) to identify the relevant disciplines, if you e.g. select the privacy risk domain, it would make sense to involve your privacy team within your TPRM efforts.

After the selection of risk domains, you can identify the involved discipline(s) within your TPRM capability.

2.3 Other stakeholders

Complementary to the directly involved disciplines, you should also identify the different other involved business stakeholders within the selected risk domains. Exactly how, when, and where are they involved? Procurement, for example, generally owns the onboarding and third-party management process, while business owners and centralised risk assessors interface with the risk subject matter experts at critical points, such as during the initial and ongoing risk assessment process.

It is common to go back and forth between those three scope elements and make adjustments over time.

3. Ownership

When you have a defined scope that consists of involved risk disciplines, domains and other stakeholders, you can assign formal ownership for the TPRM program. Whereby we commonly distinguish two types of ownership:

• The primary ownership (accountable for TPRM)
• The operational ownership (responsible for TPRM)

3.1 Primary ownership (accountable for TPRM)

Third-party engagement and incidents have a direct impact on the continuity and reputation of your organisation; that is why it is advised to put accountability at the top of your organisation. In the latest industry surveys from EY, Deloitte and KPMG, we also do see that CEOs and board members are increasingly accountable for TPRM:

•  CEO *  
•  CFO *  
•  CRO *  
•  CSO / CISO *
•  Procurement
•  Legal
•  BU leadership
•  Audit  
•  Other  

* = Most common roles that are accountable for TPRM within an organisation.

These senior executives are ultimately responsible for the successful execution of the third-party capability, and they discuss significant deviations and risks in line with their risk appetite.

Put accountability for TPRM at the top of your organisation.

3.2 Operational ownership (responsible for TPRM)

The people with primary ownership are regularly not the people tasked with running the TPRM capability, but they assign operational responsibility to other members of the C-suite, business unit leaders with the additional support of second-line departments (e.g. Risk & Compliance or Procurement). In this step, we will identify and assign this operational ownership.

As a guidance, you can use the decision made in the involved discipline(s) of the scope section (section 2.2):

• If you initially start with only cybersecurity risks as your scope, then it is probably your security team. If you select one or two more disciplines, it is probably most pragmatic to discuss internally who is going to take the end-responsibility.
• With an organisation-wide TPRM capability it is common to set up a dedicated third-party risk team or assign the responsibility to a Risk & Compliance or Procurement department.

After a clear primary responsibility, you can define the operational ownership of TPRM within your organisation.

4. Operating model

To set up an operating style to manage your identified third-party risk domains (section 2.1) across business lines and regions, you can either chose for a centralised or distributed model.

Distributed model *

In a distributed model, the business relationship manager will coordinate inherent risk assessment activities within the organisation.

The business will perform the risk assessment activities.

Centralised model

Alternately, you can set up a centralised team that facilitates the inherent risk assessment on behalf of (and with input from) the business.

A centralised team will perform all the risk assessment activities.

* = Most commonly used.

Based on the latest research from EY, Deloitte, Protiviti and KPMG, we do see that it is these days more common to have a centralised team that executes the risk assessment activities for the organisation. The primary reason is that organisations would like to have a more holistic view of the complete risk landscape and that there is an overall higher cost to maintain a distributed model.

Invest some time to select the right operating model, including the high-level roles & responsibilities and supporting processes.

5. Mandate

When you have defined the scope (risk domains, risk discipline(s), other stakeholders), ownership (primarily and operational) and know the operating model, it is time to identify the requirements needed to ensure the right level of the internal and external mandate for the capability to perform the different third-party risk activities.

In most corporations, you probably need a formal governance change, new global policy and you have to discuss with procurement and contract managers the terms and conditions towards new and existing third-parties.

A clear mandate is needed to get your TPRM capability formally up and running within the organisation.

6. Technology

TPRM is a typical capability whereby technology is really beneficial and can give you a head start when you start from scratch. With TPRM you will process large volumes of data, have a lot of repetitive low-level activities, and it is for most organisations a commodity capability whereby you can easily leverage best-practices (both on content as technology setup).

You have different technology strategies that you can follow:

1. Spreadsheets

In the latest research, we do see that organisations are moving away from their spreadsheet approach. The main problem is maintenance (most common issue: "the colleague that created all the advanced macro spreadsheets left the organisation..."), data integrity, scalability and lack of automation. These are all key elements of a robust TPRM approach, so this should be your least prefered option.

2. GRC tooling

Most popular GRC platforms, like Riskonnect and RSA, do offer VRM modules which you can use to manage TPRM activities. The common downside of these solutions is the price (implementation costs and monthly licenses), rigid platform setup and implementation efforts. In addition, these are more generic risk solutions that are tailored to this type of risk, which makes it not the best solution for third-party risk management. It can some case the prefered solution when you already have a complete Archer landscape.

3. Third-party screening solutions

These are point solutions like CyberGRX, BitSight and SecurityScoreCard. They will provide you with generic information about security and risk postures of your third-parties. This information can be helpful but you should always approach it with your own context.

E.g. how does a critical vulnerability identified at Atos.net relate to the in-house sourced workplace management contract that you have with them? I don't know but I guess limited.

That is why these services are perfect for some sort of risk sensing, which you can integrate within your TPRM technology strategy, but this can never be the foundation of your TPRM program. Especially since they are, as a point solution, also not covering the other TPRM processes and supporting workflows.

4. Specialised SaaS TPRM solution (like our 3rdRisk platform)

These are software solutions completely built for managing third-party risks. They provide standardised workflows and cover all important TPRM processes out-of-the-box. A common deployment model is SaaS and they are shipped with best-practice configurations. This means that you will not have any long term contracts, no operational maintenance, and it will be up and running in a few minutes. If you are about to start with TPRM than this solution is the sweet spot; it is future proof, financially attractive (It's a fraction of what a GRC module cost you) and you can integrate it with your existing infrastructure (e.g. procurement systems) and external third-party risk screening solutions.

So my advice is to go for option 4. Avoid in any case the spreadsheet approach, this includes PoC (Proof of Concept), as you can also easily leverage a TPRM SaaS product for a few weeks/months. Eventually, you will be held hostage by your own created spreadsheets.

Select a supporting technology strategy that suits your need, requirements and organisation.

Next steps

Setting up a TPRM program is complicated, but with a little guidance, you are able to fully implement TPRM within your organisation. In the next blog post, we will discuss the identification of requirements that you need to incorporate within your program. So keep following our social channels (LinkedIn, YouTube, Twitter) for the latest content updates.

Further reading

Starting with third-party risk management (2): How to define your requirements? 

‍