Third-party risk management: control of supplier risk

What is third-party risk management?

Third-party risk management, often abbreviated to TPRM, is the way you assess and control risks of external parties structurally.

That goes wider than cybersecurity.

Remember, too.

• continuity;
• privacy;
• compliance;
• finance;
• concentration risk;
• reputation.

For Kynexis, the focus is on digital dependencies.

Do not start with every supplier as heavy as you can

A caterer and your central SaaS platform don't ask the same assessment.

For example, classify suppliers at:

• access to sensitive data;
• access to systems;
• importance for critical processes;
• Replaceability;
• repair impact;
• subcontractors;
• geographical/legal dependencies.

Then a simple layout is created such as:

• criticism;
• high;
• regular;
• Down.

The depth of assessment then follows from the classification.

What do you want from a critical supplier?

For a critical IT provider, I look at at at least five things.

1. What exactly does the party deliver?

Which processes, systems and data are dependent?

2. What access does the party have?

Does the supplier have management rights, API access or access to personal data?

3. What security is agreed?

What requirements are in contract, SLA, DPA or security annex?

4. What evidence is available?

For example certifications, assurance, audit reports, test results or KPIs.

5. What happens when you fail?

How quickly is it restored, who decides and what are alternatives?

Contracts are important but not sufficient

A contract can contain excellent security clauses.

The interesting question is:

How do you know the supplier's gonna stick to it?

For example, you can use:

• ISO 27001 certificate with appropriate scope;
• SOC reporting;
• ISAE reporting;
• penetration test summary;
• audit report;
• SLA reporting;
• incident statistics;
• restore test;
• supplier review.

Read the scope and exceptions.

A certificate at group level doesn't say much when your specific service is outside scope.

Who assesses supplier risk?

That's rarely just buying.

Depending on the supplier, the following may be involved:

• business owner;
• IT;
• security;
• privacy;
• procurement;
• finance;
• legal function;
• Risk/control.

I think one owner per critical supplier is important.

Otherwise, the supplier remains everyone's and often nobody's.

Make risk ownership explicit

A supplier may implement a measure.

The organisation itself must decide the risk it accepts.

Examples include:

A supplier only provides daily backup while the organisation finds up to four hours of data loss acceptable.

Then there's a difference between need and service.

That requires a decision.

Not just a technical ticket.

What do you do with assurance?

Assurance is valuable when you use it.

I can see that an organisation receives an ISO certificate or SOC report and then records it.

Read at least:

• Scope;
• period;
• exceptions;
• findings;
• Supplementary controls;
• subcontractors;
• relevant restrictions.

Then ask:

What does this mean for our own risk?

Think of the chain behind the supplier

Your direct supplier often uses other suppliers.

Cloud hosting.

Authentication.

Data centers.

Support parties.

Software components.

In critical services you should therefore know:

• which essential subcontractors exist;
• where concentration risk exists;
• any changes notified;
• What exit possibilities you have.

Suppliers' Incidents

Pre-capture:

• how quickly incidents are reported;
• what information you are getting;
• who is contact person;
• how updates are done;
• when forensic information becomes available;
• how privacy or legal notifications are supported.

During a major incident, we are looking for the contract too late.

Continuity and exit

I also judge a critical supplier on the question:

How do we get out of here if we have to?

Remember:

• exportability of data;
• ownership of data;
• documentation;
• transfer;
• escrow where relevant;
• alternative suppliers;
• restoration in the event of bankruptcy;
• notice periods;
• support for exit.

A good exit strategy makes dependency visible.

How often do you judge suppliers?

Not every supplier every quarter.

Work risk-driven.

Examples include:

• critical suppliers annually plus major changes;
• high risks periodically;
• other suppliers in the event of contract extension or relevant change.

Triggers may be:

• major incident;
• takeover;
• modified services;
• new subcontractor;
• deteriorated SLA;
• changed regulations.

What does the board/direction want?

No spreadsheet with a hundred suppliers.

I'd like a compact image:

• which suppliers are critical;
• the most serious risks;
• where assurance is missing;
• which incidents occur;
• which contractual gaps exist;
• which improvements are lagging behind;
• where there is concentration risk.

For oversight, the question of whether the board knows and controls these dependencies is particularly relevant.

A Practical Supplier Dashboard

That makes more sense to me than a generic supplier score.

My starting point

Third-party risk management does not need to become a huge compliance program.

Start with the suppliers that can really hit your organisation.

Know:

• which you depend on;
• the risk involved;
• what proof you have;
• the agreements that are missing;
• who owns it.

It'll give us a grip.

Would you like to deepen that analysis for your main suppliers? Read how to assess a critical IT provider.