SOC 2 Compliance Checklist for Small Teams: What to Do First and What Auditors Actually Fail

Before you write a policy or change a setting, make three decisions: which systems the audit covers (your scope), which report you are buying, and which CPA firm will sign it. The next two sections walk through those decisions, and the one after gives you a week-by-week plan to get ready. For pre-seed companies, one product audited against Security alone is almost always the right start.

The controls after that start where audits most often go wrong, not with criterion number one. In the CBIZ 2024 SOC Benchmark Study of 193 SOC reports, failed user access reviews were the top reason for a qualified opinion (a report where the auditor says a control did not hold up). User access reviews (15.6%), terminations (12%), and change management (11.7%) were among the most common causes of control exceptions. So start with access control (CC6) and change management (CC8), then work through risk assessment (CC3), monitoring (CC7), and vendor management (CC9.2).

Each control item says what to do and names the evidence the auditor will ask to see, so you know when an item is done. To get this list as a file for your own scope and team size, use the SOC 2 checklist template, which downloads as Excel or PDF.

Decide what the audit covers before any control work, because the auditor tests every control inside that line and nothing outside it. Your scope is a system, not your whole company: the product or service your customers buy, plus the infrastructure, code, data stores, people, processes, and vendors that keep it running.

Not every system you run has to be in scope. Internal tools that never touch customer data or production, such as your marketing site or a team wiki, can usually stay out. A tighter boundary means fewer controls for the auditor to test and less evidence for you to collect.

Use one rule for each system: if it stores or processes customer data, can change production, or controls who can reach either one, it is in. If it does none of those, leave it out. When you are unsure about a system, ask your auditor while you plan, not during fieldwork.

For a 10-person team the list is usually short: one product, its cloud account, the code repository and deploy pipeline, the identity provider, and the vendors that hold customer data. Write it down. The boundary becomes part of your system description, the section of the report that tells readers what the audit covered. Management is responsible for it, though the auditor often drafts it with you (Linford & Co).

Decide which report you are buying, which criteria it covers, and which CPA firm will sign it before you start control work, so your readiness plan has a date to aim at.

The recommended path: go straight to a security-only Type 2 with a 3-month observation window. A Type 2 is the report enterprise buyers ask for, because it shows your controls worked over a stretch of time rather than on a single day. Type 2 reports generally cover 3 to 12 months (BARR Advisory), so choose the 3-month end of that range and your first report arrives sooner.

Security-only means the audit tests one Trust Services Criterion: Security (the Common Criteria), which every SOC 2 report must include and which is the right choice on its own for a first audit. Add Availability or Confidentiality only when a customer or a contract you signed asks for it. Plenty of reports include them (75.3% and 64.4% of the 73 reports in the CBIZ 2024 SOC Benchmark Study), and you can add either one at renewal.

The option: a Type 1 is the cheapest and fastest report. It is the auditor's opinion on your controls at a single point in time, so there is no observation window to wait through: the audit can start as soon as your controls are in place and documented (BARR Advisory). Choose it if you must hand a prospect a report in under about 3 months. The SOC 2 Type 1 vs Type 2 guide compares the two in detail.

For the auditor, MJD Advisors is a peer-reviewed, US-based CPA firm. With MJD, a SOC 2 Type 2 starts at $7,500/yr and a SOC 2 Type 1 starts at $5,000.

Whichever firm you choose, check its peer review. CPA firms that issue SOC 2 reports have their audit practice reviewed by another firm every three years, and the result is publicly searchable on the AICPA site (Linford & Co). That means your buyer's security team can check the firm that signed your report, so ask any auditor for its latest peer review letter before you sign. The guide to choosing a SOC 2 auditor lists the other questions to ask.

MJD Advisors is SimpleAudit's audit partner.

Six weeks of focused work gets a 10-person team audit-ready, and it is the same work whichever report you buy. Audit-ready means your Type 2 observation window (or your Type 1 fieldwork) is booked to start.

• Week 1: Write down your scope (the product and the systems, people, and vendors behind it), book the auditor and a fieldwork date, turn on centralized logging (log retention counts from the day you turn it on), list your people, systems, and vendors.
• Week 2: Approve your security policies, run the risk assessment, build the risk register, tier your vendors.
• Week 3: Enforce MFA and SSO, remove stale accounts, run and record the first access review, write the offboarding checklist.
• Week 4: Turn on branch protection and required review, run a vulnerability scan and a penetration test, test a backup restore.
• Week 5: Collect training records and signed confidentiality agreements, approve the incident response plan, start the incident log.
• Week 6: Gather the 10 evidence items, self-test each one, fix gaps; your observation window (or Type 1 fieldwork) starts at the end of the week.

