Lab 01 — Perform a SOC 2 Readiness Assessment

Mission Information

Field	Details
Lab Type	GRC / SOC 2 Readiness
Difficulty	Intermediate
Estimated Time	90–120 Minutes
Role	GRC / SOC Readiness Analyst
Environment	Fictional SaaS Organization
Primary Framework	SOC 2
Report Objective	SOC 2 Type II
Primary TSC Categories	Security, Availability, Confidentiality
Deliverable	SOC 2 Readiness Assessment Package

Mission Scenario

You have recently joined CloudNova Technologies, a growing SaaS company providing a cloud-based collaboration platform to enterprise customers.

Several prospective customers have started requesting independent security assurance before signing contracts.

CloudNova management has therefore decided to pursue its first:

SOC 2 Type II

report.

The organization wants the examination to cover:

Security

Availability

Confidentiality

Before engaging the external service auditor for formal fieldwork, management has asked the GRC team to perform a complete SOC 2 Readiness Assessment.

You have been assigned as the GRC analyst responsible for evaluating whether CloudNova’s existing control environment is ready.

Your job is not to make the organization appear compliant.

Your job is to determine:

Can CloudNova demonstrate that appropriately designed controls exist, are implemented, are operating consistently, and can be supported by reliable evidence during a SOC 2 Type II examination?

You will examine the organization from:

SOC Scope
      ↓
System Boundary
      ↓
Trust Services Criteria
      ↓
Risks
      ↓
Controls
      ↓
Evidence
      ↓
Control Testing
      ↓
Readiness Gaps
      ↓
Remediation
      ↓
Readiness Decision

Mission Objectives

By completing this lab, you will practice how to:

• Define SOC 2 examination scope.

• Determine applicable Trust Services Categories.

• Document the in-scope system.

• Identify subservice organizations.

• Identify Complementary User Entity Controls.

• Build a SOC 2 control inventory.

• Map controls to Trust Services Criteria.

• Define control ownership.

• Determine control frequency.

• Identify evidence requirements.

• Validate evidence quality.

• Define control populations.

• Assess control design.

• Evaluate implementation.

• Test operating effectiveness.

• Identify SOC readiness gaps.

• Classify findings.

• Perform root-cause analysis.

• Develop corrective actions.

• Build a SOC remediation tracker.

• Build a readiness dashboard.

• Make a formal audit-readiness recommendation.

Final Mission Deliverables

At the end of the lab, you should have created:

01 SOC Readiness Assessment Plan

02 SOC Scope & Applicability Register

03 SOC System Boundary

04 SOC Control Inventory

05 TSC-to-Control Mapping

06 SOC Evidence Matrix

07 Control Testing Workbook

08 SOC Readiness Gap Register

09 SOC Remediation Tracker

10 SOC Readiness Dashboard

11 Executive Readiness Assessment

Part 1 — Understand the Organization

CloudNova provides the following services.

Core SaaS Platform

The primary enterprise collaboration platform includes:

Web Application

REST API

Customer Database

Document Storage

Administrative Portal

Supporting Environment

The organization also uses:

AWS

Microsoft Entra ID

GitHub

GitHub Actions

Cloudflare

Datadog

PagerDuty

Jira

Slack

Google Workspace

Salesforce

Zendesk

Assume these represent typical third-party services for this fictional lab. Your objective is assurance analysis rather than configuration of the actual platforms.

Organization Structure

CloudNova has approximately:

250 Employees

across:

Engineering

Security

Cloud Operations

IT

Customer Support

Sales

HR

Finance

Legal

GRC

Customer Data

The SaaS platform processes:

Customer Account Information

User Profiles

Business Documents

Application Metadata

Audit Logs

Some enterprise customers upload information classified as confidential.

Business Commitments

CloudNova tells customers that:

Customer information is protected.

The platform targets 99.9% availability.

Confidential customer information is encrypted.

Access to customer systems is restricted.

Security incidents are monitored and investigated.

