SOC 2 Readiness skill for Claude Code
Controls engineers actually run, with evidence on tap. Claude scopes the system and criteria, runs a gap assessment against the engineering controls auditors sample, and builds what is missing: SSO and MFA, leaver checks, quarterly access reviews, branch rulesets and pipeline-only deploys, logging and restore tests. Evidence is pulled by scripts from GitHub, the IdP and cloud APIs. It is engineering guidance, not audit or legal advice.
- name
soc2-readiness - size164 lines · ≈2,550 tokens
- files2
- licenseMIT
- updated
What Claude sees before loading it
This description is the only part of the skill that sits in context all the time. Claude reads it to decide when to load the full playbook below.
description: Builds the engineering side of SOC 2 readiness - scoping the system and Trust Services Criteria, gap assessment, SSO and MFA, quarterly access reviews, joiner-mover-leaver deprovisioning, change management with branch protection and deploy pipelines, centralized logging, vulnerability SLAs, backups and restore tests, and automated, timestamped evidence collection for Type I and Type II audits. Use when a customer asks for a SOC 2 report, when preparing for an auditor, setting up Vanta or Drata, or writing control evidence scripts. Not audit or legal advice.Try asking
- A customer needs our SOC 2 Type II in six months. What do we need to build first?
- Write a script that pulls change-management evidence from GitHub for the Q3 audit window
- Set up a quarterly access review process for AWS, GitHub and our database
Use it when
- A deal or security questionnaire requires a SOC 2 report
- An auditor sent a request list and evidence is scattered
- You are configuring Vanta, Drata, or Secureframe integrations
- Engineering needs to define change management and access controls it can actually follow
Skip it when
- You need the security event logging pipeline itself — use security-logging instead
- The question is GDPR or CCPA data handling — use gdpr-privacy instead
How to check the result
Pull a random sample from each population (merged PRs, hires, leavers, reviews, restore tests) and produce dated, system-generated evidence for each within 15 minutes.
The common mistake it prevents
Writing policies with frequencies the team cannot meet, such as monthly reviews done quarterly, which turns every missed occurrence into a Type II exception.
--- name: soc2-readiness description: Builds the engineering side of SOC 2 readiness - scoping the system and Trust Services Criteria, gap assessment, SSO and MFA, quarterly… license: MIT ---
Readiness is done when every in-scope control has an owner, runs on a schedule, and produces system-generated, timestamped evidence that a sampled auditor request can be answered in minutes, and when the controls you describe match what engineers actually do. Writing policies the team does not follow is how Type II reports get exceptions.
This skill is engineering guidance, not audit, legal, or accounting advice. Only a licensed CPA firm issues a SOC 2 report and decides whether a control is designed and operating effectively. Confirm scope, control wording, and evidence expectations with your auditor before the observation window starts.
Ground rules
- Describe controls you already operate or will operate from day one of the window. Aspirational controls become exceptions.
- Prefer automated evidence pulled from the source system (GitHub, IdP, cloud APIs) over screenshots. Keep the raw export plus the date and the query used.
- Changes to production access, branch protection, or logging config are themselves changes: route them through the same change process.
- Do not weaken a control to make evidence easier (e.g. disabling required reviews for a bot) without recording the exception and its compensating control.
Workflow
- [ ] 1. Scope: system boundary, Trust Services Criteria, report type, timeline
- [ ] 2. Inventory systems, data flows, vendors, and people with production access
- [ ] 3. Gap assessment against the control list below
- [ ] 4. Implement or fix controls (engineering backlog with owners)
- [ ] 5. Automate evidence collection and a monthly self-check
- [ ] 6. Readiness review (internal or auditor), then Type I or start the Type II window
- [ ] 7. Operate: run recurring controls on schedule, track exceptions1. Scope decisions
| Decision | Default | Notes |
|---|---|---|
| Criteria | Security (Common Criteria) only | Add Availability if customers ask about uptime SLAs; Confidentiality if you hold customer confidential data under NDA; Privacy and Processing Integrity rarely needed first |
| Report type | Type I first if a deal needs something in weeks; otherwise go straight to a Type II window | Type I = design at a point in time; Type II = operating effectiveness over a period |
| Observation window | 3 months for a first Type II, then 12-month cycles | Agree with the auditor; the window cannot start before controls run |
| System boundary | The production service customers use, its infra, CI/CD, and the people and tools that can change it | Exclude internal tools that never touch customer data, and document why |
| Subservice orgs | Carve-out (AWS, GCP, Azure, Stripe, etc.) | Collect their SOC 2 reports yearly; list complementary controls you rely on |
2. Inventory
Produce and keep current (these become audit populations):
- System list: production accounts/projects, databases, CI/CD, IdP, code hosting, logging, ticketing, endpoint management.
- People list from HR: employees and contractors with start and end dates.
- Access list: who has production, cloud admin, database, and code-merge rights.
- Vendor list with data shared, criticality, and their latest SOC 2 or equivalent.
- Data flow diagram of customer data (reuse threat-modeling output if it exists).
3–4. Engineering control set
| Area | Control that auditors expect to see operating | Typical implementation |
|---|---|---|
| Identity | SSO for all in-scope systems; MFA enforced (phishing-resistant for admins) | Okta, Google Workspace, Entra ID; SCIM provisioning |
| Joiner/leaver | Access granted on ticket with approval; removed within a defined time (e.g. 24 h) of termination | HRIS to IdP automation; leaver checklist ticket |
| Access reviews | Quarterly review of production and admin access by the system owner, with removals tracked | Export from IdP and cloud, reviewer sign-off in ticket |
| Least privilege | No shared accounts; production access via role assumption, time-bound, logged | AWS IAM Identity Center, break-glass account with alerting |
| Change management | All production changes via PR with at least one reviewer who is not the author; CI passes; deploys only through pipeline | Branch protection or rulesets on default branch, CODEOWNERS, deploy role only for CI |
| Emergency change | Documented path for hotfixes with retrospective review within N business days | Label emergency, post-merge review ticket |
| Logging and monitoring | Central logs for infra, app auth events, admin actions; retention set (often 1 year); alerts routed on-call | CloudTrail org trail, SIEM or log platform, PagerDuty |
| Vulnerability management | Dependency and image scanning; remediation SLAs by severity; annual penetration test | Dependabot/Trivy + vulnerability-triage SLAs |
| Encryption | TLS in transit; encryption at rest for databases, buckets, backups; key management | KMS defaults; TLS 1.2+ |
| Backups and DR | Automated backups; restore test at least annually (quarterly is better); documented RTO/RPO | Snapshot policies; restore test ticket with timing |
| Incident response | Written plan; tabletop exercise annually; incidents tracked with postmortems | incident-response runbook, ticket per incident |
| Endpoints | Company devices with disk encryption, screen lock, OS updates, MDM | Jamf, Kandji, Intune; MDM compliance report |
| Secure SDLC | Secrets scanning, code review, security training for engineers | gitleaks in CI; annual training record |
| Vendor management | Risk review before onboarding; annual review of critical vendors | Vendor tracker with report dates |
| Risk assessment | Annual risk assessment with treatment decisions | Risk register reviewed by leadership |
Non-engineering controls (board oversight, HR background checks, policy acknowledgment, code of conduct) are usually owned by operations or a compliance platform; list them so they are not forgotten.
For the criterion-by-criterion map of controls to evidence and automation sources, read references/control-evidence-map.md when building the control matrix or answering an auditor request list.
5. Evidence automation
Evidence an auditor can trust is complete (whole population), system-generated, and dated. Script the pulls and run them monthly; store outputs in a write-once location (e.g. a versioned bucket with object lock, or the compliance platform).
# Change management: branch protection or rulesets on default branches
gh api repos/ORG/REPO/branches/main/protection > evidence/$(date +%F)-REPO-branch-protection.json
gh api repos/ORG/REPO/rulesets > evidence/$(date +%F)-REPO-rulesets.json
# Population of merged PRs in the window, with review decision (sampling source)
gh pr list -R ORG/REPO --state merged --limit 1000 \
--search "merged:2026-07-01..2026-09-30" \
--json number,title,author,mergedAt,mergedBy,reviewDecision \
> evidence/2026Q3-REPO-merged-prs.json
jq '[.[] | select(.reviewDecision != "APPROVED")] | length' evidence/2026Q3-REPO-merged-prs.json
# Cloud: audit trail on, MFA and key age
aws cloudtrail describe-trails --query 'trailList[].[Name,IsMultiRegionTrail,IsOrganizationTrail]' > evidence/$(date +%F)-cloudtrail.json
aws iam generate-credential-report >/dev/null; sleep 5
aws iam get-credential-report --query Content --output text | base64 --decode > evidence/$(date +%F)-iam-credential-report.csvLeaver check (run weekly): compare the HR termination list with active accounts in the IdP, cloud, code host, and any system not behind SSO. Any terminated person still active past the SLA is an exception; remove access, then record the date and reason.
Compliance platforms (Vanta, Drata, Secureframe and similar) connect to these sources and track tests continuously. They reduce manual pulls but do not operate controls for you; still run access reviews and restore tests as real work.
6. Readiness review
Simulate the auditor: pick a random sample from each population (5 merged PRs, 2 new hires, 2 leavers, 1 quarterly review, 1 restore test, 1 incident) and produce the evidence for each in under 15 minutes. Anything you cannot produce is a gap.
7. Operate
Put recurring controls on a calendar with owners: weekly leaver check, monthly evidence pull, quarterly access review, annual pentest, risk assessment, tabletop, restore test, vendor review, policy review, training. Missed occurrences inside the window become exceptions in the report; record and remediate them rather than backfilling.
Output: control matrix row
| ID | Criterion | Control description (as operated) | Owner | Frequency | Evidence | Source/automation | Status |
|---|---|---|---|---|---|---|---|
| CHG-01 | CC8.1 | PRs to main in prod repos require 1 approving review from a non-author and passing CI; enforced by ruleset | Eng lead | Continuous | Ruleset JSON; merged PR population with reviewDecision | gh api monthly job | Operating |Gotchas
- Admins able to bypass branch protection is fine only if bypasses are logged and reviewed; otherwise the control is not enforced. Check ruleset bypass actors.
- Direct database edits and console changes in production are changes too; either route them through tickets or restrict the access that allows them.
- Service accounts and bots count in access reviews; unowned keys are a common finding.
- Evidence screenshots without visible date, system, and URL are often rejected.
- Policy says “quarterly” but the review happened in month 4: that is an exception. Write frequencies you can meet.
- Scope creep: every system in the boundary multiplies evidence work. Keep the boundary as small as the customer promise allows.
Verification
- Every control in the matrix has an owner, frequency, and at least one stored evidence artifact from the current period.
- The random-sample drill passes for every population.
- The merged-PR population shows zero unapproved merges, or each one maps to an emergency change ticket with a retrospective review.
- The leaver check shows no active accounts for people terminated beyond the SLA.
Bundled files
Loaded only when a step in the skill needs them. Review them here before installing.
references/control-evidence-map.md
# Control to evidence map (engineering-owned criteria)
Mapping of the 2017 Trust Services Criteria (with the 2022 revised points of focus) to
typical engineering controls, the evidence an auditor usually samples, and where to pull
it automatically. Criterion numbering and the exact evidence your auditor accepts vary;
treat this as a starting matrix to confirm with them, not as audit guidance.
## How to read it
- **Population**: the complete list the auditor samples from. You must be able to
export it for the whole observation window.
- **Evidence**: what one sampled item needs to show.
- **Source**: the system of record to automate the pull from.
## CC1–CC5: governance (mostly non-engineering)
| Criterion | Engineering contribution | Evidence | Source |
|---|---|---|---|
| CC1 control environment | Engineering onboarding includes security responsibilities; background checks for prod-access roles | Signed policy acknowledgments; training completion | HRIS, LMS, compliance platform |
| CC2 communication | Security policies published internally; customer-facing security page and status page | Policy repo or wiki with version history; status page | Wiki, Git |
| CC3 risk assessment | Annual risk assessment including technical risks and fraud; threat models for major features | Risk register with dates and treatment; threat model docs | Ticketing, docs repo |
| CC4 monitoring of controls | Monthly control self-checks; tracking of exceptions to closure | Self-check outputs; exception tickets | Evidence job logs, compliance platform |
| CC5 control activities | Controls documented with owners and frequencies | Control matrix | Compliance platform or repo |
## CC6: logical and physical access
| Criterion focus | Control | Population | Evidence per sample | Source |
|---|---|---|---|---|
| CC6.1 access security architecture | SSO + MFA for in-scope systems; prod access via roles; encryption keys managed in KMS | In-scope system list | IdP app config showing SSO enforced; MFA policy export; KMS key policy | IdP admin API, cloud APIs |
| CC6.2 provisioning | Access requested and approved before granted | New hires and access grants in window | Ticket with approver and timestamp before account creation date | Ticketing + IdP system log |
| CC6.2/6.3 deprovisioning | Access removed within SLA after termination or role change | Terminations in window | Termination date (HR) vs deactivation timestamp (IdP, cloud, code host) | HRIS export, IdP system log |
| CC6.3 periodic review | Quarterly review of privileged and production access | Review occurrences in window | Reviewer, date, list reviewed, removals completed | Ticket per review with export attached |
| CC6.6 boundary protection | Network controls; no public admin ports; WAF where applicable | Security groups / firewall rules | Rule export; CSPM report | Cloud APIs, Prowler |
| CC6.7 data in transit and removable media | TLS enforced; endpoint disk encryption | Endpoints; public endpoints | TLS config scan; MDM encryption report | MDM, TLS scanner |
| CC6.8 malicious software | Endpoint protection; dependency and image scanning in CI | Endpoints; repos | MDM/EDR compliance; CI scan config and recent runs | MDM/EDR, CI |
## CC7: system operations
| Criterion focus | Control | Population | Evidence per sample | Source |
|---|---|---|---|---|
| CC7.1 config and vulnerability detection | Scanning of dependencies, images, cloud config; remediation SLAs | Findings opened in window | Finding, priority, fix date within SLA or approved exception | Scanner, ticketing |
| CC7.1 | Annual penetration test with remediation | Pentest reports | Report date, findings, fix tickets | Vendor report |
| CC7.2 monitoring | Centralized logging, alerting on security events | Alert rules; alerts fired | Rule config; sample alert with response | SIEM/log platform, paging tool |
| CC7.3–7.4 incident response | Incidents triaged, tracked, communicated, reviewed | Incidents in window | Incident ticket, timeline, postmortem, customer notice if required | Ticketing, postmortem docs |
| CC7.5 recovery | Restore from backup tested | Restore tests | Ticket with date, dataset, duration, success | Ticketing, backup logs |
## CC8: change management
| Criterion focus | Control | Population | Evidence per sample | Source |
|---|---|---|---|---|
| CC8.1 authorized changes | PR review by non-author; CI checks pass; deploy only via pipeline | Merged PRs to prod repos; deployments | PR with approval before merge, CI status, linked deploy | `gh pr list --json ...`, CI/CD logs |
| CC8.1 enforcement | Branch protection or rulesets configured | Prod repos | Ruleset/protection JSON per repo, bypass list | `gh api` |
| CC8.1 emergency changes | Expedited path with retrospective review | Emergency-labeled PRs | Post-merge review within defined days | Ticketing, GitHub labels |
| CC8.1 infrastructure changes | IaC through PR; console changes restricted and logged | IaC PRs; CloudTrail write events by humans | PR evidence; CloudTrail query of console writes | Git, CloudTrail |
## CC9: risk mitigation
| Criterion focus | Control | Evidence | Source |
|---|---|---|---|
| CC9.1 business disruption | DR plan with RTO/RPO; multi-AZ or documented single points of failure | DR plan; architecture doc; DR test record | Docs, ticketing |
| CC9.2 vendors | Vendor risk review at onboarding and annually; SOC 2 reports of subservice orgs collected | Vendor tracker; downloaded reports with dates; CUEC review | Compliance platform, vendor portals |
## Availability (A1) if in scope
| Criterion focus | Control | Evidence |
|---|---|---|
| A1.1 capacity | Capacity monitoring and alerts; autoscaling | Dashboards, alert configs |
| A1.2 backups and environmental protections | Automated backups, retention, cross-region copies | Backup policy export, recent job logs |
| A1.3 recovery testing | Periodic restore and failover tests | Test tickets with results |
## Confidentiality (C1) if in scope
| Criterion focus | Control | Evidence |
|---|---|---|
| C1.1 identify and protect confidential info | Data classification; access restricted to need | Classification policy; access lists |
| C1.2 disposal | Customer data deleted on contract end within defined time | Deletion tickets, job logs |
## Common auditor request list (prepare these exports)
1. Full list of employees and contractors with start/end dates (HR).
2. User list for each in-scope system with role and last login (IdP, cloud, Git host, database).
3. All merged PRs to production repos in the window with reviewers.
4. All production deployments in the window.
5. All security incidents and postmortems.
6. Vulnerability findings with dates opened and closed.
7. Access review records for each quarter.
8. Backup configuration and restore test records.
9. Vendor list with SOC 2 report dates.
10. Policies with approval dates and employee acknowledgments.
About this skill
Written and maintained by the Claude Skills editors to the same editorial standard as every skill in the directory: a selective trigger, a real workflow, known pitfalls and a verification step. First published , last updated . MIT licensed.