04 Perform a SOC 2 Readiness Review

Welcome to the fourth project in:

Module 11 — Enterprise GRC Transformation Project

In the previous projects, you moved through:

Enterprise Risk Assessment
        ↓
Build an ISMS
        ↓
ISO 27001 Gap Assessment

You learned how to evaluate an organization against an information security management system framework.

Now the organization has another business requirement.

Enterprise customers are asking:

Do You Have
a SOC 2 Report?

Sales teams are receiving security questionnaires.

Customers want assurance over:

Security

Availability

Confidentiality

Processing Integrity

Privacy

CloudNova therefore needs to understand whether its environment and control program are ready for a:

SOC 2
Examination

Your assignment is to perform a:

SOC 2
Readiness Review

Project Objective

Your objective is to determine whether CloudNova has the:

Governance

Processes

Controls

Ownership

Documentation

Evidence

Operational Consistency

needed to support a SOC 2 examination.

You will move through:

Business & Customer Requirements
             ↓
System Boundary
             ↓
Trust Services Categories
             ↓
Applicable Criteria
             ↓
Risk Assessment
             ↓
Control Mapping
             ↓
Control Ownership
             ↓
Evidence
             ↓
Design Assessment
             ↓
Implementation Review
             ↓
Operating Readiness
             ↓
Gap Identification
             ↓
Remediation
             ↓
SOC 2 Readiness

Mission Information

Project Type: SOC 2 Readiness Assessment
Difficulty: Intermediate to Advanced
Estimated Time: 4–6 Hours
Primary Role: GRC Analyst / Security Compliance Analyst
Supporting Roles: CISO / Security / IT / Engineering / HR / Legal / Privacy / Procurement / Internal Audit
Framework: AICPA Trust Services Criteria
Environment: Spreadsheet, documentation platform, ticketing system, evidence repository, or GRC platform
Deliverable: SOC 2 Readiness Assessment & Remediation Pack

Important: SOC 2 examinations are performed by appropriately licensed CPA firms. This project teaches readiness methodology and does not represent an actual SOC 2 examination or opinion.

Learning Objectives

By completing this project, you will learn how to:

understand the purpose of SOC 2.
distinguish SOC 1 from SOC 2.
understand SOC 2 Type I and Type II.
understand the Trust Services Criteria.
select relevant Trust Services Categories.
define a SOC 2 system boundary.
identify system components.
identify infrastructure and software dependencies.
identify people, procedures, and data.
understand complementary controls.
understand subservice organizations.
create a SOC 2 control matrix.
map internal controls to applicable criteria.
assign control ownership.
evaluate control design.
evaluate control implementation.
assess operating readiness.
identify control evidence.
create an evidence request list.
test representative control samples.
identify control gaps.
assess remediation priority.
prepare a readiness dashboard.
create a SOC 2 remediation roadmap.
prepare teams for examination readiness.

Scenario

CloudNova Technologies provides an enterprise SaaS platform hosted primarily in AWS.

Its customers include:

Financial Services

Healthcare

Technology Companies

Professional Services

Enterprise Customers

The sales team reports that major customers increasingly request:

SOC 2 Type II
Report

during procurement.

Some customers will not approve CloudNova without independent assurance over its security controls.

The CEO asks:

How Quickly
Can We Become
SOC 2 Ready?

The CISO asks:

Do Our Existing
ISO 27001 Controls
Support SOC 2?

The GRC team is assigned to perform a readiness review before engaging the organization’s external auditor.

Your Mission

Determine:

What Is
in Scope?

Which Criteria
Apply?

What Controls
Already Exist?

Who Owns
Those Controls?

Are Controls
Designed Properly?

Are They
Implemented?

Are They
Operating Consistently?

Can We
Produce Evidence?

What Gaps
Exist?

What Must
Be Fixed?

Required Deliverables

Create:

01 SOC 2 Readiness Scope

02 System Boundary

03 System Component Inventory

04 Trust Services Category Assessment

05 SOC 2 Control Matrix

06 Control Ownership Register

07 Evidence Request List

08 Control Testing Workbook

09 Gap Register

10 Finding Register

11 Remediation Plan

12 SOC 2 Readiness Dashboard

13 Management Readiness Report

14 Examination Preparation Checklist

15 SOC 2 Readiness Roadmap

Part 1 — Understand SOC 2

SOC 2 is an assurance reporting framework used to evaluate controls relevant to the:

Security

Availability

Processing Integrity

Confidentiality

Privacy

of systems used to provide services.

SOC 2 is based on the:

AICPA
Trust Services Criteria

Part 2 — Understand the Five Trust Services Categories

The five categories are:

Security

Availability

Processing Integrity

Confidentiality

Privacy

Part 3 — Security

Security focuses on protecting systems and information against unauthorized access, unauthorized disclosure, and other events that could compromise the system.

Think:

Access

Threat Protection

