SOC 2 Risk Assessment and Gap Analysis

Build a GRC portfolio with a risk register, control mapping, and gap analysis.

Introduction

30 Second Summary

Every company that handles sensitive customer data eventually faces a moment where a big client says: "Prove your security is up to standard." For B2B software companies, that proof usually means passing a SOC 2 audit.

In this project, you will role-play as a GRC Analyst conducting a full risk assessment and compliance gap analysis for a fictional fintech startup that needs SOC 2 readiness within 12 months.

What You'll Build

You will build a professional GRC portfolio on GitHub containing a risk register, control mapping matrix, gap analysis, and executive summary for a fictional company called NovaPay Solutions.

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

  • A completed risk register with 15+ scored cybersecurity risks using a qualitative 5x5 likelihood/impact matrix aligned to NIST SP 800-30.
  • A control mapping that cross-references NIST CSF 2.0 functions to SOC 2 Trust Services Criteria.
  • A gap analysis with a prioritized remediation roadmap (0-30, 30-90, 90+ days) ready to present to leadership.
  • Secret Mission: Conduct a third-party vendor risk assessment for NovaPay's critical SaaS dependencies.

Are there any prerequisites?

You need a GitHub account (free) and a Google account for Google Sheets (free). No prior GRC or cybersecurity experience is required.

Set Up Your GRC Repository and Workspace

Every professional GRC engagement starts with a structured workspace. Before you can assess risks, map controls, or write a gap analysis, you need a central location where all your deliverables live together and tell a coherent story.

In this step, you will create a GitHub repository that mirrors how a real GRC analyst organizes compliance documentation. You will also set up your risk register spreadsheet in Google Sheets, ready for scoring in the next step.

In this step, get ready to:
  • Create a GitHub repository with a professional folder structure for your GRC portfolio.
  • Document NovaPay Solutions' company profile, ISMS scope, and key assets.
  • Set up the risk register spreadsheet template with all required columns.
Create the GitHub repository

Your repository will serve as both your working project space and a portfolio piece that demonstrates your GRC skills to hiring managers.

  • Open github.com in your browser and sign in to your account.
  • Click the + icon in the top-right corner of the page.
  • Select New repository from the dropdown.
  • Enter grc-soc2-readiness-assessment in the Repository name field.
  • Set the visibility to Public.
  • Check the box for Add a README file.
  • Click Create repository.

GitHub will create your repository and open it with a default README.md file.

Why a public repository?

A public repository lets recruiters and hiring managers view your work directly. GRC portfolios on GitHub demonstrate practical skills more effectively than listing certifications alone.

Now you will update the README with a proper project description. This is the first thing a visitor sees when they open your repository.

  • Click the pencil icon (edit button) on the README.md file to open the editor.
  • Delete all existing content and replace it with the following:
# GRC SOC 2 Readiness Assessment

A professional GRC portfolio demonstrating SOC 2 readiness assessment for NovaPay Solutions.

**Author:** [[YOURNAME="your name"]]

**Description:** This repository contains a complete SOC 2 readiness assessment including risk register, control mapping, gap analysis, and executive summary for NovaPay Solutions, a fictional B2B SaaS fintech startup.

What does this README do?

The README acts as the landing page for your repository. It immediately tells a visitor what the project is, who created it, and what deliverables they will find inside.

  • Click Commit changes.
  • In the commit message field, type Update README with project description.
  • Click Commit changes to save.

Next, create the folder structure. On GitHub, folders are created by including a / in the file name when you add a new file.

  • From your repository's main page, click the Add file dropdown above the file list.
  • Click Create new file.
  • In the file name field, type 01_Company_Profile/.gitkeep. GitHub will automatically create the folder when you include the / separator.
  • Leave the file contents empty.
  • Click Commit changes, then Commit changes again in the dialog.
  • Repeat this process for the remaining four folders, creating one .gitkeep file in each:
  • 02_Risk_Assessment/.gitkeep
  • 03_Control_Mapping/.gitkeep
  • 04_Gap_Analysis/.gitkeep
  • 05_Executive_Summary/.gitkeep

What is a .gitkeep file?

Git does not track empty folders. A .gitkeep file is a convention that forces Git to preserve the folder structure. The file itself has no content. You will replace these with real documents as you progress through the project.

  • Return to your repository's main page and verify that all five folders appear in the file list.

Don't see all five folders?

Make sure each .gitkeep file was committed successfully. Check that you typed the folder name followed by /.gitkeep (with the forward slash) in the file name field. If a folder is missing, create it now by repeating the Add file process.

Help me fix my repository folder structure.

Create the company profile document

The company profile is the foundation of any GRC engagement. It defines who the organization is, what systems are in scope, and what assets need protection. Auditors read this first to understand the environment.

  • Navigate to the 01_Company_Profile folder in your repository.
  • Click the Add file dropdown, then Create new file.
  • In the file name field, type company-profile.md.
  • Paste the following content into the file editor:
# NovaPay Solutions – Company Profile

## Company Overview
- **Name:** NovaPay Solutions
- **Type:** B2B SaaS Fintech Startup
- **Size:** 50 employees
- **Infrastructure:** AWS-hosted payment processing platform
- **Data:** Handles PCI-sensitive cardholder data
- **Clients:** Mid-market retailers

## ISMS Scope
- Production AWS environment
- Customer data processing systems
- Internal IT systems
- Remote workforce endpoints

## Key Assets
- AWS infrastructure (EC2, RDS, S3)
- Customer transaction database
- Employee endpoints
- Third-party integrations: Stripe, Datadog, Slack

What does this document do?

The Company Overview tells an auditor what NovaPay does and the scale of the environment. The ISMS scope (Information Security Management System scope) defines exactly which systems fall under the SOC 2 audit boundary.

The Key Assets section lists what you are protecting. Every risk you score later will connect back to one of these assets.

  • Click Commit changes.
  • In the commit message field, type Add company profile document.
  • Click Commit changes to save.
  • Verify that company-profile.md now appears inside the 01_Company_Profile folder.

File ended up in the wrong folder?

If company-profile.md is in the root of your repository instead of inside 01_Company_Profile, you may have created the file from the repository root. Delete it, navigate into the 01_Company_Profile folder first, then use Add file from within that folder.

Help me move my file to the correct folder on GitHub.

✔️ Awesome, I've got everything!

Great. Double check you have the README updated and company-profile.md committed inside 01_Company_Profile/.

ⓧ I'd like to double check the full code

Here is what your README.md should look like:

# GRC SOC 2 Readiness Assessment

A professional GRC portfolio demonstrating SOC 2 readiness assessment for NovaPay Solutions.

**Author:** [Your Name]

**Description:** This repository contains a complete SOC 2 readiness assessment including risk register, control mapping, gap analysis, and executive summary for NovaPay Solutions, a fictional B2B SaaS fintech startup.

And here is what 01_Company_Profile/company-profile.md should look like:

# NovaPay Solutions – Company Profile

## Company Overview
- **Name:** NovaPay Solutions
- **Type:** B2B SaaS Fintech Startup
- **Size:** 50 employees
- **Infrastructure:** AWS-hosted payment processing platform
- **Data:** Handles PCI-sensitive cardholder data
- **Clients:** Mid-market retailers

## ISMS Scope
- Production AWS environment
- Customer data processing systems
- Internal IT systems
- Remote workforce endpoints

## Key Assets
- AWS infrastructure (EC2, RDS, S3)
- Customer transaction database
- Employee endpoints
- Third-party integrations: Stripe, Datadog, Slack
Set up the risk register template in Google Sheets

