Runbook 02 — SOC 2 Report Review, Exception Assessment & Vendor Assurance

Runbook Information

Field	Details
Runbook Type	Third-Party Risk / GRC Assurance
Primary Role	Third-Party Risk / GRC Analyst
Supporting Roles	Security, Legal, Privacy, Procurement, IAM, Application Owners
Primary Artifact	SOC 2 Report
Use Case	Vendor Assurance / Third-Party Risk
Execution Model	Onboarding + Periodic Reassessment
Primary Output	SOC 2 Vendor Assurance Decision

Purpose

This runbook provides a repeatable operational process for reviewing an external provider’s SOC 2 report and determining whether it provides sufficient assurance for the organization’s intended use of the service.

Use this runbook when:

Onboarding a new SaaS provider

Performing annual vendor reassessment

Reviewing an updated SOC 2 report

Evaluating vendor control exceptions

Reviewing a bridge letter

Assessing CUECs

Assessing carved-out subservice providers

Responding to customer or internal audit questions

Reassessing a critical vendor after an incident

The objective is not simply to determine:

Does the vendor have SOC 2?

The objective is to establish:

Correct Vendor
      ↓
Correct Service
      ↓
Correct Report
      ↓
Correct Scope
      ↓
Relevant TSC
      ↓
Current Assurance
      ↓
Acceptable Opinion
      ↓
Exceptions Understood
      ↓
CUECs Implemented
      ↓
Subservices Understood
      ↓
Residual Risk Accepted

Runbook Outcome

Successful execution should produce:

SOC Report Intake Record
      ↓
Scope Review
      ↓
TSC Coverage Review
      ↓
Period & Freshness Review
      ↓
Auditor Opinion Assessment
      ↓
Exception Register
      ↓
CUEC Mapping
      ↓
Subservice Review
      ↓
Additional Assurance Requests
      ↓
Residual Risk Assessment
      ↓
Vendor Decision
      ↓
Ongoing Monitoring

Operating Principles

Follow these principles throughout every SOC 2 vendor review:

SOC 2 is an assurance input, not a certification badge.
Confirm the exact service before reviewing controls.
Scope relevance is more important than the report label alone.
Type II provides operating history but does not guarantee zero exceptions.
An unmodified opinion does not mean every tested control passed.
Read the exceptions.
Read the CUECs.
Read the subservice organization section.
Review the report period and bridge gap.
Do not assume Security includes Confidentiality or Privacy.
Evaluate exception relevance to your own use case.
Customer-side controls can create more risk than vendor exceptions.
Use targeted follow-up instead of unnecessary duplicate questionnaires.
Document residual risk and the approval decision.

Phase 1 — Initiate the Vendor Assurance Review

Step 1 — Confirm Vendor Criticality

Determine how important the provider is to the organization.

Consider:

Data Sensitivity

Service Criticality

System Access

Integration Level

Operational Dependency

Customer Impact

Regulatory Impact

Possible classifications:

Critical

High

Medium

Low

Escalation

For Critical or High-risk providers, a deeper SOC review should normally be performed.

Output

Create:

01 Vendor Assurance Intake Record

Use:

Field	Value
Vendor
Service
Criticality
Data Processed
Integrations
Business Owner
Reviewer
Review Date

Step 2 — Define the Assurance Objective

Ask:

What risk are we trying to evaluate through this SOC report?

Possible objectives:

Security Assurance

Availability Assurance

Confidentiality Assurance

Processing Integrity Assurance

Privacy Assurance

Do not assume every SOC 2 report addresses every objective.

Phase 2 — Validate the SOC Report

Step 3 — Confirm SOC Report Type

Identify:

SOC 2 Type I

or

SOC 2 Type II

Type I

Use primarily for:

Point-in-Time Control Design

Control Implementation

Type II

Use for:

Control Design

Implementation

Operating Effectiveness
Across a Period

Review Question

Do we require evidence that controls operated over time?

If yes:

Type II Preferred

Step 4 — Validate Service Organization

Confirm the entity named in the report matches the provider being assessed.

Check:

Legal Entity

Parent Company

Subsidiary

Operating Entity

Escalate If

Contract is with:

Vendor Entity A

but SOC report covers:

Vendor Entity B

without clear relationship or scope.

Step 5 — Validate Product and Service Scope

Compare:

Service We Are Buying

against:

Service Covered by SOC Report

