SOC 2 readiness checklist for small teams

What SOC 2 readiness means for a small team

A SOC 2 report is an attestation issued by a licensed CPA firm. It describes your system and gives the auditor's opinion on your controls, measured against the AICPA's 2017 Trust Services Criteria. It is a report, not a certification: there is no certificate to hang on the wall, and the auditor decides what evidence is enough.

Being "ready" for the audit comes down to three things. You know exactly what is in scope. Your controls are designed and written down. And, if you are going for a Type 2 report, those controls have been running long enough to leave a trail of evidence. This SOC 2 readiness checklist breaks audit preparation into seven phases, each with a short list you can work through.

For startups the hard part is rarely technical complexity. It is consistency: doing the same reviews on time, every time, and being able to prove it months later.

Phase 1: Define your scope

Scope drives everything else, so decide it first and write it down. A narrow, well-understood scope is easier to operate and to audit.

• List the systems in scope. The product or service customers buy, plus the infrastructure, data stores, identity provider, code repositories and tools that support it or touch customer data.
• Draft a system description. A few pages on what the service does, the infrastructure and software behind it, the people who run it, the data it handles and the procedures that keep it running. The final report includes one.
• Choose the Trust Services Categories. Security (the Common Criteria, CC1 to CC9) is required in every SOC 2 report. Availability, Confidentiality, Processing Integrity and Privacy are optional. Add one only when customers ask for it or it is central to what you sell.
• Pick the report type. A Type 1 report looks at the design of your controls at a point in time. A Type 2 report also tests whether they operated effectively over a period. See SOC 2 Type 1 vs Type 2 for how to choose.
• Set the audit period. For a Type 2, agree the observation window. Windows of 3 to 12 months are common; your auditor and your customers' expectations shape yours.
• List your subservice organizations. Your cloud host and other providers that run part of your system. Collect their own SOC reports, and expect the auditor to ask how you oversee them.

Phase 2: Name the people

Every control needs a person behind it. In a small team one person will wear several hats, and that is fine, as long as it is written down and nobody approves only their own work.

• A compliance owner. One person accountable for the program as a whole: the schedule, the gaps and the relationship with the auditor.
• Policy owners. One owner per policy, who keeps it accurate and current. The engineering lead owns change management; whoever runs IT owns access control.
• Control owners. One owner per recurring activity, such as access reviews, scan reviews or vendor reviews.
• Approvers. Someone other than the author signs off on each policy and each piece of evidence. In a five-person company, founders can approve each other's work. Self-approval is not automatically a finding, but auditors may ask about it.
• Management oversight. A regular meeting where leadership reviews security, risks and open issues, with notes kept.
• A source of truth for staff. An accurate list of employees and contractors, with start and end dates. Auditors often sample from it.

Phase 3: Get policies written, approved and acknowledged

Policies are where auditors start. They read what you say you do, then test whether you do it. Our guide to which policies you need for SOC 2 covers the full set.

• Write the core set. Information security, acceptable use, access control, change management, incident response, risk management, vendor management, data classification and business continuity, plus any your chosen categories add.
• Tailor every template. Remove statements you don't follow and add the ones you do. A policy that promises more than you deliver creates exceptions.
• Approve each policy formally. Record who approved which version, and when. "We all agreed in a chat thread" is hard to evidence.
• Set review dates. Annual review is the usual baseline. Record each review, even when nothing changes.
• Collect acknowledgements. Employees confirm they have read the policies that apply to them, new hires when they join, and everyone again after a meaningful change.
• Keep the history. Older approved versions and their acknowledgements stay on record. An auditor testing a Type 2 period needs to see what was in force at the time.

Phase 4: Get your controls operating

A control only counts when it runs. Before a Type 1, each control should exist and have run at least once. Before and during a Type 2 window, it should run on its stated schedule without gaps. The table lists controls most small teams start with; the cadences are common choices, not rules.

The backup row maps to Availability, but most teams test restores even when that category is out of scope, because a backup nobody has restored is an assumption. Security awareness training (usually annual, with a completion roster) belongs on the list too.

• Give every control an owner and a written procedure, even a short one.
• Put every recurring control on a calendar with due dates, aligned to your fiscal year if your reporting follows it.
• Have each completed run reviewed and approved by someone other than the person who did it, where you can.
• When a run is genuinely not needed (no vendors added this quarter, say), record the reason instead of leaving a silent gap.

