Misconfigured Cloud Storage Exposure via Vendors

In 2019, a security researcher discovered a publicly accessible AWS S3 bucket containing the personal data of over 540 million Facebook users. The bucket did not belong to Facebook. It belonged to a third-party app developer who had collected the data through Facebook's platform and stored it in cloud storage with no access controls applied. Facebook had not misconfigured anything. Their vendor had , and the data was sitting openly on the public internet, indexed and accessible to anyone who found the URL. This is the storage misconfiguration problem through a third-party lens: your data, your regulatory exposure, someone else's mistake.

What is Cloud Storage Misconfiguration, Really?

Cloud object storage , AWS S3, Azure Blob Storage, Google Cloud Storage , is one of the most widely used and most frequently misconfigured services in enterprise cloud environments. It is cheap, scalable, and designed to make data accessible at speed. That accessibility is also its primary risk vector. Every cloud storage bucket or container has an access control configuration that determines who can read from it, write to it, or list its contents , and the default configurations, the ease of making buckets public, and the complexity of permission inheritance have combined to make cloud storage misconfiguration one of the most consistent sources of data breaches over the past decade.

In the vendor context, the risk takes two distinct forms. The first is a vendor misconfiguring storage that holds your data , either storage provisioned in their own cloud environment to process data you have shared with them, or storage provisioned within your cloud environment that the vendor manages on your behalf. The second is a vendor whose access to your cloud storage is misconfigured on your side , overly permissive bucket policies, missing access controls, or public access settings that allow the vendor's credentials to reach data they were never intended to see. Both forms result in the same outcome: data that should be protected is accessible to parties who should not have it.

What makes this persistently difficult is the gap between intended configuration and actual configuration. A developer creating a bucket for a vendor data exchange intends it to be accessible only to the vendor's specific IAM role. They set the bucket policy, test that the vendor can access it, and move on. What they may not have checked is whether the account-level public access block is enabled, whether the bucket's ACL allows broader access than the policy intends, whether the bucket is accessible from other roles in the same account with broader permissions, or whether a subsequent configuration change somewhere in the stack silently overrode their original intent. Cloud storage permissions are layered and interact in ways that are not always intuitive, and most vendor data exchange configurations are set up once and never audited again.

Storage misconfiguration risk through vendors surfaces across several specific patterns:

• Publicly accessible vendor-managed buckets containing your data , the most visible and most common form, where a vendor's storage configuration inadvertently allows unauthenticated access to objects
• Overpermissive bucket policies in your environment , storage you control that grants the vendor broader access than necessary, allowing them to read data beyond the intended scope of the integration
• Missing encryption at rest , vendor-managed storage receiving your data without encryption configured, leaving the data readable by anyone with storage-level access regardless of network controls
• Vendor backup and archive storage configured with weaker controls than primary storage , data migrated to cheaper storage tiers with less rigorous access management
• Logging and access monitoring gaps , storage access events not being captured, meaning unauthorized reads of your data generate no alert and leave no audit trail

Why this matters

Cloud storage misconfiguration sits at the intersection of two risk categories that TPRM programs often treat separately: vendor data handling and cloud security. When a vendor misconfigures storage containing your data, the resulting breach is simultaneously a vendor security failure and a cloud security failure , but the regulatory and reputational consequences land on your organization as the data controller or custodian. GDPR, CCPA, HIPAA, and equivalent frameworks do not provide an exemption for breaches caused by vendor negligence. They impose obligations on the data controller to ensure vendors handle data appropriately, and a misconfigured bucket is evidence that those obligations were not met.

The third-party dimension creates a specific visibility problem. When your own team misconfigures cloud storage, there is at least a plausible path to detection , internal security scanning, cloud security posture tools, or an alert triggered by anomalous access patterns. When a vendor misconfigures storage in their own environment, you have no direct visibility. You are dependent on the vendor detecting and disclosing the issue, or on a security researcher or threat actor finding it first. In the majority of documented cloud storage breach cases, the exposure was discovered externally , by researchers, by automated scanners, or by attackers , before the organization or their vendor became aware of it.

The scale of exposure in a storage misconfiguration can also be disproportionate to the apparent simplicity of the failure. A single misconfigured bucket can contain years of accumulated data , transaction records, customer files, backup archives, log exports , that was deposited over time without anyone taking stock of the total volume. The breach is not proportional to the effort that caused it. A single checkbox in the wrong state can expose millions of records accumulated over years of normal operations.

Where most teams get this wrong