Monitoring

Change Management

Risk Management

Security Operations

Part 4 — Availability

Availability considers whether systems are available for operation and use as committed or agreed.

Think:

Capacity

Resilience

Monitoring

Backup

Recovery

Business Continuity

Part 5 — Processing Integrity

Processing Integrity addresses whether system processing is:

Complete

Valid

Accurate

Timely

Authorized

according to system objectives.

Part 6 — Confidentiality

Confidentiality focuses on information designated as confidential.

Think:

Classification

Access Restrictions

Encryption

Retention

Secure Disposal

Part 7 — Privacy

Privacy addresses personal information and how it is:

Collected

Used

Retained

Disclosed

Disposed

according to relevant commitments and criteria.

Part 8 — Security Is Foundational

For SOC 2, the Security category is based on the Common Criteria and is part of every SOC 2 examination.

Additional categories are selected based on:

Business Commitments

Customer Requirements

System Characteristics

Risk

Service Commitments

Part 9 — Do Not Select Categories for Marketing

Weak approach:

Let's Include
All Five
Because It
Looks Better

Professional approach:

Customer Commitments
        +
System Requirements
        +
Risk
        ↓
Relevant Trust
Services Categories

Every additional category can introduce additional criteria, controls, evidence, and examination effort.

Part 10 — Example CloudNova Selection

Suppose CloudNova determines that its enterprise SaaS commitments require:

Security

Availability

Confidentiality

Privacy may require separate evaluation depending on CloudNova’s privacy commitments and system responsibilities.

Processing Integrity may also be considered if commitments regarding processing completeness, validity, accuracy, timeliness, or authorization are material.

Part 11 — SOC 2 Type I vs Type II

A common source of confusion is:

Type I
vs
Type II

A Type I report addresses control design and implementation as of a specified date.

Conceptually:

Do Appropriate
Controls Exist
at This Point
in Time?

A Type II report additionally considers operating effectiveness over a specified period.

Conceptually:

Did Those
Controls Operate
Effectively Over
the Review Period?

Part 12 — Readiness for Type II

For Type II readiness, you need more than:

Policy Exists

You need controls that:

Are Designed
      ↓
Are Implemented
      ↓
Operate Consistently
      ↓
Generate Evidence
      ↓
Can Be Tested
Over Time

Part 13 — SOC 1 vs SOC 2

SOC 1 focuses on controls relevant to:

User Entities'
Internal Control
Over Financial Reporting

SOC 2 focuses on controls relevant to the applicable:

Trust Services
Criteria

Do not use the terms interchangeably.

Part 14 — Define the System

Before evaluating controls, define:

What System
Are We
Assessing?

This is one of the most important parts of readiness.

Part 15 — Define System Boundary

For CloudNova, the system might include:

Enterprise SaaS Platform

Production AWS Accounts

Kubernetes Clusters

Application Services

Databases

CI/CD Pipeline

GitHub

Identity Services

Monitoring

Security Tooling

Customer Support Systems

Part 16 — Identify Supporting Components

The system is not only technology.

Consider:

Infrastructure

Software

People

Procedures

Data

Part 17 — Infrastructure

Examples:

AWS

Kubernetes

Networks

Compute

Storage

Databases

Load Balancers

Part 18 — Software

Examples:

CloudNova Application

CI/CD Tooling

Security Platforms

Monitoring Platforms

Identity Platforms

Supporting SaaS

Part 19 — People

Include relevant:

Developers

SRE

Security

IT

Customer Support

Management

Contractors

Part 20 — Procedures

Examples:

Access Management

Change Management

Incident Response

Vulnerability Management

Backup

Recovery

Vendor Management

Part 21 — Data

Identify:

Customer Data

Authentication Data

Application Data

Logs

Backups

Configuration Data

Support Data

Part 22 — Create System Component Inventory

Use:

Component	Type	Owner	Purpose	In Scope
AWS Production	Infrastructure	Cloud	Hosting	Yes
Kubernetes	Infrastructure	Platform	Workloads	Yes
GitHub	Software/SaaS	Engineering	Source Code	Yes
Microsoft 365	SaaS	IT	Corporate Services	Review
SIEM	Security	SOC	Monitoring	Yes

Part 23 — Understand Subservice Organizations

CloudNova relies on external organizations such as:

AWS

Identity Providers

SaaS Providers

Payment Providers

Support Platforms

These may be:

Subservice
Organizations

depending on their role in delivering the system.

Part 24 — Determine Treatment of Subservice Organizations

Understand whether the system description uses an approach such as:

Carve-Out

or:

Inclusive

for relevant subservice organizations.

This decision should be made with the organization’s auditor and reporting strategy.

Part 25 — Complementary Subservice Organization Controls

CloudNova may depend on controls operated by service providers.

Example:

CloudNova
Uses AWS
      ↓
AWS Operates
Certain Physical
and Infrastructure
Controls

