soc2— agent skill

You are in AUTONOMOUS MODE. Do NOT ask questions. Evaluate, assess, and produce a readiness report.

TARGET: $ARGUMENTS

If no arguments provided, evaluate the entire project in the current working directory against all five SOC 2 Trust Service Criteria.

============================================================ PHASE 0: TECH STACK AND INFRASTRUCTURE DETECTION ============================================================

Auto-detect the project's technology and infrastructure:

APPLICATION LAYER:

• Backend framework and language
• Frontend framework
• Database technology
• Authentication mechanism

INFRASTRUCTURE:

• Cloud provider (AWS, GCP, Azure) — check for config files, SDK imports
• Container orchestration (Docker, Kubernetes) — check for manifests
• CI/CD pipeline (GitHub Actions, GitLab CI, Jenkins) — check workflow files
• Infrastructure as Code (Terraform, CloudFormation, Pulumi) — check configs

INTEGRATIONS:

• Monitoring/alerting services
• Logging infrastructure
• Secret management (Vault, AWS Secrets Manager, etc.)
• Backup services

Record all detected components. SOC2 controls apply across the entire stack.

============================================================ PHASE 1: SECURITY (CC / Common Criteria) ============================================================

Evaluate security controls:

CC6.1 — LOGICAL ACCESS CONTROLS:

• Authentication mechanism exists and enforces strong credentials
• Role-based access control (RBAC) implemented
• Principle of least privilege applied
• Service accounts use minimal permissions
• API authentication on all endpoints

CC6.2 — ACCESS PROVISIONING:

• User registration flow with proper validation
• Admin user management capabilities
• Ability to disable/revoke access
• Access review mechanisms

CC6.3 — ACCESS REMOVAL:

• Account deactivation/deletion capability
• Session invalidation on logout
• Token revocation mechanisms
• Cleanup of associated resources on user removal

CC6.6 — SYSTEM BOUNDARIES:

• Network segmentation (Docker networks, VPC config)
• Firewall rules / security groups defined
• Internal services not exposed publicly
• Rate limiting on public endpoints

CC6.7 — DATA TRANSMISSION:

• TLS/HTTPS enforced for all external communication
• Certificate validation enabled (no rejectUnauthorized: false)
• Sensitive data not transmitted in URL parameters
• WebSocket connections use WSS

CC6.8 — MALICIOUS SOFTWARE PREVENTION:

• Input validation on all user-supplied data
• File upload type and size restrictions
• Dependency vulnerability scanning configured
• No eval() or dynamic code execution with user input

CC7.1 — VULNERABILITY MANAGEMENT:

• Dependency audit tool configured (npm audit, pip-audit, etc.)
• CI pipeline includes security scanning
• Process for addressing reported vulnerabilities

CC7.2 — INCIDENT DETECTION:

• Security event logging (failed logins, access denied, etc.)
• Anomaly detection or alerting configured
• Error monitoring service integrated

CC7.3 — INCIDENT RESPONSE:

• Incident response documentation exists
• Contact information for security issues
• Mechanism to disable compromised accounts/keys

For each control: PASS / PARTIAL / FAIL with evidence and gaps.

============================================================ PHASE 2: AVAILABILITY (A1) ============================================================

Evaluate availability controls:

A1.1 — CAPACITY MANAGEMENT:

• Resource limits configured (memory, CPU, connections)
• Auto-scaling configuration (if cloud-hosted)
• Database connection pooling
• Queue/worker capacity planning

A1.2 — RECOVERY:

• Database backup configuration
• Backup frequency and retention
• Tested restore procedures (documentation)
• Point-in-time recovery capability
• Disaster recovery plan documented

A1.3 — RECOVERY TESTING:

• Evidence of backup restoration tests
• Failover testing documentation
• Recovery time objectives (RTO) defined
• Recovery point objectives (RPO) defined

MONITORING:

• Health check endpoints implemented
• Uptime monitoring configured
• Performance monitoring (response times, error rates)
• Alerting thresholds defined
• Status page or incident communication channel

============================================================ PHASE 3: PROCESSING INTEGRITY (PI) ============================================================

Evaluate processing integrity controls:

PI1.1 — DATA VALIDATION:

• Input validation on API endpoints (type checking, length limits, format)
• Schema validation for data models
• Request payload validation middleware
• Output encoding/sanitization

PI1.2 — ERROR HANDLING:

• Structured error handling (try/catch, error middleware)
• Error responses do not expose internal details
• Failed operations rolled back cleanly
• Partial failure handling (batch operations)

PI1.3 — TRANSACTION LOGGING:

• Critical operations logged with timestamps
• Audit trail for data modifications
• Transaction IDs for traceability
• Immutable log storage (logs cannot be tampered with)

PI1.4 — DATA PROCESSING ACCURACY:

• Idempotent operations (safe to retry)
• Race condition protection (locks, transactions, optimistic concurrency)
• Data transformation validation
• Calculation verification (financial, statistical)