Example

Purchased:

Enterprise SaaS Platform

SOC report:

Consumer Application Only

Result:

Scope Gap

Output

Create:

02 SOC Scope Review Matrix

Use:

Component	Used by Organization	SOC Scope	Status

Step 6 — Identify Material Exclusions

Review excluded:

Products

Features

Regions

Environments

Subsidiaries

AI Services

Support Functions

Important

A vendor can legitimately have SOC 2 while the service your organization uses is outside the report.

Phase 3 — Review Trust Services Categories

Step 7 — Identify TSC Categories Included

Record whether the report covers:

Security

Availability

Processing Integrity

Confidentiality

Privacy

Security is always part of SOC 2.

Other categories depend on the engagement scope.

Output

Create:

03 Trust Services Category Review

Use:

TSC Category	Included	Required	Gap

Step 8 — Compare Against Business Requirements

Example:

Organization requires:

Security

Availability

Confidentiality

Report includes:

Security Only

Result:

Availability Assurance Gap

Confidentiality Assurance Gap

Additional assurance may be required.

Step 9 — Handle Privacy Separately When Necessary

If Privacy is outside the SOC report, consider:

Privacy Questionnaire

DPA

Data Flow Review

Subprocessor Review

Retention / Deletion Review

Do not write:

SOC 2 Covers Privacy

unless the Privacy Trust Services Category is actually included.

Phase 4 — Review Report Period & Freshness

Step 10 — Record Examination Period

Document:

Start Date

End Date

Report Issue Date

Current Review Date

Output

Create:

04 SOC Period & Freshness Register

Step 11 — Calculate the Bridge Period

Use:

Current Assessment Date
-
SOC Period End Date

Example:

SOC Ends:
31 December

Review:
31 March

Bridge period:

3 Months

Step 12 — Determine Whether Bridge Evidence Is Needed

If the report does not cover the current period, request where appropriate:

Bridge Letter

Material Change Statement

Incident Disclosure

Updated Assurance

Step 13 — Review Bridge Letter

A bridge letter may indicate whether management is aware of significant changes after the SOC period.

Remember:

Bridge Letter
≠
Independent Type II Testing

Use it as supplemental evidence.

Step 14 — Assess Freshness

Classify:

Current

Current With Bridge

Aging

Stale

Insufficient

Factors include:

Vendor Criticality

Bridge Duration

Major Changes

Security Incidents

New Products

Architecture Changes

Phase 5 — Review Auditor Opinion

Step 15 — Identify Opinion

Record:

Unmodified

Qualified

Adverse

Other / Insufficient Evidence

Output

Create:

05 Auditor Opinion Assessment

Step 16 — Unmodified Opinion

Generally positive.

But do not stop reviewing.

Continue to:

Test Results

Exceptions

CUECs

Subservices

Step 17 — Qualified Opinion

Determine:

Which Area?

Which Control?

Which Period?

Which TSC?

Does It Affect Our Use?

For critical services:

Escalate

before approval.

Step 18 — Adverse Opinion

Treat as a significant assurance concern.

Likely actions:

Executive Escalation

Additional Assurance

Risk Review

Potential Vendor Rejection

Phase 6 — Review Control Testing

Step 19 — Prioritize Relevant Controls

Do not review every control with identical depth.

Prioritize controls relevant to your vendor risk.

Common areas:

Identity & Access

Privileged Access

Change Management

Vulnerability Management

Logging

Incident Response

Availability

Backup & Recovery

Encryption

Vendor Risk

Data Protection

Step 20 — Review Auditor Test Procedure

For each important control, identify:

Population

Sample

Test Method

Exception Count

Auditor Result

Step 21 — Identify Control Exceptions

Examples:

Delayed Termination

Missing Change Approval

Overdue Vulnerability

Access Review Gap

Backup Failure

Incomplete Logging

Output

Create:

06 SOC Exception Register

Use:

ID	Control	Population	Sample	Exceptions	Risk

Phase 7 — Analyze Exceptions

Step 22 — Confirm the Exception

Ask:

What Requirement Failed?

What Actually Happened?

Was the Evidence Complete?

Was the Sample in Scope?

Step 23 — Determine Exception Rate

Example:

Sample:
40

Exceptions:
2

Record:

2 / 40

Do not assess significance based only on percentage.

Step 24 — Assess Exception Nature

Compare:

2 Non-Privileged Terminations
Delayed 1 Day

with:

2 Privileged Administrators
Active 30 Days

Same number of exceptions.

Very different risk.

Step 25 — Assess Customer Relevance

Use:

High

Medium

Low

Not Relevant

Ask:

Does this control protect our data?

Does this control affect our service?

Does this control affect availability?

Does this failure increase our exposure?

Step 26 — Determine Isolated vs Systemic

Potential isolated indicators:

Low Exception Count

Clear Specific Cause

No Repeat Pattern

Strong Compensating Controls

Potential systemic indicators:

High Exception Rate

Multiple Periods

Same Root Cause

Large Population Gap

Repeat Finding

Step 27 — Check Incident Impact

Ask:

Did the exception cause:

Security Incident?

Data Exposure?

Customer Outage?

Regulatory Event?

Actual impact can significantly change risk.

Phase 8 — Review Management Responses

Step 28 — Evaluate Response Quality

A strong management response should describe:

What Happened

Root Cause

Correction

Corrective Action

Weak

Staff were reminded.

Strong

Contractor identities were excluded from the HR integration. Contractor lifecycle events are now included in the automated identity termination workflow and monitored for delayed deactivation.

Step 29 — Determine Whether Validation Is Needed

Classify:

No Follow-Up

Targeted Confirmation

Remediation Evidence Required

Independent Assurance Required

Output

Create:

07 Management Response Assessment

Phase 9 — Review Complementary User Entity Controls

Step 30 — Identify All Relevant CUECs

Examples:

Customer User Management

Customer User Termination

MFA Configuration

Admin Reviews

API Credential Security

Security Configuration

Output

Create:

08 CUEC Mapping Register

Use:

CUEC	Internal Control	Owner	Status

Step 31 — Determine Applicability

Classify each:

Applicable

Not Applicable

Partially Applicable

Step 32 — Map to Internal Controls

Example:

CUEC:
Customer must disable terminated users

Internal control:

Joiner / Mover / Leaver Process

Step 33 — Identify CUEC Gaps

Example:

Vendor requires:

Customer MFA

Internal environment:

MFA Not Enabled

Result:

Customer-Side Control Gap

Important

The vendor’s SOC report can be strong while your implementation remains weak.

Step 34 — Escalate Unimplemented Critical CUECs

Examples:

MFA Not Enabled

Shared Admin Accounts

No SaaS Admin Review

API Keys Stored Insecurely

Treat these as internal risk conditions.

Phase 10 — Review Subservice Organizations

Step 35 — Identify Subservice Providers

Examples:

AWS

Azure

Google Cloud

Cloudflare

Payment Provider

Email Provider

Output

Create:

09 Subservice Organization Register

Step 36 — Identify Method

Record:

Inclusive

Carve-Out

Step 37 — Assess Carve-Out Relevance

Ask:

What Control Does Provider Perform?

How Critical Is That Control?

Does Vendor Assess the Provider?

Is Separate Assurance Available?

Step 38 — Review Provider Assurance Process

Look for vendor controls such as:

Annual Provider Review

SOC Review

Contract Review

Security Assessment

Risk Monitoring

Step 39 — Request Additional Provider Assurance When Necessary

Examples:

Relevant Cloud Provider SOC

ISO Certificate

Current Assurance Confirmation

Do not automatically collect every subservice provider report if risk does not justify it.

Phase 11 — Identify Assurance Gaps

Step 40 — Create Gap Register

Create:

10 Vendor Assurance Gap Register

Use:

Gap	Area	Risk	Required Action	Owner

Potential gaps:

Wrong Product Scope

Missing TSC Category

Stale SOC Report

No Bridge Evidence

Qualified Opinion

Material Control Exception

Unimplemented CUEC

Critical Carve-Out

Privacy Outside Scope

Remediation Not Validated

Phase 12 — Request Targeted Additional Assurance

Step 41 — Avoid Duplicating Existing Assurance

If the SOC report already provides strong evidence for a control:

Do Not Re-Ask 50 Questions
About the Same Control

Step 42 — Ask Only for Identified Gaps

Examples:

Updated Bridge Letter

Remediation Confirmation

Current SOC Report

Emergency Change Procedure

Vulnerability Closure Evidence

Subprocessor List

DPA

Privacy Information

Output

Create:

11 Additional Assurance Request Register

Use:

Request	Gap	Priority	Owner	Status