These commitments will help determine SOC scope.

Part 2 — Define the SOC Objective

Management has stated:

Goal:
Obtain SOC 2 Type II

Target examination period:

01 January 2027
through
30 June 2027

Target auditor fieldwork:

July–August 2027

Your readiness assessment is being conducted before the examination period.

Task 2.1 — Document the SOC Objective

Create:

01 SOC Readiness Assessment Plan

Record:

Field	Value
Organization	CloudNova Technologies
Report	SOC 2
Report Type	Type II
Target Period	Jan–Jun 2027
Readiness Objective	Determine audit readiness
Assessment Owner	GRC
Executive Sponsor	CISO
Intended Users	Customers / Customer Auditors

Part 3 — Determine Trust Services Categories

Management initially proposes:

Security

Availability

Confidentiality

You must determine whether this scope makes sense.

Security

Security should be included.

Reason:

Mandatory SOC 2 category

Availability

Applicable because CloudNova makes:

99.9% Availability Commitment

Confidentiality

Applicable because CloudNova processes information designated as confidential.

Processing Integrity

For this fictional assessment, assume CloudNova does not make significant processing-integrity commitments requiring this category.

Privacy

CloudNova maintains privacy controls, but management has decided not to include the Privacy category in this initial SOC 2 engagement.

This does not remove privacy obligations from the organization.

Task 3.1 — Build Scope & Applicability Register

Create:

02 SOC Scope & Applicability Register

Use:

Category	Applicable	Rationale
Security	Yes	Mandatory SOC 2 foundation
Availability	Yes	99.9% service commitment
Processing Integrity	No	Outside current attestation objective
Confidentiality	Yes	Confidential customer data
Privacy	No	Outside current SOC 2 scope

Part 4 — Define the System Boundary

You now need to determine what makes up the system being examined.

Use the standard SOC model:

Infrastructure

Software

People

Procedures

Data

Infrastructure

Identify:

AWS Compute

AWS Storage

AWS Databases

Cloud Networking

Load Balancers

Cloudflare

Corporate Endpoints

Software

Include:

CloudNova SaaS Application

Administrative Portal

REST API

GitHub

GitHub Actions

Monitoring Platforms

IAM Platforms

People

Include personnel who influence the system:

Engineering

Security

Cloud Operations

IT

Customer Support

GRC

Procedures

Include:

Access Management

Change Management

Incident Response

Vulnerability Management

Backup & Recovery

Vendor Risk

Risk Management

Data

Include:

Customer Account Data

Customer Documents

Application Logs

Security Logs

Configuration Data

Task 4.1 — Create System Boundary Diagram

Create:

03 SOC System Boundary

Start with:

                    Customers
                        │
                        ▼
                   Cloudflare
                        │
                        ▼
                CloudNova SaaS
                  /     │      \
                 /      │       \
                ▼       ▼        ▼
             API    Application  Admin Portal
                \       │        /
                 \      │       /
                    AWS
                     │
           ┌─────────┼─────────┐
           ▼         ▼         ▼
       Database   Storage    Logging
                     │
                     ▼
               Datadog / SIEM

Add enterprise dependencies:

Microsoft Entra ID
      ↓
Authentication

GitHub / GitHub Actions
      ↓
Development & Deployment

PagerDuty
      ↓
Incident Escalation

Part 5 — Identify Subservice Organizations

CloudNova relies on external providers.

Potential subservice organizations include:

AWS

Cloudflare

Identity Provider

You should evaluate whether relevant provider controls are:

Inclusive

or:

Carved Out

For this lab assume:

AWS
→ Carve-Out

Cloudflare
→ Carve-Out

Identity Provider
→ Carve-Out

Task 5.1 — Build Subservice Register

Use:

Provider	Service	Method	Control Dependency
AWS	Cloud Infrastructure	Carve-Out	Infrastructure security & availability
Cloudflare	Edge / CDN	Carve-Out	Network availability
Identity Provider	Authentication	Carve-Out	Authentication controls

