What Is Third-Party Risk Management? A Practical Introduction for GRC Analysts

Introduction

Imagine you have just joined a financial technology company as a GRC analyst.

The organisation is preparing to introduce a new cloud-based customer support platform. The system will allow employees to respond to customer enquiries, review transaction-related complaints and access customer information.

The Operations Manager has already selected a supplier. The procurement team is negotiating the contract, and the business wants the system operational within two weeks.

Your manager asks you a question:

"Have we assessed the risks associated with this supplier?"

Where would you begin?

You might need to understand the services being provided, the information the supplier will access, the consequences of a service failure, the supplier's security arrangements and whether the organisation has approved the resulting exposure.

These activities are part of Third-Party Risk Management.

In this guide, you will learn what TPRM means, why organisations need it, how a typical supplier assessment works and what a GRC analyst contributes to the process.

1. What Is Third-Party Risk Management?

Third-Party Risk Management (TPRM) is the process through which an organisation identifies, assesses, manages and monitors risks arising from relationships with external organisations.

A third party may provide technology, process information, deliver essential services or support an organisation's business operations.

Examples include:

• Cloud hosting providers.
• Payment processing companies.
• Software-as-a-Service (SaaS) providers.
• Managed IT service providers.
• Payroll and human resources platforms.
• Customer support providers.
• External consultants and professional services.
• Logistics and operational service providers.

These relationships can help organisations operate more efficiently, reduce costs, access specialist expertise and deliver services that would otherwise be difficult to provide internally.

However, they can also introduce risks.

When an organisation depends on another company, events affecting that company may also affect its own operations, customers, finances or compliance obligations.

TPRM helps the organisation understand these exposures and decide how they should be managed.

Third-party risk vs supplier risk

The terms third-party risk management, supplier risk management and vendor risk management are often used interchangeably.

However, third-party relationships can be broader than traditional purchasing arrangements.

For example, an organisation might exchange sensitive information with a strategic partner without buying a conventional product from that partner.

For this learning pathway, we will focus primarily on suppliers that provide technology, handle information or support important business services.

2. Why Does Third-Party Risk Management Matter?

Consider a company that operates an online banking application.

Although the company develops its own customer-facing application, it relies on external providers for cloud infrastructure, payment processing, identity verification and customer communications.

If one of these providers experiences a serious disruption, the bank's services may be affected even when its internal systems are operating correctly.

Similarly, an attacker who compromises a supplier may be able to exploit a trusted integration or obtain information entrusted to that supplier.

The business may therefore face consequences arising from systems and processes it does not directly operate.

TPRM is important because outsourcing a business activity does not automatically remove the organisation's responsibility for managing the associated risk.

Common categories of third-party risk

Risk category	Example
Cybersecurity	A supplier's compromised administrative account exposes a connected system
Data protection	A service provider mishandles personal information
Operational resilience	A critical cloud provider suffers prolonged downtime
Regulatory compliance	A relevant supplier arrangement fails to meet applicable contractual or regulatory obligations
Financial	A supplier becomes insolvent and can no longer deliver a necessary service
Concentration	Several essential services depend on the same underlying provider
Reputational	A supplier incident causes customer harm and damages trust

These risks can overlap.

A single supplier security incident might result in service disruption, information exposure, contractual disputes and reputational damage.

The purpose of TPRM is not to avoid every external relationship.

It is to ensure that significant dependencies and exposures are understood, managed and appropriately authorised.

3. The Third-Party Risk Management Lifecycle

TPRM is not a one-time questionnaire completed when purchasing a product.

It generally continues throughout the supplier relationship.

A typical lifecycle includes the following stages.

Stage 1: Supplier identification and onboarding

The organisation identifies a need for an external product or service.

Before approval, it gathers basic information about the supplier, the proposed service and the business dependency.

Stage 2: Supplier criticality and inherent risk assessment

The organisation determines how important the supplier is to its operations and what risks the proposed relationship could introduce.

This helps establish the level of review required.

Stage 3: Due diligence and control assessment

Relevant evidence is requested and evaluated.

This may include security questionnaires, independent assurance reports, relevant policies, technical evidence and explanations of the supplier's control arrangements.

Stage 4: Risk evaluation and treatment

The organisation documents identified weaknesses, assesses remaining exposure and decides whether the relationship requires additional controls, remediation, restrictions or formal risk acceptance.

Stage 5: Contracting and approval

Appropriate decision-makers review the proposed arrangement.

Relevant contractual protections, responsibilities and requirements are established before the relationship proceeds.

Stage 6: Ongoing monitoring

