SOC 2 Skills: Three Agent Skills for a Lean Startup

A prospect asks for a SOC 2 report but there isn't one yet.

A common next step is a GRC platform that generates twenty-odd policies in an afternoon, and it is easy to skim them and click approve. Somewhere in that set may be a change advisory board, a SIEM, badge readers, and a separation-of-duties regime, adopted by a team of four engineers who deploy from GitHub. Each sentence in each policy is a promise, and each promise is something an auditor can test. It is possible to make several hundred promises without reading them.

Policies are cheap to write and expensive to prove. That asymmetry is the reason these three Agent Skills exist. They encode the method Adversis uses on lean SOC 2 engagements: policies name controls, procedures name products, nothing is over-documented, nothing is backdated. They are packaged so an agent can walk a team through it in Claude Code or any harness that reads Agent Skills.

Scope is Security (the Common Criteria), Type I first with a runway to Type II. They are written against the 2017 Trust Services Criteria with the 2022 points of focus and were last reviewed in September 2026.

Which direction the program is derived from

A lot of SOC 2 material, and the GRC platforms built on it, runs in one direction: criterion, then a templated control, then a templated policy, then the company is made to conform. That is efficient for the platform. It starts from a predefined framework implementation and links evidence to it afterward.

These skills run the other way: the company as it exists, then its risks, then the controls it genuinely operates, then the evidence those controls produce, then the minimum truthful documentation, and only at the end the mapping to the TSC. The order matters because it changes what gets written down.

Consider a boilerplate policy line:

"Production access is reviewed quarterly by the Security Committee."

It reads well. At a given company there may be no Security Committee, the CTO may review privileged access twice a year, and the auditor now expects four quarterly review artifacts.

That is an audit exception created by writing fiction.

Starting from what the company does, the same control reads "privileged access is reviewed semi-annually by the CTO," which is both true and testable.

The three skills

https://github.com/Adversis/soc2-skills

soc2-readiness authors the program. It handles scoping, which means choosing the TSC, Type I or II, an as-of date, and a system boundary. It replaces templated policies with a short principles-based set, stands up procedures and an evidence trail, makes the vendor and subservice decisions, and reviews the auditor's draft report at the end. It ships a starter pack for a fictional company called ACME: about 17 policies, with procedures, registers, and a system description, plus a REPLACE.md manifest listing every token to fill in.

soc2-audit-prep finalizes the program for the auditor. It builds the control matrix across CC1 through CC9, walks the system description claim by claim against evidence, assembles the evidence repository dated to the as-of date, and runs seven go-live gates before hand-off. The control-matrix.csv comes seeded with about 35 controls. Each row maps a criterion to a control, an owner, a cadence, a population, the evidence, the evidence date, and a status.

vendor-risk-analyzer is the consumer side. Given another company's SOC 2 report and its MSA, DPA, or BAA, it produces a threat-modeled risk assessment: subservice carve-outs, the complementary user entity controls the customer is responsible for, breach notification terms, and the attack paths relevant to the integration. It is the mirror image of the other two.

soc2-readiness/         SKILL.md · references/ · templates/{evidence-index.md, starter-pack/}

soc2-audit-prep/        SKILL.md · references/ · templates/control-matrix.csv

vendor-risk-analyzer/   SKILL.md · references/threat-model-index.md

Policies, procedures, and the evidence question

Policies and procedures change at different rates, which is the reason to keep them apart. An access control policy that says "Okta" has to change when the company moves to Google Workspace, with a version bump and an explanation to the auditor.

A policy that says "a centralized identity provider with MFA enforced," with Okta named only in the onboarding procedure, does not change. The control survives the tooling swap. An auditor tests the control, not the vendor.

The second idea is that the control matrix, rather than the policy set or a GRC dashboard, is the source of truth. A policy says what a company intends. The matrix says what it can prove. Every control in it has to answer one question before it is accepted: what exact artifact would be handed to an auditor to show this happened? Plenty of SOC 2 content lists controls a company "needs" without forcing that question. The answers are ordinary things: an MFA enforcement setting, reviewed pull requests, branch protection rules, an access population export, termination tickets or a signed statement that there were none, a device inventory, backup restore logs. "We comply with CC6" is a sentence. A dated screenshot is evidence.

A resource that pairs well here, with no affiliation to Adversis, is the Chiaro methodology published by Y Assurance PLLC at github.com/Chiaro-HQ/methodology under CC BY 4.0. It publishes 89 controls and 369 test attributes, each with acceptable evidence, pass criteria for point-in-time versus period testing, conditions under which a test does not apply, Type II population and sampling rules, and 552 worked judgment examples. These skills decide what a lean program should say. Chiaro is a useful reference for how an auditor might test it.

