Use when performing soc2 compliance check — assess SOC2 Type II compliance readiness across Trust Service Criteria: security, availability, processing integrity, confidentiality, and privacy. Covers access controls, change management, monitoring, incident response, and vendor management. Use for audit preparation or continuous compliance monitoring.
Scanned 9/8/2026
Install to Claude Code
npx -y skills add cloudthinker-ai/CloudSkills --skill soc2-compliance-check --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Soc2 Compliance Check?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/cloudthinker-ai-soc2-compliance-check)More formats (shields.io, HTML) on the badges page.
---
name: soc2-compliance-check
enabled: true
description: |
Use when performing soc2 compliance check — assess SOC2 Type II compliance
readiness across Trust Service Criteria: security, availability, processing
integrity, confidentiality, and privacy. Covers access controls, change
management, monitoring, incident response, and vendor management. Use for
audit preparation or continuous compliance monitoring.
required_connections:
- prefix: github
label: "GitHub (or version control)"
config_fields:
- key: organization
label: "Organization Name"
required: true
placeholder: "e.g., Acme Corp"
- key: audit_period
label: "Audit Period"
required: true
placeholder: "e.g., 2025-01-01 to 2025-12-31"
- key: trust_criteria
label: "Trust Service Criteria in Scope"
required: false
placeholder: "e.g., security, availability, confidentiality"
features:
- COMPLIANCE
- SECURITY
---
# SOC2 Compliance Check Skill
Assess SOC2 Type II readiness for **{{ organization }}** covering audit period **{{ audit_period }}**.
## Workflow
### Step 1 — Scope Definition
Establish what is in scope:
1. **Trust Service Criteria**: {{ trust_criteria | "Security (required), Availability, Confidentiality" }}
2. **Systems in scope**: [list services, infrastructure, third-party tools]
3. **Prior audit findings**: [review any open items from previous audit]
### Step 2 — CC6: Logical & Physical Access Controls
```
ACCESS CONTROLS (CC6)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] User access provisioning requires manager approval
[ ] User access reviews conducted quarterly
[ ] Terminated users deprovisioned within 24 hours
[ ] MFA enforced for all production access
[ ] Privileged access limited and logged
[ ] SSH keys / API tokens rotated on schedule
[ ] Physical data center access controlled (if applicable)
[ ] Vendor access reviewed and time-limited
[ ] Role-based access control (RBAC) implemented
```
### Step 3 — CC7: System Operations & Monitoring
```
SYSTEM OPERATIONS (CC7)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Infrastructure monitoring with alerting (uptime, errors, latency)
[ ] Security event monitoring and SIEM in place
[ ] Vulnerability scanning on regular cadence
[ ] Patch management process with defined SLAs
[ ] Capacity monitoring with proactive scaling
[ ] Backup procedures documented and tested
[ ] Backup restoration tested at least annually
[ ] Incident detection within defined time thresholds
```
### Step 4 — CC8: Change Management
```
CHANGE MANAGEMENT (CC8)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] All code changes require peer review (PR approval)
[ ] CI/CD pipeline enforces automated tests before deploy
[ ] Production deployments logged with who/what/when
[ ] Infrastructure changes via IaC (Terraform, CloudFormation)
[ ] Change approval process for production changes
[ ] Separation of duties: developers cannot deploy to production alone
[ ] Rollback procedures documented for all deployments
[ ] Emergency change process defined and documented
```
### Step 5 — Incident Response & Communication
```
INCIDENT RESPONSE (CC7.3-CC7.5)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Incident response plan documented and current
[ ] On-call rotation staffed 24/7
[ ] Incident severity classification defined
[ ] Communication procedures for security incidents
[ ] Post-incident reviews conducted for SEV1/SEV2
[ ] Annual incident response drill or tabletop exercise
[ ] Customer notification process for data breaches
```
### Step 6 — Risk Assessment & Vendor Management
```
RISK & VENDOR MANAGEMENT (CC3, CC9)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[ ] Annual risk assessment conducted
[ ] Risk register maintained with owners and mitigations
[ ] Vendor inventory maintained with criticality ratings
[ ] Critical vendors have SOC2 reports or equivalent
[ ] Vendor access reviewed annually
[ ] Business continuity plan documented
[ ] Data processing agreements in place with vendors
```
### Step 7 — Evidence Collection Checklist
For each control, gather evidence:
- **Access reviews**: Export of quarterly review with approvals
- **Change management**: Sample PRs showing review process
- **Monitoring**: Screenshots of dashboards and alert configurations
- **Incident response**: Post-mortem documents from audit period
- **Vendor management**: Vendor SOC2 reports or security questionnaires
- **Training**: Security awareness training completion records
### Step 8 — Gap Analysis & Remediation
| Control Area | Status | Gaps Found | Remediation | Priority | Owner |
|-------------|--------|------------|-------------|----------|-------|
| Access Controls | READY/GAP | [details] | [action] | P1/P2 | [name] |
| System Operations | READY/GAP | [details] | [action] | P1/P2 | [name] |
| Change Management | READY/GAP | [details] | [action] | P1/P2 | [name] |
| Incident Response | READY/GAP | [details] | [action] | P1/P2 | [name] |
| Risk Management | READY/GAP | [details] | [action] | P1/P2 | [name] |
## Counter-Rationalizations
| Shortcut | Counter | Why |
|----------|---------|-----|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |
## Output Format
Produce a SOC2 readiness report with:
1. **Scope summary** (criteria, systems, audit period)
2. **Control assessment** per Trust Service Category with READY/GAP status
3. **Evidence checklist** with collection status per control
4. **Gap analysis** with prioritized remediation actions
5. **Readiness score** (% of controls audit-ready)
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!