Cloud data security: make shared responsibility specific

A cloud provider operates part of the security environment. Your team still needs to establish which protections it configures, whether they cover the data and services in use, and how it knows they remain effective.

Cloud data security protects confidentiality, integrity, and availability across storage, processing, sharing, and recovery. It includes databases and object stores, but also application permissions, SaaS exports, service identities, backups, and the laptops or automation systems that can retrieve data.

From a CTO’s perspective, shared responsibility becomes useful only when it produces specific engineering decisions: who configures a control, who monitors it, what evidence demonstrates its operation, and who acts when it fails. A provider’s security statement cannot answer those questions for your deployment.

Establish the boundary before choosing controls

Cloud environments combine remotely delivered infrastructure, platforms, and applications. Public cloud generally uses provider-operated infrastructure serving multiple customers; private cloud is dedicated to an organization. Neither label determines whether your data is adequately protected. Isolation, access paths, operational ownership, and recovery arrangements matter more than the label.

Start with one business service and trace its dependencies. Identify cloud accounts or subscriptions, regions, services, data stores, administrators, and deployment systems. Include SaaS products used by support, finance, and engineering: a production database may be tightly controlled while its customer export sits in a broadly shared workspace.

The inventory should answer these questions:

• What information is stored or processed, and who owns the business purpose?
• Where are the primary records, replicas, logs, exports, caches, and backup copies?
• Which people, workloads, suppliers, and external recipients can access them?
• Which accounts, regions, and services are approved, and how are new ones discovered?
• What retention, deletion, availability, and contractual requirements apply?

Cloud scalability and remote accessibility can improve operations, while managed services can reduce infrastructure maintenance. They also make it easy to create resources and copies faster than reviewers can track them. Security cost therefore includes identity administration, monitoring, evidence collection, recovery testing, and supplier oversight—not just the storage bill.

Classify information where it actually lives

Use a manageable classification scheme tied to actions. For example, public, internal, confidential, and restricted categories can determine sharing rules, access reviews, logging, and retention. Define which category covers customer identifiers, authentication secrets, financial records, source code, and sensitive personal information.

Automated discovery can help locate overlooked datasets, but validate results with data owners. A scanner may miss compressed archives or application-specific fields, while a harmless test string may trigger a false positive. Record unscanned locations and sampling limits. For a fuller discovery workflow, see data discovery and privacy.

Map responsibility service by service

The responsibility boundary changes with the service model and the provider’s implementation. Treat the following as a starting point to confirm against service documentation and contracts, not a universal allocation.

For every important protection, record the provider contribution, customer configuration, operating owner, reviewer, and evidence source. Avoid entries such as “encryption: provider.” Instead write: “Provider supplies managed encryption; platform team selects the key configuration; security reviews decrypt permissions; service owner tests recovery.”

Include service identities and deployment automation alongside human users. A pipeline that creates resources, changes access policies, or retrieves secrets is part of the security boundary. Managed-service operators and external support providers also need explicit responsibilities, even when they administer infrastructure on your behalf.

Identify handoff failures. If the provider reports a compromised credential, who receives the notice outside working hours? If a database is unavailable, who decides whether to restore, fail over, or wait? Assign one accountable internal owner to each customer-side outcome, even where several teams execute the work.

Evaluate provider assurance without overextending it

Review the service’s security documentation, incident communications, support-access arrangements, subprocessors, deletion behavior, recovery options, and available audit logs. Check whether the relevant account tier actually includes the features your design needs.

Assurance documents need scope review. A SOC 2 report is an attestation report, not a certification. ISO 27001 certification concerns a scoped information security management system, not proof that your tenant is configured securely. Check services covered, reporting period, exceptions, and customer controls identified in the report.

Where relevant, BSI’s C5 catalogue provides cloud assurance criteria. Distinguish a Type 1 assessment of design and implementation at a point in time from Type 2 coverage of operation over a period. Neither replaces testing your own access and data flows.

Translate obligations into technical requirements

Determine applicable law and customer commitments before selecting a region or accepting provider terms. Applicability depends on information, processing roles, sector, jurisdictions, and service relationships. A provider report or certificate does not establish your organization’s legal compliance.

For personal data covered by the GDPR, Article 32 requires security appropriate to risk; it is not a blanket mandate to encrypt every dataset in every circumstance. Where the provider acts as a processor, assess the Article 28 contractual requirements. International-transfer arrangements require a separate assessment. Data location alone does not prove sovereignty or GDPR compliance, particularly where support access or subprocessors create additional access paths.

