How should security teams divide responsibility between SaaS providers and their own organisation when protecting cloud applications?

Security teams should separate platform responsibility from data and access responsibility. The SaaS provider secures the underlying infrastructure, but the customer owns the data, user accounts, and access governance inside the application. That means teams must know who can access what, validate whether access is authorised, and monitor user behavior rather than endpoint malware. Treat cloud apps as a shared responsibility model with clear operational ownership.

Where the provider’s responsibility ends and your organisation’s begins

Shared responsibility in SaaS is not a slogan, it is an operating boundary. The provider typically owns platform availability, infrastructure hardening, patching, and the security of the service itself, while the customer owns how the service is used: who is onboarded, what they can access, what data is stored, and how access is approved or revoked. That boundary should be written down in service ownership terms, not assumed from the contract.

For cloud applications, the most important divide is usually between platform security and application governance. The customer needs clarity on the controls inside the SaaS tenant, especially access provisioning, privileged actions, role design, and auditability. That is why access and identity issues often matter more than endpoint controls once the application is already delivered as a managed service.

Provider assurances still matter, but they answer a different question. They tell you whether the service is engineered and operated securely enough to host your workload or data. They do not tell you whether your users have excessive permissions, whether dormant accounts still exist, or whether a third-party integration is retaining access after a business relationship has ended.

For teams mapping those boundaries, NHIMG’s Identity Provider and SSO Security Guide is a useful companion because SaaS responsibility usually depends on the trust chain feeding the application, not just the app itself.

Which controls belong to the customer inside the SaaS tenant?

The customer side of the model usually includes identity lifecycle, role assignment, access review, and governance over connected applications. If an employee, contractor, or integration can reach the SaaS data, your organisation is responsible for deciding whether that access is appropriate, time-bound, and still justified. That is true even when the provider controls the underlying stack.

Customer ownership also extends to the quality of authorisation decisions. Knowing a user can log in is not enough. Teams need to know whether the user should see specific records, whether delegated access is still valid, and whether admin-level rights are tightly limited. In practice, many SaaS incidents come from overbroad roles or from access that was never removed after a change in job function or vendor status.

Connected apps deserve the same discipline. OAuth grants, API tokens, and marketplace integrations often outlive the purpose for which they were approved. A healthy SaaS governance model treats those connections as managed access paths with review, revocation, and monitoring requirements, not as background plumbing.

NHIMG’s SaaS-to-SaaS and OAuth App Governance Guide is relevant here because SaaS responsibility frequently breaks at the integration layer, where consent, scopes, and token revocation become customer-owned decisions.

What should security teams monitor, and what should they not expect the SaaS provider to see?

Security teams should expect the provider to surface service health, platform incidents, and vendor-side security events that affect the tenant. They should not expect the SaaS vendor to understand business context well enough to decide whether a given user action is legitimate. That judgement belongs to the customer, who knows the role, the workflow, and the acceptable use case.

This is why monitoring for cloud applications should focus on user behaviour, access anomalies, privileged activity, and unusual consent events. Endpoint malware may still matter, but in many SaaS cases the more relevant signal is an account behaving in an unexpected way from a valid login. If a session, token, or delegated integration is abused, the provider may only see normal-looking service activity unless the customer has its own detection and review process.

There is also a practical limit to provider visibility. The SaaS operator may not see your internal HR changes, your approval chain, or why a specific data export was sensitive. The customer therefore needs alerting and review processes that combine identity signals, business ownership, and access history. That is the difference between technically available access and authorised access.

For teams that want a broader control baseline for this model, NIST Cybersecurity Framework 2.0 is a useful external anchor for aligning govern, identify, protect, detect, respond, and recover activities around SaaS ownership.

Risk and Threat Considerations

SaaS responsibility gaps create predictable failure modes: overprivileged users, stale accounts, abused integrations, and weak visibility into who accessed what. The biggest risk is not that the provider fails to run the platform, but that the customer assumes provider security extends to tenant-level authorisation and governance.

Failure mechanism: Access decisions drift when provisioning, role changes, and offboarding are not tightly owned by the customer. Third-party app consent and token scope can also persist long after the original business need has ended, creating a durable access path that looks legitimate until it is abused.

Impact: Data exposure, fraudulent actions, unauthorised exports, and hard-to-detect account abuse become more likely because the activity occurs inside a trusted SaaS boundary. That can also expand incident scope, since a single compromised account or integration may reach many records or multiple connected apps.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	Shared responsibility in SaaS needs explicit ownership of platform and tenant risk.
	PR.AA-01 — Identities and Credentials Are Issued, Managed, Verified, Revoked, and Audited	Customer-owned SaaS access depends on identity lifecycle and tenant governance.
	DE.CM-09 — Detect Potentially Adverse Events	Monitoring user behavior inside SaaS is central to detecting misuse beyond platform health.
Recommendation — Define SaaS ownership boundaries and assign risk decisions to the correct control owner. Manage SaaS identities and revoke access promptly when roles or vendors change. Monitor SaaS user activity and investigate anomalous access or consent events.
NIST SP 800-53 Rev 5	AC-2 — Account Management	SaaS customers must govern account creation, modification, and removal in the tenant.
	AC-6 — Least Privilege	The question centers on who can access what inside the application.
	AU-6 — Audit Record Review, Analysis, and Reporting	Customer-side review of SaaS activity is needed to validate authorized use.
Recommendation — Control SaaS account lifecycle and remove stale or unnecessary access. Restrict SaaS permissions to the minimum needed for each role. Review SaaS audit records for unusual access and high-risk actions.
NIST Zero Trust (SP 800-207)	3 — Zero Trust Architecture principles	SaaS shared responsibility depends on continuous verification and least privilege.
Recommendation — Apply continuous verification before trusting SaaS access or sessions.
CIS Controls v8	CIS-6 — Access Control Management	SaaS access governance is primarily a customer-owned access control problem.
Recommendation — Centralize SaaS access control and remove unnecessary permissions quickly.

Practitioner Guidance

What to verify: Confirm that every SaaS application has a named customer owner for identity lifecycle, role governance, and integration approvals. If no one can explain who can grant access, approve an app, or revoke a token, the responsibility split is already failing.

Decision rule: If the control concern is about tenant data, permissions, or user behaviour, treat it as a customer-owned control problem. If the concern is about uptime, patching, or service infrastructure, treat it as provider-owned and hold the vendor accountable through its assurance evidence and incident commitments.

What good looks like: The organisation can answer, for each SaaS app, who owns the data, who approves access, who reviews privileged use, and who can revoke third-party connections. The provider’s responsibilities and the customer’s responsibilities should be explicit enough that a handoff is obvious during an incident or audit.

Practitioner takeaway: The safest SaaS model is the one where provider security is assumed for the platform, but customer accountability remains non-negotiable for access, authorisation, and data governance.