soc2-compliance

name	soc2-compliance
description	Implement SOC 2 Trust Services Criteria. Configure security, availability, and processing integrity controls. Use when achieving SOC 2 certification.
license	MIT
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

Trust Services Criteria Detailed Checklist

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

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
      -   
         

  
    
              
              
            
           
    
           
          
            

  
    
          
            
         
        
    
            
         
             

Evidence Collection Automation

#!/usr/bin/env bash
# collect-soc2-evidence.sh - Automated SOC 2 evidence collection
# Run monthly or before audit requests

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 members and roles
gh api orgs/YOUR_ORG/members --paginate --jq '.[] | [.login, .role_name // "member"] | @csv' \
  > "$EVIDENCE_DIR/github-org-members.csv"


 repo  $(gh repo list YOUR_ORG --json name -q ); 
  gh api repos/YOUR_ORG//branches/main/protection \
    >  2>/dev/null


 


aws cloudtrail get-trail-status --name org-audit-trail \
  > 


aws cloudwatch describe-alarms --state-value ALARM \
  > 


aws guardduty list-findings --detector-id DETECTOR_ID \
  --finding-criteria  \
  > 

 


gh run list --repo YOUR_ORG/YOUR_REPO -- 50 --json conclusion,createdAt,displayTitle,headBranch \
  > 


gh  list --repo YOUR_ORG/YOUR_REPO --state merged -- 100 \
  --json number,title,author,mergedBy,mergedAt,reviews \
  > 

 


aws rds describe-db-snapshots --db-instance-identifier prod-db \
  --query  \
  > 


aws s3api get-bucket-replication --bucket prod-data-bucket \
  > 

 
tar -czf  
 

Audit Preparation Timeline

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  

  
           
          
           
          
          

  
         
         
          
          
          

  
          
         
        
          

  
           
          
        
           
          

Continuous Compliance Monitoring

# 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:
      - name: Check MFA enforcement
        run: |
          USERS_WITHOUT_MFA=$(aws iam generate-credential-report && sleep 5 && \
            aws iam get-credential-report --output text --query Content | \
            base64 -d | awk -F, '$4=="true" && $8=="false" {print $1}')
          if [ -n "$USERS_WITHOUT_MFA" ]; then
            echo "::error::Users without MFA: $USERS_WITHOUT_MFA"
            exit 1
          fi

      - name: Check for unused credentials
        run: |
          THRESHOLD=$(date -d '90 days ago' +%Y-%m-%dT%H:%M:%S)
          aws iam get-credential-report --output text --query Content | \
            base64 -d | awk -F, -v t="$THRESHOLD" '$5!="N/A" && $5<t {print $1" last used "$5}'

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

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