The organisation monitors important changes, supplier performance, incidents, outstanding findings and the continued suitability of relevant controls.

Stage 7: Termination and exit

When a relationship ends, the organisation considers access removal, data return or deletion, continuity arrangements, contractual obligations and transition risks.

The exact process differs between organisations. Some stages run in parallel, and the depth of review should reflect the nature of the relationship.

A low-risk stationery supplier will generally require a different level of cybersecurity review from a provider hosting production financial systems.

4. Understanding Supplier Criticality

One of the first questions in TPRM is:

How important is this supplier to the organisation?

Supplier criticality concerns the potential consequences if the supplier cannot deliver its service, or if its service is seriously compromised.

Factors commonly considered include:

• Whether the supplier supports a critical business process.
• The likely operational impact of an outage.
• Whether customer services would be interrupted.
• The sensitivity and volume of information involved.
• The supplier's access to systems or infrastructure.
• The availability of alternative suppliers.
• How quickly the organisation could recover or replace the service.
• Relevant legal, regulatory and contractual consequences.

Example: Three suppliers

Meridian Financial Services, a fictional UK fintech company, uses the following suppliers.

Supplier	Service	Initial criticality considerations
CloudCore Hosting	Hosts production payment applications	Direct dependency for essential customer services
HelpDesk Cloud	Provides customer support software	Access to customer records and potential service impact
OfficeSupply Direct	Supplies office stationery	Limited impact on critical technology services

CloudCore Hosting is likely to be highly critical to the organisation's operations.

HelpDesk Cloud may also require substantial review because of its access to customer information, even if an outage would not stop payment processing.

OfficeSupply Direct would generally require less cybersecurity scrutiny, assuming it has no unusual access or integration.

Criticality is not the same as security quality

A supplier can be operationally critical while maintaining strong security controls.

Another supplier may support a less critical service but have serious security weaknesses.

Supplier criticality describes the importance of the dependency. Security assurance examines the safeguards relevant to that dependency.

These concepts should be assessed separately.

5. Inherent Risk and Residual Risk in TPRM

If you have completed the ERM pathway, you will already be familiar with inherent and residual risk.

The same general principles apply to supplier relationships.

Inherent supplier risk

Inherent risk considers the exposure associated with a supplier relationship before accounting for the safeguards relevant to the assessment.

For example, a service provider with privileged access to production databases presents potentially significant inherent exposure.

This does not automatically mean the supplier is insecure.

It means the nature of the relationship could produce serious consequences if relevant threats materialise.

Residual supplier risk

Residual risk is the exposure remaining after relevant controls are considered.

Suppose the supplier demonstrates restricted privileged access, enforced MFA, security monitoring, access reviews and tested recovery arrangements.

These measures may reduce exposure.

However, the GRC analyst must evaluate how relevant and effective the controls are before recommending a residual risk position.

An organisation should not automatically reduce a risk rating simply because a supplier claims to have implemented a control.

Supplier risk assessment example

A fictional fintech uses a five-by-five matrix.

Its preliminary assessment of a critical cloud provider produces:

• Inherent likelihood: 4.
• Inherent impact: 5.
• Inherent risk score: 20.

Following a review of evidence and relevant controls, its risk assessment team proposes:

• Residual likelihood: 3.
• Residual impact: 4.
• Residual risk score: 12.

These values are illustrative and must be justified using the organisation's approved methodology.

The score alone does not establish whether the supplier should be approved.

The analyst must also consider applicable risk appetite, evidence limitations, outstanding findings and the authority required for the decision.

6. What Is Supplier Due Diligence?

Supplier due diligence is the process of gathering and evaluating information to determine whether a proposed or existing supplier presents acceptable risks.

It should be proportionate to the service, dependency and potential consequences.

For technology and information-security assessments, information requests may cover:

Governance: Security policies, accountability, risk management and independent assurance.

Access controls: MFA, privileged access, account lifecycle management and authentication.

Data protection: Data handling, retention, encryption, access and deletion.

Vulnerability management: Patching, vulnerability assessment and remediation.

Incident response: Detection, investigation, escalation and notification arrangements.

Resilience: Backups, recovery testing and business continuity.

Subcontractors: Reliance on other suppliers that support the service.

Examples of due diligence questions

• Does the supplier enforce MFA for privileged accounts?
• How are critical vulnerabilities identified and remediated?
• What is the process for notifying customers of security incidents?
• Where will relevant customer information be stored or processed?
• How does the supplier verify backup restoration?
• Which subcontractors support the proposed service?

A questionnaire is useful for gathering information, but a completed questionnaire is not the same as independently verified assurance.

