Resources · 07

Third-party digital risk: assess a critical supplier

Connect evidence, dependencies, subcontractors, continuity and reversibility before entrusting a sensitive service or dataset.

Updated 5 November 2026 · 6 min

Illustration · fictional scene

What this guide helps achieve

Separate useful suppliers from genuinely critical third parties
Verify beyond self-assessment
See dependency chains
Prepare a workable exit

Quick check

Which service stops if this supplier fails?
Which data can it read, transform or export?
Which subcontractors are essential?
Has restoration been demonstrated?
Can data be recovered in a usable format?

Step-by-step method

01
Classify criticality
Connect each supplier to processes, data, users, obligations and recovery deadlines. High spend is not always critical; a small API may be.
Deliverable: service, impact and owner profile.
02
Request proportionate evidence
Target architecture, access, incidents, backups, tests, relevant certifications and exceptions. An attestation does not replace understanding its scope.
Deliverable: evidence file and clarification points.
03
Map the chain
Identify hosting, data processors, SaaS components and geographic dependencies. Look for common concentration across several suppliers.
Deliverable: dependency and concentration map.
04
Test scenarios
Assess outage, compromise, data loss, ownership change and contract termination. Give each scenario a signal, decision and fallback.
Deliverable: failure scenarios and compensating measures.
05
Align contract and operation
Check that notification deadlines, evidence access, subcontracting, return, deletion and exit support can work in practice.
Deliverable: contractual and operational controls.
06
Decide and monitor
State acceptance, remediation or rejection with an owner, deadline and closure evidence. Reassess after major change or incident.
Deliverable: conditional decision and monitoring plan.

Understand · try · decide

SaaS exit: from a copy to a working service

Fictional exercise: a team moves 400 case records and 60 attachments to another provider. Its chosen criteria require complete content, correct permissions and a business journey without calls to the old service.

Testing uses fictional data and accounts in an authorized environment. Retrieving a file does not establish that object relationships, permissions or automation have been restored.

Four distinct kinds of evidence

Item	Exercise observation	Check to retain
Reconciled records	400 / 400	Compare identifiers, relationships and relevant fields; the count alone is insufficient.
Readable attachments	58 / 60	Recover the two missing files and check their links to records.
Access permissions	One customer can read another customer's case	Replay an allowed access and an expected denial using test identities.
Business journey	One step still uses the old API	Complete the task on the target without that dependency on the old service.

Vary the scenario

What would change the decision?

Each variation starts from the initial case. These are exercise criteria, not a universal supplier quality score.

Define scope
List expected objects, relationships, roles and the task to complete.
Rebuild on the target
Record losses, transformations and remaining dependencies.
Observe the outcome
Retain version, date, owner and evidence of passed or failed tests.

Fictional variations: no real migration is performed here.

All 60 attachments are readable: enough?

New evidence: The two missing files are recovered.
Effect on the decision: No: cross-customer access and the old API still need fixing.

The count matches, but identifiers changed?

New evidence: All 400 rows exist, but their relationships no longer resolve.
Effect on the decision: Require an identifier mapping and test links; a count does not prove fidelity.

Everything opens, but the old connector remains?

New evidence: Content and permissions are repaired, but the journey relies on the old provider.
Effect on the decision: Test the replacement connector before declaring the dependency removed.

Every scoped check passes?

New evidence: Content, relationships, permissions and the journey are verified without the old service.
Effect on the decision: Accept the tested scope with its evidence. This does not establish deletion of copies at the old provider.

Worked example

Illustrative situation

A service depends on an email provider to confirm orders. The team records access, transferred data, received alerts and the acceptable interruption time.

Decision and expected evidence

The plan includes an escalation contact, a restoration check and a testable continuity option instead of relying on a contract clause alone.

Management indicators

Indicator	What it measures	First action
Coverage	Critical suppliers with an owner and current file	Address services with no fallback
Valid evidence	Important controls supported by recent proof	Request items that can change the decision
Concentration	Services dependent on the same actor or region	Prepare a realistic alternative
Reversibility	Measured time and quality for recovering service and data	Test an export before it is urgently needed

Common pitfalls

Sending every supplier the same questionnaire
Treating certification as absence of risk
Ignoring supplier subcontractors
Negotiating exit without testing it

Frequently asked questions

Must every supplier be audited?

No. Start with those whose failure affects an essential service, sensitive data, an obligation or an existing concentration.

Is certification enough?

No. It can be useful evidence, but its scope, date, exclusions and relationship to your use must be checked.

How often should a supplier be reviewed?

According to criticality and pace of change, and after an incident, acquisition, major service change or material subcontracting change.

