SOC 2 Doesn't Answer "What Can the Customer Configure?" - CSA's SSCF-CAIQ for SaaS Vendors

You shipped SOC 2. The report sits on your Trust Center. Then the next enterprise prospect sends a 200-question product security pack - and half of it asks about SSO enforcement, session revocation, granular OAuth scopes, and SIEM log delivery. Your auditor never tested those. Your Type 2 report does not answer them.

That gap is not a failure of SOC 2. SOC 2 and ISO 27001 certify how the vendor company operates. Enterprise buyers also need a clear answer to a different question: once we adopt your product, what can we configure on our side?

The Cloud Security Alliance's SaaS Security Capability Framework (SSCF) defines those configurable, consumable, customer-facing security controls. In April 2026, CSA released SSCF v1.0.1 with SSCF-CAIQ - a reusable self-assessment questionnaire for that product-control layer, plus implementation guidelines and machine-readable JSON/OSCAL. ResponseHub covered the update on 10 April 2026.

Buyers need both artifacts. One does not replace the other.

Who this is for

Growth SaaS founders, Heads of Sales or RevOps, and lone security/compliance owners who already maintain a SIG or CAIQ answer bank or a Trust Center - and who keep losing weeks in enterprise procurement because organizational audits do not cover product-config questions.

What is the SaaS Security Capability Framework?

Per CSA's artifact page, the SSCF defines configurable, consumable, and customer-facing security controls provided by SaaS vendors to their customers. It sits on the shared-responsibility / customer-config layer: the settings, APIs, and product features a buyer can actually use once they are inside your app.

That framing matters for GTM. Organizational certifications answer 'does this vendor run a serious security program?' Product controls answer 'can our security team enforce MFA, revoke sessions, scope OAuth grants, and pull structured audit logs into our SIEM?' Procurement packs mix both. Vendors who only bring SOC 2 keep answering the second set from scratch on every deal.

Grip Security's 24 September 2025 overview (pre-questionnaire context) listed six domains that still frame the framework: Change Control and Configuration Management (CCC), Data Security and Privacy Lifecycle (DSP), Identity and Access Management (IAM), Interoperability and Portability (IPY), Logging and Monitoring (LOG), and Security Incident Management / e-Discovery / Forensics (SEF). Domain naming aligns with CSA's Cloud Controls Matrix, so TPRM teams already fluent in CCM can read SSCF without a translation layer.

What changed in SSCF v1.0.1 (April 2026)?

The original SSCF gave vendors a control baseline. v1.0.1 adds the operational pieces that make it sharable the way classic CAIQ works for CCM:

• SSCF-CAIQ - structured self-assessment questions mapped to SSCF controls
• Implementation guidelines - 'must' control specs vs 'should' how-to guidance
• Machine-readable JSON and OSCAL - for tooling and automated assessment workflows
• Spreadsheet aligned to CCM domains, introduction, and a slide deck

CSA's download bundle on the official artifact page includes all of the above. The practical GTM win is the same pattern Workstreet readers already know from CAIQ: complete once, maintain as the product evolves, share early instead of inventing answers for every custom spreadsheet.

This is not the same artifact as CAIQ v4.1 for STAR/CCM organizational questionnaires. That cutover story lives on our CAIQ v4.1 post. SSCF-CAIQ is the product customer-facing cousin in the same 'reduce questionnaire chaos' family.

Which SSCF domains matter most for enterprise deals?

ResponseHub's 10 April 2026 write-up summarizes 36 controls across six domains, with IAM holding 21 of 36 - more than half. That weight matches where enterprise deals actually stall:

• SSO and MFA enforcement the customer can turn on
• Non-human identity (service accounts, bots, API keys) governance
• Real-time session revocation, including before JWT natural expiry
• Granular OAuth scopes instead of monolithic read_write_all-style grants
• Structured audit logs buyers can deliver to a SIEM

ResponseHub also flags concrete spec examples vendors can put on an engineering backlog: granular resource/action scopes (for example projects.read vs a catch-all), API-driven session invalidation, and structured JSON log fields (ISO 8601 UTC timestamp, actor, action in dot-notation, source IP/user agent, session ID).

What SSCF deliberately leaves out

Do not overclaim. CSA scoped SSCF to customer-facing product controls. ResponseHub notes that items such as backend encryption-at-rest (vendor-only by definition), GenAI-specific configuration (covered elsewhere), and some incident-handling process depth sit outside SSCF. Those gaps are intentional. SSCF is not trying to replace SOC 2, ISO 27001, or AI questionnaire addendums - it answers the narrow question of what a customer can control inside your product.

SSCF vs SOC 2 (and vs classic CAIQ / SIG)

