11 Third-Party Risk Management

Modern enterprises rarely operate entirely on infrastructure and services they control themselves.

Organizations depend on:

Cloud providers.
SaaS platforms.
Managed service providers.
Software vendors.
Payment processors.
Consultants.
Contractors.
Data processors.
Security providers.
Business partners.
Supply-chain providers.

Every external dependency can introduce additional risk.

For example, a vendor may:

Store sensitive company information.
Process customer data.
Connect to corporate networks.
Receive privileged system access.
Host critical applications.
Provide security services.
Support business-critical processes.

Organizations therefore need a structured process for identifying and managing these risks.

This discipline is known as Third-Party Risk Management (TPRM).

Business Requirement
        ↓
Third Party Identified
        ↓
Risk Classification
        ↓
Due Diligence
        ↓
Security Assessment
        ↓
Risk Decision
        ↓
Contracting
        ↓
Onboarding
        ↓
Continuous Monitoring
        ↓
Reassessment
        ↓
Offboarding

For GRC professionals, TPRM is one of the most common practical responsibilities encountered in enterprise environments.

Learning Objectives

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

Explain third-party risk.
Understand the purpose of TPRM.
Differentiate vendors, third parties, and fourth parties.
Build and maintain a third-party inventory.
Classify vendors based on inherent risk.
Perform vendor risk tiering.
Conduct security due diligence.
Develop and review security questionnaires.
Review SOC reports.
Review ISO certifications.
Evaluate penetration-testing evidence.
Assess privacy and data-protection considerations.
Evaluate business continuity and resilience.
Identify fourth-party dependencies.
Understand contractual security requirements.
Manage vendor findings and remediation.
Manage vendor risk exceptions.
Perform periodic reassessments.
Understand continuous vendor monitoring.
Manage vendor offboarding.
Build meaningful TPRM metrics and dashboards.

1. What Is a Third Party?

A third party is an external organization or individual that provides products or services to the enterprise.

Examples include:

Cloud Provider

SaaS Provider

Payment Processor

Managed Security Provider

Consultant

Contractor

Software Vendor

Data Processor

Third parties may have different levels of access to enterprise systems and information.

2. What Is Third-Party Risk?

Third-party risk is the possibility that an external relationship introduces adverse consequences to the organization.

Risk may arise from:

Cybersecurity weaknesses.
Data breaches.
Privacy failures.
Operational outages.
Regulatory violations.
Financial instability.
Supply-chain compromise.
Poor business continuity.
Concentration risk.
Contractual failures.

The organization may outsource a service.

It does not automatically outsource accountability for the associated risk.

3. What Is TPRM?

Third-Party Risk Management is the structured process used to identify, assess, monitor, and manage risks associated with external organizations.

A mature TPRM lifecycle looks like:

Identify
   ↓
Classify
   ↓
Assess
   ↓
Decide
   ↓
Contract
   ↓
Onboard
   ↓
Monitor
   ↓
Reassess
   ↓
Offboard

TPRM should cover the entire vendor relationship.

4. Why Third-Party Risk Matters

Consider a highly secure organization using an insecure SaaS provider.

Enterprise
    ↓
Sensitive Data
    ↓
SaaS Provider
    ↓
Security Breach

The enterprise may still experience:

Data exposure.
Regulatory consequences.
Customer impact.
Business interruption.
Reputational damage.

Your organization’s security posture is therefore partly dependent on the security of its external ecosystem.

5. Third-Party Inventory

Organizations should maintain a centralized inventory of third parties.

Example:

Vendor	Service	Owner	Data	Criticality
Vendor A	CRM	Sales	Customer	High
Vendor B	Payroll	HR	Employee	High
Vendor C	Marketing	Marketing	Public	Low
Vendor D	Cloud Hosting	IT	Production	Critical

Without an inventory, organizations may not know where their information or dependencies exist.

6. Shadow Vendors

Employees may adopt services without formal approval.

Examples include:

AI applications.
File-sharing platforms.
SaaS productivity tools.
Browser extensions.
Development tools.

