Cloud Data Security and Shared Responsibility

Shared responsibility follows the service

Cloud responsibility is divided between the provider and customer, and the boundary changes with the service. A provider operates facilities and underlying infrastructure; a customer decides what data to put into a service, who can access it, how it is classified and how it may be used. Managed services shift more operation to the provider, but they do not transfer the customer’s decisions about data, identities, configuration or legal obligations.

Do not use a service-model chart as a contract. SaaS, PaaS and IaaS describe broad patterns, but the exact responsibility for logging, encryption keys, backup, patching, retention and configuration depends on the service and its terms. Review the provider’s responsibility documentation and map it to the customer’s own control owners.

These are broad study patterns, not a guarantee about a specific product. A provider may offer customer-controlled keys, managed backups or detailed audit logs; another service may handle those differently. Determine what the service actually performs, what the customer can configure and what the contract assigns.

Start with discovery and classification

A data-protection plan begins by finding the information and its flows. Data can be structured in tables, semi-structured in event records, or unstructured in documents, images and messages. It may be copied into logs, backups, analytics tools or AI services. Discovery identifies locations and movement; classification assigns handling expectations based on sensitivity and business or legal needs.

Classification should guide decisions. A public product image does not need the same access restrictions as a customer identity document. Once a data owner identifies the category, the organization can choose who may use it, where it may be processed, whether masking or tokenization is appropriate, what encryption and key controls are needed, how long to retain it and how to prove access.

A discovery scan is not a classification policy. A scan may locate likely identifiers, but an owner still needs to confirm context, apply the approved category and connect it to a handling rule. Labels and tags can then help cloud services enforce access, retention or DLP rules. Incorrect labels can expose data or block legitimate work, so classification quality matters.

Protect data at rest, in transit and in use

Encryption protects confidentiality when data is stored or transmitted, but it does not replace authorization or lifecycle controls. Key management determines who can create, use, rotate and revoke keys. A customer-controlled key may give the customer additional control, while also creating responsibility to protect availability and preserve a recovery path. A lost key can make protected information unusable.

Hashing can help verify integrity or support non-repudiation when applied within an appropriate design. Masking, anonymization and tokenization change how sensitive values appear to users or systems. Information-rights management can restrict permitted use or distribution. Data-loss prevention can detect or block certain transfers. These techniques solve different problems; select them based on the data and workflow rather than treating them as interchangeable.

Access remains central. Limit users and service accounts to the data they need, review permissions when roles change and remove access when it is no longer required. In SaaS, the provider may operate the application, but customer administrators still control user roles and many settings. A provider’s infrastructure protection does not make an overly broad analyst role safe.

Balance customer key control with recovery

Customer-controlled encryption keys can strengthen separation of duties and limit provider access, but they create operational responsibilities. Define who can use and administer keys, how access is approved, how revocation affects running services and how recovery works if an administrator leaves. A key rotation policy that nobody can operate may interrupt access to valid records. Assess confidentiality and availability together, then verify which parts the provider manages for that service.

For a customer-managed key, the provider may supply the encryption mechanism while the customer controls key permissions. For provider-managed keys, the service may automate more of the operation, while the customer still chooses which identities can read the data and whether the arrangement meets policy. The service documentation and contract determine the specific boundary.

Control retention, archiving and deletion

Retention rules balance business needs, legal obligations and data minimization. An archive should remain protected and discoverable for its approved purpose. At the end of the retention period, use a defined deletion procedure and verify that the data is removed from the relevant service and copies. Media sanitization can involve overwriting or cryptographic erase, depending on the system and data.

A legal hold changes the normal deletion decision for the records it covers. The data owner and legal function should identify the held subset, preserve it and prevent scheduled deletion from destroying it. Data outside the hold can still follow its normal retention process. Keeping every record indefinitely because one subset is held increases exposure and storage without a matching need.

Cloud deletion needs a service-specific view of backups, replicas, snapshots, logs and subcontractor copies. The customer should understand what deletion means under the provider’s service terms, how long residual copies persist and what evidence can be supplied. A customer-issued delete request may not immediately purge every backup, so define the expected process before the data is placed in the service.

Make data events traceable

Accountability requires logs that show useful context, such as identity, time, source address, location where available, action and affected data or resource. Define event sources, protect log storage, limit access to records and review the signals that matter. Logs should help answer who accessed data, what changed, where information moved and whether a policy or incident process needs to begin.

If logs may support an investigation, preserve their integrity and document how evidence was collected, transferred and stored. Chain of custody matters when a record may be used for legal, regulatory or disciplinary review. Centralizing logs can improve visibility, but access to the central system and its retention also need protection.

Map each lifecycle decision to an owner

This matrix is a planning aid, not a universal promise about a vendor. Before relying on it, replace the broad descriptions with the provider’s actual service documentation, contractual terms and customer settings. A control can be split: the provider may generate a log, while the customer enables export, stores a protected copy and reviews it.

For example, a provider may encrypt stored objects by default, yet the customer still decides who can retrieve them and whether a key policy fits the data. A platform may retain service backups according to its own design, while the customer defines the record-retention period and communicates legal holds. Ask what the service does automatically, what the customer must configure and what evidence confirms each action.

Apply the model to a migration scenario

A health-services organization plans to move support documents and diagnostic files to a cloud analytics provider. Some documents contain personal information; the data’s locations and retention rules are not fully mapped. The team should begin with discovery and classification, identify allowed processing locations and users, review the provider’s data-use and deletion terms, and decide which fields need masking or tokenization for analysis.

The customer should map responsibility for identities, key choices, query permissions, event logging, retention and incident notification. The provider may operate the managed analytics engine and its underlying infrastructure, while the customer remains responsible for what it uploads, who queries results and whether the use is permitted. A provider assurance report can support review only if its services and customer controls match the actual deployment.

Before migration, test a sample lifecycle: ingest a classified record, grant access to a named role, log a query, apply an approved retention date, place a record under legal hold and delete a record that is no longer required. This exercise exposes gaps between policy and service behavior before the full data set is moved.

Account for AI and machine-learning data

The current outline includes security and privacy of AI data sets and models. A cloud AI service can receive prompts, documents, training data, retrieval indexes and model outputs. Each may contain sensitive information. Identify the data source, validate its integrity and permission, restrict who can submit or view it, and understand whether the provider retains it or uses it for another purpose.

A model can reveal information through outputs even when the original file is not directly downloadable. Access control, testing, validation, retention and data minimization still apply. If a model supports a high-impact business process, define who reviews outputs and how questionable results are escalated. Do not assume that an AI feature has the same retention or access behavior as the underlying storage service.

Common shared-responsibility mistakes

• Assuming the provider is responsible for customer data access because it operates the service.
• Assuming encryption fixes excessive access, unlawful use, incorrect retention or poor data discovery.
• Treating an assurance report as coverage for every feature, region or customer setting.
• Deleting data automatically without checking whether a legal hold applies.
• Assuming a managed service makes customer identity, logging and recovery decisions unnecessary.

A useful review asks who controls each setting, which obligation applies and what evidence shows the control works. The customer may rely on provider evidence for physical and platform safeguards while still testing its own permissions, retention rules and monitoring. Shared responsibility requires an explicit map, not a general belief that security belongs to one side.

Try a data-lifecycle decision