Responses should be evaluated and, where warranted, supported by appropriate evidence.

7. Understanding Supplier Assurance Evidence

Suppliers may provide documents such as:

• ISO/IEC 27001 certificates.
• SOC 2 reports.
• Independent security assessment reports.
• Penetration testing summaries.
• Security policies and procedures.
• Business continuity test records.
• Vulnerability remediation evidence.

These documents differ in purpose, scope, reliability and limitations.

Example: Reviewing an ISO 27001 certificate

Suppose a supplier provides a current ISO/IEC 27001 certificate.

Before relying on it, the analyst should consider:

1. Is the certificate authentic and current?
2. Which legal entity and locations does it cover?
3. What activities, systems and services are included in its scope?
4. Is the proposed service within that scope?
5. Is the certification body appropriately accredited, where relevant?
6. Are additional controls or assurance activities needed for the specific relationship?

A certificate can be valuable evidence, but it should not automatically be treated as proof that every product, service and system supplied by that organisation is secure.

The next TPRM lessons will examine assurance evidence in greater depth.

8. Who Is Responsible for Third-Party Risk?

TPRM normally involves several stakeholders.

Role	Typical responsibility
Business or supplier relationship owner	Accountable for the business dependency and associated risk
Procurement	Coordinates sourcing, supplier processes and commercial arrangements
GRC analyst	Facilitates assessments, evaluates evidence, documents findings and supports escalation
Information Security	Provides technical security expertise and control assessments
Privacy or Legal	Advises on applicable data protection, legal and contractual requirements
Senior management or risk committee	Makes decisions within its approved authority
Supplier	Provides information, operates agreed controls and addresses its responsibilities

The exact responsibilities depend on the organisation's governance framework.

Does the GRC analyst approve suppliers?

Not necessarily.

A GRC analyst may provide an assessment, challenge inadequate evidence and recommend whether a supplier should proceed subject to conditions.

The final approval should come from the person or body assigned the relevant authority.

For example, a GRC analyst might conclude:

The supplier presents elevated residual risk due to incomplete privileged-access controls. Approval should be conditional on satisfactory remediation evidence or a documented exception approved by the designated risk authority.

This is a recommendation informed by evidence, not an assumption that the analyst has the authority to accept the risk.

9. Practical Example: A New Customer Support Supplier

Let's return to Meridian Financial Services.

The Operations Manager proposes purchasing a customer support platform called AssistFlow, a fictional SaaS service.

The system will allow employees to access customer support records and transaction-related complaints.

The planned implementation is two weeks away.

Information available

• The supplier will process customer contact information and support records.
• The service will integrate with the existing customer management system.
• Twenty employees will use the platform.
• The supplier has provided a security questionnaire.
• The supplier claims to hold an ISO 27001 certificate.
• The supplier has not yet provided the certificate or its scope.
• The contract has not been finalised.

What should the GRC analyst do first?

The analyst should establish the scope and nature of the proposed relationship before deciding whether the supplier is acceptable.

This includes confirming the information involved, the integration permissions, the business dependency, the proposed data processing arrangements and the organisation's supplier approval requirements.

The analyst should then coordinate a proportionate assessment.

Step 1: Confirm the supplier profile

Record the supplier's service, relationship owner, proposed access, data categories and key dependencies.

Step 2: Determine criticality and inherent exposure

Consider the consequences of an outage, unauthorised access or mishandling of customer information.

The service may have limited effect on payment processing but potentially significant data protection consequences.

Step 3: Request relevant due diligence evidence

Request the ISO 27001 certificate and applicable scope, together with any additional information required by the assessment methodology.

Step 4: Evaluate findings

Identify whether the supplier's responses and evidence adequately address the relevant risks.

Where information is missing, record the limitation rather than assuming the control is effective or ineffective.

Step 5: Determine required governance actions

Provide findings to the accountable business owner and relevant specialists.

If the supplier will act as a processor of personal data on behalf of a UK controller, applicable UK GDPR controller–processor requirements, including Article 28 contractual terms, should be considered.

Not every third party is a processor, so the legal role must be determined from the actual processing arrangement.

Step 6: Prepare a recommendation

The analyst might recommend:

The proposed customer support supplier requires further due diligence before an unconditional approval recommendation can be made. Its assurance scope has not been verified, and the integration's information access and processing arrangements need confirmation. The business owner should coordinate outstanding evidence and obtain the required security, privacy and contractual reviews.

This recommendation does not automatically reject the supplier.

It explains the uncertainty, the work outstanding and the decision-making process needed.