As a practical recommendation, translate each applicable requirement into a testable statement: permitted processing regions, approved recipients, retention periods, access restrictions, recovery objectives, or incident-notification handoffs. Have legal and privacy specialists confirm the interpretation while engineering establishes how the requirement will be implemented and evidenced.

Verify effective access, not just intended permissions

Stolen credentials, excessive privileges, public sharing, and insider misuse are common routes to cloud data exposure. An encrypted store can still disclose records through an authorized account or an application that returns the wrong customer’s data.

Federate human identities where feasible so joiner, mover, and leaver processes reach cloud services. Require strong authentication for privileged access, favor phishing-resistant MFA where supported, and separate routine work from administration. Emergency access needs controlled credentials, monitored use, and a tested recovery process; it should not become a permanent bypass.

For workload identities, prefer narrowly scoped, short-lived credentials where supported. Review trust relationships: which workload may assume a role, under which conditions, and in which environment? Remove embedded secrets from repositories and deployment artifacts, and restrict access to the secrets service itself.

Evaluate effective permissions across identity policies, resource policies, role assumptions, group membership, sharing links, and organization-level restrictions. “Read-only” may still permit large-scale extraction of sensitive information. A role that cannot read records but can alter the application or key policy may obtain access indirectly.

Access review evidence should identify the principal, resource, allowed actions, business justification, approver, and removal date where applicable. Test offboarding and expired temporary access rather than relying exclusively on a written procedure.

Inspect exposure and application behavior together

Misconfiguration often combines several individually plausible settings. For an object store, default encryption does not answer who can read objects or whether a sharing policy makes them public. Examine identity, resource policies, application behavior, and monitoring together.

Check public-access restrictions, network ingress, database listeners, cross-account trust, signed-link behavior, and external sharing. Private endpoints can reduce exposure, but they do not correct excessive privileges or a vulnerable application. Separate environments and constrain production access from development systems.

Cloud APIs need authentication and authorization at the object and action level. A valid user token must not allow someone to retrieve another tenant’s records by changing an identifier. Test export endpoints, administrative operations, bulk queries, and upload handlers. Rate limits can reduce abuse but do not substitute for authorization.

Use infrastructure-as-code review and policy checks to prevent known unsafe settings, then compare approved rules with deployed configuration. Console changes, migrations, and emergency fixes can create drift. Record why exceptions exist, their compensating controls, and when they expire. Threat modeling can help identify paths from an exposed interface to sensitive data before implementation.

Make encryption and key access separate controls

Protect data in transit using modern authenticated protocols and appropriate certificate validation. Review internal application connections as well as public endpoints. For stored data, establish which services, replicas, exports, snapshots, and backups are encrypted, and under what key arrangements.

Provider-managed keys and customer-managed keys support different operational choices. Select based on the threat model, contractual requirements, administrative separation, and recovery needs. A customer-managed key is not automatically safer if the same unrestricted administrator controls both data access and key permissions.

Document who may encrypt, decrypt, administer, disable, and delete keys. Review key-policy changes and unusual decrypt activity. Establish rotation, revocation, retention, and recovery processes; rotating a key does not necessarily re-encrypt every existing copy, depending on the service.

KMS and HSM services can support key protection and cryptographic operations, but they do not remove lifecycle responsibilities. Test the consequences of key unavailability before enforcing a deletion or revocation process. A protected backup is unusable if its required key cannot be recovered. See encryption and key management for the supporting cryptographic decisions.

Monitor data activity and preserve response capability

Logging must cover the questions responders need to answer. Administrative audit events may show who changed a policy without showing who downloaded a dataset. Establish where data-access logging is available, whether it is enabled, and which events or services remain outside coverage.

Collect relevant identity, control-plane, data-access, application, key-management, and sharing events. Preserve account and resource identifiers, actor identity, timestamps, actions, and outcomes. Protect logs against alteration and unauthorized deletion. Avoid placing sensitive payloads or reusable credentials in logs; diagnostic data can become another exposure source.

Prioritize detection scenarios such as:

• A restricted store becoming publicly accessible.
• New external trust or a privileged role assignment.
• Unusual bulk exports or access by a dormant identity.
• Logging being disabled or its destination changed.
• Backup deletion or key-administration changes.

Define responders and test alerts through a controlled exercise. A rule that fires into an unattended inbox is not an effective detection process. Record collection failures, delayed ingestion, newly created resources, and provider limitations rather than presenting a dashboard as complete coverage.