Part 6 — Identify Complementary User Entity Controls

CloudNova customers also have responsibilities.

Potential CUECs include:

Customers manage their own users.

Customers remove terminated users.

Customers protect administrator credentials.

Customers configure available security settings.

Customers review authorized administrators.

Task 6.1 — Build CUEC Register

Create:

CUEC	Customer Responsibility	Relevant Area
CUEC-01	Manage authorized users	Security
CUEC-02	Remove terminated users	Security
CUEC-03	Protect admin credentials	Security
CUEC-04	Configure required security settings	Security
CUEC-05	Review customer administrators	Security

Part 7 — Build the SOC Control Inventory

You now begin evaluating CloudNova’s internal control environment.

Create:

04 SOC Control Inventory

Use:

Control ID	Domain	Control	Frequency	Owner

Use the following fictional controls.

Governance Controls

GOV-001 — Information Security Policy

Management maintains and annually reviews an approved information-security policy.

Frequency:

Annual

Owner:

CISO

GOV-002 — Security Awareness Training

Employees complete security-awareness training during onboarding and annually thereafter.

Frequency:

Annual + Event Driven

Owner:

Security

GOV-003 — Security Roles & Responsibilities

Security responsibilities are formally assigned and communicated.

Frequency:

Annual Review

Risk Controls

RISK-001 — Enterprise Security Risk Assessment

CloudNova performs a security risk assessment annually and following significant environmental changes.

Frequency:

Annual + Event Driven

RISK-002 — Risk Treatment

Material security risks are assigned owners and tracked through approved treatment plans.

IAM Controls

IAM-001 — User Provisioning

New access requires documented approval before provisioning.

IAM-002 — Multi-Factor Authentication

MFA is required for administrative access to critical production systems.

IAM-003 — Privileged Access Review

Privileged production access is reviewed quarterly.

IAM-004 — User Termination

Access for terminated personnel is disabled within 24 hours of termination notification.

IAM-005 — Service Account Governance

Service and workload identities have documented owners and least-privilege permissions.

Change Management Controls

CHG-001 — Production Change Approval

Production changes require documented testing and approval before deployment.

CHG-002 — Peer Review

Production application changes require peer review before merge.

CHG-003 — Emergency Changes

Emergency production changes undergo documented post-implementation review.

Vulnerability Controls

VUL-001 — Vulnerability Scanning

Production systems are regularly scanned for vulnerabilities.

VUL-002 — Critical Vulnerability Remediation

Critical vulnerabilities are remediated within the defined security SLA or have an approved exception.

VUL-003 — Penetration Testing

External penetration testing is performed annually.

Logging & Monitoring Controls

LOG-001 — Central Logging

Security-relevant logs from in-scope production systems are centrally collected.

LOG-002 — Security Alert Monitoring

Material security alerts are investigated according to documented procedures.

LOG-003 — Log Retention

Security logs are retained according to approved retention requirements.

Incident Controls

IR-001 — Incident Response Plan

CloudNova maintains an approved incident-response plan.

IR-002 — Incident Handling

Security incidents are classified, investigated, escalated, and resolved.

IR-003 — Incident Exercise

CloudNova performs an incident-response tabletop exercise annually.

Availability Controls

AVL-001 — Availability Monitoring

Production services are continuously monitored for availability.

AVL-002 — Backup

Critical production data is backed up according to defined schedules.

AVL-003 — Backup Monitoring

Failed backup jobs generate alerts and are investigated.

AVL-004 — Restore Testing

Backup restoration is tested periodically.

AVL-005 — Disaster Recovery

Disaster-recovery procedures are documented for critical services.

AVL-006 — DR Testing

Recovery capabilities are tested annually.

Confidentiality Controls

CONF-001 — Information Classification

Information is classified according to defined sensitivity requirements.

CONF-002 — Confidential Access

Access to confidential customer information is restricted according to need-to-know.

