SOC 2 Compliance: Engineering Team Handbook

SOC 2 isn’t a feature — it’s a business requirement. If you sell B2B SaaS, enterprise customers will ask for your SOC 2 report before signing. The average enterprise sales cycle stalls 3-6 months without SOC 2 attestation. This guide translates SOC 2 requirements into engineering tasks so your team knows exactly what to build, document, and maintain, and how to gather evidence without disrupting development velocity.

The key insight for engineers: SOC 2 doesn’t prescribe specific technologies — it prescribes outcomes. You can use any tool or framework as long as you can prove the control exists, operates effectively, and is continuously monitored.

SOC 2 Trust Service Criteria

Criteria	Focus	Engineering Impact	Typical Controls
Security (required)	Protection against unauthorized access	IAM, encryption, network controls	Firewalls, MFA, encryption at rest/transit
Availability	System uptime and performance	SLAs, monitoring, DR planning	Uptime SLAs, failover, monitoring
Confidentiality	Data protection	Encryption at rest/transit, access controls	Data classification, DLP, key management
Processing Integrity	Accurate, complete processing	Validation, error handling, audit trails	Input validation, reconciliation, logging
Privacy	PII handling	Consent, data minimization, retention	Privacy policy, consent management, anonymization

Most companies start with Security + Availability. Add Confidentiality if you handle sensitive data. Add Processing Integrity if you process financial transactions. Add Privacy if you’re subject to GDPR or CCPA.

SOC 2 Type I vs Type II

Aspect	Type I	Type II
What it proves	Controls exist as of a specific date	Controls operate effectively over 3-12 months
Timeline	1-2 months	6-12 months (observation period)
Customer perception	”They have controls"	"Their controls actually work”
Recommended for	First-time compliance, quick wins	Mature organizations, enterprise sales
Cost	$15K-$30K	$30K-$80K

Access Control

Principle of Least Privilege

# Infrastructure as Code: Role definitions
roles:
  developer:
    permissions:
      - read:production-logs
      - write:development-environment
      - deploy:staging
    denied:
      - write:production-database
      - access:customer-pii
      
  senior_engineer:
    inherits: developer
    permissions:
      - deploy:production  # Via CI/CD only, not direct access
      - read:production-database  # Read-only, audited
      
  admin:
    inherits: senior_engineer
    permissions:
      - manage:iam-roles
      - access:break-glass  # Emergency access, requires justification

Access Reviews

# Quarterly access review automation
def generate_access_review():
    report = {
        "review_period": "Q1 2026",
        "reviewer": "Engineering Manager",
        "due_date": "2026-04-15",
        "users": []
    }
    
    for user in get_all_users():
        report["users"].append({
            "name": user.name,
            "role": user.role,
            "last_login": user.last_login,
            "permissions": user.permissions,
            "status": "active" if user.last_login > thirty_days_ago else "review-needed",
            "action_required": "confirm" if user.active else "revoke"
        })
    
    return report

Access Control Evidence Checklist

Control	Evidence Required	Collection Method
MFA enabled for all users	MFA enrollment report	IdP export (quarterly)
Least privilege enforced	Role assignment list	IAM policy export
Access reviews completed	Signed review reports	Quarterly review documents
Offboarded users deprovisioned	Termination checklist + timestamp	HR workflow integration
Break-glass access logged	Emergency access audit trail	CloudTrail/Activity Log
SSH keys rotated	Key age report	Automated scanning

Change Management

Required Process

1. Developer creates PR with changes
2. Automated tests run (unit, integration, security)
3. Peer review + approval (minimum 1 reviewer)
4. CI/CD deploys to staging
5. QA validation in staging
6. Production deployment via CI/CD (no manual deployments)
7. Post-deployment monitoring (15 min window)

Evidence Collection

# GitHub Actions: SOC 2 evidence collection
- name: Log deployment evidence
  run: |
    echo '{
      "change_id": "${{ github.sha }}",
      "pr_number": "${{ github.event.pull_request.number }}",
      "author": "${{ github.actor }}",
      "reviewer": "${{ github.event.review.user.login }}",
      "tests_passed": true,
      "deployed_at": "'$(date -u +%Y-%m-%dT%H:%M:%SZ)'",
      "environment": "production"
    }' >> $GITHUB_STEP_SUMMARY

Change Management Evidence

Control	What Auditors Check	What You Need
All changes have PRs	No direct commits to main	Branch protection rules screenshot
Changes are reviewed	PR has at least 1 approval	PR approval logs (GitHub/GitLab API)
Changes are tested	CI pipeline passes before merge	CI/CD execution history
No manual production deploys	All production changes go through CI/CD	Deployment logs with pipeline links
Emergency changes documented	Hotfix process with post-mortem	Emergency change log with justification

