SOC 2 Compliance

---
name: soc2-compliance
description: Implement SOC 2 Trust Services Criteria. Configure security, availability,
  and processing integrity controls. Use when preparing for a SOC 2 examination.
category: security
risk: safe
source: https://github.com/BagelHole/DevOps-Security-Agent-Skills
source_repo: BagelHole/DevOps-Security-Agent-Skills
source_type: community
date_added: '2026-09-20'
license: MIT
license_source: https://github.com/BagelHole/DevOps-Security-Agent-Skills/blob/main/LICENSE
compatibility: Checklist and framework guidance; no privileged tooling required. Apply
  controls through your own change process.
metadata:
  author: devops-skills
  version: '1.0'
---

# SOC 2 Compliance

Implement SOC 2 Trust Services Criteria controls, evidence collection, and continuous compliance monitoring for Type I and Type II audits.

## When to Use

- Preparing for a SOC 2 Type I or Type II audit
- Mapping existing controls to Trust Services Criteria
- Automating evidence collection for auditor requests
- Building continuous compliance monitoring into CI/CD
- Onboarding new services and ensuring SOC 2 control coverage

SOC 2 is an independent CPA examination/report, not a product certification. Type I addresses design at a specified date; Type II also addresses operation over a period. Agree system boundaries, applicable categories, criteria and evidence period with the auditor. This abbreviated mapping omits criteria and is not a complete authoritative checklist.

## Trust Services Criteria Detailed Checklist

```yaml
security_common_criteria:
  CC1_control_environment:
    CC1.1: "Management demonstrates commitment to integrity and ethical values"
    CC1.2: "Board exercises oversight of internal controls"
    CC1.3: "Management establishes structure, authority, and responsibility"
    CC1.4: "Commitment to competence - hire and retain qualified personnel"
    CC1.5: "Individuals are held accountable for internal control responsibilities"
    evidence:
      - Code of conduct document
      - Organizational chart
      - Job descriptions with security responsibilities
      - Board meeting minutes discussing security
      - Background check policy and records

  CC2_communication:
    CC2.1: "Entity obtains or generates relevant quality information"
    CC2.2: "Entity internally communicates information including objectives and responsibilities"
    CC2.3: "Entity communicates with external parties"
    evidence:
      - Security awareness training records
      - Internal security newsletters or updates
      - Customer-facing security documentation
      - Status page and incident communication records

  CC3_risk_assessment:
    CC3.1: "Entity specifies objectives clearly to identify and assess risks"
    CC3.2: "Entity identifies risks to achievement of objectives"
    CC3.3: "Entity considers potential for fraud"
    CC3.4: "Entity identifies and assesses significant changes"
    evidence:
      - Annual risk assessment report
      - Risk register with ratings and treatment plans
      - Fraud risk assessment documentation
      - Change management records

  CC4_monitoring:
    CC4.1: "Entity selects, develops, and performs ongoing/separate evaluations"
    CC4.2: "Entity evaluates and communicates internal control deficiencies"
    evidence:
      - Continuous monitoring dashboard screenshots
      - Internal audit reports
      - Vulnerability scan results
      - Penetration test reports

  CC5_control_activities:
    CC5.1: "Entity selects and develops control activities to mitigate risks"
    CC5.2: "Entity selects and develops technology-based controls"
    CC5.3: "Entity deploys control activities through policies and procedures"
    evidence:
      - Information security policy
      - Access control procedures
      - Change management procedures
      - Encryption standards documentation

  CC6_logical_access:
    CC6.1: "Logical access security over protected information assets"
    CC6.2: "Prior to access, users are registered and authorized"
    CC6.3: "Access to data, software, functions, and other IT resources is authorized and modified"
    CC6.6: "Logical access security measures against threats from outside system boundaries"
    CC6.7: "Transmission of data between parties is protected"
    CC6.8: "Controls to prevent or detect unauthorized or malicious software"
    evidence:
      - IAM credential report
      - MFA enforcement configuration
      - Access review completion records
      - Firewall and WAF configurations
      - TLS/encryption configurations
      - Endpoint protection deployment records

  CC7_system_operations:
    CC7.1: "Detect anomalies and potential security incidents"
    CC7.2: "Monitor system components for anomalies"
    CC7.3: "Evaluate detected events and determine incidents"
    CC7.4: "Respond to identified security incidents"
    CC7.5: "Identify and remediate security incidents"
    evidence:
      - SIEM alert rules and dashboards
      - Monitoring configuration (CloudWatch, Datadog, etc.)
      - Incident response plan
      - Incident tickets and post-mortems

  CC8_change_management:
    CC8.1: "Entity authorizes, designs, develops, configures, documents, tests, approves, and implements changes"
    evidence:
      - Change management policy
      - Pull request approval requirements
      - CI/CD pipeline configurations
      - Deployment records with approvals

  CC9_risk_mitigation:
    CC9.1: "Entity identifies, selects, and develops risk mitigation activities"
    CC9.2: "Entity assesses and manages risks associated with vendors"
    evidence:
      - Risk treatment plans
      - Vendor assessment records
      - Business associate agreements
      - Insurance certificates

availability_criteria:
  A1.1: "System processing capacity and availability are maintained"
  A1.2: "Environmental protections and recovery measures"
  A1.3: "Recovery plan procedures to support system availability"
  evidence:
    - Uptime SLA documentation
    - Capacity monitoring dashboards
    - Disaster recovery plan
    - DR test results
    - Backup verification records

processing_integrity_criteria:
  PI1.1: "Entity obtains or generates, uses, and communicates quality information"
  evidence:
    - Input validation procedures
    - Data processing accuracy checks
    - Error handling and retry logic documentation
    - Output reconciliation records

confidentiality_criteria:
  C1.1: "Entity identifies and maintains confidential information"
  C1.2: "Entity disposes of confidential information"
  evidence:
    - Data classification policy
    - Encryption configurations
    - Data retention and destruction policies
    - Secure disposal records

privacy_criteria:
  P1-P8: "Privacy notice, choice, collection, use, disclosure, access, quality, monitoring"
  evidence:
    - Privacy policy (published)
    - Consent management records
    - Data processing inventory
    - DSAR handling procedures
```

