Runbook 01 — Third-Party Risk Assessment & Vendor Onboarding

Runbook Information

Item	Details
Runbook Type	Third-Party Risk Management
Primary Role	GRC Analyst / Third-Party Risk Analyst
Supporting Roles	Procurement, Security, Privacy, Legal, Business Owner, IAM
Trigger	New vendor or material vendor-service change
Objective	Assess and approve third-party risk before production use
Primary Output	Approved Vendor Risk Assessment & Onboarding Record
Review Frequency	At least annually and after material changes

Purpose

This runbook provides a repeatable operational process for evaluating and onboarding third parties.

Use it when an organization plans to introduce:

Cloud Provider

SaaS Platform

Software Vendor

Managed Service Provider

Consultant

Payment Processor

Data Processor

AI Provider

Business Partner

Technology Supplier

The runbook ensures that vendor onboarding follows:

Vendor Request
      ↓
Business Intake
      ↓
Inherent Risk
      ↓
Vendor Tier
      ↓
Assessment Scope
      ↓
Due Diligence
      ↓
Evidence Review
      ↓
Findings
      ↓
Residual Risk
      ↓
Contract Requirements
      ↓
Approval
      ↓
Secure Onboarding
      ↓
Monitoring

Runbook Objectives

This runbook helps ensure that:

• all new vendors enter through a controlled intake process.

• vendor business owners are identified.

• data and system exposure are understood.

• inherent risk is determined before due diligence.

• vendors are assigned appropriate risk tiers.

• security, privacy, compliance, and resilience reviews are risk-based.

• supporting evidence is collected and validated.

• vendor-control gaps are documented.

• residual risk is formally evaluated.

• material risks are remediated or accepted by authorized owners.

• contractual controls reflect identified risks.

• third-party access is governed before provisioning.

• onboarding is not completed until required controls are satisfied.

• ongoing monitoring and reassessment requirements are defined.

Scope

Use this runbook for:

New Vendors

New SaaS Platforms

New Cloud Providers

New Managed Services

New Outsourcing Arrangements

New Data Processors

New AI Providers

Material Changes
to Existing Vendors

Material changes may include:

New Sensitive Data

New Production Access

New Privileged Access

New Country

New Subprocessor

New AI Functionality

Changed Hosting Model

Major Service Expansion

Roles and Responsibilities

Role	Responsibility
Business Owner	Defines business need and owns relationship
Procurement	Coordinates sourcing and contract workflow
TPRM / GRC	Performs risk assessment and governance
Cybersecurity	Reviews security controls
Privacy	Reviews personal-data processing
Legal	Reviews contractual and regulatory obligations
IAM	Provisions approved third-party access
Business Continuity	Reviews resilience where applicable
Risk Owner	Accepts residual risk where authorized

Entry Criteria

Start this runbook when:

New Vendor Requested

or when:

Existing Vendor
      ↓
Material Change

Do not wait until:

Contract Signed

or:

Vendor Already
in Production

to begin the assessment.

Exit Criteria

The vendor may complete onboarding when:

• vendor intake is complete.

• business owner is confirmed.

• inherent risk is assessed.

• vendor tier is assigned.

• required due diligence is complete.

• required evidence is validated.

• critical findings are resolved or formally approved.

• residual risk is documented.

• security/privacy contractual requirements are addressed.

• risk acceptance is approved where required.

• onboarding conditions are completed.

• monitoring requirements are established.

Phase 1 — Vendor Request Intake

Step 1.1 — Receive Vendor Request

Capture:

Vendor Name

Requested Service

Business Purpose

Business Owner

Requested Go-Live Date

Create a unique assessment identifier:

TPRA-YYYY-####

Example:

TPRA-2026-0042

Step 1.2 — Open Vendor Assessment Record

Create:

Vendor Assessment Record

Record:

Field	Value
Assessment ID
Vendor
Service
Business Owner
Request Date
Requested Go-Live
Analyst
Status	Intake

Step 1.3 — Verify Business Need

Ask:

Why Is the Vendor Needed?

What Business Process
Does It Support?

Who Will Use It?

Is an Approved
Alternative Available?

Document the justification.

Decision Point

If there is:

No Valid
Business Owner

or:

No Valid
Business Need

set status:

ON HOLD

and return the request for clarification.

Phase 2 — Understand Vendor Exposure

Step 2.1 — Identify Data

Determine whether vendor will process:

Public Data

Internal Data

Confidential Data

Personal Data

Sensitive Personal Data

Payment Data

Authentication Data

Financial Data

Intellectual Property

Security Data

Step 2.2 — Identify System Access

Determine:

No Access

Application Access

API Access

Network Access

Cloud Access

Production Access

Privileged Access

Step 2.3 — Identify Integration

Document:

SSO

API

VPN

Database

Cloud Role

Agent

Webhook

File Transfer

Remote Support

Step 2.4 — Identify Data Locations

Ask:

Where Is Data Stored?

Where Is It Processed?

Where Are Backups?

Where Can Support
Personnel Access It?

Step 2.5 — Identify Subprocessors

Request:

Vendor Subprocessor List

Document critical:

Cloud Providers

Hosting Providers

Support Providers

Model Providers

Payment Providers

Phase 3 — Perform Inherent Risk Assessment

Step 3.1 — Score Data Sensitivity

Example:

Exposure	Score
Public	1
Internal	2
Confidential	3
Restricted / Regulated	4

Step 3.2 — Score Access

Access	Score
None	1
Standard User	2
Production / API	3
Privileged	4

Step 3.3 — Score Business Criticality

Criticality	Score
Low	1
Medium	2
High	3
Critical	4

Step 3.4 — Score Regulatory Exposure

Exposure	Score
Minimal	1
Limited	2
Significant	3
Regulated / Critical	4

Step 3.5 — Score Operational Dependency

Dependency	Score
Easily Replaceable	1
Limited Dependency	2
Important	3
Essential	4

Step 3.6 — Calculate Inherent Risk

Example:

Data                4
Access              3
Criticality         4
Regulatory          4
Dependency          4
                   ──
Total              19

Example thresholds:

Score	Risk
5–8	Low
9–12	Medium
13–16	High
17–20	Critical

Phase 4 — Assign Vendor Tier

Use:

Inherent Risk	Tier
Critical	Tier 1
High	Tier 2
Medium	Tier 3
Low	Tier 4

Record:

Vendor Tier

in the assessment record.

Phase 5 — Determine Assessment Scope

Tier 1

Require:

Detailed Security Assessment

Privacy Assessment

Compliance Review

BCP / DR Review

Independent Assurance

Pen-Test Evidence

Contract Security Review

Continuous Monitoring

Tier 2

Require:

Detailed Questionnaire

Security Evidence

Privacy Review if Applicable

Compliance Review

Resilience Review

Annual Reassessment

Tier 3

Require:

Standard Questionnaire

Risk-Based Evidence

Privacy Review if Applicable

Tier 4

Require:

Basic Screening

Phase 6 — Issue Vendor Questionnaire

Send applicable modules:

Core Security

Privacy

Cloud

SaaS

Software

Resilience

AI

Record:

Sent Date

Vendor Due Date

Response Date

Escalation

If questionnaire is overdue:

Day 7
Reminder

Day 14
Business Owner Reminder

Day 21
Escalate to Procurement

Adjust to organizational SLA.

Phase 7 — Request Evidence

Core Evidence

Request as applicable:

SOC 2

ISO 27001 Certificate

Security Policies

Penetration-Test Summary

Vulnerability Management Evidence

Incident Response Plan

BCP / DR Evidence

Privacy Documentation

Subprocessor List

AI Vendor Evidence

Also request:

AI Data Processing Terms

Model Provider Information

Training Policy

Prompt Retention

AI Subprocessor List

Deletion Capabilities

Phase 8 — Validate Evidence

For every artifact verify:

Current?

Correct Vendor?

Correct Legal Entity?

Correct Service?

Correct Scope?

Valid Period?

Exceptions?

Independent?

Do not record:

SOC 2 Received

without also determining:

SOC 2 Reviewed

Phase 9 — Review SOC Reports

Check:

Type I / Type II

Audit Period

Scope

Opinion

Exceptions

Subservice Organizations

CUECs

Escalate if:

Qualified Opinion

Repeated Critical Exceptions

Relevant Scope Excluded

Report Expired

Phase 10 — Review ISO Evidence

Validate:

Certificate Number

Legal Entity

Scope

Locations

Issue Date

Expiry

Certification Body

Do not treat:

ISO Certified

as sufficient without validating scope.

Phase 11 — Assess Identity & Access

Verify:

MFA

SSO

Least Privilege

RBAC

PAM

Access Reviews

Joiner / Mover / Leaver

Service Accounts

Critical Finding Trigger

Escalate if:

Privileged Production Access
Without MFA

or:

Shared Administrative
Accounts

without appropriate controls.

Phase 12 — Assess Encryption

Review:

Data at Rest

Data in Transit

Backups

Key Management

Key Rotation

Determine whether controls align with:

Data Classification

Phase 13 — Assess Vulnerability Management

Review:

Scanning Frequency

Patch SLA

Critical Vulnerability Handling

Exception Process

Retesting

Critical Trigger

If vendor has:

Known Critical
Exploited Vulnerability

determine whether production onboarding should be blocked.

Phase 14 — Assess Penetration Testing

Verify:

Test Date

Scope

Independence

Critical Findings

High Findings

Remediation

Retesting

Finding

Do not treat:

Pen Test Completed

as sufficient if:

Critical Findings
Remain Open

Phase 15 — Assess Secure Development

For software vendors review:

Secure SDLC

Code Review

SAST

DAST

SCA

Dependency Management

Secrets Scanning

Threat Modeling

SBOM

Artifact Integrity

Phase 16 — Assess Logging & Monitoring

Review:

Authentication Logging

Administrative Logging

Security Events

Data Access

Log Retention

Monitoring

SOC / SIEM

Phase 17 — Assess Incident Response

Review:

Incident Response Plan

Testing

Customer Notification

Escalation

Forensics

Root Cause Analysis

Compare vendor capability with contractual requirements.

Phase 18 — Perform Privacy Review

If personal data is processed, assess:

Data Categories

Purpose

Location

Retention

Deletion

Subprocessors

International Transfers

Data Subject Rights

Incident Notification

Privacy Escalation Triggers

Escalate:

Indefinite Retention

Unapproved Secondary Use

Unknown Subprocessors

Unapproved Cross-Border Processing

Inability to Delete Data

Phase 19 — Assess AI Risk

For AI vendors determine:

Which Model?

Which Provider?

Are Prompts Retained?

Are Outputs Retained?

Is Customer Data
Used for Training?

Are Files Used
for Model Improvement?

Are Embeddings Stored?

Is Memory Persistent?

Can Data Be Deleted?

AI Risk Trigger

Escalate when:

Sensitive Enterprise Data
      +
Provider Model Training

without approved controls.

Phase 20 — Assess Compliance

Determine applicable:

SOC 1

SOC 2

ISO 27001

ISO 27017

ISO 27018

PCI DSS

Privacy Requirements

Industry Requirements

Map:

Requirement
      ↓
Vendor Evidence
      ↓
Gap

Phase 21 — Assess Business Continuity

Review:

BCP

DR

Backup

RTO

RPO

Failover

Recovery Testing

Compare:

Business Requirement

against:

Vendor Capability

Example

Required RTO:
4 Hours

Vendor RTO:
24 Hours

Record:

Resilience Finding

Phase 22 — Assess Fourth-Party Risk

Identify:

Critical Subprocessors

Cloud Providers

Model Providers

Hosting Dependencies

Network Dependencies

Ask:

Could Failure
of a Fourth Party
Impact Our Service?

Phase 23 — Identify Concentration Risk

Check whether multiple services rely on:

Same Vendor

Same Cloud Provider

Same Region

Same Model Provider

Same Payment Provider

Record material dependencies.

Phase 24 — Create Findings

Each finding should include:

Condition

Criteria

Risk

Severity

Evidence

Required Action

Example:

Finding

Vendor administrators
are not required
to use MFA.

Risk

Compromised credentials
could provide unauthorized
privileged access.

Severity

High

Required Action

Implement mandatory MFA
for privileged users.

Phase 25 — Rate Finding Severity

Use:

Critical

High

Medium

Low

Consider:

Likelihood

Impact

Data Sensitivity

Business Criticality

Exposure

Existing Controls

Phase 26 — Assess Control Effectiveness

Use:

Effective

Partially Effective

Ineffective

Not Implemented

Not Applicable

Assess both:

Design Effectiveness

and:

Operating Effectiveness

Phase 27 — Determine Residual Risk

Conceptually:

Inherent Risk
      ↓
Vendor Controls
      ↓
Control Effectiveness
      ↓
Findings
      ↓
Compensating Controls
      ↓
Residual Risk

Use:

Low

Medium

High

Critical

Phase 28 — Determine Risk Treatment

Choose:

Avoid

Mitigate

Transfer

Accept

Avoid

Do not use vendor.

Mitigate

Require remediation or additional controls.

Transfer

Use contractual allocation or insurance where appropriate.

Accept

Obtain formal authorization.

Phase 29 — Define Compensating Controls

If vendor cannot immediately remediate, possible controls include:

Data Minimization

Restricted Access

IP Allowlisting

Additional Monitoring

Tokenization

Customer-Side Encryption

No Sensitive Data

Limited Pilot

Ensure compensating controls address the actual risk.

Phase 30 — Determine Approval Decision

Available outcomes:

APPROVED

APPROVED WITH CONDITIONS

REMEDIATION REQUIRED

ESCALATED

REJECTED

Approval Criteria — Approved

Use when:

Residual Risk
Within Tolerance

and no blocking issues remain.

Approval Criteria — Approved With Conditions

Use when:

Risk Acceptable
for Limited Operation

provided defined remediation is completed.

Approval Criteria — Remediation Required

Use when:

Material Risk
Must Be Reduced
Before Production

Approval Criteria — Escalated

Use when:

Risk Exceeds
Analyst Authority

Approval Criteria — Rejected

Use when:

Risk Cannot Be
Reduced to
Acceptable Level

Phase 31 — Obtain Risk Acceptance

For unresolved risks, create:

Risk Acceptance Record

Document:

Risk

Business Justification

Compensating Controls

Residual Risk

Owner

Approver

Expiry

Rule

Risk acceptance must be:

Authorized
+
Time-Bound
+
Reviewable

Phase 32 — Translate Findings Into Contract Requirements

Send required items to:

Procurement

Legal

Examples:

Incident Notification

Data Deletion

Subprocessor Notification

Audit Rights

MFA Requirements

Security Testing

BCP / DR

Data Location

AI Training Restriction

Phase 33 — Review Contract Security Terms

Confirm relevant:

Security Addendum

DPA

SLA

Audit Rights

Incident Terms

Retention

Deletion

Subprocessors

Termination

are addressed.

Phase 34 — Record Contract Exceptions

If vendor rejects a required clause:

Contract Requirement
      ↓
Vendor Exception
      ↓
Risk Assessment
      ↓
Approval

Do not silently remove the requirement.

Phase 35 — Pre-Onboarding Security Gate

Before onboarding verify:

Assessment Complete?

Approval Complete?

Contract Complete?

Blocking Findings Resolved?

Risk Acceptance Approved?

Access Requirements Defined?

If any mandatory item is:

No

hold onboarding.

Phase 36 — Third-Party Access Review

If vendor requires internal access, determine:

Named Accounts

Business Approval

Least Privilege

MFA

PAM

JIT

Expiry

Logging

Phase 37 — Service Account Review

For integrations verify:

Account Owner

Purpose

Least Privilege

Secret Storage

Rotation

Expiration

Monitoring

Phase 38 — API Access Review

Check:

API Authentication

Token Scope

Credential Storage

Rotation

Logging

Rate Limiting

Phase 39 — Network Access Review

For VPN / network access:

Vendor
      ↓
Restricted Segment
      ↓
Required System

Avoid:

Vendor
      ↓
Entire Internal Network

Phase 40 — Secure Onboarding Checklist

Create:

Vendor Onboarding Checklist

Verify:

• named vendor identities created.

• MFA enabled.

• least privilege applied.

• access expiry configured.

• PAM used where required.

• service accounts documented.

• API credentials protected.

• network access restricted.

• audit logs enabled.

• vendor owner confirmed.

Phase 41 — Data Onboarding Controls

Before sending production data verify:

Data Approved?

Minimum Necessary?

Encryption?

Region Approved?

Retention Defined?

DPA Executed?

Phase 42 — AI Onboarding Controls

For AI vendors verify:

Approved Use Cases

Permitted Data

Training Disabled
where Required

Retention Configured

Model Provider Approved

Subprocessors Reviewed

Sensitive Data Restrictions

Logging Enabled

Phase 43 — Document Final Approval

Create:

Vendor Approval Record

Include:

Field	Value
Vendor
Service
Tier
Inherent Risk
Residual Risk
Open Findings
Decision
Conditions
Risk Owner
Approval Date
Next Review

Phase 44 — Update Vendor Risk Register

Add:

Vendor

Business Owner

Service

Tier

Inherent Risk

Residual Risk

Findings

Risk Acceptance

Decision

Monitoring

Next Review

Phase 45 — Define Monitoring Requirements

Use risk tier.

Tier 1

Continuous Monitoring

Quarterly Governance Review

Annual Assessment

Annual SOC Review

Pen-Test Review

Incident Monitoring

Critical Vulnerability Monitoring

Tier 2

Quarterly / Annual Monitoring

Annual Assessment

Evidence Review

Finding Monitoring

Tier 3

Annual / Event-Based Review

Tier 4

Renewal / Event-Driven Review

Phase 46 — Define Reassessment Triggers

Trigger reassessment after:

Security Breach

Major Outage

New Data Type

New Production Access

New Privileged Access

New Country

New Subprocessor

AI Feature Change

Acquisition

Certification Loss

Critical Vulnerability

Phase 47 — Define Vendor Finding Monitoring

For each finding track:

Owner

Due Date

Severity

Status

Evidence

Retest

Phase 48 — Escalate Overdue Findings

Example:

High Finding
      ↓
Past Due
      ↓
Vendor Owner
      ↓
TPRM
      ↓
Risk Committee

based on defined thresholds.

Phase 49 — Monitor Risk Acceptance Expiry

Before expiry:

30 Days
      ↓
Reminder

then determine:

Remediated?

Renew Acceptance?

Escalate?

Stop Service?

Phase 50 — Monitor Vendor Incidents

If vendor reports an incident:

Open Vendor Incident Record

Assess:

Our Data?

Our Systems?

Our Users?

Our Operations?

Regulatory Impact?

Contract SLA?

Phase 51 — Vendor Incident Reassessment

If material:

Vendor Incident
      ↓
Trigger Reassessment
      ↓
Update Residual Risk

Phase 52 — Monitor Assurance Expiry

Track:

SOC Reports

ISO Certificates

Pen Tests

Insurance

BCP Tests

Set alerts before expiry.

Phase 53 — Review Vendor at Renewal

Before renewal reassess:

Current Risk

Open Findings

Incidents

SLA

Evidence

Subprocessors

Service Changes

Contract Exceptions

Phase 54 — Secure Vendor Termination

If vendor relationship ends:

Contract End
      ↓
Access Removal
      ↓
Token Revocation
      ↓
Data Return
      ↓
Data Deletion
      ↓
Evidence

Phase 55 — Offboarding Checklist

Verify:

• user accounts disabled.

• privileged accounts disabled.

• VPN removed.

• API keys revoked.

• service accounts disabled.

• tokens revoked.

• certificates revoked.

• integrations removed.

• data returned.

• data deleted.

• deletion evidence retained.

Escalation Conditions

Immediately escalate when:

Critical Residual Risk

Confirmed Vendor Breach

Unresolved Critical Finding

Privileged Access Without MFA

Material Data Residency Issue

Vendor Refuses Required Security Terms

Critical Certification Loss

Major Resilience Failure

Unapproved High-Risk Subprocessor

Escalation Path

TPRM Analyst
      ↓
TPRM Manager / GRC
      ↓
Cybersecurity / Privacy
      ↓
Business Risk Owner
      ↓
Risk Committee
      ↓
Executive Management

Vendor Assessment Status Values

Use standardized statuses:

Requested

Intake

Risk Tiering

Assessment

Waiting for Vendor

Evidence Review

Remediation

Risk Approval

Contract Review