Encryption

Layer	Requirement	Implementation	Evidence
In transit	TLS 1.2+ everywhere	Enforce HTTPS, HSTS headers	SSL Labs scan report
At rest (database)	AES-256 encryption	AWS RDS encryption, Azure TDE	Cloud provider encryption status
At rest (storage)	AES-256 encryption	S3 SSE, Azure Blob encryption	Bucket/container encryption policy
Secrets	Encrypted, rotatable	AWS Secrets Manager, HashiCorp Vault	Secrets rotation log
Backups	Encrypted	Encrypted snapshots with separate key	Backup encryption configuration
Key management	Keys rotated annually	KMS with automatic rotation	Rotation schedule + evidence

Logging & Monitoring

What to Log

Event	Log?	Retention	Why Auditors Care
Authentication (success/fail)	Yes	1 year	Detect unauthorized access attempts
Authorization failures	Yes	1 year	Detect privilege escalation attempts
Data access (PII reads)	Yes	1 year	Track who accessed sensitive data
Configuration changes	Yes	3 years	Unauthorized system modifications
Deployments	Yes	3 years	Change management evidence
System errors	Yes	1 year	Availability monitoring evidence
User CRUD operations	Yes	1 year	Account lifecycle tracking
Admin actions	Yes	3 years	Privileged access monitoring

Alerting Requirements

alerts:
  - name: "Multiple failed logins"
    condition: "failed_logins > 5 in 5 minutes for same user"
    severity: high
    action: "Lock account, notify security"
    soc2_control: "CC6.1 - Logical Access Security"
    
  - name: "Unusual data access"
    condition: "PII queries > 100 in 1 hour by single user"
    severity: medium
    action: "Alert security team for review"
    soc2_control: "CC6.3 - Restricts Logical Access"
    
  - name: "Production deployment outside hours"
    condition: "deploy to production outside 9AM-5PM ET weekdays"
    severity: low
    action: "Log and review in weekly security standup"
    soc2_control: "CC8.1 - Change Management"

Log Integrity

Requirement	Implementation	Why
Logs cannot be modified	Write-once storage (S3 Object Lock, CloudWatch)	Tamper-proof audit trail
Logs cannot be deleted (within retention)	Retention policies + access controls	Preservation for auditors
Log access is itself logged	CloudTrail on log bucket access	Who’s looking at the logs?
Time synchronization	NTP configured on all servers	Correlate events across systems

Incident Response

┌──────────────┐
│  Detection   │ Automated monitoring, customer report, security scan
└──────┬───────┘
       ▼
┌──────────────┐
│   Triage     │ Severity classification (P1-P4), assign incident commander
└──────┬───────┘
       ▼
┌──────────────┐
│ Containment  │ Isolate affected systems, preserve evidence
└──────┬───────┘
       ▼
┌──────────────┐
│ Remediation  │ Fix root cause, patch vulnerability
└──────┬───────┘
       ▼
┌──────────────┐
│  Recovery    │ Restore services, verify fix
└──────┬───────┘
       ▼
┌──────────────┐
│  Postmortem  │ Document timeline, root cause, prevention measures
└──────────────┘

Incident Severity Matrix

Severity	Definition	Response Time	Notification
P1 - Critical	Data breach, service down, security compromise	15 minutes	Executive team + legal + customers
P2 - High	Partial outage, degraded performance, near-miss	1 hour	Engineering leadership
P3 - Medium	Non-critical vulnerability, minor data issue	4 hours	Security team
P4 - Low	Informational finding, policy deviation	Next business day	Team lead

Vendor Management

SOC 2 requires you to assess the security of vendors that handle your data.

Vendor Tier	Criteria	Assessment Required
Critical	Processes/stores customer data	SOC 2 report review + security questionnaire annually
High	Infrastructure provider (AWS, GCP)	SOC 2/3 report review annually
Medium	SaaS tools with company data	Security questionnaire + policy review
Low	No access to sensitive data	Vendor register entry only

Audit Preparation Timeline

Months Before	Action
6 months	Select auditor, review scope, gap assessment
4 months	Implement missing controls, document policies
2 months	Internal readiness review, test evidence collection
1 month	Freeze major changes, finalize documentation
Audit period	3-6 month observation window
Post-audit	Receive report, remediate findings, share with customers

Checklist

:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For compliance consulting, visit garnetgrid.com. :::