09 Third-Party Risk Assessments

A Third-Party Risk Assessment brings together the major components of vendor risk management.

Earlier activities may have identified:

Vendor Information

Business Criticality

Data Access

System Access

Questionnaire Responses

SOC Reports

ISO Certifications

Contract Requirements

Security Findings

Privacy Risks

Operational Dependencies

The Third-Party Risk Assessment converts this information into a defensible answer to one important question:

Should the organization accept the risk of using this third party?

A mature assessment follows:

Vendor Request
      ↓
Business Context
      ↓
Inherent Risk
      ↓
Risk Tier
      ↓
Assessment Scope
      ↓
Questionnaire
      ↓
Evidence Review
      ↓
Control Assessment
      ↓
Findings
      ↓
Control Effectiveness
      ↓
Residual Risk
      ↓
Risk Treatment
      ↓
Approval
      ↓
Continuous Monitoring

Learning Objectives

By the end of this lesson, you will be able to:

Explain Third-Party Risk Assessments.
Define assessment scope.
Identify vendor business context.
Calculate inherent vendor risk.
Assign vendor risk tiers.
Determine assessment depth.
Review vendor questionnaires.
Validate supporting evidence.
Assess cybersecurity controls.
Assess privacy risks.
Assess compliance posture.
Assess operational resilience.
Assess cloud and SaaS providers.
Assess AI vendors.
Evaluate fourth-party dependencies.
Identify vendor-control gaps.
Assess control effectiveness.
Calculate residual risk.
Develop risk-treatment plans.
Document compensating controls.
Manage vendor exceptions.
Prepare vendor-risk recommendations.
Obtain formal risk acceptance.
Define monitoring requirements.
Produce a Third-Party Risk Assessment Report.

1. What Is a Third-Party Risk Assessment?

A Third-Party Risk Assessment is a structured process for evaluating risks created when an organization relies on an external entity.

Third parties may include:

SaaS Providers

Cloud Providers

Managed Service Providers

Software Vendors

Consultants

Payment Processors

Data Processors

Outsourcing Providers

AI Providers

Business Partners

2. What Are We Assessing?

The assessment asks:

What Does the Vendor Do?

What Can the Vendor Access?

What Data Does It Process?

How Critical Is the Service?

What Could Go Wrong?

What Controls Exist?

How Effective Are They?

What Risk Remains?

3. Assessment vs Questionnaire

A common mistake is treating:

Completed Questionnaire

as:

Completed Risk Assessment

They are different.

The questionnaire provides:

Vendor Responses

The assessment evaluates:

Responses
+
Evidence
+
Business Context
+
Risk
+
Control Effectiveness

Therefore:

Questionnaire
≠
Risk Assessment

4. Assessment Inputs

A comprehensive assessment may use:

Vendor Intake

Inherent Risk Assessment

Questionnaire

SOC Report

ISO Certificate

Pen-Test Report

Policies

Architecture

Privacy Documentation

BCP / DR Evidence

Contract

External Risk Signals

Previous Assessments

5. Build the Assessment Template

Create:

01 Third-Party Risk Assessment Template

Recommended sections:

01 Executive Summary

02 Vendor Profile

03 Business Context

04 Inherent Risk

05 Assessment Scope

06 Security Assessment

07 Privacy Assessment

08 Compliance Assessment

09 Resilience Assessment

10 Fourth-Party Assessment

11 Findings

12 Control Effectiveness

13 Residual Risk

14 Risk Treatment

15 Recommendation

16 Approval

17 Monitoring Requirements

6. Start With Business Context

Before evaluating controls, understand:

Why is the organization using this vendor?

Document:

Business Service

Business Owner

Users

Criticality

Dependencies

Data

Access

Geography

7. Vendor Profile

Create:

02 Vendor Profile

Capture:

Field	Example
Vendor	CloudCRM
Service	CRM SaaS
Business Owner	Sales
Hosting	Cloud
Data	Customer PI
Users	2,500
Criticality	High
Risk Tier	Tier 1

8. Understand the Service

Ask:

What Is Being Purchased?

How Is It Delivered?

Where Is It Hosted?

Who Operates It?

Who Uses It?

What Does It Integrate With?

9. Understand Data Exposure

Identify:

Public Data

Internal Data

Confidential Data

Personal Data

Sensitive Personal Data

Financial Data

Authentication Data

Payment Data

Intellectual Property

10. Data Flow

Document:

Organization
      ↓
Vendor
      ↓
Cloud Provider
      ↓
Subprocessor

Ask:

Where does our data actually go?

11. System Access

Determine whether the vendor has:

No Access

Application Access

API Access

Network Access

Production Access

Privileged Access

Cloud Access

12. Privileged Vendor Access

If the vendor has:

Administrative
Production Access

risk may increase substantially.

Assess:

MFA

PAM

Named Accounts

Session Logging

JIT Access

Access Reviews

13. Business Criticality

Ask:

What Happens
If the Vendor
Stops Working?

Impact may include:

Revenue Loss

Operational Disruption

Customer Impact

Security Impact

Regulatory Impact

Reputational Damage

14. Determine Inherent Risk

Inherent risk means:

Risk before considering the vendor’s controls.

Conceptually:

Vendor Activity
      ↓
Potential Exposure
      ↓
Inherent Risk

15. Inherent Risk Factors

Common factors include:

Data Sensitivity

System Access

Privileged Access

Business Criticality

Transaction Volume

Customer Impact

Regulatory Exposure

Geographic Exposure

Service Dependency

Subprocessors

16. Inherent Risk Scoring Matrix

Create:

03 Inherent Risk Scoring Matrix

Example:

Factor	Low	Medium	High
Data	Public	Internal	Sensitive
Access	None	User	Privileged
Criticality	Low	Medium	Critical
Regulatory	None	Limited	Significant
Dependency	Replaceable	Important	Essential

17. Simple Scoring Model

Example:

Low
= 1

Medium
= 2

High
= 3

If vendor scores:

Data              3
Access            3
Criticality       3
Regulatory        2
Dependency        3
                  ──
Total            14

the vendor may be classified:

High Inherent Risk

18. Risk Tier

Translate inherent risk into:

Vendor Risk Tier

Example:

Score	Tier
5–7	Tier 4 — Low
8–10	Tier 3 — Medium
11–13	Tier 2 — High
14–15	Tier 1 — Critical

Actual thresholds should follow organizational methodology.

19. Why Tiering Matters

Risk tier determines:

Assessment Depth

Evidence Requirements

Approval Level

Contract Requirements

Monitoring Frequency

Reassessment Frequency

20. Assessment Scope

Create:

04 Assessment Scope

For each vendor determine applicable domains.

Example:

Security
✓

Privacy
✓

Compliance
✓

Resilience
✓

Cloud
✓

AI
✗

21. Risk-Based Assessment

Do not assess every vendor identically.

Example:

Office Supplier

does not need the same assessment as:

Production Cloud Provider

22. Evidence Collection

Create:

05 Assessment Evidence Register

Use:

Evidence	Requested	Received	Validated	Result

23. Common Evidence

Examples:

SOC 2

ISO 27001

Pen-Test Summary

Security Policies

BCP / DR Test

Architecture

Privacy Documentation

Insurance

Certifications

Security Questionnaire

24. Evidence Validation

For each artifact ask:

Is It Current?

Is It Authentic?

Is It Relevant?

Does Scope Match?

Does It Cover
the Service?

25. Evidence Scope

Example:

Vendor provides:

ISO 27001 Certificate

but certificate covers:

Corporate IT

while your service runs in:

Separate SaaS Environment

The evidence may provide limited assurance for the assessed service.

26. Evidence Freshness

Review:

Issue Date

Audit Period

Expiry Date

Current Version

Environment Changes

27. Evidence Hierarchy

Conceptually:

Vendor Statement
      ↓
Policy
      ↓
Process Evidence
      ↓
Configuration Evidence
      ↓
Independent Assurance
      ↓
Technical Validation

The strongest evidence depends on the control being assessed.

28. Security Control Assessment

Create:

06 Vendor Control Assessment

Assess:

Security Governance

Asset Management

IAM

Encryption

Network Security

Vulnerability Management

Secure Development

Logging

Incident Response

Resilience

29. Control Assessment Structure

For each control document:

Requirement

Vendor Control

Evidence

Effectiveness

Finding

Risk

30. Security Governance

Assess whether the vendor maintains:

Security Program

Policies

Security Leadership

Risk Management

Management Oversight

31. Identity and Access Management

Assess:

MFA

SSO

RBAC

Least Privilege

PAM

Access Reviews

Provisioning

Offboarding

32. MFA Assessment

Do not accept:

MFA:
Yes

Determine:

Which Users?

Which Systems?

Administrators?

Production?

Remote Access?

Cloud Console?

33. Privileged Access

Assess:

Separate Admin Accounts

MFA

PAM

Session Logging

Approval

JIT / JEA

34. Encryption

Assess:

Data at Rest

Data in Transit

Backups

Key Management

Key Rotation

Certificates

35. Network Security

Assess:

Segmentation

Firewalls

Remote Access

Administrative Networks

Internet Exposure

IDS / IPS

36. Vulnerability Management

Assess:

Scanning

Prioritization

Patch SLAs

Critical CVEs

Exceptions

Retesting

37. Vulnerability Evidence

Evidence may include:

Scan Summary

Patch Policy

Vulnerability Metrics

Remediation Records

38. Penetration Testing

Review:

Frequency

Scope

Independence

Critical Findings

Remediation

Retesting

39. Pen-Test Finding

Suppose vendor’s latest test identified:

Critical Authentication
Bypass

Status:

Open

This may materially affect vendor approval.

40. Secure Development

For software vendors assess:

Secure SDLC

Threat Modeling

Code Review

SAST

DAST

SCA

Secrets Scanning

Pen Testing

41. Software Supply Chain

Assess:

Dependencies

Open Source

SBOM

Artifact Integrity

Build Security

Package Sources

42. Logging and Monitoring

Assess:

Authentication Logs

Admin Activity

Security Events

SIEM

SOC

Detection

Retention

43. Incident Response

Assess:

IR Plan

Roles

Testing

Customer Notification

Forensics

Lessons Learned

44. Incident History

Ask:

Has the Vendor
Experienced Material
Security Incidents?