## Tool Mappings for Control Evidence

```yaml
control_to_tool_mapping:
  CC6.1_logical_access:
    aws:
      - IAM credential report (aws iam generate-credential-report)
      - IAM Access Analyzer findings
      - AWS SSO configuration
      - GuardDuty findings
    azure:
      - Azure AD sign-in logs
      - Conditional Access policies
      - PIM role assignments
    github:
      - Organization member list and roles
      - Repository access permissions
      - Branch protection rules
    okta:
      - User status report
      - MFA enrollment report
      - Application assignment report

  CC7.2_monitoring:
    tools:
      - CloudWatch / Azure Monitor / Cloud Monitoring dashboards
      - Datadog / New Relic / Grafana alert configurations
      - SIEM (Splunk, Elastic, Sentinel) saved searches
      - PagerDuty / OpsGenie escalation policies
    evidence_format:
      - Dashboard screenshots with date stamps
      - Alert rule configuration exports
      - Incident response records from ticketing system

  CC8.1_change_management:
    tools:
      - GitHub/GitLab PR merge requirements
      - CI/CD pipeline configurations (GitHub Actions, Jenkins)
      - Terraform plan outputs
      - Deployment logs
    evidence_format:
      - PR with approvals and CI checks
      - Deployment audit trail
      - Change advisory board meeting notes (if applicable)
```

## Evidence Collection Automation

