Runbook 01 — SOC 2 Readiness, Evidence Collection & Audit Coordination

Runbook Information

Field	Details
Runbook Type	GRC / SOC 2 Assurance Operations
Primary Role	GRC / Compliance Analyst
Supporting Roles	Control Owners, Security, IAM, Engineering, IT, HR, Procurement, Legal
Framework	SOC 2
Use Case	Readiness, Evidence Collection, Audit Coordination
Execution Model	Continuous + Audit Cycle
Primary Output	Audit-Ready SOC 2 Control & Evidence Package

Purpose

This runbook provides a repeatable operational process for managing a SOC 2 program from initial planning through external auditor coordination.

Use this runbook when:

Preparing for SOC 2 Type I

Preparing for SOC 2 Type II

Starting a new SOC 2 program

Entering a new audit period

Collecting audit evidence

Responding to auditor PBC requests

Preparing control walkthroughs

Submitting populations

Managing auditor samples

Responding to control exceptions

Reviewing the draft SOC 2 report

The objective is to maintain a control environment that is:

Defined
      ↓
Owned
      ↓
Operating
      ↓
Evidence Supported
      ↓
Testable
      ↓
Audit Ready

Runbook Outcome

Successful execution should produce:

SOC Scope
      ↓
TSC Applicability
      ↓
Control Inventory
      ↓
Control Ownership
      ↓
Evidence Matrix
      ↓
Control Calendar
      ↓
Validated Populations
      ↓
Readiness Testing
      ↓
Gap Remediation
      ↓
PBC Management
      ↓
Audit Walkthroughs
      ↓
Sample Evidence
      ↓
Exception Management
      ↓
Final SOC Report

Operating Principles

Follow these principles throughout the SOC 2 program:

Scope before controls.
Controls before evidence.
Evidence before audit.
Use authoritative evidence sources.
Maintain complete control populations.
Never fabricate historical evidence.
Validate evidence before submission.
Keep auditor requests centrally coordinated.
Record known exceptions accurately.
Remediate root causes, not only individual samples.
Retest material remediation.
Maintain continuous readiness between audit periods.

Phase 1 — Initiate the SOC 2 Program

Step 1 — Confirm Business Objective

Determine why SOC 2 is required.

Possible drivers:

Customer Requirement

Enterprise Sales

Contract Requirement

Board Requirement

Vendor Assurance

Market Expansion

Analyst Actions

Document:

Business Objective

Executive Sponsor

Target Customers

Required Completion Date

Output

Create:

01 SOC Program Charter

Recommended fields:

Field	Value
Business Objective
Executive Sponsor
SOC Owner
Target Report
Target Period
Target Issue Date

Step 2 — Confirm SOC Report Type

Determine:

SOC 2 Type I

or

SOC 2 Type II

Use:

Need Point-in-Time Assurance?
      ↓
Type I

Need Operating Effectiveness?
      ↓
Type II

Escalate If

Management requests Type II but controls have not yet operated long enough to support the planned examination period.

Step 3 — Define Target Timeline

Document:

Readiness Assessment

Remediation

Control Stabilization

Operating Period

Auditor Fieldwork

Draft Report

Final Report

Example:

Readiness
      ↓
Remediation
      ↓
Control Operation
      ↓
Type II Period
      ↓
Fieldwork
      ↓
Final Report

Output

Create:

02 SOC Audit Timeline

Phase 2 — Define SOC Scope

Step 4 — Identify In-Scope Services

Inventory customer-facing services.

Record:

Product

Service

Environment

Legal Entity

Customer Use

Validation Question

Does the SOC scope cover the exact service customers rely on?

Step 5 — Define System Components

Document:

Infrastructure

Software

People

Procedures

Data

Infrastructure

Examples:

Cloud Infrastructure

Networks

Databases

Storage

Endpoints

Identity Platforms

Software

Examples:

Production Application

APIs

Deployment Platforms

Monitoring Platforms

Security Platforms

People