CONF-003 — Encryption at Rest

Confidential production information is encrypted at rest.

CONF-004 — Encryption in Transit

Confidential information transmitted across untrusted networks uses approved encryption.

CONF-005 — External Sharing

External sharing of confidential information requires authorized business need and approved mechanisms.

CONF-006 — Secure Disposal

Confidential information is securely disposed of when approved retention requirements expire.

Vendor Risk Controls

TPRM-001 — Vendor Risk Assessment

Critical third parties undergo security due diligence before onboarding.

TPRM-002 — Vendor Reassessment

Critical third parties are reassessed annually.

TPRM-003 — Vendor Assurance Review

Current assurance reports are reviewed for critical technology providers.

Part 8 — Map Controls to the Trust Services Criteria

Create:

05 TSC-to-Control Mapping

You do not need to memorize every TSC identifier for this lab.

Focus first on meaningful control domains.

Example:

TSC Area	Control
Control Environment	GOV-001
Risk Assessment	RISK-001
Logical Access	IAM-001
Logical Access	IAM-002
Logical Access	IAM-003
System Operations	LOG-001
System Operations	IR-002
Change Management	CHG-001
Risk Mitigation	TPRM-001
Availability	AVL-001
Availability	AVL-006
Confidentiality	CONF-003
Confidentiality	CONF-005

Mission Checkpoint

You should now have:

SOC Objective
      ✓

TSC Scope
      ✓

System Boundary
      ✓

Subservices
      ✓

CUECs
      ✓

Control Inventory
      ✓

TSC Mapping
      ✓

You are now ready to test the environment.

Part 9 — Define Evidence Requirements

Create:

06 SOC Evidence Matrix

Use:

Control	Evidence Required	Source	Frequency

Populate examples below.

IAM-001

Evidence:

Access Request

Manager Approval

Provisioned Role

Timestamp

Source:

IAM / ITSM

IAM-002

Evidence:

Privileged Account Population

MFA Configuration

MFA Coverage Report

IAM-003

Evidence:

Quarterly Review Population

Reviewer

Review Decisions

Removed Access

IAM-004

Evidence:

HR Termination Population

Identity Disablement Records

Disablement Timestamp

CHG-001

Evidence:

Production Change Population

Pull Request

Testing

Approval

Deployment Timestamp

VUL-001

Evidence:

Vulnerability Scan Reports

Asset Coverage

Scan Dates

VUL-002

Evidence:

Critical Findings

Remediation Tickets

Closure Dates

Exceptions

LOG-001

Evidence:

Production System Inventory

Logging Configuration

SIEM Coverage

IR-002

Evidence:

Incident Population

Severity

Investigation

Closure

AVL-002

Evidence:

Backup Configuration

Backup Reports

Failure Records

AVL-004

Evidence:

Restore Test

Test Date

Result

Issues

CONF-003

Evidence:

Production Data Stores

Encryption Configuration

Exception Register

TPRM-002

Evidence:

Critical Vendor Population

Annual Review

Assessment

Approval

Part 10 — Review the Fictional Evidence

Your evidence review identifies the following conditions.

Observation 1 — Privileged MFA

Population:

52 Privileged Accounts

MFA enabled:

50

Without MFA:

2

Both accounts belong to legacy administrators.

Observation 2 — Quarterly Access Reviews

Expected:

Q1
Q2
Q3
Q4

Evidence available:

Q1 ✓

Q2 ✓

Q3 ✗

Q4 ✓

The Q3 review was not performed.

Observation 3 — Terminations

Population:

48 Terminations

Sample:

20

Results:

18
→ Disabled Within 24 Hours

2
→ Disabled After 72 Hours

Observation 4 — Production Changes

Population:

1,250 Production Changes

Sample:

25

Results:

22
→ Approved Before Deployment

3
→ Approval Obtained After Deployment

Observation 5 — Vulnerability Management

Critical vulnerabilities:

18

