Soc2 Controls

name: soc2-controls description: SOC 2 Type II Trust Services Criteria reference for scoping, mapping controls, gathering evidence, and preparing for audit readiness. tags: [compliance, security]

SOC 2 Type II Trust Services Criteria

Overview

SOC 2 (System and Organization Controls 2) is an auditing framework developed by the American Institute of Certified Public Accountants (AICPA) that evaluates an organization's information systems against the Trust Services Criteria (TSC). A SOC 2 Type II report covers both the design and operating effectiveness of controls over a review period (typically 6-12 months).

SOC 2 is the de facto compliance standard for B2B SaaS companies. Enterprise customers increasingly require a clean SOC 2 Type II report before signing contracts, making it a critical business enabler alongside a security control.

When to Use This Skill

• Preparing for your first SOC 2 audit.
• Mapping existing security controls to Trust Services Criteria.
• Building an evidence collection and management process.
• Responding to customer security questionnaires that reference SOC 2.
• Evaluating third-party vendor SOC 2 reports (complementary user entity controls).
• Maintaining continuous compliance between audit periods.

How It Works

Step 1: Define Scope

Identify the systems, infrastructure, people, processes, and data flows that are in scope for the SOC 2 report. Scope typically includes:

• Production infrastructure and environments.
• CI/CD pipelines and deployment processes.
• Identity and access management systems.
• Monitoring and incident response tools.
• Third-party subservice organizations (cloud providers, SaaS tools).
• Personnel with access to in-scope systems.

Step 2: Select Trust Services Categories

Choose which of the five TSC categories to include. Security (Common Criteria) is always required. Additional categories should align with customer requirements and business operations.

Step 3: Map Controls to Criteria

For each criterion (CC1 through CC9 and supplemental criteria), document the specific controls your organization has in place. Each control should have:

• Control ID -- unique identifier for tracking.
• Control description -- what the control does.
• Control owner -- person responsible.
• Frequency -- how often the control operates (continuous, daily, quarterly).
• Evidence type -- what artifacts demonstrate the control is working.

Step 4: Gather Evidence

Collect evidence that demonstrates each control operated effectively throughout the review period. Evidence categories include:

• Policies and procedures -- documented, approved, version-controlled.
• Configuration screenshots -- system settings proving controls are in place.
• Logs and reports -- audit trails, access reviews, vulnerability scans.
• Tickets and records -- change management, incident response, onboarding/offboarding.
• Automated exports -- infrastructure-as-code configs, CI/CD pipeline definitions.

Step 5: Prepare for Audit

Engage a licensed CPA firm to perform the examination. Preparation includes:

• Conduct a readiness assessment (gap analysis against TSC).
• Remediate identified gaps before the review period begins.
• Establish the review period (minimum 6 months for Type II).
• Assign evidence owners for each control area.
• Schedule walkthroughs and inquiry sessions with the auditor.
• Prepare a system description narrative.

Common Criteria (CC) Reference

CC1 -- Control Environment

Establishes the tone at the top and organizational commitment to integrity and security.

CC2 -- Communication and Information

Ensures quality information flows to support internal controls.

CC3 -- Risk Assessment

Identifies and manages risks that could prevent achieving objectives.

CC4 -- Monitoring Activities

Ongoing evaluation of internal controls.

CC5 -- Control Activities

Policies and procedures that mitigate risks.

CC6 -- Logical and Physical Access Controls

Controls over system access -- often the largest evidence collection area.

CC7 -- System Operations

Monitoring and incident management.

CC8 -- Change Management

Controls over system changes.

CC9 -- Risk Mitigation

Vendor management and business risk transfer.

Examples

Example 1: Evidence Collection Automation with Python

"""
SOC 2 evidence collector -- automates periodic evidence gathering
from cloud infrastructure and identity providers.
"""
import json
import datetime
from pathlib import Path

import boto3
from google.cloud import asset_v1


