Checklist
Every SOC 2 check, paired with the record that proves it.
A checklist helps only if you know when an item may be ticked. Each check below carries a finish line and the record a service auditor would accept, so you can tell work in progress from work that will survive testing. It is grouped by who has to act, because most stalled programmes stall on an owner, not on a task.
Back to SOC 2 services01 · Leadership decides
Decisions only leadership can make
Write them down. Everything below depends on them.
| Check | Done when | Record that proves it |
|---|---|---|
| Categories chosen | Security, plus any of Availability, Confidentiality, Processing Integrity or Privacy that your contracts actually promise | A scoping memo that cites the commitments |
| Boundary drawn | Products, environments, data and teams in scope are named, and each exclusion has a reason | Boundary diagram and asset inventory |
| Vendors placed | Each subservice organization is marked carve-out or inclusive | Vendor register with that column filled |
| Report type picked | Type 1 or Type 2 is chosen, with the reason tied to what buyers have asked for | A line in the scoping memo |
| Programme owner named | One person runs the work and has time set aside for it | Leadership minutes or an appointment note |
| Risks assessed | Threats to your commitments are identified, rated and given a treatment | A dated risk register that leadership approved |
02 · Engineering runs
Controls engineering must already be running
Running means producing records now, not configured last week.
| Check | Done when | Record that proves it |
|---|---|---|
| Multi-factor sign-in | Required on the identity provider and on every production console | Policy export from the identity provider |
| Joiner and leaver access | Accounts are created from approved requests and removed promptly after someone leaves | Access tickets matched against HR dates |
| Access reviews | Production access is confirmed at the frequency your description states | Dated review records, with removals carried out |
| Change approval | No production deploy goes out without a second person approving | Branch protection settings and merge history |
| Logging and alerting | Security events are collected, kept for the whole period, and alerts get answered | Retention settings and alert tickets |
| Vulnerability handling | Scans run, and findings close inside the timelines you set yourself | Scan output and closure tickets |
| Backups and recovery | Backups succeed and a restore has actually been tested | Job history and a restore test write-up |
| Encryption | Customer data is encrypted in transit and at rest | Configuration exports or screenshots |
03 · HR and managers
Checks that sit with HR and line managers
The CC1 criteria are about people, and auditors sample them too.
- Background checks. Run for new hires as your policy states and local law allows, with the outcome on file.
- Policy acknowledgement. Everyone in scope has accepted the security policies, with a date against each name.
- Awareness training. Completed at joining and repeated at the frequency you have written down.
- Defined responsibilities. Job descriptions or a role map show who carries which security duty.
- Consequences written down. A documented process exists for breaches of policy.
04 · Documents
Documents management approves and signs
Short, accurate and approved beats long and generic.
- Information security policies, approved by leadership and written to match how the team really works.
- Incident response plan, naming roles, with a record that it has been exercised.
- Vendor management procedure, plus your reviews of key vendors' own assurance reports.
- System description, drafted by management against the DC 200 criteria.
- Management assertion, signed once the description is final.
05 · The engagement
Checks for the examination itself
The CPA firm does the testing. You make testing possible.
| Check | Done when | Record that proves it |
|---|---|---|
| Firm engaged | A licensed CPA firm with no hand in building your controls has signed on | Engagement letter, and the firm's latest peer review result |
| Window agreed | Start and end dates are fixed, after controls began producing records | Engagement letter |
| Populations ready | Each recurring control has a complete list and the query behind it | Population files |
| Single contact | One person routes requests and tracks what is still open | Request tracker |
| Response process | Someone is ready to draft management responses to any finding | Response template |
Where to go deeper
Readiness work, evidence quality and the length of the observation window each have their own guide. Use this page as the master list and those pages for the detail behind each line.
06 · After the report
Traps once the report arrives
The next window should already be booked by the time you read the opinion.
- A late start to the next window. Any month between two periods is a month no report speaks to.
- Ignoring drift. New tools, vendors and staff that never reach the inventory turn into gaps.
- Sharing without terms. A SOC 2 report is meant for specified readers. Share it under a non-disclosure agreement.
- Loose answers about recent months. Use a bridge letter signed by management, stating only what you have checked.
Sources: AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (with revised points of focus, 2022); AICPA, DC section 200 description criteria; AICPA Guide, SOC 2 Reporting on an Examination of Controls at a Service Organization; AICPA Peer Review Program standards.
Questions about using the checklist
Which group of checks should come first?
The leadership decisions.
Categories, boundary and vendor placement set the size of everything else. Pull your customer contracts first and see what you have actually promised.
Is this the same as a list of SOC 2 controls?
No. It is wider.
Controls are what you run to meet the criteria, and our controls list gives examples. This checklist also covers decisions, documents and the engagement.
If every item is ticked, is a clean report guaranteed?
No.
The opinion rests on the service auditor's testing across the whole window. A check ticked today can still fail later if the control stops running.
Who should own the checklist?
One named person with the standing to chase others.
Usually a compliance or security lead who reports to leadership. Owners of individual checks sit across engineering, HR and legal, so the programme owner needs authority to follow up.
Turn the checklist into a plan.
A SOC 2 readiness assessment marks each check as done, partial or missing, and hands you an ordered roadmap for the rest.