SOC 2 Readiness in 90 Days
This is for founders and executives whose customers have started asking for a SOC 2 report. For many cloud-based companies with 30 to 500 people, reaching audit readiness in about 90 days is realistic if leadership commits time and scope stays tight. Readiness is the point where you can begin an audit. Depending on the report type, the report itself may arrive months later.
What is the difference between SOC 2 Type 1 and Type 2?
SOC 2 is an attestation report issued by an independent CPA firm under standards set by the AICPA. It evaluates your controls against the Trust Services Criteria. Security is the required category. Availability, confidentiality, processing integrity, and privacy are optional.
A Type 1 report says your controls were designed appropriately at a single point in time. A Type 2 report says they operated effectively over a period, commonly somewhere between three and twelve months, agreed with your auditor. Most enterprise buyers ultimately want Type 2. Some will accept a Type 1 as a first step while your Type 2 period runs. Ask your key customers which they need before you plan anything.
What does "ready" mean at day 90?
At day 90 you should have a defined scope, adopted policies that match how you actually work, controls that are running, evidence being collected (automatically where possible), and an auditor engaged. You should also have completed a readiness review, internal or external, that found no major gaps. If all of that is true, you can start a Type 1 audit or begin a Type 2 observation period.
How should you sequence the 90 days?
Sequence by risk, then by audit need. The controls that protect you most tend to be the ones auditors examine closely anyway.
Days 1 to 30: define scope and find gaps. Decide which systems, data, and teams are in scope, and keep it as small as your customers allow. Then fix the highest-risk items first: single sign-on and multi-factor authentication on critical systems, prompt removal of access when people leave, and backups that are tested and known to work.
Days 31 to 60: build the core program. Put change management in place so production changes are reviewed before they ship. Set up vendor risk reviews, security awareness training, device management for laptops, and logging on production systems. Write policies that describe these controls as they actually operate.
Days 61 to 90: operate and prove it. Run the controls, collect evidence, and fix what breaks. Run a tabletop exercise (a guided walk-through of a mock incident) to test your incident response plan. Select your auditor and agree on the audit window.
Where do teams waste money?
The most common waste I see is buying a compliance automation platform before scope is defined. These tools can save real time, but only after you know what you are automating. Decide scope first, then choose the platform.
Other common waste: adding optional Trust Services Criteria your customers never asked for, buying new security tools for controls a simple process would satisfy, paying for template policies that nobody reads or follows, and scheduling a penetration test before the fixes it would find are in place. Each of these adds cost without making you safer or the audit easier.
What slows teams down?
Rarely the technology. The usual blockers are executive time, engineers pulled back to product work, and auditor availability, which can tighten in busy seasons. Name a single owner with authority to make decisions, protect a small amount of engineering time every week, and book your auditor early.
Takeaway: keep scope small, fix the riskiest controls first, and buy tools only after you know what they must do.
If a customer is asking for SOC 2 and you want a realistic plan, request a call with AZEN.