SOC 2 Type II guide SaaS
SOC 2 Type II Guide for SaaS Companies: What Engineering Teams Actually Need to Do
A practical SOC 2 Type II guide for SaaS engineering teams — what the controls actually require, how to implement them efficiently, and how to automate evidence collection for the observation period.
TL;DR — Key Points
- 1SOC 2 Type II takes 4–8 weeks of engineering work plus a 6-month observation period — not 12–18 months — if the infrastructure is fixed before policies are written.
- 2The most common cause of SOC 2 delays is treating compliance as a policy project rather than an infrastructure project.
- 3MFA enforcement, IAM least-privilege, audit logging, and automated access reviews are the four highest-weight control areas for most SaaS environments.
- 4Automated evidence collection before the observation period starts is the single most impactful preparation for a smooth audit.
SOC 2 Type II Guide for SaaS Companies: What Engineering Teams Actually Need to Do
When a SaaS company first gets asked for a SOC 2 Type II report in a sales cycle, the initial reaction is usually panic about timeline. Enterprise security teams want a Type II report — which requires a minimum 6-month observation period — and the prospect is in Q4. Most SaaS teams assume this means 12–18 months of work.
The reality is different. The observation period is fixed at 6 months minimum. But the engineering work to reach readiness — implementing the actual infrastructure controls — takes 4–8 weeks if done efficiently. Most of the apparent 18-month SOC 2 timeline is caused by starting with policies and documentation before fixing the underlying infrastructure, which means controls fail during the observation period and the clock resets.
Why SOC 2 takes longer than it should for most SaaS companies
The most common reason SOC 2 Type II takes 12–18 months is that teams treat it as a compliance project managed by a GRC tool rather than an engineering project managed by the platform team. GRC tools are excellent at tracking policies, questionnaires, and vendor reviews. They are not good at remediating the infrastructure gaps that cause control failures during the observation period.
The typical failure pattern is: a compliance consultant audits the environment, identifies 30–40 gaps, and the team spends three months writing policies to address them on paper. The auditor then starts the observation period, and within the first month, automated evidence collection reveals that 15 of those 40 gaps are still open in the infrastructure — meaning the control is not actually operating, regardless of what the policy says. The observation period restarts or the audit fails.
Infrastructure controls that are commonly open at the start of SOC 2 readiness work include: MFA not enforced for all users with administrative access, IAM roles with wildcard permissions or inactive users still present, CloudTrail or equivalent audit logging not enabled in all regions, security patching not automated with documented SLA, and access reviews not conducted on a documented schedule.
Another common issue is the evidence gap. SOC 2 Type II requires evidence that controls operated effectively throughout the observation period — not just at a point in time. Manual evidence collection during a 6-month observation period is burdensome and error-prone. Teams that do not automate evidence collection from the start spend weeks before the audit trying to reconstruct records that should have been collected continuously.
SOC 2 Type II Implementation Framework for SaaS Engineering Teams
The following framework reflects the sequence Wolk Inc uses when implementing SOC 2 Type II readiness for SaaS clients. The order matters — fixing infrastructure before writing policies is consistently faster than the reverse.
Gap Assessment Against Trust Services Criteria
Start with an engineering-led gap assessment against the SOC 2 Trust Services Criteria (specifically the Common Criteria CC1–CC9). Map each criterion to the specific infrastructure control it requires, then audit whether that control currently exists and is operating. Do not accept "we have a policy for this" as evidence — verify the technical implementation. Most SaaS environments have 20–40 open gaps at this stage, heavily concentrated in logical access (CC6), system operations (CC7), and change management (CC8).
Logical Access Controls: MFA, IAM, and Access Reviews
The highest-weight SOC 2 controls are in the logical access category. Implement MFA enforcement for all user accounts with access to production systems, cloud infrastructure, and source code repositories — no exceptions. Audit all IAM roles and users, remove inactive accounts, scope permissions to least-privilege, and document the purpose of each elevated permission. Configure automated access review tooling (AWS Access Analyzer, Vanta, or equivalent) to generate quarterly access review reports as audit evidence. Implement offboarding automation that revokes access within 24 hours of employee departure.
Infrastructure Hardening: Encryption, Patching, and Network Controls
Verify encryption at rest (EBS, RDS, S3 bucket policies) and in transit (TLS 1.2+ enforced, no HTTP endpoints for production services). Implement automated security patching with defined SLA (maximum 30 days for critical/high CVEs, documented in runbooks). Configure WAF for OWASP Top 10 protection on public-facing applications. Implement VPC security groups and NACLs with deny-by-default configurations. Document and evidence all of these controls — not just implement them.
Audit Logging and SIEM Configuration
Enable CloudTrail in all regions with log file validation and export to a separate, locked S3 bucket with object-lock retention. Enable VPC Flow Logs for all production VPCs. Implement application-level audit logging for all authentication events, privilege escalation, and data access. Configure a SIEM or log aggregation tool (AWS Security Hub, Datadog SIEM, or Elastic SIEM) with alerting rules for: repeated failed authentication, administrative API calls from unexpected IPs, and IAM policy changes. These alerts constitute evidence of the monitoring control operating.
Automated Evidence Collection Before the Observation Period
Configure automated evidence collection before the observation period begins. This includes: weekly AWS Config rule compliance snapshots exported to S3, monthly access review report generation, vulnerability scan exports from your scanner (Tenable, Qualys, or equivalent), deployment records from your CI/CD system, and incident response log exports. Store all evidence in a structured, timestamped format that can be delivered to auditors without manual reconstruction. The difference between a painful SOC 2 audit and a smooth one is almost entirely determined by whether evidence was collected continuously or assembled retrospectively.
The observation period then runs for 6 months while the automated evidence system collects control operating evidence. Wolk Inc recommends a pre-audit internal review at month 4 to identify any control exceptions before the auditor finds them — leaving time to remediate and still complete the observation period without restarting.
SOC 2 Type II Readiness: A B2B SaaS Company Example
A Series B B2B SaaS company was blocked in three enterprise deals pending SOC 2 Type II. Their previous approach had been to work with a GRC tool vendor and compliance consultant who had been engaged for 14 months with no audit start date in sight.
Wolk Inc conducted a two-week engineering audit, found 28 open infrastructure gaps, and implemented all of them in 6 weeks. Automated evidence collection was configured and the 6-month observation period began immediately after. The company received their SOC 2 Type II report 8 months after Wolk Inc engagement started — and closed all three blocked enterprise deals within 6 weeks of receiving the report.
The total Wolk Inc engagement cost was less than one month of the existing compliance consultant retainer. The difference was treating SOC 2 as an engineering project from the start.
Actionable takeaways
- SOC 2 Type II takes 4–8 weeks of engineering work plus a 6-month observation period — not 12–18 months — if the infrastructure is fixed before policies are written.
- The most common cause of SOC 2 delays is treating compliance as a policy project rather than an infrastructure project.
- MFA enforcement, IAM least-privilege, audit logging, and automated access reviews are the four highest-weight control areas for most SaaS environments.
- Automated evidence collection before the observation period starts is the single most impactful preparation for a smooth audit.
- A pre-audit internal review at month 4 of the observation period is the cheapest insurance against observation period failures.
Marcus Reid
Lead DevOps Engineer · Wolk Inc
Eight years building platform reliability programs, CI/CD pipelines, and cloud infrastructure for North American enterprises.
Blocked in enterprise deals pending SOC 2?
Wolk Inc implements the infrastructure controls required for SOC 2 Type II readiness in 4–8 weeks and configures automated evidence collection before the observation period begins. Book a 30-minute call to get an honest assessment of your current gap count and timeline.
Wolk Inc is a 2021-founded senior-engineer-only DevOps, Cloud, AI and Cybersecurity consulting firm serving US and Canadian enterprises.