Examples:

Engineering

Security

IT

Customer Support

Management

Procedures

Examples:

Access Management

Change Management

Incident Response

Vendor Risk

Backup

Risk Management

Data

Examples:

Customer Data

Confidential Information

Application Data

Security Logs

Output

Create:

03 SOC System Boundary

Step 6 — Identify Subservice Organizations

Identify providers supporting the service.

Examples:

AWS

Azure

Google Cloud

CDN Providers

Email Providers

Identity Providers

Determine:

Inclusive Method

or

Carve-Out Method

Output

Create:

04 Subservice Organization Register

Use:

Provider	Service	Method	Dependency	Assurance

Step 7 — Identify Complementary User Entity Controls

Identify controls customers are expected to perform.

Examples:

Customer User Management

MFA Configuration

Admin Review

Credential Protection

Customer Configuration

Output

Create:

05 CUEC Register

Phase 3 — Select Trust Services Categories

Step 8 — Confirm Security

Security is included in every SOC 2 engagement.

Record:

Security
→ Applicable

Step 9 — Assess Optional Categories

Evaluate:

Availability

Processing Integrity

Confidentiality

Privacy

Use actual:

Customer Commitments

Contracts

System Requirements

Business Risk

Do not add categories only because they sound comprehensive.

Output

Create:

06 TSC Applicability Matrix

Use:

Category	Applicable	Rationale

Phase 4 — Build the Control Environment

Step 10 — Create Control Inventory

Build one authoritative SOC control inventory.

Recommended fields:

Control ID

Domain

TSC Area

Risk

Control Statement

Owner

Operator

Frequency

Evidence

System

Status

Output

Create:

07 SOC Control Inventory

Step 11 — Validate Control Statements

A control should be:

Specific

Repeatable

Owned

Measurable

Testable

Weak:

Access is reviewed regularly.

Strong:

Privileged production access is reviewed quarterly by the system owner for continued business need.

Step 12 — Assign Control Owners

For each control define:

Control Owner

Control Operator

Evidence Owner

Example:

Control Owner:
IAM Director

Operator:
Identity Operations

Evidence Owner:
IAM Analyst

Escalate If

No accountable owner exists.

Step 13 — Define Control Frequency

Use standardized values:

Continuous

Daily

Weekly

Monthly

Quarterly

Annual

Event Driven

Output

Create:

08 SOC Control Calendar

Phase 5 — Map Controls to TSC

Step 14 — Perform TSC Mapping

Map:

Trust Services Criterion
      ↓
Risk
      ↓
Enterprise Control

One criterion may map to multiple controls.

One control may support multiple criteria.

Output

Create:

09 TSC-to-Control Mapping

Use:

TSC Area	Risk	Control ID	Owner

Phase 6 — Define Evidence Requirements

Step 15 — Define Evidence for Every Control

For each control ask:

What proves this control operated?

Possible evidence:

Policy

System Configuration

System Export

Population

Ticket

Approval

Log

Report

Review Record

Test Result

Output

Create:

10 SOC Evidence Matrix

Use:

Control	Evidence	Source	Frequency	Owner

Step 16 — Identify Authoritative Sources

Examples:

Identity Control
→ Identity Platform

Deployment
→ CI/CD

Incident
→ Incident Platform

Termination
→ HR + IAM

Vulnerability
→ Scanner

Avoid replacing authoritative system evidence with manually maintained spreadsheets where better sources exist.

Step 17 — Define Evidence Retention

Ask:

How long is the examination period?

When will fieldwork occur?

Will the source system still retain the evidence?

Ensure historical evidence is preserved.

Step 18 — Create Evidence Repository

Recommended structure:

SOC-Evidence/
│
├── 01-Governance/
├── 02-Risk/
├── 03-IAM/
├── 04-Security-Operations/
├── 05-Change-Management/
├── 06-Vendor-Risk/
├── 07-Availability/
├── 08-Confidentiality/
├── 09-Privacy/
├── 10-Populations/
├── 11-Samples/
└── 12-PBC/

