Understanding how Trust Services Criteria, controls, policies, procedures, people, roles, systems, and evidence all connect to form a functioning compliance program.
SOC 2 is built as a layered system. At the top sit the AICPA's Trust Services Criteria, and everything below exists to satisfy them. Here's the full hierarchy from top to bottom.
Each entity in the SOC 2 ecosystem plays a distinct role. Here's what each one is and what it's responsible for.
Nothing in SOC 2 exists in isolation. Every entity connects to others through specific relationships. Understanding these connections is critical to building a system that doesn't collapse under audit scrutiny.
CC6.1 (Logical Access) might be covered by your "MFA Required" control AND your "Role-Based Access" control. Meanwhile, "MFA Required" also helps satisfy CC6.3 and CC6.6.
Your "Access Review" control references the Access Management Policy. That same policy also backs your "Onboarding Access" and "Offboarding Revocation" controls.
The Incident Response Policy has procedures for: detection, triage, escalation, communication, post-mortem. Each is a separate documented process.
The "Security Engineer" role executes the vulnerability scanning procedure AND the incident triage procedure. The scanning procedure may also involve the "DevOps Engineer" role.
At a startup, the CTO might hold the roles of "Security Officer," "Engineering Manager," and "Incident Commander." At scale, these are separate people. The mapping must be explicit and documented.
"Encrypted data at rest" applies to your RDS instances, S3 buckets, and EBS volumes. Each system needs its own evidence that encryption is enabled. Meanwhile, AWS KMS is the system that enforces the control across all of them.
Here's a realistic mock of what teams interact with daily when managing their SOC 2 program. This is representative of tools like Vanta, Drata, Secureframe, or custom-built GRC platforms.
| Control ID | Control Name | TSC Mapping | Owner | Status | Evidence |
|---|---|---|---|---|---|
| CTRL-001 | Multi-factor authentication required | CC6.1, CC6.6 | J. Martinez (Security) | Pass | 4/4 |
| CTRL-002 | Quarterly access reviews | CC6.2, CC6.3 | S. Chen (IT Admin) | Pass | 3/3 |
| CTRL-003 | Vulnerability scanning (weekly) | CC7.1 | A. Patel (DevOps) | Review | 2/3 |
| CTRL-004 | Encrypted backups with 30-day retention | CC6.1, A1.2 | A. Patel (DevOps) | Pass | 5/5 |
| CTRL-005 | Annual security awareness training | CC1.4 | R. Kim (HR) | Fail | 0/2 |
| CTRL-006 | Change management: PR review required | CC8.1 | M. Lopez (Eng Mgr) | Pass | 8/8 |
| CTRL-007 | Incident response plan tested annually | CC7.3, CC7.4 | J. Martinez (Security) | Fail | 1/4 |
This is what the “Controls” page looks like when selected from the sidebar — a dedicated control registry with search, filtering by status, and expandable detail panels for each control.
| Control ID | Control Name | Category | TSC Criteria | Owner | Status | Evidence | Last Tested |
|---|---|---|---|---|---|---|---|
| CTRL-001 | Multi-factor authentication required | Access Controls | CC6.1CC6.6 | J. Martinez | Pass | 4/4 | Mar 12, 2025 |
| CTRL-002 | Quarterly access reviews | Access Controls | CC6.2CC6.3 | S. Chen | Pass | 3/3 | Mar 1, 2025 |
| CTRL-003 | Vulnerability scanning (weekly) | Risk & Monitoring | CC7.1 | A. Patel | Review | 2/3 | Mar 10, 2025 |
CTRL-003 Vulnerability Scanning (Weekly) Needs Review
All production systems must undergo automated vulnerability scanning on a weekly cadence. Critical and high findings must be remediated within 14 days; medium within 30 days.
Mapped TSC Criteria
CC7.1
Detect and monitor anomalies
Linked Policies
POL-008
Vulnerability Management Policy
POL-003
Risk Assessment Policy
Systems In Scope
AWS EC2
AWS RDS
GitHub Enterprise
Evidence (2 of 3 collected)Weekly Nessus scan report (auto)
Mar 10
Collected
AWS Inspector findings export
Mar 10
Collected
Remediation tracker spreadsheet
—
Missing
⚠ Missing evidence: Remediation tracker must be uploaded before next audit review.
Automated Test Results
✓
Mar 10
Scan completed — 0 critical, 2 medium
✓
Mar 3
Scan completed — 0 critical, 1 medium
●
Feb 24
Scan completed — 1 critical, 3 medium
✓
Feb 17
Scan completed — 0 critical, 1 medium
✗
Feb 10
Scan failed — agent timeout on prod-db-01
Activity Log2h ago
A. Patel acknowledged 2 medium findings from Mar 10 scan
1d ago
System auto-collected Nessus scan report for week of Mar 10
5d ago
J. Martinez flagged remediation tracker as overdue
12d ago
A. Patel resolved critical finding CVE-2025-1234 from Feb 24 scan
19d ago
System detected critical vulnerability in Feb 24 scan — alert sent to A. Patel
|
|||||||
| CTRL-004 | Encrypted backups with 30-day retention | Operations | CC6.1A1.2 | A. Patel | Pass | 5/5 | Mar 14, 2025 |
| CTRL-005 | Annual security awareness training | Operations | CC1.4 | R. Kim | Fail | 0/2 | Feb 28, 2025 |
| CTRL-006 | Change management: PR review required | Change Mgmt | CC8.1 | M. Lopez | Pass | 8/8 | Mar 15, 2025 |
| CTRL-007 | Incident response plan tested annually | Risk & Monitoring | CC7.3CC7.4 | J. Martinez | Fail | 1/4 | Jan 20, 2025 |
Each control needs evidence to prove it's working. Here's what a typical evidence vault looks like for a single control.
Auditors need to see exactly who is responsible for what. Here's a typical role assignment view.
| Person | Role(s) | Controls Owned | Procedures Assigned | Training Status |
|---|---|---|---|---|
| J. Martinez Security Engineer |
Security Officer, Incident Commander | CTRL-001, CTRL-007, CTRL-012 | 5 procedures | Complete |
| S. Chen IT Administrator |
Access Administrator | CTRL-002, CTRL-009 | 3 procedures | Complete |
| A. Patel DevOps Lead |
Infrastructure Owner | CTRL-003, CTRL-004, CTRL-006 | 4 procedures | Pending |
| R. Kim HR Manager |
Training Coordinator | CTRL-005, CTRL-010 | 2 procedures | Overdue |
Every in-scope system must be documented with its purpose, data classification, and which controls apply to it.
| System | Category | Data Classification | Controls Applied | Status |
|---|---|---|---|---|
| AWS (us-east-1) Production infrastructure |
IaaS | Confidential | CTRL-001, 003, 004, 006 | Compliant |
| GitHub Enterprise Source code management |
SaaS | Internal | CTRL-001, 006 | Compliant |
| Okta Identity provider & SSO |
SaaS | Confidential | CTRL-001, 002 | Compliant |
| Slack Team communication |
SaaS | Public | CTRL-001 | Review |
| PostgreSQL RDS Primary database |
DBaaS | Confidential | CTRL-003, 004 | Compliant |
Evidence isn't just collected once. It follows a lifecycle from generation to audit review.
These are the mistakes that derail audits, waste months of preparation, and lead to qualified opinions. Many stem from treating SOC 2 as a one-time project rather than an ongoing program.
The single most common disaster. Your architecture changed — you migrated from Heroku to AWS, replaced Jenkins with GitHub Actions, or restructured your team — but your controls still reference the old setup. The auditor now has controls that don't match reality.
Controls that existed last year are carried forward into the new period even though the underlying system or process no longer exists. Nobody notices until the auditor asks for evidence of a system that was decommissioned 8 months ago.
Policies are updated but the version that was in effect during the audit period is lost. Auditors need to see the policy as it was at the time the control was operating, not the version you updated last week.
You migrated your monitoring from Datadog to Grafana in June. You have Datadog evidence for Jan-May and Grafana evidence from Aug-Dec. But June-July has nothing because the new system wasn't fully configured yet. That's a finding.
Someone leaves the company. Their role was "Incident Commander." Nobody formally reassigns the role. For 3 months, the incident response procedure technically has no owner. The auditor spots this as a control failure.
You add a new service, a new database, a new third-party vendor. They process customer data. But nobody updated the system inventory, added controls for the new system, or notified the auditor about the scope change.
Teams write a "policy" that's actually a step-by-step runbook, or write a "procedure" that's just a high-level mandate. Auditors expect clear separation: policies say what and why; procedures say how and when.
You collect a screenshot of your firewall rules today and call it evidence for the whole year. But SOC 2 Type II covers a period, not a moment. The auditor wants to know the control was operating consistently across the entire period.
Here's what happens when you blindly carry over last year's control environment into a new audit period after your architecture has changed.
Instead of a blind carryover, here's the recommended process when starting a new audit period.
Before the new period starts, review all infrastructure, tooling, and vendor changes from the past year. Catalog what was added, removed, or replaced.
Walk through every control. Update system references, tool names, and configuration details. Retire controls for decommissioned systems. Create new controls for new systems.
Verify all role assignments. Account for departures, new hires, and reorganizations. Ensure every control has a current, valid owner.
Confirm all policies are current and reflect the new architecture. Create new versions where needed. Ensure effective dates align with the audit period start.
Test that automated evidence collection works with the new systems. Set up new integrations. Verify that evidence is being generated from day one of the new period.
Brief your auditor on material changes to the control environment. Discuss any new systems, retired controls, or scope changes before they start fieldwork.
TSC, controls, policies, procedures, people, roles, systems, and evidence are all interconnected. Weakness in any layer propagates upward and becomes an audit finding.
You can have the best controls in the world on paper. Without evidence that they're operating effectively over the full audit period, they don't exist to the auditor.
The transition between audit periods is the most dangerous time. Architecture changes, personnel turnover, and tool migrations all create gaps that are easy to miss.
SOC 2 Type II isn't a project with a deadline. It's an ongoing program that runs 365 days a year. The audit just checks whether you maintained it consistently.
Copy the prompt below and use it to generate a fully functional, interactive SOC-2 compliance management app — complete with data storage, CRUD operations, and all the views shown above.