How to Pass SOC2 Type II Without Slowing Down Your Engineering Team

SOC2 Type II is the most common compliance requirement for B2B SaaS startups in the US. Enterprise customers request it. VCs mention it in term sheets. Yet most engineering teams treat it as a compliance project - a checklist to satisfy, not an engineering discipline to adopt.

The result: 6 months of retroactive documentation, manual evidence collection, and auditor meetings. Then, after the audit, everything reverts.

Here is the approach that makes SOC2 Type II a continuous output of your engineering process, not a project you do once and forget.

What SOC2 Type II Actually Measures

SOC2 is based on the Trust Services Criteria (TSC). Type II audits cover a defined observation period - typically 6 or 12 months - and assess whether your controls were consistently operating during that period, not just at the point of audit.

The five TSC categories:

1. •Security (CC) - the mandatory category. Covers access control, encryption, change management, incident response
2. •Availability (A) - uptime commitments. Usually required for infrastructure-critical SaaS
3. •Processing Integrity (PI) - data is processed correctly
4. •Confidentiality (C) - sensitive data is protected
5. •Privacy (P) - PII handling

Most startups pursue Security + Availability at minimum. Add Confidentiality if you handle sensitive customer data.

The Engineering Controls That Map to SOC2

The good news: most SOC2 technical controls are engineering best practices you should have anyway.

Access Control (CC6.1, CC6.2, CC6.3)

What auditors check:

• •Principle of least privilege on all systems
• •MFA enforced for all access to production systems
• •Access reviews conducted quarterly
• •Terminated employee access revoked within 24 hours

Engineering implementation:

hclcopy
# Terraform: enforce MFA for IAM users
resource "aws_iam_account_password_policy" "strict" {
  require_uppercase_characters   = true
  require_lowercase_characters   = true
  require_numbers                = true
  minimum_password_length        = 16
  require_symbols                = true
  allow_users_to_change_password = true
  max_password_age               = 90
  password_reuse_prevention      = 12
}

# Block actions without MFA
data "aws_iam_policy_document" "deny_without_mfa" {
  statement {
    sid    = "DenyWithoutMFA"
    effect = "Deny"
    not_actions = [
      "iam:CreateVirtualMFADevice",
      "iam:EnableMFADevice",
      "sts:GetSessionToken",
    ]
    resources = ["*"]
    condition {
      test     = "BoolIfExists"
      variable = "aws:MultiFactorAuthPresent"
      values   = ["false"]
    }
  }
}

Use AWS IAM Identity Center (formerly SSO) with short-lived credentials. Engineers should never have long-lived AWS access keys.

For GitHub: enforce SAML SSO and require branch protection rules on all repositories with a main or master branch:

jsoncopy
{
  "required_status_checks": { "strict": true, "contexts": ["ci/build", "ci/test"] },
  "enforce_admins": true,
  "required_pull_request_reviews": {
    "required_approving_review_count": 1,
    "dismiss_stale_reviews": true
  },
  "restrictions": null
}

Change Management (CC8.1)

What auditors check:

• •All production changes go through a documented process
• •Changes are reviewed before deployment
• •Changes can be traced from requirement to deployment

Engineering implementation:

• •Every change via a Pull Request with required review
• •CI/CD pipeline gates on tests passing
• •Deployment logs show who deployed what, when

Your Git history is your change management log. ArgoCD or GitHub Actions deployment records are your audit trail. Make sure you retain these for at least 1 year (the observation period plus buffer).

Encryption (CC6.7)

What auditors check:

• •Data encrypted at rest
• •Data encrypted in transit
• •Key management documented

hclcopy
# RDS encryption at rest
resource "aws_db_instance" "main" {
  storage_encrypted = true
  kms_key_id        = aws_kms_key.rds.arn
}

# S3 bucket encryption
resource "aws_s3_bucket_server_side_encryption_configuration" "main" {
  bucket = aws_s3_bucket.main.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.s3.arn
    }
  }
}