Remediated within SLA:

16

Remaining:

2

No documented exception exists.

Observation 6 — Central Logging

Production systems:

45

Forwarding logs to SIEM:

42

Not integrated:

3

Observation 7 — Incident Response

Five incidents occurred during the review period.

All contain:

Severity

Investigation

Closure

Result:

No Exceptions Identified

Observation 8 — Backup

Critical databases:

12

Backups enabled:

12

Result:

100%

Observation 9 — Restore Testing

Policy requirement:

Quarterly

Actual:

1 Restore Test During Year

Observation 10 — DR Testing

CloudNova has a disaster-recovery plan.

However:

No Full Recovery Test
has been performed
in the last 18 months.

Observation 11 — Encryption

Production data stores:

20

Encrypted:

20

Result:

100%

Observation 12 — Vendor Reassessment

Critical vendors:

15

Current annual assessment:

11

Overdue:

4

Part 11 — Build the Control Testing Workbook

Create:

07 Control Testing Workbook

Use:

Control	Population	Test	Result	Conclusion

Example — IAM-002

Population:

52 Privileged Accounts

Test:

Inspect privileged-account population and verify MFA status.

Result:

50 / 52 MFA Enabled

Conclusion:

Partially Effective

Example — IR-002

Population:

5 Incidents

Test:

Inspect incident records for classification, investigation, and closure.

Result:

5 / 5 Passed

Conclusion:

Effective

Complete Your Testing

Classify each selected control as:

Effective

Partially Effective

Ineffective

Not Tested

Part 12 — Assess Design Effectiveness

Do not evaluate only whether evidence exists.

Ask:

If the control operates exactly as designed, will it reasonably address the identified risk?

Design Test — IAM-002

Control:

MFA Required for
Privileged Production Access

Design:

Strong

Implementation / operation:

Incomplete

Therefore:

Design Effective

Operating Effectiveness Problem

Design Test — AVL-004

Policy:

Quarterly Restore Testing

Control design:

Appropriate

Operation:

Only One Test Per Year

Therefore:

Operating Gap

Design Test — DR Testing

Requirement:

Annual DR Test

No recovery test completed.

Conclusion:

Control Not Operating

Part 13 — Identify Readiness Gaps

Create:

08 SOC Readiness Gap Register

Use:

Gap ID	Control	Gap	Type	Severity	Owner

Identify at least these gaps.

GAP-001 — Privileged MFA Coverage

Control:

IAM-002

Condition:

2 / 52 privileged accounts
do not have MFA.

Gap Type:

Operating / Configuration Gap

Suggested severity:

High

GAP-002 — Missing Q3 Access Review

Control:

IAM-003

Condition:

Quarterly review not completed.

Gap Type:

Operating Gap

Suggested severity:

High

GAP-003 — Delayed Termination

Control:

IAM-004

Condition:

2 / 20 sampled accounts
removed after required timeline.

Suggested severity:

High

GAP-004 — Change Approval Exceptions

Control:

CHG-001

Condition:

3 / 25 sampled changes
approved after deployment.

Suggested severity:

High

GAP-005 — Critical Vulnerabilities Outside SLA

Control:

VUL-002

Condition:

2 critical vulnerabilities
past SLA

No approved exception

Suggested severity:

High

GAP-006 — Logging Coverage

Control:

LOG-001

Condition:

3 / 45 production systems
not integrated with SIEM.

Suggested severity:

High

GAP-007 — Restore Testing

Control:

AVL-004

Requirement:

Quarterly

Actual:

Annual

Suggested severity:

Medium / High

based on service criticality.

GAP-008 — DR Testing

Control:

AVL-006

Condition:

No test in last 18 months.

Suggested severity:

High

GAP-009 — Vendor Reassessments

Control:

TPRM-002

Condition:

4 / 15 critical vendors overdue.

Suggested severity:

Medium / High

Part 14 — Perform Root Cause Analysis

Do not stop at:

User Forgot