```bash
#!/usr/bin/env bash
# collect-soc2-evidence.sh - Automated SOC 2 evidence collection
# Run monthly or before audit requests in the approved accounts/regions only.
set -euo pipefail
umask 077

EVIDENCE_DIR="./soc2-evidence/$(date +%Y-%m)"
mkdir -p "$EVIDENCE_DIR"

echo "=== CC6.1 - Logical Access Evidence ==="

# AWS IAM credential report
aws iam generate-credential-report
sleep 10
aws iam get-credential-report --output text --query Content | \
  base64 -d > "$EVIDENCE_DIR/aws-iam-credential-report.csv"

# AWS IAM Access Analyzer findings
aws accessanalyzer list-findings \
  --analyzer-arn "arn:aws:access-analyzer:us-east-1:123456789012:analyzer/org-analyzer" \
  --filter '{"status": {"eq": ["ACTIVE"]}}' \
  > "$EVIDENCE_DIR/access-analyzer-findings.json"

# MFA enforcement status
aws iam list-users --query 'Users[*].UserName' --output text | \
  tr '\t' '\n' | while read -r user; do
    mfa=$(aws iam list-mfa-devices --user-name "$user" --query 'MFADevices[0].SerialNumber' --output text)
    echo "$user,$mfa"
  done > "$EVIDENCE_DIR/mfa-status.csv"

# GitHub organization membership only; this endpoint does not establish member/admin roles.
# Collect authorized per-member membership-role evidence separately; never default unknown roles to member.
gh api orgs/YOUR_ORG/members --paginate --jq '.[] | [.login] | @csv' \
  > "$EVIDENCE_DIR/github-org-members.csv"

# GitHub branch protection rules
for repo in $(gh repo list YOUR_ORG --json name -q '.[].name'); do
  gh api repos/YOUR_ORG/$repo/branches/main/protection \
    > "$EVIDENCE_DIR/branch-protection-$repo.json"
done

echo "=== CC7.2 - Monitoring Evidence ==="

# CloudTrail status
aws cloudtrail get-trail-status --name org-audit-trail \
  > "$EVIDENCE_DIR/cloudtrail-status.json"

# Active CloudWatch alarms
aws cloudwatch describe-alarms --state-value ALARM \
  > "$EVIDENCE_DIR/active-alarms.json"

# GuardDuty findings summary
aws guardduty list-findings --detector-id DETECTOR_ID \
  --finding-criteria '{"criterion":{"severity":{"gte":4}}}' \
  > "$EVIDENCE_DIR/guardduty-findings.json"

echo "=== CC8.1 - Change Management Evidence ==="

# Recent deployments (GitHub Actions)
gh run list --repo YOUR_ORG/YOUR_REPO --limit 50 --json conclusion,createdAt,displayTitle,headBranch \
  > "$EVIDENCE_DIR/recent-deployments.json"

# Pull requests merged in audit period
gh pr list --repo YOUR_ORG/YOUR_REPO --state merged --limit 100 \
  --json number,title,author,mergedBy,mergedAt,reviews \
  > "$EVIDENCE_DIR/merged-prs.json"

echo "=== A1 - Availability Evidence ==="

# Backup status
aws rds describe-db-snapshots --db-instance-identifier prod-db \
  --query 'DBSnapshots | sort_by(@, &SnapshotCreateTime) | [-5:]' \
  > "$EVIDENCE_DIR/rds-backup-snapshots.json"

# S3 replication status
aws s3api get-bucket-replication --bucket prod-data-bucket \
  > "$EVIDENCE_DIR/s3-replication-config.json"

echo "Evidence collected in $EVIDENCE_DIR"
tar -czf "$EVIDENCE_DIR.tar.gz" "$EVIDENCE_DIR"
echo "Archive: $EVIDENCE_DIR.tar.gz"
```

The examples collect partial evidence, not proof of compliance. Preserve command failures as gaps, use bounded readiness retries for IAM credential-report generation instead of assuming a fixed sleep succeeds, and record collection time/account/region/tool version. API limits and audit-period filters must be expanded for the full population; `--limit 100` and the latest five backups are samples. Do not infer IAM Identity Center MFA, access-key usage, root security, GuardDuty coverage or actual backup restorability from these snippets. Evidence contains sensitive identity/security data: encrypt storage and transfer, restrict auditor access, and follow agreed retention.

## Audit Preparation Timeline

```yaml
audit_prep_timeline:
  12_months_before:
    - Select auditor firm and sign engagement letter
    - Perform gap assessment against TSC criteria
    - Remediate identified control gaps
    - Begin formal evidence collection cadence

  6_months_before:
    - Conduct internal readiness assessment
    - Verify all controls are operating effectively
    - Complete risk assessment and update risk register
    - Ensure vendor assessments are current
    - Test disaster recovery procedures

  3_months_before:
    - Run automated evidence collection and verify completeness
    - Conduct access review and remediate findings
    - Review and update all policies and procedures
    - Perform vulnerability scan and penetration test
    - Confirm all training records are current

  1_month_before:
    - Prepare evidence request list responses
    - Organize evidence into auditor-friendly structure
    - Brief key personnel on audit interviews
    - Verify monitoring dashboards show healthy state
    - Confirm incident response records are complete

  during_audit:
    - Designate audit liaison for request management
    - Provide timely evidence and clarifications
    - Track open auditor questions
    - Escalate issues to control owners promptly

  after_audit:
    - Review draft report and provide management response
    - Create remediation plan for any exceptions
    - Communicate results to stakeholders
    - Update controls and processes based on findings
    - Begin next audit period evidence collection
```