The most consistent failure is the assumption that data security is governed by the data transfer mechanism rather than the data storage configuration. Organizations that encrypt data in transit, use secure file transfer protocols, and authenticate vendor access carefully often have no corresponding controls or requirements around how the vendor stores the data once it arrives. The secure handoff does not extend to the landing zone. What happens to the data after it reaches the vendor's environment is often entirely ungoverned in the customer's security framework.

The second failure is treating storage configuration as a one-time setup task rather than an ongoing governance obligation. Bucket policies and access controls set at the time of integration establishment can be overridden by subsequent configuration changes, platform updates, or well-intentioned adjustments made by the vendor's engineering team without understanding the security implications. A vendor whose storage was correctly configured at onboarding but has since drifted , through automation, through incident response shortcuts, or simply through accumulated small changes , represents a risk that no amount of initial due diligence will catch.

• No requirement in vendor contracts for encryption at rest on storage containing customer data
• No assessment of whether vendor-managed storage has public access blocks enabled , the single most effective control against accidental public exposure
• Vendor data handling assessments that cover transfer security but not storage security , treating the handoff as the risk boundary
• No visibility into vendor storage access logs , whether the customer's data in vendor storage is being accessed, by whom, and whether those access patterns are expected
• No configuration drift monitoring on storage provisioned within your own cloud environment that vendors access , what was correctly configured at setup may not remain correctly configured

What good looks like

Organizations with mature vendor storage security governance treat data handling requirements as a contract obligation, not a vendor preference. The specific storage configuration controls that protect their data are defined, documented, and verifiable , not assumed based on the vendor's general security posture.

• Contractual encryption at rest requirements for all storage containing customer data , specifying the encryption standard and key management approach, not just stating that encryption is required
• Public access block verification as a standard vendor assessment question for any vendor using cloud object storage , this single control prevents the most common class of storage exposure
• Storage access logging enabled and retained for all vendor-managed storage containing customer data , logs reviewed for anomalous access patterns on a defined schedule
• CSPM coverage of your own cloud environment detecting misconfigurations in storage accessible to vendors , continuous monitoring rather than point-in-time assessment
• Data minimization enforced , vendors store only the data they need, for only as long as they need it, with deletion requirements contractually specified and periodically verified
• Vendor storage configuration reviewed as part of periodic reassessment , not just questionnaire responses, but evidence of current configuration state

Tooling

The tooling landscape for cloud storage security is mature on the customer side and increasingly available for vendor-side assessment. The gap for most organizations is applying these tools to vendor-managed storage, not just internally managed resources.

Cloud Security Posture Management , Wiz, Orca Security, Prisma Cloud, Lacework

CSPM platforms continuously scan cloud environments for storage misconfigurations , publicly accessible buckets, missing encryption, overpermissive ACLs, and access logging gaps. For your own cloud environment, these tools provide continuous coverage of storage accessible to vendors. For vendor environments, some CSPM platforms support agentless scanning of vendor cloud accounts where the vendor grants read-only assessment access , enabling direct configuration verification rather than reliance on questionnaire attestation.

Native Cloud Storage Security , AWS S3 Block Public Access, Azure Storage Defender, GCP VPC Service Controls

Each major cloud platform provides native controls specifically designed to prevent the most common storage misconfiguration failures. AWS S3 Block Public Access, when enabled at the account level, prevents any bucket in the account from being made publicly accessible regardless of individual bucket settings , it is a guardrail against the most visible class of storage breach. Azure Defender for Storage provides threat detection on storage access patterns. These native controls are free or near-free and should be treated as baseline requirements for any vendor managing cloud storage.

Data Loss Prevention , Microsoft Purview, Google Cloud DLP, Nightfall

DLP tools provide visibility into what sensitive data exists in cloud storage environments , enabling organizations to understand the actual exposure surface of a misconfiguration rather than discovering it only after a breach. For vendor assessments, asking whether the vendor has DLP coverage of storage containing customer data is a meaningful maturity signal , it indicates whether the vendor understands what sensitive data they hold and whether they are monitoring it.

Cloud Storage Access Monitoring , AWS CloudTrail + S3 Access Logs, Azure Storage Analytics, Datadog

Storage access logging captures every read, write, and list operation against cloud storage resources. In the context of vendor-managed storage, these logs are the audit trail for every interaction with your data , providing evidence of normal operations and a detection mechanism for unauthorized access. Requiring vendors to enable and retain access logging on storage containing customer data is a baseline contractual control that also supports incident investigation if exposure occurs.

Governance challenges