Phase 5: Organize your evidence

Audit preparation goes faster when evidence is filed as you go, not hunted down the week before fieldwork. SOC 2 evidence collection goes into this in depth.

• One location. All evidence in one place, organized by control and by period, not scattered across inboxes and drives.
• Dated and attributable. Each item shows what was done, by whom and when. Screenshots should show dates; exports should carry the date they were taken.
• Mapped to criteria. A controls matrix that links each criterion to the policies and activities that address it, so you can spot gaps before the auditor does.
• Tamper-evident. Approved evidence should not be quietly edited afterwards. If it changes, the change should be visible.
• Access-controlled. Access exports and pen test reports are sensitive. Limit who can see them, and plan view-only access for the auditor.

Phase 6: Choose an auditor and ask the right questions

Only a licensed CPA firm can issue a SOC 2 report. Firms differ in experience with small companies and in how they work, so talk to more than one.

• Have you audited companies of our size, on a similar technology stack?
• Which report type and audit period do you recommend for us, and why?
• Do you offer a readiness assessment, and how do you keep it independent of the audit itself?
• What format do you want evidence in? Will you work from exports and pages we share, or do you need access to our systems?
• How do you sample, and when will we get the full request list?
• How do you treat our subservice organizations, such as our cloud host?
• What is the timeline from the end of the period to the final report, and who will be on our engagement?
• What does the fee cover, and what would cost extra?

Phase 7: The weeks before fieldwork

Fieldwork is when the auditor tests your controls. The final stretch of SOC 2 audit preparation is about closing gaps.

• Get the request list early and map every item to the evidence you already have. Anything unmapped is a gap to close now.
• Clear the overdue items. Late access reviews, policies past their review date, missing acknowledgements, unapproved evidence.
• Check separation of duties. Find anything approved only by its own author and decide whether to have it reviewed again.
• Prepare populations. Lists of joiners and leavers, changes, incidents and vendors for the period. Auditors commonly sample from these.
• Finalize the system description and review management's assertion with your auditor.
• Run a walkthrough. Each owner explains their control in two minutes and shows one piece of evidence. Weak spots show up fast.
• Set up auditor access to the evidence, view-only, and test it.

Getting to SOC 2 readiness in Confluence

If your team already writes in Confluence Cloud, Compliance in a Box covers much of this checklist in one space, running on Atlassian with no external services.

• Scope and structure. In Settings you choose your employee and Compliance Admins groups, your company profile and fiscal year, then the app creates a dedicated compliance space. You tick the Trust Services Categories in scope (Security is always included) and it generates the page tree: with every category, 24 policy templates and 15 recurring activities. Categories can be added later.
• People. Under Owners & approvers each policy and activity gets an owner and one or more approvers. Managed pages are locked so only the owner and Compliance Admins can edit them.
• Policies. Owners edit the drafts in the normal Confluence editor and submit a version. Approvers approve that exact page version, and an edit before approval cancels the submission. Employees acknowledge with one click, and a material change asks them again.
• Controls. Recurring activities such as User Access Review, Vulnerability Scan Review and Vendor Risk Review open their own dated evidence pages on schedule, with due dates, reminders and approvals. Skipping a period needs a written reason.
• Gaps. The Dashboard shows overdue items, reviews coming due and acknowledgement completion, and flags work approved without an independent approver.
• Evidence. The Evidence & Reports pages (policy approval log, acknowledgement report, activity completion report and audit log) and a SOC 2 controls matrix are generated and refreshed daily. An optional Auditors group gets view-only access to them.

Some items stay outside the app: onboarding and offboarding checklists, scanning itself and choosing your auditor. The templates and control mappings are a starting point, not legal or audit advice, so have them reviewed. The app is free for up to 10 users with every feature included. Getting started walks through setup step by step.

SOC 2 readiness FAQ

How long does SOC 2 readiness take?

It depends on how much already exists. A Type 1 can follow once your controls are designed and have run at least once. A Type 2 also needs the observation window itself, commonly 3 to 12 months, so plan backwards from when customers need the report.

Do we need a readiness assessment?

It is optional. Some teams pay for one to find gaps early; others work through a checklist like this one.

Can a very small startup get a SOC 2 report?

Yes. Keep the scope narrow, write policies that match how you really work, and arrange approvals so nobody only approves their own work. The criteria are the same for every company size; how you meet them can be simpler.

← All articles