If yes:

What Happened?

Was Our Service Affected?

What Changed?

45. Privacy Risk Assessment

Create:

07 Vendor Privacy Assessment

Assess:

Personal Data

Purpose

Legal / Contractual Basis

Retention

Deletion

Location

Subprocessors

Data Subject Rights

Incident Management

46. Data Minimization

Ask:

Does the Vendor
Actually Need
All Requested Data?

Example:

Vendor requests:

Date of Birth

but service only needs:

Email Address

Potential:

Excessive Data Collection

47. Purpose Limitation

Assess whether data is used only for:

Contracted Purpose

or additionally for:

Analytics

Advertising

Training

Product Improvement

Research

48. Retention

Assess:

Retention Period

Business Need

Deletion

Backups

Archives

49. Data Location

Identify:

Countries

Cloud Regions

Support Locations

Subprocessor Locations

50. International Transfers

Where applicable, review:

Transfer Mechanisms

Contractual Requirements

Privacy Requirements

Data Residency

51. Subprocessors

Review:

Who?

Purpose?

Data?

Location?

Security?

Contractual Flow-Down?

52. Privacy Rights

Determine whether vendor can support relevant:

Access

Correction

Export

Restriction

Deletion

requirements.

53. Compliance Assessment

Create:

08 Vendor Compliance Assessment

Determine applicable requirements such as:

SOC 1

SOC 2

ISO 27001

PCI DSS

HIPAA

Privacy Requirements

Industry Regulations

54. SOC Report Review

Assess:

Report Type

Audit Period

Scope

Opinion

Exceptions

CUECs

Subservice Organizations

55. Qualified Opinion

If the auditor issues a:

Qualified Opinion

understand:

Why?

Which Controls?

Which Period?

What Risk?

56. SOC Exceptions

Do not count exceptions only.

Evaluate:

Control

Frequency

Population

Sample

Impact

Management Response

57. CUECs

Identify:

Complementary
User Entity Controls

that your organization must implement.

Vendor control assurance may depend on:

Customer Controls

being effective.

58. ISO Certification

Validate:

Certificate

Scope

Locations

Expiry

Certification Body

59. PCI DSS

For payment-related vendors assess:

PCI Responsibility

Attestation

Scope

Service Provider Status

Shared Responsibility

60. Operational Resilience Assessment

Create:

09 Vendor Resilience Assessment

Assess:

BCP

DR

RTO

RPO

Backups

Redundancy

Failover

Testing

61. RTO

Compare:

Business Required RTO

with:

Vendor Capability

Example:

Business:
4 Hours

Vendor:
24 Hours

Potential:

Resilience Gap

62. RPO

Compare:

Acceptable Data Loss

with:

Vendor Recovery Capability

63. DR Evidence

Review:

Test Date

Scenario

Systems

Recovery Time

Recovery Point

Failures

Remediation

64. Backup Controls

Assess:

Frequency

Encryption

Immutability

Retention

Restore Testing

65. Geographic Resilience

Understand whether:

Primary

Backup

DR

depend on the same:

Region

Provider

Data Center

66. Cloud Vendor Assessment

Cloud vendors require additional consideration of:

Shared Responsibility

IAM

Regions

Encryption

Logging

Isolation

Resilience

Compliance

67. Shared Responsibility

Document:

Customer

Vendor

Shared

responsibility for each major control.

68. SaaS Vendor Assessment

For SaaS assess:

Tenant Isolation

SSO

MFA

Admin Controls

Audit Logs

API Security

Data Export

Retention

Deletion

69. Tenant Isolation

Ask:

What prevents one customer from accessing another customer’s information?

Evidence may include:

Architecture

Authorization Controls

Testing

Pen-Test Evidence

70. API Risk

Assess:

Authentication

Authorization

Tokens

Rate Limiting

Logging

Data Exposure

71. AI Vendor Assessment

Create:

10 AI Vendor Risk Assessment

Assess:

Prompt Data

Files

Outputs

Training

Fine-Tuning

Model Improvement

Retention

Memory

Embeddings

Vector Stores

Model Providers

Subprocessors

72. AI Training

Ask explicitly:

Are Our:

Prompts

Files

Outputs

Metadata

used for:

Training

Fine-Tuning

Evaluation

Model Improvement?

73. AI Model Provider

Determine:

Who Actually
Runs the Model?

Example:

Our Organization
      ↓
AI SaaS Vendor
      ↓
Model Provider
      ↓
Cloud Provider

74. AI Data Flow

Map:

Prompt
      ↓
Application
      ↓
Model
      ↓
Logs
      ↓
Vector Store
      ↓
Monitoring

75. AI Retention

Assess separately:

Prompts

Outputs

Files

Logs

Embeddings

Conversation Memory

76. AI Memory

Determine:

What Is Remembered?

For How Long?

Across Which Users?

Can It Be Deleted?

77. AI Cross-Tenant Risk

Assess:

Tenant Isolation

Retrieval Isolation

Prompt Isolation

Vector Isolation

78. AI Output Risk

Consider:

Sensitive Data Disclosure

Hallucinated Information

Unsafe Output

Cross-Tenant Leakage

Unauthorized Retrieval

79. AI Governance

Assess whether vendor maintains:

AI Risk Management

Model Evaluation

Safety Testing

Security Testing

Change Management

Incident Management

80. Fourth-Party Assessment

Create:

11 Fourth-Party Dependency Assessment

Identify critical dependencies:

Vendor
      ↓
Cloud Provider

Model Provider

Payment Provider

Support Provider

Data Processor

81. Why Fourth Parties Matter

Your vendor may have strong controls but depend on:

Critical Subprocessor

with weak controls.

Risk can propagate:

Fourth Party
      ↓
Vendor
      ↓
Your Organization

82. Concentration Risk

Example:

Vendor A ─┐
Vendor B ─┼── Cloud Provider X
Vendor C ─┘

One cloud-provider outage may affect multiple critical vendors.

83. Geographic Concentration

Multiple services may depend on:

Same Region

creating systemic risk.

84. Technology Concentration

Multiple critical vendors may depend on:

Same Identity Provider

Same CDN

Same Cloud

Same Software Component

85. Findings Identification

Create:

12 Third-Party Findings Register

Use:

Finding	Domain	Risk	Severity	Evidence	Owner

86. Finding Structure

A strong finding contains:

Condition

Criteria

Risk

Evidence

Required Action

87. Example Finding — MFA

Condition:

Vendor Does Not
Require MFA
for Production Admins

Criteria:

Organizational
Privileged Access
Requirement

Risk:

Unauthorized
Administrative Access

88. Example Finding — Encryption

Condition:

Backups Are
Not Encrypted

Risk:

Sensitive Data
Exposure

89. Example Finding — DR

Condition:

Vendor Has Not
Performed DR Test
in 24 Months

Risk:

Recovery Capability
Not Validated

90. Example Finding — Privacy

Condition:

Customer Data
Retained Indefinitely

Risk:

Unnecessary Privacy
and Breach Exposure

91. Example Finding — AI

Condition:

Customer Prompts
May Be Used
for Model Improvement

Risk:

Confidential Data
Secondary Use

92. Severity Assessment

Possible scale:

Critical

High

Medium

Low

Severity should consider:

Likelihood

Impact

Exposure

Exploitability

Data Sensitivity

Business Criticality

93. Do Not Confuse Finding Severity With Vendor Risk

A vendor may have:

One High Finding

but still have:

Medium Overall
Residual Risk

Or one critical issue may make:

Vendor Approval
Unacceptable

94. Control Effectiveness

Create:

13 Control Effectiveness Matrix

Possible ratings:

Effective

Partially Effective

Ineffective

Not Implemented

Not Applicable

95. Effective Control

Example:

MFA

is:

Implemented

Enforced

Monitored

Evidence Supported

Rating:

Effective

96. Partially Effective

Example:

MFA Required
for Employees

but not:

Administrators

Rating:

Partially Effective

97. Ineffective

Policy exists:

Quarterly
Access Reviews

but evidence shows:

Reviews Not Performed

Rating:

Ineffective

98. Control Design vs Operating Effectiveness

Ask:

Is the Control
Designed Correctly?

and:

Does the Control
Actually Operate?

99. Design Effectiveness

Example:

Policy requires:

Quarterly
Access Reviews

This may be appropriately designed.

100. Operating Effectiveness

Evidence shows:

No Reviews
for 12 Months

Therefore:

Design:
Effective

Operation:
Ineffective

101. Residual Risk

Residual risk means:

Risk remaining after considering implemented controls.

Conceptually:

Inherent Risk
      ↓
Controls
      ↓
Control Effectiveness
      ↓
Residual Risk

102. Residual Risk Matrix

Create:

14 Residual Risk Matrix

Example:

Inherent Risk	Control Effectiveness	Residual Risk
Critical	Strong	Medium
Critical	Weak	Critical
High	Strong	Low/Medium
High	Partial	High
Medium	Strong	Low

103. Residual Risk Is Not Simple Subtraction

Avoid:

Risk 10
-
Controls 5
=
Residual 5

unless the organization has a validated quantitative methodology.

Residual risk requires:

Context

Control Effectiveness

Threat

Impact

Professional Judgment

104. Risk Treatment

Create:

15 Vendor Risk Treatment Plan

Possible treatments:

Avoid

Mitigate

Transfer

Accept

105. Avoid

Do Not
Use Vendor

appropriate when risk cannot be reduced to acceptable levels.

106. Mitigate

Require:

Vendor Remediation

Customer Controls

Contract Controls

Scope Reduction

107. Transfer

Examples may include:

Insurance

Contractual Liability

but risk is rarely completely transferred.

108. Accept

Residual risk may be accepted by:

Authorized
Risk Owner

109. Vendor Remediation

Create:

16 Vendor Remediation Plan

Use:

Finding	Action	Owner	Due	Evidence	Status

110. Remediation Priority

Prioritize:

Critical
      ↓
High
      ↓
Medium
      ↓
Low

while considering business context.

111. Compensating Controls

Vendor cannot implement:

Customer-Managed Keys

Possible compensating controls:

Data Minimization

Tokenization

Strong IAM

Additional Monitoring

Reduced Data Scope

112. Compensating Control Requirements

A compensating control should:

Address Same Risk

Be Implemented

Be Evidence Supported

Be Sustainable

113. Risk Exception

If a gap cannot be remediated:

Finding
      ↓
Residual Risk
      ↓
Exception
      ↓
Risk Acceptance

114. Exception Record

Document:

Risk

Reason

Compensating Controls

Owner

Approval

Expiry

115. Time-Bound Exceptions

Avoid:

Accepted Forever

Prefer:

Approved Until
Defined Review Date

116. Assessment Recommendation

Possible recommendations:

APPROVE

APPROVE WITH CONDITIONS

REMEDIATION REQUIRED

ESCALATE

REJECT

117. Approve

Appropriate when:

Residual Risk
Within Tolerance

and no unacceptable findings remain.

118. Approve With Conditions

Example:

Vendor Approved

provided:

MFA Enabled
Within 30 Days

Updated DR Evidence
Within 60 Days

119. Remediation Required

Use when:

Material Risk
Must Be Reduced
Before Approval

120. Escalate

Use when:

Residual Risk
Exceeds Analyst
Approval Authority

121. Reject

Appropriate when:

Risk Unacceptable

Controls Insufficient

Remediation Unavailable

Business Exposure Too High

122. Business Pressure

A common scenario:

Business:
We Need Vendor Today

Security:

Critical Findings
Remain Open

GRC should not simply:

Approve

or:

Block

Instead:

Document Risk
      ↓
Identify Options
      ↓
Define Controls
      ↓
Escalate
      ↓
Authorized Decision

123. Vendor Approval Record

Create:

17 Vendor Approval Record

Capture:

Vendor

Risk Tier

Inherent Risk

Residual Risk

Open Findings

Conditions

Risk Owner

Approval

Date

Expiry / Review Date

124. Formal Risk Acceptance

Risk should be accepted by someone with:

Appropriate
Risk Authority

not simply:

The Analyst
Performing Assessment

125. Risk Acceptance Statement

Document:

Known Risk

Business Justification

Compensating Controls

Residual Risk

Approval

Expiry

126. Monitoring Requirements

Approval should determine:

How Will We
Monitor This Vendor?

Create:

18 Monitoring Requirements Register

Use:

Risk	Monitoring	Frequency	Owner	Trigger

127. Monitoring Based on Findings

Example:

Finding:

Weak Vulnerability
Management

Monitoring:

Quarterly
Vulnerability Metrics

128. Monitoring Based on Criticality

Critical vendors may require:

Continuous Signals

Quarterly Review

Annual Assessment

Annual SOC Review

Annual Pen Test Review

129. Reassessment Triggers

Define:

Security Incident

New Data

New Access

New AI

Acquisition

New Subprocessor

New Country

Critical Vulnerability

Major Outage

130. Final Assessment Report

Create:

19 Final Third-Party Risk Assessment Report

Recommended structure:

Executive Summary

Vendor Overview

Business Context

Inherent Risk

Assessment Scope

Evidence Reviewed

Security Assessment

Privacy Assessment

Compliance Assessment

Resilience Assessment

Fourth-Party Risk

Findings

Control Effectiveness

Residual Risk

Risk Treatment

Recommendation

Approval

Monitoring

131. Executive Summary

Management should quickly understand:

What Vendor?

Why Needed?

Risk Tier?

Major Risks?

Residual Risk?

Recommendation?

132. Example Executive Summary

Vendor:
CloudCRM

Service:
Customer Relationship Management

Risk Tier:
Tier 1 — Critical

Inherent Risk:
High

Key Findings:
2 High
3 Medium

Residual Risk:
Medium

Recommendation:
Approve With Conditions

133. Assessment Evidence Pack

Create:

20 Third-Party Assessment Evidence Pack

Suggested structure:

01 Vendor Intake

02 Inherent Risk

03 Questionnaire

04 SOC / ISO

05 Pen Test

06 Policies

07 Privacy

08 Resilience

09 Findings

10 Remediation

11 Risk Acceptance

12 Approval

13 Monitoring

134. Evidence Traceability

Every conclusion should be traceable:

Risk
      ↓
Control
      ↓
Evidence
      ↓
Assessment
      ↓
Finding
      ↓
Decision

135. Assessment Quality Review

Before final approval, perform:

Peer Review

or:

Quality Assurance

for high-risk assessments.

136. QA Checklist

Verify:

Correct Vendor?

Correct Service?

Correct Risk Tier?

Correct Evidence?

All Findings Included?

Severity Consistent?

Residual Risk Supported?

Approval Correct?

137. Assessment Aging

An assessment should have:

Assessment Date

Validity Period

Next Review Date

138. Stale Assessments

A two-year-old assessment may no longer represent:

Current Vendor Risk

especially if the service has materially changed.

139. Assessment Reuse

Existing assessment evidence may be reused when:

Current

Same Service

Same Scope

No Material Change

140. Do Not Reuse Blindly

Old:

SOC Report

or:

Questionnaire

should not automatically be treated as current evidence.

141. Third-Party Assessment KPIs

Track:

Assessment Completion

Assessment SLA

Evidence Coverage

Finding Closure

Risk Acceptance

Reassessment

142. KPI — Assessment Completion