If you are still choosing between classic CAIQ and SIG for organizational questionnaires, use CAIQ vs SIG and our SIG questionnaire guide. For why SOC 2 alone never clears every diligence pack, see SOC 2 vs security questionnaires.

Certification path note: ResponseHub (10 April 2026) describes a formal CSA certification path for SSCF as roadmap language, not a live certification program you can enroll in today. Do not market 'SSCF certified' unless CSA primary sources say otherwise. Treat SSCF-CAIQ as a reusable self-assessment and product baseline.

A practical Workstreet playbook for SSCF-CAIQ

1. Run SSCF-CAIQ as an internal product-security gap pass

Before the next enterprise deal forces the conversation, download the SSCF-CAIQ and walk it with security + product engineering. Score each applicable control: implemented and customer-consumable, partially implemented, or missing. Start with IAM 'must' controls - that is where ResponseHub and procurement friction both concentrate.

2. Put completed SSCF-CAIQ + SOC 2 summary on the Trust Center / answer bank

Treat the completed questionnaire like your SOC 2 summary: share it early. Pair it with the attestation PDF so buyers see company-level assurance and product-config clarity in one place. If you are still building that surface, our guide to building trust with a company trust page covers the pattern.

3. Map 'must' controls to the engineering backlog with owners

SSCF separates must (control baseline) from should (implementation guidelines). Convert every failing 'must' into a ticket with an owner, target release, and customer-facing evidence note (setting path, API, or admin doc). That evidence becomes your next questionnaire answer bank row.

4. Train AEs to offer SSCF-CAIQ early

Sales should not wait for a custom 200-row spreadsheet. When a prospect asks for product security detail, AEs can lead with: 'Here is our SOC 2 summary and our completed SSCF-CAIQ for customer-facing controls.' That framing sets expectations and shortens the first diligence round.

Checklist (copy into your runbook)

• Download CSA SSCF v1.0.1 bundle (intro, spreadsheet, SSCF-CAIQ, guidelines, JSON/OSCAL)
• Complete SSCF-CAIQ internally with security + eng
• Prioritize IAM 'must' gaps on the product backlog
• Publish completed SSCF-CAIQ + SOC 2 summary to Trust Center / answer bank
• Brief AEs on when to attach SSCF-CAIQ in outbound diligence
• Schedule a quarterly refresh when product controls change
• Keep classic CAIQ/SIG answer banks current for organizational questions (separate artifacts)

How this fits Workstreet's questionnaire stack

Same family, different artifact:

• SSCF-CAIQ (this post): product customer-facing control baseline
• CAIQ v4.1: STAR/CCM organizational questionnaire version cutover
• AI addendums: LLM / model / training-data questions buyers bolt onto packs
• SIG / classic CAIQ: broad third-party risk questionnaires

If questionnaire volume is already eating your week, security questionnaire automation is the primary next step - answer banks, reuse, and faster turnaround across SSCF-CAIQ, CAIQ, SIG, and custom packs. A Trust Center and light vCISO / GTM security support help when you need the public surface or backlog prioritization, not as a replacement for SOC 2.

How should AEs talk about SSCF-CAIQ on a live deal?

Use plain language. Buyers do not need the CSA acronym soup on the first call. A working script:

1. 'We have a current SOC 2 that covers how our company runs security - access, change management, vendor management.'
2. 'Separately, here is our completed SSCF-CAIQ. It documents the security settings your team can configure inside the product: SSO/MFA, session controls, OAuth scopes, and audit log delivery.'
3. 'If your questionnaire asks product-config questions, map them to this SSCF-CAIQ first. We will still answer custom rows, but this cuts the first round.'

That framing prevents two failure modes: overselling SOC 2 as a product-feature list, and waiting until legal sends a 200-row sheet before engineering has named owners for gaps.

What 'good enough' looks like before enterprise season

You do not need every SSCF control perfect on day one. You do need:

• Honest SSCF-CAIQ answers (yes / no / N/A with evidence notes - not marketing fluff)
• A shortlist of IAM 'must' gaps with ship dates AEs can say out loud
• SOC 2 (or ISO) summary available in the same packet
• A single owner for questionnaire refresh when product settings change

Vendors who skip the honesty step create worse diligence later: a buyer who finds an overclaimed MFA or log capability mid-security review loses trust faster than one who sees a dated roadmap row.

Bottom line

SOC 2 proves how your company operates. SSCF-CAIQ documents what customers can configure inside your SaaS product. CSA's April 2026 v1.0.1 release finally gave vendors a reusable questionnaire for that second layer. Complete it once, put it next to your SOC 2 summary, fix the IAM gaps buyers will find anyway, and stop rediscovering product-security answers on every enterprise deal.