Skills · grc

`soc2-evidence-map`

Map an organisation's controls to the SOC 2 Trust Services Criteria in scope (Security always, plus Availability, Confidentiality, Processing Integrity or Privacy if chosen), and for each control list the evidence an auditor will ask for, the system it lives in, the owner, how often it is produced, and the gaps — distinguishing Type I (designed and in place at a date) from Type II (operating over a period, sampled from a full population) — as a table and a CSV the team can work from. Use when the user is preparing for a SOC 2 audit or readiness assessment, says "SOC 2 evidence", "map our controls to the TSC", "what will the auditor ask for", "SOC 2 gap analysis".

Pack grcTier standardJob Manage risk and compliancev0.1.0

npx skilldrop-cli install soc2-evidence-map

Other ways to install

With the sibling skills it hands off to:

npx skilldrop-cli install soc2-evidence-map --with-related

The whole pack it belongs to:

npx skilldrop-cli install --pack grc

By hand, from a clone of the repo:

cp -R packs/grc/skills/soc2-evidence-map ~/.claude/skills/

In Claude Code, with the grc plugin installed, invoke it as:

/grc:soc2-evidence-map

Try it

A realistic prompt from the skill's acceptance evals:

Acme Payments is going for SOC 2 Type II, Security and Availability, for 1 April to 30 September 2027. Controls today: Google Workspace SSO with MFA, joiners requested in Linear and approved by the hiring manager, leavers removed by IT 'usually the same day' with no ticket, GitHub PR reviews required on main, GCP Cloud SQL backups nightly, an uptime status page, PagerDuty on-call run by Priya Nair (SRE lead). Map our controls to the criteria, list the evidence the auditor will want, and show the gaps as a table and a CSV.

What a good result looks like

Every criterion in scope has a control or is listed as a gap. The coverage table shows it.
Every control is written as who, what, how often, with what record. No adjectives in place of a mechanism.
Evidence is specific to the report type: Type I names design evidence; Type II names the population, its source system, and the per-sample record.
Criteria IDs appear only where reference.md gives them; anything else is described in words.
System, owner and frequency are filled for every row, or the blank is itself a gap.
Status is honest: a control with no record, or one that started mid-period, is not in place.
Proposed controls are marked proposed, never presented as existing.

Example output

Worked example: Northwind Analytics, first SOC 2 Type II (Security) · the skill's own worked example, source

Input

A fictional 60-person SaaS company. The input is what its Head of Security might send; the output is the summary and the CSV, shortened where rows repeat a pattern.

We're Northwind Analytics. A big customer wants a SOC 2 Type II, Security only, and our auditor has proposed a six-month period, 1 January to 30 June 2027. We don't have a formal controls list. What we do today:

Okta SSO with MFA for everyone. Access is requested by Jira ticket with manager approval and granted through role-based Okta groups (Dev Rao, IT Lead).
BambooHR terminations deactivate Okta automatically, within the day.
Background checks through Certn before start, KnowBe4 training within 30 days (Ola Brandt, People Ops).
Laptops in Kandji with FileVault and malware protection. Four contractors use their own laptops.
Snyk scans weekly; criticals fixed in 14 days, highs in 30 (Rui Costa, Platform Lead).
Datadog security alerts page the PagerDuty on-call.
All deploys go through GitHub PRs with one approval and CI, but two admins can bypass branch protection (Kim Novak, VP Engineering).
RDS daily backups. Never tested a restore.
We wrote security policies in 2025, CEO approved them. Nobody has acknowledged them.
Incident response plan exists, never tested. We have a vendor list in Vanta.
Engineering managers "look at" AWS and GitHub admin access now and then.
We're on AWS; no production data in the office.

I'm Sam Ito, Head of Security.

No question was needed: scope, type, period, systems and most owners were given.

Output

Scope

SOC 2 Type II, Security (common criteria CC1–CC9), Northwind Analytics production platform, period 1 January 2027 to 30 June 2027. AWS is treated as a carved-out subservice organisation [assumption: confirm with the auditor].

Prepared for Northwind's compliance lead and auditor to review; not audit advice. The auditor decides what evidence is sufficient.

Coverage by criterion

