Third-Party Risk Management: A Practical Supplier Assurance Guide

Third parties are essential to modern organisations. Suppliers provide software, infrastructure, professional services, specialist skills and access to capabilities that would be difficult to build internally. They can also introduce cyber risk, operational dependency and uncertainty into the organisation's supply chain.

Third-party risk management is the discipline of understanding, assessing and managing those risks throughout the relationship. It is not simply a procurement questionnaire, a security certificate or a one-off approval. It is a practical way to make better decisions about suppliers, vendors and external partners before, during and after engagement.

My perspective comes from working on supplier assurance, security risk assessments and external-organisation onboarding in complex, regulated environments. I have seen how quickly a supplier process can become a delivery constraint when ownership is unclear, evidence is scattered or every organisation is assessed in exactly the same way. I have also seen how a proportionate, evidence-led model can improve security without making legitimate delivery impossible.

What third-party risk management means

Third-party risk management is the structured process of identifying and controlling the risks created by an external organisation's products, services, people, technology and dependencies.

It normally includes:

• understanding why the organisation is needed and what it will deliver;
• identifying the information, systems and facilities involved;
• assessing the supplier's security, resilience and operating model;
• agreeing appropriate contractual and technical requirements;
• deciding whether the residual risk is acceptable;
• onboarding the supplier through controlled processes;
• monitoring changes, incidents, evidence and performance; and
• reassessing or exiting the relationship when circumstances change.

A mature approach distinguishes between supplier risk, service risk and access risk. These decisions are connected, but they are not interchangeable. A supplier may be suitable for one service but not another. A low-risk service may become higher risk if it receives sensitive data or privileged access. The assessment needs to reflect the relationship that is actually being proposed.

What is third-party risk management?

It is the lifecycle discipline used to understand, assess, approve, monitor and exit relationships with suppliers, vendors, contractors and external partners. The aim is not to remove all risk; it is to make important risk visible, owned and managed.

Why supplier risk is a business risk

A supplier can affect more than information security. Failure may interrupt operations, delay a project, expose confidential information, create regulatory issues or make it impossible to deliver a contractual commitment.

The potential impact is often wider than the direct service. A supplier may rely on subcontractors, cloud platforms, managed service providers, logistics partners or software components that are not obvious from the original contract. A business can therefore inherit dependencies without having a complete view of them.

The most useful starting question is not "Does this supplier have a security certificate?" It is:

What could happen to our organisation if this relationship failed, was compromised or changed without our knowledge?

That question leads to better conversations about criticality, data, availability, concentration risk, recovery, substitution and accountability. It also prevents third-party risk from being treated as a narrow compliance activity owned only by procurement or cybersecurity.

Start before the contract is signed

Security requirements are most useful when they influence supplier selection rather than arrive after the commercial decision has already been made.

In my experience, late engagement creates predictable problems. A project selects a supplier, agrees a delivery date and then discovers that the proposed service cannot meet the organisation's access, data, resilience or assurance expectations. Security is then asked to resolve the issue under deadline pressure, often with incomplete information and limited negotiating leverage.

A better process introduces an early triage point during sourcing and tendering. At that stage, the organisation can identify:

• the business outcome and service criticality;
• the data that may be processed or accessed;
• required system integrations and connectivity;
• the expected user and administrator population;
• subcontractors and important dependencies;
• minimum security and resilience standards;
• likely assurance evidence; and
• who will own the decision if residual risk remains.

This does not mean completing a full security risk assessment before a supplier is known. It means asking the right questions early enough to inform the shortlist, contract and implementation plan.

Build a proportionate assurance model

A third-party security assessment should be proportionate to the relationship. A supplier handling public information with no technical connectivity should not automatically receive the same assessment as a provider managing privileged access to an operationally important platform.

Useful risk factors include:

• sensitivity and classification of information;
• impact if the service becomes unavailable;
• access to internal systems or environments;
• privileged, administrative or remote-support capability;
• number of users and locations involved;
• use of subcontractors or fourth parties;
• dependence on a single supplier or region;
• supplier size, maturity and financial resilience;
• regulatory, safety or contractual obligations; and
• the organisation's ability to replace or exit the supplier.

A practical model might use a short screening route, a focused assessment or a deeper third-party security assessment. The route should be explainable and repeatable. It should also allow escalation when evidence is weak, the use case changes or the supplier cannot demonstrate that important controls are operating.

The objective is not to create a "light" process that ignores risk. The objective is to reserve the deepest work for the relationships where it will change the decision.

Separate the supplier from the service

A common weakness in vendor risk management is treating a supplier's corporate reputation as proof that every product, service and implementation is safe.

