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, WeSecureX 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 vulnerability posture directly in the WeSecureX Vulnerabilities Catalog.
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.
Continuous Security Audits & Audit-Ready Evidence with WeSecureX for SOC 2
During a SOC 2 Type II audit, CPAs do not merely review written security policies - they inspect continuous operational evidence across your 6-to-12-month observation window. Proving adherence to Common Criteria 6.1 (Vulnerability Management), CC6.6 (Boundary Protection), and CC7.1 (System Monitoring) requires continuous automated testing evidence.
How WeSecureX Automates SOC 2 Type II Compliance
- Continuous Scheduled Vulnerability Scans (CC6.1): Set automated weekly or daily recurring scans in the WeSecureX Instant Vulnerability Scanner. Continuous scan histories prove that software vulnerabilities were detected and tracked promptly.
- Centralized Vulnerability Lifecycle & MTTR (CC7.1): Track Mean Time to Remediate (MTTR), assign remediation owners, and document false positives directly within the WeSecureX Vulnerability Manager.
- Executive Auditor Reports with One-Click PDF Export: Generate branded, comprehensive executive audit summaries documenting CVSS scores, remediation proofs, and scan timestamps for direct submission to your SOC 2 auditor.
- Surface Perimeter Asset Discovery (CC6.6): Maintain an up-to-date inventory of external cloud assets, subdomains, and API gateways via WeSecureX External Attack Surface Recon.
Explore enterprise scanning quotas on our WeSecureX Pricing & Plans page, or reach out to our security engineers through WeSecureX Engineering Support.
- Export executive PDF reports monthly to maintain an unbroken audit trail in your SOC 2 evidence repository.
- Integrate automated vulnerability scanning directly into pull requests via the WeSecureX REST API to enforce automated build gating.
- Review our related frameworks in the [GDPR Compliance Blueprint](/guides/compliance-security/gdpr-for-developers) and [PCI DSS v4.0 Engineering Guide](/guides/compliance-security/pci-dss-basics).
Apply it with WeSecureX
Add a hostname you own or are allowed to test, run a scan, and open the findings for that target. A confirmed result includes the request WeSecureX sent and the response the site returned, so you can reproduce it, fix it in your own application, and rescan the same host to confirm the issue is gone. WeSecureX is automated testing, not a manual penetration test, and a clean report is not a promise that every weakness is gone.
WeSecureX modules for this topic
Checks that belong with this topic
- Enforce mandatory multi-factor authentication (MFA) across all developer tooling (GitHub, AWS, Slack).
- Enable GitHub branch protection requiring peer review and automated CI checks before merging.
- Deploy immutable AWS CloudTrail and application audit logging to a dedicated logging account.
- Conduct quarterly access reviews to revoke permissions for departed or transitioned employees.
- Conduct annual third-party penetration testing and automated weekly vulnerability scanning.
- Perform annual disaster recovery backup restoration drills and record evidence.
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
WeSecureX 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).
Type 1 evaluates whether your security controls are designed correctly at a single point in time. Type 2 evaluates the operational effectiveness of those controls over a 6-to-12-month period.
Security (mandatory baseline), Availability, Processing Integrity, Confidentiality, and Privacy.
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.