CloudNova must still understand its responsibilities under the shared-responsibility model.

Part 26 — Complementary User Entity Controls

Customers may also have responsibilities.

These may be described as:

Complementary
User Entity
Controls

For example:

Customer
Must Protect
Administrator
Credentials

Part 27 — Understand Entity-Level Controls

SOC 2 readiness is not only technical.

Evaluate enterprise controls around:

Governance

Ethics

Accountability

Risk Management

Communication

Monitoring

Part 28 — Start With Risk

Control design should follow:

Service Commitments
        ↓
System Requirements
        ↓
Risk
        ↓
Criteria
        ↓
Controls

not:

SOC 2 Checklist
        ↓
Create Random
Controls

Part 29 — Reuse the Enterprise Risk Assessment

CloudNova already identified risks including:

Privileged Account Compromise

Cloud Misconfiguration

Critical Vulnerabilities

Ransomware

Third-Party Compromise

Service Outage

Data Exposure

Software Supply-Chain Risk

These risks can help determine appropriate controls.

Part 30 — Build Control Matrix

Create:

Control ID

Control Name

Control Objective

Control Description

Applicable Criterion

Risk

Control Owner

Frequency

Evidence

Control Type

Status

Part 31 — Example Control

Control ID:
IAM-001

Control:
Privileged MFA

Objective:
Protect privileged
accounts from
unauthorized access.

Owner:
IAM Manager

Frequency:
Continuous

Evidence:
Identity configuration
and account reports

Part 32 — One Control Can Support Multiple Criteria

Avoid assuming:

One Criterion
=
One Control

An enterprise control may support multiple requirements.

Example:

Quarterly
Privileged Access Review

may support several security-related criteria.

Part 33 — Reuse Existing ISO Controls

CloudNova already has controls from its ISMS.

Instead of:

ISO Controls
+
Separate SOC 2 Controls

build:

Enterprise
Common Controls
        ↓
ISO 27001
Mapping
        +
SOC 2
Mapping

Part 34 — Common Control Framework

Example:

Internal Control
IAM-001
      ↓
ISO Mapping
      ↓
SOC 2 Mapping
      ↓
NIST Mapping
      ↓
Customer Requirement

This reduces duplicate control management.

Part 35 — Assess Control Design

For every control ask:

Would This Control,
If Performed
as Designed,
Address the
Relevant Risk?

Part 36 — Design Example

Risk:

Former Employee
Retains Access

Control:

HR Emails IT
When Someone
Leaves

This may work.

But ask:

Is It Timely?

Is It Complete?

Who Tracks It?

What Happens
If Email Is Missed?

Can It Be Proven?

Part 37 — Better Control Design

HR Termination
Record Created
      ↓
Automated Workflow
      ↓
Identity Access
Disabled
      ↓
Ticket Generated
      ↓
Completion Verified
      ↓
Exception Escalated

Part 38 — Assess Implementation

A well-designed control is not useful if:

Nobody
Implemented It

Verify:

Configuration

Procedure

Ownership

Workflow

Evidence

Part 39 — Assess Operating Readiness

For Type II preparation, ask:

Has the Control
Operated Consistently
Across the Intended
Period?

Part 40 — Example

Control:

Quarterly
Access Review

Evidence:

Q1 ✓

Q2 ✓

Q3 Missing

Q4 ✓

Conclusion:

Control Exists

Design May
Be Appropriate

Operation
Is Inconsistent

Part 41 — Define Control Frequency

Controls may operate:

Continuous

Daily

Weekly

Monthly

Quarterly

Annually

Event-Driven

Frequency affects evidence expectations and sampling.

Part 42 — Identify Control Owners

Every control should answer:

Who Is
Accountable
for This Control?

Examples:

IAM
→ Access Controls

Security Engineering
→ Vulnerability Controls

SOC
→ Monitoring

Engineering
→ Change Controls

HR
→ Personnel Controls

TPRM
→ Vendor Controls

BCM
→ Recovery Controls

Part 43 — Build Ownership Register

Control	Owner	Operator	Evidence Owner	Frequency
Privileged MFA	IAM	IAM	IAM	Continuous
Access Review	IAM	IAM	IAM	Quarterly
Vulnerability Scan	Security	Security	Security	Weekly
Vendor Review	TPRM	GRC	TPRM	Risk-Based

Part 44 — Establish Evidence Requirements

SOC 2 readiness requires:

Control
      ↓
Operation
      ↓
Evidence

Evidence should be produced through normal control operation.

Part 45 — Evidence Examples

Examples include:

Policies

System Configurations

System-Generated Reports

Tickets

Approvals

Logs

Access Reviews

Change Records

Incident Records

Training Records

Vendor Assessments

Recovery Tests

Meeting Minutes

Part 46 — Evidence Quality

Good evidence should be:

Relevant

Reliable

Complete

Accurate

Current

Traceable

