Data classification & residency
Data classification and residency is the discipline of knowing which stores hold regulated or sensitive information, labeling them so controls can be applied at the right level, and proving that each store physically lives in a region your organization is allowed to use. It is distinct from encryption or public-exposure work: a bucket can be private and encrypted and still be a violation if it holds regulated records in the wrong geography or has no owner accountable for it. In sprawling multi-cloud estates, data crosses these lines silently — a global service, a cross-region replica, or a disaster-recovery copy quietly moves records into a jurisdiction nobody signed off on. We look for evidence that sensitive data is discovered and classified, that a data owner is assigned, and that its location matches the commitments in your contracts, privacy laws, and regulatory obligations. This is read-only: we inspect discovery tooling, tags, policies, and region configuration, never the contents of the data.
Overview
What this check looks like in practice
You cannot protect data at the right level if you do not know which stores hold regulated or sensitive information, and where those stores physically live. Residency requirements from contracts, regional privacy law, or regulators depend on data staying in agreed geographies, yet replication and multi-region services move it silently. We look for evidence that sensitive data is identified and that its location matches the commitments your organization has made.
Why it matters
An auditor's first question about any sensitive dataset is how you know where it is and who owns it — and in most cloud estates the honest answer is that nobody does, because classification was never applied and residency was never enforced. Residency failures are uniquely expensive: unlike a firewall rule you can tighten, data that has already replicated into a prohibited region cannot be un-moved after the fact, and the exposure may itself breach a contract, a data-processing agreement, or a sovereignty requirement. Regulators and enterprise customers increasingly write geographic constraints into agreements, so a single default-on geo-redundant storage setting can turn a routine configuration choice into a contractual breach. Classification is the upstream control that makes everything else possible — without it, teams cannot know which stores deserve customer-managed keys, stricter access, or residency guardrails, so protection ends up uniform and therefore wrong. This is where findings map straight to ISO 27001 information-classification controls, HIPAA and GLBA data-handling obligations, and the residency clauses that appear in SOC 2 and FedRAMP scope.
What we assess
What we look for
- Sensitive or regulated stores with no classification, sensitivity label, or assigned data owner — data whose protection level cannot be reasoned about
- Native data-discovery tooling (Macie, Purview, Sensitive Data Protection) unenabled or scoped to only a fraction of accounts, so unknown PII/PHI/PAN sits undiscovered
- Regulated data held in regions outside the geographies your contracts, privacy laws, or regulatory scope permit
- Region-restriction guardrails absent — no organization-level policy preventing resources or data from being created in disallowed locations
- Default geo-redundant or multi-region storage and replication that moves data across residency boundaries without an explicit decision
- Global or multi-region managed services (databases, backups, CDN origins) configured without residency constraints on where copies land
- Tagging that is inconsistent or missing, so classification and residency cannot be enforced or audited programmatically across accounts
- No mapping from classified datasets to the frameworks and contractual commitments that govern them, leaving residency claims unevidenced
Across your clouds
AWS, Azure & Google Cloud
AWS
Amazon Macie for automated discovery and classification of sensitive data (PII, PHI, credentials) in S3; AWS Organizations tag policies and AWS Config rules to enforce and monitor classification tags; and region control via Service Control Policies using the aws:RequestedRegion condition key or Control Tower region-deny guardrails, plus review of S3 Cross-Region Replication rules and bucket region placement against residency requirements.
Azure
Microsoft Purview for the unified data map, automated classification, and sensitivity labeling across storage accounts and databases; Azure Policy's allowed-locations built-in policy definition to restrict which regions resources may deploy into; and review of storage-account redundancy (GRS/GZRS geo-replication) and resource tags to confirm data stays within permitted geographies.
Google Cloud
Sensitive Data Protection (formerly Cloud DLP) for discovering and classifying sensitive data in Cloud Storage and BigQuery; the Organization Policy Service resource-location constraint (constraints/gcp.resourceLocations) to restrict where resources and data may be created; and review of bucket and dataset location settings and labels to verify residency and enable consistent classification enforcement.
Example finding
Regulated customer records replicated to a non-permitted region by default geo-redundant storage, with no classification or residency guardrail
Risk: A storage account holding data that a customer contract requires to remain in-region is configured for geo-redundant storage that replicates copies into a second geography, and no organization-level location policy or classification tag exists to catch it — so the residency commitment is breached silently, and because the replication has already occurred the historical exposure cannot be reversed even after the setting is corrected.
Fix: Confirm the residency requirement for the dataset, change the store to a locally-redundant or in-region redundancy option, and delete the out-of-region replica. Apply a classification and data-owner tag to the store, then add an organization-wide allowed-locations policy so future resources cannot be created or replicated outside permitted regions.
Remediation
How to close it
- 1 Run the provider's native discovery tooling (Amazon Macie, Microsoft Purview, or Cloud Sensitive Data Protection) across all in-scope accounts to inventory where sensitive and regulated data actually lives.
- 2 Define a classification scheme and residency policy, then apply consistent tags or sensitivity labels and an assigned data owner to every store that holds regulated information.
- 3 Reconcile each classified store's actual region against the residency commitments in your contracts, privacy laws, and regulatory scope, and remediate any data sitting outside permitted geographies.
- 4 Enforce region constraints at the organization level — SCPs with aws:RequestedRegion, Azure Policy allowed-locations, or GCP resource-location constraints — so disallowed regions are blocked rather than merely audited.
- 5 Review redundancy and replication settings (geo-redundant storage, cross-region replication, global database services) and switch to in-region options wherever residency requires it.
- 6 Wire classification and residency tags into ongoing configuration monitoring so new stores are flagged when they are created without an owner, a classification, or in a prohibited region.
Questions
Do you actually read our sensitive data to classify it?
No. The assessment is read-only and inspects your classification and residency controls — whether discovery tooling is enabled, whether stores carry classification tags and owners, and which regions data sits in. Where native discovery services such as Macie, Purview, or Sensitive Data Protection already run, we review their configuration and coverage; we do not read the contents of your records.
We use encryption and keep buckets private — why does residency still matter?
Encryption and access controls protect data from unauthorized reach, but residency is a separate obligation about where data physically lives. A store can be private and encrypted and still breach a contract or privacy law if regulated records replicate into a region you are not permitted to use. Classification and residency guardrails are what keep that from happening silently.
How is classification different from just finding public buckets?
Public-exposure checks ask who can reach a store; classification asks what is inside it and how sensitive it is. Without classification, protection is applied uniformly, so highly regulated data may get the same controls as public marketing assets. Classification is the upstream step that tells you which stores deserve customer-managed keys, stricter access, and residency enforcement.
See where you stand
A health check finds and prioritizes real exposure. It is not a certification or a promise you will never be breached — closing the findings is what changes your risk.
Related domain surfaces
The rest of what we assess
The same read-only assessment covers every domain — see what else it looks at.