Assessments
Completed on Time
──────────────── × 100
Assessments Due

143. KPI — Critical Vendor Coverage

Critical Vendors
with Current Assessment
──────────────────── × 100
Critical Vendors

144. KPI — Evidence Coverage

Required Evidence
Validated
─────────────── × 100
Required Evidence

145. KPI — Finding Closure

Vendor Findings
Closed on Time
────────────── × 100
Findings Due

146. KPI — Reassessment Completion

Vendor Reassessments
Completed on Time
────────────────── × 100
Reassessments Due

147. Third-Party Risk KRIs

Examples:

Critical Vendors
Without Current Assessment

Open Critical Findings

Unapproved High
Residual Risk

Expired Risk Acceptance

Missing Assurance

Overdue Remediation

148. KRI — High Residual Risk

Vendors Operating
with High or Critical
Residual Risk

149. KRI — Unassessed Critical Vendors

Critical Vendors
in Production
Without Completed
Risk Assessment

150. KRI — Expired Risk Acceptance

Vendor Exceptions
Operating Beyond
Approved Expiry

151. Third-Party Risk Dashboard

Create:

21 Third-Party Risk Assessment Dashboard

Example:

Metric	Target
Critical vendors with current assessment	100%
Assessments completed before onboarding	100%
Required evidence coverage	100%
Open critical findings	0
Unapproved high residual risk	0
Expired risk acceptances	0
Reassessments completed on time	100%
Critical remediation overdue	0

152. Portfolio-Level Risk

Do not view vendors individually only.

Ask:

How Many Vendors
Have High Risk?

Where Are
Common Findings?

Which Controls
Fail Most Often?

Where Is
Concentration Risk?

153. Common Vendor Findings

Trend categories may include:

MFA

Vulnerability Management

Incident Notification

Retention

DR Testing

Subprocessor Governance

Logging

AI Data Use

154. Risk Concentration

Example:

70% of Critical Vendors
Depend on Same
Cloud Provider

This may create:

Systemic Third-Party Risk

155. Assessment Automation

Mature TPRM platforms may automate:

Inherent Risk

Tiering

Questionnaires

Evidence Requests

Scoring

Findings

Reminders

Approvals

Reassessment

156. Automated Assessment Workflow

Vendor Intake
      ↓
Risk Questions
      ↓
Automatic Tier
      ↓
Assessment Modules
      ↓
Evidence Requests
      ↓
Reviewer
      ↓
Findings
      ↓
Approval Workflow

157. Automation Should Not Replace Judgment

Automation can support:

Consistency

Efficiency

Tracking

but complex risk decisions still require:

Context

Evidence Analysis

Professional Judgment

158. Practical Activity — CloudCRM Assessment

Use fictional vendor:

CloudCRM

Business context:

CRM SaaS

2,500 Users

Customer PI

Business Critical

Cloud Hosted

Multiple Subprocessors

Inherent risk:

High

Perform assessments for:

Security

Privacy

Compliance

Resilience

Fourth Parties

159. Practical Activity — Security Finding

Vendor states:

MFA:
Enabled

Evidence shows:

Employees:
MFA

Administrators:
Optional

Document:

Finding

Severity

Risk

Required Remediation

Residual Risk

160. Practical Activity — SOC Exception

SOC report identifies:

Quarterly Access Reviews
Not Completed

Questionnaire says:

Access Reviews:
Quarterly

Determine:

Evidence Conflict

Control Effectiveness

Finding

Follow-Up

161. Practical Activity — Resilience

Business requirement:

RTO:
4 Hours

Vendor capability:

RTO:
24 Hours

Assess:

Business Impact

Finding Severity

Compensating Controls

Approval Impact

162. Practical Activity — Privacy

Vendor retains:

Customer Data:
7 Years

Business requires:

1 Year

Assess:

Need

Privacy Risk

Contract Requirement

Remediation

163. Practical Activity — AI

Vendor introduces:

AI Assistant

using:

Third-Party
Foundation Model

Assess:

Prompt Data

Training

Retention

Model Provider

Data Location

Subprocessors

Deletion

Security

164. Practical Activity — Fourth Party

Three critical vendors depend on:

Same Cloud Region

Assess:

Concentration Risk

Business Impact

Alternative

Resilience Strategy

165. Practical Activity — Final Decision

Assessment identifies:

1 Critical Finding

3 High Findings

4 Medium Findings

Business says:

Vendor Must
Launch Tomorrow

Determine:

Can Critical Risk
Be Remediated?

Can Scope
Be Restricted?

Are Compensating
Controls Available?

Who Must Approve?

Should Vendor
Be Rejected?

Third-Party Risk Assessment Operational Checklist

Scoping

vendor identified.
service identified.
business owner identified.
business purpose documented.
criticality established.
data identified.
access identified.
integrations identified.

Inherent Risk

data sensitivity assessed.
system access assessed.
privileged access assessed.
business impact assessed.
regulatory exposure assessed.
geographic exposure assessed.
dependency assessed.
risk tier assigned.

Assessment Scope

security scope defined.
privacy scope defined.
compliance scope defined.
resilience scope defined.
cloud scope defined.
AI scope defined.
fourth-party scope defined.

Evidence