class SOC2EvidenceCollector:
    """Collects and organizes SOC 2 evidence artifacts."""

    def __init__(self, output_dir: str, review_period_start: str):
        self.output_dir = Path(output_dir)
        self.output_dir.mkdir(parents=True, exist_ok=True)
        self.review_start = datetime.date.fromisoformat(review_period_start)
        self.collection_date = datetime.date.today().isoformat()

    def collect_aws_iam_evidence(self) -> dict:
        """CC6.1-CC6.3: Collect IAM configuration evidence."""
        iam = boto3.client("iam")

        # Credential report for MFA status
        iam.generate_credential_report()
        cred_report = iam.get_credential_report()

        # Password policy
        password_policy = iam.get_account_password_policy()

        # List users and their MFA devices
        users = iam.list_users()["Users"]
        user_mfa = {}
        for user in users:
            mfa_devices = iam.list_mfa_devices(UserName=user["UserName"])
            user_mfa[user["UserName"]] = {
                "has_mfa": len(mfa_devices["MFADevices"]) > 0,
                "created": user["CreateDate"].isoformat(),
                "last_login": (
                    user.get("PasswordLastUsed", "never").isoformat()
                    if hasattr(user.get("PasswordLastUsed", ""), "isoformat")
                    else "never"
                ),
            }

        evidence = {
            "criterion": "CC6.1",
            "collected_at": self.collection_date,
            "password_policy": password_policy["PasswordPolicy"],
            "user_mfa_status": user_mfa,
            "total_users": len(users),
            "mfa_enabled_count": sum(
                1 for u in user_mfa.values() if u["has_mfa"]
            ),
        }

        output_path = self.output_dir / f"cc6_1_iam_{self.collection_date}.json"
        output_path.write_text(json.dumps(evidence, indent=2, default=str))
        return evidence

    def collect_encryption_evidence(self) -> dict:
        """CC6.7: Collect encryption-in-transit evidence."""
        acm = boto3.client("acm")
        certs = acm.list_certificates(
            CertificateStatuses=["ISSUED"]
        )["CertificateSummaryList"]

        evidence = {
            "criterion": "CC6.7",
            "collected_at": self.collection_date,
            "tls_certificates": [
                {
                    "domain": c["DomainName"],
                    "status": c["Status"],
                    "not_after": c.get("NotAfter", "").isoformat()
                    if hasattr(c.get("NotAfter", ""), "isoformat")
                    else "",
                }
                for c in certs
            ],
        }

        output_path = self.output_dir / f"cc6_7_encryption_{self.collection_date}.json"
        output_path.write_text(json.dumps(evidence, indent=2, default=str))
        return evidence

    def collect_change_management_evidence(self) -> dict:
        """CC8.1: Collect change management evidence from GitHub."""
        # Uses GitHub API -- requires GITHUB_TOKEN env var
        import requests
        import os

        token = os.environ["GITHUB_TOKEN"]
        org = os.environ["GITHUB_ORG"]
        headers = {"Authorization": f"Bearer {token}"}

        repos_resp = requests.get(
            f"https://api.github.com/orgs/{org}/repos",
            headers=headers,
            params={"per_page": 100},
            timeout=30,
        )
        repos = repos_resp.json()

        branch_protections = {}
        for repo in repos:
            bp_resp = requests.get(
                f"https://api.github.com/repos/{org}/{repo['name']}"
                f"/branches/{repo['default_branch']}/protection",
                headers=headers,
                timeout=30,
            )
            if bp_resp.status_code == 200:
                bp = bp_resp.json()
                branch_protections[repo["name"]] = {
                    "required_reviews": bp.get(
                        "required_pull_request_reviews", {}
                    ).get("required_approving_review_count", 0),
                    "dismiss_stale_reviews": bp.get(
                        "required_pull_request_reviews", {}
                    ).get("dismiss_stale_reviews", False),
                    "require_status_checks": bp.get(
                        "required_status_checks") is not None,
                }

        evidence = {
            "criterion": "CC8.1",
            "collected_at": self.collection_date,
            "repos_assessed": len(repos),
            "branch_protections": branch_protections,
        }

        output_path = self.output_dir / f"cc8_1_change_mgmt_{self.collection_date}.json"
        output_path.write_text(json.dumps(evidence, indent=2, default=str))
        return evidence

    def generate_collection_summary(self, results: list[dict]) -> None:
        """Generate a summary report of all collected evidence."""
        summary = {
            "collection_date": self.collection_date,
            "review_period_start": self.review_start.isoformat(),
            "artifacts_collected": len(results),
            "criteria_covered": [r["criterion"] for r in results],
        }
        output_path = self.output_dir / f"collection_summary_{self.collection_date}.json"
        output_path.write_text(json.dumps(summary, indent=2))


# Usage:
# collector = SOC2EvidenceCollector("./evidence/2026-q1", "2025-09-01")
# results = [
#     collector.collect_aws_iam_evidence(),
#     collector.collect_encryption_evidence(),
#     collector.collect_change_management_evidence(),
# ]
# collector.generate_collection_summary(results)

Example 2: Control Mapping for a SaaS Company

