Menu

Individual skill

soc2-evidence-helper

0upvotes

Maps engineering controls to SOC 2 Trust Service Criteria, builds a continuous evidence-collection plan with cadences per control family, and produces the control-to-evidence table auditors work from. Use when someone asks "what evidence do we need for SOC 2", "map our controls to the Trust Service Criteria", "how do we prepare for Type II fieldwork", "the auditor asked for access reviews", or is closing findings or standing up a compliance program. Do NOT use for building an incident postmortem - use postmortem-writer instead; do NOT use for finding and prioritizing actual vulnerabilities - use vulnerability-triage instead; this skill organizes proof that controls operate, it does not implement the controls.

skills/soc2-evidence-helper/SKILL.md

Read pinned source

Source commit 97a13607d669157a4a16d5ba79b77f208319f7b9

What was checked

Matches the observed repository HEAD
Yes
Scanner rules are current
No
Repository scan complete
No
Skill scan complete
No
Observed behavior
Not checked yet
Last checked
Nov 6, 2026

These are observations at the recorded commit, not a guarantee of safety. Review the source before running it.

Install this skill

Choose an agent in your Stack or copy a command below. Commands fetch the pinned commit and copy only this skill directory. Existing destinations are refused. Copying a command does not install anything.

An install command is unavailable: current rules, complete repository and skill scans, an eligible behavior level and a permitted license are required.

Repository context

Repository stars (not skill ratings)
24
Repository last updated
Oct 13, 2026
License
MIT

Observed agent integration: No specific integration evidence. Standard SKILL.md installation does not imply verified compatibility.

Files and excerpt

File metadata and permitted, redacted excerpts come from the recorded scan. Source links are pinned to that commit.

Browse files
Read excerpt
# SOC 2 Evidence Helper

SOC 2 audits test whether security controls exist (Type I, point in time) and operate consistently over a review period (Type II, typically 3-12 months). Engineering teams lose the most time gathering evidence reactively in the month before fieldwork - and for Type II that scramble cannot work, because auditors sample from the whole period and a gap in month two is already a finding. Build collection into normal operations instead.

## Operating procedure

### Step 1: Gather inputs

- Type I or Type II, and the review period dates. Default assumption: first audit is Type I, followed by a 6-month Type II.
- Which Trust Service Criteria are in scope (Security is mandatory; the rest are contract-driven). If unknown, check customer contracts and security questionnaires - scope only what customers demand.
- The systems of record: IdP (Okta, Entra), source control, CI, cloud provider, ticketing, HR system, vulnerability scanner.
- Any prior findings or bridge letters. Label unknowns as unknowns.

### Step 2: Scope the criteria before collecting anything
Back to top