Use clear naming such as:

IAM-003_Q1-2027_Privileged-Access-Review

Phase 7 — Operate Continuous Evidence Collection

Step 19 — Collect Evidence When Controls Operate

Use:

Control Executes
      ↓
Evidence Generated
      ↓
Evidence Collected
      ↓
Evidence Reviewed
      ↓
Evidence Stored

Do not wait until audit fieldwork.

Step 20 — Validate Evidence Quality

Use:

Relevant?

Reliable?

Complete?

Correct Period?

Traceable?

Evidence Status

Use:

Expected

Received

Accepted

Rejected

Missing

Step 21 — Reject Weak Evidence

Example:

Control:

Quarterly Access Review

Submitted:

Screenshot of user list

Missing:

Reviewer

Date

Decision

Removed Access

Status:

Rejected

Request appropriate evidence.

Phase 8 — Validate Populations

Step 22 — Define Control Populations

Examples:

All New Hires

All Terminations

All Access Requests

All Production Changes

All Incidents

All Critical Vendors

Output

Create:

11 Control Population Register

Use:

Control	Population	Source	Period	Count

Step 23 — Validate Population Completeness

Example:

HR Terminations
120

IAM Disablements
117

Difference:

Investigate.

Step 24 — Include Failures

Never provide a population containing only successful control executions.

Incorrect:

Approved Changes Only

Correct:

All Production Changes

Step 25 — Record Query Logic

Document:

System

Query

Date Range

Filters

Record Count

This supports auditor reproducibility.

Phase 9 — Perform SOC Readiness Testing

Step 26 — Test Control Design

Ask:

If the control operates exactly as designed, does it reasonably address the intended risk?

Classify:

Effective

Partially Effective

Ineffective

Step 27 — Validate Implementation

Ask:

Is the control actually configured?

Does a workflow exist?

Does the owner know the control?

Can evidence be generated?

Step 28 — Conduct Walkthroughs

Trace real examples.

For user provisioning:

Employee
      ↓
Request
      ↓
Approval
      ↓
Provisioning

For change management:

Change
      ↓
Testing
      ↓
Approval
      ↓
Deployment

Step 29 — Test Operating Effectiveness

For Type II readiness:

Expected Control Operations
      ↓
Actual Operations
      ↓
Evidence
      ↓
Exceptions

Example:

Quarterly Review

Expected:
4

Completed:
3

Result:

Operating Gap

Step 30 — Document Readiness Gaps

Create:

12 SOC Readiness Gap Register

Use:

Gap	Control	Type	Severity	Owner	Status

Gap types:

Scope

Design

Implementation

Operation

Evidence

Population

Ownership

Documentation

Phase 10 — Remediate Gaps

Step 31 — Perform Root Cause Analysis

Avoid:

Human Error

Forgot

Busy Team

Investigate:

Process

Technology

Governance

Ownership

Architecture

Training

Step 32 — Define Correction

Correction addresses the immediate problem.

Example:

Enable MFA on missing accounts.

Step 33 — Define Corrective Action

Corrective action prevents recurrence.

Example:

Implement continuous privileged MFA monitoring.

Step 34 — Create Remediation Tracker

Create:

13 SOC Remediation Tracker

Use:

Finding	Root Cause	Corrective Action	Owner	Due	Status

Step 35 — Retest Material Findings

Never close based only on:

Owner Says Fixed

Retest.

Status:

Effective
→ Close

Partially Effective
→ Remain Open

Ineffective
→ Escalate

Phase 11 — Audit Kickoff

Step 36 — Confirm Engagement Details

Before kickoff verify:

Report Type

Period

Scope

TSC Categories

Timeline

Auditor Contacts

Internal Contacts

Step 37 — Hold Internal Kickoff

Include:

GRC

Control Owners

Evidence Owners

Security

Engineering

IAM

IT

Procurement

Legal

Review:

Timeline

Responsibilities

