I'll never forget sitting across from a frustrated CEO in 2020 who threw a 47-page SOC 2 audit report on the conference table. "I've read this thing three times," he said, "and I still don't understand what controls we actually need to implement. It's like they're speaking a different language."
He wasn't wrong. The SOC 2 framework can feel like trying to solve a Rubik's cube blindfolded—there are pieces you know need to fit together, but figuring out how can be maddening.
After helping over 40 organizations achieve SOC 2 compliance in the past 15 years, I've learned that the secret to success isn't working harder—it's having a clear map. That's exactly what a SOC 2 control matrix provides: a systematic way to connect the dots between what auditors want to see (Trust Services Criteria) and what you actually need to do (implement specific controls).
Today, I'm going to share the exact framework I use with my clients—the one that transforms confusion into clarity and turns SOC 2 from an overwhelming mountain into a manageable checklist.
Understanding the SOC 2 Control Universe
Before we dive into the matrix, let me share something that took me years to truly understand: SOC 2 isn't prescriptive—it's principle-based.
When I started in this field, I expected SOC 2 to be like PCI DSS, which tells you exactly what to do: "Use firewalls here, encrypt this way, scan on this schedule." SOC 2 doesn't work that way.
Instead, SOC 2 says: "You need to achieve these outcomes (the criteria), and you need to prove you're achieving them consistently." How you get there? That's up to you.
This flexibility is both SOC 2's greatest strength and its biggest source of confusion.
The Five Trust Services Criteria: Your North Star
Let me break down the five Trust Services Criteria (TSC) in plain English:
Criteria | What It Really Means | When You Need It |
|---|---|---|
Security | Protect your systems from unauthorized access | Always required - this is mandatory for all SOC 2 audits |
Availability | Keep your systems up and running | Required if you promise uptime SLAs or if downtime affects customer operations |
Processing Integrity | Process data completely, accurately, and on time | Required if you process customer transactions or transform their data |
Confidentiality | Protect information designated as confidential | Required if you handle proprietary business information beyond just personal data |
Privacy | Handle personal information according to your commitments | Required if you collect, use, retain, or dispose of personal information |
"Think of Security as the foundation of a house—you always need it. The other four criteria are like additional rooms you build based on what your business actually does."
I worked with a SaaS analytics company in 2021 that initially wanted all five criteria because they thought "more is better." After walking through their actual service, we realized they only needed Security and Availability. They didn't process transactions (no Processing Integrity), didn't handle trade secrets (no Confidentiality beyond Security), and didn't collect personal information (no Privacy).
Focusing on just two criteria saved them $40,000 in audit costs and three months of implementation time.
The Common Criteria Categories: Building Blocks of Control
Here's where things get interesting. Within each Trust Services Criterion, AICPA organizes requirements into categories. Think of these as the chapters in your SOC 2 story.
After years of implementation, I've found that these nine categories appear across all criteria:
1. Control Environment (CC1)
This is about your organization's culture and governance. I call it the "do people actually care about security?" category.
Key Focus Areas:
Organizational structure and authority
Commitment to competence and integrity
Board oversight and accountability
Performance measurement and rewards
Real Talk: I've seen companies with every security tool imaginable fail audits because their control environment was weak. When employees see executives ignoring security policies, no technical control will save you.
2. Communication and Information (CC2)
How you share security-relevant information internally and externally.
Key Focus Areas:
Internal communication channels
External communication with customers and vendors
Quality of information used for controls
Reporting of control deficiencies
Story Time: A fintech startup I worked with had amazing security practices but terrible documentation. Their audit failed because auditors couldn't verify controls were communicated to the right people. We spent two months backfilling documentation that should have been created along the way.
3. Risk Assessment (CC3)
How you identify, analyze, and respond to risks.
Key Focus Areas:
Identification of relevant risks
Analysis of risk significance
Risk response decisions
Assessment of fraud risk
"Risk assessment isn't a one-time document gathering dust in SharePoint. It's a living process that should inform every security decision you make."
4. Monitoring Activities (CC4)
How you verify that controls are actually working.
Key Focus Areas:
Ongoing and periodic evaluations
Internal audit functions
Remediation of identified deficiencies
Management review processes
5. Control Activities (CC5)
The actual things you do to achieve security outcomes.
Key Focus Areas:
Selection and development of controls
Technology controls
Deployment through policies and procedures
Periodic review and updates
6. Logical and Physical Access Controls (CC6)
Who can access what, and how you prevent unauthorized access.
Key Focus Areas:
User provisioning and de-provisioning
Authentication mechanisms
Authorization and access rights
Physical security of facilities
7. System Operations (CC7)
Day-to-day management of your technology infrastructure.
Key Focus Areas:
Change management
System monitoring
Data backup and recovery
Capacity planning
8. Change Management (CC8)
How you manage changes to your systems safely.
Key Focus Areas:
Change approval processes
Testing procedures
Emergency change handling
Change communication
9. Risk Mitigation (CC9)
How you protect against specific threats.
Key Focus Areas:
Malware protection
Network security
Data loss prevention
Vulnerability management
The Master Control Matrix: Your Implementation Roadmap
Here's the matrix I use with every client. This shows how Common Criteria map to specific controls you need to implement. I'm going to share the Security criterion first since it's mandatory for everyone.
Security Criterion - Essential Controls Matrix
Common Criteria | Control Category | Example Controls | Why It Matters |
|---|---|---|---|
CC1.1 | Entity demonstrates commitment to integrity and ethics | - Code of conduct<br>- Background checks<br>- Conflict of interest policies | Sets the tone for the entire security program |
CC1.2 | Board exercises oversight | - Quarterly security reviews<br>- Board cybersecurity training<br>- Risk reporting to board | Ensures accountability at the highest level |
CC1.3 | Management establishes structure and authority | - Organization chart<br>- Role definitions<br>- Segregation of duties | Prevents concentration of power and risk |
CC2.1 | Information system supports internal control | - SIEM implementation<br>- Security dashboards<br>- Automated alerts | Enables timely decision-making |
CC2.2 | Communicates internally | - Security newsletters<br>- Incident reporting channels<br>- Policy acknowledgment tracking | Ensures everyone knows their responsibilities |
CC3.1 | Entity specifies objectives | - Security objectives document<br>- Risk tolerance statements<br>- Performance metrics | Gives the team a target to hit |
CC3.2 | Identifies and analyzes risk | - Risk register<br>- Threat modeling<br>- Impact assessments | Focuses resources on real threats |
CC3.4 | Assesses fraud risk | - Fraud risk assessment<br>- Anti-fraud controls<br>- Whistleblower hotline | Addresses both external and internal threats |
CC4.1 | Monitors controls | - Control self-assessments<br>- Internal audit program<br>- KPI tracking | Catches problems before auditors do |
CC5.1 | Selects and develops controls | - Control design documentation<br>- Control testing evidence<br>- Control remediation tracking | Proves controls are appropriate and effective |
CC6.1 | Implements logical access controls | - Identity management system<br>- MFA implementation<br>- Access reviews | Prevents unauthorized system access |
CC6.2 | Implements physical security | - Badge access systems<br>- Visitor logs<br>- Security cameras | Protects physical assets and facilities |
CC6.6 | Manages encryption keys | - Key management system<br>- Key rotation procedures<br>- Key access logs | Ensures encrypted data stays protected |
CC7.1 | Manages system operations | - Change management process<br>- Deployment procedures<br>- Configuration standards | Maintains system stability and security |
CC7.2 | Monitors system components | - Infrastructure monitoring<br>- Application performance monitoring<br>- Capacity management | Detects issues before they impact customers |
CC7.3 | Implements backup procedures | - Automated backups<br>- Backup testing<br>- Disaster recovery plan | Ensures business continuity |
CC8.1 | Manages changes | - Change request system<br>- Change approval workflow<br>- Post-implementation review | Prevents unauthorized or harmful changes |
CC9.1 | Identifies and assesses threats | - Vulnerability scanning<br>- Penetration testing<br>- Threat intelligence | Proactively identifies security gaps |
CC9.2 | Manages threats | - Patch management<br>- Anti-malware systems<br>- Incident response plan | Responds to and mitigates identified threats |
Availability Criterion - Control Mapping
For organizations that need to prove system availability, here's how additional controls map:
Common Criteria | Specific to Availability | Example Implementation | Audit Evidence |
|---|---|---|---|
A1.1 | Maintains availability commitments | - SLA documentation<br>- Uptime monitoring<br>- Performance baselines | SLA agreements, uptime reports, monitoring dashboards |
A1.2 | Monitors system availability | - 24/7 monitoring<br>- Alerting systems<br>- Incident tracking | Alert logs, incident tickets, response times |
A1.3 | Implements availability controls | - Load balancing<br>- Redundant systems<br>- Failover procedures | Architecture diagrams, failover tests, capacity reports |
Processing Integrity Criterion - Control Mapping
For organizations processing customer transactions or data:
Common Criteria | Processing Integrity Focus | Example Implementation | Real-World Application |
|---|---|---|---|
PI1.1 | Processes data completely | - Transaction logging<br>- Reconciliation procedures<br>- Error handling | Payment processors, data transformation services |
PI1.2 | Processes data accurately | - Data validation rules<br>- Quality checks<br>- Exception reporting | Financial calculations, data analytics platforms |
PI1.3 | Processes data timely | - Processing SLAs<br>- Queue monitoring<br>- Performance metrics | Order processing, report generation services |
PI1.4 | Processes data authorized | - Transaction approval workflows<br>- Authorization logs<br>- Segregation of duties | Banking apps, approval systems |
PI1.5 | Maintains processing integrity | - Batch controls<br>- Hash verification<br>- Audit trails | Data migration, ETL processes |
Building Your Custom Control Matrix: A Step-by-Step Guide
Let me walk you through how I help clients build their specific control matrix. This is the exact process I used with a healthcare technology company last year to go from "completely lost" to "audit ready" in seven months.
Step 1: Determine Your Required Criteria
Start by honestly assessing what your service actually does:
Decision Tree:
Do you handle any data? → Security (always yes)
Do you promise uptime in contracts? → Availability
Do you process, transform, or calculate customer data? → Processing Integrity
Do you handle trade secrets or proprietary business information? → Confidentiality
Do you collect personal information? → Privacy
I worked with a project management SaaS company that initially thought they needed all five criteria. After this analysis:
Security: ✓ (handles customer data)
Availability: ✓ (99.9% uptime SLA in contracts)
Processing Integrity: ✗ (doesn't transform or calculate data)
Confidentiality: ✗ (no trade secrets beyond standard security)
Privacy: ✓ (collects user emails and names)
Focusing on Security, Availability, and Privacy saved them approximately $35,000 in audit costs.
"Don't collect criteria like Pokemon. Choose only what your business actually needs to demonstrate to customers."
Step 2: Map Your Existing Controls
Most organizations have more controls than they realize—they just aren't documented. Here's a practical exercise I do with clients:
Control Inventory Workshop:
Business Process | Current Practice | Applicable Criteria | Common Criteria Category | Evidence Available |
|---|---|---|---|---|
Employee onboarding | IT sends access request form | Security (CC6.1) | Logical Access | Email tickets, access logs |
Code deployment | Must pass automated tests | Security (CC8.1) | Change Management | CI/CD logs, test results |
Customer support | Tickets logged in Zendesk | Security (CC2.2) | Communication | Zendesk reports |
Data backup | Nightly automated backups | Availability (A1.3) | System Operations | Backup logs, restore tests |
A fintech company I worked with discovered they had 73 existing practices that qualified as SOC 2 controls. They just needed to document them properly.
Step 3: Identify Control Gaps
Now compare what you have against what's required. Here's how I organize this:
Gap Analysis Matrix:
Required Control | Current State | Gap | Priority | Effort to Close |
|---|---|---|---|---|
MFA on all systems | Implemented on production, missing on admin tools | Medium | High | 2 weeks |
Quarterly access reviews | Never performed | High | High | 1 month setup, ongoing |
Penetration testing | Last test 18 months ago | Medium | Medium | Vendor engagement |
Incident response plan | Documented but never tested | Low | High | 2 weeks |
Backup restoration testing | Backups exist, never tested restore | High | Critical | Immediate |
This matrix becomes your implementation roadmap. I always tell clients: "This is your project plan. Everything on here needs to be complete before your audit."
Step 4: Create Control Descriptions
For each control, document:
What the control does
How it operates
Who is responsible
When it executes (frequency)
Where evidence is stored
Here's an example from a real client:
Control: User Access Provisioning (CC6.1)
Element | Description |
|---|---|
What | Ensures new employees receive appropriate system access based on role |
How | HR submits access request via ServiceNow → Manager approves → IT provisions access using least privilege principle → Access logged in IDP |
Who | HR initiates, Direct Manager approves, IT Administrator executes |
When | Upon hire and role changes |
Evidence | ServiceNow tickets, approval emails, access logs from Okta, quarterly access reviews |
Testing | Sample 5 new hires per quarter, verify approval chain and appropriate access |
This level of detail makes audits smooth. Auditors know exactly what to look for, and you know exactly what to provide.
Common Control Pitfalls I've Seen (And How to Avoid Them)
After 15 years and dozens of audits, I've seen the same mistakes repeatedly:
Pitfall 1: Copy-Paste Controls From the Internet
The Mistake: A startup I worked with downloaded a "SOC 2 control matrix template" and claimed they implemented everything listed.
The Problem: The template included controls for physical data centers. They were 100% cloud-based with no data centers.
The Fix: Build your control matrix based on YOUR actual environment and operations. Templates are starting points, not finish lines.
Pitfall 2: Controls Without Evidence
The Mistake: "We do quarterly access reviews" (but had no documentation proving it).
The Problem: In SOC 2 audits, if you can't prove it happened, it didn't happen.
The Fix: Every control needs an evidence trail. I use this rule: "If you can't point to a file, log, or screenshot proving this control operated, it's not actually implemented."
Pitfall 3: Over-Engineering Controls
The Mistake: A company implemented a complex, three-tier approval process for any system configuration change—even fixing typos in documentation.
The Problem: The process was so cumbersome that IT started finding workarounds, creating more risk.
The Fix: Controls should be effective, not bureaucratic. Design controls that fit your organization's maturity and size.
"The best control is one that actually gets followed. A theoretically perfect control that everyone bypasses is worse than useless—it's dangerous because you think you're protected when you're not."
Pitfall 4: Ignoring the Control Environment
The Mistake: Companies focus entirely on technical controls (CC6-CC9) and neglect governance (CC1-CC5).
The Problem: I've watched organizations with perfect technical controls fail audits because they couldn't demonstrate tone at the top or management oversight.
The Fix: Spend at least 30% of your effort on CC1-CC5. These "soft" controls are just as important as the technical ones.
Advanced Matrix Techniques: Taking It to the Next Level
Once you have the basics down, here are advanced techniques I use with mature organizations:
Risk-Weighted Control Matrix
Not all controls have equal impact. Here's how I prioritize:
Control | Risk Addressed | Impact if Fails | Likelihood of Failure | Priority Score | Implementation Status |
|---|---|---|---|---|---|
MFA on production | Unauthorized access | Critical (10) | Medium (5) | 50 | Complete |
Quarterly access reviews | Excess permissions | High (8) | High (7) | 56 | In Progress |
Penetration testing | Unknown vulnerabilities | Critical (10) | Medium (5) | 50 | Scheduled Q2 |
Password complexity | Weak authentication | Medium (5) | Low (3) | 15 | Complete |
Priority Score = Impact × Likelihood. Focus on controls scoring above 40 first.
Control Testing Matrix
For each control, define how it will be tested:
Control ID | Control Description | Testing Method | Sample Size | Testing Frequency | Pass Criteria |
|---|---|---|---|---|---|
CC6.1-01 | User provisioning follows approval workflow | Inquiry + Inspection | 25 new users | Quarterly | 100% have approved tickets |
CC7.2-01 | Production systems monitored 24/7 | Observation + Inspection | N/A - population | Monthly | <5 min alert response |
CC8.1-01 | Changes require approval | Inspection + Reperformance | 40 changes | Quarterly | 100% have approval + testing |
This matrix becomes your internal audit program and prepares you for external audit.
Evidence Collection Matrix
Create a map of where evidence lives:
Control Category | Evidence Type | Storage Location | Retention Period | Access Control | Audit Frequency |
|---|---|---|---|---|---|
Access Reviews | Excel spreadsheet | SharePoint/Compliance folder | 7 years | Security team only | Quarterly |
Change Approvals | Jira tickets | Jira Production Board | 7 years | IT team read-only | Per change |
Security Training | Completion certificates | LMS system | 7 years | HR + Security | Annual |
Vulnerability Scans | PDF reports | Security tool exports | 3 years | Security team only | Weekly |
Penetration Tests | PDF reports | Vendor portal + SharePoint | 7 years | Senior leadership | Annual |
When audit time comes, you know exactly where to find everything.
Real-World Example: Complete Control Matrix Implementation
Let me walk you through a real client engagement from 2023 (details changed for confidentiality).
Company: Healthcare scheduling software (SaaS) Team Size: 45 employees Criteria Needed: Security, Availability, Confidentiality Timeline: 8 months to audit Budget: $120,000 (consulting + audit)
Month 1-2: Assessment and Gap Analysis
We started with their current state:
Category | Status | Gap Count | Criticality |
|---|---|---|---|
Control Environment | Minimal documentation | 8 gaps | High |
Risk Assessment | Informal process | 5 gaps | High |
Logical Access | Partially implemented | 12 gaps | Critical |
System Operations | Good practices, poor docs | 7 gaps | Medium |
Change Management | Ad-hoc process | 9 gaps | High |
Risk Mitigation | Technical controls exist | 4 gaps | Low |
Total Gaps: 45 controls needing implementation or documentation
Month 3-5: Control Implementation
We prioritized based on criticality and implementation time:
Phase 1 (Months 3-4): Critical Controls
Implemented MFA across all systems
Documented and began quarterly access reviews
Created incident response plan and playbooks
Established change management workflow in Jira
Implemented automated backup testing
Phase 2 (Month 5): High-Priority Controls
Documented control environment policies
Conducted and documented risk assessment
Implemented SIEM solution for monitoring
Established vendor management program
Created security awareness training program
Month 6-7: Documentation and Testing
Control Testing Results:
Control Area | Controls Tested | Passed | Failed | Remediation Status |
|---|---|---|---|---|
Access Controls | 15 | 14 | 1 | Fixed - MFA gap on test environment |
Change Management | 12 | 11 | 1 | Fixed - missing approval on hot fix |
System Operations | 10 | 10 | 0 | All passed |
Risk Mitigation | 8 | 7 | 1 | Fixed - vulnerability scan schedule |
Month 8: Audit
Audit Results:
No Type 1 exceptions (design deficiencies)
2 Type 2 exceptions (operating effectiveness issues - both minor)
Successfully achieved SOC 2 Type II certification
Business Impact:
Closed 3 enterprise deals worth $1.4M ARR within 60 days of certification
Reduced cyber insurance premium by $45,000 annually
Sales cycle for enterprise deals decreased from 9 months to 4.5 months
The CEO told me: "The SOC 2 audit process was expensive and time-consuming, but it fundamentally changed how we operate. We're not just more secure—we're more professional in every way."
Your Control Matrix Starter Template
Let me give you a starter template to build from. This is simplified but covers the essentials:
Essential Security Controls (Minimum Viable Matrix)
# | Control | Description | Evidence Type | Frequency |
|---|---|---|---|---|
1 | Code of Conduct | All employees acknowledge security policies | Signed acknowledgments | Annual |
2 | Background Checks | Verify employees before system access | Background check reports | Pre-hire |
3 | Security Training | Employees complete security awareness training | Training certificates | Annual |
4 | Risk Assessment | Document and assess security risks | Risk assessment document | Annual |
5 | Change Management | All changes approved and tested | Change tickets | Per change |
6 | Access Provisioning | New access requires manager approval | Approval emails + logs | Per request |
7 | Access Reviews | Quarterly review of all system access | Review spreadsheets | Quarterly |
8 | Multi-Factor Authentication | MFA required for all production access | MFA logs | Continuous |
9 | Password Policy | Strong passwords enforced technically | Password policy settings | Continuous |
10 | System Monitoring | 24/7 monitoring of security events | SIEM alerts + response | Continuous |
11 | Vulnerability Scanning | Regular scanning for vulnerabilities | Scan reports | Monthly |
12 | Patch Management | Critical patches applied within 30 days | Patch reports | Monthly |
13 | Anti-Malware | Endpoint protection on all devices | AV logs + updates | Continuous |
14 | Data Backups | Automated daily backups | Backup logs | Daily |
15 | Backup Testing | Quarterly restoration testing | Test results | Quarterly |
16 | Incident Response | Documented response procedures | Incident response plan | Annual review |
17 | Vendor Management | Security review of critical vendors | Vendor assessments | Annual |
18 | Physical Security | Badge access to facilities | Access logs | Continuous |
19 | Network Security | Firewall protection on all networks | Firewall rules + logs | Continuous |
20 | Encryption | Data encrypted in transit and at rest | Encryption verification | Continuous |
This covers approximately 80% of what most organizations need for a basic SOC 2 Security audit.
The Matrix Maintenance Challenge
Here's something nobody tells you: creating the control matrix is the easy part—maintaining it is the real challenge.
I worked with a company that achieved SOC 2 in 2020. By 2021, their surveillance audit failed because:
4 new employees never completed security training
Quarterly access reviews stopped after the first audit
Change management discipline deteriorated
Documentation wasn't updated when tools changed
They had to remediate and reaudit, costing an extra $45,000 and delaying a major customer deal.
My Maintenance Framework
Weekly Tasks:
Review security alerts and incidents
Verify backups completed successfully
Check vulnerability scan results
Monitor access request processing
Monthly Tasks:
Run vulnerability scans
Review change management compliance
Verify patch management status
Check anti-malware updates and detections
Quarterly Tasks:
Conduct access reviews
Perform control self-assessments
Review and test incident response procedures
Update risk assessment for changes
Annual Tasks:
Complete security awareness training
Conduct penetration testing
Review and update all policies
Perform vendor security reviews
Board-level security review
"SOC 2 compliance is not a destination—it's a journey. The organizations that succeed treat it like they treat financial reporting: as a routine, ongoing part of business operations."
When to Get Help
I'm a big believer in DIY approaches when possible, but here's when I tell companies they need external help:
Definitely Get Help If:
This is your first SOC 2 audit
You have complex technology environments
You're under time pressure (less than 6 months)
You've failed a previous audit
You lack internal security expertise
You Might Be Fine DIY If:
You have experienced security team members
You have 12+ months timeline
Your environment is relatively simple
You're willing to learn through trial and error
Budget is extremely constrained
The average cost of external help: $30,000-$80,000 for consulting plus $15,000-$30,000 for audit fees.
The average cost of failing an audit and reauditing: $45,000-$75,000 in additional fees plus deal delays.
Final Thoughts: The Control Matrix as Your Security Foundation
After 15 years in this field, I've come to see SOC 2 control matrices not as compliance paperwork, but as the blueprint for organizational security.
When you map controls to criteria systematically, something magical happens:
You understand exactly what you need to do
Your team has clear responsibilities
Audits become predictable rather than stressful
Your security posture actually improves (not just on paper)
The control matrix I've shared today isn't just about passing audits. It's about building a security program that:
Protects your customers' data
Enables you to win enterprise deals
Scales with your growth
Creates a culture of security consciousness
Your homework for this week:
Determine which TSC criteria you actually need
List your existing controls (you have more than you think)
Identify your top 5 control gaps
Create evidence collection processes for your existing controls
Schedule time to work on this consistently (not just before audits)
Remember: Perfect is the enemy of done. Start with the basics, get those right, then layer on sophistication over time.
You don't need a perfect control matrix on day one. You need a functional one that you can actually implement and maintain.
Start there. Everything else follows.