SOC 2 Type I vs. Type II Compared
The AICPA defines two distinct tiers of SOC 2 attestation:
- SOC 2 Type I: Evaluates the design of security controls at a single point in time (e.g., 'As of December 1st, does the organization have branch protection rules and MFA configured?'). It can be completed in 1-2 months and is useful for early-stage startups needing initial enterprise proof.
- SOC 2 Type II: Evaluates the operational effectiveness of controls over a continuous observation window (typically 6 or 12 months). The auditor collects continuous evidence proving that every pull request had required approvals, no employee retained access post-termination, and vulnerability scans were executed on schedule.
The Five Trust Services Criteria (TSC) & Technical Controls
The AICPA organizes SOC 2 controls into five Trust Services Criteria categories:
AICPA SOC 2 Trust Services Criteria & Engineering Evidence Table
| Trust Service Category | Engineering Scope | Required Technical Controls | Continuous Audit Evidence Sources |
|---|---|---|---|
| Security (Common Criteria) | Perimeter & App Defense (Mandatory) | Mandatory MFA, RBAC, branch protection, scheduled vulnerability scanning | GitHub PR audit logs, AWS IAM credential reports, Wescequre scan history |
| Availability | Infrastructure Uptime & Failover | Automated multi-AZ backups, RPO/RTO SLAs, disaster recovery drills | CloudWatch uptime metrics, automated restore drill logs, Terraform state |
| Confidentiality | Sensitive Data Protection | KMS encryption at rest and in transit, least-privilege data access | KMS key rotation logs, DLP alerts, database access audit streams |
| Processing Integrity | Accurate & Authorized Processing | Schema validation, automated CI/CD unit and integration testing | GitHub Actions test run logs, Zod schema validation suites |
| Privacy | Personal Data Handling | Notice, consent tracking, data retention policies, Article 17 erasure | Cookie consent state logs, automated user erasure audit trails |
Every SOC 2 audit mandates the Security (Common Criteria) category. SaaS organizations selectively add Availability, Confidentiality, Processing Integrity, or Privacy based on customer contractual obligations.
Key Technical Controls: Branch Protection & Change Management
To satisfy SOC 2 auditors, software engineering teams must eliminate untracked manual changes to production environments. All changes must originate from version-controlled, peer-reviewed pull requests enforced via repository branch protection rules:
# GitHub Branch Protection Settings for SOC 2 Compliance
# Enforced via Terraform / GitHub API
resource "github_branch_protection" "main_branch" {
repository_id = "vulnwatch-core"
pattern = "main"
enforce_admins = true # Admins cannot bypass rules
required_pull_request_reviews {
dismiss_stale_reviews = true
require_code_owner_reviews = true
required_approving_review_count = 1
}
required_status_checks {
strict = true
contexts = [
"ci/automated-tests",
"security/snyk-dependency-scan",
"security/vulnwatch-pr-check"
]
}
}Immutable Audit Logging & Centralized SIEM Ingestion
Auditors require evidence that systems cannot be altered without generating immutable audit trails:
- CloudTrail Multi-Region Trails: Enable AWS CloudTrail across all regions and stream logs to a dedicated, write-once (S3 Object Lock) logging account where production administrators possess read-only permissions.
- Application Audit Logs: Log all security-relevant user actions (login, password reset, role modification, API key generation, customer data export) with structured JSON containing timestamp, actor ID, IP address, and resource ID.
- Minimum Retention Window: Retain centralized audit logs for a minimum of 1 year (with at least 90 days immediately searchable in OpenSearch/Datadog). Review historical scan logs directly in the Wescequre Scan History Center.
Disaster Recovery Testing & RTO/RPO SLA Guarantees
To satisfy the Availability criteria, engineering teams must document and validate disaster recovery capabilities:
- Recovery Point Objective (RPO): Maximum acceptable data loss period (e.g., automated point-in-time RDS database snapshots every 5 minutes).
- Recovery Time Objective (RTO): Maximum acceptable downtime to restore systems (e.g., sub-2 hours via automated Terraform infrastructure reproduction).
- Annual Failover Drills: Execute and document an annual tabletop simulation or live disaster recovery failover drill to verify backup restoration capabilities.
Common Mistakes to Avoid
❌Allowing engineers direct SSH access or manual deployment rights to production servers
Why it happens: Convenience for hotfixing production bugs.
Why it matters: Direct production access creates untracked changes, triggering immediate audit failure.
Correct approach: Enforce zero manual production access; all changes must pass through automated CI/CD pipelines.
❌Failing to document offboarding access revocation within the defined SLA (typically 24 hours)
Why it happens: HR notifies IT late, or offboarding is handled manually across dozens of SaaS tools.
Why it matters: Auditors sample all terminated employees; a single active account 48 hours after termination triggers an audit exception.
Correct approach: Use Single Sign-On (Okta/Google Workspace) so disabling one master account instantly revokes access to GitHub, AWS, and Slack.
Troubleshooting Guide
Problem: SOC 2 auditor flags missing peer review evidence on a production release
Possible Causes:
- An administrator used bypass permissions to merge an emergency hotfix without approval.
How to verify: Check GitHub pull request audit logs for emergency merges.
How to fix: Configure GitHub branch protection with `enforce_admins: true` so even administrators must obtain peer approval.
Actionable Checklist
Wescequre Platform · Compliance Diff
Security Regression & Diff Engine
Track scan-over-scan vulnerability status, verify fixes, and export evidence reports for SOC 2, ISO 27001, and PCI DSS.
Includes: Scan-to-scan vulnerability state diffs · Remediation verification audit logs · Exportable compliance summary reports
Frequently Asked Questions
A typical SOC 2 Type II process takes 6 to 9 months: 1 to 2 months of readiness remediation to implement missing controls, followed by a mandatory 6-month observation period where the controls operate continuously to generate auditor evidence.
No. SOC 2 reports are annual attestations. To maintain enterprise trust, SaaS companies must undergo an audit renewal every 12 months to receive a new Type II report covering the preceding year.
SOC 2 Common Criteria CC7.1 and CC7.2 mandate vulnerability management and risk assessment. Automated weekly scans provide timestamped evidence that vulnerabilities are identified and remediated within defined SLAs. See our guide on [What Is Vulnerability Scanning?](/guides/vulnerability-scanning/what-is-vulnerability-scanning).
Authoritative Sources & References
- AICPA: SOC 2 Overview and Trust Services CriteriaAICPA (official)View Source
- AICPA: TSP Section 100 - 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and PrivacyAICPA (official)View Source
- CIS Benchmarks: Security Guidelines for Cloud & Container InfrastructureCenter for Internet Security (technical)View Source
Related Guides
Continue exploring related technical architecture and defensive guides
GDPR · compliance
GDPR Compliance for Developers: Architecture & Engineering Checklist
Developer blueprint for GDPR: personal data schemas, Article 17 right-to-erasure workflows, cryptographic shredding patterns, and audit log compliance.
PCI DSS · PCI DSS v4.0
PCI DSS v4.0 for Web Developers: Scope Reduction & Tokenization
Developer blueprint for PCI DSS v4.0: CDE scope reduction via hosted fields, Requirement 6.4.3 script monitoring, and 11.6.1 tamper detection mechanisms.
vulnerability scanning · DAST
What Is Vulnerability Scanning? Complete Guide
An authoritative guide to automated vulnerability scanning: how scanners crawl and audit applications, how DAST contrasts with SAST and SCA, and how to triage findings effectively.