Define who protects cloud identities, configurations, data and recovery before a gap becomes an incident.
A cloud service still needs an owner
Moving an application to the cloud changes the work involved in protecting it. It does not remove the need to decide who performs that work. A provider may operate the physical infrastructure while the customer remains responsible for user access, data handling and configuration choices. The exact boundary depends on the service and the agreement, so it should be checked rather than assumed.
Infrastructure, platform and software services allocate responsibilities differently. A virtual machine may require the customer to maintain its operating system, while a hosted application may handle that layer for them. Provider documentation from AWS and Microsoft illustrates these distinctions. Use the documentation for the actual product you purchase, including any features that require separate configuration or licensing.
Build a responsibility table for each service
Create a short table covering identity, privileged access, configuration, logging, updates, data protection, backups and incident response. For each activity, name the provider responsibility, the customer responsibility and the person who verifies it. Where an IT partner performs the task, identify a business owner who can review the evidence and approve decisions.
For example, a provider may generate audit logs while the customer must enable the right events, choose retention and arrange investigation. A storage service may support encryption without deciding which employees should see a document. A backup feature may be available without meeting the recovery requirements of a particular workflow. Translate product capabilities into tasks that somebody actually performs.
Review identities and configurations together
Start with administrative accounts and external sharing. Require appropriate authentication, remove unused access and avoid giving routine users broad administration rights. Review invitations, application integrations and service credentials as well as human accounts. An organisation can have strong employee sign-in controls while an abandoned integration still retains extensive access to its information.
Use approved configuration baselines and review changes against them. Pay attention to publicly accessible storage, permissive network rules and settings that expose data to more people than intended. CISA's cloud architecture guidance treats monitoring and cloud security posture management as part of operating the environment. A secure initial setup needs a process for detecting drift as the service changes.
Plan for evidence, continuity and exit
Ask how the organisation will obtain the information needed during an incident. Confirm which logs are available, how long they remain accessible and what the provider can supply through support. Keep a reliable escalation route. Define who can restrict access or suspend a service, and consider the effect on other teams before using those controls in an emergency.
Test how important data can be restored or exported. Recovery should account for accidental deletion, malicious changes and a loss of access to the primary tenant. Keep the process proportionate to the business requirement and the provider's actual capabilities. Document how access and data will be handled when the service is replaced, the contract ends or the supplier changes its offering.
Review after meaningful changes
Revisit the responsibility table when you enable a major integration, add a new type of data or change the support arrangement. Include cloud services in the regular asset and risk review. Clear ownership makes cloud security easier to operate because questions about evidence, configuration and response already have an agreed destination.
