Shared responsibility models: what is truly the customer’s responsibility?

In a cloud shared responsibility model, the provider secures the cloud infrastructure, while the customer secures what they run and store inside it: identities, configurations, data, and day‑to‑day operations. Understanding these boundaries lets you design safe steps, avoid misconfigurations, and negotiate realistic responsibilities, especially in Brazilian (pt_BR) regulatory and business contexts.

At-a-Glance: What Customers Truly Control

• You configure and secure identities, access, and permissions to your cloud resources.
• You define network exposure (security groups, firewalls, VPNs, WAF rules) for your workloads.
• You protect data: classification, encryption choices, key management, retention, and deletion.
• You manage OS hardening, patching, and application security for IaaS workloads.
• You design backup, restore, and disaster recovery strategies and test them regularly.
• You ensure compliance, logging, monitoring, and incident response for what runs in the cloud.

Common Myths About Customer Responsibilities in Shared Models

The modelo de responsabilidade compartilhada na nuvem is often presented in a simple diagram, but in practice it is easy to misread where the provider stops and the customer starts. A clear definition: the provider secures the infrastructure and managed services; the customer secures configurations, data, identities, and usage.

Myth 1: “The provider encrypts everything, so I do not need to worry about data security.” In reality, you choose which data goes to which service, who can access it, how keys are managed, and how applications handle sensitive information. Encryption by default does not replace access control and good design.

Myth 2: “Using PaaS or SaaS removes my security responsibilities.” It reduces some tasks (like OS patching) but increases others: identity federation, role design, tenant configuration, and monitoring. Responsabilidade do cliente em segurança na nuvem moves up the stack instead of disappearing.

Myth 3: “If something goes wrong, the provider is always liable.” Real contrato de responsabilidade compartilhada cloud documents allocate liability based on whether the issue came from the underlying service or from your configuration and operations. Many breaches are caused by misconfigured storage, keys, or identities that were fully under customer control.

Core Customer Responsibilities Across Major Cloud Providers

Regardless of provider (AWS, Azure, Google Cloud, or a Brazilian local cloud), your responsibilities converge on the same themes: identity, configuration, data, and operations. Providers may use different names, but the core concepts remain stable across services and regions.

Area	Typical Provider Responsibility	Typical Customer Responsibility
Physical & Core Infrastructure	Data centers, hardware, power, networking, hypervisor security.	None directly; you choose regions and availability options.
Network Security	Core backbone security, DDoS protections on the platform.	Design VPCs/VNets, subnets, security groups, firewalls, VPNs, private endpoints.
Compute (IaaS VMs)	Host OS and hypervisor patching, instance availability.	Guest OS patching, hardening, installed software, endpoint protection.
PaaS Services (DB, queues, functions)	Service availability, internal redundancy, base security of the platform.	Access control, network exposure, data model, secrets, query and code security.
Data & Storage	Durability within the service, basic encryption mechanisms.	Data classification, encryption choices, key management, lifecycle and deletion.
Identity & Access Management	Identity platform reliability, MFA options, IAM engine.	Account structure, roles, policies, MFA enforcement, credential hygiene.
Monitoring & Logs	Logging capabilities, metrics pipeline, basic dashboards.	Enabling logs, retention, alert rules, correlation, and response playbooks.
Compliance & Privacy	Compliance of the platform itself (certifications, reports).	Your LGPD/GDPR compliance, processing purposes, DPIAs, and legal bases.

1. Account and tenant design: Organize subscriptions/projects/accounts to separate environments (prod, test, dev) and business units with clear boundaries.
2. Identity and access: Centralize identities, enforce MFA, use least privilege roles, and avoid long‑lived access keys.
3. Network layout: Decide which workloads are internet‑facing, which must be internal, and which must use VPN or private links from Brazil.
4. Service configuration: For each cloud service, configure encryption, backups, retention, and access restrictions explicitly; do not rely on defaults.
5. Operational monitoring: Enable and review logs, define alerts for suspicious activities, and integrate with an incident response process.
6. Vendor and consulting support: When using serviços de consultoria em modelo de responsabilidade compartilhada, keep final design decisions documented and signed off internally-you still own the risk.

Operational Tasks Customers Must Own: Practical Checklist

Day‑to‑day safety in cloud environments comes from operational discipline. The provider offers tools, but you must connect them in a coherent way. Use the following scenarios as a practical checklist of what stays under your direct control.

1. Deploying a new web application on IaaS
   • Harden and patch the OS, including web server and runtime.
   • Configure security groups and firewalls to expose only required ports.
   • Store application secrets in a managed secret store, not in code or images.
   • Enable application and web server logs; ship them to a central log service.
2. Using a managed database service
   • Restrict who can connect (network rules, private endpoints, IP allowlists).
   • Use strong authentication and roles; avoid shared admin accounts.
   • Define backup retention and test restore procedures regularly.
   • Encrypt sensitive columns or fields at the application level when needed.
3. Multi‑account setup for a growing company in Brazil
   • Create separate accounts for production, staging, and development.
   • Apply central guardrails (policies, budget limits, region restrictions).
   • Standardize baseline security configurations using templates or blueprints.
   • Align account structure with LGPD responsibilities and data types.