A risk register is the central document in any risk assessment. It captures every identified risk, scores its severity, and tracks what the organization plans to do about it.

You will build this in Google Sheets so it is easy to sort, filter, and visualize later.

  • Open sheets.google.com in your browser and sign in to your Google account.
  • Click Blank spreadsheet to create a new sheet.
  • Click the title (it will say Untitled spreadsheet) and rename it to NovaPay Risk Register.

Now set up the header row with all 13 columns required for a complete risk register.

  • In row 1, enter the following column headers across cells A1 through M1:
  • A1: Risk ID
  • B1: Risk Description
  • C1: Threat Source
  • D1: Vulnerability
  • E1: Affected Asset
  • F1: Likelihood (1-5)
  • G1: Impact (1-5)
  • H1: Inherent Risk Score
  • I1: Existing Controls
  • J1: Residual Risk Score
  • K1: Risk Owner
  • L1: Treatment Plan
  • M1: Status

What do these columns capture?

Each column maps to a component of the NIST SP 800-30 risk assessment methodology. Likelihood and Impact are scored on a 1-5 scale. The Inherent Risk Score is Likelihood multiplied by Impact (before controls). The Residual Risk Score reflects what remains after Existing Controls are factored in.

Risk Owner and Treatment Plan ensure accountability. Without an owner, risks stay unresolved.

  • Bold the entire header row by selecting row 1 and pressing Cmd+B (macOS) or Ctrl+B (Windows).
  • Freeze the header row so it stays visible as you scroll. Click View in the menu bar, then Freeze, then 1 row.

Next, create the Risk Matrix tab for visualizing risk distribution.

  • Click the + icon at the bottom-left of the sheet to add a new tab.
  • Double-click the new tab name and rename it to Risk Matrix.
  • Also rename the first tab (currently Sheet1) to Risk Register by double-clicking its tab name.

Now set up the 5x5 scoring grid structure on the Risk Matrix tab.

  • In cell A1, type Impact \ Likelihood.
  • In cells B1 through F1, type the likelihood labels: 1 - Very Low, 2 - Low, 3 - Moderate, 4 - High, 5 - Very High.
  • In cells A2 through A6, type the impact labels: 5 - Critical, 4 - Major, 3 - Moderate, 2 - Minor, 1 - Negligible.
  • Leave the inner cells (B2 through F6) empty for now. You will populate them with risk scores in the next step.

Why a 5x5 matrix?

NIST SP 800-30 supports qualitative, semi-quantitative, and quantitative risk assessment approaches. The 5x5 qualitative matrix is the standard starting point used in entry-level GRC roles. It teaches the mental model of risk scoring (Likelihood x Impact) without requiring statistical expertise.

  • Switch back to the Risk Register tab and confirm your 13 column headers are in place.
  • Switch to the Risk Matrix tab and confirm the 5x5 grid labels are visible.

Accidentally deleted a tab?

If you deleted a tab by mistake, use Cmd+Z (macOS) or Ctrl+Z (Windows) immediately to undo. If undo does not work, click the + icon to add a new tab and re-enter the headers.

Help me set up my risk register spreadsheet.

Your workspace is fully set up. You have a professional repository structure on GitHub, a documented company profile defining NovaPay's environment, and a risk register template ready for scoring. Next up, you will populate that register with real risks using the NIST SP 800-30 methodology.

Conduct the Risk Assessment

Your repository and company profile are ready. Now it's time for the core activity of any GRC engagement: assessing what could go wrong.

In this step, you'll build a formal risk assessment for NovaPay Solutions using NIST SP 800-30 methodology. You'll define scoring scales, identify 15+ cybersecurity risks across the company, and visualize the results in a heat map that makes risk distribution immediately clear.

In this step, get ready to:
  • Define likelihood and impact scoring scales aligned with NIST SP 800-30.
  • Identify and score 15+ cybersecurity risks across NovaPay's environment.
  • Create a risk heat map and summary document for your portfolio.
Define likelihood and impact scales

Before scoring any risks, you need a consistent methodology. This prevents subjective guesswork and ensures every risk is measured on the same yardstick.

  • In your text editor, create a new file called risk-methodology.md inside the 02_Risk_Assessment/ folder of your repository.
  • Copy the following content into the file:
# Risk Assessment Methodology

## Likelihood Scale (NIST SP 800-30 Aligned)
| Score | Level | Description |
|-------|-------|-------------|
| 1 | Very Low | Rare – unlikely to occur |
| 2 | Low | Unlikely – could occur but not expected |
| 3 | Moderate | Possible – may occur occasionally |
| 4 | High | Likely – expected to occur |
| 5 | Very High | Almost Certain – expected to occur frequently |

## Impact Scale
| Score | Level | Description |
|-------|-------|-------------|
| 1 | Negligible | Minimal effect on operations |
| 2 | Minor | Small impact, easily recoverable |
| 3 | Moderate | Noticeable impact, recoverable with effort |
| 4 | Major | Significant impact on operations or reputation |
| 5 | Critical/Catastrophic | Severe or irreversible damage |

## Risk Score Calculation
Risk Score = Likelihood x Impact (Range: 1–25)

## Risk Appetite Thresholds
| Score Range | Rating |
|-------------|--------|
| 1–5 | Low |
| 6–12 | Medium |
| 13–19 | High |
| 20–25 | Critical |

What does this methodology do?

The likelihood scale measures how probable a threat event is. The impact scale measures how damaging it would be if it occurred.

Multiplying them together gives you a risk score from 1 to 25. The risk appetite thresholds then classify each score into Low, Medium, High, or Critical so stakeholders can quickly see which risks demand immediate attention.

  • Save risk-methodology.md.
  • Commit and push the file to your GitHub repository.
  • On GitHub, navigate to 02_Risk_Assessment/ and confirm that risk-methodology.md appears with the formatted tables visible in the preview.

Tables not rendering on GitHub?

Make sure each table row has the same number of pipe characters. The separator row (|-------|) must have the same number of columns as the header.

help me fix my Markdown table formatting in risk-methodology.md

Identify and score 15 risks

Now you'll populate the risk register with real-world cybersecurity risks that a startup like NovaPay would face. Each risk needs a complete entry covering the threat, vulnerability, affected asset, scoring, and treatment plan.

  • Switch back to your NovaPay Risk Register Google Sheet.
  • In the Risk Register tab, populate 15 or more risks covering all five categories: access control, data protection, operational, vendor/supply chain, and personnel.
  • For each risk, fill in every column: Risk ID, Risk Description, Threat Source, Vulnerability, Affected Asset, Likelihood (1-5), Impact (1-5), Inherent Risk Score, Existing Controls, Residual Risk Score, Risk Owner, Treatment Plan, and Status.

What goes in each column?

  • Risk ID: A unique identifier like RISK-001, RISK-002, etc.
  • Threat Source: Who or what causes the threat (e.g., external attacker, insider, natural disaster).
  • Inherent Risk Score: Likelihood x Impact before any controls are applied.
  • Residual Risk Score: The risk score after existing controls reduce the likelihood or impact.
  • Treatment Plan: Accept, Mitigate, Transfer, or Avoid.

✔️ I'll give it a go!

Use the categories below as your guide. Aim for at least 3 risks per category.

  • Access Control: Think about MFA, shared credentials, privileged access, terminated employee accounts.
  • Data Protection: Think about encryption at rest, encryption in transit, DLP controls, data classification.
  • Operational: Think about incident response plans, backup testing, change management, disaster recovery.
  • Vendor/Supply Chain: Think about vendor assessments, SaaS sprawl, data sharing agreements, third-party outages.
  • Personnel: Think about security training, background checks, acceptable use policies, separation of duties.

Remember to reference the company profile for NovaPay's specific assets and environment when writing your risk descriptions.

ⓧ Maybe a little help...

Here are 15 risks you can use to populate your register. Enter each one as a row in Google Sheets, scoring it with your methodology.

## Access Control Risks
RISK-001: No MFA on production AWS console
  Threat: External attacker | Vuln: Single-factor auth | Asset: AWS infrastructure
  Likelihood: 4 | Impact: 5 | Inherent: 20 | Controls: Password policy | Residual: 16

RISK-002: Shared admin credentials for production database
  Threat: Insider/External | Vuln: No individual accountability | Asset: Customer DB
  Likelihood: 4 | Impact: 5 | Inherent: 20 | Controls: None | Residual: 20

RISK-003: No privileged access management (PAM) solution
  Threat: Insider threat | Vuln: Excessive standing privileges | Asset: All systems
  Likelihood: 3 | Impact: 4 | Inherent: 12 | Controls: Quarterly reviews | Residual: 9

## Data Protection Risks
RISK-004: Unencrypted data at rest in legacy S3 buckets
  Threat: External attacker | Vuln: No encryption | Asset: S3 legacy buckets
  Likelihood: 3 | Impact: 5 | Inherent: 15 | Controls: Network ACLs | Residual: 12

RISK-005: No Data Loss Prevention (DLP) controls
  Threat: Insider | Vuln: No monitoring of data exfiltration | Asset: Customer data
  Likelihood: 3 | Impact: 4 | Inherent: 12 | Controls: None | Residual: 12

RISK-006: PCI cardholder data in unmasked logs
  Threat: External/Insider | Vuln: Insufficient log sanitization | Asset: Logging system
  Likelihood: 3 | Impact: 5 | Inherent: 15 | Controls: Partial masking | Residual: 10

## Operational Risks
RISK-007: No documented incident response plan
  Threat: Any threat actor | Vuln: No structured response | Asset: All systems
  Likelihood: 5 | Impact: 4 | Inherent: 20 | Controls: Ad-hoc response | Residual: 16

RISK-008: No backup testing or restoration drills
  Threat: System failure | Vuln: Untested recovery | Asset: Customer DB
  Likelihood: 3 | Impact: 5 | Inherent: 15 | Controls: Daily backups exist | Residual: 10

RISK-009: No formal change management process
  Threat: Developer error | Vuln: Unreviewed prod changes | Asset: Production env
  Likelihood: 4 | Impact: 4 | Inherent: 16 | Controls: Peer review (informal) | Residual: 12

## Vendor/Supply Chain Risks
RISK-010: No vendor security assessments conducted
  Threat: Supply chain attack | Vuln: Unknown vendor posture | Asset: Third-party integrations
  Likelihood: 3 | Impact: 4 | Inherent: 12 | Controls: None | Residual: 12

RISK-011: SaaS sprawl with no inventory
  Threat: Shadow IT | Vuln: Unmanaged apps with company data | Asset: Corporate data
  Likelihood: 4 | Impact: 3 | Inherent: 12 | Controls: None | Residual: 12

RISK-012: No data processing agreements with vendors
  Threat: Regulatory | Vuln: Non-compliant data sharing | Asset: Customer data
  Likelihood: 3 | Impact: 4 | Inherent: 12 | Controls: None | Residual: 12

## Personnel Risks
RISK-013: No security awareness training program
  Threat: Social engineering | Vuln: Untrained staff | Asset: All employees
  Likelihood: 4 | Impact: 3 | Inherent: 12 | Controls: Onboarding mention | Residual: 10

RISK-014: No background checks for engineers with prod access
  Threat: Insider threat | Vuln: Unvetted privileged users | Asset: Production env
  Likelihood: 2 | Impact: 5 | Inherent: 10 | Controls: None | Residual: 10

RISK-015: No separation of duties for financial transactions
  Threat: Fraud | Vuln: Single person can initiate and approve | Asset: Payment system
  Likelihood: 3 | Impact: 5 | Inherent: 15 | Controls: Manager approval | Residual: 10

For each risk, set the Risk Owner to a role (e.g., CISO, Engineering Lead, IT Manager) and the Status to Open.

  • After entering all 15+ risks, review your Inherent Risk Scores to confirm the math is correct (Likelihood x Impact = Inherent Risk Score).
  • Set the Status column to Open for all risks.
  • Verify your register has at least 3 risks per category.

Not sure how to set residual risk?

If existing controls partially reduce a risk, lower either the Likelihood or Impact score by 1-2 points. For example, if backups exist but are untested, the Impact drops from 5 to 4 because some recovery is possible. If no controls exist at all, the Residual Risk Score equals the Inherent Risk Score.

help me understand how to calculate residual risk scores for my risk register

Create risk visualization

A risk heat map turns your register into a visual tool that leadership can understand at a glance. It plots risks on a 5x5 grid and uses color to communicate severity.

  • Switch to the Risk Matrix tab in your Google Sheet.
  • Build the 5x5 grid with Impact on the X-axis (columns 1-5) and Likelihood on the Y-axis (rows 1-5).
  • In each cell, enter the calculated risk score (Likelihood x Impact).
  • Apply color coding using your risk appetite thresholds:
  • Below the grid, add a summary section that counts how many of your 15+ risks fall into each severity level.

How do I color code cells in Google Sheets?

Select the cells you want to color. Click the fill color button (paint bucket icon) in the toolbar. Choose green, yellow, orange, or red to match the severity level of that cell's score.

  • Verify your heat map shows a mix of colors. Most startup risk registers will have a concentration in the yellow/orange zone with a few critical reds.

Now create a summary document for your GitHub portfolio that captures the key findings from your risk register.

  • In your text editor, create a new file called risk-register-summary.md inside the 02_Risk_Assessment/ folder.
  • Copy the following template and fill in the counts from your heat map:
# Risk Register Summary

## Risk Distribution Heat Map
The 5x5 risk matrix plots 15+ identified risks by likelihood and impact.

## Severity Summary
- **Critical (20-25):** [count] risks
- **High (13-19):** [count] risks
- **Medium (6-12):** [count] risks
- **Low (1-5):** [count] risks

## Top Risks by Category
- Access Control: No MFA on production AWS console, shared admin credentials
- Data Protection: Unencrypted data at rest in legacy S3 buckets, no DLP controls
- Operational: No documented incident response plan, no backup testing
- Vendor/Supply Chain: No vendor security assessments, SaaS sprawl
- Personnel: No security awareness training, no background checks for engineers with prod access

What does this summary do?

This document gives anyone reviewing your GitHub repository a quick snapshot of the risk landscape without needing to open the full spreadsheet. It highlights the distribution across severity levels and names the top risks by category.

Replace each [count] with the actual number of risks from your register that fall into that severity band.

  • Replace the [count] placeholders with the actual numbers from your risk register.
  • Save risk-register-summary.md.
  • Commit and push both risk-methodology.md and risk-register-summary.md to GitHub.
  • On GitHub, navigate to 02_Risk_Assessment/ and confirm both files appear.

Not sure what counts to put in the summary?

Go back to your Google Sheet and count how many risks have an Inherent Risk Score in each range. For example, if RISK-001 scores 20 and RISK-002 scores 20, that's 2 Critical risks. Add up each band and enter those numbers in the summary.

help me count and categorize my risks by severity level

✔️ Awesome, I've got everything!

Great. Double check you've saved both files and pushed them to GitHub.

ⓧ I'd like to double check the full code

Here is the complete risk-methodology.md file:

# Risk Assessment Methodology

## Likelihood Scale (NIST SP 800-30 Aligned)
| Score | Level | Description |
|-------|-------|-------------|
| 1 | Very Low | Rare – unlikely to occur |
| 2 | Low | Unlikely – could occur but not expected |
| 3 | Moderate | Possible – may occur occasionally |
| 4 | High | Likely – expected to occur |
| 5 | Very High | Almost Certain – expected to occur frequently |

## Impact Scale
| Score | Level | Description |
|-------|-------|-------------|
| 1 | Negligible | Minimal effect on operations |
| 2 | Minor | Small impact, easily recoverable |
| 3 | Moderate | Noticeable impact, recoverable with effort |
| 4 | Major | Significant impact on operations or reputation |
| 5 | Critical/Catastrophic | Severe or irreversible damage |

## Risk Score Calculation
Risk Score = Likelihood x Impact (Range: 1–25)

## Risk Appetite Thresholds
| Score Range | Rating |
|-------------|--------|
| 1–5 | Low |
| 6–12 | Medium |
| 13–19 | High |
| 20–25 | Critical |

And here is the complete risk-register-summary.md file (with your own counts filled in):

# Risk Register Summary

## Risk Distribution Heat Map
The 5x5 risk matrix plots 15+ identified risks by likelihood and impact.

## Severity Summary
- **Critical (20-25):** [count] risks
- **High (13-19):** [count] risks
- **Medium (6-12):** [count] risks
- **Low (1-5):** [count] risks

## Top Risks by Category
- Access Control: No MFA on production AWS console, shared admin credentials
- Data Protection: Unencrypted data at rest in legacy S3 buckets, no DLP controls
- Operational: No documented incident response plan, no backup testing
- Vendor/Supply Chain: No vendor security assessments, SaaS sprawl
- Personnel: No security awareness training, no background checks for engineers with prod access

You've built a complete risk assessment with a formal methodology, a populated register, and a visual heat map. Next up, you'll map these risks to real compliance frameworks by connecting NIST CSF 2.0 controls to SOC 2 criteria.

Map Controls Across NIST CSF 2.0 and SOC 2

Your risk register now holds 15+ scored risks across NovaPay's environment. The next question is: which of these risks already have controls in place, and where are the dangerous gaps?

Control mapping is how GRC analysts connect the dots between security frameworks. You will map NIST CSF 2.0 Functions to SOC 2 Trust Services Criteria, assess NovaPay's current state against each control area, and surface the gaps that would fail an audit.

In this step, get ready to:
  • Build a control mapping matrix linking NIST CSF 2.0 Functions to SOC 2 Common Criteria (CC1-CC9).
  • Assess NovaPay's implementation status for each control area with supporting evidence.
  • Identify cross-framework coverage, efficiency wins, and audit-failure gaps.
Create the control mapping matrix

Control mapping creates a crosswalk between two frameworks so you can see how a single security control satisfies requirements from both. Each row connects a NIST CSF 2.0 Function to the SOC 2 Common Criteria it addresses, then records whether NovaPay actually has that control in place.

  • In your text editor, create a new file at 03_Control_Mapping/control-mapping.md inside your grc-soc2-readiness-assessment repository folder.
  • Add the following content to build the mapping matrix:
# NIST CSF 2.0 to SOC 2 Control Mapping

## Control Mapping Matrix
| NIST CSF 2.0 Function | NIST CSF Category | SOC 2 CC | Implementation Status | Evidence / Notes |
|---|---|---|---|---|
| Govern (GV) | Organizational Context, Risk Management Strategy | CC1, CC3 | Partially Implemented | Basic org structure exists; no formal risk management policy |
| Identify (ID) | Asset Management, Risk Assessment | CC3, CC6 | Not Implemented | No asset inventory; no formal risk assessment process |
| Protect (PR) | Identity Mgmt & Access Control (PR.AA) | CC5, CC6, CC8 | Partially Implemented | SSO for SaaS apps; no MFA on AWS console; no PAM |
| Detect (DE) | Continuous Monitoring, Adverse Event Analysis | CC4, CC7 | Not Implemented | No SIEM; no centralized logging |
| Respond (RS) | Incident Management | CC7, CC9 | Not Implemented | No documented IR plan |
| Recover (RC) | Incident Recovery, Business Continuity | CC9 | Not Implemented | No tested recovery plan |

What does this mapping tell us?

Each row connects one of the six NIST CSF 2.0 Functions (Govern, Identify, Protect, Detect, Respond, Recover) to the SOC 2 Common Criteria series it helps satisfy.

For example, the Protect function's PR.AA category (Identity Management, Authentication, and Access Control) maps to CC5 (Control Activities), CC6 (Logical and Physical Access Controls), and CC8 (Change Management). One control implementation can satisfy multiple CC requirements at once.

  • Save control-mapping.md.
  • Open the file in your Markdown preview (or view it on GitHub after committing). You should see a formatted table with six rows, one per NIST CSF Function.

Table not rendering correctly?

Make sure each row has exactly five pipe-separated columns. The separator row (|---|---|---|---|---|) must have the same number of columns as the header.

help me fix my Markdown table formatting

Assess current implementation status for each control area

The mapping matrix uses three statuses to describe NovaPay's current posture for each control area. Choosing the right status requires evidence from the company's systems, documentation, and processes.

  • Implemented means the control is fully deployed, documented, and operating effectively.
  • Partially Implemented means some elements of the control exist but coverage is incomplete.
  • Not Implemented means no evidence of the control exists in the environment.

How do you determine the status?

Look at the Protect row as an example. NovaPay has SSO for SaaS applications (partial coverage), but no MFA on the AWS production console and no privileged access management (PAM). That combination gives it a Partially Implemented status.

Compare this to the Detect row. NovaPay has no SIEM, no centralized logging, and no alerting. Zero evidence means Not Implemented.

In a real engagement, you would interview system owners, review configurations, and inspect documentation to make each determination. For this project, use the company profile and risk register findings as your evidence source.

Why does NovaPay have nothing fully Implemented?

This is typical for a startup that grew fast without a dedicated security team. SOC 2 readiness assessments frequently uncover this pattern. Your job as the GRC analyst is to document the current state honestly so the remediation plan addresses real gaps.

Identify cross-framework coverage and gaps

Auditors want to know which SOC 2 CC series have adequate controls versus which would result in a qualified opinion. A coverage summary table gives leadership a quick view of where the company stands.

  • In control-mapping.md, add the following sections below the mapping matrix table:
## Coverage Summary
| SOC 2 CC | Coverage Status | Audit Risk |
|---|---|---|
| CC1 \u2013 Control Environment | Partial | Medium |
| CC3 \u2013 Risk Assessment | None | Critical \u2013 Audit Failure |
| CC4 \u2013 Monitoring Activities | None | Critical \u2013 Audit Failure |
| CC5 \u2013 Control Activities | Partial | High |
| CC6 \u2013 Logical and Physical Access | Partial | High |
| CC7 \u2013 System Operations | None | Critical \u2013 Audit Failure |
| CC8 \u2013 Change Management | None | High |
| CC9 \u2013 Risk Mitigation | None | Critical \u2013 Audit Failure |

## Cross-Framework Efficiency Wins
- Implementing MFA on AWS satisfies PR.AA (NIST CSF), CC6 (SOC 2), and reduces Risk R-001 and R-002 from the risk register.
- Deploying centralized logging satisfies DE.CM (NIST CSF), CC4 and CC7 (SOC 2) simultaneously.

What is an audit failure vs. an improvement opportunity?

A Critical - Audit Failure rating means a SOC 2 auditor would issue a qualified opinion (or exception) for that criteria series. NovaPay cannot pass its SOC 2 Type II without addressing these.

A High or Medium rating means partial controls exist. The auditor may note deficiencies, but these are improvement opportunities rather than immediate disqualifiers. Prioritizing audit failures first is how you build a realistic remediation timeline.

Why highlight cross-framework efficiency wins?

Executives want to know where a single investment closes multiple compliance gaps. Showing that enabling MFA satisfies both NIST CSF PR.AA and SOC 2 CC6 makes the business case for prioritizing that control. It also reduces the total number of remediation projects the company needs to fund.

  • Save control-mapping.md.
  • Preview the full file. You should see the mapping matrix table, the coverage summary table, and the efficiency wins section all rendering correctly.

Coverage summary not showing all CC series?

Check that you have eight rows in the Coverage Summary table (CC1, CC3, CC4, CC5, CC6, CC7, CC8, CC9). CC2 (Communication and Information) is omitted because it is addressed through organizational practices rather than technical controls.

help me verify my control mapping is complete

✔️ Awesome, I've got everything!

Great. Double check you have saved control-mapping.md with all three sections (mapping matrix, coverage summary, efficiency wins).

ⓧ I'd like to double check the full code

Here is the complete 03_Control_Mapping/control-mapping.md file:

# NIST CSF 2.0 to SOC 2 Control Mapping

## Control Mapping Matrix
| NIST CSF 2.0 Function | NIST CSF Category | SOC 2 CC | Implementation Status | Evidence / Notes |
|---|---|---|---|---|
| Govern (GV) | Organizational Context, Risk Management Strategy | CC1, CC3 | Partially Implemented | Basic org structure exists; no formal risk management policy |
| Identify (ID) | Asset Management, Risk Assessment | CC3, CC6 | Not Implemented | No asset inventory; no formal risk assessment process |
| Protect (PR) | Identity Mgmt & Access Control (PR.AA) | CC5, CC6, CC8 | Partially Implemented | SSO for SaaS apps; no MFA on AWS console; no PAM |
| Detect (DE) | Continuous Monitoring, Adverse Event Analysis | CC4, CC7 | Not Implemented | No SIEM; no centralized logging |
| Respond (RS) | Incident Management | CC7, CC9 | Not Implemented | No documented IR plan |
| Recover (RC) | Incident Recovery, Business Continuity | CC9 | Not Implemented | No tested recovery plan |

## Coverage Summary
| SOC 2 CC | Coverage Status | Audit Risk |
|---|---|---|
| CC1 \u2013 Control Environment | Partial | Medium |
| CC3 \u2013 Risk Assessment | None | Critical \u2013 Audit Failure |
| CC4 \u2013 Monitoring Activities | None | Critical \u2013 Audit Failure |
| CC5 \u2013 Control Activities | Partial | High |
| CC6 \u2013 Logical and Physical Access | Partial | High |
| CC7 \u2013 System Operations | None | Critical \u2013 Audit Failure |
| CC8 \u2013 Change Management | None | High |
| CC9 \u2013 Risk Mitigation | None | Critical \u2013 Audit Failure |

## Cross-Framework Efficiency Wins
- Implementing MFA on AWS satisfies PR.AA (NIST CSF), CC6 (SOC 2), and reduces Risk R-001 and R-002 from the risk register.
- Deploying centralized logging satisfies DE.CM (NIST CSF), CC4 and CC7 (SOC 2) simultaneously.

You now have a clear picture of where NovaPay stands against two major frameworks. Next up, you will turn these gaps into a prioritized remediation roadmap that tells leadership exactly what to fix and when.

Write the Gap Analysis and Remediation Roadmap

Your control mapping revealed a stark picture. Multiple SOC 2 Common Criteria series have zero implemented controls, and several would result in an immediate audit failure.

Now it is time to translate those findings into action. In this step, you will write a structured gap analysis that connects each missing control to its business risk, then build a phased remediation roadmap that tells the CISO exactly what to fix, when, and who owns it.

In this step, get ready to:
  • Write a narrative gap analysis with structured assessments for each critical gap.
  • Build a prioritized remediation roadmap with three time-based phases.
  • Create an executive summary that communicates technical findings in business language.
Write the narrative gap analysis

A gap analysis goes beyond simply listing what is missing. For each gap, you need to explain what the gap is, what risk it exposes, which specific framework requirements it violates, and how mature (or immature) the organization currently is in that area.

What is a maturity level?

Maturity levels describe how well-developed a control or process is. The scale runs from None (nothing exists) through Initial, Developing, Defined, Managed, and Optimized.

Most of NovaPay's critical gaps sit at None or Initial. Knowing the current maturity helps leadership understand the size of the journey ahead.

  • In your text editor, create a new file at 04_Gap_Analysis/gap-analysis.md.
  • Add the following content, which documents the critical gaps from your control mapping:
# Gap Analysis – NovaPay Solutions SOC 2 Readiness

## Critical Gaps

### Gap 1: No Multi-Factor Authentication on AWS Console
- **Gap Description:** MFA is not enforced for any AWS IAM users, including root and admin accounts.
- **Risk Exposure:** Unauthorized access to production environment (Risk R-001, Inherent Score: 20 – Critical).
- **Framework Requirement:** NIST CSF PR.AA-01; SOC 2 CC6.1
- **Current Maturity:** None

### Gap 2: No Incident Response Plan
- **Gap Description:** No documented or tested incident response procedures exist.
- **Risk Exposure:** Uncontrolled breach impact, regulatory exposure (Risk R-007, Inherent Score: 20 – Critical).
- **Framework Requirement:** NIST CSF RS.MA-01; SOC 2 CC7.3, CC9.1
- **Current Maturity:** None

### Gap 3: No Centralized Logging or Monitoring
- **Gap Description:** No SIEM or centralized log aggregation. AWS CloudTrail not enabled.
- **Risk Exposure:** Inability to detect or investigate security events (Risk R-009, Inherent Score: 16 – High).
- **Framework Requirement:** NIST CSF DE.CM-01; SOC 2 CC4.1, CC7.1
- **Current Maturity:** None

[Additional gaps documented for all critical findings from control mapping...]

What does this document structure do?

Each gap follows a consistent four-part structure. The gap description states the facts. The risk exposure links back to your risk register by ID and score, connecting the gap to quantified business risk.

The framework requirement cites the exact NIST CSF 2.0 subcategory and SOC 2 CC criterion being violated. This makes your analysis auditable. The maturity level sets the baseline for measuring improvement later.

  • Review your control-mapping.md Coverage Summary table. Every CC series marked "Critical – Audit Failure" or "High" needs its own gap entry.
  • Add additional gaps following the same four-part structure until you have covered all critical findings from your control mapping.
  • Save gap-analysis.md.

Reference your risk register by ID

Each gap should reference the corresponding risk ID from your Google Sheets risk register (e.g., R-001, R-007). This cross-referencing demonstrates traceability, which auditors specifically look for during a SOC 2 examination.

Not sure which gaps to add?

Look at the Coverage Summary in your control-mapping.md. Any row with "None" in Coverage Status or "Critical" in Audit Risk is a gap that needs documenting. CC3, CC4, CC7, CC8, and CC9 all need entries.

Struggling to structure my gap analysis entries.

Build the prioritized remediation roadmap

A gap analysis without a remediation plan is just a list of problems. Leadership needs to see the path forward, broken into actionable phases with clear ownership and timelines.

  • Create a new file at 04_Gap_Analysis/remediation-roadmap.md.
  • Add the following three-phase remediation plan:
# Remediation Roadmap – NovaPay Solutions

## Phase 1: Critical Actions (0–30 Days)
| Action | Owner | Effort | Dependencies | Gaps Closed |
|---|---|---|---|---|
| Enable MFA on all AWS IAM accounts | IT/DevOps Lead | 1 day | AWS admin access | Gap 1, CC6.1 |
| Document Incident Response Plan | CISO | 3 days | None | Gap 2, CC7.3, CC9.1 |
| Enable AWS CloudTrail in all regions | IT/DevOps Lead | 1 day | AWS admin access | Gap 3, CC4.1, CC7.1 |
| Conduct initial formal risk assessment | GRC Analyst | 5 days | None | CC3.1 |

## Phase 2: High-Priority Actions (30–90 Days)
| Action | Owner | Effort | Dependencies | Gaps Closed |
|---|---|---|---|---|
| Implement centralized logging (SIEM) | IT/DevOps Lead | 2 weeks | CloudTrail enabled | Gap 3, CC4.1, CC7.2 |
| Deploy endpoint protection | IT Lead | 1 week | Endpoint inventory | CC6.8 |
| Establish vendor risk management process | GRC Analyst | 2 weeks | Vendor list | CC9.2 |
| Launch security awareness training | HR + CISO | 3 weeks | LMS platform | Personnel risks |

## Phase 3: Strategic Initiatives (90+ Days)
| Action | Owner | Effort | Dependencies | Gaps Closed |
|---|---|---|---|---|
| Achieve SOC 2 Type I readiness | CISO + GRC | 3 months | Phase 1 & 2 complete | All CC series |
| Implement continuous monitoring program | IT/DevOps | 2 months | SIEM deployed | CC4, CC7 |
| Establish internal audit program | GRC Analyst | 2 months | Policies documented | CC1, CC3 |
| Formalize change management process | Engineering Lead | 1 month | None | CC8 |

Why three phases?

Phase 1 (0-30 days) targets quick wins that dramatically reduce risk with minimal effort. Enabling MFA takes a single day but closes a critical gap.

Phase 2 (30-90 days) builds the operational foundation. These actions take longer and may depend on Phase 1 completions. Phase 3 (90+ days) tackles strategic goals like achieving SOC 2 Type I readiness, which requires the earlier phases as prerequisites.

  • Save remediation-roadmap.md.
  • Review your roadmap to confirm each action specifies an owner, estimated effort, dependencies, and which gaps it closes.

Why does each action need an owner?

SOC 2 auditors look for accountability. A remediation plan without named owners is a wish list. By assigning owners, you demonstrate that NovaPay treats compliance as an operational responsibility distributed across the organization.

Unsure about effort estimates?

Effort estimates do not need to be exact. Use your judgment based on the complexity of each action. A configuration change (MFA, CloudTrail) is typically hours to a day. A policy document is days. A full program rollout (SIEM, training) is weeks.

Help me estimate effort for my remediation actions.

Create the executive summary

The executive summary is the document your CISO would present to the board. It translates all of your technical analysis into business language. No jargon. No framework codes. Just risk, impact, and the path forward.

  • Create a new file at 05_Executive_Summary/executive-summary.md.
  • Add the following executive summary content:
# Executive Summary – SOC 2 Readiness Assessment
**NovaPay Solutions | Prepared by: GRC Analyst | Date: [Date]**

## Current State
- 3 of 8 SOC 2 Common Criteria series have any controls implemented (all partial)
- 15 cybersecurity risks identified; 4 rated Critical, 6 rated High
- 0 of 4 critical SOC 2 control areas (CC3, CC4, CC7, CC9) have implemented controls

## Key Findings
1. **No MFA on AWS:** Any compromised credential grants full production access. Risk of data breach is high and immediate.
2. **No Incident Response Plan:** If a breach occurs today, NovaPay has no playbook — increasing regulatory exposure and client notification failures.
3. **No Monitoring or Logging:** Security events go undetected. SOC 2 auditors will flag this as an immediate disqualifier.

## Recommended Path to SOC 2 Type I Readiness
- **0–30 days:** Address critical gaps (MFA, IR plan, CloudTrail) — estimated 10 person-days
- **30–90 days:** Build monitoring, training, and vendor risk program — estimated 8 weeks
- **90+ days:** Sustain controls, conduct readiness assessment, engage auditor

## Resource Requirements
- 0.5 FTE GRC Analyst (6 months)
- ~$15,000–$25,000 in tooling (SIEM, endpoint protection, LMS)
- External auditor engagement: ~$30,000–$50,000 for Type II audit

## Business Case
Failure to achieve SOC 2 Type II within 12 months results in loss of the enterprise client deal (estimated $[X]M ARR) and competitive disadvantage in the enterprise market. Investment in compliance now protects revenue and enables future enterprise sales.

What makes this executive-ready?

Notice how the Key Findings section avoids framework codes entirely. A board member does not care about CC6.1. They care that any stolen password grants full access to production.

The Business Case section connects compliance to revenue. This is the language that gets budget approved. Without a clear financial consequence, security investments compete poorly against product features.

  • Replace [Date] with today's date.
  • Replace $[X]M ARR with a realistic estimate for an enterprise SaaS deal (for example, $2M ARR).
  • Save executive-summary.md.

Not sure if your summary is concise enough?

The executive summary should fit on a single page when printed. If yours is longer, cut detail from the Key Findings or Resource Requirements sections. Link to the full gap analysis and roadmap for anyone who wants the deep dive.

Help me tighten my executive summary.

✔️ Awesome, I've got everything!

Great. Double check you have saved all three files: gap-analysis.md, remediation-roadmap.md, and executive-summary.md.

ⓧ I'd like to double check the full code

Here is the full content for each file you created in this step.

# Gap Analysis – NovaPay Solutions SOC 2 Readiness

## Critical Gaps

### Gap 1: No Multi-Factor Authentication on AWS Console
- **Gap Description:** MFA is not enforced for any AWS IAM users, including root and admin accounts.
- **Risk Exposure:** Unauthorized access to production environment (Risk R-001, Inherent Score: 20 – Critical).
- **Framework Requirement:** NIST CSF PR.AA-01; SOC 2 CC6.1
- **Current Maturity:** None

### Gap 2: No Incident Response Plan
- **Gap Description:** No documented or tested incident response procedures exist.
- **Risk Exposure:** Uncontrolled breach impact, regulatory exposure (Risk R-007, Inherent Score: 20 – Critical).
- **Framework Requirement:** NIST CSF RS.MA-01; SOC 2 CC7.3, CC9.1
- **Current Maturity:** None

### Gap 3: No Centralized Logging or Monitoring
- **Gap Description:** No SIEM or centralized log aggregation. AWS CloudTrail not enabled.
- **Risk Exposure:** Inability to detect or investigate security events (Risk R-009, Inherent Score: 16 – High).
- **Framework Requirement:** NIST CSF DE.CM-01; SOC 2 CC4.1, CC7.1
- **Current Maturity:** None

[Additional gaps documented for all critical findings from control mapping...]
# Remediation Roadmap – NovaPay Solutions

## Phase 1: Critical Actions (0–30 Days)
| Action | Owner | Effort | Dependencies | Gaps Closed |
|---|---|---|---|---|
| Enable MFA on all AWS IAM accounts | IT/DevOps Lead | 1 day | AWS admin access | Gap 1, CC6.1 |
| Document Incident Response Plan | CISO | 3 days | None | Gap 2, CC7.3, CC9.1 |
| Enable AWS CloudTrail in all regions | IT/DevOps Lead | 1 day | AWS admin access | Gap 3, CC4.1, CC7.1 |
| Conduct initial formal risk assessment | GRC Analyst | 5 days | None | CC3.1 |

## Phase 2: High-Priority Actions (30–90 Days)
| Action | Owner | Effort | Dependencies | Gaps Closed |
|---|---|---|---|---|
| Implement centralized logging (SIEM) | IT/DevOps Lead | 2 weeks | CloudTrail enabled | Gap 3, CC4.1, CC7.2 |
| Deploy endpoint protection | IT Lead | 1 week | Endpoint inventory | CC6.8 |
| Establish vendor risk management process | GRC Analyst | 2 weeks | Vendor list | CC9.2 |
| Launch security awareness training | HR + CISO | 3 weeks | LMS platform | Personnel risks |

## Phase 3: Strategic Initiatives (90+ Days)
| Action | Owner | Effort | Dependencies | Gaps Closed |
|---|---|---|---|---|
| Achieve SOC 2 Type I readiness | CISO + GRC | 3 months | Phase 1 & 2 complete | All CC series |
| Implement continuous monitoring program | IT/DevOps | 2 months | SIEM deployed | CC4, CC7 |
| Establish internal audit program | GRC Analyst | 2 months | Policies documented | CC1, CC3 |
| Formalize change management process | Engineering Lead | 1 month | None | CC8 |
# Executive Summary – SOC 2 Readiness Assessment
**NovaPay Solutions | Prepared by: GRC Analyst | Date: [Date]**

## Current State
- 3 of 8 SOC 2 Common Criteria series have any controls implemented (all partial)
- 15 cybersecurity risks identified; 4 rated Critical, 6 rated High
- 0 of 4 critical SOC 2 control areas (CC3, CC4, CC7, CC9) have implemented controls

## Key Findings
1. **No MFA on AWS:** Any compromised credential grants full production access. Risk of data breach is high and immediate.
2. **No Incident Response Plan:** If a breach occurs today, NovaPay has no playbook — increasing regulatory exposure and client notification failures.
3. **No Monitoring or Logging:** Security events go undetected. SOC 2 auditors will flag this as an immediate disqualifier.

## Recommended Path to SOC 2 Type I Readiness
- **0–30 days:** Address critical gaps (MFA, IR plan, CloudTrail) — estimated 10 person-days
- **30–90 days:** Build monitoring, training, and vendor risk program — estimated 8 weeks
- **90+ days:** Sustain controls, conduct readiness assessment, engage auditor

## Resource Requirements
- 0.5 FTE GRC Analyst (6 months)
- ~$15,000–$25,000 in tooling (SIEM, endpoint protection, LMS)
- External auditor engagement: ~$30,000–$50,000 for Type II audit

## Business Case
Failure to achieve SOC 2 Type II within 12 months results in loss of the enterprise client deal (estimated $[X]M ARR) and competitive disadvantage in the enterprise market. Investment in compliance now protects revenue and enables future enterprise sales.

Your gap analysis, remediation roadmap, and executive summary are complete. Next up, you will finalize the entire portfolio, polish the README for recruiter-readability, and publish everything to GitHub.

Finalize and Publish Your GRC Portfolio

You have a complete risk assessment, control mapping, gap analysis, and executive summary. Now it is time to package everything into a professional portfolio that a recruiter or hiring manager can navigate in under 60 seconds.

In this step, you will polish your README.md into a portfolio landing page, export your risk register data into the repository, and push the final version to GitHub.

In this step, get ready to:
  • Update the README with a table of contents, methodology section, and skills demonstrated.
  • Export the risk register as CSV and create a top risks summary.
  • Review all documents for consistency and publish to GitHub.
Polish the README and add navigation

Your README.md is the first thing anyone sees when they visit your repository. A well-structured README transforms a collection of files into a navigable portfolio.

  • Open README.md in your text editor.
  • Replace the entire contents of the file with the following:
# GRC SOC 2 Readiness Assessment

A professional GRC portfolio demonstrating SOC 2 readiness assessment for NovaPay Solutions.

**Author:** [[YOURNAME="your name"]]

## Table of Contents
- [Company Profile](01_Company_Profile/company-profile.md)
- [Risk Methodology](02_Risk_Assessment/risk-methodology.md)
- [Risk Register (CSV)](02_Risk_Assessment/risk-register.csv)
- [Top 5 Critical Risks](02_Risk_Assessment/top-risks.md)
- [Risk Register Summary](02_Risk_Assessment/risk-register-summary.md)
- [Control Mapping](03_Control_Mapping/control-mapping.md)
- [Gap Analysis](04_Gap_Analysis/gap-analysis.md)
- [Remediation Roadmap](04_Gap_Analysis/remediation-roadmap.md)
- [Executive Summary](05_Executive_Summary/executive-summary.md)

## Methodology
- **NIST SP 800-30**: Risk assessment methodology (5x5 qualitative matrix)
- **NIST CSF 2.0**: Control framework (6 Functions, 22 Categories)
- **SOC 2 Trust Services Criteria**: Compliance target (CC1–CC9)

## Skills Demonstrated
- Risk assessment and scoring
- Control mapping across multiple frameworks
- Gap analysis and maturity assessment
- Remediation roadmap development
- Executive communication and board-level reporting
- Multi-framework compliance (NIST CSF 2.0, SOC 2 TSC, NIST SP 800-30)

What does this README accomplish?

The Table of Contents gives visitors clickable links to every deliverable in the repository. Each link uses a relative path so GitHub renders them as navigable hyperlinks.

The Methodology section names the three frameworks you used, showing multi-framework proficiency at a glance. The Skills Demonstrated section speaks directly to the capabilities hiring managers look for in GRC analyst candidates.

  • Save README.md.

Links not working on GitHub?

Make sure the file paths in your Table of Contents match your folder and file names exactly, including capitalization. GitHub links are case-sensitive.

Verify there are no extra spaces between the brackets and parentheses in each Markdown link.

Help me fix my README links on GitHub.

Add the risk register to the repository

Your risk register lives in Google Sheets, but reviewers need to see it directly in your GitHub repository. You will export the spreadsheet as a CSV file and create a formatted Markdown summary of your top risks.

  • Switch back to your NovaPay Risk Register in Google Sheets.
  • Click File in the top menu bar.
  • Hover over Download.
  • Select Comma Separated Values (.csv).
  • Rename the downloaded file to risk-register.csv.
  • Move the file into your 02_Risk_Assessment/ folder in the repository.

Why include a CSV?

CSV files are viewable directly on GitHub as formatted tables. This means reviewers can browse your full risk register without downloading anything or opening Google Sheets.

Now create a formatted Markdown file highlighting the most severe risks. This gives readers a quick snapshot of the most urgent findings.

  • In 02_Risk_Assessment/, create a new file named top-risks.md.
  • Add the following content:
# Top 5 Critical Risks – NovaPay Solutions

| Risk ID | Description | Likelihood | Impact | Risk Score | Rating | Treatment |
|---|---|---|---|---|---|---|
| R-001 | No MFA on production AWS console | 4 | 5 | 20 | Critical | Enforce MFA immediately |
| R-002 | Shared admin credentials in production | 4 | 5 | 20 | Critical | Implement IAM individual accounts + PAM |
| R-007 | No documented incident response plan | 4 | 5 | 20 | Critical | Draft and test IR plan within 30 days |
| R-003 | Unencrypted data at rest in legacy S3 buckets | 3 | 5 | 15 | High | Enable S3 default encryption |
| R-009 | No centralized logging or monitoring | 4 | 4 | 16 | High | Enable CloudTrail + deploy SIEM |

What does this file do?

This table pulls the highest-scoring risks from your register into a single view. It demonstrates you can prioritize and communicate the most urgent findings without requiring someone to read through 15+ rows.

The Risk IDs (R-001, R-002, etc.) match your full register and gap analysis, creating traceability across your documents.

  • Save top-risks.md.
  • Confirm your 02_Risk_Assessment/ folder now contains four files: risk-methodology.md, risk-register-summary.md, risk-register.csv, and top-risks.md.

CSV looks garbled on GitHub?

Make sure you exported only the Risk Register tab (not the Risk Matrix tab). Google Sheets exports whichever tab is active when you click Download.

Check that the first row of your CSV contains the column headers: Risk ID, Risk Description, Threat Source, Vulnerability, Affected Asset, Likelihood, Impact, Inherent Risk Score, Existing Controls, Residual Risk Score, Risk Owner, Treatment Plan, Status.

Help me fix my CSV export from Google Sheets.

Final review and commit

A GRC portfolio loses credibility if the documents contradict each other. Before publishing, you need to verify that risk IDs, control references, and terminology are consistent across all files.

  • Review your documents using this consistency checklist:
  • Risk IDs in top-risks.md match the IDs in gap-analysis.md and your CSV register.
  • SOC 2 CC references in control-mapping.md match those in remediation-roadmap.md.
  • Gap numbers in gap-analysis.md match the "Gaps Closed" column in remediation-roadmap.md.
  • Terminology is consistent (e.g., always "MFA" not sometimes "2FA", always "incident response plan" not "IR plan" in one document and "incident response procedure" in another).
  • All headings use professional formatting with no typos.

Why does cross-referencing matter?

In a real SOC 2 audit, the auditor traces evidence across documents. If your risk register says "R-001" but your gap analysis references "Risk 1", the auditor flags it as a control weakness. Consistent cross-referencing is a sign of professional maturity.

  • Fix any inconsistencies you find during the review.
  • Save all updated files.

Now push your final commit to GitHub.

  • If you are using Git from the terminal, commit and push all changes by running these commands:
git add .
git commit -m "Finalize portfolio: add README navigation, risk register CSV, and top risks summary"
git push origin main

Using GitHub's web interface instead?

If you have been creating files directly on GitHub, upload your risk-register.csv by clicking Add file then Upload files in the 02_Risk_Assessment/ folder. Make sure all other files are saved with their latest edits.

  • Visit your repository on GitHub in your browser.
  • Verify the README renders with clickable links in the Table of Contents.
  • Click at least two links from the Table of Contents to confirm they navigate to the correct documents.
  • Confirm the repository visibility is set to Public by checking the label next to the repository name.

Repository showing as private?

Click Settings in your repository's top navigation. Scroll to the bottom of the page to the Danger Zone section. Click Change visibility and select Public.

Help me make my GitHub repository public.

✔️ Awesome, I've got everything!

Your GRC portfolio is live and navigable. Double check that you have saved all files.

ⓧ I'd like to double check the full README

Here is the complete README.md for reference:

# GRC SOC 2 Readiness Assessment

A professional GRC portfolio demonstrating SOC 2 readiness assessment for NovaPay Solutions.

**Author:** [[YOURNAME="your name"]]

## Table of Contents
- [Company Profile](01_Company_Profile/company-profile.md)
- [Risk Methodology](02_Risk_Assessment/risk-methodology.md)
- [Risk Register (CSV)](02_Risk_Assessment/risk-register.csv)
- [Top 5 Critical Risks](02_Risk_Assessment/top-risks.md)
- [Risk Register Summary](02_Risk_Assessment/risk-register-summary.md)
- [Control Mapping](03_Control_Mapping/control-mapping.md)
- [Gap Analysis](04_Gap_Analysis/gap-analysis.md)
- [Remediation Roadmap](04_Gap_Analysis/remediation-roadmap.md)
- [Executive Summary](05_Executive_Summary/executive-summary.md)

## Methodology
- **NIST SP 800-30**: Risk assessment methodology (5x5 qualitative matrix)
- **NIST CSF 2.0**: Control framework (6 Functions, 22 Categories)
- **SOC 2 Trust Services Criteria**: Compliance target (CC1–CC9)

## Skills Demonstrated
- Risk assessment and scoring
- Control mapping across multiple frameworks
- Gap analysis and maturity assessment
- Remediation roadmap development
- Executive communication and board-level reporting
- Multi-framework compliance (NIST CSF 2.0, SOC 2 TSC, NIST SP 800-30)

Secret mission

Conduct a Third-Party Vendor Risk Assessment

NovaPay relies on critical SaaS vendors like AWS, Stripe, and Slack. Enterprise clients and SOC 2 auditors will ask how you manage third-party risk. In this secret mission, you will build a vendor risk assessment that demonstrates you can evaluate supplier security posture, apply a risk scoring model, and make risk acceptance recommendations with justification.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely on free tools, so there are no ongoing costs. Decide whether to keep your resources available, pause them, or delete them entirely.

Resources you used:

  • GitHub repository grc-soc2-readiness-assessment (public).
  • Google Sheet NovaPay Risk Register (in your Google Drive).

Keep everything running

No action needed. Choose this if you plan to continue refining your GRC portfolio, adding more frameworks, or sharing it with recruiters.

  • Your GitHub repository remains public and accessible to anyone with the link.
  • Your Google Sheet remains in your Google Drive and does not cost anything to store.

Pause - I'll come back to this later

Make your work private so it is not publicly visible while you take a break.

  • On GitHub, go to your grc-soc2-readiness-assessment repository.
  • Click Settings in the repository navigation bar.
  • Scroll down to the Danger Zone section.
  • Click Change visibility and set the repository to Private.
  • Your Google Sheet requires no action. It stays in your Drive and is only accessible to you unless you shared it.

Delete - I don't want to use this again

Remove all project resources permanently. This cannot be undone.

  • Delete the GitHub repository:
  • On GitHub, go to your grc-soc2-readiness-assessment repository.
  • Click Settings in the repository navigation bar.
  • Scroll to the Danger Zone section and click Delete this repository.
  • Confirm by typing the repository name when prompted.
  • Delete the Google Sheet:
  • Open Google Drive and locate NovaPay Risk Register.
  • Right-click the file and select Move to trash.
  • Empty your trash to permanently delete it.

Nice Work!

Nice Work!

You just completed a full SOC 2 readiness assessment for a fictional fintech startup, from initial risk identification all the way through to a board-ready executive summary. Your GitHub repository now stands as a professional GRC portfolio that demonstrates the exact skills hiring managers look for in compliance analyst candidates.

You learned how to:

  • Conduct a structured risk assessment with 15+ scored cybersecurity risks using NIST SP 800-30 methodology and a 5x5 qualitative likelihood/impact matrix.
  • Map controls across NIST CSF 2.0 (6 Functions, 22 Categories) and SOC 2 Trust Services Criteria (CC1-CC9), identifying critical compliance gaps and cross-framework efficiency wins.
  • Produce a gap analysis with narrative assessments, a phased remediation roadmap (0-30, 30-90, 90+ days), and an executive summary communicating technical findings in business language for CISO and board audiences.
  • Secret Mission: Conducted third-party vendor risk assessments for NovaPay's critical SaaS dependencies, demonstrating supply chain risk management capability.

Ready to quiz yourself?