SOC 2 Compliance for Engineering Teams: What You Actually Need to Build

SOC 2 is the compliance framework that every B2B SaaS company eventually encounters. Your enterprise customer asks for your SOC 2 report. You do not have one. Your sales team panics. Your CTO assigns it to engineering. Nobody on the team knows what SOC 2 actually requires, so they start reading audit firm marketing material and become deeply confused.

This guide cuts through the noise. SOC 2 is not as complicated as compliance consultants make it sound, but it is also not as trivial as your manager who approved the budget thinks. Here is what engineering teams actually need to know and build.

---

What SOC 2 Actually Is

SOC 2 is an audit framework that evaluates your organization against five Trust Service Criteria:

Criteria	What It Covers	Required?
Security (CC)	Protection of system against unauthorized access	✅ Always required
Availability	System uptime and performance	Optional but common
Processing Integrity	Accurate, complete data processing	Optional
Confidentiality	Protection of confidential information	Optional but common
Privacy	Personal information handling	Optional

The minimum viable SOC 2: Security only (called CC — Common Criteria). Most companies start here. Add Availability and Confidentiality if your customers require them. Do not add all five unless you have a specific business reason.

Type I vs Type II

	Type I	Type II
What it proves	Controls exist at a point in time	Controls work over a period (3-12 months)
Duration	Snapshot audit	Observation period + audit
Value	”We have policies"	"We follow our policies consistently”
What customers want	Acceptable for first audit	Required for mature companies
Timeline	1-3 months to prepare	6-12 months observation + 1-2 months audit

---

What Auditors Actually Look For

Auditors are not checking whether your code is elegant. They are checking whether you have controls and whether you follow them. Here is what “controls” means in engineering terms:

Access Control (CC6)

What auditors want to see:

✅ Role-based access control (RBAC) for all production systems
✅ MFA enforced on all accounts with production access
✅ Access reviews conducted quarterly (who has access and why)
✅ Access revoked within 24 hours of employee departure
✅ Principle of least privilege documented and enforced
✅ Break-glass procedures for emergency access (with audit trail)

What engineers need to build:

# Example: Terraform for access control
resource "aws_iam_policy" "production_readonly" {
  name = "production-readonly"
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect   = "Allow"
        Action   = ["s3:GetObject", "s3:ListBucket"]
        Resource = ["arn:aws:s3:::prod-*"]
      },
      {
        Effect   = "Deny"
        Action   = ["s3:DeleteObject", "s3:PutObject"]
        Resource = ["*"]
      }
    ]
  })
}

# Quarterly access review automation
resource "aws_config_rule" "iam_user_mfa" {
  name = "iam-user-mfa-enabled"
  source {
    owner             = "AWS"
    source_identifier = "IAM_USER_MFA_ENABLED"
  }
}

Change Management (CC8)

What auditors want to see:

✅ Code changes reviewed by someone other than the author
✅ All changes tested before production deployment
✅ Production deployments logged with who, what, when
✅ Rollback capability for every deployment
✅ Separation of duties (developers cannot deploy to production unilaterally)

What engineers need to build:

# GitHub branch protection — this IS your change management control
# .github/settings.yml or manual configuration
branches:
  main:
    protection:
      required_pull_request_reviews:
        required_approving_review_count: 1
        dismiss_stale_reviews: true
        require_code_owner_reviews: true
      required_status_checks:
        strict: true
        contexts:
          - "ci/unit-tests"
          - "ci/integration-tests"
          - "ci/security-scan"
      enforce_admins: true
      restrictions: null  # Only CI/CD can push to main

Monitoring and Incident Response (CC7)

What auditors want to see:

✅ Systems monitored for anomalies and security events
✅ Alerts configured for critical conditions
✅ Incident response plan documented
✅ Incidents tracked with resolution details
✅ Post-incident reviews conducted

Logging and Audit Trail (CC4, CC7)

# Structured logging that satisfies audit requirements
import structlog
import datetime

logger = structlog.get_logger()