Phase 13 — Assess Residual Risk

Step 43 — Start With Inherent Risk

Examples:

High Data Sensitivity

Critical Service

Administrative Access

Deep Integration

Step 44 — Consider Vendor Assurance

Evaluate:

SOC Scope

Opinion

Control Testing

Exception Quality

Subservice Governance

Step 45 — Consider Customer Controls

Evaluate:

CUECs

Internal IAM

Configuration

Monitoring

Data Handling

Step 46 — Determine Residual Risk

Use:

Low

Low / Medium

Medium

Medium / High

High

Output

Create:

12 Residual Risk Assessment

Use:

Domain	Inherent Risk	Assurance	Customer Controls	Residual Risk

Phase 14 — Determine Vendor Decision

Step 47 — Use Standard Decision Categories

Recommended:

APPROVED

APPROVED WITH CONDITIONS

ADDITIONAL ASSURANCE REQUIRED

REJECTED

Step 48 — Approved

Use when:

Relevant Scope

Current Assurance

Acceptable Opinion

No Material Relevant Gaps

CUECs Implemented

Residual Risk Acceptable

Step 49 — Approved With Conditions

Use when risk is manageable but specific actions remain.

Examples:

Enable MFA Before Go-Live

Complete Privacy Review

Obtain Remediation Confirmation

Establish Quarterly Admin Review

Step 50 — Additional Assurance Required

Use when:

Report Stale

Wrong Scope

Qualified Opinion

Material Exception

Missing Critical TSC

Critical Carve-Out Unresolved

Step 51 — Rejected

Potential scenarios:

Unacceptable Residual Risk

Adverse Opinion

Systemic Critical Control Failure

Vendor Cannot Remediate

Mandatory Assurance Missing

Output

Create:

13 Vendor Assurance Decision

Phase 15 — Document the Decision

Step 52 — Write Executive Summary

Include:

Vendor

Service

SOC Type

Period

TSC Coverage

Auditor Opinion

Material Exceptions

CUECs

Subservices

Residual Risk

Decision

Step 53 — Document Conditions

Example:

Vendor Approved With Conditions

Conditions:

SSO/MFA Before Production

Vendor Remediation Confirmation

Privacy Review Complete

Quarterly Admin Review Established

Step 54 — Assign Condition Owners

Every condition should have:

Owner

Due Date

Status

Output

Create:

14 Vendor Assurance Condition Tracker

Phase 16 — Obtain Risk Acceptance

Step 55 — Escalate Residual Risk to Appropriate Owner

For high-criticality vendors, final approval may require:

CISO

Business Risk Owner

Privacy

Legal

Procurement

depending on organizational governance.

Step 56 — Document Acceptance

Record:

Risk

Conditions

Approver

Approval Date

Expiry / Review Date

Phase 17 — Production Go-Live Gate

Before approving go-live verify:

Required CUECs implemented.
MFA/SSO configured.
Administrator access reviewed.
API credentials protected.
Privacy review completed.
DPA executed where required.
Critical vendor exceptions addressed.
Required remediation evidence received.
Conditions accepted by risk owner.

If material conditions remain:

Do Not Mark Review Complete

Phase 18 — Periodic Vendor Reassessment

Step 57 — Track Next SOC Report

Record:

Expected Report Date

Current Report End Date

Next Review Date

Step 58 — Request Updated SOC Report

At reassessment review:

New Period

New Opinion

New Exceptions

New CUECs

New Subservices

Scope Changes

Step 59 — Compare Year Over Year

Create a delta review.

Ask:

New Exception?

Repeat Exception?

New Product?

New Subprocessor?

New TSC?

Control Removed?

Scope Reduced?

Step 60 — Identify Repeat Findings

Example:

2026:
Termination Exceptions

2027:
Termination Exceptions

Result:

Potential Systemic Weakness

Escalate.

Phase 19 — Trigger-Based Reassessment

Do not wait for annual review when there is a major event.

Trigger reassessment after:

Security Breach

Major Outage

Acquisition

New Subprocessor

Major Architecture Change

Material Product Change

Qualified SOC Opinion

Customer Data Expansion

Phase 20 — Vendor Incident Integration

If the vendor experiences an incident:

Incident
      ↓
Determine Service Impact
      ↓
Review SOC-Relevant Controls
      ↓
Reassess Residual Risk

Example:

Vendor breach caused by:

Delayed User Termination

and prior SOC report had termination exceptions.

This materially changes interpretation of the prior exception.

Phase 21 — Maintain Vendor Assurance Repository

Store:

SOC Reports

Bridge Letters

Certificates

Exception Reviews

CUECs

Subprocessor Lists

Privacy Evidence

Risk Decisions

Recommended structure:

Vendor-Assurance/
│
├── Vendor-Name/
│   ├── 2026/
│   │   ├── SOC2/
│   │   ├── Bridge/
│   │   ├── Exceptions/
│   │   └── Decision/
│   └── 2027/

SOC 2 Review Quick Decision Tree

Use:

Correct Vendor?
      │
      ├── No → Reject Report
      │
      └── Yes
             ↓
Correct Service?
      │
      ├── No → Additional Assurance
      │
      └── Yes
             ↓
Correct SOC Type?
      │
      ├── No → Assess Sufficiency
      │
      └── Yes
             ↓
Current Period?
      │
      ├── No → Updated Assurance / Bridge
      │
      └── Yes
             ↓
Required TSC Covered?
      │
      ├── No → Additional Assurance
      │
      └── Yes
             ↓
Opinion Acceptable?
      │
      ├── No → Escalate
      │
      └── Yes
             ↓
Material Exceptions?
      │
      ├── Yes → Risk Assessment
      │
      └── No
             ↓
CUECs Implemented?
      │
      ├── No → Customer Remediation
      │
      └── Yes
             ↓
Subservice Risk Acceptable?
      │
      ├── No → Additional Assurance
      │
      └── Yes
             ↓
Residual Risk Acceptable?
      │
      ├── Yes → APPROVE
      └── No → CONDITIONAL / REJECT

Exception Assessment Quick Check

For each exception ask:

Which control failed?
Which TSC area?
What was the population?
How large was the sample?
How many exceptions?
What was the severity of each deviation?
Was privileged access involved?
Was customer data involved?
Did a security incident occur?
Was the issue isolated?
Was the issue systemic?
Is the root cause clear?
Is corrective action defined?
Is remediation evidence required?
Does the exception materially affect our service?

CUEC Quick Check

For every CUEC ask:

Is it applicable?
Which internal control addresses it?
Who owns that control?
Is it implemented?
Is it operating?
Can we demonstrate it?
Is there a gap before go-live?

Subservice Quick Check

For every critical provider ask:

What service does it provide?
Inclusive or carve-out?
Which controls depend on it?
How critical is the dependency?
Does the vendor assess it?
Is separate assurance required?
Has anything materially changed?

SOC Freshness Quick Check

Ask:

What is the report end date?
What is today’s review date?
How large is the bridge period?
Is there a bridge letter?
Are material changes disclosed?
Has the vendor had a recent incident?
Is a newer SOC report expected?
Does vendor criticality justify stronger assurance?

Escalation Matrix

Critical Escalation

Escalate immediately for:

Adverse Opinion

Systemic Privileged Access Failure

Material Customer Data Exposure

Large-Scale Control Failure

Known Breach Related to SOC Exception

Escalate to:

CISO

Risk Owner

Legal

Privacy

Procurement

High Escalation

Examples:

Qualified Opinion

Critical Service Out of SOC Scope

Unimplemented MFA CUEC

Repeat High-Risk SOC Exception

Critical Carve-Out Without Assurance

Stale Report for Critical Vendor

Medium Escalation

Examples:

Short Bridge Period

Isolated Medium Exception

Minor CUEC Gap

Outdated Subprocessor Inventory

Vendor Assurance Dashboard

Recommended metrics:

Metric	Target
Critical Vendors With Current SOC	100%
Critical SOC Reviews Completed	100%
Unresolved High Assurance Gaps	0
Critical CUECs Implemented	100%
SOC Reports Past Freshness Threshold	0
Vendor Conditions Overdue	0
Repeat High-Risk Exceptions	0

Key Risk Indicators

Track:

Critical Vendors Without Current Assurance

Qualified SOC Opinions

Adverse SOC Opinions

High-Risk Control Exceptions

Unimplemented Critical CUECs

Critical Carve-Out Gaps

Stale Bridge Evidence

Repeat Vendor Findings

Master SOC 2 Vendor Review Checklist

Intake

Vendor identified.
service identified.
criticality assigned.
data categories identified.
integrations identified.

Report

