Who owns cloud security responsibilities in managed cloud IT services?

Cloud security responsibilities in managed cloud IT services are divided according to the technology layer, the control being operated and the party able to make the relevant decision. The provider usually manages the security of the hosted platform and the services it has agreed to operate, while the customer retains accountability for business decisions, information use and authorised access. Ownership should therefore be documented control by control rather than assumed from the fact that a service is hosted in the cloud.

The service model affects the allocation. In infrastructure-as-a-service, the provider commonly maintains physical facilities, hardware, core networking and the underlying virtualisation layer. The customer may still need to secure operating systems, workloads, applications, identities, network rules and stored information. With platform-as-a-service, the provider takes responsibility for more of the operating environment, but the customer remains responsible for the application code, user permissions, data and settings it controls. Software-as-a-service generally transfers more technical maintenance to the supplier, but it does not remove the customer’s responsibility for account administration, information governance, user behaviour or appropriate configuration.

Responsibility should be separated from accountability. A provider may perform a task, such as applying a security update or reviewing an alert, while the customer remains accountable for deciding whether the control meets its business, contractual or regulatory requirements. Conversely, a customer may own a policy but delegate its day-to-day operation to the managed service provider. This distinction prevents gaps caused by statements such as “the provider looks after security” without specifying what that means in practice.

A useful responsibility schedule should identify, for each important control:

• the system, data or process covered;
• the party responsible for configuring and operating the control;
• the party approving exceptions or accepting risk;
• the evidence that demonstrates the control was performed;
• the information each party must provide to the other; and
• the escalation route when the control fails or an incident is suspected.

Identity and access management require particular care. The provider may administer the technical identity platform, but the customer normally decides who should have access, which privileges are appropriate and when access must be removed. The arrangement should cover joiners, movers and leavers, privileged accounts, multi-factor authentication, service accounts, third-party access and periodic access reviews. Shared administrator credentials make ownership difficult to prove and should be avoided where individual accounts and audit trails are available.

Configuration is a shared operational risk. Secure baseline settings, network restrictions, logging, encryption options, retention rules and backup policies may be implemented by the provider, selected by the customer or jointly approved. The agreement should state who can change each setting, how changes are authorised, how configuration drift is detected and who assesses the security effect of a requested change. A provider cannot reliably protect a control that the customer can alter without notification, and a customer cannot assess risk if it has no visibility of material changes.

Data protection responsibilities extend beyond hosting. The customer should determine what information may be placed in the service, the required retention period, acceptable locations and who may process it. The provider should explain how data is protected within the managed environment, how access is recorded, how backups are handled and how information is returned or securely removed when the service ends. Where personal data is involved, the parties should document their respective data protection roles and the arrangements for handling subject rights, breaches, subcontractors and international transfers where relevant.

Monitoring and incident handling need an agreed hand-off. The operating model should define which events the provider monitors, what constitutes a reportable alert, what information is included in a notification and which decisions remain with the customer. The customer may need to approve containment actions that could interrupt business operations, preserve evidence, inform insurers or regulators, and communicate with affected parties. These dependencies should be recorded in an incident procedure and tested so that authority is clear before a real event occurs.

Security assurance is also divided. A provider can supply service records, audit information, vulnerability findings, configuration reports and details of relevant controls. The customer must review that evidence against its own risk assessment and compliance obligations rather than treating a certification or assurance report as proof that every customer configuration is secure. The contract should state the form, scope and frequency of assurance information, along with the process for addressing control weaknesses.

Subcontractors and connected services should not be overlooked. A managed cloud service may depend on hosting, backup, security monitoring or support partners. The customer should understand which parties can access systems or data, how those parties are assessed, where their responsibilities sit and how the customer will be informed of material changes. Responsibility should remain traceable through the supply chain instead of ending at the primary provider.

Before signing or renewing a managed cloud agreement, a business should check that it can answer these questions:

1. Which cloud layers and security controls are included in the managed service?
2. Which decisions and administrative permissions remain with the business?
3. Who owns identity approval, access reviews, encryption choices and retention settings?
4. What monitoring, vulnerability management and security testing does the provider perform?
5. How are incidents reported, investigated, contained and closed?
6. What evidence is supplied to support internal reviews or regulatory enquiries?
7. How are backups, service termination, data export and secure deletion managed?
8. How are exceptions, customer-controlled settings and changes to the service recorded?

S2 Technology Group can help businesses map these responsibilities to their managed cloud arrangements, review practical control ownership and identify areas where the contract, configuration or internal process leaves an avoidable security gap. The objective is a documented operating model in which every important control has an owner, an accountable decision-maker and a defined way to demonstrate that it is working.