These can become shadow third parties.

Employee
   ↓
Unapproved SaaS
   ↓
Corporate Data Uploaded
   ↓
Unknown Third-Party Risk

Procurement and technical controls should help identify these services.

7. Business Owner

Every vendor should have an internal business owner.

The business owner should understand:

Why the service is required.
What business process depends on it.
Which information is involved.
How critical the service is.
Whether the relationship is still required.

GRC assesses risk but does not normally own the business relationship.

8. Inherent Vendor Risk

Before evaluating vendor controls, determine the risk naturally associated with the relationship.

This is inherent risk.

Factors may include:

Data Sensitivity
      +
System Access
      +
Business Criticality
      +
Transaction Volume
      +
Regulatory Impact
      +
Service Dependency
      =
Inherent Vendor Risk

9. Vendor Risk Tiering

Organizations commonly classify vendors into tiers.

Example:

Tier 1 — Critical

Tier 2 — High

Tier 3 — Moderate

Tier 4 — Low

Assessment requirements can then be based on tier.

10. Critical Vendor

A vendor may be critical if it:

Hosts production infrastructure.
Processes highly sensitive information.
Provides essential business services.
Has privileged network access.
Supports critical security operations.
Would cause major disruption if unavailable.

Critical vendors should receive stronger due diligence.

11. Low-Risk Vendor

Consider a vendor supplying office furniture.

If it:

Has no system access.
Processes no sensitive data.
Provides no critical service.

a 300-question cybersecurity assessment may be unnecessary.

This demonstrates risk-based TPRM.

12. Vendor Tiering Questionnaire

Before detailed assessment, ask questions such as:

Will the vendor process personal data?

Will it process financial data?

Will it access production systems?

Will it receive privileged access?

Will it host business-critical workloads?

Will it connect to our network?

Would vendor failure interrupt critical operations?

Is the service regulated?

Responses determine assessment depth.

13. TPRM Assessment Model

A scalable model might look like:

Vendor Identified
       ↓
Inherent Risk Assessment
       ↓
       ├── Low → Basic Due Diligence
       │
       ├── Medium → Standard Assessment
       │
       ├── High → Enhanced Assessment
       │
       └── Critical → Enhanced + Independent Assurance

Not every vendor requires identical assessment.

14. Security Due Diligence

Security due diligence evaluates whether the vendor maintains appropriate safeguards.

Areas commonly assessed include:

Governance.
IAM.
Encryption.
Vulnerability management.
Security monitoring.
Incident response.
Application security.
Cloud security.
Privacy.
Business continuity.
Third-party management.

15. Security Questionnaire

A vendor security questionnaire may ask:

Do administrators use MFA?

Is customer data encrypted at rest?

Is customer data encrypted in transit?

Are vulnerabilities regularly scanned?

Are penetration tests performed?

Is security logging centralized?

Does the vendor maintain an incident response plan?

Are backups tested?

Are subcontractors assessed?

Questionnaires help collect structured information.

16. Questionnaire Limitations

A vendor can answer:

Yes, we use MFA.

But that does not tell you:

Whether every administrator is covered.
Whether exceptions exist.
Whether MFA is phishing resistant.
Whether legacy systems bypass it.

Questionnaires are useful but should not automatically be treated as proof.

17. Evidence-Based Due Diligence

For higher-risk vendors, request supporting evidence.

Examples:

SOC reports.
ISO certificates.
Penetration-test summaries.
Security policies.
Business continuity test results.
Privacy documentation.
Architecture information.
Vulnerability-management evidence.

Assessment depth should remain proportional to risk.

18. SOC Report Review

SOC reports can provide useful independent assurance.

However, GRC should not simply record:

SOC 2 Available = Yes

The report itself should be reviewed.

19. SOC Review Questions

When reviewing a SOC report, consider:

Which service is covered?

What period is covered?

Which Trust Services Criteria apply?

Were exceptions identified?

What did management say about exceptions?

