SOC 2 Type II For SaaS: What It Costs And When To Start

A deal worth 6 figures reached procurement and stopped. The questionnaire asked for a SOC 2 Type II report. The founder's answer, that they take security seriously and use encryption, is the answer that loses the deal, because nobody at the other end is allowed to accept it.

The uncomfortable part is the arithmetic. SOC 2 Type II cost is the number everyone asks about first, but the constraint is not money. It is that a Type II report covers a window of time that has to have already happened, so the earliest possible report date is set by when you started, and no budget compresses it.

What a Type II report actually is

A SOC 2 report is an opinion issued by a licensed CPA firm about whether your controls meet the AICPA Trust Services Criteria. It is not a certificate and there is no logo you are entitled to put in a footer.

There are 5 criteria. Security, often called the common criteria, is mandatory. Availability, Processing Integrity, Confidentiality and Privacy are optional and you choose which to include. Most B2B SaaS companies scope Security alone for the first report, and add Availability in year 2 if customers ask. Adding all 5 at the start is a common and expensive mistake, because every criterion you include brings its own controls, its own evidence and its own testing.

The report itself is a document of several sections: management's assertion, the auditor's opinion, a system description you write, and the controls with the tests performed against them. Buyers read the opinion and the exceptions. Everything else is context.

Two things about that document surprise people. The system description is written by you, not by the auditor, and it is the section a technical buyer reads most closely, so a vague one costs you credibility with exactly the audience you were trying to convince. And the opinion has grades: unqualified is clean, qualified means the auditor found something material. A qualified opinion is not fatal and it is a conversation you will have with every prospect for a year.

Scope is your decision and it is where the money goes. The report covers named systems, not your company. A product with one application and one database is a cheap audit. The same product plus an internal admin tool, a data warehouse, a mobile app and a separate marketing stack is 4 more system boundaries to describe and evidence. Draw the boundary at what customers actually touch, and be able to justify the line if an auditor pushes on it.

Type I is a decision, not a stepping stone

Type I says your controls were designed appropriately on one date. Type II says they operated effectively across a window, typically 3 to 12 months.

The usual advice is to do a Type I first and a Type II after. That is sometimes right and often not. A Type I costs a real audit fee and buys you a document that many enterprise buyers will read as unfinished, because it proves design and not operation. If the deal in front of you needs Type II, a Type I is 2 months of delay and a bill.

Type I earns its place in 2 situations. When a buyer has explicitly said it is enough for now, which happens more than people expect with mid-market customers. And when you genuinely need an external opinion that the design is right before committing to a 6 month window, which is a reasonable thing to want if your controls were built in a hurry.

Otherwise, pick a 3 month window and go straight to Type II. A 3 month observation window produces a valid Type II report. The reason most first reports cover 6 months is that companies drift, not because 6 is required.

The three costs that get conflated

Almost every article on this subject quotes one number. There are 3, they behave differently, and the largest is the one nobody quotes.

The audit fee. Paid to a licensed CPA firm. It varies with scope, criteria count, and how many subservice organisations are in play. Get 3 quotes, ask each what is excluded, and ask specifically whether the fee covers the readiness review or only the audit. This is not our line and we do not mark it up.

The tooling. Compliance automation platforms such as Vanta, Drata and Secureframe collect evidence continuously, monitor endpoints and keep policies versioned. They are genuinely useful and they are a subscription, not a one-off. They do not implement controls. They observe whether the controls you built are working, which is a different job.

The engineering. This is the largest line for most SaaS products and it is invisible in every vendor's pricing page, because it is not their revenue. It is the audit logging you did not build, the access review workflow that does not exist, the SSO your product does not support, and the restore test nobody has run.

A useful sanity check: a SOC 2 plan with no engineering hours in it has bought a subscription and called it a plan.

The engineering work is product change, not paperwork

Here is the part that surprises founders. Much of what SOC 2 forces you to build is functionality your enterprise buyers were going to demand anyway, which means the work has commercial value beyond the report.

1. Audit logging. Who did what, to which record, when, and from where. Immutable, queryable, and retained for a defined period. Most products have application logs and no audit trail, and the two are not the same thing.

2. Access reviews. A quarterly workflow where a named owner confirms who has access to what, and the confirmation is recorded. Doing this in a spreadsheet works for the first audit and stops working the moment headcount moves. The failure is predictable: the reviewer approves the whole list in one click because reviewing 340 permission rows by hand is nobody's Tuesday, and the auditor asks how the approval was reached.

3. SSO and SCIM. SAML or OIDC against Entra ID, Okta and the rest, plus SCIM provisioning so that when a customer's employee leaves, the account is actually deactivated. Deprovisioning is the control auditors test hardest and the one most products fail, because manual offboarding leaves accounts alive.

4. Role granularity. Admin and user is a switch rather than a permission model. Auditors ask about least privilege, buyers ask about it too, and the practical test is whether a customer can give somebody read access to 1 workspace without also handing them billing.

5. Encryption and key handling. At rest and in transit is table stakes. Where the keys live, who can reach them and how they rotate is the actual question.

6. Backup and restore, tested. Not backup. Restore. An untested backup is a hypothesis, and the test has to be evidenced with a date and an outcome.

7. Change management. Every production change traceable to an approved change, which usually means the pipeline enforces review rather than a policy document asking for it.

8. Incident response. A runbook, named roles, and at least one exercise on the record. A tabletop exercise with 5 people for 90 minutes, written up, satisfies this and is worth doing on its own merits.

9. Vendor management. A register of every subprocessor with its own security posture recorded and reviewed annually. This one is administrative rather than engineering, and it is the control most likely to be quietly missing at audit time because no single team owns it.