Part 47 — Evidence Hierarchy

Depending on the control, stronger evidence often includes:

System-Generated
Evidence

rather than relying solely on:

Manual
Screenshots

Screenshots can still be useful, but they may require additional context and validation.

Part 48 — Build Evidence Request List

Example:

ID	Control	Evidence	Owner	Frequency	Status
E-001	IAM-001	MFA Export	IAM	Continuous	Ready
E-002	IAM-002	Access Review	IAM	Quarterly	Partial
E-003	VM-001	Scan Report	Security	Weekly	Ready
E-004	BCM-001	DR Test	BCM	Annual	Missing

Part 49 — Create Evidence Repository

Suggested:

SOC2-Evidence
│
├── Governance
├── Risk
├── IAM
├── Asset Management
├── Change Management
├── Vulnerability Management
├── Logging
├── Incident Response
├── Vendor Management
├── Business Continuity
├── HR
└── Privacy

Part 50 — Avoid Auditor-Specific Evidence Silos

Weak:

ISO Evidence

SOC 2 Evidence

Customer Evidence

Better:

Enterprise
Control Evidence
       ↓
Multiple
Assurance Uses

Part 51 — Evaluate Governance Controls

Review:

Security Governance

Roles & Responsibilities

Policies

Risk Management

Management Oversight

Control Monitoring

Part 52 — Evaluate Access Controls

Review:

User Provisioning

Authentication

MFA

Privileged Access

Access Reviews

Termination

Service Accounts

Access Exceptions

Part 53 — Evaluate Asset Management

Review:

Asset Inventory

Ownership

Classification

Lifecycle

Cloud Resources

Endpoints

Software

Part 54 — Evaluate Change Management

Review:

Change Request

Authorization

Testing

Approval

Deployment

Emergency Changes

Rollback

Part 55 — Example Change Workflow

Code Change
    ↓
Pull Request
    ↓
Peer Review
    ↓
Automated Testing
    ↓
Approval
    ↓
Deployment
    ↓
Logging

Part 56 — Test Change Samples

Select changes and verify:

Request

Approval

Testing

Reviewer

Deployment

Segregation

Traceability

Part 57 — Evaluate Vulnerability Management

Review:

Scanning

Prioritization

Remediation SLA

Exception Management

Validation

Reporting

Part 58 — Example Evidence

Scanner Report

Critical Finding

Ticket

Assigned Owner

Remediation

Rescan

Closure

Part 59 — Evaluate Security Monitoring

Review:

Logging

SIEM

Alerting

Triage

Escalation

Incident Creation

Retention

Part 60 — Test Monitoring

Select alerts and trace:

Security Event
      ↓
Alert
      ↓
Analyst Review
      ↓
Disposition
      ↓
Escalation
      ↓
Incident

Part 61 — Evaluate Incident Response

Review:

Incident Policy

Response Plan

Roles

Detection

Escalation

Communication

Investigation

Recovery

Lessons Learned

Part 62 — Test Incident Samples

Verify:

Incident Record

Severity

Timeline

Actions

Communication

Closure

Lessons Learned

Part 63 — Evaluate Vendor Management

Review:

Vendor Inventory

Risk Classification

Due Diligence

Security Assessment

Contract Requirements

Monitoring

Reassessment

Termination

Part 64 — Critical Vendors

Focus on providers that could materially affect:

Security

Availability

Confidentiality

Privacy

Processing

Part 65 — Evaluate Business Continuity

If Availability is in scope, review:

Business Impact Analysis

Recovery Requirements

Backup

Redundancy

Disaster Recovery

Testing

Capacity

Monitoring

Part 66 — Evaluate Backup Controls

Determine:

What Is Backed Up?

How Often?

Where?

How Is It Protected?

Is Restore Tested?

Who Reviews Failures?

Part 67 — Evaluate Recovery Testing

Evidence may include:

Test Plan

Participants

Scenario

Recovery Results

RTO Results

RPO Results

Failures

Lessons Learned

Remediation

Part 68 — Evaluate Confidentiality Controls

If Confidentiality is selected, evaluate areas such as:

Data Classification

Access Restrictions

Encryption

Data Transfer

Retention

Secure Disposal

Part 69 — Evaluate Privacy Controls

If Privacy is selected, evaluate the organization’s privacy commitments and applicable criteria across relevant personal-information lifecycle activities.

Potential areas include:

Notice

Choice / Consent

Collection

Use

Retention

Access

Disclosure

Quality

Monitoring

The exact assessment should follow the applicable Trust Services Criteria and organizational commitments.

Part 70 — Evaluate HR Controls

Review:

Background Screening

Security Agreements

Onboarding

Training

Role Changes

Termination

Confidentiality

Part 71 — Evaluate Security Awareness

Evidence may include:

Training Content

Employee Population

Completion Records

Reminders

Exceptions

Phishing Exercises

Part 72 — Evaluate Logical Access

Trace:

Employee
      ↓
Approved Role
      ↓
Access Request
      ↓
Approval
      ↓
Provisioning
      ↓
Periodic Review
      ↓
Modification
      ↓
Termination

Part 73 — Test Joiners

Select new employees.

Verify:

Request

Approval

Role

Access

Provisioning Date

Part 74 — Test Movers

Select employees who changed roles.

Verify:

Old Access

New Role

Required Access

Removed Access

Approval

Part 75 — Test Leavers

Select terminated personnel.

Verify:

Termination Date

Notification

Account Disablement

Privileged Access

Tokens

Devices

Part 76 — Evaluate Exceptions

Controls may have exceptions.

Examples:

MFA Exception

Vulnerability Exception

Emergency Change

Access Exception

Every exception should have appropriate:

Justification

Approval

Risk Evaluation

Compensating Control

Expiration

Review

Part 77 — Identify Readiness Gaps

Common gaps may include:

Missing Control

Weak Control Design

Control Not Implemented

Inconsistent Operation

Missing Evidence

Unclear Ownership

Missing Review

Unmanaged Exception

Incomplete Population

Missing Monitoring

Part 78 — Create Gap Register

Example:

Gap	Area	Issue	Risk	Priority
G-001	IAM	Access review missed	High	High
G-002	BCM	Restore testing incomplete	High	High
G-003	TPRM	Vendor reassessment overdue	Medium	Medium
G-004	HR	Training evidence incomplete	Medium	Medium

Part 79 — Write Strong Findings

Weak:

Access Review
Missing

Better:

The quarterly privileged
access review was not
completed during Q2.

Evidence was available
for Q1 and Q3, but
no evidence was available
for Q2.

Part 80 — Finding Structure

Use:

Criteria

Control

Condition

Evidence

Risk

Recommendation

Part 81 — Root Cause

Do not stop at:

Control
Failed

Ask:

Why Did
It Fail?

Part 82 — Example Root Cause

Gap:

Vendor Reviews
Overdue

Why?

No Reminder

Why?

No Central
Review Calendar

Why?

Vendor Governance
Not Integrated
Into GRC Workflow

Part 83 — Remediation

Better action:

Centralize Vendor Inventory
        ↓
Assign Risk Tier
        ↓
Define Review Frequency
        ↓
Automate Reminder
        ↓
Escalate Overdue Reviews
        ↓
Track Evidence

Part 84 — Build Remediation Register

Record:

Gap ID

Action

Owner

Priority

Dependencies

Target Date

Expected Evidence

Status

Retest Result

Part 85 — Do Not Close Gaps Too Early

Do not close because:

Policy
Created

Validate:

Control Designed
       ↓
Implemented
       ↓
Operated
       ↓
Evidence Generated
       ↓
Retested

Part 86 — Prepare for Observation Period

For a Type II examination, operating history matters.

A control introduced:

Yesterday

cannot demonstrate months of prior operation.

Therefore readiness planning must consider:

Control Implementation
        ↓
Stabilization
        ↓
Evidence Generation
        ↓
Operating Period
        ↓
Examination

The exact examination period and expectations should be coordinated with the CPA firm performing the engagement.

Part 87 — Create Control Calendar

Example:

Control	Frequency	Owner	Evidence
Access Review	Quarterly	IAM	Review Report
Vulnerability Scan	Weekly	Security	Scanner Report
Vendor Review	Risk-Based	TPRM	Assessment
DR Test	Annual	BCM	Test Report
Training	Annual	HR	Completion Report

Part 88 — Evidence Calendar

Track:

Control

Expected Date

Evidence Due

Owner

Collected

Reviewed

Exception

Part 89 — Continuous Evidence Readiness

Mature organizations move from:

Auditor Requests
Evidence
      ↓
Everyone Searches
for Files

to:

Control Operates
      ↓
Evidence Generated
      ↓
Evidence Stored
      ↓
Evidence Validated
      ↓
Audit Ready

Part 90 — Build Readiness Dashboard

Example:

SOC 2 READINESS

Controls Identified       75

Controls Implemented      69

Controls Operating        64

Evidence Ready            60

High Gaps                  5

Medium Gaps               11

Overdue Controls           3

Readiness Blockers         2

Values are illustrative.

Part 91 — Do Not Rely Only on a Percentage

Avoid:

SOC 2 Ready
92%

without explaining:

Which Controls
Are Missing?

Which Controls
Failed?

Which Evidence
Is Missing?

Which Gaps
Could Affect
the Examination?

Part 92 — Identify Readiness Blockers

Examples might include:

Undefined System Boundary

Incomplete Risk Assessment

Critical Controls Missing

Key Controls Not Operating

Insufficient Evidence

Major Access Weaknesses

No Vendor Governance

Untested Recovery

Actual significance depends on scope, criteria, control design, and the auditor’s evaluation.