Which subservice organizations are used?

Are complementary user entity controls listed?

Is the report current?

These details matter.

20. Complementary User Entity Controls

SOC reports may identify controls that the customer must implement.

These are commonly called Complementary User Entity Controls.

Example:

Vendor Control:
MFA capability provided.

Customer Responsibility:
Customer must enable MFA for administrators.

If the customer fails to enable MFA, vendor assurance alone does not solve the risk.

21. SOC Exceptions

Suppose the auditor identifies:

Five terminated vendor employees retained system access beyond the required period.

GRC should evaluate:

Was customer data affected?
Was the relevant service affected?
Has remediation occurred?
What residual risk remains?

A SOC report with exceptions is not automatically unacceptable.

22. Bridge Letters

A SOC report may not cover the entire period required by the organization.

A vendor may provide a bridge letter covering the gap between the report period and current date.

The organization should evaluate whether this provides sufficient assurance for its needs.

23. ISO Certification Review

A vendor may provide an ISO/IEC 27001 certificate.

GRC should verify:

Certification Body

Certificate Validity

Certification Scope

Locations Covered

Services Covered

Expiration Date

A certificate should not automatically be assumed to cover every service the vendor offers.

24. Statement of Applicability

Where appropriate, organizations may review information concerning the vendor’s Statement of Applicability.

This helps understand which controls have been selected within the vendor’s ISMS.

25. Penetration-Test Review

Higher-risk vendors may provide penetration-test summaries.

Review:

Testing date.
Scope.
Testing provider.
Significant findings.
Remediation status.
Retesting.

Avoid requesting unnecessary sensitive exploit details when a suitable assurance summary is sufficient.

26. Vulnerability Management

Vendor assessment may examine:

Scanning Frequency

Patch Management

Remediation SLAs

Critical Vulnerability Handling

External Attack Surface

Dependency Management

Weak vulnerability management may increase supply-chain risk.

27. Identity & Access Management

Assess:

MFA.
Privileged access.
Access approvals.
Access reviews.
Termination.
Service accounts.
Authentication standards.

Privileged vendor access to enterprise environments deserves additional scrutiny.

28. Vendor Remote Access

Example:

Vendor Engineer
      ↓
Remote Connection
      ↓
Production Environment

Controls may include:

MFA

PAM

Time-Limited Access

Approval

Session Recording

Monitoring

Third-party privileged access should be tightly governed.

29. Data Protection Assessment

Understand what information the vendor receives.

Questions include:

What data?

Why is it required?

Where is it stored?

How is it encrypted?

Who can access it?

How long is it retained?

How is it deleted?

Data flow should be understood before onboarding.

30. Data Classification

Vendor assessment should consider data classification.

Example:

Public
      ↓
Internal
      ↓
Confidential
      ↓
Restricted

Higher classifications usually require stronger assessment.

31. Data Location

Organizations may need to know:

Storage country.
Processing locations.
Backup locations.
Support-access locations.
Subprocessor locations.

This can affect regulatory and contractual obligations.

32. Privacy Assessment

Where personal information is involved, privacy review may consider:

Processing purpose.
Data categories.
Data subjects.
Legal basis.
Retention.
International transfers.
Subprocessors.
Breach notification.

Privacy and security reviews often work together.

33. Business Continuity Assessment

Security is not the only concern.

A vendor outage may create significant operational risk.

Assess:

Business Continuity Plan

Disaster Recovery Plan

Recovery Time Objective

Recovery Point Objective

Backup Strategy

Testing Frequency

34. Vendor Concentration Risk

An organization may depend heavily on one provider.

Example:

CRM
Email
Identity
Analytics
Collaboration
        ↓
Same Provider

A significant outage could affect multiple critical services.

This is concentration risk.

35. Geographic Concentration

Several critical vendors may also depend on the same:

Cloud region.
Data center.
Country.
Telecommunications provider.

This creates hidden concentration risk.

36. Fourth-Party Risk

Your vendor may depend on other organizations.

Your Organization
       ↓
