Runbook 02 — Third-Party Risk Assessment & Vendor Onboarding

Runbook Information

Item	Details
Runbook	02 — Third-Party Risk Assessment & Vendor Onboarding
Module	01 — GRC Fundamentals
Difficulty	Intermediate
Estimated Time	90–120 Minutes
Primary Role	GRC Analyst / Third-Party Risk Analyst
Supporting Roles	Procurement, Legal, Privacy, Security, Business Owner
Primary Output	Vendor Risk Assessment & Approval Record
Runbook Type	Third-Party Risk Management

Purpose

This runbook provides a repeatable process for assessing and onboarding third parties such as:

• SaaS providers.

• Cloud providers.

• Managed service providers.

• Contractors.

• Consultants.

• Software vendors.

• Data processors.

• Payment providers.

• Security vendors.

• Business partners.

The objective is to ensure that no significant third party begins processing sensitive information, accessing systems, or supporting critical business services without an appropriate level of risk assessment and approval.

The core principle is:

The depth of third-party due diligence should be proportional to the risk introduced by the relationship.

Runbook Outcomes

By following this runbook, the GRC team should produce:

• Vendor intake record.

• Business owner confirmation.

• Data classification.

• Business criticality assessment.

• Inherent vendor risk score.

• Vendor risk tier.

• Due diligence requirements.

• Security assessment.

• Assurance-document review.

• Vendor findings.

• Residual risk rating.

• Contractual security requirements.

• Risk decision.

• Approval record.

• Remediation plan.

• Ongoing monitoring schedule.

• Reassessment schedule.

• Offboarding requirements.

Operational Workflow

Business Need
      ↓
Vendor Intake
      ↓
Business Owner
      ↓
Data Classification
      ↓
Business Criticality
      ↓
Inherent Risk Assessment
      ↓
Vendor Tiering
      ↓
Due Diligence
      ↓
Security Questionnaire
      ↓
Assurance Evidence
      ↓
Findings
      ↓
Residual Risk
      ↓
Contract Review
      ↓
Risk Decision
      ↓
Approval
      ↓
Onboarding
      ↓
Monitoring
      ↓
Reassessment
      ↓
Offboarding

Phase 1 — Vendor Intake

Step 1 — Receive the Vendor Request

Every assessment should begin with a documented business request.

Record:

Vendor Name

Requested Service

Business Owner

Business Unit

Business Justification

Expected Contract Date

Expected Go-Live Date

Avoid beginning the assessment using only an email such as:

We need this vendor approved today.

The relationship should be formally recorded.

Step 2 — Confirm the Business Owner

Every vendor must have an internal owner.

The business owner should understand:

• Why the vendor is needed.

• Which process it supports.

• What data will be shared.

• Which users will use the service.

• How important the service is.

• What happens if the vendor fails.

Example:

Vendor:
CloudCollab

Business Owner:
Director of Customer Operations

GRC owns the assessment process.

The business owner owns the business relationship and associated business risk.

Step 3 — Record Vendor Service Details

Document:

Field	Example
Service	SaaS Collaboration
Hosting	Vendor Managed
Users	1,500
SSO	Yes
API Integration	Yes
Production Access	No
Sensitive Data	Yes
Subprocessors	Yes

This establishes assessment context.

Phase 2 — Understand Data and Access

Step 4 — Identify Data Processed

Ask:

Will the vendor process:

Customer Data?

Employee Data?

Financial Data?

Authentication Data?

Source Code?

Confidential Documents?

Regulated Data?

Payment Data?

Document all applicable categories.

Step 5 — Determine Data Classification

Use the organization’s classification model.

Example:

Public

Internal

Confidential

Restricted

Higher data sensitivity generally increases vendor risk.

Step 6 — Identify System Access

Determine whether the vendor will receive:

• Corporate accounts.

• Network access.

• VPN access.

• Production access.

• Privileged access.

• API credentials.

• Service accounts.

• Customer-facing access.

Example:

Vendor:
Managed Database Provider

Access:
Privileged production support

Result:
Higher Inherent Risk

Step 7 — Understand Data Flow

Document:

Enterprise
     ↓
Vendor
     ↓
Vendor Systems
     ↓
Subprocessors

Where relevant identify:

• Data storage locations.

• Processing locations.

• Backup locations.

• Support locations.

• Subprocessor locations.

This is particularly important for privacy and regulatory requirements.

Phase 3 — Determine Business Criticality

Step 8 — Assess Service Criticality

Ask:

What happens if the vendor becomes unavailable?

Potential impact:

No Material Impact

Minor Productivity Loss

Department Disruption

Critical Business Service Failure

Customer Service Outage

Use a consistent criticality scale.

Step 9 — Consider Replacement Difficulty

Assess:

• Are alternatives readily available?

• Can the service be replaced quickly?

• Is significant integration required?

• Is there data lock-in?

• Is migration complex?

A vendor may become operationally critical even if it does not process highly sensitive information.

Step 10 — Identify Regulatory Impact

Determine whether the service involves:

• Privacy obligations.

• Payment processing.

• Financial reporting.

• Healthcare information.

• Customer contractual commitments.

• Data residency.

• Regulated business functions.

Where legal interpretation is required, involve Legal or Compliance.

Phase 4 — Perform Inherent Risk Assessment

Step 11 — Score Inherent Risk

Assess the relationship before considering vendor controls.

Possible factors:

Data Sensitivity

Business Criticality

System Access

Privileged Access

User Population

Integration Complexity

Regulatory Impact

Subprocessor Dependency

Example scoring:

Factor	Score
Data Sensitivity	4
Business Criticality	4
System Access	3
Regulatory Impact	3
Subprocessor Dependency	4

Step 12 — Calculate the Result

Use the organization’s documented methodology.

Example:

Total Score:
18

Possible classification:

Tier 1 — Critical

Tier 2 — High

Tier 3 — Moderate

Tier 4 — Low

Do not alter the tier because the business wants faster approval.

Phase 5 — Assign the Vendor Risk Tier

Step 13 — Tier 1 — Critical

Typical characteristics:

• Sensitive or regulated data.

• Critical business service.

• Privileged access.

• Significant customer impact.

• Difficult replacement.

• High operational dependency.

Required assessment may include:

Full Questionnaire

SOC 2 Review

ISO Review

Penetration-Test Review

BCP / DR Review

Privacy Assessment

Subprocessor Review

Contract Review

Enhanced Monitoring

Step 14 — Tier 2 — High

May require:

• Full questionnaire.

• Relevant assurance documents.

• Security evidence.

• Contract review.

• Annual reassessment.

Step 15 — Tier 3 — Moderate

May require:

• Shorter questionnaire.

• Selected evidence.

• Basic security review.

• Periodic reassessment.

Step 16 — Tier 4 — Low

May require:

• Basic intake.

• Sanctions or business checks where applicable.

• Minimal security review.

• Event-driven reassessment.

The goal is scalability.

Phase 6 — Define Due Diligence Requirements

Step 17 — Create the Assessment Checklist

For high-risk vendors, request as applicable:

Security Questionnaire

SOC 2 Type II

ISO/IEC 27001 Certificate

Penetration-Test Summary

Incident Response Information

Business Continuity Information

Privacy Documentation

Subprocessor List

Data Flow Information

Security Policies

Do not ask for every artifact from every vendor.

Step 18 — Set Due Dates

Record:

Request	Owner	Due	Status
Questionnaire	Vendor	Aug 10	Open
SOC 2	Vendor	Aug 10	Received
ISO Certificate	Vendor	Aug 10	Received
Pentest	Vendor	Aug 15	Open

Track requests centrally.

Phase 7 — Security Questionnaire Review

Step 19 — Review Security Domains

Assess:

Security Governance

IAM

Encryption

Vulnerability Management

Secure Development

Logging & Monitoring

Incident Response

Business Continuity

Privacy

Third-Party Management

Step 20 — Validate Significant Responses

Questionnaire response:

MFA is implemented.

Ask:

For all users?

For administrators?

Any exclusions?

Which authentication methods?

How is coverage monitored?

For critical controls, request evidence.

Step 21 — Identify Unsupported Assertions

Example:

Vendor Response:
Annual penetration testing = Yes

Evidence:
None

Result:

Unverified

Do not mark a control effective without reasonable support.

Phase 8 — Review SOC Reports

Step 22 — Confirm Report Type