## Continuous Compliance Monitoring

```yaml
# GitHub Actions workflow for continuous SOC 2 checks
name: SOC2 Compliance Checks
on:
  schedule:
    - cron: '0 6 * * 1'  # Weekly on Monday
  workflow_dispatch:

jobs:
  access-review:
    runs-on: ubuntu-latest
    steps:
      # Configure approved AWS OIDC credentials and read-only IAM permissions first.
      # Install a pinned boto3 in the reviewed runner environment first.
      - name: Review credential report without printing identities
        run: |
          python - <<'PYTHON'
          import boto3, csv, io, time
          from datetime import datetime, timedelta, timezone
          iam = boto3.client('iam')
          for attempt in range(15):
              if iam.generate_credential_report()['State'] == 'COMPLETE':
                  break
              time.sleep(2)
          else:
              raise RuntimeError('Credential report not ready')
          report = iam.get_credential_report()['Content'].decode('utf-8')
          rows = list(csv.DictReader(io.StringIO(report)))
          missing_mfa = sum(r['password_enabled'] == 'true' and r['mfa_active'] == 'false' for r in rows)
          threshold = datetime.now(timezone.utc) - timedelta(days=90)
          stale = 0
          for row in rows:
              value = row['password_last_used']
              if row['password_enabled'] == 'true' and value not in ('N/A', 'no_information', 'not_supported'):
                  stale += datetime.fromisoformat(value.replace('Z', '+00:00')) < threshold
          print(f'Console accounts missing MFA: {missing_mfa}; stale recorded password use: {stale}')
          if missing_mfa:
              raise SystemExit(1)
          PYTHON

      - name: Verify CloudTrail is logging
        run: |
          STATUS=$(aws cloudtrail get-trail-status --name org-audit-trail --query 'IsLogging' --output text)
          [ "$STATUS" = "True" ] || (echo "::error::CloudTrail logging stopped" && exit 1)

      - name: Check GuardDuty is enabled
        run: |
          DETECTOR=$(aws guardduty list-detectors --query 'DetectorIds[0]' --output text)
          [ "$DETECTOR" != "None" ] || (echo "::error::GuardDuty not enabled" && exit 1)
```

## Best Practices

- Start with a gap assessment to understand current control maturity before engaging an auditor
- Automate evidence collection to reduce the burden of auditor requests and ensure consistency
- Map each control to a specific tool, owner, and evidence artifact for traceability
- Implement continuous monitoring rather than point-in-time checks for Type II readiness
- Maintain a central evidence repository organized by control criteria
- Conduct quarterly internal reviews to catch control drift before the audit period
- Keep policies living documents with version history and annual review dates
- Train all employees on their role in maintaining SOC 2 controls
- Use the audit preparation timeline to avoid last-minute scrambling
- Treat each auditor exception as an improvement opportunity rather than a failure

## Limitations

- Guidance and checklists only; not legal advice and not a substitute for a qualified auditor.
- Docs-only import: upstream templates and scripts not bundled.

### Example

```markdown
Map this skill's control checklist to our current evidence and list gaps.
```

> Adapted from [BagelHole/DevOps-Security-Agent-Skills](https://github.com/BagelHole/DevOps-Security-Agent-Skills) (MIT); frontmatter, When to Use/Limitations, and safety boundaries added for upstream compliance. Docs-only import: helper scripts and templates not bundled.

Credential report dates/sentinels and aggregate counts need account-level review; federated identities and access keys require separate controls. Credentials configure through approved OIDC, and only aggregate output belongs in public CI logs. The snippet uses boto3-decoded report bytes with a bounded readiness wait and a real CSV parser; it does not execute decoded content.