# SOC 2 Type II Evidence Checklist — Security TSC

A plain, per-control checklist of what auditors actually ask for, and how to collect each item. Built for small SaaS teams doing evidence collection themselves. No platform required.

**How to use it:** for each control, collect the evidence listed, name files consistently (e.g. `2026-09-access-review.csv`), and drop them in one evidence folder per control. Auditors care about three things: the control exists in writing, you can show it operating over the audit period, and the evidence is dated.

**Two rules that save months:**
1. Evidence must show the control *operating over time* — not one screenshot on day one. Pick a cadence (monthly is fine) and stick to it.
2. If the control isn't written down somewhere as yours (policy or procedure doc), the evidence doesn't attach to anything.

---

## CC6.1 — Logical access: who has access and why

| Evidence | What to collect | How |
|---|---|---|
| Access policy | Short doc: who grants access, on what approval, review cadence | 1 page is enough; version it |
| User access list | Every human and service account with prod access | Export from cloud IAM / GitHub org |
| Onboarding evidence | For 2–3 hires in the period: ticket granting access + manager approval | Ticket link or saved approval email |
| Offboarding evidence | For every leaver in the period: access removed, with date | Ticket + post-change export |
| Quarterly access review | Signed (or committed) review: list of accounts, approver, date | CSV with a "reviewed by / date" column |

**Common fail:** offboarding with no artifact. If someone left and access was removed in the console only, there's nothing to show the auditor. Create a ticket for it every time.

## CC6.2 / CC6.3 — Authentication and least privilege

| Evidence | What to collect | How |
|---|---|---|
| MFA enforcement | Screenshot of MFA policy setting in IdP/Google Workspace + current coverage report | Export "users without MFA" — should be 0 |
| Password / SSO policy | The section of your policy covering authentication | Already in policy doc |
| Role definitions | What roles exist and what each can do (GitHub, AWS, DB) | One-page table or IAM policy docs |
| Least-privilege sample | For 2–3 users: their roles match their job | Screenshot of role assignment |

**Common fail:** service accounts and CI tokens. Auditors ask about non-human access. List them, note owner and rotation.

## CC6.6 / CC6.7 — Boundaries, encryption, transmission

| Evidence | What to collect | How |
|---|---|---|
| Encryption in transit | TLS config report on public endpoints (SSL Labs or similar), dated | Run once per quarter, save report PDF |
| Encryption at rest | Statement of what's encrypted where (DB, backups, file storage) + console screenshot of the setting | 1 screenshot + paragraph |
| Network boundary description | Short diagram/description: VPC, public subnets, what's exposed | Draw.io or text — clarity beats beauty |
| Secrets handling | Where secrets live (secrets manager, not code), rotation approach | Policy paragraph + screenshot of the vault |

## CC7.x — Monitoring, logging, incident response

| Evidence | What to collect | How |
|---|---|---|
| Logging enabled | Screenshot of log retention config (app, infra, access logs) | One per system in scope |
| Alerting rules | List of configured alerts and who they page | Export or screenshot |
| Incident response plan | The plan doc: severity levels, who does what, contact list | Version it, date it |
| Incident log | Every incident in the period, even minor ones, with what happened and what changed | A simple spreadsheet is fine |
| Tabletop exercise | Notes from one walkthrough of the incident plan during the period | Half an hour, write up the notes |

**Common fail:** empty incident logs read as "no process", not "no incidents". Record near-misses and false alarms — that shows the process works.

## CC8.1 — Change management

| Evidence | What to collect | How |
|---|---|---|
| Change policy | How code gets to prod: PR review, CI checks, deploy process | 1 page |
| PR review evidence | For 2–3 changes: PR with reviewer approval + CI pass | GitHub links, exported to PDF or screenshot |
| Deploy log | List of deploys in the period (dates, what, by whom) | CI export or changelog |
| Rollback approach | How you roll back a bad deploy | Paragraph in the policy |

## CC9.x — Risk and vendor management

| Evidence | What to collect | How |
|---|---|---|
| Risk register | Risks with owner, likelihood, impact, treatment, review date | CSV template — review quarterly |
| Vendor list | Third parties touching customer data (hosting, email, payments, support) with what data they hold | Spreadsheet |
| Vendor security review | For top vendors: their SOC 2 report / security page reviewed, dated | Note the date you reviewed each |
| Risk review minutes | One written review of the register during the period | Even a doc with bullet points works |

---

## Evidence hygiene checklist

- [ ] One folder per control, files named with dates
- [ ] Nothing hand-drawn over with edits — originals
- [ ] Every artifact dated within the audit period
- [ ] Access reviews done at least quarterly, dated, with a named reviewer
- [ ] Offboarding has an artifact for every leaver
- [ ] Incident log has entries (near-misses count)
- [ ] Policies versioned — the auditor will ask what changed

*This is self-assessment material, not audit advice. Your auditor decides what's sufficient — this checklist gets you to the conversation with most of the folder already built.*