Record:

SOC 1 or SOC 2?

Type I or Type II?

Reporting Period?

Service Scope?

For security assurance, a relevant SOC 2 Type II report may provide significant information.

Step 23 — Review Scope

Confirm that the actual service being purchased is included.

A SOC report covering:

Vendor Payroll Platform

does not necessarily provide assurance over:

Vendor Cloud Security Product

Scope matters.

Step 24 — Review Auditor Opinion

Identify whether the opinion is:

• Unmodified.

• Qualified.

• Adverse, where applicable.

• Otherwise modified.

Understand the reason for any modification.

Step 25 — Review Exceptions

Create a list:

Exception	Impact	Vendor Response
MFA gap	High	Remediation
Late access removal	Medium	Closed

Determine whether exceptions are relevant to your use of the service.

Step 26 — Review CUECs

Identify Complementary User Entity Controls.

Example:

Vendor Provides:
SSO Capability

Customer Must:
Enable SSO

Create internal onboarding requirements from these responsibilities.

Step 27 — Review Subservice Organizations

Determine whether significant fourth parties are:

• Included.

• Carved out.

• Relevant to your service.

Document major dependencies.

Phase 9 — Review ISO Certification

Step 28 — Validate Certificate

Check:

Organization Name

Certification Standard

Certification Body

Scope

Issue Date

Expiration Date

Locations / Services

Step 29 — Review Scope Relevance

Ask:

Does the certification actually cover the service we are purchasing?

If not, do not treat the certificate as sufficient assurance.

Step 30 — Record Expiration

Set a future monitoring reminder in the vendor record.

Expired certifications should trigger review.

Phase 10 — Review Penetration-Test Evidence

Step 31 — Review Testing Details

Confirm:

Testing Date

Scope

Tester

Critical Findings

High Findings

Remediation Status

Retesting

Step 32 — Assess Freshness

A penetration test several years old may provide limited assurance for a rapidly changing SaaS environment.

Determine whether current testing is required.

Step 33 — Avoid Excessive Sensitive Detail

You may not need:

• Exploit code.

• Exact vulnerability locations.

• Credentials.

• Full technical report.

A suitable executive or assurance summary may be sufficient for TPRM.

Phase 11 — Review Identity & Access Management

Step 34 — Assess Vendor Workforce IAM

Review:

• MFA.

• Privileged access.

• Joiner/Mover/Leaver process.

• Access reviews.

• Password controls.

• Service accounts.

• Privileged monitoring.

Step 35 — Assess Customer IAM Capabilities

Determine whether the service supports:

• SSO.

• Federation.

• MFA.

• Role-based access.

• SCIM.

• Session controls.

• Audit logs.

Create onboarding requirements where appropriate.

Phase 12 — Review Data Protection

Step 36 — Assess Encryption

Confirm:

Encryption in Transit

Encryption at Rest

Key Management

Backup Encryption

Step 37 — Review Retention

Ask:

• How long is data retained?

• Can NorthStar define retention?

• Are backups included?

• What happens after termination?

Step 38 — Review Data Deletion

Determine:

How deletion is requested.

How long deletion takes.

Whether backups are handled.

Whether deletion can be certified.

Contractual requirements should reflect this.

Phase 13 — Review Vulnerability Management

Step 39 — Assess

Review:

• Scan frequency.

• Patch process.

• Critical remediation targets.

• External attack-surface monitoring.

• Dependency scanning.

• Secure coding.

Identify gaps based on risk.

Phase 14 — Review Logging and Monitoring

Step 40 — Evaluate Security Monitoring

Review:

Centralized Logging

SIEM

SOC Monitoring

Privileged Activity Monitoring

Alerting

Log Retention

Also determine what logs are available to NorthStar.

Phase 15 — Review Incident Response

Step 41 — Evaluate Vendor IR

Review:

• Incident response plan.

• Response team.

• Exercises.

• Customer communication.

• Forensic capability.

• Lessons learned.

Step 42 — Compare Notification Requirement

Vendor:

72 Hours

Enterprise requirement:

24 Hours

This creates a contractual issue requiring resolution.

Phase 16 — Review Business Continuity

Step 43 — Review Resilience

Assess:

BCP

DR Plan

RTO

RPO

Backup

