SaaS companies spend real effort on SOC 2. Auditors sign off, a PDF gets filed, and the certification language goes on the website. Then the first enterprise prospect sends a 200-question security questionnaire and the SOC 2 report doesn’t answer half of it.
That gap has a name now. The Cloud Security Alliance released version 1.0.1 of its SaaS Security Capability Framework (SSCF) in April 2026, adding what was conspicuously missing from the original: a structured self-assessment questionnaire and practical vendor implementation guidelines. For SaaS security teams, this is a more concrete target than anything that existed before.
By the time you finish reading this, you will understand why the framework matters, what it covers, and how to use it before your next enterprise procurement cycle forces the conversation.
Key takeaways:
- Run the SSCF-CAIQ as a product security audit before your next enterprise deal — gaps customers will find anyway
- IAM holds 21 of 36 controls and covers the most common enterprise deal-breakers: SSO, MFA, NHI governance, session revocation
- “Must” controls define the mandatory baseline; “should” guidelines tell you how to implement them
- A completed CAIQ on file cuts custom questionnaire overhead for both sides
Why SOC 2 doesn’t answer the right question
SOC 2 and ISO 27001 are organizational certifications. They tell a prospective customer that your company has documented its security policies, passed an audit, and maintains controls around how your team operates. That is genuinely valuable. But it answers the wrong question for a security team trying to onboard a new SaaS product.
What the enterprise security team actually wants to know is: once we adopt your product, what can we configure on our side?
This is the Shared Security Responsibility Model in practice. The SaaS vendor secures the application and the infrastructure it runs on. The customer is responsible for their configuration inside the product: enforcing MFA, setting session timeouts, managing who has access to what, and controlling how integrations connect. A SOC 2 report covers the first part. The SSCF covers the second.
“The customer adopting the SaaS platform is ultimately responsible for operating it securely.” — CSA SaaS Security Capability Framework
Large enterprises manage hundreds of SaaS applications. Across that portfolio, visibility into basic controls — whether MFA enforcement is possible, whether session tokens can be revoked in real time, whether audit logs can be delivered to a SIEM — is inconsistent from vendor to vendor. There is no standard to compare against. Every product does something slightly different, and the security team has to rediscover the answer from scratch for each one.
The absence of a standard hurts vendors as much as buyers. SaaS startups building toward enterprise procurement have no clear specification for which product security features actually matter. They end up building toward SOC 2, which tells them how to operate their company, when what they actually need is a spec for what to build into the product.
That is the problem the SSCF was designed to address.
What the SSCF covers (and why the scope is deliberate)
The framework organizes 36 controls across six domains. IAM holds 21 of them — more than half. The rest of the framework distributes seven controls across Logging and Monitoring (LOG), four across Change Control and Configuration Management (CCC), two across Interoperability and Portability (IPY), and one each in Data Security (DSP) and Security Incident Management (SEF).
The domain naming aligns with the CSA Cloud Controls Matrix v4. Enterprise TPRM teams already familiar with CCM can read the SSCF without a translation layer.
“SSCF controls are configurable, consumable, and customer-facing.” — CSA SaaS Security Capability Framework
IAM commands more than half the framework for a reason. This is where enterprise deals break down in practice. SSO enforcement, MFA configuration, non-human identity governance, session revocation, granular OAuth scopes, SCIM provisioning — these are the controls enterprise security teams ask about most and that SaaS products implement most inconsistently. The depth here reflects the real-world distribution of procurement friction.
What the SSCF deliberately excludes is equally important. Encryption at rest, backend infrastructure monitoring, data residency, GenAI-specific configuration, and incident handling processes are all out of scope. These are either vendor-controlled by definition (the customer cannot configure them), governed by separate contractual obligations, or covered by other CSA frameworks. The SSCF is not trying to be comprehensive. It is trying to be specific to the narrow question of what a customer can control inside your product.
That deliberate scope is what makes the framework usable. A checklist that tries to cover everything ends up answering nothing precisely.
What the CAIQ addition changes
The SSCF-CAIQ, released in v1.0.1, is the questionnaire component. It follows the same model as the Consensus Assessments Initiative Questionnaire that the CSA publishes for its Cloud Controls Matrix: each control specification is translated into structured assessment questions, and a vendor completes the questionnaire once and shares the result with multiple buyers.
This solves a real operational problem. Every enterprise buyer currently sends its own bespoke security questionnaire. The questions largely cover the same ground, but the wording differs, the format differs, and the mapping back to your actual controls differs. You end up answering the same questions repeatedly in slightly different ways, for every deal, indefinitely. The CAIQ model is a way out of that loop.
“The SSCF-CAIQ reduces the need for bespoke security questionnaires and inconsistent vendor assessments.” — CSA SaaS Security Capability Framework
A completed SSCF-CAIQ on file is a standardized security profile of your product’s customer-facing capabilities. TPRM teams that have adopted the CCM know how to interpret it. For everyone else, it provides structure where there is currently none. You complete it once, maintain it as your product evolves, and share it at the start of procurement conversations rather than waiting for a custom questionnaire to arrive.
The questionnaire also makes the Shared Security Responsibility Model explicit. For each control, it distinguishes between what the provider has implemented and what the customer is responsible for configuring. That distinction matters when enterprises are onboarding your product into an environment with specific compliance requirements. They need to know whose job it is to enable each control, and the CAIQ surface that clearly.
How SaaS vendors should use the framework
The framework distinguishes between two types of requirements. Control specifications use the word “must” and define the mandatory baseline. If the control applies to your product, this is non-negotiable. Implementation guidelines use “should” and define how to implement the control in a way that is vendor-agnostic, adapted to your stack, your regulatory context, and your resource constraints.
“Controls represent what must be implemented. Implementation guidelines represent how.” — CSA SaaS Security Capability Framework
That distinction is a prioritization signal. Start with the “must” controls. They define the floor your product needs to clear before an enterprise security team will seriously evaluate it. The guidelines tell you how to build those controls in a way that will hold up to scrutiny.
The IAM section gives you the most concrete direction. IAM-SaaS-18, for example, flags monolithic OAuth scopes as an explicit anti-pattern. Scopes like read_write_all are a deal-breaker in enterprise procurement. The implementation guideline calls for granular resource and action scopes: projects.read, projects.write, users.read, admin.security.read. This is the kind of precise, actionable specification that security engineering teams can take directly into a product backlog.
IAM-SaaS-15 specifies that your platform must be able to invalidate all active sessions in real time — including JWTs before natural expiration — via API. This is a critical incident response capability. A security team that discovers a compromised account needs to be able to cut access immediately, on every device, across every active session. Many SaaS products cannot do this today, and it comes up in enterprise procurement more often than vendors expect.
LOG-SaaS-02 is similarly precise. It specifies a structured JSON schema with required fields: timestamp in ISO 8601 UTC, actor type and identifier, action in dot-notation format (for example, user.login.failed or config.sso.updated), source IP and user agent, and session ID. This is not vague guidance about maintaining audit logs. It is a spec your engineering team can implement against.
The guidelines were written with early-stage resource constraints explicitly in mind. They acknowledge that the right approach depends on your risk landscape, regulatory requirements, and technology stack. You are not expected to implement every guideline identically. You are expected to have a considered approach you can articulate.
Where to start
The practical path is straightforward. Download the SSCF-CAIQ and work through it as an internal product security audit before your next enterprise deal. The gaps it surfaces are not gaps the framework invented. They are gaps your prospective customers will find anyway, just at a worse point in the sales cycle.
IAM is where most early-stage products will have the most work. Session revocation, OAuth scope granularity, non-human identity governance, and SSO enforcement are consistently underbuilt and consistently the first things enterprise security teams probe. Start there.
Once the internal audit is complete, maintain a completed CAIQ on file and treat it as you treat your SOC 2 summary: a document you share early in procurement to reduce the back-and-forth. A certification framework for formally validating controls against the SSCF standard is on the CSA roadmap. Getting your product to the baseline now means less to scramble for when that arrives.
“For SaaS startups aiming to attract enterprise clients, the SSCF identifies the most impactful security features to satisfy procurement requirements.” — CSA SaaS Security Capability Framework
The SSCF does not replace SOC 2. It answers the question SOC 2 was never designed to answer. Run both.
