SOC 2 feels huge until you realise it is really a finite list of things you either do or you do not. An auditor is checking whether you manage access, control changes, protect data, watch your systems, and can respond when something goes wrong. Get those in order and the report mostly writes itself.
This is the checklist we use to get startups audit-ready. It is organised by the areas an auditor groups their questions into. Work top to bottom, be honest about what is missing, and you will have a real gap list by the end of an afternoon.
Want the editable version?
Get this checklist as an editable tracker you can share with your team and tick off as you go. We will send it over and include a couple of the templates we use.
01 Governance and policies
Auditors want written policies that match how you actually work, plus evidence someone owns security.
- An information security policy exists, is approved, and is reviewed at least annually
- Acceptable use, access control, change management, and incident response policies are documented
- A named person or role owns security, even if it is a founder or a fractional CISO
- Employees acknowledge the policies when they join and yearly after
- A risk assessment has been done and is revisited on a schedule
02 Access control and identity
The single most common source of findings. Prove that the right people, and only the right people, can reach your systems and data.
- Multi-factor authentication is enforced on all systems, with no exceptions
- Single sign-on is used for internal tools where possible
- There are no shared or generic logins, and any that existed have been rotated
- Access is granted by role and follows least privilege
- Access is reviewed on a regular cadence, and removed promptly when someone leaves
- Production access is restricted and logged
03 Change management
Show that code and infrastructure changes are reviewed and traceable, not pushed straight to production on a whim.
- Code changes go through pull requests with a required reviewer
- The main branch is protected and cannot be force-pushed
- Deployments are automated and leave a record of what shipped and when
- Infrastructure changes are tracked, ideally as code
04 Infrastructure and network security
The basics of not leaving the doors open. Auditors and buyers both look here.
- Cloud accounts follow least privilege, with no over-permissioned root or admin use
- Storage buckets and databases are not publicly exposed by accident
- Networks are segmented and only necessary ports are open
- Systems are patched on a defined schedule
- Endpoints have protection such as EDR, and disks are encrypted
05 Data protection
Prove customer data is encrypted, backed up, and recoverable.
- Data is encrypted in transit and at rest
- Encryption keys and secrets are managed properly, not hard-coded
- Backups run automatically and have been tested by actually restoring
- Data retention and deletion practices are documented
06 Logging and monitoring
You cannot detect or investigate what you do not log. Auditors want evidence you would notice something going wrong.
- Centralized logging is in place with sensible retention
- Access to production and sensitive data is logged
- Alerts exist for meaningful security and availability events
- Someone is responsible for looking at them
07 Vendor and third-party risk
Your subprocessors are part of your attack surface, and buyers will ask about them.
- A list of vendors and subprocessors that touch customer data exists
- Critical vendors are reviewed, ideally by collecting their SOC 2 or equivalent
- Data processing agreements are in place where needed
08 Human resources and personnel
The people controls that surround access and data handling.
- Background checks are run on new hires where appropriate
- Security awareness training happens at onboarding and annually
- Onboarding and offboarding checklists cover access, equipment, and accounts
09 Incident response
A plan you have actually tested, not a document nobody has read.
- An incident response plan exists with roles, severities, and escalation paths
- The plan has been tested with at least a tabletop exercise
- Breach notification obligations, including under Canadian privacy law, are understood
10 Availability and continuity
For the availability criteria, show your service can survive a bad day.
- Uptime and performance are monitored
- A business continuity or disaster recovery approach is documented
- Recovery has been tested, not just written down
That is the shape of SOC 2. If you can honestly tick most of these, you are closer than you think. If large sections are blank, that is normal at the start, and it is exactly the work we do. For the bigger picture, see SOC 2 for Canadian SaaS, or how the whole program runs on our compliance page.