Team Was Busy

Manual Error

Identify process causes.

GAP-001 Root Cause Example

Problem:

2 administrators without MFA

Why?

Legacy local accounts

Why?

Local accounts not federated

Why?

Privileged-account inventory
does not include local identities

Root cause:

Privileged identity governance does not centrally inventory and monitor all local administrative accounts.

GAP-002 Root Cause

Problem:

Q3 Review Missing

Why?

Owner did not initiate review

Why?

Calendar reminder missed

Why?

No centralized compliance calendar

Root cause:

Recurring SOC controls are not centrally scheduled and escalated.

GAP-004 Root Cause

Problem:

Changes deployed before approval

Cause:

Emergency deployments
can bypass standard workflow

Root cause:

CI/CD enforcement does not require an approved change record before production deployment.

GAP-008 Root Cause

Problem:

DR testing overdue

Cause:

No formal annual recovery exercise schedule

Root cause:

Disaster-recovery governance does not centrally schedule, track, and escalate recovery-testing requirements.

Part 15 — Build the Remediation Tracker

Create:

09 SOC Remediation Tracker

Use:

Gap	Correction	Corrective Action	Owner	Target	Status

GAP-001

Correction:

Enable MFA for two legacy administrators.

Corrective action:

Create authoritative privileged-account inventory.

Include local administrator accounts.

Implement continuous MFA coverage monitoring.

GAP-002

Correction:

Perform current privileged access review.

Corrective action:

Implement centralized SOC control calendar.

Automate quarterly reminders.

Escalate overdue reviews.

GAP-003

Correction:

Review affected terminated accounts.

Corrective action:

Automate HR-to-IAM termination workflow.

Alert on accounts active beyond SLA.

GAP-004

Correction:

Review the three affected changes.

Corrective action:

Require valid approved change ID
before CI/CD production deployment.

GAP-005

Correction:

Remediate the two overdue critical findings.

Corrective action:

Automate vulnerability SLA tracking.

Require formal risk exception
before an SLA can expire.

GAP-006

Correction:

Integrate three missing systems with SIEM.

Corrective action:

Implement continuous logging coverage monitoring
against production asset inventory.

GAP-007

Correction:

Perform a restore test.

Corrective action:

Schedule quarterly restore tests.

Track RTO and RPO results.

Escalate overdue tests.

GAP-008

Correction:

Conduct disaster-recovery exercise.

Corrective action:

Create annual DR testing calendar.

Assign service owners.

Track findings and retesting.

GAP-009

Correction:

Complete four overdue vendor assessments.

Corrective action:

Automate vendor reassessment scheduling
based on risk tier.

Part 16 — Retest Remediation

A readiness finding should not close because:

Owner Says Fixed

Retest.

Retest — MFA

Expected:

52 / 52
Privileged Accounts
With MFA

Also verify:

New Admin Account
      ↓
Automatically Detected
      ↓
MFA Required

Retest — Termination

Select new termination samples.

Verify:

Termination
      ↓
Access Disabled
      ↓
Within 24 Hours

Retest — Change Approval

Select:

20 New Production Changes

Verify:

20 / 20

Approval Before Deployment

Retest — Logging

Compare:

Production Inventory
      ↓
SIEM Coverage

Expected:

100%

Retest — Vendor Risk

Expected:

15 / 15
Critical Vendors Current

Part 17 — Build the SOC Readiness Dashboard

Create:

10 SOC Readiness Dashboard

Assume the assessment produced:

Total Controls Reviewed:
35

Results:

Effective:
26

Partially Effective:
7

Ineffective:
2

Evidence:

Complete:
82%

High gaps:

7

Medium gaps:

2

Dashboard Example

Metric	Result	Target
Controls Effective	74%	100%
Evidence Completion	82%	100%
High-Risk Gaps	7	0
Ineffective Controls	2	0
Privileged MFA	96.2%	100%
Logging Coverage	93.3%	100%
Current Critical Vendor Reviews	73.3%	100%
Current DR Testing	No	Yes

