Wasabi’s Shared Responsibility Model: Protecting Data in the Cloud

When it comes to securing data in the cloud, responsibility is shared. At Wasabi, we provide a secure, reliable cloud storage platform, but customers also play an important role in protecting the data they store in it. Our shared responsibility model makes the boundary clear: we outline what Wasabi protects, and what you must configure and manage in your own environment.

That clarity is what helps teams assign ownership internally, design controls that stand up in audits, and respond faster when something goes wrong. If you know exactly which layer you own, you can focus your time and attention on the settings and practices that reduce risk in the real world.

Why shared responsibility exists

In a traditional data center, one organization typically owns and manages everything end-to-end: physical facilities, servers, networks, storage systems, and all of their associated security controls. Cloud changes that model. A cloud storage provider operates the infrastructure and platform. Customers control how their data is accessed, governed, and protected inside that service.

That split is why shared responsibility matters. It removes ambiguity about who manages what. It lets Wasabi focus on securing the cloud infrastructure layer, while you focus on securing access, policies, and data behavior in your environment. And it makes compliance and incident response less painful because you can map controls and accountability to a clear model rather than assumptions.

The model at a glance

At the highest level, shared responsibility is simple:

Wasabi secures the cloud itself. Customers secure what they put in the cloud.

Let’s have a closer look at these two aspects of responsibility:

• Security “in” the cloud: the customer-controlled controls of identity, access, data policies, immutability, and operational practices that determine how data is protected and managed

• Security “of” the cloud: the underlying platform, infrastructure, facilities, and operations that run the service

If you’re a technical leader, this is the ownership map. The rest is converting it into controls you can enforce and audit.

Figure 1: Wasabi Shared Responsibility Model

What customers manage: Security “in” the cloud

As a Wasabi customer, you decide how your data is secured, accessed, and managed inside the platform. These responsibilities tend to cluster into three practical areas: identity and access, data protection behaviors, and encryption / operational hygiene.

1) Access control and identity: IAM, MFA, SSO, MUA

Most cloud storage risk starts with access. That doesn’t mean the platform is insecure; it means the biggest exposure typically comes from mis-scoped permissions, leaked credentials, or overly broad administrative access.

IAM (Identity and Access Management) is the set of controls that determines who can access your storage environment and what actions they’re allowed to take. In practice, IAM is how you enforce least privilege: granting only the permissions required for a role or workload.

Customer-owned IAM responsibilities include:

• Defining users, roles, and policies that determine access

• Using IAM policies for granular control rather than relying on broad credentials

• Applying the principle of least privilege consistently

• Avoiding root credentials for day-to-day operations and using IAM roles instead

Beyond authorization, you also control authentication strength:

• MFA (Multi-Factor Authentication) adds an additional verification step beyond a password. It’s one of the simplest ways to reduce the impact of credential theft.

• SSO (Single Sign-On) allows your enterprise identity provider to manage authentication and access lifecycle, so joining/leaving the organization and policy enforcement can follow your standard processes.

Finally, some actions deserve extra protection beyond standard login controls:

• MUA (Multi-User Authentication) requires multiple approvals for sensitive actions (for example, changes to Object Lock settings). A single compromised account should not be able to disable your most critical protections.

Think of this identity layer as the gatekeeper for everything else. If you get IAM right, the rest of your storage security posture becomes easier to enforce and audit.

2) Data protection behaviors: retention, immutability, versioning, lifecycle management

The next layer is how your data behaves over time: what’s retained, what can be deleted, how recovery works, and what protections exist against tampering.

At the governance level, customers own:

• Data classification (what kind of data is this, and how sensitive is it?)

• Retention schedules (how long do we keep it, and why?)

• Secure deletion practices aligned to internal policy and regulation

These aren’t paperwork tasks. They shape the actual settings you apply in the storage environment, and they matter in audits and incident response.

Object lock and immutability (WORM)

For ransomware defense and compliance-driven retention, immutability is often the highest-value control. Wasabi Object Lock enables data to be stored in a tamper-resistant way, preventing unauthorized deletion or modification for a defined period.

This is commonly described as WORM protection (Write Once, Read Many). Once the object is written and locked, it can be read as needed, but it can’t be changed or deleted until the retention period expires.

Object lock matters because it’s a practical answer to a common failure mode: attackers (or accidents) deleting backups, wiping recovery points, or changing the rules that protect data. It also supports compliance and legal hold scenarios where data must remain intact for a defined period.

In the shared responsibility model, Wasabi provides the Object lock capability. Customers decide:

• Where object lock is enabled

• What data sets require immutability

• How long retention should be

• Who can change those settings (and whether MUA is required)

Covert Copy (ransomware recovery)

