Who owns security responsibilities in your cloud environment?
Security in a cloud environment is shared between the cloud provider, which protects the underlying infrastructure, and the customer, which remains responsible for identities, access settings, data, devices and configurations under its control. S2 Technology Group helps businesses define these responsibilities and manage the security controls needed across cloud services and endpoints.
Cloud security responsibility is allocated according to the service model, the contract and the organisation’s own configuration choices. A provider may operate the facilities, hardware and core platform, but the customer remains accountable for deciding who can access business information, how services are configured and how endpoints connect to them.
The division of responsibility usually follows three layers:
- Cloud provider: protects the physical sites, hardware, underlying network and core service infrastructure within its control.
- Customer: governs users, identities, permissions, data, security policies, service configuration and the devices used to access the environment.
- Technology partner or managed IT provider: may administer agreed controls on the customer’s behalf, but this does not remove the customer’s accountability for approving requirements, accepting risk and checking that controls are operating as intended.
The balance changes between cloud service models. With a hosted application, the provider typically manages more of the platform, while the customer still controls user access, data handling, connected devices and tenant-level settings. With infrastructure or platform services, the customer usually has greater responsibility for operating systems, workloads, networks, applications and security configuration. The exact boundary should be confirmed in the provider’s documentation and agreement rather than assumed from the name of the service.
Customer-owned responsibilities commonly include:
- creating, reviewing and removing user accounts;
- applying least-privilege access so people receive only the permissions needed for their role;
- protecting privileged accounts with strong authentication and separate administrative identities;
- configuring security, sharing, retention and audit settings;
- classifying information and deciding where it may be stored or transferred;
- maintaining supported endpoints, operating systems and security software;
- controlling third-party applications, integrations, browser sessions and unmanaged devices;
- reviewing logs, alerts and provider notifications; and
- planning how access, data and services will be handled during an incident or when a supplier relationship ends.
Responsibility also applies to information that moves between systems. A cloud provider may secure its own service, but it cannot decide whether a user should export confidential records, whether an integration has excessive permissions or whether a file-sharing link is appropriate. Those decisions depend on the customer’s policies, business processes and risk tolerance.
Clear ownership should therefore be recorded in a responsibility matrix. For each important control, the matrix can identify who is accountable for the decision, who performs the task, who reviews evidence and who must be consulted. Useful entries include identity administration, access reviews, vulnerability management, backup testing, logging, incident escalation, supplier assurance and data retention. This prevents assumptions such as treating a provider’s infrastructure certification as proof that a customer’s tenant settings are secure.
Contracts and supplier documentation should be checked for the practical boundaries of the service. Important points include security obligations, audit information, breach notification arrangements, data locations, subcontractors, recovery provisions, logging availability and the process for securely deleting or returning information. These terms do not replace internal controls, but they define what the provider is expected to operate and what evidence the customer can request.
Effective governance combines technical safeguards with regular review. Access should be reassessed when people change roles or leave, configuration changes should be approved and recorded, exposed services should be identified, and logs should be examined for unusual activity. Exceptions should have a named owner, a documented reason, an expiry or review date and compensating controls where appropriate.
S2 Technology Group can help organisations map these boundaries across their cloud services and endpoints, translate them into practical policies and manage agreed security controls. The customer should nevertheless retain oversight of business requirements, risk acceptance and the decisions that determine how its information is protected.
During a cloud security incident, responsibility is divided according to which party controls the affected layer and which evidence it can access. The cloud provider investigates faults within its platform, while the customer assesses the effect on its accounts, data, users and connected endpoints.
- The provider should investigate service-wide failures, platform vulnerabilities and infrastructure events within its contractual scope.
- The customer should determine whether accounts, permissions, devices, applications or data were misused, and decide what business action is required.
- Any managed IT provider may carry out agreed containment and recovery tasks, such as disabling accounts or isolating endpoints, but should work from the customer’s approved incident process.
This distinction prevents a provider notification from being treated as a complete incident assessment. A service may be restored while compromised credentials, unauthorised downloads or unsafe endpoint sessions still require investigation. Incident procedures should therefore specify who can declare an incident, who preserves evidence, who communicates with the provider and who approves restoration of access.
