Cloud Security Shared Responsibility: The Tasks Your Provider Won’t Do for You

Moving a workload to a reputable cloud provider changes where some security controls operate; it does not transfer every security decision to the provider. The provider may protect physical facilities and parts of the underlying service, while the customer remains responsible for identities, data, configuration, and how the application is used. The exact division changes between infrastructure, platform, and software services. A clear shared-responsibility map helps UAE business leaders avoid both duplicate work and dangerous assumptions.

Start with the service model and the actual contract

Microsoft’s shared-responsibility guidance explains that tasks vary by service type: customers generally take on more infrastructure management in infrastructure-as-a-service, while managed platform and software services shift some operational responsibilities to the provider. “Shift” does not mean “disappear.” A managed database may handle some patching while the customer still chooses user permissions, data classification, network exposure, backup policy, and application queries. A cloud email provider may secure its platform while the customer configures multifactor authentication, retention, external sharing, and account recovery.

Create a matrix for each important service rather than relying on a general cloud diagram. Mark each control as provider-operated, customer-operated, shared, or needing clarification. Check service documentation, contract terms, support plan, and actual configuration. Provider responsibilities can differ by product, region, and feature. Ask the vendor to clarify areas such as incident notification, log availability, data export, backup retention, identity integration, and support access. If the answer is unclear, record it as a risk or contract question rather than assuming the most favorable interpretation.

Identify customer-owned controls that are often missed

Identity is a common customer responsibility. Maintain named accounts, enforce multifactor authentication where available, remove former-user access promptly, and limit administrative privileges. Protect emergency accounts and document how they are used. Review third-party applications connected to business accounts; a secure platform cannot prevent risk from an overly broad integration that the customer approved. Keep access reviews proportionate to risk and maintain an owner for service identities and keys.

Configuration and data handling also remain significant. Decide which resources are publicly reachable, how encryption and keys are managed, where sensitive information may be stored, and how exports are protected. The fact that a provider offers encryption or logging does not guarantee that every relevant setting is enabled or that your team reviews the result. Check whether backup coverage includes the data and configuration needed for recovery, and test that a backup can be restored. Establish who owns vulnerability remediation in application code and who can safely deploy a fix.

Make responsibility operational with a control matrix

For each workload, list the controls that matter: identity, device access, network rules, application updates, data classification, encryption, logging, incident response, backup, recovery, and supplier oversight. Assign an accountable role and evidence for each item. Evidence may be a configuration export, review record, tested restore, or signed vendor answer. Avoid ambiguous ownership such as “IT” when multiple providers or departments are involved. A service owner is responsible for coordinating the result even if a specialist performs the technical task.

Use the matrix during onboarding and change review. When a team enables a new managed service, ask which settings are inherited and which require customer action. When an employee changes role, check access across cloud accounts and SaaS applications. When a provider changes a product, assess whether the responsibility boundary moved. CISA’s Cross-Sector Cybersecurity Performance Goals are a voluntary prioritized baseline that can help organizations choose foundational security outcomes. Use them to guide proportionate action, not as a claim that an SME has met every applicable legal or contractual obligation.

Prepare for incidents and provider dependencies

Write down how your business will receive a provider security notice, decide whether it affects your systems, preserve relevant logs, and communicate internally. Know which logs your subscription includes, how long they are retained, and who can access them. A provider may investigate its platform while your organization investigates accounts, data access, customer impact, and business decisions. Establish contact paths and an incident severity process before a real event. If a critical control depends on a vendor support ticket, confirm response expectations rather than assuming immediate assistance.

Plan for service disruption and exit as well as cyber incidents. Export critical data periodically, understand format and portability limits, and know which alternate channels support customer service. A provider’s own continuity capabilities do not automatically establish your recovery time or restore your business process. Record dependencies on identity, DNS, billing access, support portals, and key staff. Protect break-glass procedures while ensuring they are available to authorized responders when normal access is impaired.

Shared-responsibility review checklist

1. List cloud and SaaS services supporting important business processes.
2. For each service, verify the shared-responsibility boundary in current provider documentation.
3. Assign an owner for identity, configuration, data, logging, backups, updates, and response.
4. Test multifactor authentication, administrator access, offboarding, and recovery credentials.
5. Confirm which logs, alerts, backups, and support channels are included in your service tier.
6. Review vendor access, incident communication, data export, and service-exit arrangements.
7. Exercise a restore and an incident escalation using the named owners.
8. Revisit the matrix after significant product, contract, or architecture changes.

A UAE SME example and conclusion

A Dubai marketing firm adopts a hosted customer relationship platform and assumes the vendor handles security. A review reveals that the platform protects its service, but the firm must still configure administrator MFA, approve integrations, manage user offboarding, and control exported lead lists. The business assigns a sales operations owner for permissions, an IT contact for identity and logs, and a privacy contact for data use. It tests a user-removal workflow and requests written clarification on incident notice and export from the vendor. These actions do not eliminate risk; they convert unclear assumptions into accountable tasks.

Cloud security is a partnership with boundaries that differ by service. Ask what the provider operates, what your team configures, and how each side supplies evidence. Microsoft’s guide was updated on 24 August 2026, but service-level documentation and contracts remain essential. Combine the responsibility map with prioritized controls and periodic tests. Seek qualified advice for UAE-specific, free-zone, sector, and contractual requirements rather than treating a provider statement as a compliance guarantee.

Sources and further reading

• Microsoft: Shared responsibility in the cloud
• CISA: Cross-Sector Cybersecurity Performance Goals