Criteria	Controls	Status
CC1.1, CC5.3	GOV-01 policy approval and acknowledgement	partial
CC1.4	HR-01 background checks and training	in place
CC1.2, CC1.3, CC1.5	none	gap: GOV-02, GOV-03 proposed
CC2.1, CC2.2, CC2.3	none (GOV-01 covers part of CC2.2)	gap: COM-01 proposed
CC3.1–CC3.4, CC5.1	RISK-01 risk assessment	gap: RISK-01 not yet run
CC4.1, CC4.2	none	gap: MON-02 proposed
CC5.2	none mapped yet	gap: map once technology controls are confirmed
CC6.1	AC-04 SSO with MFA	in place
CC6.2	AC-01 joiners, AC-02 leavers	in place
CC6.3	AC-01 role groups; AC-03 access review	partial (AC-03 is a gap)
CC6.4	AWS (carved out); office holds no production data	subservice `[to confirm]`
CC6.5, CC6.6, CC6.7	none	gap: EP-02, NET-01, ENC-01 proposed
CC6.8	EP-01 managed laptops	partial
CC7.1	VM-01 vulnerability scanning	in place
CC7.2	MON-01 alert routing	in place
CC7.3, CC7.4	IR-01 incident response	partial
CC7.5	IR-01; BC-01 restore tests	partial
CC8.1	CHG-01 pull request review	partial
CC9.1	none	gap: BC-02 proposed
CC9.2	VEN-01 vendor reviews	partial

Evidence map (selected rows; full set in the CSV)

Control	Criteria	Type II population (source)	Per-sample record	System	Owner	Frequency	Status
AC-02 IT removes all access within 24 hours of termination, triggered from BambooHR	CC6.2	All terminations in the period (BambooHR report)	Okta deactivation timestamp within 24 hours of termination date	BambooHR; Okta	IT Lead (Dev Rao)	per event	in place
AC-03 Engineering managers review AWS and GitHub admin access quarterly; removals ticketed	CC6.3	The two quarterly reviews in the period (Jira)	Signed-off access list and a ticket per removal	Jira; AWS IAM Identity Center; GitHub	VP Engineering (Kim Novak)	quarterly	gap
CHG-01 Production deploys only via PR with a non-author approval and passing CI	CC8.1	All production deployments (GitHub Actions)	PR with non-author approval and green checks	GitHub	VP Engineering (Kim Novak)	per event	partial
EP-01 All laptops managed in Kandji with encryption and malware protection	CC6.8	Device compliance reports for the period	Sampled devices encrypted and protected	Kandji	IT Lead (Dev Rao) `[to confirm]`	continuous	partial
BC-01 Daily RDS backups; restore tested every six months	CC7.5	Restore tests in the period (Jira)	Restore record with date and outcome	AWS RDS; Jira	Platform Lead (Rui Costa) `[to confirm]`	semi-annually	proposed

For a Type I on the same scope, the CHG-01 evidence would be the branch protection settings export dated on the report date plus one merged PR, with no population. Here the auditor will sample deployments from all six months, so the bypass rights matter for every day of the period.

Gaps, ordered by audit risk

CHG-01 branch protection bypass (CC8.1). Every bypassed deploy is an exception the auditor finds by sampling. Remove bypass rights, or log and review each bypass, before 1 January. Owner: Kim Novak. Due 2026-11-15.
AC-03 no access review record (CC6.3). Schedule a quarterly review ticket and run the first before the period starts so Q1 and Q2 both have evidence. Owner: Kim Novak. Due 2026-12-15.
RISK-01 no risk assessment (CC3.1–CC3.4). Run one in January and minute leadership's review. Owner: Sam Ito. Due 2027-01-31.
GOV-01 no acknowledgements (CC1.1). Run the acknowledgement cycle in December so every person in the population has a date. Owner: Sam Ito. Due 2026-12-15.
EP-01 four unmanaged contractor laptops (CC6.8). Enrol or replace. Owner: Dev Rao [to confirm]. Due 2026-11-30.
IR-01 untested plan, BC-01 untested restore (CC7.4, CC7.5). Each needs one recorded test inside the period. Owners: Sam Ito, Rui Costa [to confirm].
No control yet for CC1.2, CC1.3, CC1.5, CC2.x, CC4.x, CC5.2, CC6.5–CC6.7 and CC9.1. Proposed controls are listed below; each needs an owner from Sam Ito.

Proposed controls (proposed until Northwind confirms):