The SaaS industry page calls this bundle the enterprise gate, and notes that it usually arrives on a questionnaire instead of on the roadmap. SOC 2 is simply the moment the gate becomes unavoidable.

Count the timeline backwards from the report date

This is the section to read twice, because the calendar is the binding constraint rather than the budget.

Work backwards from when the report has to be in a buyer's hands.

Step	Duration	Note
Report issued	3 to 6 weeks after the window closes	Auditor fieldwork and drafting
Observation window	3 to 12 months	The part that cannot be compressed
Remediation and build	6 to 16 weeks	The engineering above, done before the window opens
Readiness assessment	2 to 4 weeks	Gap analysis against the criteria
Scoping and auditor selection	2 to 4 weeks	Run in parallel with readiness

Add it up. A report needed in 12 months is comfortable. A report needed in 6 months means a 3 month window and an aggressive remediation phase running in parallel with the audit selection. A report needed in 90 days is not achievable, and the honest move is to tell the buyer the window opening date and offer a Type I or a completed readiness assessment as an interim.

One trap worth naming. The observation window only counts once the controls are operating. Opening the window before the engineering is finished produces exceptions in the report, and an exception is worse than a later report, because it is permanent and every future buyer reads it.

The second trap is evidence you cannot produce retrospectively. If a control is meant to run quarterly and your window is 3 months, that control has exactly one chance to be evidenced. Miss it and there is no way to manufacture the evidence later without lying, which is the point at which a compliance project stops being a compliance project. Build the evidence capture into the workflow itself rather than relying on somebody to remember to screenshot something.

A practical scheduling note. Windows that close in late December are a bad idea, because fieldwork lands across the holiday period and the 3 to 6 week issuance estimate stretches. Close a window in a month where both your team and the auditor are actually working.

The parts nobody warns you about

Subservice organisations. Your cloud provider, your payment processor and your email service all perform controls on your behalf. The report either carves them out, which is normal, or includes them, which is rare. Carve out means you are responsible for monitoring their reports, so somebody has to actually collect and read them annually.

Complementary user entity controls. Your own report will list controls your customers must perform for the whole thing to hold, such as managing their own user accounts. Write these deliberately. They end up in your customers' compliance reviews and a vague list creates work for your support team forever.

Bridge letters. Your report covers a window that ended. A buyer evaluating you 2 months later wants assurance about the gap, and the standard answer is a bridge letter from management confirming no material change. It costs nothing to produce and is routinely forgotten until a deal is waiting on it. Convention caps it at about 90 days, so a gap wider than that is not something a letter can cover, and the answer becomes the next report rather than more paperwork.

Year 2. SOC 2 is annual. The second year is cheaper on engineering and roughly the same on audit fee and tooling. Budget it as a recurring line rather than a project, because a lapsed report is worse than no report: it tells a buyer you could do it once and then stopped.

The questionnaire does not go away. Enterprise buyers send their own security questionnaires alongside the report request, frequently 150 to 300 questions long. The report answers many of them and does not replace the exercise. Keep the answers in one place from the first one, because the second buyer asks 80 percent of the same things and the fourth one arrives while somebody is on holiday.

SOC 2 or ISO 27001, and the honest answer

This is a market question dressed as a technical one.

SOC 2 is the default ask from US buyers. ISO/IEC 27001:2022, with its 93 Annex A controls across 4 themes, carries more weight in Europe, the Gulf and India. The transition from the 2013 version closed on 31 October 2025, so a 2013 certificate is now void, which is worth checking on your own vendors as well as on yourself.

If your pipeline is US enterprise, start with SOC 2. If it is European or Gulf, start with ISO 27001. If it is genuinely both, do SOC 2 first because the observation window is the long pole, then map across, since the control overlap is substantial and the second one costs far less than the first.

There is also SOC 1, which the SaaS page calls the forgotten one. It covers controls feeding your customers' financial reporting, and it arrives the moment your product touches their books. Nobody plans for it and it lands on billing and settlement products first.

Regional buyers add their own layer on top of either. In Saudi Arabia and the UAE, data residency questions arrive early and are frequently a harder blocker than the report itself, because they change where the product runs rather than how it is controlled. Answer the residency question before you scope the audit, since the answer can change which cloud regions are in scope and therefore what the report covers.

What we build, with the hours shown

Published rates, published hours, arithmetic you can argue with. We hold no certifications ourselves. We build the controls and the evidence that let you hold them.

Component	Hours	Note
Audit logging, immutable and queryable	120 to 240	Retention policy included
SSO with SAML or OIDC	90 to 180	Buy the identity layer rather than hand rolling it
SCIM provisioning and deprovisioning	80 to 160	The control tested hardest
Role granularity and least privilege	100 to 220	Scales with your object model
Access review workflow	60 to 130	With evidence capture, not a spreadsheet
Backup, restore and a tested runbook	50 to 110	The test is the deliverable
Change management enforced in the pipeline	40 to 90	Usually the cheapest line

At $40 to $100 per hour by seniority, blending to $60 to $70 for a mixed squad, a full readiness build lands near 540 to 1,130 hours, so roughly $35,000 to $73,000 at a $65 blend, before the audit fee and tooling which are paid elsewhere. Most products need a subset, because some of this already exists.

For comparison, the SaaS page's phase one worked example is 1,240 hours at about $80,600. Readiness is a meaningful fraction of building the product in the first place, which is exactly why it should be scheduled rather than discovered.

Pick the date the report has to exist, subtract the window, subtract remediation, and put the result in a calendar. Everything else on this page is detail.