Readiness Rating

Use:

READY

READY WITH MINOR GAPS

MATERIAL REMEDIATION REQUIRED

NOT READY

Based on the current findings, your initial rating should be:

MATERIAL REMEDIATION REQUIRED

CloudNova should not yet begin the Type II examination period with the expectation that these control conditions will simply be resolved during the audit.

Part 18 — Prepare Executive Readiness Assessment

Create:

11 Executive Readiness Assessment

Use the following structure.

Executive Summary

CloudNova has established a meaningful SOC 2 control environment across Security, Availability, and Confidentiality.

However, the readiness assessment identified several material control-operating gaps that could result in Type II exceptions if the examination period begins before remediation.

Positive Areas

Examples:

Incident Response

Encryption Coverage

Backup Coverage

Security Governance

Significant Readiness Gaps

Priority concerns include:

Privileged MFA

Access Reviews

User Termination

Change Approval

Critical Vulnerability Remediation

Logging Coverage

Disaster Recovery Testing

Vendor Reassessment

Recommendation

Use:

CloudNova should delay entry into the planned SOC 2 Type II operating period until all High-severity readiness findings are remediated, independently retested, and supported by reliable operating evidence.

The organization should then allow the corrected controls to operate consistently throughout the formal examination period.

Part 19 — Determine Audit Readiness

Your decision should consider:

Scope
      ↓
Appropriate

TSC Categories
      ↓
Appropriate

Control Inventory
      ↓
Established

Evidence Process
      ↓
Partially Mature

Operating Effectiveness
      ↓
Material Gaps

Remediation
      ↓
Required

Final decision:

NOT READY FOR TYPE II OPERATING PERIOD

until high-risk remediation is completed and retested.

Part 20 — Readiness Gate

Before approving the Type II period, require:

• 100% privileged MFA.

• All recurring access reviews scheduled.

• Termination SLA operating effectively.

• Change approval enforcement implemented.

• Critical vulnerability backlog within SLA.

• 100% SIEM coverage for in-scope systems.

• Restore-test schedule operational.

• DR test completed.

• Critical vendor assessments current.

• High findings independently retested.

• Evidence owners confirmed.

• Population sources validated.

• SOC system description updated.

• Evidence repository ready.

Part 21 — Challenge Scenario

Management tells you:

“The auditor is starting next month. Can’t we just fix these during the audit?”

As the GRC analyst, explain why this is risky.

Your response should address:

Type II Measures Operating Effectiveness

Historical Failures Remain Historical Failures

Late Remediation Does Not Erase Exceptions

Controls Need Time to Operate

Evidence Must Be Generated During Operation

A strong response would explain:

Fixing a control before or during fieldwork is useful, but it does not retroactively demonstrate that the control operated effectively throughout the Type II examination period. High-risk gaps should therefore be remediated before the operating period begins wherever possible.

Part 22 — Challenge Scenario: Evidence vs Control Failure

Control owner says:

“We performed the quarterly access review, but we cannot find the Q3 evidence.”

Classify the condition.

Potential classification:

Evidence Gap

However, without sufficient supporting evidence:

Auditor May Be Unable
to Confirm Control Operation

Your action:

Investigate Authoritative Sources

Do Not Recreate False Historical Evidence

Document the Gap

Improve Evidence Retention

Part 23 — Challenge Scenario: Scope Change

During readiness, CloudNova launches a new AI feature.

The feature:

Processes Customer Documents

Uses Separate Cloud Infrastructure

Uses External AI Provider

Ask:

Does it affect the SOC service?

Does it process in-scope data?

Does it introduce new providers?

Do existing controls cover it?

If yes:

Reassess SOC Scope

before beginning the examination.

Part 24 — Challenge Scenario: New Vendor

CloudNova begins using:

New Customer Support AI Provider

The vendor receives customer support content.

Determine:

Data Classification