PBC Process

Walkthrough Expectations

Escalation

Step 38 — Hold Auditor Kickoff

Confirm:

Audit Method

PBC Portal

Walkthrough Schedule

Population Requests

Sample Process

Follow-Up Process

Report Timeline

Phase 12 — Manage Auditor PBC Requests

Step 39 — Create PBC Tracker

Create:

14 SOC PBC Tracker

Use:

Request ID	Request	Owner	Due	Status

Recommended statuses:

Not Started

In Progress

Ready for Review

Submitted

Auditor Reviewing

Follow-Up

Accepted

Step 40 — Review Every Submission

Validate:

Correct Request?

Correct Scope?

Correct Period?

Complete?

Sensitive Information Minimized?

before sending to the auditor.

Step 41 — Protect Sensitive Evidence

Do not unnecessarily expose:

Passwords

Private Keys

Customer Records

Authentication Secrets

Full Vulnerability Data

Use secure auditor-sharing channels.

Phase 13 — Coordinate Audit Walkthroughs

Step 42 — Build Walkthrough Schedule

Create:

15 SOC Walkthrough Schedule

Use:

Area	Control Owner	Date	Auditor	Status

Step 43 — Prepare Owners

Owners should understand:

What Is the Control?

Why Does It Exist?

How Does It Work?

How Often?

What Evidence Exists?

What Happens If It Fails?

Step 44 — Use Real Transactions

Do not present theoretical workflows where real examples exist.

Use:

Real User

Real Change

Real Incident

Real Vendor

Phase 14 — Submit Populations

Step 45 — Validate Population Before Submission

Check:

Correct Period

Correct Scope

Complete Records

Failures Included

Contractors Included

Emergency Activity Included

Step 46 — Create Population Submission Register

Create:

16 Population Submission Register

Use:

Population	Source	Period	Count	Validated	Submitted

Phase 15 — Manage Auditor Samples

Step 47 — Receive Auditor Sample

Example:

Population:
1,500 Changes

Auditor Selects:
40

Step 48 — Create Sample Tracker

Create:

17 SOC Sample Tracker

Use:

Sample	Control	Owner	Evidence	Submitted	Result

Step 49 — Package Sample Evidence

Example:

CHG-103/
├── Change Request
├── Testing
├── Approval
└── Deployment

Step 50 — Maintain Traceability

Always preserve:

Population
      ↓
Sample
      ↓
Evidence
      ↓
Auditor Result

Phase 16 — Manage Auditor Follow-Ups

Step 51 — Track Follow-Up Requests

Create:

18 Auditor Follow-Up Register

Use:

Request	Control	Owner	Due	Status

Step 52 — Validate Before Responding

If auditor says:

Approval is missing.

Check the authoritative system.

Possible outcomes:

Evidence Exists
→ Provide Clarification

Evidence Does Not Exist
→ Potential Exception

Phase 17 — Manage Potential Exceptions

Step 53 — Validate Potential Exception

Confirm:

Correct Requirement?

Correct Sample?

Correct Date?

Correct Scope?

Complete Evidence?

Step 54 — Classify Result

Use:

No Exception

Evidence Clarification

Confirmed Exception

Output

Create:

19 Exception Discussion Log

Step 55 — Never Fabricate Evidence

Do not:

Backdate Approval

Create Fake Historical Review

Modify Logs

Reconstruct False Evidence

Document the gap accurately.

Phase 18 — Prepare Management Responses

Step 56 — Document Root Cause

Management response should identify:

What Happened

Why It Happened

Step 57 — Document Correction

Example:

Remove Excess Access

Step 58 — Document Corrective Action

Example:

Automate Termination Workflow

Step 59 — Assign Owner and Target

Use:

Owner

Target Date

Status

Output

Create:

20 Management Response Register

Phase 19 — Review Draft SOC Report

Step 60 — Review Auditor Opinion

Confirm:

Unmodified

Qualified

Adverse

or other applicable outcome.