def log_data_access(user_id: str, resource: str, action: str):
    """Every access to sensitive data must be logged."""
    logger.info(
        "data_access",
        user_id=user_id,
        resource=resource,
        action=action,
        timestamp=datetime.datetime.utcnow().isoformat(),
        source_ip=get_client_ip(),
        # Auditors want: WHO did WHAT to WHICH resource WHEN
    )

# Log retention: minimum 1 year for SOC 2
# Store logs in immutable storage (S3 with Object Lock)

---

Automating Compliance Evidence

The secret to surviving SOC 2 audits is automation. If evidence collection is manual, every audit will consume weeks of engineering time and everyone will hate it.

Evidence Collection Matrix

Control	Manual Evidence	Automated Evidence
Access reviews	Spreadsheet of users + roles (nightmare)	Script that exports IAM roles quarterly
Code review	Screenshots of PR approvals (tedious)	GitHub API query: PRs merged without review
Encryption at rest	AWS console screenshots	AWS Config rule checking encryption
Backup completion	Manual check of backup logs	CloudWatch alarm on backup failure
Vulnerability scanning	Point-in-time scan PDF	CI/CD pipeline with SAST/DAST on every PR

#!/bin/bash
# evidence-collector.sh — run monthly to generate audit evidence

EVIDENCE_DIR="evidence/$(date +%Y-%m)"
mkdir -p "$EVIDENCE_DIR"

# 1. Access review: list all IAM users and their last activity
aws iam generate-credential-report
aws iam get-credential-report --output text \
  --query 'Content' | base64 --decode > "$EVIDENCE_DIR/iam-credential-report.csv"

# 2. MFA status: verify all users have MFA
aws iam list-users --query 'Users[*].UserName' --output text | \
  while read user; do
    mfa=$(aws iam list-mfa-devices --user-name "$user" --query 'MFADevices' --output text)
    echo "$user,$mfa"
  done > "$EVIDENCE_DIR/mfa-status.csv"

# 3. Encryption status: check all S3 buckets
aws s3api list-buckets --query 'Buckets[*].Name' --output text | \
  while read bucket; do
    encryption=$(aws s3api get-bucket-encryption --bucket "$bucket" 2>&1)
    echo "$bucket: $encryption"
  done > "$EVIDENCE_DIR/s3-encryption-status.txt"

# 4. Change management: PRs merged without review
gh api repos/company/api-service/pulls?state=closed \
  --jq '.[] | select(.merged_at != null) | {number, title, review_count: (.requested_reviewers | length)}' \
  > "$EVIDENCE_DIR/pr-review-report.json"

echo "Evidence collected. Upload to compliance platform."

---

Timeline and Cost

Phase	Duration	Cost
Gap assessment	2-4 weeks	$5K-$15K (consultant) or free (self-service)
Control implementation	2-4 months	Engineering time (~1 FTE for 3 months)
Type I observation	N/A	N/A
Type I audit	2-4 weeks	$15K-$40K (audit firm)
Type II observation	3-12 months	Ongoing operational discipline
Type II audit	4-8 weeks	$20K-$60K (audit firm)
Annual renewal	Ongoing	$15K-$40K/year

Budget reality: Your first SOC 2 will cost $30K-$80K in audit fees plus 3-6 months of engineering effort. After the first year, maintenance drops to 20% of initial effort if you automated evidence collection properly.

---

Implementation Checklist

• Decide which Trust Service Criteria to include (start with Security only)
• Choose an audit firm (Big 4 is expensive and unnecessary for most startups)
• Run a gap assessment: what controls exist today vs what SOC 2 requires
• Implement access control: RBAC, MFA, quarterly reviews, offboarding
• Implement change management: branch protection, required reviews, CI/CD gates
• Implement logging: structured logs, 1-year retention, immutable storage
• Implement monitoring: alerts for security events, incident response process
• Automate evidence collection: monthly script that generates audit evidence
• Write policies: Information Security, Acceptable Use, Incident Response, Change Management
• Train the team: everyone should know what SOC 2 is and why it matters for the business