Six weeks assumes the basics already exist: SSO, MFA, and a code review on every change. If you are starting from nothing, plan for 8-10 weeks. To see the range for your own team size and starting point, use the SOC 2 timeline estimator.

What a first audit actually teaches you: I led SOC 2 at a prior company before building SimpleAudit, and four months of preparation went into a first three-month Type 2 window. Most of that time went to things no checklist warned me about.

Start the employee-facing changes in week one. Technical controls can be set up in a weekend; getting people to change how they work takes months. Converting remote laptops to managed devices sounded simple. About 30% converted cleanly and the other 70% needed troubleshooting one machine at a time. Policy sign-offs, security training and device enrolment all depend on people, so they go first.

You do not need a five-figure gap assessment. The Trust Services Criteria are public and the gaps small teams have are common. Compare what you do today against each section below, write down what is missing, and rank the list by risk and effort. That list is your plan.

Write policies that describe what you actually do. The auditor tests whether you follow your own policies. A quarterly access review you have never run is a finding waiting to happen; a monthly one you do run is fine.

There is no pass or fail. Anything the auditor finds that conflicts with your policies becomes a finding in the report, with your management response beside it. Buyers read both and decide whether the risk is acceptable, and often it is. Aim for honest, consistently operated controls rather than a perfect first report.

Once you have signed with the CPA firm and the observation window has started, ask for a letter confirming you are in an audit period. It often satisfies a prospect while you wait for the report, at no extra cost, and it is one reason to go straight to a Type 2 rather than paying for a separate Type 1 report.

The pitfalls that cost the most: planning for less than three months of preparation, treating training and policy acknowledgments as paperwork (auditors check them), forgetting that vendors who process your data are inside your report, and letting everything lapse after the first report instead of putting the reviews on the calendar.

For a printable version to work through, the open-source SOC 2 readiness checklist on GitHub mirrors these sections.

Start your control work here, because failed user access reviews are the top reason auditors qualify an opinion (CBIZ 2024 SOC Benchmark Study).

MFA everywhere (CC6.1): Require multi-factor authentication on your identity provider, cloud console, code repository, and every other system that can reach customer data or production. Turn it on as an enforced setting, not a request in the team chat. Evidence: screenshots or exports of the enforcement setting in each system.

SSO and role-based access (CC6.1): Send logins through one identity provider, and give each person the access their role needs rather than whatever they asked for. Write down the roles you have and what each one can reach. Evidence: your role list and an export of current users with their roles.

Provisioning (CC6.2): Grant new access only through a request that someone other than the requester approves, founders included. Evidence: access request tickets showing who asked, who approved, and when access was granted.

Offboarding (CC6.2): Revoke all access within 24 hours of someone leaving and collect their company devices. Work from a written checklist so no account is missed. Evidence: an offboarding ticket showing each account disabled and the date.

Quarterly access review (CC6.2): Every quarter, export the user list from each key system, confirm each account still needs its access, and remove the ones that do not. Evidence: the signed-off review listing the accounts checked, who checked them, what was removed, and the date.

Service accounts (CC6.1): Give every non-human account and API key a named owner. Protect it with MFA where the system allows, and otherwise rotate its keys on a schedule you write down. Evidence: a list of service accounts with owners and the last rotation date for each key.

Change management is another common cause of control exceptions (CBIZ 2024 SOC Benchmark Study), and for a small team it comes down to a few settings in your code repository.

Required code review (CC8.1): Require an approving review from someone other than the author before any change merges to your main branch. Evidence: a few merged pull requests, each showing a reviewer approved it before the merge.

Branch protection (CC8.1): Turn on branch protection for your default branch so no one, admins included, can push straight to it or merge without the required review and passing checks. Evidence: a screenshot or export of the branch protection settings.

Emergency changes (CC8.1): When a fix has to ship without review, for example during an outage, record what changed and why, and have someone review it after the fact. Evidence: the emergency change record with its after-the-fact review.

