SOC 2 Compliance Gap Analysis

Map NIST CSF controls to SOC 2 criteria and build a remediation roadmap.

Introduction

30 Second Summary

Imagine you're about to have your house inspected before a big sale. You would not wait for the inspector to find every crack and loose wire. You would walk through yourself first, note what needs fixing, and prioritize repairs before inspection day.

In this project, you will perform a SOC 2 compliance gap analysis for a fictional SaaS company. You will map their existing security controls to SOC 2 audit criteria, identify gaps, and build a prioritized remediation plan.

What You'll Build

You will produce a complete SOC 2 gap analysis package for "CloudTask," a fictional SaaS startup preparing for its first SOC 2 Type II audit.

By the end of this project, you'll have:

A control matrix mapping existing NIST CSF controls to all nine SOC 2 Common Criteria categories (CC1-CC9).
A gap analysis with severity-rated findings and specific evidence requirements for each compliance gap.
A prioritized remediation roadmap with owners, timelines, dependencies, and target dates ready for stakeholder review.
Secret Mission: Write an executive readiness summary with a compliance score, top risks, and a go/no-go recommendation for engaging the auditor.

Are there any prerequisites?

This project assumes basic cybersecurity knowledge (the CIA triad, threats, and controls) and familiarity with NIST CSF 2.0 functions and categories. If you have completed a NIST CSF risk assessment before, you are ready to go.

Set Up Your Workspace

A SOC 2 gap analysis produces multiple deliverables that build on each other. Your control matrix feeds your gap findings, and your gap findings feed your remediation plan.

To keep everything organized, you'll create a single Google Sheets workbook with dedicated tabs for each deliverable. In this step, you'll build the workbook structure and pre-populate it with the SOC 2 Common Criteria categories that form the backbone of your entire analysis.

In this step, get ready to:

Create a Google Sheets workbook with four dedicated tabs.
Set up the Control Matrix tab with structured column headers.
Populate all nine SOC 2 Common Criteria categories (CC1-CC9).

Create your Google Sheets workbook

Your gap analysis workbook needs four distinct tabs, one for each deliverable in your analysis package. Each tab holds a different stage of the assessment process.

Open Google Sheets by navigating to sheets.google.com in your browser.
Click the Blank spreadsheet option (the large "+" icon) to create a new workbook.
Click on the title field in the top-left corner (it says "Untitled spreadsheet") and rename it to CloudTask SOC 2 Gap Analysis.

Now you need four tabs. The default tab ("Sheet1") will become your first one.

Double-click the Sheet1 tab at the bottom of the screen and rename it to Scope and System Description.
Click the + icon to the left of the tab bar to add a new tab. Rename it to Control Matrix.
Add a third tab and rename it to Gap Analysis.
Add a fourth tab and rename it to Remediation Roadmap.

Why four separate tabs?

Each tab represents a distinct deliverable in a professional gap analysis package. Keeping them separate makes it easy to share individual sections with stakeholders who only need to see specific parts.

For example, a CISO might only review the Remediation Roadmap, while an auditor focuses on the Control Matrix.

You should now see four tabs at the bottom of your workbook: Scope and System Description, Control Matrix, Gap Analysis, and Remediation Roadmap.

Tabs not showing at the bottom?

If you don't see your tabs, scroll down to the very bottom of the browser window. The tab bar sits below the grid area. Make sure you're clicking the "+" icon in the tab bar, not the "+" button on the toolbar.

Help me find the tab bar in Google Sheets

Set up the Control Matrix columns

The Control Matrix is the core artifact in your gap analysis. It maps each SOC 2 criterion to your existing controls and tracks whether those controls satisfy the requirement. The columns you set up here define the information you'll collect for every single criterion.

Click the Control Matrix tab at the bottom of your workbook to switch to it.
In row 1, enter the following column headers across cells A1 through H1:

A1: SOC 2 Criteria ID.
B1: SOC 2 Criteria Description.
C1: NIST CSF Function.
D1: NIST CSF Category/Subcategory.
E1: Existing Control Description.
F1: Control Owner.
G1: Evidence Artifact.
H1: Assessment Status.

What does each column track?

SOC 2 Criteria ID and Description identify what the auditor expects to see.
NIST CSF Function and Category/Subcategory show the cross-framework mapping between NIST CSF 2.0 and SOC 2.
Existing Control Description documents what the company already has in place.
Control Owner names the person accountable for operating the control.
Evidence Artifact specifies the proof an auditor needs to verify the control works.
Assessment Status records whether the control is Fully Satisfied, Partially Satisfied, Not Satisfied, or Not Applicable.

Select the entire header row (click the row number "1" on the left) and bold it using Cmd+B (macOS) or Ctrl+B (Windows).

Populate the Common Criteria categories

The Common Criteria (CC1 through CC9) form the mandatory Security criterion in every SOC 2 audit. These nine categories cover everything from governance and risk to access controls and change management.

Starting in cell A2, enter the following nine criteria IDs down column A (one per row, A2 through A10):

A2: CC1.
A3: CC2.
A4: CC3.
A5: CC4.
A6: CC5.
A7: CC6.
A8: CC7.
A9: CC8.
A10: CC9.

Now enter the corresponding descriptions in column B (B2 through B10):

B2: Control Environment.
B3: Communication and Information.
B4: Risk Assessment.
B5: Monitoring Activities.
B6: Control Activities.
B7: Logical and Physical Access Controls.
B8: System Operations.
B9: Change Management.
B10: Risk Mitigation.

What are the Common Criteria?

CC1 through CC5 are derived from the COSO Internal Control framework (2013), which covers general organizational governance. CC6 through CC9 are supplemental criteria added by the AICPA specifically for technology companies.

Together, these nine categories cover every aspect of how a company protects its systems and data. They are mandatory for every SOC 2 audit regardless of which optional Trust Services Criteria you add.

Your Control Matrix tab should now have a header row with 8 columns and 9 data rows (CC1 through CC9) with their IDs and descriptions filled in.

✔️ Awesome, I've got everything!

Great. Double check that all four tabs are visible at the bottom and that your Control Matrix has CC1 through CC9 with matching descriptions.

ⓧ I'd like to double check the full layout

Here is what your Control Matrix tab should look like. Columns C through H are empty for now. You'll fill those in during the next steps.

Row 1 (headers):

A1: SOC 2 Criteria ID | B1: SOC 2 Criteria Description | C1: NIST CSF Function | D1: NIST CSF Category/Subcategory | E1: Existing Control Description | F1: Control Owner | G1: Evidence Artifact | H1: Assessment Status.

Rows 2-10 (data):

Row 2: CC1 | Control Environment.
Row 3: CC2 | Communication and Information.
Row 4: CC3 | Risk Assessment.
Row 5: CC4 | Monitoring Activities.
Row 6: CC5 | Control Activities.
Row 7: CC6 | Logical and Physical Access Controls.
Row 8: CC7 | System Operations.
Row 9: CC8 | Change Management.
Row 10: CC9 | Risk Mitigation.

Your other three tabs (Scope and System Description, Gap Analysis, Remediation Roadmap) should be empty for now.

Columns too narrow to see your text?

Select all cells with Cmd+A (macOS) or Ctrl+A (Windows), then go to Format > Column width and set a width that lets you read the full header text. Alternatively, double-click any column border in the header bar to auto-fit.

Help me resize columns in Google Sheets

Your workspace is ready. Next up, you'll define CloudTask's audit scope and document exactly what systems, data, and teams fall within the boundaries of this SOC 2 assessment.

Define the Audit Scope

Your workbook is structured and the Control Matrix has all nine Common Criteria categories ready to go.

Before mapping any controls, an auditor needs to know exactly what they're looking at. A SOC 2 audit scope defines which systems, data types, teams, and third parties are included in the assessment.

In this step, you'll document CloudTask's system boundaries, choose which Trust Services Criteria apply to the audit, and map how customer data flows through the infrastructure.

In this step, get ready to:

Document CloudTask's full system description including infrastructure, data types, teams, and third-party dependencies.
Select and justify the Trust Services Criteria that apply to CloudTask's audit.
Create a data flow description showing how customer data moves through the system.

Document CloudTask's system description

A system description tells the auditor exactly what is being assessed. It covers the service itself, the infrastructure it runs on, the data it processes, the teams responsible, and any external parties involved.

Switch to the Scope and System Description tab in your workbook.
In cell A1, type System Description as a section header and bold it.

Below the header, document the following five areas. Use one row per area, with the category label in column A and the details in column B.

In the Services in Scope row, enter: CloudTask SaaS platform - a cloud-based project management tool for teams.
In the Infrastructure row, enter: AWS-hosted. Uses RDS for database, S3 for file storage, CloudFront for CDN.
In the Data Types Processed row, enter: Customer PII including names, emails, project files, and payment card tokens via Stripe.
In the Organizational Boundaries row, enter: Engineering, DevOps, and Customer Support teams.
In the Third-Party Dependencies row, enter: AWS (infrastructure), Stripe (payment processing), SendGrid (email notifications), Okta (employee SSO).

Why does the system description matter?

The system description sets the audit boundary. Anything outside it is out of scope, meaning the auditor will not assess it.

Third-party dependencies are especially important because the auditor will want to see how you manage risk from external vendors like Stripe and AWS. This is where SOC 2's CC9 (Risk Mitigation) becomes relevant.

Select the applicable Trust Services Criteria

SOC 2 has five Trust Services Criteria categories, but only Security is mandatory. You choose additional categories based on the commitments your company makes to customers.

Below your system description, skip a row and type Trust Services Criteria Selection as a new section header in column A. Bold it.
Create a small table with three columns: TSC Category, Included?, and Justification.

Fill in each row with the following criteria decisions:

For Security (Common Criteria CC1-CC9): set Included to Yes - Mandatory. For the justification, enter: Required for all SOC 2 engagements. Covers the foundational Common Criteria (CC1-CC9).
For Availability: set Included to Yes. For the justification, enter: CloudTask has SLA commitments to enterprise customers (99.9% uptime). Availability criteria validate these commitments.
For Processing Integrity: set Included to No. For the justification, enter: CloudTask does not perform complex data transformations or financial calculations. Processing accuracy is not a primary customer commitment.
For Confidentiality: set Included to No. For the justification, enter: No designated confidential information beyond what is covered by Security criteria. May add in a future audit cycle.
For Privacy: set Included to No. For the justification, enter: CloudTask processes PII but does not act as a data controller. Privacy obligations are handled through contractual DPAs rather than SOC 2 Privacy criteria.

Why not include all five criteria?

Adding more criteria increases audit cost, timeline, and the number of controls you need evidence for. Most companies start with Security only (or Security plus one) for their first SOC 2 Type II audit, then expand in future cycles.

CloudTask includes Availability because their enterprise contracts contain a 99.9% uptime SLA. If customers are paying for guaranteed uptime, the auditor needs to verify that controls exist to deliver on that promise.

Create the data flow description

Auditors need to understand how customer data moves through the system. A data flow shows the path from the user's browser through your infrastructure to storage and external services.

Below your TSC selection table, skip a row and type Data Flow Description as a new section header in column A. Bold it.
In the rows below, document CloudTask's data flow as a text-based description. Enter each connection on its own row.

Enter the following data flow paths, one per row:

Row 1: User browser connects to CloudFront CDN (content delivery and SSL termination).
Row 2: CloudFront routes requests to application servers (AWS EC2/ECS).
Row 3: Application servers connect to RDS database (customer data, project metadata).
Row 4: Application servers connect to S3 storage (uploaded project files).
Row 5: Stripe handles payment processing externally (payment card tokens, no raw card data stored).
Row 6: Okta handles employee authentication (SSO for internal staff access).
Row 7: SendGrid sends transactional emails (notifications, password resets).

Why include third-party services in the data flow?

Every external service that touches customer data is a potential risk vector. The auditor will want to verify that CloudTask has vendor management controls (CC9) in place for each dependency.

Notice that Stripe handles raw card data externally. This means CloudTask stores only tokenized references, which reduces their PCI DSS scope significantly.

Make it visual if you have time

You can use Google Sheets' built-in drawing tool (Insert then Drawing) to create a simple box-and-arrow diagram alongside your text description. Text is sufficient for this exercise, but a visual diagram adds polish to a real deliverable.

Review your completed tab to confirm all three sections are present: system description, TSC selection table, and data flow.

Your audit boundaries are clearly defined. The auditor now knows exactly what systems, data, and teams are in scope. Next, you'll build the control matrix by mapping CloudTask's existing NIST CSF controls to each of the nine Common Criteria categories.

Build the Control Matrix

Your audit scope is locked in. CloudTask's system boundaries, data flows, and Trust Services Criteria selections are all documented and ready for the next phase.

Now it's time to connect CloudTask's existing security controls to the SOC 2 Common Criteria. Cross-framework control mapping is the core skill that transforms a generic security program into audit-ready evidence.

In this step, get ready to:

Map CloudTask's existing NIST CSF controls to each of the nine SOC 2 Common Criteria categories.
Assign control owners and identify the evidence artifacts an auditor would request.
Rate each control's assessment status based on documentation and evidence availability.

Map existing controls to SOC 2 criteria

Each SOC 2 Common Criteria category corresponds to one or more NIST CSF functions. Your job is to document what controls CloudTask already has from their earlier NIST CSF risk assessment, then map each control to the SOC 2 criterion it satisfies.

Why is this a many-to-many relationship?

A single NIST CSF subcategory can satisfy multiple SOC 2 criteria, and a single SOC 2 criterion may require evidence from multiple NIST CSF functions. The mapping is not one-to-one.

The AICPA publishes an official mapping spreadsheet that connects the Trust Services Criteria to NIST CSF. Your control matrix mirrors this same cross-referencing process that GRC analysts perform in practice.

Switch to the Control Matrix tab in your workbook.
For each CC row (CC1 through CC9), fill in the NIST CSF Function, NIST CSF Category/Subcategory, and Existing Control Description columns using the mappings below.

Use this reference to fill in each row:

CC1 (Control Environment) — NIST CSF Function: Govern (GV). Existing Control: CloudTask has a security policy, defined roles, and annual security awareness training.
CC2 (Communication and Information) — NIST CSF Function: Govern (GV). Existing Control: CloudTask has an internal wiki with security policies and quarterly all-hands security updates.
CC3 (Risk Assessment) — NIST CSF Function: Identify (ID.RA). Existing Control: CloudTask has a risk register from their NIST CSF risk assessment.
CC4 (Monitoring Activities) — NIST CSF Function: Detect (DE). Existing Control: CloudTask uses AWS CloudWatch for infrastructure monitoring.
CC5 (Control Activities) — NIST CSF Function: Protect (PR). Existing Control: CloudTask has documented procedures for key security processes.
CC6 (Logical and Physical Access Controls) — NIST CSF Function: Protect (PR.AC/PR.AA). Existing Control: CloudTask uses Okta SSO with MFA for employee access and conducts quarterly access reviews.
CC7 (System Operations) — NIST CSF Functions: Detect (DE) and Respond (RS). Existing Control: CloudTask has an incident response plan and uses PagerDuty for alerting.
CC8 (Change Management) — NIST CSF Function: Protect (PR). Existing Control: CloudTask uses GitHub pull requests with required code reviews before merge.
CC9 (Risk Mitigation) — NIST CSF Functions: Identify (ID) and Recover (RC). Existing Control: CloudTask has vendor risk assessments for critical third parties and basic business continuity planning.

What do these mappings tell us?

The NIST CSF Govern (GV) function feeds into CC1 and CC2 because governance and communication are foundational to the control environment. The Protect (PR) function maps to CC5, CC6, and CC8 because protective controls span access management, operational procedures, and change management.

CC7 draws from both Detect (DE) and Respond (RS) because system operations requires both monitoring for anomalies and having a plan to respond when something goes wrong.

Assign control owners and evidence artifacts

Every control in a SOC 2 audit needs an assigned owner who is accountable for maintaining the control and producing evidence when the auditor asks. The evidence artifact is the specific document, log, or report that proves the control operates as described.

For each CC row, fill in the Control Owner and Evidence Artifact columns using the assignments below.

CC1 — Owner: VP Engineering. Evidence: Security policy document and training completion records.
CC2 — Owner: Security Lead. Evidence: Wiki screenshots and meeting notes from quarterly all-hands.
CC3 — Owner: Security Lead. Evidence: Risk register spreadsheet.
CC4 — Owner: DevOps Manager. Evidence: CloudWatch dashboards and alert configurations.
CC5 — Owner: VP Engineering. Evidence: Procedure documents.
CC6 — Owner: Security Lead. Evidence: Okta access logs and access review reports.
CC7 — Owner: DevOps Manager. Evidence: IR plan document and PagerDuty alert history.
CC8 — Owner: VP Engineering. Evidence: GitHub PR approval history.
CC9 — Owner: Security Lead. Evidence: Vendor assessment documents and BCP document.

Why are evidence artifacts so specific?

An auditor will not accept "we have access controls" as proof. They need a specific, retrievable artifact like "Okta access logs showing quarterly user access reviews with manager approval timestamps." The more specific you are now, the faster evidence collection goes during the actual audit.

Set the assessment status for each control

The assessment status tells you how ready each control is for the auditor. A control can exist in practice but still fail an audit if it lacks formal documentation or consistent evidence.

For each CC row, fill in the Assessment Status column using the following ratings and rationale.

What do the status ratings mean?

Fully Satisfied — a documented control exists AND evidence is available to prove it operates effectively.
Partially Satisfied — the practice exists but is informal, undocumented, or missing consistent evidence.
Not Satisfied — no control exists for that criterion.

Enter the following statuses for each row:
CC1 — Partially Satisfied. Security policy exists but training lacks completion tracking.
CC2 — Partially Satisfied. Wiki exists but policies lack version control and formal acknowledgment records.
CC3 — Fully Satisfied. Risk register is documented and current from the NIST CSF assessment.
CC4 — Partially Satisfied. CloudWatch is running but alert thresholds are not formally documented.
CC5 — Partially Satisfied. Procedures exist but have not been reviewed or tested in over a year.
CC6 — Partially Satisfied. Okta SSO and MFA are in place, but access reviews lack formal documentation of removal actions.
CC7 — Partially Satisfied. Incident response plan exists but has never been tested through a tabletop exercise.
CC8 — Fully Satisfied. GitHub enforces required code reviews with a clear approval history trail.
CC9 — Partially Satisfied. Vendor assessments exist for critical third parties but the BCP has not been updated in 18 months.

Why are most controls only Partially Satisfied?

This is realistic for a startup preparing for its first audit. CloudTask has done the right things operationally, but lacks the formal documentation, testing evidence, and consistent record-keeping that an auditor needs to see. SOC 2 is principles-based, meaning the auditor needs proof that controls operate effectively over time, not just that they exist on paper.

✔️ Awesome, I've got everything!

Great. Double check that every row from CC1 through CC9 has all six columns filled in: NIST CSF Function, NIST CSF Category/Subcategory, Existing Control Description, Control Owner, Evidence Artifact, and Assessment Status.

ⓧ I'd like to double check the full matrix

Here is the complete Control Matrix for reference:

CC1 | Govern (GV) | Security policy, defined roles, annual security awareness training | VP Engineering | Policy doc + training records | Partially Satisfied.
CC2 | Govern (GV) | Internal wiki + quarterly all-hands updates | Security Lead | Wiki screenshots + meeting notes | Partially Satisfied.
CC3 | Identify (ID.RA) | Risk register from NIST CSF assessment | Security Lead | Risk register spreadsheet | Fully Satisfied.
CC4 | Detect (DE) | AWS CloudWatch monitoring | DevOps Manager | CloudWatch dashboards + alert configs | Partially Satisfied.
CC5 | Protect (PR) | Documented procedures for key security processes | VP Engineering | Procedure documents | Partially Satisfied.
CC6 | Protect (PR.AC/PR.AA) | Okta SSO with MFA + quarterly access reviews | Security Lead | Okta access logs + access review reports | Partially Satisfied.
CC7 | Detect (DE) / Respond (RS) | Incident response plan + PagerDuty alerting | DevOps Manager | IR plan doc + PagerDuty alert history | Partially Satisfied.
CC8 | Protect (PR) | GitHub PRs with required code reviews | VP Engineering | GitHub PR approval history | Fully Satisfied.
CC9 | Identify (ID) / Recover (RC) | Vendor risk assessments + basic BCP | Security Lead | Vendor assessment docs + BCP document | Partially Satisfied.

Your control matrix is complete. You now have a clear picture of where CloudTask stands against each SOC 2 criterion. Next up, you will turn every "Partially Satisfied" and "Not Satisfied" control into a formal gap finding with severity ratings and evidence requirements.

Perform the Gap Analysis

Your Control Matrix now tells you exactly where CloudTask stands. Some controls are fully in place, but most are only partially satisfied.

In this step, you will translate those partial controls into a formal gap analysis. Each gap becomes a documented finding with a severity rating and a specific evidence requirement that tells the auditor exactly what "fixed" looks like.

In this step, get ready to:

Set up the Gap Analysis tab with structured columns and create entries for each compliance gap.
Rate each gap by severity using a Critical/High/Medium/Low scale.
Document the specific evidence an auditor would need to see for each gap to be considered closed.

Set up the Gap Analysis tab and create gap entries

A gap analysis converts vague "we're not quite compliant" findings into structured, actionable records. Each gap needs enough detail that someone unfamiliar with the assessment could understand what is missing and why it matters.

Switch to the Gap Analysis tab in your workbook.
In Row 1, create the following column headers:

A1: Gap ID.
B1: SOC 2 Criteria Reference.
C1: Gap Description.
D1: Current State.
E1: Target State.
F1: Severity.
G1: Evidence Required.

Bold Row 1 so the headers stand out from the data rows.

What is a Gap ID?

A Gap ID is a unique identifier you assign to each finding (e.g., GAP-001, GAP-002). It lets you reference specific gaps in your remediation roadmap without repeating the full description every time.

Now you need to populate this tab with one row for each compliance gap. Look at your Control Matrix tab and find every row marked "Partially Satisfied" or "Not Satisfied" in the Assessment Status column.

Return to your Control Matrix tab and identify the criteria marked Partially Satisfied: CC1, CC2, CC4, CC5, CC6, CC7, and CC9.
Switch back to the Gap Analysis tab.
For each Partially Satisfied criterion, create one or more gap entries. Some criteria will have multiple gaps because the control exists in some form but is missing key components.

Here is an example of how to fill in a gap row for CC7 (System Operations):

Gap ID: GAP-001.
SOC 2 Criteria Reference: CC7 - System Operations.
Gap Description: Incident response plan exists but has never been tested through a tabletop exercise or simulation.
Current State: IRP documented in wiki; PagerDuty configured for alerting; no test exercises conducted.
Target State: IRP tested at least annually with documented results, lessons learned, and plan updates.
Severity: Leave blank for now (you will rate it in the next substep).
Evidence Required: Leave blank for now (you will document it in the final substep).

Use this example as your template and create gap entries for each Partially Satisfied criterion. Aim for 8-12 total gaps across CC1, CC2, CC4, CC5, CC6, CC7, and CC9.

Why might one CC have multiple gaps?

A single CC category covers several related requirements. For example, CC6 (Logical and Physical Access Controls) covers user provisioning, access reviews, and termination procedures. CloudTask might have Okta SSO configured (user provisioning works) but lack evidence of quarterly access reviews (a separate gap).

Here are suggested gaps to guide your work. You can use these directly or adapt them based on your Control Matrix:

CC1: Security awareness training exists but lacks formal completion tracking and annual refresh evidence.
CC2: Security policies published on internal wiki but not formally reviewed or version-controlled on a defined schedule.
CC4: AWS CloudWatch alerts configured but no documented response procedures for each alert type.
CC5: Key security procedures documented but no periodic testing to validate they are followed.
CC6 (gap 1): Quarterly access reviews not producing documented evidence of reviewer decisions.
CC6 (gap 2): No formal user deprovisioning SLA. Terminated employee access removal not tracked.
CC7 (gap 1): Incident response plan never tested through a tabletop exercise or simulation.
CC7 (gap 2): No formal incident classification scheme. Severity levels not defined.
CC9 (gap 1): Business continuity plan not formally approved by leadership or tested.
CC9 (gap 2): Vendor risk assessments completed for critical third parties but no defined reassessment cadence.

Fill in the Gap ID, SOC 2 Criteria Reference, Gap Description, Current State, and Target State columns for each gap you create.

Current State vs. Target State

Current State describes what CloudTask does today (even if informal or incomplete). Target State describes what the auditor expects to see operating effectively. The gap between these two is what remediation must close.

Rate each gap by severity

Not all gaps carry the same risk. A missing access review process could result in an audit exception, while a policy that is slightly overdue for review is a minor improvement opportunity. Severity ratings help the compliance team prioritize what to fix first.

Go to the Severity column (F) in your Gap Analysis tab.
Rate each gap using the following four-level scale:

Critical: Gap would prevent the audit from proceeding. Example: no documented risk assessment process, no access review evidence.
High: Gap would likely result in an audit exception. Example: incident response plan exists but has never been tested.
Medium: Gap needs remediation but will not block the audit. Example: security awareness training lacks completion tracking.
Low: Minor improvement opportunity. Example: policies exist but were last reviewed 18 months ago.

Apply a severity rating to each gap in your tab. Your distribution should include at least 2 gaps rated Critical or High, several Medium gaps, and at least 1 Low gap.

Why does severity distribution matter?

If every gap is rated Critical, you have not differentiated risk. A real gap analysis helps leadership understand which items are blockers versus nice-to-haves. Auditors also look at your self-assessment to judge organizational maturity.

For CloudTask, the BCP not being tested or approved (CC9) is Critical because it indicates a fundamental process gap. A policy review being 6 months overdue (CC2) is Low because the policy exists and is accessible.

Here is a suggested severity assignment for the gaps listed above:

CC9 BCP not tested or approved: Critical.
CC6 access review evidence missing: High.
CC7 incident response plan never tested: High.
CC4 CloudWatch alerts lack response procedures: Medium.
CC5 security procedures not periodically tested: Medium.
CC6 no deprovisioning SLA: Medium.
CC7 no incident classification scheme: Medium.
CC1 training lacks completion tracking: Medium.
CC9 vendor reassessment cadence undefined: Medium.
CC2 policies not reviewed on schedule: Low.

Adjust these ratings if your specific gap descriptions warrant a different level. The key is that your reasoning is defensible.

Document evidence requirements for each gap

An auditor does not accept "we fixed it" as proof. They need specific, verifiable evidence artifacts. The more precise your evidence requirements, the easier it is for control owners to know exactly what to produce during remediation.

Go to the Evidence Required column (G) in your Gap Analysis tab.
For each gap, write a specific description of what documentation or records the auditor would need to see. Avoid vague language like "access control documentation."

What makes a good evidence requirement?

Good evidence is specific, time-bounded, and names the artifact format. Compare these two:

Vague: "Access control documentation." Specific: "Quarterly access review report showing all active users reviewed, terminated users removed within 24 hours, and manager approval documented for each access decision."

The specific version tells a control owner exactly what to produce. This eliminates back-and-forth during the audit.

Here are example evidence requirements for your key gaps:

CC6 access review gap: Quarterly access review report showing all active users reviewed, terminated users removed within 24 hours, and manager approval documented for each access decision.
CC7 IRP never tested: Tabletop exercise report with date, participants, scenario description, response actions taken, identified gaps, and documented plan updates resulting from the exercise.
CC1 training completion: LMS or spreadsheet showing each employee's training completion date, quiz score, and annual refresh status. Signed acknowledgment of security policy for new hires.
CC9 BCP not tested: Formally approved BCP document with executive sign-off, DR test report showing recovery time achieved versus RTO/RPO targets, and post-test action items.
CC4 alert response procedures: Documented runbook for each critical alert type showing escalation path, response steps, resolution criteria, and sample resolved incident tickets demonstrating the runbook was followed.
CC2 policy review schedule: Version-controlled policy documents with review dates, approver names, and change log showing updates made during each review cycle.

Write similarly specific evidence requirements for all remaining gaps in your tab.
Review your completed Gap Analysis tab. You should have 8-12 rows, each with all seven columns filled in.

Think like the auditor

For each evidence requirement, ask yourself: "If I were the auditor, could I verify this control is working from this artifact alone?" If the answer is no, add more specificity. Auditors want to see that controls operate over time, not just that they exist at a single point.

✔️ Awesome, I've got everything!

Great. Double check that every row has all seven columns filled and that your severity distribution looks realistic (not everything is the same level).

ⓧ I'd like to double check my work

Here is what your completed Gap Analysis tab should look like. Your specific wording may differ, but the structure and distribution should be similar:

7 columns across: Gap ID, SOC 2 Criteria Reference, Gap Description, Current State, Target State, Severity, Evidence Required.
8-12 data rows covering CC1, CC2, CC4, CC5, CC6, CC7, and CC9.
At least 1 Critical gap (CC9 BCP) and 2 High gaps (CC6 access reviews, CC7 IRP testing).
Several Medium gaps spread across remaining criteria.
At least 1 Low gap (CC2 policy review schedule).
Every Evidence Required cell contains a specific, auditor-ready description naming the artifact type, time period, and what it must demonstrate.

Your gap analysis is complete. You now have a clear picture of exactly where CloudTask falls short of SOC 2 requirements. Next, you will turn these findings into an actionable remediation roadmap with owners, timelines, and dependencies.

Create the Remediation Roadmap

Your gap analysis has identified exactly where CloudTask falls short of SOC 2 compliance. Now you need to turn those findings into a plan that someone can actually execute.

A remediation roadmap transforms compliance gaps into a prioritized project plan with named owners, effort estimates, and deadlines. This is the deliverable that a compliance lead hands to engineering managers so work actually gets scheduled.

In this step, get ready to:

Set up your Remediation Roadmap tab with columns for tracking actions, owners, and timelines.
Prioritize gaps by severity and effort to determine scheduling order.
Document dependencies between gaps and set realistic target completion dates.

Set up columns and transfer your gaps

Every gap from your analysis needs a corresponding remediation action. The roadmap tab acts as a project tracker that links each gap back to its source finding.

Switch to the Remediation Roadmap tab in your workbook.
In Row 1, create the following column headers:

Column A: Gap ID (this links back to your Gap Analysis tab).
Column B: Remediation Action.
Column C: Owner.
Column D: Effort Estimate (hours).
Column E: Dependencies.
Column F: Target Completion Date.
Column G: Status (values: Not Started / In Progress / Complete).

Transfer every Gap ID from your Gap Analysis tab into Column A. Each gap gets its own row.
For each gap, write a specific remediation action in Column B. This should describe exactly what work needs to happen to close the gap.
Set the Status column to Not Started for every row.

What makes a good remediation action?

A remediation action should be specific enough that someone could start working on it without asking follow-up questions.

For example, instead of writing "fix access reviews," write "implement automated quarterly access review process in Okta with manager approval workflow and export report to PDF for evidence collection."

Assign an Owner to each remediation action. Use role titles that make sense for a 30-person startup: VP Engineering, Security Lead, DevOps Manager, or Engineering Manager.

Match owners to expertise

Assign owners based on who controls the system or process involved. Access control gaps (CC6) go to whoever manages Okta. Change management gaps (CC8) go to the engineering lead who owns the GitHub workflow. Policy gaps (CC1, CC2) go to the Security Lead.

Prioritize by severity and effort

Not all gaps are equal. A Critical gap that blocks the audit entirely needs to be fixed before a Low-severity policy refresh.

Review each gap's severity rating from your Gap Analysis tab.
Set effort estimates in Column D using hours. Be realistic for a 30-person startup where security is not anyone's full-time job.

Use the following prioritization logic to assign target completion dates:

Critical and High severity gaps with low effort (under 20 hours): target dates within 2 weeks from today.
Medium severity gaps: target dates within 4 weeks from today.
Low severity gaps: target dates within 6 weeks from today.

Enter target completion dates in Column F using a specific date format (e.g., 2026-06-29 for a 2-week target).
If a Critical or High gap requires significant effort (over 40 hours), it still gets priority but its target date may extend to 3-4 weeks to stay realistic.

Why severity-first, then effort?

Critical gaps can prevent the audit from proceeding entirely. If a low-effort Critical gap exists, fixing it first removes a blocker at minimal cost.

This is the same logic incident responders use: triage by impact first, then by ease of resolution.

Document dependencies and adjust target dates

Some gaps cannot be fixed independently. A gap in CC9 (Risk Mitigation) may require that CC3 (Risk Assessment) is remediated first, because you cannot mitigate risks you have not formally assessed.

Review each gap and ask: does closing this gap require another gap to be closed first?
Document dependencies in Column E. Reference the Gap ID of the prerequisite item (e.g., Depends on GAP-003).
If a gap has no dependencies, enter None in Column E.

Here are common dependency patterns to look for:

CC3 (Risk Assessment) must complete before CC9 (Risk Mitigation) can be fully addressed.
CC1 (Control Environment) policy updates may need to complete before CC5 (Control Activities) procedures can reference them.
CC4 (Monitoring Activities) improvements may depend on CC7 (System Operations) tooling being in place.

Adjust target completion dates for any dependent gaps. A dependent gap's target date must be later than its prerequisite's target date.
Verify that your roadmap reads logically from top to bottom. A compliance lead should be able to hand this to an engineering team and have them start work immediately.

What does a well-sequenced roadmap look like?

Your Critical and High gaps with no dependencies appear first with the earliest target dates. Dependent items appear later with dates that account for prerequisite completion.

The roadmap should show a clear "wave" pattern: quick wins in weeks 1-2, core remediation in weeks 2-4, and refinements in weeks 4-6.

Not sure what effort estimates to use?

For a 30-person startup, these are realistic ranges: writing or updating a policy document takes 8-16 hours. Implementing a new tool or process takes 20-40 hours. Building automated evidence collection takes 40-80 hours.

If you are stuck, help me estimate realistic effort for SOC 2 remediation actions at a small startup.

Review your completed roadmap one final time. Every gap from your Gap Analysis tab should have a corresponding row with all seven columns filled in.

Secret mission

Write the Executive Readiness Summary

You have a full gap analysis package. Now translate it into something a VP or board member would actually read. Write a two-page executive readiness summary with a compliance score, top risks in business language, and a go/no-go recommendation for engaging the auditor.

Clean Up Your Resources

This project runs entirely in Google Sheets, so there are no ongoing costs or cloud resources to manage.

Decide whether to keep your workbook as a portfolio piece, extend it with additional criteria, or delete it entirely.

Resources you used:

One Google Sheets workbook ("CloudTask SOC 2 Gap Analysis") with five tabs.

Keep everything running

No action needed. Choose this if you want to keep your gap analysis as a portfolio piece or reference for future projects.

Share a view-only link to the workbook in job applications to demonstrate your cross-framework compliance mapping skills.
Consider duplicating the workbook before making further edits so you preserve the original deliverable.

Pause - I'll come back to this later

Google Sheets saves automatically and costs nothing to store. There is nothing to pause.

Your workbook will be waiting in Google Drive whenever you return.

Delete - I don't want to use this again

Remove the workbook entirely from your Google Drive.

Open Google Drive.
Find the workbook named "CloudTask SOC 2 Gap Analysis".
Right-click the file and select Move to trash.
To permanently delete it, open Trash in the left sidebar, right-click the file, and select Delete forever.

Nice Work!

You just completed a full SOC 2 compliance gap analysis for a fictional SaaS company. This is the exact deliverable GRC analysts produce when preparing organizations for their first audit.

You've learned how to:

Map existing NIST CSF controls to SOC 2 Common Criteria (CC1-CC9), demonstrating cross-framework compliance skills that appear in nearly every GRC analyst job posting.
Perform a gap analysis with severity-rated findings and specific evidence requirements that an auditor would accept.
Build a prioritized remediation roadmap with named owners, effort estimates, dependencies, and target completion dates ready for immediate execution.
Secret Mission: Wrote an executive readiness summary translating technical compliance findings into business risk language for leadership review.

Ready to quiz yourself?