4. Onboarding a new SaaS service integrated with your IdP
   • Use SSO and SCIM where possible; avoid local users inside the SaaS.
   • Define role mappings from your IdP groups to SaaS permissions clearly.
   • Review the SaaS configuration for sharing, export, and retention options.
   • Ensure logs from the SaaS are exported to your SIEM or monitoring stack.
5. Migrating on‑premises workloads to the cloud
   • Re‑evaluate trust boundaries; do not copy flat internal networks into the cloud.
   • Refactor backup and DR plans to use cloud‑native capabilities.
   • Update documentation and runbooks to reflect the shared model responsibilities.
   • Use treinamento responsabilidade compartilhada provedores de nuvem to upskill your teams before and after the migration.

Security Controls and Compliance Obligations for the Customer

Security and compliance in the cloud are about using provider features in a structured way. The provider rarely enforces correct use for you. The following controls and obligations sit firmly on the customer side of the model.

Customer-Side Security Controls You Must Design

• Identity and access architecture (MFA, SSO, roles, conditional access policies).
• Network segmentation (subnets, security groups, micro‑segmentation for critical services).
• Endpoint and workload protection (EDR/antimalware, OS hardening baselines, secure images).
• Secrets management (managed key vaults, rotation policies, eliminating hard‑coded credentials).
• Logging and monitoring (enabling audit logs, centralizing them, and defining alert rules).
• Application security (secure SDLC, code review, dependency management, runtime protection).

Compliance and Governance Duties That Stay With You

• Defining what personal data is processed, why, and under which legal basis (LGPD/GDPR alignment).
• Maintaining records of processing activities and data flows across regions and providers.
• Conducting risk assessments and DPIAs where required by law or internal policy.
• Implementing data subject rights processes (access, correction, deletion, portability).
• Handling third‑party and sub‑processor due diligence beyond the main cloud provider.
• Documenting and reviewing the contrato de responsabilidade compartilhada cloud with all key vendors, not only hyperscalers.

Data Protection, Backup, and Recovery: Customer Duties Explained

Data is where most business risk lives, yet shared responsibility discussions often stay at infrastructure level. Clarity about data‑related duties is essential to avoid silent failures in backup, retention, and recovery.

• Assuming provider backups cover every scenario: Many services require explicit backup configuration, and point‑in‑time restore has limits. You must decide RPO/RTO and verify they are achievable.
• Confusing durability with recovery strategy: High durability of objects or disks does not mean you can recover from logical errors, ransomware, or accidental deletions without dedicated backup copies.
• Not classifying data: Without classification, you may store highly sensitive data in services or regions that do not meet your regulatory or contractual needs.
• Ignoring key management responsibilities: Even when the provider manages the encryption engine, you decide who can use keys and when; compromised keys remain your responsibility.
• Failing to test restores: Backups that were never tested may be incomplete or misconfigured. Testing is part of your operational duty, not the provider’s.
• Overlooking exit and portability: Long‑term backup and export formats should consider how you will move or decommission data if you change providers or architectures.

When Incidents Happen: Determining Customer vs Provider Liability

When something breaks, the shared model becomes very concrete. Liability usually follows control: whoever controlled the failing component is typically responsible, subject to the details of contracts, SLAs, and local law.

Consider a simplified incident in a Brazilian company using IaaS and a managed database:

1. An attacker obtains leaked application credentials from a public code repository.
2. Using those credentials, the attacker connects to the managed database over the internet.
3. Network rules were configured by the customer to allow wide access, including from the internet.
4. Logs show the provider’s platform worked as designed; the database stayed available and consistent.

In this scenario, root causes are weak secret management and permissive network configuration-both under customer control. The provider is unlikely to be liable, even though the attacker used a managed service. Effective use of the shared model means building safer defaults, reviewing configurations regularly, and ensuring operational maturity, not expecting the provider to “catch” your mistakes.

Straight Answers to Practical Customer Concerns

Is the cloud provider responsible if my data is leaked from a misconfigured storage bucket?

Generally no. If you configured the bucket to be public or allowed broad access, that decision is considered under your control. The provider is responsible for the platform working correctly, not for your access rules.

Does using managed services remove my patching responsibilities?

It removes some, but not all. The provider patches the underlying service and OS, but you must update your application code, client libraries, containers, and any integration components you deploy.

How can I clearly understand what is mine vs the provider’s in a shared model?

Review your provider’s shared responsibility documentation, map it to your architectures, and then document responsibilities per service. Include this mapping in your internal policies and in any contrato de responsabilidade compartilhada cloud with partners.

Do I need separate training for different cloud providers?

Concepts are similar, but implementations differ. Focus treinamento responsabilidade compartilhada provedores de nuvem on shared principles first, then add hands‑on practice for each provider your organization actually uses.

When does it make sense to hire consulting services for shared responsibility?

When you lack in‑house experience to design guardrails, multi‑account strategies, or compliance mappings. Use serviços de consultoria em modelo de responsabilidade compartilhada to accelerate design, but keep decision authority and documentation internally.

Who is responsible for meeting LGPD requirements in a public cloud setup?

You, as controller or processor, remain responsible for LGPD compliance. The provider offers compliant infrastructure and tools, but you decide what personal data to store, where, and how to secure and govern it.

Can a provider ever be liable for a security incident?

Yes, if the root cause is a failure of the underlying service or an SLA breach. Proving this requires logs, contracts, and sometimes independent investigation, so maintain detailed evidence and clear support channels.