Vendor
       ↓
Vendor's Vendor

The vendor’s vendor is often referred to as a fourth party.

37. Example Fourth Party

Your Organization
       ↓
SaaS Provider
       ↓
Cloud Provider

If the cloud provider fails, the SaaS service may also fail.

Understanding critical dependencies is therefore important.

38. Fourth-Party Assessment

Organizations usually cannot directly assess every fourth party.

Instead, they may evaluate whether the primary vendor:

Maintains a supplier-risk program.
Performs due diligence.
Monitors critical suppliers.
Maintains contractual controls.
Tracks concentration risk.

This creates scalable oversight.

39. Software Supply-Chain Risk

Modern software vendors depend on:

Open-Source Libraries

Package Registries

CI/CD Platforms

Cloud Providers

Development Tools

Compromise within these dependencies may affect customers.

Vendor security assessment increasingly includes supply-chain practices.

40. Contractual Security Controls

Security requirements should be included in contracts where appropriate.

Examples include:

Security safeguards.
Encryption.
Access control.
Incident notification.
Vulnerability remediation.
Audit rights.
Data deletion.
Subprocessor requirements.
Business continuity.
Termination requirements.

Contracts help convert expectations into enforceable obligations.

41. Incident Notification

A contract may require:

Vendor must notify the organization within a defined period following discovery of a security incident affecting company information.

The notification timeline should align with business and regulatory requirements.

42. Right to Audit

Some contracts include:

Right to Audit

This may allow the organization to:

Request evidence.
Conduct assessments.
Review assurance reports.
Perform audits under specified conditions.

The exact terms should be defined contractually.

43. Data Return and Deletion

Contracts should address what happens when the relationship ends.

Contract Ends
      ↓
Data Returned
      ↓
Vendor Copies Deleted
      ↓
Access Revoked
      ↓
Deletion Confirmed

Without this, sensitive information may remain indefinitely.

44. Vendor Risk Findings

Assessment may identify weaknesses.

Example:

Finding:
Administrative MFA is incomplete.

Severity:
High

Vendor Response:
Migration scheduled.

Target:
30 November

The finding should be tracked.

45. Vendor Finding Register

ID	Vendor	Finding	Severity	Target
VR-001	Vendor A	MFA gap	High	Nov
VR-002	Vendor B	Old pentest	Medium	Dec
VR-003	Vendor C	No DR test	High	Jan

This provides centralized visibility.

46. Vendor Remediation

Possible decisions include:

Accept Vendor
      ↓
Accept with Remediation
      ↓
Require Compensating Controls
      ↓
Escalate Risk
      ↓
Reject Vendor

Not every issue requires rejecting the vendor.

47. Residual Vendor Risk

After evaluating vendor controls:

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

The organization decides whether the residual risk is acceptable.

48. Vendor Risk Acceptance

If significant risk remains, formal approval may be required.

Example:

High Residual Risk
      ↓
Business Justification
      ↓
Compensating Controls
      ↓
Risk Owner Approval
      ↓
Expiration / Review

GRC should document the decision.

49. Vendor Exceptions

A vendor exception should include:

Risk.
Requirement not met.
Business justification.
Compensating controls.
Approver.
Remediation commitment.
Expiration date.

Exceptions should be monitored.

50. Vendor Onboarding

Once approved, onboarding may include:

Contract Signed
      ↓
Security Requirements Confirmed
      ↓
Accounts Provisioned
      ↓
Integration Configured
      ↓
Data Sharing Approved
      ↓
Vendor Added to Inventory

Security approval should occur before sensitive access or data sharing begins.

51. Vendor Monitoring

Vendor risk does not end after onboarding.

Vendors change.

They may:

Change infrastructure.
Acquire companies.
Change subprocessors.
Experience breaches.
Lose certifications.
Introduce new services.
Change data locations.

Ongoing monitoring is therefore necessary.

52. Continuous Monitoring

Monitoring may include:

Security Incidents

Certification Status

External Security Signals

