How to Audit Cloud Storage for Sensitive Data Exposure Before an Incident Forces You To

The first audit challenge is completeness: most organizations cannot produce an accurate list of all their cloud storage from memory. Storage proliferates through self-service provisioning, application deployments, and collaboration tool use.

AWS S3 enumeration. Across all accounts in your AWS Organization: aws s3 ls --region us-east-1 lists buckets in the current account. To enumerate all accounts: use AWS Organizations with a Lambda function or script that assumes a read-only role in each member account and runs the S3 list command. Collect: bucket name, region, account ID, creation date, and current block public access settings. Flag any bucket where BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets are not all set to true.

Microsoft SharePoint and OneDrive enumeration. Use the SharePoint admin center's Active Sites view (or the PowerShell equivalent: Get-SPOSite -Limit All) to list all SharePoint sites. For each site: export the current external sharing setting (Disabled, Existing guests only, New and existing guests, Anyone). Flag any site with "Anyone" sharing enabled, which allows link sharing without authentication.

Google Drive Shared Drives enumeration. In the Google Workspace Admin console: Reports > Drive > Shared Drive activity, or use the Google Drive API to enumerate all shared drives in the domain. For each shared drive: export the sharing settings (domain-only, specific people, public). Flag any shared drive with content shared publicly or with "Anyone with the link" access.

Azure Blob Storage enumeration. Use the Azure CLI: az storage account list --query '[].{name:name, resourceGroup:resourceGroup}' across all subscriptions. For each storage account: check the publicNetworkAccess setting and the allowBlobPublicAccess property. Flag storage accounts with blob public access enabled.

Access control misconfiguration is distinct from sensitive data presence -- a publicly accessible bucket that contains only non-sensitive public assets is a configuration concern but not a data exposure risk. A privately accessible bucket containing sensitive data that is readable by all authenticated users in the company is a data exposure risk. The audit identifies both.

AWS S3 public access. For each S3 bucket where Block Public Access is not fully enabled: check the bucket ACL (aws s3api get-bucket-acl) and bucket policy (aws s3api get-bucket-policy) for any statements that grant access to "Principal": "*" or "Principal": {"AWS": "*"}. These are publicly readable buckets. Also check for s3:GetObject grants to "Principal": {"AWS": "arn:aws:iam::*:root"} or AllUsers group. Use AWS Trusted Advisor or AWS Config rule s3-bucket-public-read-prohibited to automate this check.

SharePoint "Anyone" links. In the SharePoint admin center: Reports > Sharing > Files shared with "Anyone" links. This report shows all files across all SharePoint sites that have been shared via an unauthenticated "Anyone with the link" URL. Sort by date and site to identify patterns (a single site producing many Anyone links may indicate a training gap or a business process that needs a more controlled alternative).

Google Drive "Anyone with the link" sharing. In Google Workspace Admin: Security > Access and data controls > Drive and Docs > Sharing settings. At the domain level, disable "Allow users to publish files on the web or make them visible to anyone with the link" if the business does not require public sharing. For existing publicly shared files: use Google Vault or the Drive API to enumerate files with "type": "anyone" in the permissions.

Azure blob public access. For any storage account with allowBlobPublicAccess = true: enumerate containers within the account (az storage container list) and check which containers have public access level set to blob (individual blob access) or container (full container listing and read access).

Knowing which storage has overly permissive access controls is necessary but not sufficient. The remediation priority depends on what data is in each storage location. A publicly accessible S3 bucket containing product images has different risk than one containing customer account exports.

Automated data classification scanning. Several tools scan cloud storage for sensitive content patterns:

• AWS Macie: Scans S3 buckets for PII (names, addresses, SSNs, credit card numbers), credentials (AWS keys, passwords in plaintext), and custom data identifiers. Enable Macie across all accounts via AWS Organizations and run a discovery job on all buckets. Macie findings show which specific buckets contain which sensitive data categories.

• Microsoft Purview: Scans SharePoint, OneDrive, and Exchange for sensitive information types (credit card numbers, passport numbers, health information, custom patterns). Create a content scan job targeting all SharePoint sites with priority on sites identified as having external sharing enabled.

• Google Cloud DLP: Scans Google Drive and Google Cloud Storage for sensitive data types. Configure a DLP job targeting all shared drives in the domain, using the built-in infoType detectors for PII, credentials, and financial data.

• Varonis or Normalyze (commercial DSPM tools): Provide cross-platform sensitive data discovery with risk correlation between data sensitivity and access control permissiveness. These produce prioritized findings (high-sensitivity data in publicly accessible locations ranked above low-sensitivity data in internal-only locations).

The data classification scan prioritizes remediation: address the intersection of "high sensitivity data" and "overly permissive access control" first.

Remediating cloud storage access controls at scale risks breaking legitimate business processes if done without coordination. The remediation sequence accounts for this.

Immediate remediation (no coordination required): Remove public access from any storage location where a data classification scan identified sensitive data. This is the high-priority group: sensitive data + public access = immediate risk. For S3: enable Block Public Access at the bucket level and remove any bucket policy statements that grant public read. For SharePoint: remove all "Anyone" links for files identified by Macie or Purview as containing sensitive data. For Google Drive: revoke "Anyone with the link" sharing for items with sensitive content. These changes are safe to make immediately because legitimate external access to sensitive data without authentication is not a valid business use case.

Coordinated remediation for broad internal sharing: Storage locations with sensitive data accessible to "all authenticated users in the organization" are a different risk profile from public access, but still warrant remediation. Notify the business unit that owns the storage location: "This SharePoint site/S3 bucket/Shared Drive contains [data category] and is accessible to all employees. We recommend restricting access to [specific group]. Please confirm the intended audience so we can implement the correct access control." Give 14 days for response before implementing the more restrictive control.

Enable preventive controls at the organization level: After remediating existing exposure, implement organization-level preventive controls that prevent new exposure from being created:

• AWS: Enable S3 Block Public Access at the AWS Organization level (applies to all accounts, prevents any new public S3 configuration)
• Microsoft 365: Set the default SharePoint external sharing level to "Existing guests only" or "Only people in your organization" at the tenant level
• Google Workspace: Disable external sharing by default at the organizational unit level, enabling it only for OUs where external sharing is an approved business requirement

One-time audit remediation without ongoing monitoring produces a clean state at the audit date and accumulating exposure afterward. Three monitoring controls maintain the clean state:

Real-time alerting for public access changes. For AWS: AWS Config rule s3-bucket-public-read-prohibited with a CloudWatch Events rule that triggers an alert (and optionally a Lambda function that automatically re-enables Block Public Access) when a bucket's public access settings change. For Azure: Azure Policy with a deny effect on storage account blob public access changes. For Microsoft 365: Microsoft Purview Data Loss Prevention policies that alert when an "Anyone" link is created for a file containing sensitive content.

Weekly external sharing report. SharePoint admin center and Google Workspace admin both support scheduled external sharing activity reports. Schedule a weekly report delivered to the security team and data protection officer showing: new external sharing events in the last 7 days, files shared via unauthenticated links, and new external users given access to internal sites. This provides visibility without requiring manual inspection of every sharing event.

Quarterly data classification rescan. New data is continuously uploaded to cloud storage. A quarterly data classification scan catches new sensitive data in locations that were clean at the last audit but have since received sensitive uploads. Run Macie, Purview content scan, or Google Cloud DLP quarterly against all storage, not just the locations that were flagged in the initial audit.

CSPM integration for access control drift. Cloud Security Posture Management platforms (Wiz, Orca, Prisma Cloud) continuously monitor cloud storage access controls and alert on drift from the defined baseline. If CSPM is already deployed, configure a policy that flags any storage location with sensitive data classification that transitions from internal-only to external or public access.

Every cloud storage audit surfaces storage locations that have no clear owner: S3 buckets created by a project that has since ended, SharePoint sites whose admin left the company, Google Drive shared drives from a merger integration that were never cleaned up.

Ownerless storage is a significant risk because there is no one to notify for coordinated remediation and no one tracking what data it contains or who can access it.

Owner identification. For S3 buckets: check the bucket's tags for an Owner or Team tag (this is why a bucket tagging policy with mandatory Owner tags is valuable). Query CloudTrail for the IAM identity that created the bucket. Check cost allocation tags to identify the billing team. For SharePoint sites: the SharePoint admin center shows the site's primary and secondary site collection administrators -- contact them directly even if they have left the company (their manager or successor typically holds this context). For Google Drive shared drives: the Workspace admin console shows the drive managers.

Escalation for unowned storage with sensitive data. If a storage location contains sensitive data and cannot be attributed to any current owner: escalate to the data protection officer and the business unit that is most likely responsible based on the data content (customer records suggest the customer-facing team, financial records suggest finance, HR data suggests HR). Document the escalation and the response. For GDPR, HIPAA, or PCI-scoped data: unowned storage with sensitive data that has been accessible beyond its intended audience may require regulatory assessment even without a confirmed external breach.

Decommission rather than leave orphaned. If a storage location has no current business use, no owner, and contains no sensitive data: decommission it. Unused storage that cannot be attributed to any team is a permanent audit finding that creates ongoing monitoring burden without business value.

The cloud storage audit produces findings that have regulatory implications (GDPR, HIPAA, PCI DSS all require appropriate access controls on regulated data). Leadership needs to understand the findings at a level that supports remediation prioritization and compliance decisions without requiring technical details.

The audit report for leadership should include:

Risk summary. Total number of storage locations audited, number with overly permissive access controls, number of those containing sensitive data (the intersection that represents the highest risk), and the estimated number of records that were exposed based on the data classification scan results.

Regulatory implications. For any sensitive data exposure that affects regulated data categories (PII under GDPR, PHI under HIPAA, cardholder data under PCI DSS): note whether the exposure requires regulatory notification based on your legal team's interpretation of applicable regulations. Proactive disclosure to counsel before remediating is typically required for confirmed data exposure incidents in regulated categories.

Remediation status and timeline. What has been remediated immediately (public access to sensitive data -- no coordination required), what is in the coordinated remediation queue (broad internal access requiring owner notification), and what organization-level preventive controls will be implemented to prevent recurrence.

Ongoing monitoring posture. What monitoring has been put in place after the audit so that leadership can confirm the organization will know if new exposure occurs, rather than only learning about it during a future audit or an incident.