When to Use This Skill
- Preparing for a SOC 2 Type I or Type II examination
- Annual SOC 2 readiness assessment before the auditor arrives
- After a major infrastructure change (cloud migration, new CI/CD pipeline, provider switch)
- After adding a new service, database, or third-party integration
- After an incident — to verify controls operated correctly during the event
- When onboarding a new compliance automation tool (Vanta, Drata, Secureframe)
- Periodic control testing — quarterly self-assessment between audits
- When building a control matrix from scratch for a new product
- Before selecting Trust Service Categories for your first SOC 2 report
How It Works
┌──────────────────────────────────────────────────────────────────────┐
│ SOC 2 AUDIT FLOW │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ PHASE 1 │ │ PHASE 2 │ │ PHASE 3 │ │ PHASE 4 │ │
│ │ Scope & │─▶│ Control │─▶│ Evidence │─▶│ Gap │ │
│ │ Criteria │ │ Mapping │ │ Review │ │ Analysis │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ Identify Map each Verify each Identify │
│ TSC in CC/A/PI/C/P control has missing │
│ scope to controls evidence controls │
│ │ │ │
│ │ ┌──────────┐ │ │
│ │ │ PHASE 5 │ │ │
│ └─────────────▶│ Readiness│◀────────────────┘ │
│ │ Report │ │
│ └──────────┘ │
│ Type I/II │
│ readiness │
│ + findings │
│ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ TRUST SERVICE CATEGORIES │ │
│ │ │ │
│ │ SECURITY (Required) CC1-CC9 Organization, access, │ │
│ │ operations, change mgmt │ │
│ │ AVAILABILITY A1 Uptime, failover, DR │ │
│ │ PROCESSING INTEGRITY PI1 Accuracy, completeness │ │
│ │ CONFIDENTIALITY C1 Data classification, │ │
│ │ encryption, disposal │ │
│ │ PRIVACY P1-P8 Notice, consent, use, │ │
│ │ disclosure, retention │ │
│ └──────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────┘
Phase 1: SOC 2 Framework Overview
Trust Service Criteria Mapping
┌──────────────────────────────────────────────────────────────────────┐
│ TRUST SERVICE CRITERIA STRUCTURE │
│ │
│ SECURITY (CC) ─── Always required ── Foundation for all categories │
│ │ │
│ ├── CC1: Control Environment │
│ │ └── Org structure, board oversight, policies, ethics │
│ ├── CC2: Communication & Information │
│ │ └── Internal/external communication, system descriptions │
│ ├── CC3: Risk Assessment │
│ │ └── Risk identification, fraud risk, change impact │
│ ├── CC4: Monitoring Activities │
│ │ └── Ongoing monitoring, deficiency evaluation │
│ ├── CC5: Control Activities │
│ │ └── Policies mapped to risks, technology controls │
│ ├── CC6: Logical & Physical Access Controls │
│ │ └── Access provisioning, authentication, restrictions │
│ ├── CC7: System Operations │
│ │ └── Detection, incident response, recovery │
│ ├── CC8: Change Management │
│ │ └── Change authorization, testing, approval │
│ └── CC9: Risk Mitigation │
│ └── Vendor management, business continuity │
│ │
│ AVAILABILITY (A1) ── Optional ── Uptime + Recovery │
│ │ │
│ └── A1.1-A1.3: Capacity, DR, backup, failover, SLA monitoring │
│ │
│ PROCESSING INTEGRITY (PI1) ── Optional ── Accuracy │
│ │ │
│ └── PI1.1-PI1.5: Input validation, processing, output, error │
│ handling, corrections │
│ │
│ CONFIDENTIALITY (C1) ── Optional ── Data protection │
│ │ │
│ └── C1.1-C1.2: Classification, encryption, access, disposal │
│ │
│ PRIVACY (P1-P8) ── Optional ── Personal information │
│ │ │
│ ├── P1: Notice P5: Use, Retention, Disposal │
│ ├── P2: Choice/Consent P6: Disclosure to Third Parties │
│ ├── P3: Collection P7: Security for Privacy │
│ └── P4: Access P8: Quality │
└──────────────────────────────────────────────────────────────────────┘
Type I vs Type II Comparison
| Dimension | Type I | Type II | |
|---|
| What it tests | Control design (do controls exist?) | Control effectiveness (do controls work consistently?) | |
| Time scope | Point-in-time (single date) | Period of time (6-12 months) | |
| Evidence needed | Current policies, configs, screenshots | Logs, audit trails, samples across the period | |
| Auditor work | Inspect and inquire | Inspect, inquire, observe, re-perform, sample | |
| Timeline to achieve | 2-4 months | 6-12 months after Type I | |
| Typical first step | Yes — most companies start here | After Type I is clean | |
| Customer expectation | Acceptable for early-stage | Required for enterprise sales | |
| Cost | Lower (less auditor time) | Higher (sampling, testing over period) | |
| Common mistake | Policies exist but are not enforced | Controls enforced in month 1, relaxed by month 6 | |
Phase 2: Common Criteria Deep Dive — CC1 through CC9
CC1: Control Environment
┌──────────────────────────────────────────────────────────────┐
│ CC1: CONTROL ENVIRONMENT │
│ "Does the organization demonstrate commitment to integrity │
│ and ethical values?" │
│ │
│ WHAT THE AUDITOR CHECKS │
│ □ Board/management oversight of security program │
│ □ Organizational structure with defined security roles │
│ □ Written security policies (acceptable use, access, │
│ incident response, change management) │
│ □ Code of conduct / ethics policy │
│ □ Background checks for employees with system access │
│ □ Security awareness training — completion records │
│ □ Annual policy review with dated sign-off │
│ │
│ EVIDENCE IN CODE / INFRA │
│ □ CODEOWNERS file defines who owns what │
│ □ GitHub org has SSO enforced │
│ □ Team structure in identity provider (Okta, Google) │
│ matches org chart │
│ □ Security policies stored in version control │
│ (dated, reviewed, approved via PR) │
│ □ Onboarding/offboarding checklists in ticketing system │
│ │
│ COMMON FINDINGS │
│ → No evidence of annual policy review │
│ → Security training not tracked or completed │
│ → No defined security roles in org structure │
└──────────────────────────────────────────────────────────────┘
CC2: Communication and Information
┌──────────────────────────────────────────────────────────────┐
│ CC2: COMMUNICATION AND INFORMATION │
│ "Does the organization communicate security responsibilities│
│ internally and externally?" │
│ │
│ WHAT THE AUDITOR CHECKS │
│ □ System description document (what the system does, │
│ boundaries, components, data flows) │
│ □ Internal security communications (Slack channels, │
│ email updates, training materials) │
│ □ External communications (privacy policy, ToS, │
│ security page, incident notification process) │
│ □ Whistleblower / reporting mechanism │
│ □ Vendor security requirements communicated │
│ │
│ EVIDENCE IN CODE / INFRA │
│ □ Architecture diagrams in version control │
│ □ README files with security-relevant setup instructions │
│ □ API documentation with auth requirements noted │
│ □ Public security.txt (/.well-known/security.txt) │
│ □ Status page (e.g., statuspage.io) for external comms │
│ □ Incident communication templates │
│ │
│ COMMON FINDINGS │
│ → System description is outdated or missing │
│ → No public-facing security contact or policy │
│ → Architecture diagrams not maintained │
└──────────────────────────────────────────────────────────────┘
CC3: Risk Assessment
┌──────────────────────────────────────────────────────────────┐
│ CC3: RISK ASSESSMENT │
│ "Does the organization identify and analyze risks?" │
│ │
│ WHAT THE AUDITOR CHECKS │
│ □ Formal risk assessment (annual minimum) │
│ □ Risk register with likelihood and impact ratings │
│ □ Fraud risk considerations │
│ □ Change-triggered risk reassessment (new features, │
│ new vendors, infrastructure changes) │
│ □ Risk acceptance documented with owner sign-off │
│ │
│ EVIDENCE IN CODE / INFRA │
│ □ Threat modeling documents for critical features │
│ □ Security review checklist in PR templates │
│ □ Dependency vulnerability scanning in CI │
│ (npm audit, Snyk, Dependabot) │
│ □ Infrastructure scanning (AWS Config rules, │
│ ScoutSuite, Prowler) │
│ □ Penetration test reports (annual) │
│ │
│ COMMON FINDINGS │
│ → No formal risk assessment exists │
│ → Risk register not updated after major changes │
│ → No fraud risk analysis documented │
└──────────────────────────────────────────────────────────────┘
CC4: Monitoring Activities
┌──────────────────────────────────────────────────────────────┐
│ CC4: MONITORING ACTIVITIES │
│ "Does the organization monitor controls and remediate │
│ deficiencies?" │
│ │
│ WHAT THE AUDITOR CHECKS │
│ □ Ongoing monitoring of controls (not just annual review) │
│ □ Deficiency tracking and remediation timelines │
│ □ Internal audit or self-assessment program │
│ □ Control owners identified and accountable │
│ □ Management review of monitoring results │
│ │
│ EVIDENCE IN CODE / INFRA │
│ □ Alerting configured for security events │
│ (failed logins, privilege escalations, config changes) │
│ □ Dashboard for control health (Vanta, Drata, or custom) │
│ □ Automated compliance checks in CI/CD │
│ □ Log aggregation with retention (CloudWatch, Datadog, │
│ Splunk — minimum 90 days, ideally 1 year) │
│ □ AWS CloudTrail enabled on all regions │
│ □ GitHub audit log retention and monitoring │
│ │
│ COMMON FINDINGS │
│ → Alerts configured but nobody responds to them │
│ → Log retention shorter than audit period │
│ → No tracking of control deficiencies over time │
└──────────────────────────────────────────────────────────────┘
CC5: Control Activities
┌──────────────────────────────────────────────────────────────┐
│ CC5: CONTROL ACTIVITIES │
│ "Does the organization deploy control activities through │
│ policies and technology?" │
│ │
│ WHAT THE AUDITOR CHECKS │
│ □ Controls mapped to identified risks (risk-control matrix) │
│ □ Technology-based controls (automated, not manual) │
│ □ Policies that define expected behavior │
│ □ Control activities at all levels (infrastructure, │
│ application, operational) │
│ │
│ EVIDENCE IN CODE / INFRA │
│ □ Infrastructure as Code (Terraform/CloudFormation) │
│ — drift detection enabled │
│ □ Automated security controls: │
│ - Branch protection rules enforced │
│ - Required PR reviews before merge │
│ - CI pipeline must pass before deploy │
│ - SAST/DAST scanning in pipeline │
│ - Secrets scanning (GitGuardian, GitHub secret scanning) │
│ □ Network segmentation (VPC, security groups, NACLs) │
│ □ WAF rules on public endpoints │
│ □ Encryption at rest and in transit enforced │
│ │
│ COMMON FINDINGS │
│ → Controls exist but can be bypassed (admin override) │
│ → Manual controls without evidence of execution │
│ → Branch protection disabled for "convenience" │
└──────────────────────────────────────────────────────────────┘
Phase 3: Security Controls Audit — CC6, CC7, CC8
CC6: Logical and Physical Access Controls
┌──────────────────────────────────────────────────────────────┐
│ CC6: LOGICAL AND PHYSICAL ACCESS CONTROLS │
│ "Does the organization restrict logical and physical │
│ access to authorized users?" │
│ │
│ CC6.1 — ACCESS PROVISIONING │
│ □ New user access requires ticket/approval │
│ □ Access granted based on role (least privilege) │
│ □ No shared accounts or credentials │
│ □ Service accounts documented with owners │
│ □ API keys rotated on schedule (90 days recommended) │
│ │
│ CC6.2 — AUTHENTICATION │
│ □ MFA enforced for all users on: │
│ - Cloud console (AWS, GCP, Azure) │
│ - Source control (GitHub, GitLab) │
│ - Identity provider (Okta, Google Workspace) │
│ - Production infrastructure access │
│ □ SSO enforced where available │
│ □ Password policy meets minimum requirements: │
│ - 12+ characters, complexity, no reuse │
│ □ Session timeouts configured │
│ │
│ CC6.3 — ACCESS REMOVAL / DEPROVISIONING │
│ □ Terminated users removed within 24 hours │
│ □ Role changes trigger access review │
│ □ Quarterly access reviews with evidence: │
│ - Who reviewed, when, what was changed │
│ □ Dormant accounts disabled (90 days inactive) │
│ │
│ CC6.6 — SYSTEM BOUNDARIES │
│ □ Firewall rules documented and reviewed │
│ □ VPN or bastion host for production access │
│ □ Network segmentation between environments │
│ (dev/staging/production in separate VPCs) │
│ □ Public endpoints minimized and documented │
│ │
│ HOW TO CHECK IN CODE │
│ → Review IAM policies: least privilege, no wildcards (*) │
│ → Review security groups: no 0.0.0.0/0 on SSH/RDP │
│ → Review GitHub org: SSO required, 2FA enforced │
│ → Review .env files: no shared secrets across environments │
│ → Review database: connection restricted to app subnets │
│ │
│ COMMON FINDINGS │
│ → MFA not enforced on all critical systems │
│ → Terminated employee still has GitHub access │
│ → Root/admin account used for daily operations │
│ → Security group allows 0.0.0.0/0 on port 22 │
│ → Access reviews not performed or not documented │
└──────────────────────────────────────────────────────────────┘
CC7: System Operations
┌──────────────────────────────────────────────────────────────┐
│ CC7: SYSTEM OPERATIONS │
│ "Does the organization detect and respond to system │
│ anomalies and security events?" │
│ │
│ CC7.1 — VULNERABILITY MANAGEMENT │
│ □ Vulnerability scanning schedule (at least quarterly) │
│ □ Patching SLAs: │
│ - Critical: 72 hours │
│ - High: 30 days │
│ - Medium: 90 days │
│ □ OS and runtime patching (EC2 AMIs, container base │
│ images, Node.js/Python versions) │
│ □ Dependency scanning in CI (npm audit, Snyk) │
│ │
│ CC7.2 — ANOMALY DETECTION AND MONITORING │
│ □ Security event monitoring: │
│ - Failed login attempts (threshold alerting) │
│ - Privilege escalation events │
│ - Unauthorized API access attempts │
│ - Configuration changes to security controls │
│ □ Infrastructure monitoring: │
│ - CPU, memory, disk, network anomalies │
│ - Unexpected outbound network traffic │
│ - New IAM users/roles created │
│ □ Application monitoring: │
│ - Error rate spikes │
│ - Request pattern anomalies │
│ - Data exfiltration indicators │
│ │
│ CC7.3 — INCIDENT RESPONSE │
│ □ Incident response plan documented and tested │
│ □ Incident severity classification: │
│ - SEV1: Data breach, system compromise │
│ - SEV2: Service outage, security control failure │
│ - SEV3: Degraded performance, minor security event │
│ □ Escalation paths defined (who to call, when) │
│ □ Communication plan (internal + external) │
│ □ Post-incident review within 5 business days │
│ □ Lessons learned tracked and controls updated │
│ │
│ CC7.4 — RECOVERY │
│ □ Recovery procedures documented │
│ □ Recovery testing (annual minimum) │
│ □ Recovery time objectives defined │
│ │
│ HOW TO CHECK IN CODE │
│ → Review monitoring config (Datadog, CloudWatch, PagerDuty) │
│ → Review alert rules and escalation policies │
│ → Check for dependency scanning in CI pipeline │
│ → Review incident response runbooks in repo │
│ → Check container base images for latest patches │
│ │
│ COMMON FINDINGS │
│ → Alerts configured but no on-call rotation │
│ → Incidents tracked in Slack, not a ticketing system │
│ → No post-mortem for SEV1/SEV2 incidents │
│ → Container base images months out of date │
│ → No recovery testing performed │
└──────────────────────────────────────────────────────────────┘
CC8: Change Management
┌──────────────────────────────────────────────────────────────┐
│ CC8: CHANGE MANAGEMENT │
│ "Does the organization authorize, design, develop, test, │
│ approve, and implement changes in a controlled manner?" │
│ │
│ THIS IS THE #1 SOURCE OF SOC 2 FINDINGS │
│ │
│ CC8.1 — CHANGE AUTHORIZATION AND APPROVAL │
│ □ All changes go through a formal process: │
│ 1. Request (ticket/PR created) │
│ 2. Review (peer review + security review if needed) │
│ 3. Approve (separate person from author) │
│ 4. Test (CI passes, QA verification) │
│ 5. Deploy (automated, auditable) │
│ 6. Validate (post-deploy checks) │
│ □ Branch protection rules: │
│ - main/production branches protected │
│ - Required reviewers (minimum 1, ideally 2) │
│ - No force pushes │
│ - No direct commits to protected branches │
│ - Status checks must pass before merge │
│ □ Infrastructure changes follow same process │
│ (Terraform PRs, not manual console changes) │
│ │
│ CC8.2 — EMERGENCY CHANGES │
│ □ Emergency change process documented │
│ □ Emergency changes still require: │
│ - Post-hoc approval within 24 hours │
│ - Documentation of what changed and why │
│ - Review that the change was appropriate │
│ □ Emergency changes tracked separately for audit │
│ │
│ CC8.3 — CHANGE TESTING │
│ □ Separate environments: dev → staging → production │
│ □ Changes tested in non-production before promotion │
│ □ CI pipeline includes: │
│ - Unit tests │
│ - Integration tests │
│ - Security scanning (SAST) │
│ - Build verification │
│ □ Rollback procedure documented and tested │
│ │
│ CHANGE MANAGEMENT FLOW (must match reality) │
│ │
│ Developer ──▶ Create PR ──▶ Peer Review ──▶ CI Passes │
│ │ │ │
│ Approved? All green? │
│ │ │ │ │ │
│ Yes No Yes No │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ Merge Block Deploy Block │
│ │ │ │
│ ▼ ▼ │
│ Staging ──▶ Validate ──▶ Prod │
│ │
│ HOW TO CHECK IN CODE │
│ → Review branch protection settings (GitHub API or UI) │
│ → Review CI/CD pipeline config (.github/workflows/) │
│ → Check for direct pushes to main in git log │
│ → Review deployment process (manual vs automated) │
│ → Search for "force push" or branch protection overrides │
│ → Check Terraform state for manual changes (drift) │
│ │
│ COMMON FINDINGS │
│ → Developer merged their own PR without review │
│ → Branch protection disabled temporarily and not re-enabled │
│ → Changes deployed without CI passing │
│ → Infrastructure changed via console, not code │
│ → No rollback procedure documented │
│ → Emergency changes not tracked or post-approved │
└──────────────────────────────────────────────────────────────┘
Phase 4: Availability Controls — A1
┌──────────────────────────────────────────────────────────────┐
│ A1: AVAILABILITY │
│ "Does the system meet its availability commitments?" │
│ │
│ Only required if Availability is in scope. │
│ │
│ A1.1 — CAPACITY MANAGEMENT │
│ □ Capacity planning documented │
│ □ Auto-scaling configured and tested │
│ □ Resource utilization monitored with thresholds │
│ □ Load testing performed (at least annually) │
│ │
│ A1.2 — DISASTER RECOVERY │
│ □ DR plan documented with: │
│ - Recovery Time Objective (RTO) │
│ - Recovery Point Objective (RPO) │
│ - Recovery procedures step-by-step │
│ - Communication plan during outage │
│ □ DR testing performed (at least annually) │
│ □ Test results documented with lessons learned │
│ □ Multi-AZ or multi-region deployment │
│ │
│ A1.3 — BACKUP AND RECOVERY │
│ □ Database backups: │
│ - Automated daily (minimum) │
│ - Retention period defined (30+ days) │
│ - Stored in separate region/account │
│ - Encrypted at rest │
│ □ Backup restoration tested (at least quarterly) │
│ □ Point-in-time recovery available │
│ □ Application state recovery procedures │
│ │
│ UPTIME AND SLA TRACKING │
│ □ Uptime monitoring (external, not just internal) │
│ □ SLA commitments documented in customer agreements │
│ □ SLA tracking dashboard / status page │
│ □ Incident impact on SLA calculated and reported │
│ │
│ HOW TO CHECK IN CODE / INFRA │
│ → Review Terraform: multi-AZ RDS, ECS service replicas │
│ → Review backup config: RDS automated backups enabled │
│ → Review monitoring: health checks, uptime probes │
│ → Review auto-scaling policies and limits │
│ → Check for single points of failure in architecture │
│ │
│ COMMON FINDINGS │
│ → Backups never tested for restorability │
│ → DR plan exists but has never been exercised │
│ → Single-AZ database deployment │
│ → No external uptime monitoring │
│ → SLA commitments with no tracking mechanism │
└──────────────────────────────────────────────────────────────┘
Phase 5: Confidentiality Controls — C1
┌──────────────────────────────────────────────────────────────┐
│ C1: CONFIDENTIALITY │
│ "Does the organization protect confidential information?" │
│ │
│ Only required if Confidentiality is in scope. │
│ │
│ C1.1 — DATA CLASSIFICATION │
│ □ Data classification scheme defined: │
│ - Public: marketing site, docs │
│ - Internal: employee data, internal tools │
│ - Confidential: customer data, PII, credentials │
│ - Restricted: encryption keys, auth secrets │
│ □ Data inventory maintained (what data, where stored, │
│ who accesses, retention period) │
│ □ Classification labels applied to data stores │
│ │
│ C1.2 — ENCRYPTION │
│ □ Encryption at rest: │
│ - Database encrypted (RDS encryption, KMS) │
│ - File storage encrypted (S3 SSE, EBS encryption) │
│ - Backups encrypted │
│ □ Encryption in transit: │
│ - TLS 1.2+ on all endpoints │
│ - Internal service communication encrypted │
│ - Database connections use SSL │
│ □ Key management: │
│ - KMS or HSM for key storage │
│ - Key rotation schedule (annual minimum) │
│ - Key access restricted to minimum necessary │
│ │
│ ACCESS RESTRICTIONS │
│ □ Confidential data access logged │
│ □ Need-to-know basis enforced │
│ □ Data masking in non-production environments │
│ □ No production data in dev/staging │
│ │
│ DATA DISPOSAL │
│ □ Data retention schedule defined │
│ □ Deletion procedures documented │
│ □ Secure deletion verified (not just soft delete) │
│ □ Customer data deletion on request (within SLA) │
│ │
│ HOW TO CHECK IN CODE / INFRA │
│ → Review Terraform: encryption settings on RDS, S3, EBS │
│ → Review TLS config: minimum version, cipher suites │
│ → Check for production data in test fixtures or seeds │
│ → Review data access patterns in API endpoints │
│ → Check .env files for secrets management approach │
│ │
│ COMMON FINDINGS │
│ → S3 bucket not encrypted or publicly accessible │
│ → Production database cloned to dev without masking │
│ → No data retention or disposal schedule defined │
│ → TLS 1.0/1.1 still supported │
│ → Encryption keys stored alongside encrypted data │
└──────────────────────────────────────────────────────────────┘
Phase 6: Processing Integrity Controls — PI1
┌──────────────────────────────────────────────────────────────┐
│ PI1: PROCESSING INTEGRITY │
│ "Does the system process data accurately, completely, │
│ and in a timely manner?" │
│ │
│ Only required if Processing Integrity is in scope. │
│ │
│ PI1.1 — INPUT VALIDATION │
│ □ All API inputs validated with schema (Zod, Joi) │
│ □ Type checking enforced (TypeScript strict mode) │
│ □ Boundary validation (min/max, length limits) │
│ □ Referential integrity enforced (foreign keys) │
│ □ Duplicate submission prevention (idempotency keys) │
│ │
│ PI1.2 — PROCESSING ACCURACY │
│ □ Business logic tested with unit tests │
│ □ Financial calculations verified (if applicable) │
│ □ Data transformation logic auditable │
│ □ Race conditions handled (database transactions, locks) │
│ □ Async processing tracked (job queues with status) │
│ │
│ PI1.3 — OUTPUT COMPLETENESS │
│ □ Reports/exports produce accurate results │
│ □ Pagination handles all records │
│ □ Aggregations verified against source data │
│ □ API responses match documented schemas │
│ │
│ PI1.4 — ERROR HANDLING │
│ □ Errors caught and logged (not swallowed silently) │
│ □ Failed operations do not leave partial state │
│ □ Database transactions used for multi-step operations │
│ □ Queue processing has retry and dead-letter handling │
│ │
│ PI1.5 — ERROR CORRECTION │
│ □ Process to identify and correct data errors │
│ □ Audit trail for data corrections │
│ □ Root cause analysis for systematic errors │
│ │
│ HOW TO CHECK IN CODE │
│ → Review Zod schemas: do they cover all endpoints? │
│ → Review database transactions: are multi-step ops atomic? │
│ → Review error handling: catch blocks log and re-throw? │
│ → Review async jobs: retry logic, dead-letter queue? │
│ → Check test coverage on business logic │
│ │
│ COMMON FINDINGS │
│ → API endpoints accept unvalidated input │
│ → Database operations without transactions │
│ → Errors caught and swallowed (empty catch blocks) │
│ → No idempotency on payment or critical operations │
│ → Async jobs fail silently with no retry │
└──────────────────────────────────────────────────────────────┘
Phase 7: Privacy Controls — P1 through P8
┌──────────────────────────────────────────────────────────────┐
│ PRIVACY CONTROLS (P1-P8) │
│ "Does the organization protect personal information?" │
│ │
│ Only required if Privacy is in scope. │
│ │
│ P1 — NOTICE │
│ □ Privacy policy published and accessible │
│ □ Data collection purposes clearly stated │
│ □ Third-party data sharing disclosed │
│ □ Privacy policy updated when practices change │
│ │
│ P2 — CHOICE AND CONSENT │
│ □ Opt-in for non-essential data collection │
│ □ Cookie consent mechanism (not just a banner) │
│ □ Marketing consent separate from service consent │
│ □ Consent records stored with timestamp │
│ │
│ P3 — COLLECTION │
│ □ Only necessary data collected (data minimization) │
│ □ Collection methods documented │
│ □ Third-party data sources disclosed │
│ │
│ P4 — USE, RETENTION, DISPOSAL │
│ □ Data used only for stated purposes │
│ □ Retention schedule defined and enforced │
│ □ Automated data purging for expired records │
│ □ Disposal methods appropriate for data sensitivity │
│ │
│ P5 — ACCESS │
│ □ Users can access their own data │
│ □ Data export/portability supported │
│ □ Users can request data correction │
│ □ Users can request data deletion (right to erasure) │
│ │
│ P6 — DISCLOSURE TO THIRD PARTIES │
│ □ Third-party data processors documented │
│ □ Data processing agreements in place │
│ □ Sub-processor notification process │
│ □ Third-party security assessed │
│ │
│ P7 — SECURITY FOR PRIVACY │
│ □ Technical controls protect personal data │
│ □ Access to personal data restricted and logged │
│ □ Encryption applied to personal data │
│ □ Breach notification process defined (72 hours for GDPR) │
│ │
│ P8 — QUALITY │
│ □ Data accuracy maintained │
│ □ Users can update their information │
│ □ Processes to correct inaccurate data │
│ │
│ HOW TO CHECK IN CODE │
│ → Review privacy policy page and cookie consent │
│ → Check for data export API endpoint │
│ → Check for user deletion / anonymization endpoint │
│ → Review third-party integrations and data shared │
│ → Check analytics (do they track PII unnecessarily?) │
│ → Review data retention in database (soft vs hard delete) │
│ │
│ COMMON FINDINGS │
│ → No data export or deletion capability │
│ → Cookie consent is cosmetic (tracks before consent) │
│ → Retention schedule defined but not enforced in code │
│ → Third-party sub-processors not disclosed │
│ → Analytics collecting PII without consent │
└──────────────────────────────────────────────────────────────┘
Phase 8: Access Control Review
┌──────────────────────────────────────────────────────────────┐
│ ACCESS CONTROL REVIEW │
│ Maps to: CC6.1, CC6.2, CC6.3, CC6.6, CC6.7, CC6.8 │
│ │
│ USER LIFECYCLE AUDIT │
│ │
│ Provisioning ─▶ Active Use ─▶ Review ─▶ Deprovisioning │
│ │ │ │ │ │
│ □ Ticket/ □ MFA □ Quarterly □ Within │
│ approval enforced access 24 hours │
│ □ Role □ Least review □ All systems │
│ assigned privilege □ Documented □ Credentials │
│ □ Minimum □ Session changes revoked │
│ access timeout □ Verified │
│ │
│ ACCESS REVIEW CHECKLIST │
│ │
│ For each system (GitHub, AWS, database, monitoring): │
│ □ List all users with access │
│ □ Verify each user still needs access │
│ □ Verify access level is appropriate for role │
│ □ Remove access for departed employees │
│ □ Remove excessive access (admin when viewer suffices) │
│ □ Document reviewer, date, and changes made │
│ │
│ SERVICE ACCOUNT AUDIT │
│ □ All service accounts inventoried │
│ □ Each has a documented owner │
│ □ Each has minimum necessary permissions │
│ □ Credentials rotated on schedule │
│ □ No service accounts with admin/root access │
│ │
│ MFA AUDIT │
│ □ Cloud provider: MFA required for all IAM users │
│ □ Source control: 2FA required for all org members │
│ □ Identity provider: MFA required for all users │
│ □ Production access: MFA required (VPN, bastion, console) │
│ □ Root/break-glass accounts: MFA with hardware token │
└──────────────────────────────────────────────────────────────┘
Phase 9: Incident Management Audit
┌──────────────────────────────────────────────────────────────┐
│ INCIDENT MANAGEMENT AUDIT │
│ Maps to: CC7.3, CC7.4, CC2.2, CC4.1 │
│ │
│ INCIDENT LIFECYCLE │
│ │
│ Detect ──▶ Triage ──▶ Escalate ──▶ Contain ──▶ Resolve │
│ │ │ │ │ │ │
│ ▼ ▼ ▼ ▼ ▼ │
│ Alerts Severity Notify Stop the Fix root │
│ Logs assigned on-call bleeding cause │
│ Reports Timeline Comms │
│ │ │
│ ▼ │
│ ┌──────────┐ │
│ │ Post- │ │
│ │ Mortem │ │
│ └──────────┘ │
│ Root cause │
│ Preventive │
│ measures │
│ Timeline │
│ │
│ WHAT THE AUDITOR WILL SAMPLE │
│ □ Select 3-5 incidents from the audit period │
│ □ For each incident, trace through the full lifecycle: │
│ - How was it detected? (alert, customer report, manual) │
│ - When was it detected vs when did it start? │
│ - Who was notified and when? │
│ - What containment actions were taken? │
│ - What was the root cause? │
│ - What preventive measures were implemented? │
│ - Were preventive measures effective? │
│ │
│ REQUIRED DOCUMENTATION PER INCIDENT │
│ □ Incident ticket with timeline │
│ □ Severity classification with justification │
│ □ Communication log (who was notified, when) │
│ □ Root cause analysis │
│ □ Post-mortem document with action items │
│ □ Evidence that action items were completed │
│ │
│ COMMON FINDINGS │
│ → Incidents discussed in Slack but not ticketed │
│ → Post-mortem written but action items never tracked │
│ → No severity classification applied │
│ → Communication was ad hoc (no defined escalation path) │
│ → Same root cause caused multiple incidents (no fix) │
└──────────────────────────────────────────────────────────────┘
Phase 10: Continuous Monitoring Setup
┌──────────────────────────────────────────────────────────────┐
│ CONTINUOUS MONITORING │
│ Maps to: CC4.1, CC4.2, CC7.1, CC7.2 │
│ │
│ AUTOMATED EVIDENCE COLLECTION │
│ │
│ Source │ What to Collect │ Retention │
│ ───────────────────┼────────────────────────┼───────────────│
│ GitHub │ PR reviews, merges, │ Audit period │
│ │ branch protection │ + 90 days │
│ AWS CloudTrail │ API calls, console │ 1 year minimum │
│ │ logins, config changes │ │
│ CI/CD (Actions) │ Build logs, deploy │ 90 days │
│ │ history, test results │ │
│ Identity Provider │ Login events, MFA │ 1 year │
│ │ status, access changes │ │
│ Monitoring │ Alert history, ack │ 1 year │
│ (PagerDuty/etc) │ times, resolution │ │
│ Ticketing │ Incident tickets, │ Indefinite │
│ (Jira/Linear) │ change requests │ │
│ Application Logs │ Auth events, errors, │ 90 days │
│ │ admin actions │ │
│ │
│ CONTROL TESTING SCHEDULE │
│ │
│ Frequency │ Controls to Test │
│ ─────────────┼──────────────────────────────────────────────│
│ Daily │ Automated: CI/CD gates, branch protection, │
│ │ secrets scanning, vulnerability alerts │
│ Weekly │ Review: alert response times, open vulns │
│ Monthly │ Review: access changes, new vendors, │
│ │ incident trends │
│ Quarterly │ Access reviews, backup restoration test, │
│ │ control effectiveness assessment │
│ Annually │ Risk assessment, DR test, penetration test, │
│ │ policy review, vendor reassessment │
│ │
│ DRIFT DETECTION │
│ □ Terraform plan runs on schedule (detect manual changes) │
│ □ Branch protection settings monitored for changes │
│ □ IAM policy changes trigger alerts │
│ □ Security group changes trigger alerts │
│ □ Encryption settings monitored (disabled = alert) │
│ □ Compliance tool (Vanta/Drata) checks daily │
└──────────────────────────────────────────────────────────────┘
Phase 11: Type I vs Type II Readiness Checklist
Type I Readiness (Design Effectiveness)
□ POLICIES AND PROCEDURES
□ Information security policy — written, dated, approved
□ Access control policy — provisioning, deprovisioning, reviews
□ Change management policy — approval, testing, deployment
□ Incident response plan — detection through resolution
□ Risk assessment document — current, with risk register
□ Business continuity / DR plan (if Availability in scope)
□ Data classification policy (if Confidentiality in scope)
□ Privacy policy (if Privacy in scope)
□ TECHNICAL CONTROLS
□ MFA enforced on all critical systems
□ Branch protection on production branches
□ CI/CD pipeline with required checks
□ Encryption at rest and in transit
□ Network segmentation (prod isolated from dev)
□ Monitoring and alerting configured
□ Logging with adequate retention
□ Vulnerability scanning enabled
□ OPERATIONAL CONTROLS
□ On-call rotation defined
□ Incident response tested (tabletop exercise minimum)
□ Access review process defined
□ Vendor management process defined
□ Security awareness training program defined
Type II Readiness (Operating Effectiveness)
All of Type I, PLUS evidence of consistent operation:
□ EVIDENCE OVER THE AUDIT PERIOD
□ PR review logs — every merge had approval
□ Access review records — quarterly, with documented changes
□ Incident tickets — full lifecycle for every incident
□ Vulnerability remediation — patched within SLA
□ Training completion — all employees, annually
□ Backup restoration — tested at least once
□ DR test — conducted at least once
□ Risk assessment — updated at least once
□ Policy review — annual review with sign-off
□ MFA — continuously enforced (no gaps)
□ Log retention — logs available for the full period
□ Monitoring — alerts were responded to
□ SAMPLING READINESS
□ Can you pull a random PR from 6 months ago and show
the approval chain?
□ Can you pull a random incident from the period and
show the full lifecycle?
□ Can you show a terminated employee was deprovisioned
within 24 hours?
□ Can you show a vulnerability was patched within SLA?
□ Can you show who had access to production on any
given date?
Top 20 Common SOC 2 Findings
| # | Finding | Criteria | Severity | How to Prevent | |
|---|
| 1 | Developer merged own PR without independent review | CC8.1 | High | Branch protection: require 1+ reviewer, no self-approval | |
| 2 | MFA not enforced on all critical systems | CC6.1 | High | Enforce MFA via IdP policy, audit monthly | |
| 3 | Terminated employee retained access for 30+ days | CC6.3 | High | Automated deprovisioning via IdP, 24-hour SLA | |
| 4 | No quarterly access reviews performed | CC6.3 | Medium | Calendar reminders, compliance tool automation | |
| 5 | Infrastructure changed via console, not IaC | CC8.1 | High | AWS SCPs preventing console changes, Terraform only | |
| 6 | Branch protection disabled and not re-enabled | CC8.1 | Critical | Monitor protection settings, alert on changes | |
| 7 | Incident handled in Slack without formal ticket | CC7.3 | Medium | Require ticket for every incident, even minor | |
| 8 | Post-mortem action items not tracked to completion | CC7.3 | Medium | Action items as tickets with owners and deadlines | |
| 9 | No formal risk assessment document | CC3.1 | High | Annual risk assessment with dated sign-off | |
| 10 | Backup restoration never tested | A1.3 | High | Quarterly restoration test with documented results | |
| 11 | Security training not completed by all employees | CC1.4 | Medium | Mandatory training with tracked completion | |
| 12 | Vulnerability patching exceeded SLA | CC7.1 | Medium | Automated patching, dependency scanning in CI | |
| 13 | Logs retained for less than audit period | CC4.1 | High | Set retention to audit period + 90 days minimum | |
| 14 | No evidence of annual policy review | CC1.1 | Medium | Version-controlled policies with annual PR review | |
| 15 | Security groups allow unrestricted inbound access | CC6.6 | Critical | Automated scanning, no 0.0.0.0/0 on any port | |
| 16 | Production data used in non-production environments | C1.1 | High | Data masking, synthetic test data, separate accounts | |
| 17 | No disaster recovery test performed | A1.2 | High | Annual DR drill with documented results | |
| 18 | Encryption not enabled on all data stores | C1.2 | High | Default encryption in Terraform modules | |
| 19 | No system description document maintained | CC2.1 | Medium | Architecture docs in version control, updated with changes | |
| 20 | Vendor security not assessed before engagement | CC9.2 | Medium | Vendor security questionnaire, annual reassessment | |
SOC 2 Compliance Checklist
CC1 — Control Environment
| # | Control | Criteria | Evidence Source | Status | |
|---|
| 1 | Security policies documented and approved | CC1.1 | Policy docs in VCS with PR approvals | [ ] | |
| 2 | Organizational structure with security roles defined | CC1.1 | Org chart, role descriptions | [ ] | |
| 3 | Board/management oversight of security program | CC1.2 | Meeting minutes, security reviews | [ ] | |
| 4 | Code of conduct / ethics policy | CC1.1 | Employee handbook, signed acknowledgments | [ ] | |
| 5 | Background checks for employees with system access | CC1.4 | HR records, check completion | [ ] | |
| 6 | Security awareness training — annual, tracked | CC1.4 | Training platform records | [ ] | |
| 7 | Annual policy review with dated sign-off | CC1.1 | PRs or change records on policy docs | [ ] | |
CC2 — Communication and Information
| # | Control | Criteria | Evidence Source | Status | |
|---|
| 8 | System description document current and accurate | CC2.1 | Architecture docs in repo | [ ] | |
| 9 | Internal security communications established | CC2.2 | Slack channels, email records | [ ] | |
| 10 | External-facing privacy policy and ToS published | CC2.3 | Website, dated versions | [ ] | |
| 11 | Security contact published (security.txt) | CC2.3 | /.well-known/security.txt | [ ] | |
| 12 | Incident notification process documented | CC2.3 | Incident response plan | [ ] | |
CC3 — Risk Assessment
| # | Control | Criteria | Evidence Source | Status | |
|---|
| 13 | Formal risk assessment conducted annually | CC3.1 | Risk assessment document, dated | [ ] | |
| 14 | Risk register maintained with ratings | CC3.2 | Risk register spreadsheet/tool | [ ] | |
| 15 | Fraud risk considerations documented | CC3.3 | Risk assessment section | [ ] | |
| 16 | Changes trigger risk reassessment | CC3.4 | Change records with risk notes | [ ] | |
CC4 — Monitoring
| # | Control | Criteria | Evidence Source | Status | |
|---|
| 17 | Security event monitoring and alerting active | CC4.1 | Monitoring tool config, alert history | [ ] | |
| 18 | Log aggregation with adequate retention | CC4.1 | CloudWatch/Datadog config | [ ] | |
| 19 | Control deficiencies tracked to resolution | CC4.2 | Ticketing system, compliance tool | [ ] | |
| 20 | Internal self-assessment performed periodically | CC4.1 | Assessment records | [ ] | |
CC5 — Control Activities
| # | Control | Criteria | Evidence Source | Status | |
|---|
| 21 | Infrastructure as Code with drift detection | CC5.1 | Terraform configs, plan output | [ ] | |
| 22 | Automated security scanning in CI pipeline | CC5.1 | CI config, scan results | [ ] | |
| 23 | Secrets scanning enabled on repositories | CC5.1 | GitHub secret scanning config | [ ] | |
| 24 | WAF or DDoS protection on public endpoints | CC5.1 | AWS WAF rules, CloudFront config | [ ] | |
| 25 | Network segmentation enforced (VPC, SGs) | CC5.1 | Terraform VPC config | [ ] | |
CC6 — Logical Access
| # | Control | Criteria | Evidence Source | Status | |
|---|
| 26 | MFA enforced on cloud console | CC6.1 | AWS IAM policy, CloudTrail logs | [ ] | |
| 27 | MFA enforced on source control | CC6.1 | GitHub org settings | [ ] | |
| 28 | MFA enforced on identity provider | CC6.1 | IdP admin config | [ ] | |
| 29 | SSO enforced where available | CC6.1 | SSO config records | [ ] | |
| 30 | Access provisioning requires approval | CC6.2 | Ticketing records | [ ] | |
| 31 | Least privilege access enforced | CC6.3 | IAM policies, role assignments | [ ] | |
| 32 | Quarterly access reviews with documentation | CC6.1 | Review records, change logs | [ ] | |
| 33 | User deprovisioning within 24 hours | CC6.5 | HR + IdP deprovisioning records | [ ] | |
| 34 | Service accounts inventoried with owners | CC6.1 | Service account register | [ ] | |
| 35 | API keys rotated on schedule | CC6.1 | Rotation records | [ ] | |
| 36 | No shared accounts or credentials | CC6.1 | Account audit records | [ ] | |
| 37 | Dormant accounts disabled (90 days) | CC6.5 | IdP inactive user reports | [ ] | |
| 38 | Production database access restricted | CC6.6 | Security group rules, IAM | [ ] | |
| 39 | VPN or bastion for production access | CC6.6 | Network config, access logs | [ ] | |
CC7 — System Operations
| # | Control | Criteria | Evidence Source | Status | |
|---|
| 40 | Vulnerability scanning on schedule | CC7.1 | Scan reports, remediation records | [ ] | |
| 41 | Patching within defined SLAs | CC7.1 | Patch records, timeline evidence | [ ] | |
| 42 | Container base images updated regularly | CC7.1 | Dockerfile history, image scan | [ ] | |
| 43 | Security event alerting configured | CC7.2 | Alert rules, PagerDuty config | [ ] | |
| 44 | On-call rotation defined and staffed | CC7.2 | On-call schedule records | [ ] | |
| 45 | Incident response plan documented | CC7.3 | IRP document in VCS | [ ] | |
| 46 | Incident severity classification defined | CC7.3 | IRP severity matrix | [ ] | |
| 47 | Post-incident reviews conducted | CC7.4 | Post-mortem documents | [ ] | |
| 48 | Incident action items tracked to completion | CC7.4 | Ticketing system records | [ ] | |
CC8 — Change Management
| # | Control | Criteria | Evidence Source | Status | |
|---|
| 49 | Branch protection on main/production branches | CC8.1 | GitHub branch protection config | [ ] | |
| 50 | PR reviews required before merge (1+ reviewer) | CC8.1 | Branch protection + PR history | [ ] | |
| 51 | No self-approval of PRs | CC8.1 | Branch protection, PR audit | [ ] | |
| 52 | CI pipeline must pass before merge | CC8.1 | Branch protection, CI config | [ ] | |
| 53 | Separate environments (dev/staging/prod) | CC8.1 | Infrastructure config | [ ] | |
| 54 | Changes tested before production deployment | CC8.1 | CI test results, staging deploys | [ ] | |
| 55 | Deployment process automated and auditable | CC8.1 | CD pipeline config, deploy logs | [ ] | |
| 56 | Rollback procedure documented and tested | CC8.1 | Runbook, rollback records | [ ] | |
| 57 | Emergency change process with post-hoc approval | CC8.1 | Emergency change records | [ ] | |
| 58 | Infrastructure changes via IaC only | CC8.1 | Terraform PRs, drift detection | [ ] | |
CC9 — Risk Mitigation
| # | Control | Criteria | Evidence Source | Status | |
|---|
| 59 | Vendor security assessment before engagement | CC9.2 | Vendor questionnaires, SOC reports | [ ] | |
| 60 | Vendor reassessment annually | CC9.2 | Annual review records | [ ] | |
| 61 | Business continuity plan documented | CC9.1 | BCP document | [ ] | |
A1 — Availability (if in scope)
| # | Control | Criteria | Evidence Source | Status | |
|---|
| 62 | Uptime monitoring (external) | A1.1 | Monitoring config, uptime records | [ ] | |
| 63 | Auto-scaling configured | A1.1 | ECS/ASG config | [ ] | |
| 64 | Multi-AZ deployment for critical services | A1.2 | Terraform config | [ ] | |
| 65 | DR plan documented with RTO/RPO | A1.2 | DR plan document | [ ] | |
| 66 | DR test conducted annually | A1.2 | DR test report | [ ] | |
| 67 | Database backups automated and encrypted | A1.3 | RDS backup config | [ ] | |
| 68 | Backup restoration tested quarterly | A1.3 | Restoration test records | [ ] | |
| 69 | SLA commitments documented and tracked | A1.1 | Customer agreements, SLA dashboard | [ ] | |
C1 — Confidentiality (if in scope)
| # | Control | Criteria | Evidence Source | Status | |
|---|
| 70 | Data classification scheme defined | C1.1 | Classification policy | [ ] | |
| 71 | Encryption at rest on all data stores | C1.1 | RDS/S3/EBS encryption config | [ ] | |
| 72 | TLS 1.2+ on all endpoints | C1.1 | TLS config, scan results | [ ] | |
| 73 | Database connections use SSL | C1.1 | Connection string config | [ ] | |
| 74 | No production data in non-production | C1.1 | Environment separation evidence | [ ] | |
| 75 | Data retention schedule enforced | C1.2 | Retention policy, purge records | [ ] | |
| 76 | Key rotation schedule defined and followed | C1.1 | KMS config, rotation records | [ ] | |
Tips for Best Results
- Start with change management — CC8 is the #1 finding area. Verify branch protection, PR reviews, and deployment controls first. If these are broken, everything else is at risk.
- Check evidence, not policies — A policy that says "we require code reviews" means nothing if PRs are merged without approval. Pull actual PR history and verify.
- Think in audit periods — For Type II, every control must operate every day for 6-12 months. One day of branch protection being disabled is a finding. Check for gaps.
- Sample like an auditor — Pick random dates across the audit period. Pull PR reviews from month 2, incident records from month 7, access reviews from month 10. Consistency matters.
- Map every finding to a criteria code — Auditors speak in CC/A/PI/C/P references. Every finding should include the specific criteria it violates (e.g., CC8.1, CC6.3).
- Automate evidence collection — Manual evidence collection breaks down. Use compliance tools (Vanta, Drata) or build automated evidence pipelines that collect continuously.
- Fix the easy wins first — MFA enforcement, branch protection, and log retention are high-impact controls that can be enabled in hours. Do them before the auditor arrives.
- Document emergency changes — "Hotfix" is not an excuse. Every emergency change needs post-hoc documentation: what changed, why, who approved it retroactively, and within 24 hours.
- Keep your system description current — Auditors compare your system description against reality. Outdated architecture diagrams create findings. Update docs when infrastructure changes.
- Train your team — Engineers who understand SOC 2 produce fewer findings. Explain why controls exist, not just what the controls are.