Recovery Testing

Service Redundancy

Step 44 — Compare With Business Requirements

Example:

Business RTO:
4 Hours

Vendor RTO:
8 Hours

This is a business-risk decision, not just a security observation.

Phase 17 — Review Fourth Parties

Step 45 — Identify Critical Subprocessors

Ask:

Which cloud provider?

Which support provider?

Which payment provider?

Which analytics provider?

Which email provider?

Focus on material dependencies.

Step 46 — Evaluate Vendor Oversight

Determine whether the vendor:

• Performs due diligence.

• Maintains supplier inventory.

• Tracks high-risk suppliers.

• Includes contractual requirements.

• Monitors critical dependencies.

Your organization generally cannot directly assess every fourth party.

Phase 18 — Document Findings

Step 47 — Create the Findings Register

Use:

Finding ID

Domain

Finding

Evidence

Severity

Risk

Recommendation

Vendor Owner

Target Date

Status

Step 48 — Write Clear Findings

Weak:

MFA Issue

Strong:

One legacy privileged administrative account is not protected by MFA, increasing the risk of unauthorized privileged access if credentials are compromised.

Step 49 — Assign Severity

Consider:

Control Weakness

Data Sensitivity

Business Criticality

Threat Exposure

Compensating Controls

Duration

Scope

Severity should be risk based.

Phase 19 — Evaluate Vendor Responses

Step 50 — Review Remediation Commitments

Vendor response:

We plan to resolve this soon.

Insufficient.

Better:

Action:
Enable MFA for legacy administrator.

Owner:
Vendor IAM Team

Target:
30 September 2026

Evidence:
Updated configuration report

Require specific commitments for material findings.

Step 51 — Evaluate Compensating Controls

If the vendor cannot immediately fix a gap:

Primary Control Missing
       ↓
Compensating Control
       ↓
Residual Risk

Assess whether the alternative meaningfully reduces the same risk.

Phase 20 — Determine Residual Risk

Step 52 — Consider the Control Environment

Start with inherent risk.

Then consider:

• Security controls.

• Assurance quality.

• Open findings.

• Compensating controls.

• Contractual protections.

Inherent Vendor Risk
        ↓
Vendor Controls
        ↓
Assurance Evidence
        ↓
Open Findings
        ↓
Residual Risk

Step 53 — Assign Residual Risk

Possible ratings:

Low

Moderate

High

Critical

Document the rationale.

Example:

Residual Risk:
High

Reason:
Strong overall security program but four unresolved high-risk issues affecting privileged access, resilience, and incident notification.

Phase 21 — Determine the Risk Decision

Step 54 — Select an Outcome

Use:

Approve

Approve With Conditions

Escalate for Risk Acceptance

Reject

Step 55 — Approve

Appropriate where:

• Residual risk is acceptable.

• Required controls are in place.

• Contract requirements are satisfied.

• No material unresolved issues exist.

Step 56 — Approve With Conditions

Appropriate where:

• Vendor is needed.

• Residual risk is manageable.

• Remediation can occur within defined timeframes.

• Pre-go-live issues are addressed.

Example:

Decision:
Approve With Conditions

Step 57 — Escalate for Risk Acceptance

Use where residual risk exceeds standard tolerance but business leadership seeks to proceed.

Record:

Risk

Business Justification

Compensating Controls

Approver

Expiration Date

Review Date

Step 58 — Reject

Reject or pause onboarding where risk is unacceptable.

Examples:

No meaningful security program

Critical unresolved vulnerabilities

Refusal to meet incident requirements

Severe assurance gaps

Unacceptable regulatory exposure

Rejection should be evidence based.

Phase 22 — Contractual Security Review

Step 59 — Map Findings to Contract Terms

Contract requirements may include:

Security Controls

MFA

Encryption

Incident Notification

Data Location

Retention

Deletion

Subprocessors

BCP / DR

Audit Rights

Vulnerability Management

Step 60 — Involve Legal

GRC identifies security requirements.

Legal determines appropriate contractual language and legal acceptability.

Do not treat security analysts as legal counsel.

Phase 23 — Pre-Go-Live Approval Gate

Step 61 — Define Mandatory Preconditions

Example:

Before Go-Live:

Contract Executed