# Enforce TLS-only S3 access
resource "aws_s3_bucket_policy" "enforce_tls" {
  bucket = aws_s3_bucket.main.id
  policy = jsonencode({
    Statement = [{
      Sid       = "DenyHTTP"
      Effect    = "Deny"
      Principal = "*"
      Action    = "s3:*"
      Resource  = ["${aws_s3_bucket.main.arn}/*", aws_s3_bucket.main.arn]
      Condition = { Bool = { "aws:SecureTransport" = "false" } }
    }]
  })
}

Logging and Monitoring (CC7.2, CC7.3)

What auditors check:

• •All access to production systems logged
• •Logs retained for 1+ years
• •Anomalies detected and investigated

hclcopy
# CloudTrail for all API calls
resource "aws_cloudtrail" "main" {
  name                          = "audit-trail"
  s3_bucket_name                = aws_s3_bucket.audit_logs.id
  include_global_service_events = true
  is_multi_region_trail         = true
  enable_log_file_validation    = true

  event_selector {
    read_write_type           = "All"
    include_management_events = true

    data_resource {
      type   = "AWS::S3::Object"
      values = ["arn:aws:s3:::*/*"]
    }
  }
}

# Alert on root account usage
resource "aws_cloudwatch_metric_alarm" "root_account_usage" {
  alarm_name  = "root-account-usage"
  namespace   = "CloudTrailMetrics"
  metric_name = "RootAccountUsageCount"
  threshold   = 1
  period      = 60
  alarm_actions = [aws_sns_topic.security_alerts.arn]
}

Incident Response (CC7.4, CC7.5)

What auditors check:

• •Documented incident response process
• •Evidence that incidents were detected, investigated, and resolved
• •Post-incident reviews conducted

Engineering implementation:

• •Maintain an incidents Notion/Confluence page (or GitHub wiki) with incident logs
• •Runbooks for common incidents
• •Alertmanager routed to PagerDuty with escalation policy

Every PagerDuty incident is an audit artifact. Make sure your alerting generates clear incident records.

The Evidence Collection Problem

Type II auditors need evidence that controls were operating continuously over the observation period. This means:

• •Access review logs from every quarter
• •Deployment records (who deployed what, when)
• •Security scanning results from CI/CD
• •Vulnerability management records
• •Training completion records

Doing this manually is painful. Tools like Vanta, Drata, or Secureframe automate evidence collection - they connect to your GitHub, AWS, Google Workspace, and HR systems and pull evidence automatically.

Cost: $15K–$30K/year for the platform. The alternative is 200–400 hours of engineering time per year doing it manually. The math usually favours the platform.

The Audit Timeline

The 6-month minimum observation period is the hard constraint. You cannot shortcut it. Start the technical controls work immediately.

What Actually Fails SOC2

From the audits we have assisted with, the most common failure points:

1. •Secrets in code - hardcoded API keys in GitHub history
2. •No MFA on production systems - GitHub or AWS accessed without MFA
3. •Missing access reviews - no evidence of quarterly reviews
4. •Terminated employee access - offboarding process not documented or not followed
5. •Unencrypted data - RDS instances without encryption enabled at creation

Numbers 1 and 2 are engineering controls. Numbers 3–5 are process controls that need both engineering support and ops discipline.

The Engineering Mindset Shift

The teams that pass SOC2 without significant pain treat it the same way they treat production reliability: it is always on, it is measured continuously, and there is an owner for every control.

The teams that struggle treat it as a compliance project that happens once a year. These teams scramble for evidence in month 10 and discover that the controls they thought were in place were not actually operating.

SOC2 Type II is a proof that your engineering practices are consistently good. If they are, the audit is straightforward. If they are not, the audit is the least of your problems.

Planning a SOC2 audit or in the middle of one? Book a free audit - we will assess your technical control gaps and build a fix plan mapped to the Trust Services Criteria.