Third-Party Risk Assessment Example: A Complete 2026 Walkthrough

A third-party risk assessment example shows what a finished vendor assessment looks like, which most frameworks describe only in principle. ISO/IEC 27001, NIST CSF 2.0 and DORA all say vendors must be assessed before you rely on them, but none gives you a completed one. This guide walks through a full third-party risk assessment example for a fictional payments firm about to put its customer wallets on a cloud platform, from tiering to the decision.

It follows the order our guide to the third-party risk assessment sets out: inherent risk first, then due diligence, then the risks that remain and the controls that manage them. The references are to ISO/IEC 27001:2022 controls A.5.19 to A.5.23, the NIST CSF 2.0 supply chain category GV.SC, and DORA Articles 28 to 30.

The Organization in This Third-Party Risk Assessment Example

Meridian Payments (a fictional company) runs e-wallets and card top-ups for about 240,000 customers. It plans to move wallet balances, transfers and daily settlement onto Cobalt Ledger Systems (also fictional), a multi-tenant cloud platform, on a five-year contract worth about 1.2 million a year. Cobalt hosts with a public cloud provider, keeps its disaster recovery site in Europe and uses an offshore subcontractor for second-line support.

Step 1: Tiering

In any third-party risk assessment example, tiering comes first, because it decides how deep the rest of the assessment goes. Meridian’s answers:

Question	Answer
Red flags from sanctions, adverse media or ownership checks?	No
Supports a critical or important function, or material outsourcing?	Yes
Holds or sees personal or confidential data?	Yes
Connects to our systems or holds privileged access?	Yes
Hard to replace quickly?	Yes (9 to 12 months to migrate)
Relies on subcontractors for key parts?	Yes
Data held or accessed outside the region?	Yes (recovery site)
Significant contract value or length?	Yes

The second answer alone makes Cobalt a Critical vendor. Under DORA, a service supporting a critical or important function brings extra contract requirements (Article 30(3)) and a documented exit strategy (Article 28(8)); under the CBB and SAMA rules, material outsourcing needs the regulator’s prior approval or no-objection.

Step 2: The Vendor Profile

Element	What Meridian recorded
Service	Cloud platform for wallets, top-ups and settlement, with 24/7 support
Function supported	All wallet balances and settlement; if it stops, customers cannot pay
Data and access	Customer identity and transaction history; vendor support has remote admin access
Locations and fourth parties	Regional cloud hosting, recovery site in Europe, offshore support subcontractor
Assurance	ISO 27001 certificate covering the platform; SOC 2 Type II with two closed exceptions
Exit route	Two alternative platforms; 9 to 12 months to move; no in-house fallback

Step 3: Due Diligence

Check	Answer	Note
Independent assurance current and in scope	Yes	Certificate scope checked against the service
Questionnaire checked against evidence	Partly	Only a summary of the penetration test shared
Vendor access least-privilege, MFA, logged	Partly	Support uses one shared admin account
Incident notification within an agreed time	Partly	Standard terms say “without undue delay”
Continuity plans tested and meet our needs	Partly	8-hour recovery time against our 4-hour tolerance
Subcontractors disclosed and bound	Partly	Support subcontractor not in the contract
Right to audit	Partly	Pooled audits and SOC 2 reports; no individual on-site audit
Exit plan	Partly	Exit clause, but no written or tested plan
Data processing agreement; regulator approval	Yes	Both in place

Seven “partly” answers is normal for a first pass on a critical vendor. Each one became either a contract condition or a risk in the register.

Step 4: Risks and Controls in This Third-Party Risk Assessment Example

Risks are rated for Meridian and its customers on 1 to 5 scales, with Medium (9 and below) as the appetite line:

Risk	Before	Controls	After
Long outage of the platform	15 High	4-hour recovery time with service credits; join the recovery test (A.5.30; DORA Art 30(3))	8 Medium
Lock-in: no orderly way out	15 High	Written and tested exit plan; standard export format (DORA Art 28(8); GV.SC-10)	8 Medium
Attack through vendor support access	12 High	Named, time-bound accounts with session recording (A.5.15, A.8.5, A.8.15)	4 Low
Slow incident notification	12 High	Notice within four hours and investigation support (A.5.20; GV.SC-08)	6 Medium
Breach at the vendor	10 High	Full penetration test report reviewed; SOC 2 exceptions tracked (A.5.22)	5 Medium

Four more risks sat within appetite: limited audit rights, concentration on the same cloud host that runs Meridian’s CRM, data in the European recovery site, and undisclosed subcontracting. They stay in the register and are watched at reassessment.

Step 5: Review and Decision

The outsourcing committee advised approval on conditions: four-hour incident notice, the support subcontractor named in the contract, on-site audit rights, and a tested exit plan within six months. Cobalt accepted everything except individual on-site audits, offering pooled audits instead, and the committee accepted that with the regulator’s inspection right preserved.

The decision of this third-party risk assessment example: approve on conditions, signed by the Chief Executive, with the next reassessment in twelve months as the policy sets for a Critical vendor.

Common Mistakes This Third-Party Risk Assessment Example Avoids

• A questionnaire instead of an assessment. Answers were checked against the SOC 2 report and the certificate scope.
• Ignoring fourth parties. The offshore support centre was found only by asking who does second-line support.
• Approving High risk silently. Every High risk has a control and a target within appetite, and the residual risk was accepted by name.
• Leaving exit for later. Lock-in scored as high as an outage.
• Assessing once. A reassessment date is set by tier, with triggers for incidents and changes.

Frequently Asked Questions

Can I use this third-party risk assessment example as a template?

Use its structure. The tier, the checks and the risks will differ for every vendor and service.

Does every vendor need this depth?

No. A low-tier vendor with no data or access needs a light review. The tiering in step 1 is what keeps the effort proportionate.

How does this fit a DORA register of information?

The assessment supports the entries for the arrangement; the register of information records every ICT arrangement in the format supervisors ask for.

What if the vendor refuses a condition?

Record it, as Meridian did with on-site audits, and decide whether a compensating control is enough or the risk must be accepted by someone with the authority to do so.

To run your own in the same order, use our free third-party risk assessment template. For the questionnaire, contract clauses, exit plan template and registers behind it, see the TPRM Toolkit, and for what to collect, the vendor due diligence checklist.