Security Approval Complete

Privacy Approval Complete

SSO Configured

MFA Configured

Critical Findings Resolved

Required Exceptions Approved

Do not allow onboarding to bypass mandatory approval gates.

Phase 24 — Vendor Onboarding

Step 62 — Configure Customer Security Controls

Examples:

Enable SSO

Enforce MFA

Configure RBAC

Disable Local Authentication Where Appropriate

Create Admin Roles

Enable Audit Logs

Secure API Credentials

Step 63 — Apply Least Privilege

Grant only required:

• User access.

• Administrative access.

• API permissions.

• Integration scopes.

Avoid default broad permissions.

Step 64 — Record Final Onboarding

Update vendor inventory:

Status:
Active

Tier:
Tier 1

Risk:
High

Approval:
Conditional

Next Review:
August 2027

Phase 25 — Track Open Vendor Findings

Step 65 — Create Remediation Tracker

ID	Finding	Owner	Due	Status
TPR-001	MFA Gap	Vendor	Sep 30	Open
TPR-002	DR Test	Vendor	Nov 30	In Progress

Step 66 — Review Material Findings

For critical/high-risk vendors:

Monthly or Quarterly

depending on severity.

Step 67 — Validate Closure

Vendor states:

Fixed.

Request appropriate evidence.

For example:

Updated SOC evidence

Configuration evidence

Updated penetration test

DR test report

Contract amendment

Validate before closure.

Phase 26 — Ongoing Monitoring

Step 68 — Monitor the Relationship

Monitor for:

Security Incidents

Breach Notifications

Certification Expiration

Service Outages

Acquisitions

Material Subprocessor Changes

Regulatory Actions

Critical Findings

High-risk vendors require stronger monitoring.

Step 69 — Record Monitoring Events

Example:

Vendor:
CloudCollab

Event:
Major cloud outage

Date:
15 October 2026

Impact:
4-hour service disruption

Action:
Resilience risk reassessment

Monitoring should feed into risk management.

Phase 27 — Periodic Reassessment

Step 70 — Set Frequency

Example:

Vendor Tier	Review Frequency
Tier 1	Annual
Tier 2	Annual
Tier 3	Every 2 Years
Tier 4	Event Driven

Adjust according to organizational methodology.

Step 71 — Refresh Evidence

At reassessment, update:

Questionnaire

SOC Report

ISO Certificate

Pentest

BCP / DR Evidence

Subprocessor List

Open Findings

Do not simply copy last year’s assessment.

Phase 28 — Trigger-Based Reassessment

Step 72 — Reassess After Material Events

Examples:

• Security breach.

• Material outage.

• New service.

• Increased data sensitivity.

• New privileged access.

• Major acquisition.

• Architecture change.

• New subprocessor.

• Regulatory change.

The risk profile may change before the scheduled review.

Phase 29 — Risk Tier Changes

Step 73 — Recalculate Inherent Risk

Example:

Original use:

Internal Collaboration

Later:

Customer Financial Data Added

Vendor risk may change from:

Tier 3

to:

Tier 1

Assessment requirements should increase accordingly.

Phase 30 — Vendor Incident Response

Step 74 — Receive Incident Notification

When a vendor incident occurs:

Vendor Notification
      ↓
Determine Exposure
      ↓
Security
      ↓
Privacy
      ↓
Legal
      ↓
Business Owner

Coordinate quickly.

Step 75 — Determine Impact

Ask:

Was our data affected?

Were our accounts affected?

Which systems?

Which users?

When did the incident begin?

Is the threat contained?

What actions must we take?

Step 76 — Reassess Vendor Risk

Significant incidents may:

Increase Residual Risk

Create Findings

Trigger Contractual Rights

Require Executive Escalation

Track vendor remediation.

Phase 31 — Vendor Offboarding

Step 77 — Initiate Offboarding

Trigger when:

• Contract ends.

• Vendor is replaced.

• Relationship terminated.

• Business service no longer required.

Step 78 — Remove Access

Verify:

SSO Disabled

Vendor Accounts Disabled

API Credentials Revoked

Tokens Revoked

VPN Removed

Privileged Access Removed

Step 79 — Recover or Delete Data

Confirm:

Required Data Exported

Vendor Data Deleted