Part 93 — Create Readiness Heat Map

Example:

Domain	Status
Governance	High
Risk Management	High
IAM	Medium
Change Management	High
Vulnerability Management	Medium
Monitoring	High
Incident Response	High
Vendor Risk	Medium
Business Continuity	Medium
Evidence Readiness	Medium

Part 94 — Prepare Management Report

Management wants to know:

Are We Ready?

What Are
the Biggest Gaps?

What Could
Delay the Examination?

What Must
Be Fixed?

Who Owns
the Work?

What Resources
Are Required?

When Can We
Begin the
Operating Period?

Part 95 — Executive Summary Structure

Create:

Objective

Scope

Trust Services Categories

System Boundary

Overall Readiness

Key Strengths

Critical Gaps

High-Risk Gaps

Evidence Readiness

Remediation Priorities

Resource Requirements

Recommended Timeline

Management Decisions

Part 96 — Example Executive Narrative

CloudNova has established
a substantial security
control environment through
its existing ISMS.

Many existing controls can
support SOC 2 requirements.

Readiness gaps remain in
privileged access reviews,
vendor monitoring,
recovery testing, and
evidence consistency.

These gaps should be
remediated and operating
evidence established before
progressing into the intended
Type II examination period.

Part 97 — Reuse ISO 27001 Work

Your previous project created:

ISO 27001
Control Environment

Now map it:

Enterprise Control
        ↓
ISO 27001
        +
SOC 2

Part 98 — Example Cross-Mapping

Risk:
Unauthorized Access
       ↓
Control:
IAM-001 MFA
       ↓
ISO Mapping
       ↓
SOC 2 Mapping
       ↓
Evidence:
Identity Report

Part 99 — One Control, Multiple Assurance Uses

The professional goal is:

One Control
      ↓
One Owner
      ↓
One Process
      ↓
One Evidence Source
      ↓
Multiple Frameworks

not:

ISO Control

SOC Control

Customer Control

NIST Control

all independently managed.

Part 100 — Build Common Control Library

Suggested domains:

GOV — Governance

RISK — Risk Management

IAM — Identity & Access

AST — Asset Management

CHG — Change Management

VM — Vulnerability Management

LOG — Logging & Monitoring

IR — Incident Response

TPRM — Third-Party Risk

BCM — Business Continuity

HR — Human Resources

DATA — Data Protection

Part 101 — Control ID Example

IAM-001
Privileged MFA

IAM-002
Quarterly Privileged
Access Review

IAM-003
User Termination

VM-001
Vulnerability Scanning

VM-002
Critical Vulnerability
Remediation

Part 102 — Build Traceability

Maintain:

Risk
 ↓
Control
 ↓
SOC 2 Criterion
 ↓
Owner
 ↓
Evidence
 ↓
Testing
 ↓
Finding
 ↓
Remediation

Part 103 — Create Traceability Matrix

Risk	Control	Criterion	Evidence	Result
Unauthorized Access	IAM-001	Applicable TSC	MFA Report	Pass
Excess Access	IAM-002	Applicable TSC	Review	Partial
Vulnerability	VM-001	Applicable TSC	Scan	Pass

Use the organization’s licensed/current Trust Services Criteria materials when recording exact criterion references.

Part 104 — Establish Evidence Retention

Determine:

What Evidence
Must Be Retained?

For How Long?

Where?

Who Can Access It?

How Is Integrity
Protected?

Retention should reflect examination needs and applicable business, legal, contractual, and regulatory requirements.

Part 105 — Prepare Teams

Control owners should understand:

What Control
Do I Own?

How Often
Does It Operate?

What Evidence
Must I Produce?

Where Is
Evidence Stored?

What Happens
If It Fails?

Who Must
I Notify?

Part 106 — Conduct Control Owner Workshops

Meet with:

IAM

Engineering

Cloud

Security

SOC

HR

Procurement

BCM

Legal

Privacy

Walk through:

Control
      ↓
Procedure
      ↓
Evidence
      ↓
Exceptions
      ↓
Testing

Part 107 — Perform Mock Evidence Request

Simulate:

Auditor Requests
Q2 Access Review

Measure:

Can We Find It?

Is It Complete?

Is It Approved?

Does It Match
the Population?

Can We Explain It?

Part 108 — Perform Mock Sampling

For example, select:

10 Joiners

10 Leavers

10 Changes

5 Incidents

5 Vendors

Sample sizes here are for training only.

Actual testing and sample selection are determined by the auditor based on the engagement.

Part 109 — Identify Evidence Failures

Typical problems:

Missing Approval

Wrong Date

Incomplete Population

No Owner

No Timestamp

Screenshot Without Context

Evidence Stored
in Personal Folder

Ticket Closed
Without Validation

Part 110 — Remediate Evidence Problems

Move toward:

System-Generated

Centralized

Repeatable

Traceable

