SOC 2 Type II: Preparing for Your Audit, Controls Mapping, and Audit Readiness

SOC 2 Type II: Preparing for Your Audit, Controls Mapping, and Audit Readiness

SOC 2 Type II is the standard security certification that enterprise B2B buyers require before signing contracts. It covers five Trust Service Criteria (TSC): Security, Availability, Processing Integrity, Confidentiality, and Privacy. Most SaaS products pursue Security only for their first certification — it covers the controls enterprise buyers actually care about.

Type II (vs Type I) means the auditor observed your controls working over a period of time (typically 6–12 months). Type I is a snapshot; Type II is evidence that your controls actually operate consistently.

---

Timeline and Investment

Compliance automation platforms (Vanta, Drata, Secureframe) reduce this significantly — they automate evidence collection, surface gaps, and speed auditor review. Cost: $10,000–30,000/year, but typically halves the audit preparation time.

---

The Five Trust Service Criteria

For Security (CC series), the required controls cover:

---

Controls Implementation Checklist

Access Control (CC6) — Most Common Audit Findings

Required controls:
- [ ] MFA enforced for all employee accounts (Google Workspace, AWS, GitHub, etc.)
- [ ] Least-privilege access: employees have access only to what they need
- [ ] Access review: quarterly review of who has access to what
- [ ] Offboarding procedure: access revoked within 24h of termination
- [ ] Privileged access monitoring: production access logged
- [ ] Vendor access documented and reviewed annually

Evidence you'll need to provide:
- MFA enrollment screenshots (for all employees, all systems)
- Access control list exports (AWS IAM, GitHub org members, etc.)
- Offboarding checklist for at least 3 terminated employees in the period
- Quarterly access review sign-off records

Automated access review:

// scripts/quarterly-access-review.ts
// Run quarterly; export for auditor evidence

async function generateAccessReport() {
  const report: Record<string, unknown[]> = {};

  // GitHub: who has admin/write access to production repos?
  const { data: orgMembers } = await octokit.orgs.listMembers({
    org: 'yourorg',
    filter: 'all',
  });
  report.github = orgMembers.map(m => ({
    login: m.login,
    role: m.role,
    lastActive: m.updated_at,
  }));

  // AWS: who has production account access?
  const iamUsers = await iam.listUsers({}).promise();
  report.aws_iam = await Promise.all(
    iamUsers.Users.map(async user => {
      const keys = await iam.listAccessKeys({ UserName: user.UserName }).promise();
      return {
        username: user.UserName,
        created: user.CreateDate,
        accessKeys: keys.AccessKeyMetadata.map(k => ({
          keyId: k.AccessKeyId.substring(0, 8) + '...',
          status: k.Status,
          created: k.CreateDate,
        })),
      };
    })
  );

  // Database: who has production DB access?
  const dbUsers = await db.query('SELECT usename, usesuper FROM pg_user');
  report.postgresql = dbUsers.rows;

  // Export report for auditor
  const filename = `access-review-${new Date().toISOString().split('T')[0]}.json`;
  await fs.writeFile(filename, JSON.stringify(report, null, 2));
  console.log(`Access review report saved: ${filename}`);

  return report;
}

Change Management (CC8)

Required controls:
- [ ] All code changes go through code review (no direct pushes to main)
- [ ] Tests run before merge (CI pipeline)
- [ ] Production deployments require approval (branch protection rules)
- [ ] Change log / release notes maintained
- [ ] Emergency change procedure documented

Evidence:
- Branch protection settings screenshots (GitHub)
- Sample PR showing review + CI passing before merge
- Deployment log for the observation period
- Emergency change requests (if any occurred)

GitHub branch protection (required for auditor):

# Via GitHub API — screenshot this settings page for evidence
gh api repos/yourorg/yourrepo/branches/main/protection \
  -X PUT \
  -f required_status_checks='{"strict":true,"contexts":["ci/test","ci/lint"]}' \
  -f enforce_admins=true \
  -f required_pull_request_reviews='{"required_approving_review_count":1}' \
  -f restrictions=null

Incident Response (CC7)

Required controls:
- [ ] Incident response plan documented and tested
- [ ] Incident tracking (every production incident recorded)
- [ ] Post-incident reviews for P1/P2 incidents
- [ ] On-call rotation with escalation path
- [ ] Mean time to detect + respond tracked

Evidence:
- Incident response runbook
- Incident log for the observation period
- Post-mortem documents for significant incidents
- On-call schedule (PagerDuty/OpsGenie export)

Vulnerability Management (CC7)

Required controls:
- [ ] Dependency scanning (runs on every PR)
- [ ] Container image scanning  
- [ ] Penetration test annually
- [ ] CVE remediation SLA (Critical: 24h, High: 7 days, Medium: 30 days)

Evidence:
- Dependabot/Snyk scan reports
- Pen test report (if in observation period)
- Remediation tickets with timestamps showing SLA compliance

---

Compliance Automation Platforms

Vanta and Drata integrate with AWS, GitHub, Google Workspace, Okta, Slack, Jira, and others — automatically collecting evidence (screenshots, logs, exports) that would otherwise require manual work every quarter.

---

Common Audit Findings (Fix These First)

Based on common SOC 2 failures:

---

Vendor Risk Management

SOC 2 requires you to assess the security posture of vendors who process your customer data:

Tier 1 vendors (process customer data):
  - AWS, GCP, Azure: Reviewed annually (use their SOC 2 reports)
  - Stripe, Twilio, SendGrid: Collect their SOC 2 report annually
  - Any SaaS with customer PII

Tier 2 vendors (business operations, no customer data):
  - Slack, Notion, Linear: Annual review of security page
  - Lower scrutiny required

Evidence needed:
  - Vendor inventory spreadsheet (name, tier, data processed, last review date)
  - Copies of vendor SOC 2 reports or security questionnaires
  - Vendor onboarding checklist

---

Working With Viprasol

We help engineering teams implement the technical controls for SOC 2 — access management automation, CI/CD controls for change management evidence, vulnerability scanning integration, infrastructure security hardening, and technical documentation for auditors. We bridge the gap between compliance requirements and engineering implementation.

→ Talk to our team about SOC 2 technical implementation.

---

See Also

• Fintech Compliance Software — compliance in regulated industries
• Zero Trust Security — identity and access controls for CC6
• DevOps Best Practices — CI/CD controls for CC8
• Technical Due Diligence — audit-readiness overlap with due diligence
• Cloud Solutions — secure cloud infrastructure