Financial Health

Regulatory Actions

Service Availability

Material Business Changes

Critical vendors may receive closer monitoring.

53. Periodic Reassessment

Vendors should be reassessed based on risk.

Example:

Critical:
Annual

High:
Annual

Moderate:
Every 2 Years

Low:
Event Driven

Actual frequency depends on organizational methodology.

54. Trigger-Based Reassessment

Do not always wait for the scheduled review.

Reassess when:

Vendor experiences a breach.
Service changes significantly.
New sensitive data is introduced.
Vendor receives privileged access.
Vendor is acquired.
Critical subprocessor changes.
Regulatory requirements change.

These are material risk events.

55. Vendor Breach Response

Suppose a critical SaaS provider announces a breach.

TPRM may initiate:

Incident Identified
      ↓
Determine Exposure
      ↓
Identify Data Affected
      ↓
Coordinate Security / Privacy / Legal
      ↓
Evaluate Vendor Response
      ↓
Assess Residual Risk
      ↓
Track Remediation

Third-party incidents require coordinated response.

56. Offboarding

Vendor relationships eventually end.

Offboarding should verify:

Accounts disabled.
Network access removed.
API keys revoked.
Credentials rotated where necessary.
Data returned.
Data deleted.
Integrations removed.
Assets returned.
Inventory updated.

57. Offboarding Risk

A forgotten vendor account can become an attack path.

Contract Ends
      ↓
Vendor Account Remains
      ↓
Credentials Compromised
      ↓
Unauthorized Access

Vendor lifecycle controls must include termination.

58. Vendor Inventory Status

Useful statuses include:

Proposed

Assessment

Approved

Active

Under Review

Suspended

Terminated

This makes lifecycle management easier.

59. TPRM Metrics

Useful metrics may include:

Total active vendors.
Critical vendors.
Vendors awaiting assessment.
High-risk findings.
Overdue reassessments.
Expired assurance reports.
Open exceptions.
Vendor incidents.

Metrics should help identify risk.

60. Example TPRM Dashboard

Metric	Result
Active Vendors	485
Critical Vendors	42
Assessments Due	31
High-Risk Findings	9
Overdue Remediation	6
Expired Assessments	14

Leadership should receive risk context alongside numbers.

61. Key Risk Indicators

Useful KRIs include:

Critical Vendors Without Current Assessment

High-Risk Vendor Findings

Expired Vendor Exceptions

Critical Vendors Without BCP Evidence

Vendor Security Incidents

These indicate increasing third-party exposure.

62. Procurement Integration

TPRM should integrate with procurement.

Weak process:

Contract Signed
      ↓
Vendor Starts Processing Data
      ↓
Security Learns About Vendor

Better process:

Business Request
      ↓
Procurement
      ↓
Risk Tiering
      ↓
Security / Privacy Assessment
      ↓
Contract Review
      ↓
Approval
      ↓
Purchase

Security assessment should occur early.

63. Vendor Intake Workflow

A practical workflow:

Business Owner
      ↓
Vendor Intake Form
      ↓
Procurement
      ↓
TPRM
      ↓
Privacy
      ↓
Legal
      ↓
Security
      ↓
Approval

Not every team must review every vendor; routing should be risk based.

64. TPRM and Compliance

Third-party management is often required by:

Security standards.
Privacy requirements.
Customer contracts.
Regulatory expectations.

TPRM therefore connects:

Enterprise Risk
      +
Cybersecurity
      +
Compliance
      +
Procurement
      +
Privacy
      +
Legal

65. Common TPRM Mistakes

Common mistakes include:

Assessing every vendor identically.
Failing to maintain a vendor inventory.
Assessing vendors after contracts are signed.
Relying only on questionnaires.
Accepting SOC reports without reviewing scope.
Accepting ISO certificates without checking validity.
Ignoring fourth parties.
Ignoring business continuity.
Failing to track remediation.
Allowing exceptions to expire unnoticed.
Failing to reassess vendors.
Forgetting vendor offboarding.
Focusing only on cybersecurity while ignoring operational risk.