Onboarding

Approved

Rejected

Monitoring

Terminated

Evidence Requirements

Retain:

Vendor Intake

Inherent Risk Assessment

Questionnaire

SOC Reports

ISO Certificates

Pen-Test Evidence

Privacy Evidence

BCP / DR Evidence

Findings

Risk Treatment

Risk Acceptance

Approval

Contracts

Onboarding Evidence

Monitoring Records

Recommended Evidence Folder

TPRA-2026-0042/
│
├── 01 Intake/
├── 02 Inherent Risk/
├── 03 Questionnaire/
├── 04 Security Evidence/
├── 05 Privacy Evidence/
├── 06 Compliance Evidence/
├── 07 Resilience/
├── 08 Findings/
├── 09 Remediation/
├── 10 Risk Acceptance/
├── 11 Contract/
├── 12 Approval/
├── 13 Onboarding/
└── 14 Monitoring/

Operational Metrics

Track:

Assessment Completion Time

Vendors Assessed Before Onboarding

Evidence Completion

Critical Findings

Overdue Findings

Risk Acceptance

Assessment Coverage

Monitoring Coverage

KPI — Pre-Onboarding Assessment

Vendors Assessed
Before Production
──────────────── × 100
New Vendors

Target:

100%

KPI — Assessment SLA

Assessments Completed
Within SLA
──────────────────── × 100
Assessments Completed

KPI — Critical Evidence Coverage

Required Critical
Evidence Received
──────────────── × 100
Critical Evidence Required

KRI — Critical Vendor Without Assessment

Critical Vendors
Operating Without
Current Assessment

Target:

0

KRI — Open Critical Findings

Open Critical
Vendor Findings

Target:

0

KRI — Expired Risk Acceptance

Vendor Risks
Operating Past
Approved Expiry

Target:

0

Common Failure Scenarios

Scenario 1 — Business Already Purchased Vendor

Do not skip risk assessment.

Perform:

Emergency Intake
      ↓
Risk Assessment
      ↓
Control Restrictions
      ↓
Formal Decision

and document process failure.

Scenario 2 — Vendor Refuses Questionnaire

Seek alternative assurance:

SOC Report

ISO Evidence

Security Portal

Independent Audit

Controlled Evidence Review

If assurance remains insufficient:

Record Assurance Gap
      ↓
Increase Residual Risk

Scenario 3 — Vendor Will Not Provide Pen Test

Assess whether:

SOC 2

Independent Security Audit

Certification

Alternative Evidence

provides adequate assurance.

If not:

Risk Exception

may be required.

Scenario 4 — Business Demands Immediate Go-Live

Use:

Documented Risk

Restricted Scope

Compensating Controls

Temporary Approval

Defined Expiry

only where appropriate and authorized.

Scenario 5 — Critical Finding Discovered

Do not automatically continue onboarding.

Determine:

Can It Be Remediated
Before Production?

If no:

Can Risk Be
Acceptably Compensated?

If no:

Escalate / Reject

Scenario 6 — Vendor Adds AI Feature

Trigger:

AI Risk Review

before sensitive enterprise data is used.

Scenario 7 — New Subprocessor Identified

Review:

Service

Data

Location

Security

Privacy

Contract Rights

Decision Tree

Vendor Requested
      ↓
Business Need Valid?
      │
      ├── No → Stop
      │
      └── Yes
             ↓
        Inherent Risk
             ↓
        Risk Tier
             ↓
      Required Assessment
             ↓
        Evidence Complete?
             │
             ├── No → Obtain / Escalate
             │
             └── Yes
                    ↓
              Critical Finding?
                    │
             ┌──────┴──────┐
            Yes            No
             ↓              ↓
      Can Remediate?     Residual Risk
          │                  ↓
      ┌───┴───┐         Within Appetite?
     Yes      No             │
      ↓        ↓         ┌───┴───┐
Remediate   Compensate? Yes      No
               │          ↓       ↓
           ┌───┴───┐   Approve  Escalate
          Yes      No
           ↓        ↓
        Accept?   Reject

Runbook Completion Checklist

Intake

• assessment record created.

• business owner confirmed.

• service documented.

• business need validated.

• go-live date captured.

Risk Identification