Backups Addressed

Deletion Confirmed

Contractual requirements should support this.

Step 80 — Remove Integrations

Verify:

Webhooks

APIs

SCIM

Service Accounts

Network Connections

are removed.

Step 81 — Update Inventory

Set:

Status:
Terminated

Termination Date:
Recorded

Data Deletion:
Confirmed

Access Removal:
Confirmed

The third-party lifecycle is now complete.

Phase 32 — TPRM Evidence Management

Step 82 — Maintain Vendor Evidence

Suggested structure:

Vendor
│
├── Intake
├── Questionnaire
├── SOC
├── ISO
├── Pentest
├── Privacy
├── BCP
├── Contract
├── Findings
└── Approval

Evidence should be centrally controlled.

Step 83 — Apply Evidence Retention

Retention should align with:

• Contract requirements.

• Audit needs.

• Regulatory obligations.

• Corporate retention policy.

Protect sensitive vendor documentation.

Phase 33 — TPRM Metrics

Step 84 — Track Program Metrics

Useful metrics:

Active Vendors

Critical Vendors

Assessments Pending

Assessments Overdue

High-Risk Findings

Expired Assurance Reports

Open Exceptions

Vendor Incidents

Step 85 — Build a Dashboard

Example:

Metric	Result
Active Vendors	510
Tier 1 Vendors	39
Overdue Assessments	14
High Findings	11
Expired SOC Reports	5
Open Exceptions	8

Metrics should support decisions.

Phase 34 — TPRM Key Risk Indicators

Potential KRIs:

Critical Vendors Without Current Assessment

Critical Vendors Without Current SOC / ISO

Overdue High-Risk Vendor Findings

Expired Vendor Exceptions

Material Vendor Incidents

Critical Vendors Without Tested BCP

Rising KRIs should trigger attention.

Phase 35 — Escalation Criteria

Escalate when:

Critical Residual Risk

High Risk With No Remediation

Critical Finding Past Due

Vendor Refuses Security Requirement

Material Breach

Major Regulatory Concern

Critical Assurance Report Exception

Escalation may involve:

• CISO.

• CRO.

• Legal.

• Procurement leadership.

• Business executive.

• Risk committee.

Phase 36 — Conditional Approval Governance

Conditional approvals should include:

Conditions

Owner

Due Date

Evidence

Risk Approver

Expiration

Avoid:

Approved for now.

Conditional approval is a formal risk decision.

Phase 37 — Common Mistakes

Mistake 1 — Security Review After Purchase

Assessment should occur before significant commitment where possible.

Mistake 2 — Same Questionnaire for Every Vendor

Assessment depth should be risk based.

Mistake 3 — Treating Certifications as Automatic Approval

Always check scope and relevance.

Mistake 4 — Ignoring SOC Exceptions

Review exceptions and their impact.

Mistake 5 — Ignoring CUECs

Customer responsibilities must become internal controls.

Mistake 6 — No Business Criticality Assessment

Operational risk may be greater than data-security risk.

Mistake 7 — No Fourth-Party Consideration

Important dependencies may sit behind the vendor.

Mistake 8 — No Contractual Controls

Security expectations should be enforceable where appropriate.

Mistake 9 — Findings Without Tracking

Every material finding requires ownership and status.

Mistake 10 — No Reassessment

Vendor posture changes.

Mistake 11 — No Offboarding

Old accounts and credentials can remain active.

Mistake 12 — GRC Owns Everything

The business owns the relationship and risk. GRC coordinates and challenges.

Operational Checklist

Vendor Intake

• Vendor request documented.

• Business owner identified.

• Service understood.

• User population documented.

• Integrations documented.

• Expected go-live documented.

Data & Access

• Data types identified.

• Data classification assigned.

• Data flow documented.

• System access identified.

• Privileged access identified.

• Subprocessors identified.

Risk Tiering

• Business criticality assessed.

• Regulatory impact assessed.

• Inherent risk calculated.

• Vendor tier assigned.

• Due diligence requirements determined.

Due Diligence

• Questionnaire reviewed.

• Significant responses validated.

• SOC report reviewed.

• SOC scope verified.

• SOC exceptions reviewed.

• CUECs documented.

• ISO certificate validated.

