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.
Related resources from NHI Mgmt Group
- How should organisations implement SOX controls across cloud and SaaS environments?
- How should healthcare organisations implement HIPAA controls across SaaS, cloud, and collaboration tools?
- How should organisations implement cloud compliance across shared-responsibility environments?
- How should security teams implement cloud user access reviews across SaaS and multi-cloud environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
