Soc2 Controls

<!-- AUTO-GENERATED by export-skills.py — DO NOT EDIT -->
---
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.

| Category | When to Include |
|----------|-----------------|
| Security (CC) | Always required -- foundational to every SOC 2 |
| Availability | SLA commitments, uptime guarantees to customers |
| Processing Integrity | Financial transactions, data pipelines, calculations |
| Confidentiality | Handling confidential business data, NDA obligations |
| Privacy | Processing personal information (PII/PHI) |

### 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.

| Criterion | Key Controls |
|-----------|-------------|
| CC1.1 | Board/management oversight of security program |
| CC1.2 | Independence and competence of oversight bodies |
| CC1.3 | Management structure, reporting lines, authorities |
| CC1.4 | Commitment to attract, develop, retain competent personnel |
| CC1.5 | Individuals held accountable for internal control responsibilities |

### CC2 -- Communication and Information

Ensures quality information flows to support internal controls.

| Criterion | Key Controls |
|-----------|-------------|
| CC2.1 | Information required for controls is generated and used |
| CC2.2 | Internal communication of security policies and objectives |
| CC2.3 | External communication with relevant parties |

### CC3 -- Risk Assessment

Identifies and manages risks that could prevent achieving objectives.

| Criterion | Key Controls |
|-----------|-------------|
| CC3.1 | Security objectives defined with sufficient clarity |
| CC3.2 | Risk identification and analysis across the entity |
| CC3.3 | Consideration of fraud risk |
| CC3.4 | Identification and assessment of significant changes |

### CC4 -- Monitoring Activities

Ongoing evaluation of internal controls.

| Criterion | Key Controls |
|-----------|-------------|
| CC4.1 | Monitoring to ascertain controls are functioning |
| CC4.2 | Deficiencies communicated and corrective action taken |

### CC5 -- Control Activities

Policies and procedures that mitigate risks.

| Criterion | Key Controls |
|-----------|-------------|
| CC5.1 | Selection and development of control activities |
| CC5.2 | Technology general controls (ITGC) deployed |
| CC5.3 | Controls deployed through policies and procedures |

### CC6 -- Logical and Physical Access Controls

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

| Criterion | Key Controls |
|-----------|-------------|
| CC6.1 | Logical access security (authentication, SSO, MFA) |
| CC6.2 | User provisioning and deprovisioning |
| CC6.3 | Role-based access, least privilege enforcement |
| CC6.4 | Physical access restrictions to facilities and hardware |
| CC6.5 | Disposal of assets and data |
| CC6.6 | Protection against external threats (firewalls, WAF, DDoS) |
| CC6.7 | Restriction of data transmission (encryption in transit) |
| CC6.8 | Prevention and detection of unauthorized software |

### CC7 -- System Operations

Monitoring and incident management.

| Criterion | Key Controls |
|-----------|-------------|
| CC7.1 | Detection of configuration changes and vulnerabilities |
| CC7.2 | Monitoring for anomalies and security events |
| CC7.3 | Evaluation of detected events as incidents |
| CC7.4 | Incident response execution |
| CC7.5 | Incident recovery and restoration |

### CC8 -- Change Management

Controls over system changes.

| Criterion | Key Controls |
|-----------|-------------|
| CC8.1 | Change authorization, testing, and approval |

### CC9 -- Risk Mitigation

Vendor management and business risk transfer.

| Criterion | Key Controls |
|-----------|-------------|
| CC9.1 | Risk mitigation through business processes |
| CC9.2 | Vendor risk management and assessment |

## Examples

### Example 1: Evidence Collection Automation with Python

```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

```yaml
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)](https://www.aicpa.org/resources/decommissioned/2017-trust-services-criteria) -- Official TSC specification.
- [AICPA SOC 2 Guide](https://www.aicpa.org/topic/audit-assurance/audit-and-assurance-greater-than-soc-2) -- Practitioner guidance.
- [CSA STAR and SOC 2](https://cloudsecurityalliance.org/star) -- Cloud-specific SOC 2 considerations.
- [CIS Controls v8 Mapping to SOC 2](https://www.cisecurity.org/controls) -- Technical control implementation guidance.

<!-- Source: .faos/custom/skills/security/soc2-controls/SKILL.md -->