Most SOC 2 content stops at readiness. This is about the audit: how to choose the firm, what to have in place before you call one, and what happens once they start testing.
The single most useful thing to understand up front: the audit is not the hard part. Preparation is. Teams that fail do not fail fieldwork, they arrive at fieldwork with controls that have not been operating long enough to sample.
Only a CPA firm can do this
SOC 2 reports can only be issued by a licensed CPA firm. That is a legal constraint, not a preference or a quality signal. Plenty of excellent security consultancies will get you ready, and compliance platforms will organise your evidence, but the opinion has to be signed by a CPA firm.
This matters commercially, because it means there are two purchases, not one, and they are often confused in budgeting.
| Purchase | Who provides it | What you get |
|---|---|---|
| Readiness | Consultancy or compliance platform | Gap assessment, policies, evidence collection, control mapping |
| The audit | Licensed CPA firm | Testing, the opinion, and the report itself |
| Penetration test | Security firm, or your platform if it runs them | An annual external test auditors expect as evidence |
What to do before you call an auditor
Calling early is fine, and booking early is essential. But there is a difference between a scoping conversation and starting the engagement. Have these in place before the engagement begins, because every one of them is cheaper to fix on your own clock than on theirs.
The pre-engagement list. Nothing here needs an auditor to tell you it is missing.
Decisions you must make yourself
0/4An auditor will help you think about these, but they cannot make them for you, and changing them mid-engagement triggers a change order.
Controls that must be operating, not just designed
0/10For a Type II, these need history. A control switched on the week before fieldwork produces a sample of one.
Paperwork
0/5Choosing the firm
Fee is the easiest thing to compare and the least useful. Ask these instead.
A firm that mostly audits banks or healthcare systems will run a heavier process than a fifty-person SaaS needs, and will price accordingly. You want someone who has done your shape of company many times.
Ask whether the people testing are employees or contractors, and whether the partner you are talking to will be involved after signature. A cheap fee with high turnover on the engagement team costs you in re-explaining your architecture.
Two to four weeks is normal. Eight to twelve is not, and it will wreck a deal timeline. Get it in the engagement letter if the date matters.
Some firms work happily from a platform auditor portal. Others insist everything is re-uploaded to their own system, which is a real hidden cost in hours. Ask before you sign, and ask specifically about the platform you use.
Scope creep mid-audit is the usual cause of a surprise invoice. Get the triggers written down: adding a criterion, adding a system, extending the period, re-testing after remediation.
A redacted sample tells you how they write, how they describe exceptions, and how readable the result will be for your customers. The report is a sales document as much as a compliance one.
Ask this first, not last. Good firms book out by quarter and their calendar will drive your report date more than your own readiness does.
The prep timeline
For a company of twenty to a hundred people on a reasonably modern cloud stack, starting without a programme. The variable is almost never the audit.
Scoping and gap assessment
1-3 weeksDecide criteria, systems and period. Identify what is missing against the criteria. Book the auditor now, not later.
Owner: You, optionally with a readiness partner
Remediation
3-8 weeksWrite the policies, close the MFA gaps, fix branch protection, set log retention, run the risk assessment, get BAAs and vendor reviews in order. This is the bulk of the work and the phase that slips.
Owner: Engineering and whoever owns the programme
Type I fieldwork and report
2-4 weeksOptional. Worth it if a deal is blocked now. The auditor tests design, not operation, so it can happen as soon as controls exist.
Owner: CPA firm
Type II observation window
3-12 monthsControls run and you evidence them continuously. This cannot be compressed. Three months is the floor; six or twelve reads better to enterprise buyers.
Owner: You
Type II fieldwork
1-3 weeksSampling across the whole window, walkthroughs, interviews. Short if your evidence is organised, painful if it is not.
Owner: CPA firm
Report
2-6 weeksDraft, management response, final. Then the next observation window starts, usually the day after the last one ended.
Owner: CPA firm
How sampling decides your result
For a Type II the auditor does not review every access change you made in twelve months. They pick a sample and test it, and sample size scales with how often the control runs.
| Control frequency | Typical sample | Example |
|---|---|---|
| Annual | 1 | The annual risk assessment |
| Quarterly | 2 | Quarterly access reviews |
| Monthly | 2 to 5 | Monthly vulnerability scan review |
| Weekly | 5 to 15 | Weekly backup verification |
| Daily | 15 to 25 | Daily log review |
| Many times daily | 25 to 60 | Code changes, access grants, onboarding |
The practical consequence is that consistency beats intensity. A control performed eleven times out of twelve months will almost certainly pass. A control performed once, in month eleven, because somebody remembered, will almost certainly be caught.
What an exception actually means
If a control did not operate as described, the auditor records an exception. This is where people panic unnecessarily.
SOC 2 reports are not pass or fail. The auditor issues an opinion, and exceptions are described in the report alongside your management response. A report with two well-explained exceptions and a clear remediation plan is a completely normal artefact that enterprise buyers accept routinely.
What you want to avoid is a qualified or adverse opinion, which happens when exceptions are severe or numerous enough that the auditor cannot conclude the controls were effective. That is uncommon and usually means the programme was not ready for the window it committed to.
After the report
- The report covers a window that ended before you received it. Customers asking months later will want a bridge letter, a short statement that nothing material has changed since period end. Your auditor can advise on wording.
- The next window usually begins the day after the last one ended. Type II is continuous, not annual-with-a-break.
- Teams that treat the report as a finish line spend the following year reconstructing evidence from scratch. The second audit is an operating rhythm, not a project.
Where Evidr fits, and where it does not
To be direct, since we make one of the platforms in this space. Evidr does not audit you and cannot issue your report; only a CPA firm can. What it does is the preparation and the evidence side.
- Pulls configuration evidence on a schedule from AWS, Azure, GCP, GitHub, Okta, Google Workspace, Microsoft 365 and sixteen more, read-only, so nobody takes screenshots.
- Maps one piece of evidence to every control it satisfies across all fourteen frameworks, so a second framework does not mean collecting everything twice.
- Reviews every uploaded file with AI, gives it a confidence score, and flags credentials or sensitive data before an auditor sees them.
- Tracks evidence expiry, so a stale policy acknowledgement surfaces in month two rather than during fieldwork.
- Runs your penetration test in-house rather than referring it out, against your live application.
- Gives the auditor a scoped read-only portal showing approved evidence and policies only, with every action they take logged.
- On the higher tiers, a dedicated support engineer and on-call onboarding assistance, and custom plans built around specific requirements if the standard tiers do not fit.
What it will not do: choose your scope, run your risk assessment, or make an unready programme pass. The controls still have to be real and they still have to have been operating.