SOC 2 confirmed.
Type I / Type II confirmed.
legal entity confirmed.
auditor identified.
examination period recorded.

Scope

exact service included.
production environment included.
APIs included where relevant.
customer data systems included.
material exclusions understood.

TSC

Security reviewed.
Availability assessed.
Processing Integrity assessed.
Confidentiality assessed.
Privacy assessed.

Freshness

report end date reviewed.
review date recorded.
bridge gap calculated.
bridge letter reviewed.
material changes assessed.

Auditor Opinion

opinion identified.
modified opinion escalated.
scope of modification understood.

Testing

relevant controls prioritized.
test procedures reviewed.
population understood.
sample understood.
exceptions recorded.

Exceptions

customer relevance assessed.
severity assessed.
systemic / isolated assessed.
management response reviewed.
remediation validation defined.

CUECs

CUECs identified.
internal controls mapped.
owners assigned.
implementation verified.
gaps remediated.

Subservices

providers identified.
inclusive / carve-out understood.
critical dependencies assessed.
provider assurance reviewed where required.

Additional Assurance

only relevant gaps requested.
privacy evidence requested where needed.
remediation evidence requested.
updated assurance requested where stale.

Residual Risk

inherent risk reviewed.
vendor assurance considered.
customer controls considered.
residual risk documented.

Decision

decision documented.
conditions defined.
owners assigned.
risk approval obtained.
production gate completed.

Monitoring

next SOC report date tracked.
reassessment scheduled.
trigger events defined.
repeat findings monitored.

GRC Analyst Operational Responsibilities

The analyst executing this runbook is responsible for coordinating:

Report Intake

Scope Validation

TSC Assessment

Freshness Review

Opinion Analysis

Exception Review

CUEC Mapping

Subservice Review

Additional Assurance

Residual Risk

Vendor Decision

Continuous Monitoring

The analyst creates the assurance chain:

Vendor Relationship
      ↓
Inherent Risk
      ↓
SOC Assurance
      ↓
Customer Controls
      ↓
Assurance Gaps
      ↓
Residual Risk
      ↓
Approval Decision

Runbook Success Criteria

This runbook has been executed successfully when the organization can clearly answer:

Which vendor did we review?

Which service?

Which SOC report?

Which period?

Which TSC categories?

Which auditor opinion?

Which exceptions?

Which CUECs apply to us?

Which providers are carved out?

What additional assurance did we require?

What residual risk remains?

Who accepted the risk?

Why was the vendor approved?

The strongest evidence of a mature third-party SOC review program is this:

The organization can explain why it trusts the vendor—not merely state that the vendor has a SOC 2 report.

Module Complete

You have now completed Module 04 — SOC 1 & SOC 2 Assurance.

Across this module, you moved from foundational SOC concepts through practical readiness, evidence collection, audit coordination, exception management, and third-party assurance.

You can now trace the complete assurance lifecycle:

SOC Fundamentals
      ↓
SOC 1 vs SOC 2
      ↓
Trust Services Criteria
      ↓
Security
      ↓
Availability
      ↓
Processing Integrity
      ↓
Confidentiality
      ↓
Privacy
      ↓
Type I vs Type II
      ↓
SOC Readiness
      ↓
Evidence Collection
      ↓
Audit Findings
      ↓
Formal Audit
      ↓
Vendor SOC Review

You also completed:

Lab 01
Perform a SOC 2 Readiness Assessment

Lab 02
Perform a SOC 2 Report Review & Exception Assessment

Runbook 01
SOC 2 Readiness, Evidence Collection & Audit Coordination

Runbook 02
SOC 2 Report Review, Exception Assessment & Vendor Assurance

What’s Next?

➡️ Next Module: 05 — PCI DSS

In the next module, you will move from assurance reporting into a prescriptive payment-card security standard.

You will learn how PCI DSS applies to:

Cardholder Data
      ↓
Cardholder Data Environment
      ↓
PCI Scope
      ↓
Network Segmentation
      ↓
Secure Configuration
      ↓
Account Data Protection
      ↓
Access Control
      ↓
Logging & Monitoring
      ↓
Vulnerability Management
      ↓
Security Testing
      ↓
Policies & Governance
      ↓
Assessment & Evidence

The module will also include dedicated PCI DSS labs and operational runbooks so learners can move from understanding PCI requirements to performing practical scope, control, evidence, and assessment activities.