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.

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.

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.

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.

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.

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.