GOV-02: leadership reviews security posture and open risks quarterly, minuted (CC1.2).
GOV-03: security roles and responsibilities documented in the org chart and job descriptions; policy breaches handled under the disciplinary policy (CC1.3, CC1.5).
COM-01: security commitments published to customers and in contracts; internal security updates sent quarterly (CC2.1–CC2.3).
MON-02: Head of Security reviews control operation quarterly and tracks deficiencies to closure (CC4.1, CC4.2).
EP-02: laptops wiped and recorded before disposal or reassignment (CC6.5).
NET-01: AWS security groups and WAF rules managed in code and reviewed on change (CC6.6).
ENC-01: TLS enforced on all external endpoints; data at rest encrypted with KMS (CC6.7, CC6.1).
BC-02: business continuity plan reviewed annually and tested by tabletop (CC9.1).

Vendor SOC reports to collect

AWS SOC 2 Type II covering the period, plus a bridge letter if it ends before 30 June 2027.
Okta SOC 2 Type II.
Complementary user entity controls to state in the system description: customers manage their own users' access and roles in Northwind's product [to confirm].

CSV

northwind-evidence-map.csv: 16 rows, one per control-criterion pair, in the columns of the template.

Why this is a passing output: every common criterion is either covered or listed as a gap; evidence names the population and source system for Type II; IDs used are only those in the reference; owners are the people the user named, owners the skill inferred are marked [to confirm], and proposed controls are left for Sam to assign; the mid-period and untested controls are not marked in place; and AWS is handled as a carve-out with the reports to collect.

How it's checked

Measured against plain Claude Code (2026-10-23): it met 57% of its checks, against 47% without it, and a blind judge preferred it. How skills are checked

21 assertions across 3 acceptance evals, and 8 trigger queries. Every skill's checks

What the output must do

Every common criterion and every Availability criterion in scope is either mapped to a control or listed as a gap
Each control is written as who does what, how often, and where it is recorded
Type II evidence names the full population, the system it is exported from, and what each sampled item must show
The leaver process with no ticket is marked partial or gap, not in place, because it leaves no per-sample record
Criteria IDs used are real AICPA TSC IDs (for example CC6.2, A1.2); areas without a confident ID are described in words
System, owner and frequency are given for every row, and owners not in the prompt are marked to confirm rather than invented
GCP is treated as a subservice organisation with its SOC report to collect
A CSV with one row per control-criterion pair is provided alongside the table
Treats the audit as Type II over 1 November 2026 to 30 April 2027: evidence asks cover the whole period's population or samples, and the plan to screenshot the background-check portal the week before the auditor arrives is flagged as not enough
Flags that access reviews (C02) are listed as quarterly but have been ad hoc, with the last one in February 2026
Flags that 90-day ticket history can't supply a full population of access requests (C01) and changes (C05) for a six-month period
Notes that audit-scope.md says 14 controls but controls.csv has 12
Maps to Security, Availability and Confidentiality only; does not treat Privacy or Processing Integrity as in scope, says the GDPR mapping is outside SOC 2 scope, and does not predict a pass
Writes evidence-map.csv with one row per control
Does not invent controls, systems, owners or evidence that exists; gaps such as the missing deletion log for C12 are recorded as gaps
Explains in plain terms that SOC 2 is an independent auditor's report, not a certificate or a form to fill in
Explains the choice between a point-in-time report and one covering a period, and that the client's requirement decides which, without stopping to ask first
Lists evidence in terms of the tools they actually named (the cloud drive, email, company laptops), such as who has access, MFA, laptop encryption, joiners and leavers
Mentions that a few policies and written processes will be needed, and that with no IT person someone must own this
Does not invent systems, tools, vendors or costs the agency didn't mention
Stays at about one page in plain language for a non-specialist

When it should and shouldn't activate

Should activate:

Map our controls to the SOC 2 Trust Services Criteria and tell me what evidence the auditor will ask for
We're moving from SOC 2 Type I to Type II, what do we need to start recording?
Build a SOC 2 gap analysis spreadsheet with owners and systems for each control
What evidence do we need for CC6.2 and CC8.1 in our SOC 2 audit?

Should leave to another skill:

Build a STRIDE threat model for our new data pipeline
Create a risk register for the company with a heat map
Write the non-functional requirements for availability and security of the billing service
Draft a DPIA for our customer analytics feature

Hands off to

risk-register — when the company has no risk assessment, which the risk assessment criteria expect. Produce the scored, owned risk register the auditor will ask to see.

Source

SKILL.md · the whole folder on GitHub.

soc2-evidence-map