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

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

Quick answer. SOC 2 Type II is the security certification enterprise B2B buyers require, and Type II (unlike a point-in-time Type I) proves your controls operated consistently over 6-12 months. Most SaaS companies certify the Security Trust Service Criterion first, starting with a 2-4 week gap assessment, then 2-6 months of remediation.

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

---

What We Bring to the Table

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.

---

Related Topics

• 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

How SOC 2 Due Diligence Fits Into Vendor Evaluation

When an enterprise buyer runs SOC 2 due diligence on a prospective vendor, they are checking that your security controls actually work as documented, not just that a report exists. Expect their procurement and security teams to request your current Type II report under NDA, review the auditor's opinion, and read every exception in the management response. They will scrutinize the trust services criteria you scoped, the audit period, and any carve-outs for subservice organizations. To pass this review smoothly, keep your report recent, your control mapping clear, and your remediation evidence ready. At Viprasol, our senior engineers build systems with auditable logging, least-privilege access, and change management from day one, so the controls a SOC 2 due diligence request examines are genuinely in place and easy to demonstrate.