10. What Documents Does a TPRM Analyst Produce?

A GRC analyst may be responsible for preparing or maintaining several records during supplier assessment.

Document	Purpose
Supplier inventory	Records supplier details and business dependencies
Criticality assessment	Documents the potential impact of supplier failure
Inherent risk assessment	Records exposure associated with the proposed relationship
Due diligence questionnaire	Collects supplier control information
Evidence review log	Tracks evidence received, assessed and outstanding
Supplier risk assessment	Records findings, controls, residual exposure and recommendations
Remediation tracker	Records outstanding actions and verification
Risk acceptance record	Documents authorised exceptions or accepted exposure
Monitoring record	Tracks ongoing review and significant changes

These documents may be maintained in a GRC platform, spreadsheet, procurement system or other approved tool.

A complete assessment should allow another authorised reviewer to follow the evidence, conclusions and decisions.

11. Common Mistakes New TPRM Analysts Should Avoid

Treating every supplier equally

Review effort should reflect the actual relationship and its potential consequences.

Confusing criticality with inherent risk

A critical dependency and the risk scenario associated with that dependency are related but distinct assessments.

Accepting questionnaire answers without challenge

Supplier statements may need corroboration, particularly for high-impact relationships.

Assuming certification covers everything

Always consider the scope and relevance of assurance evidence.

Accepting missing evidence as proof of failure

Missing evidence creates uncertainty. Further review is needed before drawing conclusions about control effectiveness.

Automatically rejecting suppliers with findings

A finding may lead to remediation, conditions, additional controls or escalation. The appropriate response depends on its significance and applicable requirements.

Assuming GRC owns supplier business decisions

GRC provides analysis and challenge. The business and designated risk authorities remain responsible for their decisions.

Forgetting ongoing monitoring

A supplier that was acceptable during onboarding may become riskier after changes to its systems, services, ownership or security posture.

12. Practical Exercise: Your First Supplier Review

You are a junior GRC analyst at a fictional online retailer.

The Marketing Department proposes using a new SaaS platform to manage customer campaigns.

The supplier will receive customer email addresses and purchasing preferences.

The supplier has provided a brief security questionnaire but no independent assurance evidence.

The platform must be operational before the next campaign.

Your assignment

Prepare an initial supplier assessment note covering:

1. The information you need to establish supplier criticality.
2. At least four risk areas relevant to the relationship.
3. Three items of evidence or clarification you would request.
4. The stakeholders who should participate in the review.
5. Your recommended next action and why.

Example response

Supplier criticality: Determine how the service supports marketing operations, the consequences of an outage, the volume and sensitivity of personal information involved, integration permissions and available alternatives.

Potential risk areas: Data protection, unauthorised information access, supplier incident response and subcontractor dependencies.

Evidence requests: Relevant assurance scope, access control details and data processing information.

Stakeholders: Marketing relationship owner, Information Security, Privacy or Legal, Procurement and GRC.

Recommendation: Complete a proportionate due diligence review before the normal supplier approval decision. Confirm applicable data protection and contractual requirements, record evidence gaps and escalate unresolved material issues according to the organisation's governance process.

Self-review checklist

A good response should:

• Recognise that business importance and security exposure are separate considerations.
• Identify risks relevant to the actual service.
• Request proportionate evidence.
• Distinguish the analyst's role from the risk owner's authority.
• Explain a defensible next action without making unsupported claims.

This exercise is intended for guided self-practice rather than automatic grading.

13. Key Takeaways

Third-Party Risk Management helps organisations identify, evaluate and manage risks arising from external relationships.

It covers more than completing supplier questionnaires.

An effective TPRM process considers supplier dependencies, inherent exposure, assurance evidence, residual risk, governance decisions, contractual arrangements, monitoring and exit.

Different suppliers require different levels of review.

A GRC analyst helps the organisation gather and challenge evidence, document relevant findings, communicate uncertainty and support properly authorised decisions.

The purpose of TPRM is not simply to approve or reject suppliers. It is to enable informed business decisions while managing the risks associated with external dependencies.

14. Further Reading

• NIST SP 1305: Cybersecurity Supply Chain Risk Management Quick-Start Guide
• NCSC: Principles of Supply Chain Security
• NIST SP 800-161 Revision 1: Cybersecurity Supply Chain Risk Management Practices
• ICO: Controller and Processor Contracts

Continue Learning

Next lesson: Understanding Supplier Criticality and Risk Tiering

In the next guide, you will learn how to classify suppliers according to business impact, service dependency, information access and other risk factors.

You will also practise selecting the appropriate depth of due diligence for different supplier relationships.