Reviewable

evidence.

Part 111 — Build Examination Preparation Checklist

Before moving forward, verify:

System Boundary Defined?

Categories Selected?

Risks Assessed?

Controls Mapped?

Control Owners Assigned?

Controls Implemented?

Evidence Available?

Exceptions Managed?

Testing Completed?

Gaps Remediated?

Operating Period Planned?

Management Ready?

Part 112 — Common Mistake: Buying a Tool First

Weak:

Buy Compliance
Automation Tool
      ↓
Assume
SOC 2 Ready

A tool may automate:

Evidence Collection

Monitoring

Control Tracking

but it cannot replace:

Governance

Risk Decisions

Control Design

Ownership

Operational Discipline

Part 113 — Common Mistake: Copying Controls

Do not simply copy:

Generic SOC 2
Control List

Controls must reflect:

CloudNova's

Systems

Risks

Processes

Commitments

Part 114 — Common Mistake: Policies Without Evidence

Policy:
Access Reviewed
Quarterly

does not prove:

Quarterly Reviews
Actually Happened

Part 115 — Common Mistake: Evidence Created for Audit

Weak:

Audit Coming
      ↓
Create Evidence

Better:

Control Operation
      ↓
Evidence Generated
Automatically

Part 116 — Common Mistake: Ignoring Exceptions

Auditors may discover:

Control Works
for 98%

but the unmanaged:

2%

may represent significant risk.

Part 117 — Common Mistake: Unclear Ownership

If the answer to:

Who Owns
This Control?

is:

Security Team

ownership may be too vague.

Prefer:

Named Role

Defined Accountability

Part 118 — Common Mistake: Over-Scoping

Including unnecessary systems can create:

More Controls

More Evidence

More Testing

More Exceptions

More Cost

Define the system boundary based on the services and commitments being reported upon.

Part 119 — Common Mistake: Under-Scoping

Do not exclude systems that materially support the service simply to reduce effort.

The system description must accurately represent the service and its relevant components.

Part 120 — Common Mistake: Ignoring Vendors

A SaaS organization may depend heavily on:

Cloud

Identity

Monitoring

Support

Development

Payment

Communication

providers.

Third-party dependencies must be understood.

Part 121 — Common Mistake: Treating SOC 2 as Certification

SOC 2 is an:

Attestation
Report

not a traditional certification like ISO/IEC 27001 certification.

Use terminology carefully.

Part 122 — SOC 2 Readiness Maturity

Level 1 — Ad Hoc

Controls Exist
Informally

Level 2 — Defined

Controls
Documented

Level 3 — Implemented

Controls
Operating

Level 4 — Evidence Ready

Consistent
Evidence
Available

Level 5 — Assurance Ready

Controls

Evidence

Monitoring

Exceptions

Testing

Governance

operate as an integrated assurance system.

Part 123 — Future-State CloudNova

Move from:

Compliance Request
      ↓
Find Evidence
      ↓
Fix Problem
      ↓
Respond

to:

Enterprise Controls
        ↓
Continuous Operation
        ↓
Evidence Generation
        ↓
Control Monitoring
        ↓
Exception Management
        ↓
Continuous Assurance

Practical Assignment

Perform the SOC 2 readiness review for CloudNova.

Task 1 — Define System Boundary

Document:

Infrastructure

Software

People

Procedures

Data

Third Parties

Task 2 — Select Trust Services Categories

Determine whether CloudNova requires:

Security

Availability

Processing Integrity

Confidentiality

Privacy

and document the rationale.

Task 3 — Build System Inventory

Identify at least:

20 System
Components

Task 4 — Build Control Matrix

Create at least:

30 Enterprise
Controls

across:

Governance

Risk

IAM

Asset Management

Change Management

Vulnerability Management

Monitoring

Incident Response

Vendor Risk

BCM

HR

Data Protection

Task 5 — Assign Control Owners

Every control must have:

Accountable Owner

Operator

Evidence Owner

Task 6 — Create Evidence Request List

Identify at least:

30 Evidence
Artifacts

Task 7 — Assess Control Design

Determine:

Effective Design

Partial Design

Ineffective Design

using a documented internal readiness methodology.

Task 8 — Assess Implementation

Determine whether each control is:

Implemented

Partially Implemented

Not Implemented

Task 9 — Assess Operating Readiness

For recurring controls, inspect representative evidence across the relevant period.

Task 10 — Perform Mock Sampling

Sample:

Joiners

Movers

Leavers

Changes

Incidents

Vulnerabilities

Vendors

Task 11 — Create Gap Register

Identify at least:

15 Realistic
Readiness Gaps

Task 12 — Root Cause Analysis

Perform root-cause analysis for at least:

5 High-Priority
Gaps

Task 13 — Build Remediation Plan

For each high-priority gap define:

Action

Owner

Target Date

Evidence

Success Criteria

Task 14 — Build Readiness Dashboard