Covert Copy, an innovative new security offering from Wasabi, goes a step further for ransomware recovery. By creating an isolated recovery copy of critical data, your data remains out of reach even if credentials are compromised.

Covert Copy includes:

• A logically air-gapped recovery copy built for ransomware scenarios

• Hidden buckets that aren’t visible through standard bucket listing operations

• Enforced Multi-User Authentication (MUA) for access and recovery actions

• Permanent immutability with no retention expiration

• Protection against overwrite, deletion, or tampering, even if an attacker gains access credentials

In other words, Wasabi Object Lock helps prevent tampering in place; Covert Copy is about ensuring you still have a clean recovery path if primary data is encrypted, corrupted, or otherwise unavailable.

Bucket policies, versioning, and lifecycle management

Buckets are the “containers” that organize data in object storage, and this is where security intent becomes enforceable behavior. Customers configure:

• Bucket policies that define access patterns and restrictions

• Versioning rules that help protect against overwrites or deletions by preserving prior object versions

• Lifecycle management rules that automate retention and cleanup over time

These controls work together. For example, versioning and lifecycle policies can support recovery and governance, while object lock enforces immutability when data must be tamper-resistant. You don’t need to turn everything on everywhere, but you do want a deliberate approach: which workloads are protected by which controls, and why.

3) Encryption choices and operational hygiene: keys, endpoints, transfers

Wasabi encrypts data at rest by default. On the customer side, teams may choose additional encryption approaches if internal policy requires customer-managed keys or pre-encryption before upload:

• Client-side encryption (optional): you encrypt data before upload using your own keys

• SSE-C (server-side encryption with customer-provided keys): Wasabi encrypts server-side, but customers supply and retain ownership of the encryption keys

Encryption strategy is often less about “more encryption” and more about alignment: key ownership requirements, operational feasibility, and what your audit/compliance posture expects.

Customers are also responsible for the operational and network layer around storage access:

• Ensuring secure data transfers (for example, HTTPS)

• Protecting API keys and endpoints used by applications and integrations

• Managing firewall and VPN configurations in the broader environment

This is where real-world failures happen: keys stored in the wrong place, overly permissive endpoints, or integrations that bypass your normal identity standards. Good operational hygiene reduces the chance that a small mistake becomes a major incident.

What Wasabi manages: Security “of” the cloud 

While customers secure what’s inside their environment, Wasabi secures the foundation of the service: infrastructure, hardware, and data centers. This is the layer customers shouldn’t have to build, operate, or physically protect themselves.

Encryption at rest (baseline)

All data is automatically encrypted at rest using AES-256. Customers don’t need to deploy or manage encryption infrastructure just to achieve baseline encryption at rest.

Durability and resilience at the storage layer

Wasabi is designed for high durability through redundancy, integrity validation, and automatic repair mechanisms. In practical terms, this is the platform-level engineering that protects data against hardware failures and supports consistent storage reliability.

Core platform infrastructure

Wasabi secures and maintains the underlying systems that power the service, including:

• Compute resources used to run the platform

• Object storage systems

• Metadata and control plane databases (the systems that coordinate storage operations and management functions)

• Networking fabric (the internal network that ties platform components together)

This is the operational layer that customers depend on but don’t directly manage.

Data centers, hardware, physical security, and compliance alignment

Wasabi operates secure data centers designed for resilience and availability, including redundant power and cooling and continuous monitoring. Wasabi also owns and maintains the hardware stack (servers, storage devices, and networking gear) which supports consistency and operational control.

From a governance standpoint, Wasabi maintains compliance alignment and auditing across major frameworks (for example, ISO 27001, HIPAA, GDPR/UK GDPR, and SEC requirements). The purpose is to give customers confidence in the platform foundation while keeping customer-side configuration and data governance in the customer’s hands.

Operational best practices

The shared responsibility model becomes real when it translates into repeatable controls. If you’re looking for a practical baseline, these are the highest-impact places to start:

• Enforce MFA and strong password policies for administrative access

• Apply least privilege to IAM policies and roles (grant the minimum needed, then expand deliberately)

• Use IAM roles instead of root credentials for day-to-day operations

• Rotate access keys on a defined cadence and remove unused credentials

• Review access logs regularly, not only during incidents, so anomalies are easier to spot early

These practices aren’t glamorous, but they’re the controls that consistently prevent avoidable exposure.

Stronger together

Cloud security works best as a partnership. Customers apply the controls that determine day-to-day risk: identity and access, immutability, encryption strategy, bucket configuration, retention behavior, and operational hygiene. Wasabi provides a secure, resilient foundation with infrastructure, platform operations, and facility-level controls that customers shouldn’t have to manage.

Together, that division creates clarity, reduces risk, and supports the compliance and resilience outcomes organizations depend on.