• data identified.

• access identified.

• integrations documented.

• criticality determined.

• regulatory exposure assessed.

• fourth parties identified.

Inherent Risk

• risk factors scored.

• inherent risk calculated.

• vendor tier assigned.

• assessment scope determined.

Due Diligence

• questionnaire completed.

• evidence received.

• evidence current.

• evidence scope validated.

• SOC/ISO reviewed where applicable.

• pen-test evidence reviewed.

Security

• IAM reviewed.

• MFA reviewed.

• privileged access reviewed.

• encryption reviewed.

• vulnerability management reviewed.

• secure development reviewed.

• logging reviewed.

• incident response reviewed.

Privacy

• personal data identified.

• purpose reviewed.

• data location reviewed.

• retention reviewed.

• deletion reviewed.

• subprocessors reviewed.

• cross-border processing reviewed.

Resilience

• BCP reviewed.

• DR reviewed.

• RTO compared.

• RPO compared.

• backup assessed.

• recovery testing reviewed.

AI

• model provider identified.

• training use reviewed.

• prompt retention reviewed.

• outputs reviewed.

• embeddings reviewed.

• AI memory reviewed.

• subprocessors reviewed.

• deletion reviewed.

Findings

• findings documented.

• severity assigned.

• remediation defined.

• owner assigned.

• due date assigned.

Residual Risk

• control effectiveness evaluated.

• compensating controls considered.

• residual risk determined.

• risk appetite checked.

Approval

• decision documented.

• conditions documented.

• authorized approval obtained.

• risk acceptance documented where applicable.

Contracts

• security requirements mapped.

• privacy terms reviewed.

• incident terms reviewed.

• audit rights reviewed.

• subprocessor requirements reviewed.

• retention/deletion reviewed.

• exceptions documented.

Onboarding

• access requirements approved.

• MFA enabled.

• least privilege applied.

• service accounts governed.

• API credentials governed.

• network access restricted.

• logging enabled.

Monitoring

• monitoring frequency established.

• reassessment date assigned.

• material-change triggers defined.

• finding monitoring established.

• evidence expiry tracked.

• risk-acceptance expiry tracked.

Runbook Output

At completion, the analyst should produce:

Vendor Assessment Record

Inherent Risk Assessment

Vendor Tier

Due Diligence Evidence Pack

Vendor Findings Register

Residual Risk Assessment

Risk Treatment Plan

Risk Acceptance Record

Contract Requirements

Vendor Approval Record

Onboarding Checklist

Monitoring Plan

Expected Outcome

A successfully completed runbook should allow the organization to answer:

Why Are We
Using This Vendor?

What Data
Do They Process?

What Access
Do They Have?

How Critical
Are They?

What Is Their
Inherent Risk?

What Controls
Do They Have?

What Evidence
Supports Those Controls?

What Findings
Remain?

What Is the
Residual Risk?

What Must
Be Remediated?

Who Accepted
Any Remaining Risk?

What Contract
Controls Apply?

Was Onboarding
Performed Securely?

How Will We
Monitor Them?

When Will We
Reassess Them?

Runbook Success Criteria

The runbook is successful when:

No Third Party
Enters Production
Without Appropriate
Risk Evaluation

and every material vendor has:

Owner
+
Risk Tier
+
Assessment
+
Evidence
+
Decision
+
Monitoring

What’s Next?

➡️ Next: Runbook 02 — Third-Party Risk Monitoring, Incident Escalation & Vendor Offboarding

In the next runbook, you will move from initial vendor assessment and onboarding to operating the vendor relationship throughout its lifecycle.

You will work through:

Approved Vendor
      ↓
Continuous Monitoring
      ↓
Risk Signals
      ↓
Vendor Incident
      ↓
Material Change
      ↓
Reassessment
      ↓
Finding / Remediation
      ↓
Risk Escalation
      ↓
Contract Renewal
      ↓
Vendor Exit
      ↓
Access Revocation
      ↓
Data Return & Deletion

The runbook will provide an operational process for continuous vendor monitoring, security-incident handling, risk-trigger validation, event-driven reassessment, finding escalation, risk-acceptance review, contract renewal, vendor termination, access revocation, data deletion, and evidence-based closure.