Summarize:

Control Status

Evidence Status

Gap Severity

Remediation

Readiness Blockers

Task 15 — Prepare Management Report

Answer:

Are We Ready?

What Is Missing?

What Could
Delay Us?

What Must
Management Decide?

When Can We
Move Forward?

Final Validation Checklist

Scope

service commitments understood.
system boundary defined.
infrastructure identified.
software identified.
people identified.
procedures identified.
data identified.
relevant third parties identified.

Trust Services Criteria

Security included.
additional categories evaluated.
selection rationale documented.
applicable criteria identified.
internal controls mapped.

Controls

controls defined.
control objectives documented.
owners assigned.
frequencies established.
design evaluated.
implementation validated.
operation reviewed.

Evidence

evidence requirements identified.
evidence owners assigned.
evidence collected.
evidence quality reviewed.
repository established.
traceability maintained.

Testing

populations identified.
representative samples selected.
control operation evaluated.
exceptions documented.
failed samples investigated.
results recorded.

Third Parties

subservice organizations identified.
relevant responsibilities understood.
vendor controls assessed.
customer responsibilities considered where relevant.

Findings

gaps clearly documented.
evidence referenced.
risk identified.
root causes considered.
recommendations developed.
priorities assigned.

Remediation

owners assigned.
target dates established.
evidence requirements defined.
success criteria established.
remediation retesting planned.

Readiness

readiness blockers identified.
control calendar established.
evidence calendar established.
operating period considered.
management report completed.
next steps agreed.

Expected Project Folder

04 Perform a SOC 2 Readiness Review
│
├── 01 SOC 2 Readiness Scope
├── 02 System Boundary
├── 03 System Component Inventory
├── 04 Trust Services Category Assessment
├── 05 SOC 2 Control Matrix
├── 06 Control Ownership Register
├── 07 Evidence Request List
├── 08 Control Testing Workbook
├── 09 Gap Register
├── 10 Finding Register
├── 11 Remediation Plan
├── 12 SOC 2 Readiness Dashboard
├── 13 Management Readiness Report
├── 14 Examination Preparation Checklist
└── 15 SOC 2 Readiness Roadmap

Success Criteria

You successfully complete this project when you can move from:

Customer
Assurance Requirement
        ↓
SOC 2 Scope
        ↓
System Boundary
        ↓
Trust Services Criteria
        ↓
Enterprise Risk
        ↓
Controls
        ↓
Ownership
        ↓
Operation
        ↓
Evidence
        ↓
Testing
        ↓
Gaps
        ↓
Remediation
        ↓
Readiness

and answer:

What System
Is In Scope?

Which Trust Services
Categories Apply?

Which Risks
Matter?

Which Controls
Address Them?

Who Owns
Each Control?

Are Controls
Designed Appropriately?

Are They
Implemented?

Do They
Operate Consistently?

Can We
Produce Evidence?

What Exceptions
Exist?

Which Gaps
Could Affect Readiness?

What Must
Be Remediated?

Are We Ready
to Proceed?

Career Connection

This project reflects work performed by:

GRC Analysts

SOC 2 Readiness
Consultants

Security Compliance
Analysts

Security Assurance
Professionals

Internal Auditors

GRC Consultants

Security Governance
Managers

A beginner may approach SOC 2 as:

Checklist
     ↓
Collect Evidence
     ↓
Pass Audit

A professional approaches it as:

Business Commitments
        ↓
System
        ↓
Risk
        ↓
Criteria
        ↓
Controls
        ↓
Ownership
        ↓
Evidence
        ↓
Operating Effectiveness
        ↓
Independent Assurance

The goal is not simply:

Get a
SOC 2 Report

The goal is to build a control environment capable of providing:

Consistent

Repeatable

Evidence-Based

Independent
Assurance

What’s Next?

➡️ Next: 05 — Conduct a PCI-DSS Assessment

You have now completed:

Enterprise Risk Assessment
        ↓
Build an ISMS
        ↓
ISO 27001 Gap Assessment
        ↓
SOC 2 Readiness Review

The next project moves into a more prescriptive compliance environment:

Payment Card
Security

You will learn how to determine:

Where Cardholder
Data Exists

How Payment Data
Flows

What Systems
Are In Scope

How Scope
Can Be Reduced

Which PCI DSS
Requirements Apply

What Controls
Are Required

What Evidence
Demonstrates Compliance

Where Compliance
Gaps Exist

You will move through:

Payment Environment
        ↓
Cardholder Data Flow
        ↓
PCI Scope
        ↓
CDE
        ↓
Connected Systems
        ↓
Segmentation
        ↓
PCI DSS Requirements
        ↓
Control Assessment
        ↓
Evidence
        ↓
Gap Analysis
        ↓
Remediation
        ↓
Compliance Readiness

➡️ Next: 05 — Conduct a PCI-DSS Assessment