66. Practical Scenario — SaaS Vendor

A business team wants to purchase a SaaS platform.

The service will:

Store Customer Data

Integrate With Corporate Identity

Support 1,500 Employees

Process Confidential Information

Initial risk tier:

HIGH

67. Due Diligence

GRC requests:

Security Questionnaire

SOC 2 Type II

ISO 27001 Certificate

Penetration-Test Summary

Business Continuity Information

Privacy Documentation

Subprocessor List

68. Assessment Findings

Review identifies:

Finding 1:
MFA available but not enforced internally.

Severity:
High

Finding 2:
Penetration test 18 months old.

Severity:
Medium

Finding 3:
No documented annual DR exercise.

Severity:
High

These findings require risk evaluation.

69. Risk Decision

The business considers the vendor important.

GRC recommends:

Conditional Approval

Conditions:

MFA remediation within 60 days

Updated penetration test within 90 days

DR exercise within 120 days

Contractual commitments are obtained.

70. Monitoring

GRC tracks:

Finding
   ↓
Vendor Action
   ↓
Evidence
   ↓
Validation
   ↓
Closure

This is practical TPRM.

71. Vendor Review Checklist

For a significant vendor, ask:

What service is being provided?
Who owns the relationship?
What information will the vendor process?
How sensitive is the information?
Will the vendor access enterprise systems?
Will privileged access be required?
Is the service business critical?
Which regulations apply?
Which countries are involved?
Which fourth parties support the service?
What independent assurance exists?
What security findings exist?
What contractual protections exist?
What residual risk remains?
Who accepts that risk?
How often should the vendor be reassessed?
How will the vendor be offboarded?

72. GRC Professional Responsibilities

As a GRC professional, you may:

Maintain the third-party inventory.
Perform inherent risk assessments.
Tier vendors.
Issue security questionnaires.
Review vendor evidence.
Review SOC reports.
Review ISO certificates.
Review penetration-test summaries.
Coordinate privacy assessments.
Assess business continuity.
Identify fourth-party risk.
Document findings.
Track vendor remediation.
Manage exceptions.
Coordinate risk acceptance.
Perform reassessments.
Monitor critical vendors.
Support vendor incident response.
Coordinate secure offboarding.
Report TPRM metrics.

These are highly practical GRC responsibilities.

73. TPRM Maturity Model

Organizations commonly evolve through stages.

Stage 1 — Reactive

Vendor Purchased
      ↓
Security Review Later

Stage 2 — Defined

Vendor Intake
      ↓
Questionnaire
      ↓
Approval

Stage 3 — Risk Based

Risk Tiering
      ↓
Assessment Depth
      ↓
Formal Risk Decision

Stage 4 — Integrated

Procurement
   +
Legal
   +
Privacy
   +
Security
   +
GRC

Stage 5 — Continuous

Vendor Inventory
      ↓
Continuous Monitoring
      ↓
Event Detection
      ↓
Dynamic Risk
      ↓
Reassessment

The objective is to manage vendor risk throughout the relationship rather than perform a one-time questionnaire.

Key Takeaways

Third parties can introduce significant cybersecurity, privacy, operational, compliance, and resilience risks.
Organizations should maintain an authoritative third-party inventory.
Vendor assessment depth should be based on inherent risk.
Critical vendors require stronger due diligence and monitoring.
Security questionnaires are useful but should not automatically be treated as proof.
SOC reports should be reviewed for scope, period, exceptions, subservice organizations, and customer responsibilities.
ISO certificates should be checked for scope and validity.
Penetration-test and resilience evidence may provide additional assurance.
Fourth-party dependencies can create hidden risk.
Security requirements should be incorporated into contracts where appropriate.
Vendor findings require remediation and tracking.
Significant residual risk may require formal acceptance.
Vendor monitoring should continue after onboarding.
Material changes should trigger reassessment.
Offboarding must remove access, integrations, credentials, and retained data.
TPRM works best when integrated with procurement, security, privacy, legal, and enterprise risk management.