• Penetration-test evidence reviewed.

• IAM assessed.

• Data protection assessed.

• Vulnerability management assessed.

• Incident response assessed.

• BCP / DR assessed.

• Fourth-party controls assessed.

Findings & Risk Decision

• Findings documented.

• Severity assigned.

• Vendor responses obtained.

• Compensating controls evaluated.

• Residual risk assessed.

• Contract requirements defined.

• Approval outcome recorded.

• Required risk acceptance approved.

Onboarding

• Contract complete.

• Mandatory findings resolved.

• SSO configured.

• MFA configured.

• Least privilege applied.

• Logging enabled.

• Vendor inventory updated.

Monitoring

• Open findings tracked.

• Reassessment date established.

• Assurance expiration dates tracked.

• Incident monitoring established.

• Material change triggers defined.

Offboarding

• Accounts removed.

• Credentials revoked.

• Integrations removed.

• Data returned.

• Data deletion confirmed.

• Vendor inventory updated.

Quick Reference — Vendor Approval Decision Tree

Vendor Requested
      ↓
Inherent Risk Assessment
      ↓
Risk Tier
      ↓
Required Due Diligence Complete?
   │
   ├── No → Hold Assessment
   │
   └── Yes
          ↓
Material Findings?
   │
   ├── No → Residual Risk Assessment
   │
   └── Yes
          ↓
Can Findings Be Remediated?
   │
   ├── Yes → Conditional Approval
   │
   └── No
          ↓
Residual Risk Acceptable?
   │
   ├── Yes → Risk Acceptance
   │
   └── No → Reject / Escalate

Runbook Deliverables

A completed vendor assessment package should contain:

01 — Vendor Intake Record

02 — Data Classification & Data Flow

03 — Inherent Risk Assessment

04 — Vendor Tiering Record

05 — Due Diligence Checklist

06 — Security Questionnaire Review

07 — SOC Review

08 — ISO Review

09 — Penetration-Test Review

10 — Control Assessment

11 — Vendor Findings Register

12 — Residual Risk Assessment

13 — Contract Security Requirements

14 — Approval / Risk Acceptance Record

15 — Remediation Tracker

16 — Monitoring Plan

17 — Offboarding Requirements

Runbook Success Criteria

The vendor is ready for final onboarding when:

Business ownership confirmed

Risk tier established

Required due diligence completed

Evidence reviewed

Material findings understood

Residual risk assessed

Contract requirements agreed

Required approvals obtained

Pre-go-live conditions completed

Monitoring requirements defined

Practical TPRM Mindset

A weak process asks:

Did the vendor complete the questionnaire?

A better process asks:

Does the available evidence support the vendor’s security claims?

A mature process asks:

Given the business use case, data, dependencies, assurance evidence, open findings, and contractual protections, is the residual third-party risk acceptable?

That is the purpose of Third-Party Risk Management.

Runbook Complete

You have now created a reusable operational process covering the full vendor lifecycle:

Request
   ↓
Intake
   ↓
Risk Tiering
   ↓
Due Diligence
   ↓
Evidence
   ↓
Findings
   ↓
Residual Risk
   ↓
Approval
   ↓
Onboarding
   ↓
Monitoring
   ↓
Reassessment
   ↓
Offboarding

Module 01 — GRC Fundamentals Complete

With this runbook, you have completed the full Module 01 — GRC Fundamentals sequence.

You have covered:

01 Introduction to GRC

02 Security Governance

03 Enterprise Risk Management

04 Risk Assessment Methodology

05 Policies, Standards & Procedures

06 Security Frameworks Overview

07 Control Design & Implementation

08 Control Testing & Effectiveness

09 Audit & Assurance Fundamentals

10 Compliance Management

11 Third-Party Risk Management

and completed the practical components:

Lab 01
Build an Enterprise Risk Register

Lab 02
Perform a Third-Party Security Risk Assessment

Runbook 01
Security Control Assessment & Evidence Collection

Runbook 02
Third-Party Risk Assessment & Vendor Onboarding

You now have the foundation required to move from general GRC concepts into framework-specific and compliance-specific implementation, including areas such as PCI DSS, SOC 1 / SOC 2, ISO/IEC 27001, cloud compliance, privacy, and other enterprise assurance programs.