SOC 2 readiness is the work that happens before an auditor ever looks at your systems. People often call the outcome a “SOC 2 certification”, but technically SOC 2 is an attestation report issued by an independent licensed US CPA firm — nobody “certifies” you, and no consultant can issue the report. What a consultant like BALTUM does is get the company ready: scope, gap analysis, policies, controls, evidence and audit support. This article lays out the readiness process we follow and ends with a checklist you can use internally.
Step 1. Decide why you need SOC 2 and which report type
Start with the customer or prospect who is asking. If they need “a SOC 2 report” quickly, a SOC 2 Type 1 report — which evaluates the design of controls as of a point in time — is the fastest route. If their procurement or security team requires proof that controls operated effectively over time, you need SOC 2 Type 2, with an observation period that typically runs 3 to 12 months.
This is also the moment to consider combining SOC 2 with ISO 27001. The two frameworks overlap heavily in policies and controls, and preparing for both at once is considerably cheaper than doing them one after another. See our SOC 2 + ISO 27001 package for how that works.
Step 2. Define the scope and Trust Services Criteria
SOC 2 is built on the AICPA Trust Services Criteria (TSC). Only Security (the Common Criteria) is mandatory. Availability, Confidentiality, Processing Integrity and Privacy are added based on what you promise customers. A typical SaaS company picks Security plus Availability, sometimes Confidentiality.
Scope drives everything downstream: which systems, teams, cloud accounts and subprocessors the auditor will examine. A frequent mistake is to scope the entire company when customers only care about one product. A narrow, clearly described scope means fewer controls, less evidence and a lower audit fee.
Step 3. Run a gap analysis
The gap analysis answers one question: where are we today relative to the TSC? We walk through each criterion and classify the result:
- the control exists and is documented — just collect evidence;
- the control exists in practice but is not formalised — write the policy and procedure;
- the control does not exist — design and implement it.
The output is a prioritised roadmap with owners and deadlines. It is also the only honest basis for estimating cost and timeline.
Step 4. Write policies you will actually follow
A SOC 2 policy set usually contains 15–25 documents: information security, access control, change management, incident response, business continuity, vendor management, acceptable use, risk management, secure development and so on. The golden rule: a policy must describe how you really operate. Auditors test the match between the document and practice, and a mismatch is the most common source of exceptions in a report.
Step 5. Implement technical and organisational controls
For most cloud-native companies on AWS, Azure or Google Cloud the core control set looks like this:
- Multi-factor authentication and single sign-on for all critical systems.
- Centralised access management with periodic access reviews.
- Encryption at rest and in transit.
- Logging, monitoring and alerting for security events.
- Vulnerability management: scanning, patching, periodic penetration testing.
- A formal change process: pull requests, code review, separate environments.
- Backups with tested restores.
- Background checks, security awareness training and an offboarding procedure.
- Risk assessment and vendor (subprocessor) review.
Most of this can be achieved with native cloud and identity-provider features. Compliance automation platforms help with evidence collection, but they do not replace the controls themselves.
Step 6. Collect evidence from day one
Auditors rely on artefacts: configuration screenshots, log exports, access-review records, change tickets, signed policy acknowledgements. For a Type 2 report evidence must cover the whole observation period, so the collection process has to be in place before the period starts. We recommend a simple matrix of control, owner, evidence and frequency.
Step 7. Choose the CPA firm and go through the audit
Only a CPA firm working under AICPA standards (SSAE 18 / AT-C 205) can issue a SOC 2 report. We agree scope and schedule with the audit team, and during fieldwork we answer requests and explain controls on your behalf. Indicative audit fees for small and mid-sized companies: roughly $8–20k for Type 1 and $15–40k for Type 2, depending on scope and period length. Readiness costs depend on how many gaps the analysis finds.
Indicative readiness timeline
| Phase | Duration | Deliverable |
|---|---|---|
| Scoping and gap analysis | 2–3 weeks | Roadmap |
| Policies and control implementation | 6–12 weeks | Operating controls |
| Type 1 audit | 3–6 weeks | Type 1 report |
| Type 2 observation period | 3–12 months | Evidence history |
| Type 2 audit | 4–8 weeks | Type 2 report |
Common SOC 2 readiness mistakes
- Buying template policies and never adapting them to real processes.
- Over-scoping and ending up with far more controls than customers require.
- Starting the observation period before controls genuinely operate.
- No named owner for each control.
- Treating the report as permanent — see our article on the SOC 2 bridge letter and continuous compliance.
The SOC 2 readiness checklist
- Report type, scope and TSC categories are defined.
- Gap analysis done, roadmap with deadlines approved.
- Policies approved and acknowledged by staff.
- MFA, encryption, logging and backups enabled and documented.
- Risk assessment and vendor review completed.
- Evidence collection mapped to every control.
- CPA firm selected and audit dates agreed.
If you are planning a SOC 2 audit and want an honest view of how much work it will take for your company, request a quote — we will run a preliminary readiness assessment and propose a plan and budget. You may also find our guide on SOC 2 for Ukrainian IT companies useful.