Knowledge Check

Before moving to the practical exercises, make sure you can answer:

What is third-party risk?
What is TPRM?
What is inherent vendor risk?
Why should vendors be risk tiered?
What makes a vendor critical?
What is security due diligence?
What are the limitations of vendor questionnaires?
What should you examine in a SOC report?
What are Complementary User Entity Controls?
What should you verify on an ISO certificate?
Why might penetration-test evidence be useful?
What is fourth-party risk?
What is concentration risk?
Why are contractual security controls important?
What is residual vendor risk?
When might vendor risk acceptance be required?
What is continuous vendor monitoring?
What events should trigger vendor reassessment?
Why is vendor offboarding important?
What role does GRC play in TPRM?

What’s Next?

You have now completed the core lessons of Module 01 — GRC Fundamentals.

Next, you will move from theory into practical GRC work through two hands-on labs and two operational runbooks.

Next: Lab 01 — Build an Enterprise Risk Register

You will act as a GRC Analyst and build a practical enterprise cybersecurity risk register.

You will:

Identify business assets and risk scenarios.
Document threats and vulnerabilities.
Determine risk owners.
Assess likelihood and impact.
Calculate inherent risk.
Map controls.
Evaluate residual risk.
Define risk treatment.
Establish remediation actions.
Build executive risk reporting.

The final deliverable will resemble a risk register used in an enterprise GRC program.

Then: Lab 02 — Perform a Third-Party Security Risk Assessment

You will perform an end-to-end security assessment of a simulated SaaS vendor.

You will:

Complete vendor intake.
Determine inherent vendor risk.
Assign a vendor risk tier.
Review a security questionnaire.
Analyze vendor evidence.
Review a simulated SOC 2 report.
Evaluate ISO certification information.
Review penetration-testing evidence.
Identify control gaps.
Calculate residual risk.
Develop remediation requirements.
Make a vendor risk recommendation.

The final deliverable will be a Third-Party Risk Assessment Report suitable for presentation to a business or risk owner.

Operational Runbooks

After completing the labs, you will learn how GRC teams operationalize recurring governance activities.

Runbook 01 — Security Control Assessment & Evidence Collection

This runbook will provide a repeatable procedure for assessing enterprise security controls.

You will learn how to:

Identify Control
      ↓
Confirm Scope
      ↓
Identify Owner
      ↓
Request Evidence
      ↓
Validate Population
      ↓
Select Samples
      ↓
Test Control
      ↓
Document Exceptions
      ↓
Determine Effectiveness
      ↓
Track Remediation

The runbook will provide practical steps for control owners, evidence requests, testing documentation, exceptions, remediation, and retesting.

Runbook 02 — Third-Party Risk Assessment & Vendor Onboarding

This runbook will provide a repeatable enterprise workflow for evaluating and approving new third parties.

You will learn how to:

Vendor Request
      ↓
Business Intake
      ↓
Inherent Risk Assessment
      ↓
Vendor Tiering
      ↓
Due Diligence
      ↓
Evidence Review
      ↓
Findings
      ↓
Residual Risk
      ↓
Risk Decision
      ↓
Contract Requirements
      ↓
Approval
      ↓
Vendor Onboarding

The runbook will also define escalation paths for high-risk findings, exceptions, conditional approvals, and rejected vendors.

Module 01 Completion

After completing the lessons, labs, and runbooks, you will have practiced the foundational workflow of an enterprise GRC program:

Governance
    ↓
Risk Management
    ↓
Risk Assessment
    ↓
Policies & Standards
    ↓
Security Frameworks
    ↓
Control Design
    ↓
Control Testing
    ↓
Audit & Assurance
    ↓
Compliance Management
    ↓
Third-Party Risk Management
    ↓
Practical Labs
    ↓
Operational Runbooks

You will then be ready to progress into the next GRC module, where these foundations can be applied to specific enterprise frameworks, compliance standards, and assurance programs.