VEX and product applicability

Request an applicability assertion matching the delivered product

A supplier may provide an SBOM and VEX document whose scope does not match your build. Connect those records to the vulnerability, delivered version and explicit status conditions.

Check issuer, product identifiers, version, time and inherited information in the complete document.
Request not_affected justifications or affected actions; preserve under_investigation as uncertainty.
Review the assertion when the build, dependencies or execution assumptions change.

Read VEX statuses and applicability conditions →

Sources checked on 2026-10-22 · OpenVEX · Specification v0.2.0

Build signatures and provenance

Request interpretable provenance evidence

Supplier evidence becomes useful when its content and scope match a delivered product. Trust needs an authorised identity and platform, with explicit expectations for production.

Identify artefact, digest, attestation format and provenance distribution method.
Distinguish a declared SLSA Build level from actual assessment of requirements and platform trust.
Record unresolved fields and dependencies; an empty list does not establish their absence.

Read the pre-deployment provenance reference →

Sources checked on 2026-10-22 · SLSA 1.2 · Build: Verifying artifacts · SLSA 1.2 · Build: Provenance · SLSA 1.2 · Build: Track Basics · in-toto · Statement v1 · Sigstore · Verifying Signatures

Explore the CISA KEV catalogue

Ask the supplier for evidence

A supplier may distribute affected components under another commercial name. Ask for the version, declared applicability and completed action, tied to a CVE and date. General security assurances do not answer those questions.

Bind commitments to a product and version.
Retain deployment evidence or the inapplicability rationale.
Reassess when an entry or component changes.

Explore the catalogue and method →

CISA KEV · 2026.11.04 · Documentary review : 2026-11-05

Explore NIST CSF 2.0 outcomes

Examine a supplier relationship beyond an attestation

GV.SC groups cybersecurity supply chain risk management outcomes. Examine the purchased service and its dependencies, not only the organisation presenting a document.

GV.SC-04: know and prioritise suppliers by criticality.
GV.SC-05: incorporate relevant requirements into contracts and other agreements.
GV.SC-08: include relevant third parties in preparation, response and recovery.
GV.SC-10: plan termination activities and responsibilities.

Explore outcomes and evidence to examine →

NIST CSWP 29 · CSF 2.0 · 2024-02-26 · 2026-10-22

RDAP: registration, roles and redacted data

A supplier’s domain is evidence to corroborate

An RDAP review supplements documentary due diligence: it helps examine registration and events but proves neither a supplier’s legal identity nor effective control at decision time.

Match the domain to the supplier file and independent sources.
Distinguish registrar, declared registrant and technical suppliers.
Read dates with their exact labels and document unconfirmed points.

Open the RDAP dossier and local reader →

IETF · RFC 9083 · RDAP JSON Responses · June 2021 · §§4–5, 9–10

Extensions: permissions and access

An extension is also an endpoint dependency

An extension may access a business session while depending on a publisher and native component. Add the tested version’s manifest and applied settings to the supplier review.

Link identifier, version and distribution source to the assessed supplier.
Compare required permissions, granted options and observed sites; retain evidence for each state.
Treat publisher, permission and native-component changes as reassessment triggers.

Read the permission directory and manifest examples →

Microsoft Learn · Manage Microsoft Edge extensions using group policies · Enterprise policy documentation consulted 2026-10-23

Media: sanitization and evidence

Compare the supplier’s deletion promise with evidence

A data-deleted clause may cover an application operation, copies or media retirement. Request explicit scope and reconciliation between items delivered to a provider and those actually processed.

Identify method, technique, tool and medium behind each attestation.
Request verification results and the validation decision separately.
For cloud storage, examine encrypted boundaries, key management and copies under contractual responsibilities.

Read the methods, evidence points and annotated situations →

NIST · SP 800-88 Rev. 2 · Guidelines for Media Sanitization · Final · 2025-09-26 · consulted 2026-10-23

CSP: directives, fallback and journeys

Describe third-party resources before relaxing CSP

Adding a script may also load images, open connections or embed a frame. Inventory requirements per journey and inspect every received policy rather than merge all origins into a global permission.

Distinguish loading an iframe from permission to embed your own page.
Read effective fallback for scripts, workers and connections.
Test the documented third-party need without adding a wildcard to hide an error.

Read CSP fallback orders and explore eight scenarios →

W3C · Content Security Policy Level 3 · Mike West, Antonio Sartori · Working Draft · 2026-09-16 · work in progress · §2.2.1, §3, §6.8.3–6.8.4, §8.1

Official references

References consulted: 23/10/2026. The method and worksheet propose checks to adapt to your context; they do not constitute certification.