SOC 2 Type II is not a certification you buy. It is an attestation that your controls operated effectively over a period of time — usually six to twelve months. For a founder going through SOC 2 for the first time, the hardest part is not the audit itself; it is figuring out where to start and what "good" looks like.
How to use this checklist
Work through each section in order. For every item, assign one owner, pick a realistic due date, and record where the evidence lives. Evidence can be policy documents, screenshots, configuration exports, ticket URLs, signed agreements, or automated logs. The auditor's job is to test whether the control existed, was followed, and produced reliable evidence.
If an item does not apply to your system — for example, you have no physical data center — mark it "not applicable" and document why. Scope is normal; unexplained gaps are not.
1. Assets & devices
- Keep an up-to-date inventory of production servers and employee workstations. Update it when devices are added or disposed of.
Evidence to collect: Asset register export with dates of addition and disposal
- Require employee workstations to install patches and restart at least monthly before accessing sensitive systems.
Evidence to collect: Patching policy + device compliance report
- Store devices awaiting disposal in a secure location, mark them as held for disposal, and wipe or destroy them at least annually.
Evidence to collect: Disposal ticket with wiping certificate or vendor receipt
2. Availability, backups & continuity
- Send production downtime and leading performance alerts to Engineering, and require acknowledgement through the on-call escalation process.
Evidence to collect: Alerting policy and sampled on-call acknowledgement logs
- Configure production services to automatically adjust capacity as usage changes.
Evidence to collect: Auto-scaling configuration screenshot or IaC snippet
- Back up production databases and capture infrastructure configuration snapshots at least weekly.
Evidence to collect: Backup job logs and configuration snapshot history
- Replicate database backups to a geographically separate data center.
Evidence to collect: Replication policy + backup location evidence
- Perform an annual business impact assessment identifying critical systems, likely disruptions, and recovery priorities.
Evidence to collect: BIA document signed and dated within the audit period
- Maintain and review business continuity and disaster recovery plans annually.
Evidence to collect: BCP/DRP document with RTO/RPO and recovery procedures
- Test restoration of production databases annually and document the results.
Evidence to collect: Restoration test ticket with pass/fail results
- Conduct annual tabletop walkthroughs of business continuity and disaster recovery plans.
Evidence to collect: Meeting minutes or tabletop runbook with attendee list
3. Customer responsibilities
- Maintain Terms of Use that explain external users' responsibilities, and require acceptance before system access.
Evidence to collect: Terms of Use version history + acceptance log or clickwrap evidence
4. Secure configuration & software changes
- Review infrastructure configuration baselines annually and check production infrastructure against them quarterly.
Evidence to collect: Baseline document + quarterly compliance scan results
- Apply operating system patches and container image updates at least weekly.
Evidence to collect: Patching schedule and sample update logs
- Manage production changes in a source code repository and require a merge request for each change.
Evidence to collect: Git history showing MR/PR for sampled production changes
- Before release, require standard checks including static code analysis, security scans, and validation in a pre-production environment.
Evidence to collect: CI pipeline configuration and passing run logs
- Require each merge request to be approved by an Engineering team member other than the submitter.
Evidence to collect: Branch protection rules and sample approved PRs
- Use a standard configuration checklist for new repositories and immutably log configuration changes to existing ones; review quarterly.
Evidence to collect: Checklist template + configuration change audit log
- Limit production deployment access to authorized personnel using the standard build process.
Evidence to collect: Deployment permissions list and CI/CD access logs
5. Encryption & data handling
- Encrypt confidential customer data at rest.
Evidence to collect: Database/storage encryption configuration screenshot or vendor attestation
- Encrypt confidential customer data in transit between the production environment and customer endpoints.
Evidence to collect: TLS/certificate configuration or security scan report
- Install full-disk encryption on employee workstations and laptops, and centrally configure and monitor it.
Evidence to collect: MDM configuration showing disk encryption enforcement
- Maintain a data classification policy and retention schedule showing where confidential customer data is stored and for how long.
Evidence to collect: Classification policy + retention schedule document
- Delete a customer's confidential data within the timeframe stated in the master services agreement when a contract ends.
Evidence to collect: Deletion ticket or automated deletion job log
6. Physical access
- Require CTO approval for physical data-center access, and have the CTO review physical access annually.
Evidence to collect: Access approval log + annual review memo
7. Organization, risk & oversight
- Maintain an organizational reporting structure and update it when changes are made in the HR system.
Evidence to collect: Org chart export with effective dates
- Maintain cyber insurance sufficient to support containment or remediation after a data breach or compromise.
Evidence to collect: Insurance certificate showing coverage limits
- Perform an annual risk assessment covering security, availability, and confidentiality of critical systems.
Evidence to collect: Risk assessment report with risk ratings and mitigation owners
- Assign the Board responsibility for oversight of management and internal controls in a charter reviewed annually.
Evidence to collect: Signed Board charter
- Have the Board meet quarterly to review strategic direction and internal control performance.
Evidence to collect: Quarterly Board meeting minutes
- Maintain an Information Security Policy reviewed annually by the CTO and available to all employees.
Evidence to collect: Policy version history with CTO approval and employee attestation log
8. Access management
- Require documented approval under the Access Management Policy before granting access to critical or security-management systems.
Evidence to collect: Access request tickets with approver signatures
- Configure authentication for systems that store sensitive data in accordance with the Password Policy.
Evidence to collect: Password policy + authentication configuration evidence
- Require multi-factor authentication for every user of critical systems.
Evidence to collect: MFA enrollment report or identity provider configuration
- Require VPN authentication to access the production environment.
Evidence to collect: VPN policy and access logs
- Disable a terminated employee's system access within 24 hours of termination.
Evidence to collect: HR termination report matched to access deactivation timestamps
- Review user access rights and roles for critical systems quarterly.
Evidence to collect: Quarterly access review logs with reviewer sign-off
- Restrict access to the production environment and critical management tools to specifically authorized teams.
Evidence to collect: Production access list and role-based permission rules
9. Incident response & security monitoring
- Maintain incident management policies and procedures for identifying, containing, eradicating, and recovering from breaches and compromises.
Evidence to collect: Incident response policy
- Track incidents to resolution in the ticketing system using a standard template with required fields.
Evidence to collect: Sample incident tickets
- After a data breach, notify affected external parties promptly with scope, actions, and assistance information.
Evidence to collect: Notification template and sample communication log
- After containing an incident, complete a root cause analysis, identify systemic issues, and implement fixes.
Evidence to collect: RCA document with remediation tickets
- Monitor the production environment for suspicious activity, send alerts to Security, and require acknowledgement through on-call escalation.
Evidence to collect: Monitoring alert configuration and acknowledgement logs
10. Network security
- Configure security groups to allow or deny production traffic based on traffic type, protocol, port range, and source IP; review quarterly.
Evidence to collect: Firewall/security group rules and quarterly review ticket
11. People & security awareness
- Maintain job descriptions for security personnel and anyone with customer-data access specifying responsibilities, qualifications, and required skills.
Evidence to collect: Sample job descriptions
- Complete employee background checks before each person's start date, and require management approval for any issues.
Evidence to collect: Background check policy and sample reports
- Maintain an employee handbook covering workplace conduct and acceptable technology use.
Evidence to collect: Employee handbook with annual acknowledgment
- Document how employees can report conduct violations, including an anonymous whistleblower hotline.
Evidence to collect: Whistleblower policy and hotline registration
- Require new hires to sign a confidentiality agreement before their start date.
Evidence to collect: Signed confidentiality agreements
- During onboarding, require employees with customer-data access to acknowledge company policies and code of conduct.
Evidence to collect: Onboarding attestation log
- Evaluate employee performance annually, including accountability for internal control responsibilities.
Evidence to collect: Performance review template with control accountability section
- Require security awareness training before an employee's start date and annually thereafter.
Evidence to collect: Training completion report
- Maintain system architecture and data-flow diagrams showing system boundaries and make them available to employees.
Evidence to collect: Architecture and data-flow diagrams
12. Customer contracts
- Execute a master services agreement before serving a customer, defining services, system boundaries, and security responsibilities.
Evidence to collect: Sample executed MSA with responsibility matrix
13. Endpoint & server protection
- Install antivirus software on employee laptops, centrally configure it, and send suspicious-activity alerts to Security.
Evidence to collect: AV configuration and alert logs
- Install anti-malware software on all production servers.
Evidence to collect: Server anti-malware deployment report
14. Third-party management
- Require third parties with access to confidential company data to sign an agreement protecting that information.
Evidence to collect: Executed NDAs / DPAs
- Assess security risk before engaging vendors and annually thereafter; assign safeguards, obtain CTO approval.
Evidence to collect: Vendor risk assessment forms and CTO approval log
15. Vulnerability management
- Run internal and external vulnerability scans monthly; review and risk-rate findings and remediate per policy timelines.
Evidence to collect: Monthly scan reports with remediation evidence
- Have an independent third party perform a penetration test annually; require CTO review and remediation plans for high findings.
Evidence to collect: Penetration test report and remediation tracker
What changes once the audit window starts
Once your audit window opens — usually three, six, or twelve months before the report date — stop changing policies for cosmetic reasons. The auditor tests whether the controls operated consistently over that window. A last-minute policy rewrite can actually hurt you because there is no evidence the new version was followed for most of the period.
Instead, use the window to generate evidence. Run the access review. Document the backup restoration. Complete the risk assessment. Save screenshots, ticket URLs, and signed approvals with dates. When the auditor arrives, you want a folder for each control, not a scramble.
How Skadi helps founders on their first SOC 2 audit
Skadi is the audit intelligence behind a network of Independent CPA audit firms. Our audit intelligence handles the repetitive work of evidence collection and analysis, while licensed CPAs apply professional judgment and issue the final opinion. The audit is scoped around SaaS and AI architecture, work with your existing repositories and GRC tools, and keep your evidence inside an audit intelligence environment — not a third-party LLM.
If you are preparing for your first SOC 2 Type II, book a call and we will walk through this checklist with you, identify the highest-risk gaps, and build a timeline that matches your sales cycle.
Ready to make your first audit protect the business?
Talk to a Skadi auditor about your current state and get a clear roadmap before the audit window opens.