SOC 2 Checklist for Startups

• Identify the systems and services likely to be in scopeName the product, production environments, and supporting services a customer would reasonably expect in a SOC 2 report. Narrow is usually better than impressive.
• Document key infrastructure, applications, and data flowsA simple diagram of how customer data moves — app, database, identity provider, cloud, vendors — is enough to start conversations with an auditor.
• Identify owners for security and compliance activitiesSomeone must coordinate policies, evidence, and auditor questions. On a small team this is often a founder or CTO, not a dedicated GRC hire.
• Identify important third-party services and subprocessorsList processors that sit in the path of customer data or production access. This later feeds vendor reviews and the system description.

• Understand the Security criterionSecurity (common criteria) is in every SOC 2. Know what it expects at a high level: access, change, monitoring, risk, and related practices — not a memorized AICPA paragraph.
• Determine whether additional Trust Services Criteria may be relevantAvailability, confidentiality, processing integrity, and privacy are optional unless you include them. Do not add criteria because a blog list looks complete.
• Discuss expected scope and report type with an independent CPA firmAuditBird does not set your audit scope. Confirm systems, criteria, Type 1 vs Type 2, and period with the firm that will examine you.

Need a starting point? Browse free SOC 2 policy templates or check a draft for common gaps.

• Maintain an information security policy that matches how you operateThe document should describe real tools, owners, and expectations. A generic PDF with placeholders still in it is not in force.
• Document an access control policyCover provisioning, least privilege, MFA, reviews, and leavers in language that matches your identity provider and production practice.
• Document an incident response policyDefine what counts as an incident, who is called, and how you record follow-up. Write the process you can actually run at 2 a.m.
• Document a vendor management policyState when a security review is required, who approves critical processors, and how offboarding works.
• Document a change management policyExplain how production changes are requested, reviewed, tested, and recorded — including emergencies.
• Document risk management and business continuity / recovery expectationsThese can be standalone policies or clearly owned sections. They should match how you actually assess risk and restore systems.

• Enforce MFA for critical systemsRequire MFA on cloud consoles, production, identity provider admin, and other privileged accounts. Partial coverage is a gap, not a maybe.
• Document how accounts are provisionedNew access should follow a role, a ticket, or another recorded request — not an undocumented Slack ping that nobody can reconstruct.
• Give people only the access their role needsShared root users and standing admin everywhere are common startup shortcuts that become findings.
• Run recurring access reviews on critical systems and keep the evidenceA calendar reminder is not enough. Save who reviewed what, when, and what was revoked.
• Remove access promptly after termination or role changeIdP, git, cloud, admin SaaS, and production secrets should be on a leaver list someone actually executes.

• Use a documented onboarding processNew hires should get the right accounts, policy acknowledgements, and a named manager — not a one-off thread.
• Use a documented offboarding processTie HR last-day notice to access removal, device return, and confirmation that privileged credentials were revoked.
• Deliver security awareness training and keep completion recordsA short annual (or onboarding) session is typical. Auditors often ask who completed it, not whether a slide deck exists.
• Collect acknowledgements of relevant policiesPeople should know the rules that apply to them. Store the acknowledgement, not only the policy file.

• Identify and track vulnerabilities to remediationDependabot, cloud findings, or a scanner is a start. Record what you fixed and what you accepted, with an owner.
• Log security-relevant activity where it is appropriateAuth, admin, and production changes should be reconstructable. You do not need every packet captured.
• Monitor or alert on important security eventsDecide what would wake someone up — failed admin login bursts, production IAM changes — and where that alert goes.
• Consider penetration testing if it fits your environment and engagementMany buyers and some auditors expect a test. It is not a universal legal requirement for every SOC 2. Confirm with your firm and customers.

• Track, review, and test production changes where appropriatePRs, tickets, or a change record should show what shipped, who looked, and that testing happened before production when it should.
• Record approval for production changesA merge from a second person, a ticket status, or an explicit approve step — something you can show later.
• Define an emergency change path and retain deployment evidenceHotfixes happen. Document how they are authorized after the fact and keep the deploy/change record.

• Keep an inventory of important vendors and mark which are criticalCritical usually means they process customer data, hold production access, or would halt the product if they failed.
• Review security or compliance risk before onboarding critical vendorsA SOC report, questionnaire, or scoped review — sized to the risk. Save what you looked at.
• Review critical vendors periodically and track issuesAnnual is common for small teams. Record findings, owners, and whether you accepted residual risk.
• Have an offboarding path for vendors that lose access or dataRevoke SSO, API keys, and data exports when a processor is no longer used.

• Document an incident response process with named responsibilitiesWho triages, who talks to customers, who has authority to take a system down. Names or roles, not “the team.”
• Define reporting and escalation pathsEmployees should know how to raise a suspected incident and when legal or customers get involved.
• Record incidents and follow them through to resolutionA ticket or log with timeline, containment, and a short post-incident note when the event warrants it.
• Run a tabletop or similar exercise where it is appropriateA 45-minute walkthrough of a realistic scenario is often enough for a small team. Keep notes as evidence.

• Identify critical systems and back up the data that mattersKnow what you would restore first. Confirm backups actually exist for those systems.
• Document recovery procedures and who owns themA short runbook beats a 40-page plan nobody has opened. Name the person who can restore production.
• Test recovery where appropriate and keep the resultA restore of a database snapshot or a documented failover drill. Save date, owner, and outcome.

• Identify, assess, and assign owners for security risksA lightweight register is fine: risk, impact, owner, treatment. Do it on a cadence, not only the week before fieldwork.
• Record treatment and accepted risksMitigate, transfer, or accept — with a person who accepted. Silent risk is still risk.
• Review the risk register periodicallyNew vendors, new products, and incidents should trigger an update. Annual-only with no trigger is a weak habit.

Having a process is different from being able to demonstrate that the process operated.

• Retain access-review, onboarding, offboarding, and training recordsExports, tickets, and completion lists dated in the period you will claim.
• Retain policy approvals, vendor reviews, and change approvalsShow that the recurring control happened — not only that a policy says it should.
• Retain vulnerability, backup/recovery, incident, and risk-assessment recordsThese are the samples auditors often request. If it is not findable, it did not happen for evidence purposes.
• Store evidence somewhere organized and retrievableA shared drive with folders by control is enough at first. Searchable beats screenshots in random Slack threads.

• Review unresolved gaps and confirm scope before fieldworkWalk the remaining holes with owners. Confirm systems and criteria still match what the auditor expects.
• Organize evidence, name evidence owners, and verify policy approvalsKnow who will pull each sample. Confirm policies are approved and current, not draft copies.
• Prepare explanations for exceptions and coordinate with the auditorMissed reviews and one-off emergencies will come up. Write the facts down. Software does not replace the CPA firm.