SaaS shared responsibility model

How the SaaS shared responsibility model works

The SaaS shared responsibility model is a boundary-setting concept, not a guarantee of end-to-end security. It clarifies that the vendor operates and protects the application service, while the customer still controls how the service is used and what data, identities, and integrations are exposed through it.

That split matters because SaaS reduces infrastructure ownership, but it does not remove governance. A tenant can still be compromised through weak authentication, unsafe configuration, or overly broad application access even when the provider’s platform is well managed.

Vendor responsibilities in SaaS

On the vendor side, the shared model usually covers the underlying cloud stack, service uptime, patching, platform resilience, and core service controls. In practice, this is where customers expect the provider to maintain secure hosting, keep the service available, and protect the multi-tenant application boundary.

For SaaS customers, this means vendor due diligence should focus on service assurances and control evidence, not on assuming the provider has absorbed every security duty. A useful reference point for control thinking is NIST SP 800-53 Rev 5 Security and Privacy Controls, which helps distinguish platform control expectations from customer-side operational controls.

Customer responsibilities in SaaS

The customer owns the parts of SaaS security that arise from usage: identity and access decisions, tenant configuration, data classification, sharing rules, and the security of connected apps and automations. Those responsibilities are often the source of real exposure because they are easy to misjudge as “the vendor’s job.”

That is why SaaS governance usually includes least privilege, strong authentication, careful API and integration access, and data handling rules that match the sensitivity of the information stored in the service. When credentials or tokens are used to connect tools to SaaS platforms, the security posture can quickly resemble the broader non-human identity control problem described in OWASP Non-Human Identity Top 10.

Why the boundary is easy to misunderstand

The shared responsibility model becomes risky when teams assume that “cloud hosted” means “provider secured” in every sense. In SaaS, the vendor may harden the service itself, but the customer still decides who can log in, what data can be exported, which integrations are trusted, and whether sensitive content is placed into the platform at all.

That distinction is especially important when SaaS includes APIs, workflow automation, or delegated access. Controls like RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants matter because service-to-service access in SaaS often depends on assertion-based authentication rather than human login flows.

How to think about SaaS responsibility in practice

The cleanest way to use the model is to ask three questions for every SaaS control: what does the vendor secure, what does the customer configure or govern, and what becomes shared because both sides influence the outcome. That lens is more useful than trying to force every issue into either “provider” or “customer” ownership.

For example, access policy, data retention, and connected application approvals sit with the customer even when the vendor supplies the platform features. Frameworks such as NIST Privacy Framework and NIST Cybersecurity Framework 2.0 are useful here because they reinforce that governance, protection, detection, and recovery remain shared responsibilities in outcome, even when infrastructure ownership is not shared.

Risk and Threat Considerations

SaaS risk usually emerges from misplaced assumptions about who owns the control. The most common failure mode is not platform compromise by the vendor, but customer-side exposure through excessive permissions, weak authentication, poor configuration, or insecure integrations that attackers can abuse once they reach the tenant.

Failure mechanism: An attacker exploits a customer-managed identity, integration, or configuration gap to gain access, move laterally through connected apps, or exfiltrate data from the SaaS tenant.

Impact: The result can be unauthorized data exposure, account takeover, destructive changes, phishing from trusted SaaS channels, or loss of trust in a business-critical service.

Practitioner Guidance

Governance implication: Treat the SaaS shared responsibility model as an ownership map, not a security program. Security teams should document which controls are vendor-provided, which are tenant-managed, and which require joint operational evidence before the service is approved.

Practitioner takeaway: The right question is not “Is the SaaS vendor secure?” but “Which parts of the risk remain mine after the vendor has done its job?”

Related resources from NHI Mgmt Group

• Shared Responsibility Model
• How should security teams apply the shared responsibility model across SaaS, PaaS, and IaaS environments?
• Who is responsible for securing cloud workloads in a shared responsibility model?
• Why do misconfigured SaaS admin endpoints create outsized risk in shared responsibility models?