soc2 evidence collector

The problem

Preparing for a SOC 2 audit often leads to a last-minute scramble to generate evidence that actually maps to specific AICPA criteria. Manually tracing IAM exports or git logs to CC6 and CC8 controls is error-prone and risks providing auditors with gapped or irrelevant data.

What it does

• Generates audit-ready access-control matrices, change-management logs, and encryption inventories.
• Maps every evidence row to specific lines in supplied IAM exports, git histories, or config files.
• Validates Type II evidence against stated observation periods to identify timestamp gaps.
• Flags stale Type I snapshots by comparing export generation dates to the current date.
• Identifies and reports control failures, such as unapproved changes or orphaned accounts, found during processing.

Why this beats prompting it yourself

General-purpose prompts often hallucinate plausible-looking data or fail to maintain the strict traceability required by auditors. This skill enforces a hard requirement for source data, ensuring every artifact is grounded in your actual system configuration rather than a description of it.

Use cases

• Generating a change-management log from git and deployment history for a Type II audit period.
• Creating an access-control matrix mapped to CC6 using raw IAM exports.
• Producing an encryption inventory for data-at-rest and in-transit based on infrastructure-as-code files.
• Identifying gaps in audit evidence before the official auditor review begins.

Known limitations

Does not cover CC7 (System Operations) or CC9 (Risk Mitigation). Requires raw text or file exports of system configs, as it cannot independently query cloud provider APIs.