The governance challenge with vendor storage security is that it requires extending your security configuration standards into environments you do not directly control. Most organizations have internal standards for cloud storage configuration , encryption requirements, access control policies, logging mandates. Applying those same standards to vendor-managed storage requires translating internal technical requirements into contractual obligations and then verifying compliance against those obligations, which is operationally more complex than simply enforcing a policy within your own environment.

The practical answer is to make storage security requirements specific and verifiable rather than general and attestation-dependent. 'Vendor must implement appropriate security controls for data at rest' is unenforceable. 'Vendor must enable AES-256 encryption at rest, enable public access blocks, enable access logging with 12-month retention, and provide configuration evidence on annual request' is a governance standard that can be assessed, evidenced, and enforced.

• Define specific storage security requirements in vendor contracts , encryption standard, public access controls, logging requirements, and retention periods, not general security language
• Request storage configuration evidence annually , screenshots or exports of bucket/container configuration settings are not difficult to provide and are far more meaningful than questionnaire attestation
• Include storage security in vendor tiering criteria , vendors that process large volumes of sensitive data in cloud storage warrant deeper configuration assessment than those handling minimal data
• Monitor your own cloud storage continuously for configuration drift , CSPM tools applied to storage accessible to vendors provide early warning of misconfigurations on your side of the boundary
• Contractually require breach notification within 24-72 hours of discovery of any unauthorized access to storage containing your data , the timeline matters for regulatory notification obligations

If you are a small team

Start with the most impactful single control: verify that public access blocks are enabled on all cloud storage in your own environment and ask your top five data-handling vendors whether public access blocks are enabled in their environments. This single question, applied to the vendors that hold your most sensitive data, will surface the most significant exposure risks faster than any comprehensive assessment framework. Then add encryption at rest verification as the second question.

• Enable AWS S3 Block Public Access at the account level, Azure Storage Defender, or GCP VPC Service Controls in your own environment , these are largely free and immediately reduce your own misconfiguration risk
• Run a CSPM scan on your own cloud environment to identify any storage accessible to vendors that has misconfigured access controls
• Add two questions to your vendor assessment: 'Is public access blocked on all storage containing our data?' and 'Is encryption at rest enabled on all storage containing our data?'
• For your highest-risk vendors, request a configuration screenshot or export as evidence , move from attestation to verification on storage security specifically

What to require

Ask directly:

"Is public access blocked at the account or storage-account level for all cloud storage containing our data? Can you provide configuration evidence confirming this?"

"Is encryption at rest enabled on all storage containing our data, and who manages the encryption keys , the cloud provider, your organization, or a dedicated key management service?"

"Is access logging enabled on storage containing our data, how long are those logs retained, and do you have a process for reviewing them for anomalous access patterns?"

Expect as evidence

• Configuration screenshots or exports confirming public access blocks are enabled , not a checkbox on a questionnaire
• Encryption configuration documentation specifying the encryption standard and key management approach
• Access logging confirmation with retention period specified
• Evidence of CSPM or equivalent continuous scanning covering storage environments holding customer data

A vendor who responds to these questions with 'our cloud environment is secure' without providing specific configuration evidence is asking you to accept their assurance in place of verification. For data handling vendors specifically, that is not an acceptable substitute.

How to evidence it

Cloud storage security is now a standard area of examination in data protection audits, regulatory reviews, and breach investigations. When a breach occurs through a vendor's misconfigured storage, the investigation will focus on what due diligence the data controller performed to ensure the vendor's storage was appropriately secured. General vendor security assessments that did not specifically address storage configuration will not satisfy that standard.

• Vendor assessment records documenting storage security controls , encryption, access controls, logging , for vendors handling sensitive data in cloud storage
• Configuration evidence collected from vendors confirming specific security controls are in place
• CSPM scan records for your own cloud environment confirming storage accessible to vendors meets your security baseline
• Contractual data handling requirements specifying storage security obligations , not general security language
• Breach notification clause in vendor contracts with defined timelines for storage exposure incidents

Key Takeaway

Cloud storage misconfiguration is not a sophisticated attack vector , it is one of the simplest failure modes in cloud security, and it has produced some of the largest data breaches of the past decade. When it happens through a vendor, the simplicity of the failure compounds the frustration: a single misconfigured setting in an environment you do not directly control exposes data you are legally responsible for protecting. The answer is not to trust vendors to get storage configuration right , it is to make specific, verifiable storage security requirements a standard part of how you govern vendor data handling. Public access blocked, encryption at rest enabled, access logging active. Three controls. Contractually required, periodically verified, not assumed.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations