# IAM: Enforce MFA and least-privilege roles
resource "aws_iam_role" "app_service" {
  name = "app-service-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = { Service = "ecs.amazonaws.com" }
    }]
  })
  tags = { Compliance = "SOC2", Control = "CC6.1" }
}

# RDS: Enforce encryption at rest & in transit
resource "aws_db_instance" "primary" {
  engine               = "postgres"
  engine_version       = "14.7"
  instance_class       = "db.t3.medium"
  allocated_storage    = 100
  storage_encrypted    = true
  kms_key_id           = aws_kms_key.db_encryption.arn
  publicly_accessible  = false
  skip_final_snapshot  = true
  tags = { Compliance = "SOC2", Control = "CC6.7" }
}

# CloudTrail: Centralized audit logging
resource "aws_cloudtrail" "audit_trail" {
  name                          = "startup-audit-trail"
  s3_bucket_name                = aws_s3_bucket.audit_logs.id
  is_multi_region_trail         = true
  enable_log_file_validation    = true
  include_global_service_events = true
  tags = { Compliance = "SOC2", Control = "CC7.2" }
}

package soc2.access

# Reject IAM roles with wildcard permissions
deny[msg] {
  input.action == "iam:CreateRole"
  policy := input.request.policy_document
  statement := policy.Statement[_]
  statement.Effect == "Allow"
  statement.Resource == "*"
  msg := "SOC2 Violation: Wildcard resource detected in IAM role creation"
}

# Enforce PR-based change approval for production infra
deny[msg] {
  input.target == "production"
  not input.approvals >= 2
  msg := "SOC2 Violation: Production changes require minimum 2 approvers"
}

import boto3
import json
from datetime import datetime, timedelta

def collect_access_evidence():
    iam = boto3.client('iam')
    cloudtrail = boto3.client('cloudtrail')
    
    # 1. List all IAM users with active keys older than 90 days
    users = iam.list_users()['Users']
    stale_keys = []
    for user in users:
        keys = iam.list_access_keys(UserName=user['UserName'])['AccessKeyMetadata']
        for key in keys:
            if (datetime.now(key['CreateDate'].tzinfo) - key['CreateDate']).days > 90:
                stale_keys.append({
                    'User': user['UserName'],
                    'KeyId': key['AccessKeyId'],
                    'Created': key['CreateDate'].isoformat()
                })
    
    # 2. Pull CloudTrail events for privileged actions in last 30 days
    end = datetime.now()

start = end - timedelta(days=30)
events = cloudtrail.lookup_events(
    LookupAttributes=[{'AttributeKey': 'EventSource', 'AttributeValue': 'iam.amazonaws.com'}],
    StartTime=start,
    EndTime=end,
    MaxResults=50
)

evidence = {
    'report_date': end.isoformat(),
    'stale_keys': stale_keys,
    'privileged_events': len(events['Events']),
    'control_mapping': ['CC6.1', 'CC6.3', 'CC7.1']
}

with open(f'evidence/soc2_access_{end.strftime("%Y%m%d")}.json', 'w') as f:
    json.dump(evidence, f, indent=2, default=str)

return evidence

if name == "main": collect_access_evidence()

### 4. CI/CD Compliance Gate (GitHub Actions)
Map to: CC8.1 (Change Management), CC6.8 (Segregation of Duties)

```yaml
name: SOC2 Compliance Gate
on:
  pull_request:
    branches: [main]
    paths:
      - 'infra/**'
      - 'src/config/**'

jobs:
  validate-controls:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install OPA
        run: |
          curl -L -o opa https://openpolicyagent.org/downloads/latest/opa_linux_amd64_static
          chmod +x ./opa
      - name: Run Policy Check
        run: |
          ./opa eval -i infra/policy_input.json -d policies/ soc2.access.deny
      - name: Verify PR Approvals
        run: |
          APPROVALS=$(gh pr view ${{ github.event.pull_request.number }} --json reviews --jq '[.reviews[] | select(.state == "APPROVED")] | length')
          if [ "$APPROVALS" -lt 2 ]; then
            echo "::error::SOC2 Control CC8.1: Minimum 2 approvals required for production changes"
            exit 1
          fi
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Implementation Notes:

• Map every control to a specific technical implementation, not just a policy document
• Store evidence in a versioned, immutable bucket (e.g., S3 with Object Lock)
• Run evidence collection on a cron schedule (weekly for access, daily for logs)
• Ensure auditors receive API-accessible evidence, not static PDFs

Pitfall Guide (6 Critical Mistakes)

1. Scope Creep & Over-Inclusion

Startups often attempt to include every system, vendor, and environment in the audit scope. This inflates cost, complicates evidence collection, and delays issuance. Mitigation: Define a strict system boundary. Include only customer-facing production environments, core data stores, and primary authentication systems. Exclude sandbox, staging, and internal-only tools unless they process customer data. Document exclusions explicitly in the system description.

2. Manual Evidence Assembly

Relying on screenshots, spreadsheets, and email trails creates fragile evidence chains. Auditors will reject inconsistent or backdated artifacts. Mitigation: Implement automated evidence pipelines. Use cloud-native logging, IaC state files, CI/CD run logs, and identity provider exports. Store evidence in a structured format with cryptographic hashes and timestamps.

3. Treating Type I as a Sales Substitute

Type I reports cover a single point in time and satisfy initial vendor questionnaires, but enterprise procurement increasingly demands Type II (6–12 months of operating effectiveness). Mitigation: Plan for Type II from day one. Run controls continuously, not just during audit prep. Use Type I as a milestone, not a destination. Communicate clearly with sales: Type I opens doors, Type II closes deals.

4. Neglecting Vendor Risk Management (VRM)

SOC 2 requires you to assess and monitor third-party services that impact your control environment (e.g., cloud providers, payment processors, customer support tools). Mitigation: Maintain a vendor register with risk tiers. Request SOC 2/ISO 27001 reports from critical vendors. Implement contract clauses for breach notification and right-to-audit. Automate vendor review reminders.

5. Inadequate Change Management Documentation

Auditors scrutinize how code and infrastructure changes are approved, tested, and deployed. Startups with "move fast" cultures often lack traceable approval workflows. Mitigation: Enforce PR-based deployments for production. Require design reviews for architectural changes. Log deployment timestamps, rollback procedures, and post-incident reviews. Map every change to a ticketing system (Jira, Linear, GitHub Issues).

6. Over-Reliance on Auditors for Implementation

Auditors are independent validators, not consultants. Expecting them to build your controls, write policies, or configure cloud security leads to scope disputes and audit delays. Mitigation: Engage a compliance automation platform or fractional CISO for implementation. Use auditors strictly for readiness reviews and final examination. Maintain clear separation between builder and verifier roles.

Production Bundle

✅ Compliance Checklist

Pre-Audit (Days 1–30)

• Define system boundary & Trust Services Criteria scope
• Draft system description (architecture, data flows, control environment)
• Implement IAM least-privilege & MFA enforcement
• Enable centralized logging & log retention (≥1 year)
• Configure encryption at rest & in transit for all data stores
• Establish change management workflow with PR approvals
• Create incident response plan & runbook
• Inventory all third-party vendors & collect their compliance certs

During Audit (Days 31–60)

• Provide auditor with read-only access to evidence repository
• Schedule control walkthroughs with engineering & ops leads
• Respond to evidence requests within 24 hours
• Document any control exceptions with remediation plans
• Conduct mock interview with designated spokesperson

Post-Audit (Days 61–90)

• Review draft report & address qualified opinions
• Distribute report to sales & customer success teams
• Update vendor portal & compliance page
• Schedule quarterly control self-assessments
• Plan Type II observation period & evidence cadence

📊 Decision Matrix

Decision Point	Option A	Option B	Option C	Recommended For Startups
Report Type	Type I (Point-in-time)	Type II (6–12 months operating effectiveness)	Both sequentially	Start with Type I for sales velocity, immediately begin Type II observation
Implementation Model	In-house founder/CTO	Fractional CISO + automation platform	Full-time GRC hire	Fractional CISO + vCompliance tool (e.g., Vanta, Drata, Sprinto)
Auditor Selection	Big 4 accounting firm	Mid-tier tech-focused CPA firm	Boutique cloud compliance specialist	Mid-tier tech-focused CPA (lower cost, faster turnaround, SaaS expertise)
Evidence Storage	Local drives + email	Shared drive + spreadsheets	Immutable S3 bucket + API-accessible JSON	Immutable cloud storage with structured JSON + version control
Control Automation	Manual policy docs + screenshots	IaC + policy engines + CI/CD gates	Full GRC platform integration	IaC + policy engines + lightweight GRC platform for vendor management

⚙️ Config Template: Control Mapping & Implementation Record

control_id: CC6.1
name: Logical and Physical Access Controls
description: The entity implements logical access security software, infrastructure, and architectures over protected information assets.
implementation:
  - method: Infrastructure-as-Code
    tool: Terraform, AWS IAM
    frequency: Continuous
    evidence: IAM role definitions, MFA enforcement logs, access reviews
  - method: Policy Enforcement
    tool: OPA, GitHub Branch Protection
    frequency: Per PR
    evidence: PR approval logs, policy violation reports
  - method: Periodic Review
    tool: Python automation + Jira
    frequency: Quarterly
    evidence: Access review tickets, remediation records
owner: Head of Engineering
reviewer: Fractional CISO
status: Automated
exceptions: None
remediation_target: 0 days

🚀 Quick Start: 30-60-90 Day Roadmap

Days 1–30: Foundation & Scope

• Finalize audit scope & Trust Services Criteria
• Stand up evidence repository (S3 + Object Lock)
• Enforce MFA, least-privilege IAM, and encryption across prod
• Draft system description & incident response plan
• Select auditor & compliance automation tool

Days 31–60: Control Automation & Evidence

• Implement IaC for all prod infrastructure
• Deploy policy-as-code gates in CI/CD
• Automate weekly evidence collection (access, logs, changes)
• Conduct internal control walkthroughs
• Complete vendor risk register & collect third-party certs

Days 61–90: Audit Execution & Issuance

• Submit evidence package to auditor
• Host control interviews & system walkthroughs
• Address findings & update control documentation
• Receive Type I report & publish to customer portal
• Initiate 6-month Type II observation period with continuous monitoring

Closing Notes

SOC 2 compliance for startups is no longer about surviving an annual audit. It's about building a control architecture that scales with your product, satisfies enterprise procurement, and reduces operational risk. By treating compliance as code, automating evidence collection, and maintaining strict scope discipline, startups can achieve audit readiness without sacrificing velocity. The companies that win in B2B SaaS don't just pass SOC 2—they operationalize it.