The same goes for adjacent tools. Teams that want a broad policy library will find more mature projects. Teams that want Git-native GRC operations will find projects that go further. These skills are intentionally narrower: judgment and program design for lean startup SOC 2.

Install and use

cp -R soc2-readiness soc2-audit-prep vendor-risk-analyzer ~/.claude/skills/

The skills trigger on SOC 2 tasks or can be invoked by name. SKILL.md is the entry point for each. references/ holds the depth. templates/ holds what gets copied and filled in.

Skills are instructions to an agent, not code. An upstream change can alter agent behavior without shipping anything executable. Vendoring a reviewed commit into a private compliance repository is safer than tracking main.

1. soc2-readiness: copy templates/starter-pack/, work through REPLACE.md, replace ACME, fill the tokens, and confirm or override each default.

2. soc2-audit-prep: build the matrix, walk the system description against evidence, run the seven gates, hand off.

3. vendor-risk-analyzer: run it on a vendor's SOC 2 and contracts before an integration decision.

The defaults are calibrated, not correct

The worked example behind the starter pack is an twelve-person startup with no prior program. Its defaults fit that company. They are likely wrong in specific ways for, say, a 50-person company post Series A, and the skills ask for confirmation rather than assuming.

Scope. Security-only Type I is usually the fastest route to a report. If prospects are already asking for a Type II, a Type I may add an audit cycle without removing the objection. Sales requirements are a reasonable guide to scope.

Access review cadence. The default is annual. At 40 people with working SSO, a quarterly review of privileged and application access can cost an afternoon and produces a stronger Type II control.

RTO and RPO. The template's 24 hours is defensible in an audit, which is a different thing from being true. The number should come from architecture and contracts. A company whose MSA implies four hours and has never restored production has a problem the audit will not surface.

Patch windows and breach notification. The 14-to-365-day patch matrix and the 72-hour customer notification are conversation starters. Contractual terms, customer questionnaires, and real exploit exposure should set them.

Passwords. The 15-character, no-composition-rules recommendation follows NIST SP 800-63B for single-factor passwords. NIST permits eight characters when the password is one factor of MFA. Fifteen is a defensible choice, not a SOC 2 requirement.

Penetration testing. The worked example deferred the pentest for Type I and used compensating controls, which the auditor accepted. Customer security teams often will not. A B2B company may want to budget for a scoped application, API, and tenant-isolation test regardless, since one reason to get a SOC 2 is to reduce friction in security reviews.

What the skills do not do

They do not inspect a cloud account, query an identity provider, check GitHub branch protection, track devices, or collect evidence on a schedule. That's the job of Vanta, Drata, Secureframe, and others. A company already paying for one has little reason to cancel it. The platform can gather evidence and run the audit workflow, and this method can decide what the policies and controls say, so the platform stops designing the program.

Without a platform, a Security-only Type I looks achievable by hand with these skills, GitHub, the identity provider and cloud consoles, and a structured evidence folder. A Type II by hand at 40 people is harder, because continuous evidence and employee and vendor lifecycle tracking are where the effort tends to concentrate.

The skills also do not:

• verify infrastructure or configuration. The audit-prep verification walk exists because each claim has to be checked against real evidence by a person
• make the scoping decision for regulated data. HIPAA, GDPR, and heavy privacy exposure call for specialist judgment
• replace the independent CPA firm performing the SOC 2 examination, whose judgment governs the report
• remediate. They identify gaps and structure evidence. They do not change controls, configurations, or code

Vendor SOC 2 reports are typically under NDA. vendor-risk-analyzer belongs in an enterprise AI environment with approved data handling and retention terms, not a consumer chat window.

Also, the control matrix is a seed across CC1 through CC9, not a sufficient control set. The AICPA defines the criteria. The auditor applies professional judgment to them. These skills help design and document an implementation that sits between the two. It goes without saying: none of this is legal or audit advice.

Before any ACME default is adopted, someone on the team should be able to answer these questions: Does the system operate this control? Can it be proven? Does the commitment make commercial sense? A company that can answer those for every row of the matrix is close to audit-ready. A company that cannot has a policy set, which is a different thing.

For the judgment calls, the infrastructure assessments, or the offensive security testing, let's talk. The guide behind these skills is at startupsoc2.fyi.