It's important to know where your data is physically located at all times. Processes and procedures should be in place to track and document the specific locations where data is stored, processed, and backed up. This ensures compliance with applicable laws and regulations.
Where did this come from?
This control comes from the CSA Cloud Controls Matrix v4.0.10 - 2023-09-26. You can download the full matrix here. The CCM provides a controls framework for cloud security good practices aligned to leading standards, regulations, and privacy frameworks. For more background, check out the CSA CCM FAQ.
Who should care?
- Chief Compliance Officers looking to meet data residency and sovereignty requirements
- IT managers responsible for data backups and disaster recovery planning
- DevOps engineers provisioning cloud infrastructure and services
- Auditors assessing an organization's data governance practices
What is the risk?
Not tracking data locations can lead to:
- Inadvertently storing regulated/sensitive data in unapproved regions
- Inability to comply with data residency laws (e.g. GDPR)
- Surprising costs from data transfer/egress fees
- Difficulties responding to e-discovery and audit requests
The risks range from hefty fines for non-compliance to reputational damage and lost customer trust. Having a register of data locations is foundational to managing these risks.
What's the care factor?
Compliance-sensitive organizations should care a lot about data location tracking, as should those with customers in multiple jurisdictions. Even if it's not a top priority, some basic processes are important for all. At minimum, know what country your production data resides in.
When is it relevant?
Data location processes are most relevant when:
- Subject to industry regulations like HIPAA, PCI-DSS, GLBA, etc.
- Doing business in regions with strict data residency laws (e.g. EU)
- Leveraging public cloud services across multiple regions/zones
- Outsourcing any data processing or backup to third parties
Conversely, data location may be less of a concern for smaller businesses operating in a single country and doing everything in-house.
What are the tradeoffs?
Restricting data to specific locations can:
- Limit choice of cloud services, as not all are available everywhere
- Add complexity to failover/backup processes
- Potentially increase costs (e.g. if required region is more expensive)
- Slow down access for geographically dispersed users
So organizations need to balance control, compliance and performance. The right mix depends on the sensitivity of the data and the specific regulations in play.
How to make it happen?
- Catalog all the places you store data - datacenters, cloud regions, backup sites, etc.
- Label each location with metadata like country, owner, supported standards
- Map applications/databases to the locations where that data resides
- Put controls in place to approve any new storage locations
- Setup ongoing processes to review and update the data location register
- Integrate checks into deployment pipelines to enforce storage location rules
- Monitor and alert on any unauthorized cross-region replication
- Regularly test failover to backup locations to ensure data is accessible
What are some gotchas?
- Many cloud services replicate data behind the scenes for durability. For example, EBS snapshots are stored in S3 which may be a different region.
- Regulations often require both primary and backup data to stay in approved regions. Check the fine print.
- Database replication and sharding can lead to data being stored in multiple places. The location register needs to track it all.
- Doing this manually doesn't scale. Automation is key - look for infrastructure-as-code tools that let you define locations declaratively.
What are the alternatives?
If the goal is keeping data within specific political borders, an alternative to tracking locations everywhere is to use single-region software/services. For example, AWS Outposts or Azure Stack let you run a subset of cloud services fully on-premises. Some SaaS providers also offer to host your instance in a particular country for data residency.
Strict data location controls can also potentially be replaced with robust encryption, anonymization, and key management. This shifts the compliance focus from where data is to who can access it. But regulations vary on whether this is sufficient.
Explore Further
- ENISA's Securing Public Cloud Deployments covers data location as part of compliance.
- CSA's Code of Conduct for GDPR Compliance goes deep on data residency challenges.
- NIST's Definition of Cloud Deployment Models explains the shared responsibility for compliance.
This control aligns closely with CIS Control 13 (Data Protection) and supports Control 3 (Data Governance). Review those benchmarks for additional best practices.