questionnaire reviewed.
SOC report reviewed.
ISO certificate validated.
pen-test evidence reviewed.
policies reviewed.
privacy evidence reviewed.
BCP / DR evidence reviewed.
evidence freshness checked.
evidence scope validated.

Security

governance assessed.
IAM assessed.
MFA assessed.
privileged access assessed.
encryption assessed.
network security assessed.
vulnerability management assessed.
secure development assessed.
logging assessed.
incident response assessed.

Privacy

personal data identified.
processing purpose reviewed.
data minimization assessed.
retention assessed.
deletion assessed.
data location assessed.
subprocessors assessed.
privacy rights assessed.

Compliance

applicable requirements identified.
SOC scope reviewed.
SOC exceptions reviewed.
CUECs identified.
ISO scope validated.
PCI requirements reviewed where applicable.

Resilience

BCP reviewed.
DR reviewed.
RTO assessed.
RPO assessed.
backups assessed.
recovery testing reviewed.
concentration assessed.

Cloud / SaaS

shared responsibility documented.
tenant isolation assessed.
cloud regions reviewed.
API security reviewed.
audit logging reviewed.
customer security controls identified.

AI

model provider identified.
prompt use assessed.
training use assessed.
output use assessed.
retention assessed.
memory assessed.
embeddings assessed.
vector storage assessed.
AI subprocessors assessed.
deletion assessed.

Fourth Parties

critical subprocessors identified.
dependencies assessed.
cloud concentration reviewed.
geographic concentration reviewed.
technology concentration reviewed.

Findings

control gaps documented.
evidence linked.
severity assigned.
risk described.
remediation defined.
owners assigned.
due dates established.

Control Effectiveness

control design assessed.
operating effectiveness assessed.
evidence validated.
control rating assigned.

Residual Risk

inherent risk documented.
control effectiveness considered.
residual risk determined.
risk tolerance checked.

Treatment

mitigation considered.
compensating controls considered.
transfer considered.
avoidance considered.
risk acceptance documented where needed.

Approval

recommendation documented.
conditions documented.
risk owner identified.
approval authority confirmed.
approval recorded.

Monitoring

monitoring requirements defined.
reassessment frequency defined.
event triggers defined.
evidence requirements defined.
review date established.

166. Common Third-Party Risk Assessment Mistakes

Mistake 1 — Questionnaire Equals Assessment

A questionnaire is an input, not the final risk decision.

Mistake 2 — No Business Context

A control weakness cannot be properly assessed without understanding the vendor’s role.

Mistake 3 — Same Assessment for Every Vendor

Assessment depth should follow risk.

Mistake 4 — Trusting Vendor Answers Without Evidence

Self-attestation provides limited assurance for material controls.

Mistake 5 — SOC Report Attached but Not Reviewed

Independent assurance must be analyzed.

Mistake 6 — Certification Scope Ignored

A valid certificate may not cover the service being assessed.

Mistake 7 — Findings Without Risk

A technical gap should explain its business or security impact.

Mistake 8 — Inherent and Residual Risk Confused

Controls affect residual risk, not inherent risk.

Mistake 9 — Mathematical Scoring Without Context

Scores should support—not replace—professional judgment.

Mistake 10 — No Fourth-Party Assessment

Critical dependencies may sit beyond the primary vendor.

Mistake 11 — AI Treated Like Traditional SaaS

AI introduces additional data, model, retention, and provider risks.

Mistake 12 — Approval Without Monitoring

Vendor risk continues after onboarding.

167. Weak Third-Party Risk Assessment

Questionnaire
      ↓
Vendor Says Yes
      ↓
Score
      ↓
Approve

168. Strong Third-Party Risk Assessment

Business Context
      ↓
Inherent Risk
      ↓
Risk Tier
      ↓
Assessment Scope
      ↓
Questionnaire
      +
Independent Evidence
      ↓
Control Assessment
      ↓
Security
+
Privacy
+
Compliance
+
Resilience
+
Fourth Parties
      ↓
Findings
      ↓
Control Effectiveness
      ↓
Residual Risk
      ↓
Risk Treatment
      ↓
Formal Approval
      ↓
Continuous Monitoring

169. GRC Analyst Responsibilities

A GRC professional performing Third-Party Risk Assessments may:

review vendor intake information.
determine inherent risk.
assign vendor risk tiers.
define assessment scope.
issue and review questionnaires.
request supporting evidence.
analyze SOC reports.
validate ISO certifications.
review penetration-test evidence.
assess security controls.
assess privacy risks.
evaluate resilience.
identify fourth-party dependencies.
assess AI vendor risks.
document findings.
determine control effectiveness.
evaluate residual risk.
coordinate vendor remediation.
identify compensating controls.
prepare risk recommendations.
coordinate formal risk acceptance.
define monitoring requirements.
maintain assessment evidence.
support internal and external audits.

GRC connects:

Business Owners

Procurement

Vendor Management

Cybersecurity

Privacy

Legal

Cloud

Application Security

Business Continuity

AI Governance

Enterprise Risk

Internal Audit

170. Third-Party Risk Assessment Maturity Model

Level 1 — Questionnaire Based

Vendor Questionnaire

Basic Approval

Level 2 — Standardized

