How should organisations implement shared responsibility controls when consuming SaaS and multi-cloud services?

Start by mapping which security duties belong to the cloud service provider and which remain with the customer across each service model. Then align logging, incident response, identity and access controls, and configuration management to those retained responsibilities. In multi-cloud estates, maintain a consistent security view so vulnerabilities and events can be handled coherently across the entire environment.

How to split responsibilities across SaaS, cloud and shared control planes

Shared responsibility only works when the boundary is explicit. Organisations need a control-by-control view of what the provider operates, what the customer still owns, and where shared duties require coordination. In SaaS, the provider may run the application, but the customer still owns access policy, user lifecycle, data handling, and many configuration decisions.

The practical mistake is treating “cloud-managed” as “risk-managed”. That assumption leaves gaps where tenant configuration, identity governance, logging retention, and incident evidence still sit with the customer. A reliable shared responsibility model makes those retained duties visible before migration, not after an event.

Which controls matter most in a multi-cloud operating model?

The highest-value controls are the ones that remain meaningful across all providers: identity and access management, logging and monitoring, incident response, configuration baselines, vulnerability handling, and data protection. In a multi-cloud environment, the objective is not identical tooling everywhere, but consistent policy intent and comparable visibility so that one provider’s telemetry, another’s IAM model, and a third’s configuration state can still be assessed together.

That matters because control fragmentation creates blind spots. If each cloud is assessed in isolation, teams often miss cross-platform misconfiguration, inconsistent logging coverage, or permission drift between environments. A common governance layer should define minimum control outcomes while allowing provider-specific implementation details underneath it.

Define the retained customer controls once, then map them to each SaaS or cloud service model.
Standardise logging fields, retention, and alert handoff so events can be correlated across platforms.
Treat configuration reviews as a recurring control, not a one-time migration task.

How should organisations operationalise the shared responsibility model?

Start with a service inventory and a responsibility matrix that names the control owner, the evidence source, and the escalation path for each service. For SaaS, this often means validating tenant settings, access administration, audit exports, and recovery expectations rather than trying to manage the underlying platform. For multi-cloud, it means defining how security baselines, identity controls, and incident workflows are applied consistently despite different native services.

Where the environment spans multiple providers, the operating model should also define how exceptions are approved and how drift is measured. The key question is whether security decisions can be made with the same level of confidence across services, not whether the tools look the same.

Risk and Threat Considerations

Shared responsibility failures usually show up as missed ownership, inconsistent control coverage, or weak visibility across tenant and provider boundaries. That creates exposure to misconfiguration, delayed incident response, and unauthorised access that neither party believes it fully owns.

Failure mechanism: Teams assume the provider covers a control that actually remains customer-owned, or they manage each cloud differently enough that alerting, identity, and configuration drift are not detected in time.

Impact: Attackers can exploit stale permissions, exposed interfaces, weak auditability, or inconsistent tenant controls to move from a limited service issue into broader data exposure or operational disruption.

Standards & Framework Alignment

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

CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-5 — Account Management	Shared responsibility depends on clear ownership of retained access duties.
	CIS-8 — Audit Log Management	The answer relies on consistent logging and cross-platform event correlation.
	CIS-4 — Secure Configuration of Enterprise Assets and Software	Multi-cloud shared responsibility hinges on tenant and platform configuration control.
Recommendation — Assign account ownership and review access regularly across SaaS and cloud services. Centralise and retain logs so events correlate across providers. Enforce secure configuration baselines and monitor drift across cloud environments.
NIST SP 800-53 Rev 5	AU-2 — Audit Events	Shared responsibility needs defined audit coverage for retained customer controls.
	CM-2 — Baseline Configuration	Consistent control outcomes across clouds require approved configuration baselines.
	AC-2 — Account Management	Retained identity administration is central to the customer side of shared responsibility.
Recommendation — Define required audit events for each SaaS and cloud service. Establish and maintain approved configuration baselines for each platform. Manage account lifecycle and access approvals for retained customer responsibilities.
ISO/IEC 27001:2022	A.5.23 — Information security for use of cloud services	The question is specifically about control allocation when using cloud services.
	A.5.15 — Access control	Retained access control remains a customer obligation in SaaS and multi-cloud use.
	A.8.15 — Logging	Consistent logging is essential for shared responsibility and multi-cloud visibility.
Recommendation — Document cloud-specific responsibilities and verify them before service use. Define and enforce access control rules for customer-managed access. Enable and retain logs needed to detect and investigate cross-cloud events.

Practitioner Guidance

What to verify: Before relying on a SaaS or multi-cloud control, verify the exact retention boundary for identity administration, audit access, configuration change rights, backup or recovery expectations, and incident notification. If the contract, architecture, and operating procedure do not all name the same owner, treat the control as incomplete.

What to measure: Track configuration drift, logging coverage, unresolved access exceptions, and the time needed to correlate an event across providers. Those measures show whether shared responsibility is actually operationalised or only documented.

Practitioner takeaway: The goal is not to force every control into one model, but to make every important duty unmistakably owned, observable, and testable across all service providers.