How do organisations decide whether to scope optional SOC 2 trust services criteria beyond Security?

Why This Matters for Security Teams

Scoping optional SOC 2 trust services criteria is a control design decision, not a branding exercise. Security is the baseline, but many assurance conversations quickly move into availability, confidentiality, processing integrity, or privacy because those dimensions reflect how the service actually behaves for customers. The practical question is whether the organisation can support the selected criteria with consistent evidence, documented procedures, and measurable operating effectiveness.

Teams often over-scope to match marketing promises or a sales request, then struggle to maintain the control set across product changes, incident response, vendor dependencies, and release cycles. That creates audit friction and weakens trust rather than strengthening it. A sensible scope decision starts with business commitments, data classification, and the likelihood that customers will ask for specific assurances. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it shows how control families translate into operational expectations, even though SOC 2 itself is a different framework.

In practice, many security teams encounter scope creep only after a customer asks for an assurance they cannot evidence consistently, rather than through intentional criteria selection.

How It Works in Practice

Deciding scope usually begins with a simple mapping exercise: what are the service commitments, what data is processed, and what could reasonably fail in a way that would matter to customers. Security is almost always in scope because it underpins the whole report. The optional criteria are then evaluated against actual risk and customer reliance, not against a desire to maximise report coverage.

Availability is a strong candidate when uptime, continuity, or recovery time is part of the service promise. Confidentiality makes sense when the service processes sensitive business data, customer records, source code, or regulated content that requires disciplined access management. Processing Integrity is relevant when the system performs calculations, workflows, routing, or transformations where accuracy and completeness matter. Privacy is appropriate when personal data is collected, used, retained, disclosed, or deleted in ways that create a clear accountability obligation.

• Start with customer contracts, security questionnaires, and procurement language to identify recurring assurance expectations.
• Map each optional criterion to actual control owners, evidence sources, and test procedures.
• Check whether the organisation can sustain the control over time, not just pass a one-off audit.
• Review dependencies such as cloud platforms, subprocessors, and non-human identities that enforce access or workflow steps.

That last point matters more than many teams expect. Optional criteria often depend on machine credentials, service accounts, API keys, and automation paths that are not fully visible in traditional access reviews. Where access, orchestration, or logging is handled by non-human identities, control evidence needs to account for how those identities are issued, rotated, monitored, and retired. The OWASP Non-Human Identity Top 10 is a useful reference for that operational layer.

Current guidance suggests that scope should be limited to criteria that the organisation can test repeatedly and evidence without manual heroics. These controls tend to break down when multiple product teams own different parts of the service and no single group can consistently produce audit-ready evidence.

Common Variations and Edge Cases

Tighter scoping often reduces audit burden, but it also limits how far the report can support sales, procurement, and regulatory conversations, so organisations must balance assurance depth against operational cost. That tradeoff becomes sharper when the service operates across jurisdictions or supports high-assurance customers.

Some organisations scope only Security at first, then add Confidentiality or Availability in later cycles once control maturity improves. That staged approach is often the safest path when evidence collection is immature. Best practice is evolving, but there is no universal standard for how many criteria should be included beyond Security. The right answer depends on whether the organisation can prove the controls are designed and operating effectively for the full reporting period.

Privacy deserves special caution. If personal data handling is limited or indirect, a privacy scope may be unnecessary; if the service stores, profiles, or transfers personal data, leaving it out can create a mismatch between assurance claims and actual obligations. For organisations operating in the EU or supporting digital identity ecosystems, eIDAS 2.0 and ENISA Threat Landscape material can help frame trust, resilience, and identity assurance expectations more concretely.

The key exception is when a customer or regulator effectively makes an optional criterion non-optional through contract, law, or service dependency. In those environments, under-scoping creates a credibility gap that is harder to repair than a slightly broader control set.

Related resources from NHI Mgmt Group

• How can organisations tell whether their SOC 2 scope is too broad?
• How do security teams decide whether to keep Cognito-like tools in scope?
• How should organisations decide whether to buy AI security tools through procurement channels?
• How can organisations decide whether their AI security workflow is mature enough?