Supplier-level questions may cover governance, security leadership, incident management, business continuity, vulnerability management, personnel security and the use of subcontractors. Service-level questions should examine the actual solution: its architecture, data flows, identity model, integrations, logging, recovery arrangements and support access.

Both views are needed. A mature supplier can deliver a poorly configured service. A smaller supplier may have a limited corporate programme but offer a tightly constrained service with strong compensating controls. The decision should reflect the real exposure rather than a simplistic label such as "approved vendor".

This distinction is particularly important when a third party is granted access to internal platforms. In my work on connected-organisation processes, the organisation-level decision, the system-level assurance and the individual user's entitlement each needed to be understood separately. Combining them into one vague approval made the process harder to scale and harder to audit.

Turn evidence into a decision

Evidence only creates value when it supports a decision. Collecting documents into a repository is not the same as performing assurance.

Useful evidence may include:

• current ISO 27001, SOC 2 or Cyber Essentials evidence, where relevant;
• independent penetration-test or vulnerability-management reports;
• security policies and control descriptions;
• architecture, data-flow and access documentation;
• incident response and business continuity evidence;
• details of subcontractors and hosting locations;
• audit findings and remediation plans;
• data-protection and retention information; and
• references, performance information or previous assurance outcomes.

The evidence should be tested for scope, currency and relevance. A certificate may exclude the service being purchased. A penetration test may not cover the APIs or supporting systems that matter most. A policy may describe an intended process without proving that it operates effectively.

A decision-ready outcome should state:

• what was assessed;
• the inherent risk and key scenarios;
• evidence that supports the conclusion;
• gaps, assumptions and dependencies;
• required controls or contractual conditions;
• the residual risk; and
• the person authorised to approve or accept it.

This is how a questionnaire becomes useful assurance rather than paperwork.

Make remediation part of the relationship

A supplier should not be treated as either "passed" or "failed" when the real position is more nuanced. Some weaknesses can be corrected through a time-bound security improvement schedule (SIS), additional contractual requirements, restricted access or stronger monitoring.

A remediation plan should identify:

• the specific finding and associated risk;
• the control or outcome required;
• the supplier owner and internal owner;
• the target completion date;
• evidence needed to confirm closure; and
• the consequence if the commitment is missed.

This approach is especially useful for suppliers that are strategically important or difficult to replace. It allows the organisation to improve the supplier's posture while keeping the decision visible and accountable.

It is not a reason to accept unlimited weakness. If the supplier cannot meet a requirement that is fundamental to the relationship, the outcome may need to be restricted use, rejection or a formal risk acceptance by the appropriate authority.

Is a supplier certificate enough?

No. ISO 27001, SOC 2, Cyber Essentials and similar evidence can provide useful confidence, but the scope, date, exclusions and relevance to the proposed service must be checked. Certification is evidence for a decision, not the decision itself.

Design onboarding as a control

Supplier onboarding is often treated as administration after the risk decision. In reality, it is one of the points where assurance becomes operational.

A controlled onboarding process should confirm that the approved supplier, contract, service, system, access scope and sponsor all match. It should prevent a supplier from receiving broader access than was assessed and should create a record that can be reviewed later.

I have worked on processes where suppliers needed access to collaboration platforms and contract workspaces before they could deliver their commitments. The practical challenge was to avoid two bad outcomes: allowing access without sufficient evidence, or creating a manual security queue that stopped the programme. The better answer was a clear front door, early scope confirmation, proportionate assurance, named ownership and an auditable decision.

For high-volume populations, the process should also distinguish between:

• suppliers already assessed and eligible for a standard route;
• suppliers requiring a focused review;
• suppliers needing a deeper assessment or remediation plan; and
• urgent exceptions requiring time-bound approval.

A temporary exception should have a restricted scope, named users where appropriate, an expiry date, an accountable approver and a plan to move into the standard model. Without those controls, an exception quietly becomes the new process.

Extend visibility beyond tier one

Many organisations understand their direct suppliers better than the wider supply chain. That creates blind spots when a tier-one supplier relies on subcontractors, outsourced support, cloud infrastructure or specialist components.

Third-party risk management should define when deeper visibility is required. Useful triggers include:

• access to sensitive or safety-relevant information;
• reliance on a critical subcontractor;
• material concentration or single points of failure;
• foreign ownership or jurisdiction concerns;
• use of fourth parties for privileged support;
• a significant change in service delivery; and
• evidence of an incident or control failure.

It is not realistic to perform the same level of assessment across every tier. A risk-based approach can require the tier-one supplier to maintain visibility, flow down security requirements and notify the organisation of material changes, while reserving direct review for the relationships that could materially affect the organisation.

Manage third-party risk throughout the lifecycle