soc2_control_mapping:
  organization: "Acme SaaS Inc."
  report_type: "Type II"
  review_period: "2025-09-01 to 2026-02-28"
  tsc_categories:
    - Security
    - Availability
    - Confidentiality

  control_matrix:
    - criterion: CC6.1
      description: "Logical access security"
      controls:
        - id: AC-001
          title: "SSO with MFA enforcement"
          owner: "IT Operations"
          frequency: "Continuous"
          evidence:
            - "Okta MFA policy screenshot"
            - "SSO configuration export"
            - "Login audit logs (quarterly sample)"
          tools: ["Okta", "AWS IAM"]

        - id: AC-002
          title: "Service account key rotation"
          owner: "Platform Engineering"
          frequency: "Every 90 days"
          evidence:
            - "Key rotation automation logs"
            - "GCP service account key age report"
          tools: ["GCP IAM", "Terraform"]

    - criterion: CC6.2
      description: "User provisioning and deprovisioning"
      controls:
        - id: AC-003
          title: "Automated onboarding/offboarding via HRIS integration"
          owner: "IT Operations"
          frequency: "Per event"
          evidence:
            - "HRIS-to-Okta sync configuration"
            - "Deprovisioning SLA report (target: 24h)"
            - "Quarterly access review records"
          tools: ["BambooHR", "Okta", "Jira"]

    - criterion: CC7.2
      description: "Monitoring for anomalies and security events"
      controls:
        - id: MON-001
          title: "SIEM with alerting for security events"
          owner: "Security Team"
          frequency: "Continuous"
          evidence:
            - "SIEM alert rule inventory"
            - "Monthly alert tuning records"
            - "Sample incident tickets from alerts"
          tools: ["Datadog SIEM", "PagerDuty"]

    - criterion: CC8.1
      description: "Change authorization, testing, and approval"
      controls:
        - id: CM-001
          title: "PR-based code review with branch protection"
          owner: "Engineering"
          frequency: "Per change"
          evidence:
            - "GitHub branch protection settings"
            - "Sample PRs showing review and approval"
            - "CI/CD pipeline configuration"
          tools: ["GitHub", "GitHub Actions"]

Best Practices

Do This

• Start with Security (Common Criteria) only for your first SOC 2; add categories later.
• Automate evidence collection wherever possible to reduce audit fatigue.
• Maintain a control-to-evidence mapping spreadsheet updated in real time.
• Run a readiness assessment 3-6 months before your desired report start date.
• Choose an auditor experienced with your tech stack and company size.
• Document compensating controls when you cannot meet a criterion directly.
• Keep evidence organized by criterion with consistent naming conventions.
• Establish a "SOC 2 channel" for coordinating evidence requests across teams.

Don't Do This

• Do not wait until the audit period to start documenting controls; auditors need evidence of consistent operation.
• Do not include unnecessary TSC categories just to appear thorough; each adds audit scope and cost.
• Do not confuse SOC 2 Type I (point-in-time design) with Type II (operating effectiveness over time).
• Do not rely solely on manual evidence; auditors value automated, tamper-resistant evidence.
• Do not assume cloud provider controls cover your responsibilities; understand the shared responsibility model.
• Do not treat SOC 2 as a one-time project; it is a continuous compliance program.

Security Checklist

Scoping and Governance:

• System boundaries and in-scope components documented
• Trust Services Categories selected based on customer and business requirements
• Subservice organizations identified and their SOC 2 reports reviewed
• Management assertion and system description narrative drafted

CC1-CC5 (Foundation Controls):

• Security policies published, versioned, and acknowledged by employees
• Risk assessment performed and risk register maintained
• Security awareness training completed by all personnel
• Background checks performed for new hires
• Board or management oversight of security program documented

CC6 (Access Controls):

• MFA enforced for all user access to in-scope systems
• Provisioning and deprovisioning SLAs defined and met
• Quarterly access reviews completed with evidence
• Encryption at rest and in transit verified for all data stores
• Physical access controls documented (or cloud provider SOC 2 referenced)

CC7 (System Operations):

• SIEM or log aggregation operational with retention meeting audit period
• Vulnerability scanning running at least quarterly
• Incident response playbooks documented and tested
• Penetration test completed within the last 12 months

CC8 (Change Management):

• All production changes go through code review and approval
• CI/CD pipeline enforces automated testing before deployment
• Emergency change process documented with post-hoc review

CC9 (Risk Mitigation):

• Vendor inventory maintained with risk ratings
• Critical vendor SOC 2 reports reviewed annually
• Data processing agreements in place with subprocessors

Audit Readiness:

• Evidence organized by criterion in shared repository
• Evidence owners assigned and responsive
• Readiness assessment gaps remediated
• Review period of at least 6 months established

Related Skills

• @nist-csf -- Map SOC 2 criteria to NIST CSF functions for broader security context.
• @iso27001-annexa -- Cross-reference SOC 2 controls with ISO 27001 Annex A for international compliance.
• @compliance-crosswalk -- Build a unified control framework spanning SOC 2, NIST, and ISO.

Additional Resources

• AICPA Trust Services Criteria (2017) -- Official TSC specification.
• AICPA SOC 2 Guide -- Practitioner guidance.
• CSA STAR and SOC 2 -- Cloud-specific SOC 2 considerations.
• CIS Controls v8 Mapping to SOC 2 -- Technical control implementation guidance.