Separate writing from deploying (CC8.1): Where your team is big enough, the person who writes a change should not be the only person who can deploy it. If you are too small for that, have a second person review each production deploy after it ships, and write that rule down. Evidence: your deploy permissions, or the log of those after-the-fact reviews.

Most of this section is documents you write once and then review on a schedule. The SOC 2 policies list names all 19 core policies.

Information security policy (CC1.1): Write down what you commit to on security, who owns it, and when the policy gets reviewed, then have management approve it and every employee acknowledge it. Evidence: the approved policy with its approval date and the employee acknowledgment records.

Risk assessment (CC3.1, CC3.2): List what could go wrong with your systems and data, rate how likely and how damaging each risk is, and decide what you will do about each one. Repeat it on the schedule your policy sets. Evidence: the dated risk assessment document.

Risk register (CC3.2): Keep every risk in one register with an owner, a mitigation plan, and a review date. SimpleAudit generates a starting risk register from your company profile. Evidence: the register itself, with an owner and a review date on every risk.

Management oversight (CC1.2): Show that leadership looks at security decisions on a schedule. For a startup this can be a quarterly founders' review with written notes. Evidence: the notes from your most recent review.

Code of conduct (CC1.1): Set out what you expect from everyone on handling data, acceptable use, and reporting problems, and have each employee acknowledge it. Evidence: the code of conduct and the signed acknowledgments.

For monitoring, the auditor wants to see history, so turn these on early.

Logging and alerting (CC7.2): Send login events, admin actions, and production changes to one central log, keep them for the period your policy sets, and alert a named person when something suspicious happens. Evidence: your logging and alerting settings, including how long logs are kept.

Incident response plan and incident log (CC7.3, CC7.4): Write down how you detect, respond to, and recover from a security incident and who does what. Then record every incident in a log, small ones included. Evidence: the approved plan with its date, and the incident log even if it is empty.

Vulnerability scanning with patch deadlines (CC7.1): Scan your systems for known vulnerabilities on a set schedule, and write down how quickly you patch each severity level. Evidence: recent scan reports and tickets showing critical findings fixed within your deadline.

Backups with a restore test (CC7.5): Back up production data automatically, then restore from a backup to prove it works. Write down how much data you can afford to lose and how fast you need to be running again. Evidence: your backup settings and a dated record of your last restore test.

For a small team, vendor management comes down to one list you keep current.

Vendor list with risk tiers (CC9.2): List every vendor that stores, processes, or can reach your customer data, what it does for you, and a risk tier (high, medium, or low) based on what it can touch. Evidence: the vendor list with a tier for each vendor.

Reports for high-risk vendors (CC9.2): For each high-risk vendor, collect its SOC 2 report or a completed security questionnaire, and read the section that lists exceptions. Evidence: the reports you collected, filed against each high-risk vendor.

Contract terms (CC9.2): Check that contracts with high-risk vendors cover data protection, breach notification, and your right to ask for security information. Evidence: the signed contract clauses or data processing agreement for each high-risk vendor.

Annual re-review (CC9.2): Go back through the vendor list once a year and update each tier. Track when vendor certifications expire and request updated documentation. Evidence: the dated review notes and the current report for each high-risk vendor.

These controls protect customer data wherever it is stored and whenever it moves.

Encryption at rest (CC6.1): Encrypt databases, file storage, and backups with AES-256 or equivalent. Your cloud provider usually offers this as a setting. Evidence: screenshots of the encryption setting on each data store.

Encryption in transit (CC6.1): Require TLS 1.2 or higher on every connection and redirect HTTP to HTTPS. Use certificate management so certificates renew before they expire. Evidence: a TLS scan of your public endpoints and the renewal settings for each TLS/SSL certificate.

Data classification (CC6.5): Define a short set of data categories (public, internal, confidential, restricted) and say which controls apply to each. Evidence: your data classification policy.

Data retention and disposal (CC6.5): Decide how long you keep each type of data and how you delete it when that time is up. Evidence: your retention schedule and a record of a recent deletion.

These controls cover the people who can reach your systems while they work for you, and offboarding sits under access control above because that is where auditors test it.

Background checks (CC1.4): Run background checks, where local law allows, on people who will have access to production or customer data. Evidence: a record that each check was completed before access was granted.

Security awareness training (CC1.4): Train every employee at onboarding and once a year on phishing, handling data, and reporting incidents. Evidence: training completion records for every current employee.

