Supplier and Third-Party Risk

Purpose

Manage dependency without treating every supplier alike

Care organisations rely on cloud platforms, managed service providers, payroll systems, specialist applications, connectivity, backup providers and remotely supported equipment. A supplier may operate the service, but the organisation still needs to understand the resulting access, data, continuity and cyber risk.

RACF-CC treats this as a cross-cutting governance issue. The objective is not to send an exhaustive questionnaire to every organisation in the purchasing ledger. It is to focus limited assurance effort where supplier failure or compromise could materially affect care, information, operations or recovery.

What good looks like

Critical suppliers and shared dependencies are known, internal owners understand what the organisation relies upon, security and incident responsibilities are clear, useful evidence is reviewed and exit arrangements are considered before they are needed.

This is not Domain 9

Supplier risk crosses identity, network, vulnerability, data, response and continuity controls. Its primary framework home is Domain 8: Governance, Risk and Framework Alignment, which connects those distributed controls to ownership and residual-risk decisions.

Resource-aware triage

Start with consequence, access and recoverability

Use a simple initial triage to decide how much scrutiny the relationship warrants. Local risk appetite, care impact and legal duties should shape the final treatment.

Stronger assurance

High-consequence dependency

Privileged or remote access, sensitive data, an essential service, difficult recovery or no realistic short-term alternative.

Use deeper due diligence, explicit requirements, current evidence, incident coordination and tested exit or recovery arrangements.

Proportionate assurance

Material but recoverable

Limited access or data, meaningful operational effect and a workable alternative or restoration route.

Confirm responsibilities, relevant safeguards, notification arrangements and periodic evidence.

Lightweight record

Low-impact commodity

No system or sensitive-data access, low service consequence and an easy replacement route.

Record the relationship and owner; reassess if its access, use or importance changes.

Critical supplier + privileged access + sensitive data + difficult recovery→

Stronger assurance and closer review

Practical method

Answer six questions about the relationship

01
What do we depend on them for?
Identify the service, system, data or operational process and its importance to care delivery.
Record:Service purpose, criticality, internal owner and important downstream dependencies.
02
What can they access?
Identify sensitive data, administrative privilege, remote connectivity, service accounts, integrations and physical or technical access.
Record:Access route, scope, identity, approval and how access can be removed.
03
What happens if they are compromised or unavailable?
Consider confidentiality, service interruption, safeguarding, regulatory consequences and recovery dependencies.
Record:Credible scenarios, operational consequence and tolerable interruption.
04
What have we required or verified?
Review contractual responsibilities, breach notification, access controls, published assurance, backup arrangements and relevant testing.
Record:Requirements, available evidence, evidence date and important uncertainty.
05
How do we recover or leave?
Consider data export and deletion, restoration, alternative suppliers, account removal, credential revocation and transition dependencies.
Record:Exit route, practical blockers, responsible parties and test evidence where proportionate.
06
Who owns the residual dependency?
Assign an internal relationship owner, review date and escalation route where exposure exceeds appetite.
Record:Decision owner, remaining risk, treatment, approval and next review trigger.

Lightweight governance

Maintain a useful supplier-risk register

The register should be small enough to maintain and detailed enough to support prioritisation, incident decisions and contract review. Begin with the suppliers supporting important services rather than waiting for a complete procurement inventory.

Field	What you are trying to establish
Supplier or service	What are we buying or depending upon?
Internal owner	Who is accountable for the relationship and service consequence?
Service criticality	What happens if the service becomes unavailable?
Data involved	What information does the supplier process, store or transmit?
Access	Does it have privileged, remote, API, service-account or physical access?
Key dependencies	Which internal services rely upon it, and what does the supplier rely upon?
Security requirements	What has been contractually, organisationally or technically required?
Assurance evidence	Which relevant, current evidence gives confidence—and what remains unverified?
Incident notification	How and how quickly will the organisation be informed?
Backup and recovery	Who protects which information, and who restores the service?
Exit arrangements	Can the organisation retrieve its data and operate elsewhere?
Offboarding	How will accounts, tokens, integrations and remote access be removed?
Concentration risk	Do several important services depend on the same provider or platform?
Residual risk	What remains outside direct organisational control?
Review date	When must the relationship be reassessed, and what triggers an earlier review?

Hidden dependency

Look across suppliers for concentration risk

Separate supplier records can hide a single point of failure. Several applications may depend on the same identity provider, cloud platform, managed service provider, network carrier or backup operator.

01

Map shared foundations

Connect important services to their common platforms, support providers and connectivity.

02

Test the consequence

Ask which services would fail together and whether administration, communication or recovery would also be affected.

03

Choose a treatment

Reduce dependence where feasible, strengthen continuity or explicitly govern the remaining concentration.

Five services can still be one dependency

Counting suppliers or products is not enough. Record the shared infrastructure, ownership, subcontractors and recovery routes that can create common-mode failure.

Relationship lifecycle

Carry assurance from selection through exit

Before commitment

Scope and require

Identify consequence and access
Assign an internal owner
Set proportionate requirements
Review exit feasibility

During service

Evidence and review

Keep contacts and access current
Review relevant assurance
Monitor service and control issues
Reassess material change

During an incident

Coordinate and decide

Use agreed notification routes
Confirm containment authority
Protect evidence and continuity
Track supplier actions

At exit

Recover control

Retrieve and validate data
Remove accounts and integrations
Confirm deletion obligations
Retain required evidence

Evidence and decisions

Seek enough confidence for the consequence

CoverageImportant suppliers and critical-service dependencies have an internal owner and current record.

Access clarityPrivileged, remote, integration and sensitive-data access is understood and reviewable.

Requirement traceabilityMaterial security and notification expectations are recorded in agreements or operating arrangements.

Evidence currencyHigher-consequence relationships have relevant evidence reviewed at a risk-defined interval.

Recovery confidenceRestoration, data retrieval, alternative operation and exit assumptions are understood and tested where proportionate.

Residual-risk ownershipUnresolved dependencies and evidence gaps have an authorised decision owner and review trigger.

A contract can allocate responsibility without removing consequence. The supplier may own an action, but the organisation still needs to understand and govern the effect if that action fails.

Across RACF-CC

Connect supplier assurance to operating controls

Identity and AccessSupplier accounts, privilege, authentication and offboarding → Network SegmentationRemote pathways, permitted flows and containment → Vulnerability ManagementSupplier fixes, unsupported systems and remediation evidence → Data and BackupShared responsibility, restoration and data retrieval → Incident ResponseNotification, escalation, evidence and coordinated recovery → Governance and RiskOwnership, assurance, exceptions and residual risk →

References

Standards alignment

NIST SP 1305: CSF 2.0 Quick-Start Guide for Cybersecurity Supply Chain Risk Management — using GV.SC to establish supplier-risk capability and communicate requirements.
NIST SP 1326: Cybersecurity Supply Chain Risk Management Due Diligence Assessment — additional due-diligence considerations for higher-risk ICT suppliers and products.
NCSC Supply Chain Security — understanding suppliers, shared responsibilities, proportionate requirements, incident arrangements and over-reliance.

Use source guidance directly where required

RACF-CC provides a proportionate implementation route. Contractual, regulatory, procurement or formal assurance requirements should be addressed using the applicable source standard, legal advice and organisational process.

Start small

Begin with the suppliers behind essential services

Identify one important service, name its internal owner and answer the six questions. The first useful outcome is not a perfect supplier inventory; it is a defensible understanding of a material dependency and its next decision.

Continue to Domain 8 Use the RACF-CC Method Framework overview