Escalate modified opinions immediately.

Step 61 — Review Report Details

Validate:

Organization Name

Service Name

Report Type

Report Period

TSC Categories

System Scope

Step 62 — Review System Description

Confirm:

Infrastructure

Software

People

Procedures

Data

Providers

match reality.

Step 63 — Review Control Statements

Ensure:

Reported Control
=
Actual Control

Step 64 — Review Testing

Confirm factual accuracy of:

Sample

Test Procedure

Result

Exception

Step 65 — Review CUECs

Ensure customer responsibilities are:

Specific

Accurate

Understandable

Step 66 — Review Subservice Organizations

Validate:

Provider

Service

Inclusive / Carve-Out

Dependencies

Step 67 — Review Management Responses

Responses should be:

Accurate

Professional

Specific

Current

Output

Create:

21 Final SOC Report Review Checklist

Phase 20 — Final Report Issuance

Step 68 — Obtain Internal Approvals

Recommended review may include:

GRC

CISO

Legal

Engineering

Executive Sponsor

Step 69 — Store Final SOC Report

Record:

Report Period

Issue Date

Owner

Repository

Next Audit

Output

Create:

22 SOC Report Register

Step 70 — Control Distribution

SOC reports can contain sensitive security information.

Share only with authorized:

Customers

Customer Auditors

Regulators

Internal Stakeholders

according to organizational policy.

Phase 21 — Post-Audit Remediation

Step 71 — Transfer Open Findings

All open audit findings should move into the organization’s formal remediation workflow.

Track:

Finding

Risk

Owner

Corrective Action

Due Date

Retest

Step 72 — Conduct Lessons Learned

Ask:

Which evidence was difficult?

Which populations were hard to build?

Which controls generated exceptions?

Which owners struggled?

Which tasks can be automated?

Output

Create:

23 SOC Lessons Learned Register

Phase 22 — Continuous SOC Readiness

SOC readiness should continue after report issuance.

Use:

Control Operation
      ↓
Evidence
      ↓
Monitoring
      ↓
Gap Detection
      ↓
Remediation
      ↓
Next Audit

Continuous Monthly Activities

Review:

Evidence Completion

Control Failures

New Systems

New Vendors

Open Findings

Continuous Quarterly Activities

Review:

Access Reviews

Control Owner Status

Scope Changes

TSC Applicability

Provider Assurance

Annual Activities

Review:

SOC Scope

Risk Assessment

Policies

Control Inventory

System Description

Subservice Organizations

CUECs

SOC 2 Escalation Matrix

Critical Escalation

Escalate immediately when:

Material Security Incident

Potential Material SOC Exception

Incorrect SOC Scope

Evidence Integrity Concern

Auditor Indicates Possible Modified Opinion

Escalate to:

CISO

Executive Sponsor

Legal

Audit Lead

High Escalation

Examples:

Privileged MFA Gap

Missed Recurring Control

Major Population Gap

Critical Vulnerability SLA Failure

Overdue DR Test

Medium Escalation

Examples:

Evidence Quality Issue

Minor Control Delay

Vendor Assurance Freshness

Evidence Quality Quick Check

Before auditor submission ask:

Does this evidence support the correct control?
Is the source authoritative?
Is the correct period shown?
Is the system in scope?
Is the population complete?
Is the date visible?
Is ownership clear?
Is sensitive data minimized?
Can the auditor understand it without guessing?

Population Quick Check

Before submission ask:

Correct source?
Correct period?
Correct environment?
All transactions included?
Failures included?
Emergency transactions included?
Contractors included where applicable?
Query filters documented?
Completeness validated?

Walkthrough Quick Check

Before every walkthrough confirm:

Control owner present.
Control description reviewed.
Real example available.
Evidence available.
Systems accessible.
Known exceptions understood.
No unsupported claims prepared.

Exception Quick Check

When an auditor raises an exception:

Validate
      ↓
Clarify
      ↓
Confirm
      ↓