Confidentiality agreements (CC1.4): Have every employee and contractor sign a confidentiality agreement before they get access to company systems. Evidence: signed agreements dated before each person's first access.

Your first audit should cover Security alone. Add one of these criteria only when a customer or a contract you signed asks for it; you can add it at renewal. Availability items carry A1 codes, Confidentiality C1, Processing Integrity PI1 and Privacy P1-P8.

Capacity monitoring (A1.1): Track storage, compute and traffic against their limits and alert a named person before you run out. Evidence: your capacity alerts and the last capacity review.

Recovery plan (A1.2): Write down how you restore service after an outage, with your target recovery time and how much data you can lose, and keep backups in a separate account or region. Evidence: the approved recovery plan and your backup location settings.

Recovery test (A1.3): Restore from a backup to a working system at least once a year and record how long it took against your target. Evidence: the dated test record with the measured recovery time.

Confidential data inventory (C1.1): List the information customers and contracts tell you to keep confidential, where it is stored, and who can reach it. Evidence: the inventory, tied to your data classification policy.

Confidential data disposal (C1.2): Delete confidential information when its retention period ends or a customer leaves, and record each deletion. Evidence: deletion records or customer deletion confirmations.

Processing definitions (PI1.1): Write down what your system processes and what complete, accurate and on-time output looks like. Evidence: the processing documentation.

Input checks (PI1.2): Check data as it enters the system and reject or flag records that are incomplete or invalid. Evidence: the validation rules and a sample of rejected-input logs.

Processing monitoring (PI1.3): Alert someone when a processing job fails or runs late, and record how each error was fixed. Evidence: job alerts and the error tickets.

Output checks (PI1.4): Reconcile outputs against inputs, or spot-check them, before customers rely on them. Evidence: reconciliation reports or spot-check records.

Privacy notice (P1.1): Publish a notice that says what personal information you collect, why, who you share it with and how long you keep it. Evidence: the published notice and its last review date.

Consent and choices (P2.1): Record consent where your notice or the law requires it, and honor opt-outs. Evidence: consent records and opt-out handling.

Retention and deletion (P4.2): Delete personal information when the period in your notice ends. Evidence: your retention schedule and a recent deletion record.

Sharing with consent (P6.1): Keep a list of every outside party you share personal information with, and share only as your notice allows. Evidence: the sharing list and the matching agreements.

Access and correction requests (P5.1): Answer requests to see, correct or delete personal information within the deadline you publish. Evidence: a request log with dates received and completed.

Most auditors open an engagement by asking for these ten artifacts, so have each one in a folder before your observation window or fieldwork starts.

1. Your most recent access review: the list of accounts reviewed, who reviewed them, what was removed, and the date it was signed off.
2. An offboarding ticket for someone who left, showing each account disabled and the date. If no one has left yet, the offboarding checklist you will use.
3. Screenshots or exports showing multi-factor authentication is required on your identity provider, cloud console, and code repository.
4. Branch protection settings on your main code repository, plus a few merged pull requests that show a reviewer approved each change before it shipped.
5. Your risk assessment and risk register, with an owner and a review date on every risk.
6. Your logging and alerting settings, showing security events are captured and how long they are kept.
7. Your vendor list with a risk tier for each vendor, and the security reports you collected for the high-risk ones.
8. Your incident log, even if it is empty, and your incident response plan with the date it was approved.
9. Your information security policies, with the date management approved them and a record that every employee acknowledged them.
10. Security awareness training completion records for every current employee.

Use the last week to check your own work the way the auditor will.

Self-test the 10 evidence items: Pull the actual artifact for each item in the list above and ask whether someone outside your team could tell from it what was done, by whom, and when. If you cannot find it quickly, the auditor will not either. Keep everything in one place, such as SimpleAudit's Evidence Vault, which keeps version-controlled evidence with a full audit trail.

Confirm policy approval dates: Every policy should show the date management approved it, and that date should fall before your observation window or fieldwork starts. Check that every employee acknowledgment is on file too.

Run a last gap check: Walk through the control sections above in order and mark anything that has no evidence yet. B2B SaaS companies frequently find gaps in change management and vendor risk, so check those two first. Fix what you can this week, and tell your auditor about anything you cannot fix before fieldwork starts, not during it.