Risk Tiering

Standard Assessment

Evidence Collection

Findings

Level 3 — Evidence Driven

Independent Assurance

Control Effectiveness

Residual Risk

Formal Acceptance

Level 4 — Integrated

Procurement

Contracts

Security

Privacy

Monitoring

Automated Workflow

Level 5 — Continuous Assurance

Dynamic Risk

Continuous Evidence

Automated Signals

Event-Driven Reassessment

Fourth-Party Intelligence

171. Third-Party Risk Assessment Mindset

For every vendor ask:

Why Do We
Need This Vendor?

What Business Process
Depends on Them?

What Data
Will They Receive?

What Systems
Can They Access?

What Happens
If They Are Breached?

What Happens
If They Go Offline?

What Is the
Inherent Risk?

What Evidence
Supports Their Controls?

Does the Evidence
Cover Our Service?

Are the Controls
Designed Properly?

Do the Controls
Actually Operate?

What Findings
Remain?

What Fourth Parties
Do They Depend On?

Where Does
Our Data Go?

Does AI
Process Our Data?

What Residual
Risk Remains?

Can We Reduce It?

Can We Compensate?

Who Owns
the Risk?

Who Can
Accept It?

What Conditions
Are Required?

How Will We
Monitor Them?

When Will We
Reassess?

Can We Defend
Our Decision
to an Auditor?

That is the practical enterprise mindset behind Third-Party Risk Assessments.

Key Takeaways

Third-Party Risk Assessments convert vendor information and evidence into risk decisions.
Business context must be understood before assessing controls.
Inherent risk represents exposure before considering controls.
Vendor risk tiers determine assessment depth and governance requirements.
Questionnaires are assessment inputs, not complete assessments.
Material vendor claims should be supported by appropriate evidence.
Evidence should be checked for freshness, relevance, authenticity, and scope.
Security assessments should evaluate governance, IAM, encryption, vulnerabilities, development, logging, and incident response.
Privacy assessments should evaluate data purpose, minimization, location, retention, deletion, rights, and subprocessors.
Compliance assessments should evaluate relevant assurance such as SOC, ISO, and PCI.
Resilience assessments should compare vendor recovery capabilities with business requirements.
Cloud and SaaS assessments should address shared responsibility and tenant isolation.
AI assessments require additional analysis of prompts, training, models, memory, embeddings, retention, and providers.
Fourth-party and concentration risks should be evaluated.
Findings should clearly connect control weaknesses to risk.
Control design and operating effectiveness are different concepts.
Residual risk represents the risk remaining after controls.
Risk treatment may include avoidance, mitigation, transfer, or acceptance.
Material exceptions should be formally approved and time-bound.
Final vendor approval should be performed by the appropriate risk authority.
Approval should define ongoing monitoring and reassessment requirements.
Strong assessments produce traceable evidence supporting defensible business decisions.

Knowledge Check

Before continuing, make sure you can answer:

What is a Third-Party Risk Assessment?
Why is a questionnaire not the same as a risk assessment?
What information should be collected about vendor business context?
What is inherent vendor risk?
Which factors can determine inherent risk?
Why are vendors assigned risk tiers?
How does risk tier affect assessment scope?
What evidence can support a vendor assessment?
How should evidence scope be validated?
What is the difference between vendor statements and independent assurance?
What IAM controls should be assessed?
What should be reviewed during a penetration-test assessment?
What privacy risks should be assessed?
What should be reviewed in a SOC report?
What are CUECs?
How should ISO certification scope be validated?
Why should RTO and RPO be compared with business requirements?
What additional risks should be considered for SaaS vendors?
What additional risks should be considered for AI vendors?
Why are fourth-party dependencies important?
What is concentration risk?
What makes a strong vendor finding?
What is control effectiveness?
What is the difference between design and operating effectiveness?
What is residual risk?
What are the four common risk-treatment options?
What is a compensating control?
Who should accept material vendor risk?
What should be included in the final assessment report?
Why should monitoring requirements be defined during approval?

What’s Next?

➡️ Next: 10 — Third-Party Risk Reporting & Governance

In the next lesson, you will move from assessing individual vendors to managing third-party risk across the entire enterprise portfolio.

You will learn how to transform:

Vendor Assessments
      +
Risk Ratings
      +
Findings
      +
Incidents
      +
Monitoring Signals
      ↓
Portfolio-Level
Third-Party Risk
      ↓
Management Reporting
      ↓
Risk Committees
      ↓
Executive Decisions
      ↓
Board Oversight

You will examine vendor-risk governance structures, roles and responsibilities, risk committees, portfolio segmentation, risk appetite, risk acceptance, issue escalation, concentration risk, fourth-party exposure, critical-vendor reporting, KRIs, KPIs, risk heatmaps, executive dashboards, board reporting, and TPRM program effectiveness.

You will also build practical artifacts including a TPRM Governance Framework, Vendor Risk RACI Matrix, Critical Vendor Register, Vendor Risk Appetite & Threshold Matrix, Third-Party Risk Heatmap, TPRM KPI/KRI Register, Executive Vendor Risk Dashboard, Vendor Risk Committee Pack, Risk Acceptance Register, and Third-Party Risk Governance Report.