Assess Risk
      ↓
Root Cause
      ↓
Management Response
      ↓
Remediation

Do not immediately:

Argue

Accept

Hide

Validate objectively.

SOC 2 Operational Dashboard

Recommended metrics:

Metric	Target
Control Evidence Completion	100%
Controls Operating Effectively	100%
Population Validation	100%
Overdue Critical Evidence	0
High Readiness Gaps	0
Overdue High Findings	0
Auditor Requests On Time	100%
Evidence Accepted Without Rework	≥95%
Repeat High Findings	0

Key Risk Indicators

Track:

Controls Missing Evidence

Recurring Controls Missed

Population Reconciliation Failures

Critical Provider Assurance Stale

Open High Audit Findings

Failed Retests

Material Scope Changes

SOC 2 Master Operational Checklist

Program

SOC objective confirmed.
report type confirmed.
target period confirmed.
executive sponsor assigned.
timeline established.

Scope

services identified.
systems identified.
infrastructure identified.
people identified.
procedures identified.
data identified.
subservices identified.
CUECs identified.

TSC

Security included.
optional categories assessed.
applicability documented.

Controls

control inventory complete.
control statements testable.
owners assigned.
operators identified.
frequencies defined.
effective dates documented.

Evidence

evidence matrix complete.
authoritative sources identified.
retention adequate.
repository established.
evidence calendar established.
evidence quality reviewed.

Populations

populations defined.
sources documented.
query logic documented.
completeness validated.
failures included.

Readiness

design tested.
implementation validated.
walkthroughs completed.
operating effectiveness tested.
gaps documented.
remediation completed.
material gaps retested.

Audit

kickoff complete.
PBC tracker active.
walkthrough schedule active.
populations submitted.
samples tracked.
follow-ups tracked.
exceptions managed.
responses reviewed.

Report

opinion reviewed.
system description reviewed.
scope validated.
controls validated.
exceptions validated.
CUECs reviewed.
subservices reviewed.
final approvals received.

Post-Audit

final report stored.
findings transferred.
remediation tracked.
lessons learned complete.
continuous evidence restarted.
next audit cycle planned.

GRC Analyst Operational Responsibilities

The GRC analyst operating this runbook is responsible for coordinating:

SOC Strategy

Scope

Control Library

Evidence

Populations

Readiness

Auditor Requests

Walkthroughs

Samples

Exceptions

Management Responses

Report Review

Post-Audit Improvement

The analyst is not necessarily the person who operates every control.

Instead, GRC creates the assurance chain:

Requirement
      ↓
Risk
      ↓
Control
      ↓
Owner
      ↓
Operation
      ↓
Evidence
      ↓
Testing
      ↓
Finding
      ↓
Remediation
      ↓
Assurance

Runbook Success Criteria

This runbook has been executed successfully when the organization can demonstrate:

Correct SOC Scope
      ↓
Appropriate TSC Selection
      ↓
Complete Control Inventory
      ↓
Known Control Owners
      ↓
Reliable Evidence
      ↓
Complete Populations
      ↓
Readiness Testing
      ↓
Managed Findings
      ↓
Controlled Auditor Interaction
      ↓
Accurate SOC Report

The strongest indicator of maturity is simple:

When the auditor requests evidence, the organization does not need to create the evidence—it only needs to retrieve and validate it.

What’s Next?

➡️ Next: Runbook 02 — SOC 2 Report Review, Exception Assessment & Vendor Assurance

In the final runbook for this module, you will move to the customer and third-party assurance side of SOC 2 and create an operational process for reviewing external provider SOC reports.

The runbook will cover:

SOC Report Intake
      ↓
Report Type Validation
      ↓
Scope Review
      ↓
TSC Coverage
      ↓
Period & Freshness
      ↓
Auditor Opinion
      ↓
Exception Analysis
      ↓
Management Response
      ↓
CUECs
      ↓
Subservice Organizations
      ↓
Residual Risk
      ↓
Vendor Approval Decision