Almost every SOC 2 program starts the same way. A customer makes the report a condition of renewal, someone gets a quote from an audit firm, and that figure becomes the number the board discusses.
It is the wrong number to plan around. The audit fee is the one part of this you can get in writing in an afternoon. The part that decides whether you make the customer's date is how many hours your own people can give it, and which people they are.
Here is where that time goes, in the order you will spend it.
Scoping is the cheapest hour you will spend
SOC 2 is not one fixed checklist. You choose which trust services criteria are in scope, which systems and which part of the organization the report covers, and whether you are pursuing a Type I or a Type II. Those choices change the amount of work more than any other decision in the program.
Most companies include Security and stop there for the first report. Availability, Confidentiality, Processing Integrity, and Privacy each add controls, evidence, and questions from the auditor. Adding one because it sounds prudent is how a three-month program becomes a six-month one. Add it because a customer asked for it in writing, or because your contracts already commit you to it.
Scope also means systems. A report that covers one production environment is a different exercise from one that covers everything the company runs. Draw that boundary early, write it down, and expect your auditor to test it.
Policy: two weeks of writing, then the harder part
Writing the policy set is the visible half and the easy half. A competent set for a company of this size runs to a dozen or so documents: information security, access control, change management, incident response, vendor management, business continuity, risk assessment, secure development if you build software, and the human resources policies that sit around them.
The harder part is that an auditor tests what you do, not what you wrote. A policy saying access is reviewed quarterly creates an obligation to hold quarterly access reviews and to keep the evidence that they happened. Every sentence you write is a promise you will be asked to prove, so the useful discipline is to write the smallest true policy rather than the most impressive one.
A borrowed policy set is a list of promises made by a company that is not yours.
This is why template packs disappoint. They are complete, they are cheap, and they describe a company with a security team, a change advisory board, and a formal training function. You will then spend the observation period either building those things or explaining to an auditor why the policy does not match reality.
Evidence is a routine, not a document
The largest single cost in a readiness program is turning controls into habits that leave a trace. Not writing them down once — running them, on a schedule, with a record of each occurrence.
- Access reviews on a stated cadence, with the reviewer, the date, and what changed.
- Change management: tickets or pull requests that show what changed, who approved it, and when it shipped.
- Onboarding and offboarding records that match the leaver process you documented.
- Vendor reviews for the processors that hold your data, refreshed rather than done once.
- Risk assessment revisited at the interval your policy claims.
- Security awareness training completed and recorded for the people your policy names.
- Backup and restore tests with the result written down, not just the job's status.
None of these are large in isolation. Together they are a standing commitment that reaches finance, engineering, human resources, and whoever signs vendor contracts. That is the cost people do not model: it is spread across the calendars of people who do not report to whoever owns the program.
The observation period is not preparation time
A Type I report describes whether your controls were suitably designed at a point in time. A Type II describes whether they operated over a period, and your auditor sets that period. This is the distinction that most affects your customer's date.
The mistake is to treat the observation window as time to finish the work. It is not. It is the window in which your controls have to already be operating, because the auditor will sample from it. Controls that go live halfway through produce gaps you will be asked about in the report. If a customer needs the report by a particular quarter, count backwards from that date through the observation period, and only then decide what is realistic.
This is also the argument for starting with a Type I when a deadline is tight. It gets a real report in a customer's hands sooner, and the work is not wasted: it is the same control set, tested at a point in time rather than over one.
Who gets pulled in, and for how long
Readiness needs one owner with the authority to make people do things. Not a coordinator who chases, an owner who decides. Without that, the program becomes a standing meeting that produces a spreadsheet.
Around that owner, expect recurring demands on whoever administers your identity provider and cloud accounts, whoever runs engineering, whoever handles people operations, and whoever owns vendor contracts. During fieldwork the load concentrates sharply: auditors ask for specific artifacts on short notice, and someone has to produce them while doing their normal job.
Buying a compliance automation platform changes the shape of this, not the size. The platform collects evidence continuously, which genuinely removes some drudgery. It will not scope your framework, write a policy that matches how you work, decide whether an exception is acceptable, or answer the auditor's follow-up question. Those remain the expensive hours.
What shortens it and what drags
Programs that finish on time tend to share a few things. Identity was already consolidated, so access reviews are one report rather than eleven. Infrastructure changes already went through a ticket or a pull request, so change evidence exists without new process. Someone senior sponsors it, so the requests do not queue behind revenue work.
Programs that drag usually have one of four problems: a scope nobody has fixed in writing, a policy set that describes another company, no single owner, or an observation period that started before the controls did. Each of those is recoverable if it is named early and expensive if it is discovered in fieldwork.
Before you commit to a date, ask the question that governs all of this: what does the customer actually need, and by when? Sometimes the answer is a completed security questionnaire and a credible plan with a date on it, which you can produce in weeks. Sometimes it is the report itself, in which case work backwards from the observation period and be honest about what that means for the quarter.