============================================================ PHASE 4: CONFIDENTIALITY (C1) ============================================================

Evaluate confidentiality controls:

C1.1 — DATA CLASSIFICATION:

• Data sensitivity levels defined (public, internal, confidential, restricted)
• PII fields identified and labeled
• Classification applied to database schemas
• Different handling based on classification level

C1.2 — ENCRYPTION AT REST:

• Database encryption enabled
• File storage encryption enabled
• Field-level encryption for highly sensitive data
• Encryption key management (rotation, access control)

C1.3 — ENCRYPTION IN TRANSIT:

• TLS 1.2+ enforced
• HSTS headers configured
• Certificate management process
• Internal service communication encrypted

C1.4 — ACCESS LOGGING:

• Data access logged (who accessed what, when)
• Admin actions logged
• API access logging
• Log retention policy

C1.5 — SECURE DISPOSAL:

• Data deletion actually removes data (not just soft delete)
• Secure wipe for sensitive data
• Media disposal procedures (for physical infrastructure)
• Backup expiry aligned with retention policy

============================================================ PHASE 5: PRIVACY (P1) ============================================================

Evaluate privacy controls:

P1.1 — NOTICE:

• Privacy policy accessible and up to date
• Data collection notice at point of collection
• Cookie notice/consent mechanism

P2.1 — CONSENT:

• Explicit consent obtained for data processing
• Separate consent for separate purposes
• Consent withdrawal mechanism
• Consent records maintained

P3.1 — COLLECTION LIMITATION:

• Data minimization practiced (collect only what is needed)
• Purpose limitation (data used only for stated purpose)
• Collection points documented

P4.1 — USE/RETENTION/DISPOSAL:

• Retention periods defined per data category
• Automated data expiry mechanisms
• Purpose limitation on data use
• Disposal procedures implemented

P5.1 — ACCESS:

• Users can access their data
• Data export in machine-readable format
• Response time for data requests defined

P6.1 — DISCLOSURE:

• Third-party data sharing documented
• Data processing agreements in place
• Cross-border transfer safeguards

P7.1 — QUALITY:

• Users can correct their data
• Data validation at entry
• Duplicate detection mechanisms

P8.1 — MONITORING AND ENFORCEMENT:

• Privacy incident response process
• Privacy impact assessments for new features
• Regular privacy reviews scheduled

============================================================ SELF-HEALING VALIDATION (max 2 iterations) ============================================================

After producing the security analysis, validate thoroughness:

1. Verify every category in the audit was actually checked (not skipped).
2. Verify every finding has a specific file:line location.
3. Verify severity ratings are justified by impact assessment.
4. Verify no false positives by re-reading flagged code in context.

IF VALIDATION FAILS:

• Re-audit skipped categories or vague findings
• Verify or remove false positives
• Repeat up to 2 iterations

============================================================ OUTPUT ============================================================

SOC2 Readiness Report

Project: [name] Stack: [detected technologies] Assessment Date: [date]

Executive Summary

Overall Readiness: [NOT READY / PARTIAL / READY]

Detailed Control Assessment

#### Security Controls

[Repeat for each control across all criteria]

Critical Gaps (must fix before audit)

[Ordered list of FAIL items with remediation effort estimates]

Partial Controls (should improve)

[List of PARTIAL items with specific improvement steps]

Remediation Roadmap

Evidence Collection Checklist

• [ ] Access control policies documented
• [ ] Encryption configuration documented
• [ ] Incident response plan written
• [ ] Backup and recovery procedures tested
• [ ] Change management process documented
• [ ] Vendor management (third-party DPAs)
• [ ] Employee security awareness training
• [ ] Penetration test results (annual)

============================================================ NEXT STEPS ============================================================

After reviewing the readiness report:

• "Fix critical gaps identified in the Security (CC) section first."
• "Run /encryption to address Confidentiality (C1) encryption gaps."
• "Run /gdpr for deeper Privacy (P1) compliance assessment."
• "Run /pentest to generate evidence for CC7.1 vulnerability management."
• "Run /secure for a technical security baseline before SOC2 prep."
• "Engage a SOC2 auditor once all P0 gaps are remediated."

============================================================ SELF-EVOLUTION TELEMETRY ============================================================

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

• Look for the project path in ~/.claude/projects/
• If found, append to skill-telemetry.md in that memory directory

Entry format:

### /soc2 — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.

============================================================ DO NOT ============================================================

• Do NOT modify any code — this is an assessment skill, not an implementation skill.
• Do NOT claim SOC2 certification or compliance — only assess readiness.
• Do NOT provide legal or audit advice — focus on technical controls.
• Do NOT skip any Trust Service Criteria — assess all five.
• Do NOT mark a control as PASS without finding concrete evidence in the codebase.
• Do NOT conflate "not applicable" with "PASS" — mark N/A separately with justification.
• Do NOT assess organizational controls (HR policies, training) — focus on what is visible in code and config.