When a large prospect asks for SSO, a SOC 2 report and a completed security questionnaire, ship SSO first, answer the questionnaire honestly with what you have, and start the SOC 2 process in parallel without promising a report date you do not control. SSO can usually be delivered in weeks and is often the item that actually blocks the signature. A SOC 2 Type 2 report depends on an observation period that you cannot compress, so it needs an interim answer.
The goal of this post is to turn “we need to be enterprise-ready” into a sequence you can put dates on, so engineering does not end up promising sales something it cannot deliver.
What is actually blocking the deal?
Start by reading the request carefully, because the three asks are rarely equal in weight. In practice a buyer’s security team wants confidence that your product will not become a hole in their environment, and the three items are their ways of checking.
- SSO lets their employees sign in with the corporate identity provider, which lets them enforce MFA, disable leavers in one place and see who has access. It is a product feature, so you can build or buy it.
- A SOC 2 report is third-party evidence about how you run your controls. It is a process and time commitment, not a feature.
- The security questionnaire is a list of written questions, often built on a standard such as the Cloud Security Alliance’s CAIQ or the Shared Assessments SIG questionnaire. It is a documentation exercise that you can start today.
Ask the buyer which of these is a hard gate and which is a preference. A prospect that says “we need SOC 2” may accept a bridge, such as a completed questionnaire, a short call with your engineer, and a commitment to a report date, as long as SSO is in place. If you want to see how these asks look from the buyer’s side, our post on what security questionnaires ask about login lists the common questions.
Why SSO is usually the first item to ship
SSO is both the most concrete blocker and the one you can control. The buyer’s security team typically will not approve a new application that keeps its own passwords for their staff, because it sits outside their offboarding and MFA policies. That makes SSO a go or no-go item more often than SOC 2 itself.
For the product, “SSO” usually means supporting SAML 2.0 or OpenID Connect against the customer’s corporate provider, such as Okta or Microsoft Entra ID. The work includes the protocol flows, per-customer configuration, handling of multiple customers each with their own provider, and an admin screen so customers can set it up without opening a ticket. Our guides on choosing an SSO provider for B2B SaaS and SSO implementation for developers go through the options.
One caution is worth repeating to sales. Having SSO does not mean you will pass procurement, since reviewers look at what sits around it too. The article SSO doesn’t mean you pass procurement covers what else gets checked.
When does SCIM (directory sync) come up?
SCIM (System for Cross-domain Identity Management) is the standard that lets a customer’s directory create and remove users in your app automatically. Buyers tend to ask for it after SSO, often in the second round of review or once the contract is signed, because it solves the problem of departed employees keeping access in your product. If it appears in the questionnaire, answer it truthfully as planned or available, and do not build it ahead of SSO unless the buyer makes it a condition. The differences between sign-in and provisioning are explained in SCIM vs SAML, and JIT provisioning vs SCIM helps you decide which you need first.
What does a realistic SOC 2 timeline look like?
SOC 2 is an attestation framework from the AICPA (the American Institute of Certified Public Accountants). An independent auditor examines your controls against the Trust Services Criteria, with Security as the required category and others such as Availability or Confidentiality added by choice.
Type 1 vs Type 2, and why the difference matters to sales
A Type 1 report describes whether your controls are suitably designed at a single point in time. A Type 2 report covers whether they operated effectively over a period. The AICPA does not fix the length of that window, and it is often a few months for a first report and a full year after that. Many enterprise buyers prefer Type 2 because it shows the controls actually ran, while some accept Type 1 from an early-stage vendor with a committed date for Type 2.
For your sales team, the useful point is that the observation period is the schedule driver. Even if you finish the preparation quickly, a Type 2 report cannot exist before its window closes and the auditor finishes. Our comparison of SOC 2 Type 1 or Type 2, which first goes into how to choose.
In short, the work runs through readiness and remediation, an optional Type 1 report, an observation window and then the Type 2 report. Treat any specific number of weeks you hear as an estimate that depends on your starting point, your auditor and the tooling you use. The reasoning behind each step, and what to tell your deal desk about the calendar, is covered in SOC 2 Type 1 or Type 2, which first, so this post focuses on the order of work.
Your vendors count too
An important detail for a SaaS team that outsources identity: a vendor’s SOC 2 report does not make you SOC 2 compliant. It does help, since your auditor will want to see that you reviewed your service providers and their reports, and the controls they cover can reduce what you must evidence yourself. Buying identity from a vendor with its own SOC 2 attestation (Type 2) and ISO 27001 certification gives you something concrete to show. Skycloak’s are described on our security page and in our SOC 2 announcement, and our SOC 2 Type 2 report and ISO 27001 certificate are available under NDA. That is evidence about our service, and it is not a substitute for your own report.
What should you promise the deal desk?
Be specific about what you will deliver and when, and clear about what you cannot control.
This quarter:
- A completed security questionnaire, with honest “planned” answers where a control is not yet in place.
- SSO for the prospect’s identity provider, with a date your engineers have signed off on.
- Your security documentation, such as a pen test summary or policies, if you have them.
- A written commitment to start SOC 2, with the auditor’s name and a target window for the report.
Next quarter:
- A Type 1 report, if you chose that route.
- SCIM, if the buyer needs it.
- Further hardening based on the buyer’s findings.
Do not promise: a specific date for a Type 2 report before the auditor has agreed the observation period, or any control you have not implemented yet.
How do you sequence this so you do not build it twice?
The expensive mistake is building SSO as a one-off for the first customer and then rebuilding it when the second customer uses a different provider. Build it as a general capability from the start, with per-customer configuration and a self-serve setup screen. Use an identity layer that already supports SAML, OIDC and SCIM, such as a managed Keycloak, if you do not want to maintain the protocol code yourself. Our B2B SaaS solution page describes that approach.
Do the same for the compliance work: pick tooling and processes that produce evidence as a by-product, so the observation window starts clean instead of requiring a scramble at audit time.
Frequently asked questions
Do I need a SOC 2 report to sell to enterprises?
Not always, but many large buyers ask for one. Some will accept a Type 1 report, a completed questionnaire or a committed date, particularly from an earlier-stage vendor. Ask what is a hard requirement and what is flexible.
How long does it take to get a SOC 2 report?
It depends on your starting point and the auditor. The preparation can take weeks to months, and a Type 2 report needs an observation period before it can be issued, often a few months for a first report.
What is the difference between SOC 2 Type 1 and Type 2?
Type 1 assesses whether controls are designed appropriately at one point in time. Type 2 assesses whether they operated effectively over a period. Type 2 carries more weight with most buyers.
Does using an SSO or identity vendor with a SOC 2 report make me compliant?
No. You still need your own report. A vendor’s report helps by covering the vendor’s controls and giving your auditor evidence that you reviewed your service providers.
Should I build SSO before SCIM?
Usually yes. SSO is the more common blocker. SCIM tends to come up afterwards, so build it when the buyer asks for it or when your customers’ offboarding becomes a support issue.