During an incident, preserve relevant evidence and coordinate containment across identities, applications, and storage. Revoking one token may not terminate other sessions or stop an export already in progress. For personal data breaches under the GDPR, processors notify controllers without undue delay. Controllers notify the supervisory authority without undue delay and, where feasible, within 72 hours of awareness, unless the breach is unlikely to risk individuals’ rights and freedoms. High-risk breaches also require communication to affected individuals without undue delay, subject to Article 34 exceptions. Preserve the notification or non-notification reasoning.

Use security tools for defined questions

Cloud security tools are most useful when their scope and decision purpose are clear:

Start DLP enforcement with representative testing and data-owner review. A rule that blocks legitimate support work can drive users toward uncontrolled workarounds. Restrict scanners and monitoring agents to the access they need; a discovery tool with broad read access becomes a sensitive component itself.

Automation can reduce repetitive checks and evidence collection. It cannot establish that an unsupported service is secure or that a legal interpretation is correct. Keep human review explicit for material findings and exceptions.

Prove recovery independently of backup status

Backups address loss and corruption only if they can be restored within the service’s needs. Establish recovery point objectives for tolerable data loss and recovery time objectives for tolerable interruption with the business owner.

Distinguish replication, versioning, snapshots, and backups. Replication may copy corruption or deletion. Snapshots may remain vulnerable to the same administrator who controls production. Select protected copies and administrative separation appropriate to the threat model, including deletion resistance where supported.

Restore a representative workload into an isolated environment. Check data consistency, application dependencies, identity configuration, key availability, and elapsed recovery time. Database restoration alone does not demonstrate that the business service works. Record failures and retest after remediation.

Evaluate SaaS recovery separately. Provider disaster recovery may restore the platform without reversing your tenant’s accidental deletion. Determine available restore granularity, retention windows, export options, and responsibility for initiating recovery. Apply classification and retention rules to backups too.

Worked example: a customer export service

Consider an illustrative SaaS team using a managed database, an object store for exports, and a background worker. Assume exports contain confidential customer contact information, customers access only their own exports, and the agreed recovery objectives are four hours of data loss and eight hours of interruption. These are example assumptions, not recommended universal targets.

The provider operates the managed infrastructure. The platform team configures network restrictions, identities, encryption, and logging. Application engineers own tenant authorization and export-link behavior. The service owner approves retention and recovery objectives; security reviews access and evidence.

The worker receives permission to read the necessary database records and write exports to the designated store. It does not need permission to change storage policy or delete backups. Downloads pass through tenant authorization; any temporary links have bounded validity and are treated as bearer credentials. Export files expire according to the approved retention rule.

Testing includes an unauthenticated object request, a customer attempting to retrieve another customer’s export, and a worker attempting a prohibited administrative action. Reviewers also verify that public access is blocked and that test downloads produce expected audit events.

A restore exercise checks the database and application dependencies against the assumed recovery objectives. Evidence includes configuration exports, authorization-test results, sampled access events, and the restore record. If data-access logging is missing for one region, the review records that gap and assigns remediation; successful testing elsewhere does not close it.

Preserve scope, exceptions, and review decisions

Evidence should identify account, resource, time, collection method, and reviewer. A configuration export from one account cannot establish every account’s posture. Compare collected resources with the inventory and record failed collections or inaccessible locations.

Maintain a compact evidence set for each service: its responsibility map, approved baseline, current configuration checks, effective-access review, logging coverage, recovery results, and open exceptions. Each exception needs an owner, risk rationale, compensating controls, approval, expiry, and retest condition.

Use scheduled reviews alongside event-driven triggers. Material deployment changes, new regions, supplier changes, incidents, altered data classifications, and new sharing paths should prompt reassessment. The NIST Cybersecurity Framework provides a useful organizing reference across Govern, Identify, Protect, Detect, Respond, and Recover; it is guidance, not proof that a deployment meets its obligations.

Secani can connect this work to requirements, target objects, evidence, owners, tasks, and review decisions. Model the cloud service and its dependencies, attach configuration exports and test records to the controls they support, and turn missing coverage into assigned work. Keep human approval and source traceability explicit. Cloud security tools remain the source of technical configuration and alerts; the compliance workspace preserves their scope and the actions they support.

For the next engineering review, select one sensitive data flow. Trace every copy and access path, assign the customer-side responsibilities, test effective permissions, and restore a representative workload. Expand the scope once that review produces reliable evidence and a repeatable process.