Third-party risk is not complete when a contract is signed or an onboarding ticket is closed. The risk changes as the supplier, service and threat environment change.

Review triggers should include:

• scheduled reassessment based on criticality;
• material changes to the service or architecture;
• new integrations, APIs or artificial intelligence features;
• changes in ownership, hosting or key subcontractors;
• serious incidents or relevant threat intelligence;
• expired certifications or overdue remediation;
• contract renewal or scope expansion; and
• planned termination or supplier failure.

A good lifecycle process records the original decision and then updates it as evidence changes. This prevents the organisation from repeatedly starting from zero while also avoiding the assumption that an old assessment remains valid forever.

When should a supplier be reassessed?

Reassessment should follow a risk-based schedule and material-change triggers. A critical supplier may need periodic review, while a lower-risk supplier may be reviewed at renewal or when its service changes. Incidents, major control failures, new access, new data or relevant threat intelligence should trigger an earlier review.

Build the operating model around ownership and data

Third-party risk programmes often struggle because the information is spread across procurement systems, contract repositories, assessment tools, access platforms, email and individual spreadsheets. No single team can make a reliable decision if the supplier, contract, assurance outcome and access record cannot be joined together.

The operating model should define ownership for:

• the commercial relationship and contract;
• supplier due diligence and security assessment;
• the service and technical architecture;
• risk acceptance and exceptions;
• onboarding and access fulfilment;
• ongoing monitoring and reassessment; and
• exit, decommissioning and evidence retention.

A central record should make it possible to answer basic questions quickly:

• Which suppliers are active?
• What services and systems do they support?
• What information can they access?
• Which assessments and certifications are current?
• What remediation is overdue?
• Who owns the relationship and residual risk?
• Which exceptions are still open?

The long-term goal may be workflow automation and external risk intelligence, but automation should follow data quality. I have found that a manually proven process is often the best starting point: it exposes unclear ownership, duplicate checks and missing fields before those problems are embedded in technology.

What I have learned from doing this work

The most useful lessons from my practical work are straightforward.

Start early. Supplier security requirements introduced during tendering influence choices. The same requirements introduced after selection create friction and reduce leverage.

Assess the relationship, not just the brand. A well-known vendor can still create material risk in a particular implementation, and a smaller supplier may be manageable when scope is tightly controlled.

Use evidence proportionately. Good assurance is not measured by the number of questions asked. It is measured by whether the evidence changes the decision.

Do not confuse a contract with assurance. A live contract establishes a business relationship; it does not prove that the supplier is suitable for the proposed access, data or service.

Design for scale. If hundreds or thousands of suppliers are in scope, a full manual assessment for everyone will become a bottleneck. Triage, reusable evidence and clear escalation routes are essential.

Keep exceptions visible. A risk-based exception can be reasonable. An undocumented exception with no owner or expiry is not a control.

Make ownership explicit. Security teams can assess and challenge, but risk acceptance, remediation and ongoing service ownership must sit with named accountable people.

Measure outcomes, not paperwork

A third-party risk programme should demonstrate better decisions and reduced exposure, not just more completed forms.

Useful measures include:

• time to triage a new supplier;
• percentage of suppliers assessed before contract signature or onboarding;
• percentage of assessments with complete evidence;
• overdue remediation by risk level;
• suppliers with expired certifications or reviews;
• number and age of open exceptions;
• percentage of critical suppliers with an exit or continuity plan;
• time taken to revoke access or close a relationship; and
• incidents or control failures linked to third parties.

These measures should be used to improve the process, not to create a false sense of security. A high completion rate is not meaningful if assessments are superficial, ownership is unclear or critical suppliers are missing from the inventory.

Final thoughts

Third-party risk management is not about distrusting every supplier. It is about being deliberate about trust.

Suppliers, vendors and external partners are part of the organisation's operating environment. Their systems, people, subcontractors and decisions can affect confidentiality, integrity, availability, resilience and delivery. That makes supplier assurance a business discipline as much as a cybersecurity discipline.

The strongest approach I have seen combines early engagement, proportionate assessment, evidence-led decisions, contractual leverage, controlled onboarding, visible remediation and ongoing review. It gives delivery teams a practical route forward while ensuring that risk is not hidden in a mailbox, spreadsheet or unowned exception.

For recruiters and employers, third-party risk management is also a useful indicator of professional maturity. The strongest practitioners do more than send questionnaires. They connect supplier risk to business outcomes, communicate clearly with procurement and delivery teams, understand when evidence is sufficient, and create controls that can work at scale.

That is the difference between completing a supplier review and managing third-party risk. Effective Cyber Assurance treats third-party risk as one part of a wider evidence-led assurance model rather than a standalone exercise.

Frequently asked questions