Vendor Criticality

Security Assessment

Contract

Subprocessor Impact

SOC Scope Impact

This demonstrates why SOC readiness cannot be treated as a static one-time checklist.

Part 25 — Student Submission Checklist

Your final submission should include:

• SOC Readiness Assessment Plan.

• SOC Scope & Applicability Register.

• System Boundary.

• Subservice Organization Register.

• CUEC Register.

• SOC Control Inventory.

• TSC-to-Control Mapping.

• SOC Evidence Matrix.

• Control Testing Workbook.

• Readiness Gap Register.

• Root Cause Analysis.

• SOC Remediation Tracker.

• Retest Plan.

• SOC Readiness Dashboard.

• Executive Readiness Assessment.

• Final Audit Readiness Decision.

Mission Success Criteria

You have successfully completed the mission if you can demonstrate the following chain:

Business Commitments
      ↓
SOC 2 Scope
      ↓
Trust Services Categories
      ↓
System Boundary
      ↓
Risks
      ↓
Controls
      ↓
Control Owners
      ↓
Evidence
      ↓
Testing
      ↓
Exceptions
      ↓
Root Cause
      ↓
Remediation
      ↓
Retest
      ↓
Audit Readiness Decision

Key Lessons From the Lab

A SOC 2 readiness assessment is not:

Do We Have a Policy?

Do We Have MFA?

Do We Have Backups?

It is:

What commitment are we making?
      ↓
What risk threatens that commitment?
      ↓
Which control addresses the risk?
      ↓
Is the control properly designed?
      ↓
Is it implemented?
      ↓
Did it operate?
      ↓
Across the complete population?
      ↓
Can we prove it?
      ↓
What failed?
      ↓
Why?
      ↓
Was it fixed and retested?

The major lessons from this mission are:

• Define SOC scope before assessing controls.

• Select Trust Services Categories based on actual commitments.

• Understand system boundaries and third-party dependencies.

• Build one clear control inventory.

• Every control should have an owner and frequency.

• Evidence requirements should be determined before the examination period.

• Type II readiness requires operating evidence, not just policy documents.

• Population completeness matters.

• Control design and operating effectiveness are separate questions.

• Missing evidence and failed controls should be treated differently.

• Readiness findings should identify root causes.

• Correction alone is not sufficient remediation.

• High-risk gaps should be retested before beginning the Type II period.

• Audit readiness should be based on evidence rather than optimism.

Final Mission Question

Based on your assessment of CloudNova, answer:

Should CloudNova begin its SOC 2 Type II operating period today?

Recommended conclusion:

No

Reason:

Material operating-effectiveness gaps remain across identity, change management, vulnerability management, security logging, availability, and third-party risk controls. CloudNova should remediate and independently retest these high-risk gaps before starting the Type II operating period.

Mission Complete

You have now completed a practical SOC 2 Readiness Assessment from scope definition through executive readiness reporting.

This is one of the core responsibilities performed by:

GRC Analysts

SOC Readiness Consultants

Compliance Analysts

IT Risk Analysts

Security Assurance Professionals

Internal Auditors

You have moved from understanding SOC concepts to performing the type of structured assessment used before real assurance examinations.

What’s Next?

➡️ Next: Lab 02 — Perform a SOC 2 Report Review & Exception Assessment

In the next lab, you will move to the customer / third-party assurance side of SOC 2.

You will receive a fictional SOC 2 Type II report scenario and act as a Third-Party Risk / GRC Analyst responsible for reviewing:

Report Scope
      ↓
Trust Services Categories
      ↓
Report Period
      ↓
Auditor Opinion
      ↓
Control Testing
      ↓
Exceptions
      ↓
Management Responses
      ↓
CUECs
      ↓
Subservice Organizations
      ↓
Customer Impact
      ↓
Residual Risk
      ↓
Vendor Assurance Decision

Your final deliverable will be a SOC 2 Vendor Assurance Review Package with a documented risk recommendation.