Here’s the short version: cloud infrastructure for data compliance and security is designed by mapping where data and regulators actually live, pinning storage to chosen regions, segmenting access, encrypting in transit and at rest, and proving it with vendor reports plus your own settings, including backups that do not wander. Spinning up a server and hoping the bits stay put is not a design.
This is not a replacement for our CCPA or SOC 2 guides. Those pages are the rules. This page is the architecture: how a small or mid-size firm, including shops we see from Canoga Park, should build the cloud so those rules have somewhere to live.
Designing cloud infrastructure with a compliance checklist
Once product specs are hashed out, infrastructure is not “pick a cloud and ship.” You are part security guard, part digital customs officer. Data that crosses a border is not free. Small businesses need this from day one, not after the first enterprise customer sends a questionnaire.
The shared-responsibility split is the first honesty test. AWS says it plainly: they secure the cloud, you secure what you put in it (AWS data privacy FAQs). Microsoft says you are wholly responsible for your own legal compliance, and their docs are not legal advice (Azure compliance offerings). If you mis-set a region or a public storage bucket, the vendor’s ISO certificate will not save you.
Data residency mapping (what the law actually says)
First, identify where your customers live, and where their regulators live. Then separate three things people mash together:
- Lawful processing (you have a reason to hold the data).
- International transfers (the data leaves a legal territory).
- Contractual residency (the customer or a sector rule demands a specific country or region).
GDPR is about transfers, not a Frankfurt pin
GDPR does not say “EU personal data must sit on a server in Frankfurt.” The European Commission describes a toolkit for transfers outside the EEA: adequacy decisions, standard contractual clauses, binding corporate rules, and limited derogations. If no valid transfer tool exists, the practical result is that the data stays. That is residency pressure, not a pin-the-server-on-the-map statute.
CCPA is consumer rights, not a California data center
CCPA is California consumer rights, not a Sacramento data center mandate. The California Attorney General’s CCPA page is about notice, access, deletion, and opt-out. You still map California residents because you cannot fulfill those rights if you cannot find the records, and you still restrict who can see them.
Cloud region knobs
The client’s instinct is right as an engineering practice: map the data, then pick regions on AWS, Azure, or Google Cloud that match the stricter of law and contract. Just do not tell a board “GDPR requires EU disks” if your counsel has signed SCCs and an adequacy path. Write both the legal mechanism and the hosting choice in the same one-pager.
Logs, identity, and support tickets count as data. A help-desk tool hosted in another country that stores the body of a customer email is a transfer even if the “main” database is in-region. Inventory the SaaS around the workload, not only the VM.
AWS: you choose the Region(s). They state they will not move or replicate customer content outside those Regions without agreement, except as needed to provide the service you started or to comply with law. Azure: most services let you specify where customer data is located, and Microsoft says it will not replicate that customer data outside the chosen geography (for example, the United States). Google Cloud documents regions, zones, and geographic management of data. Multi-regional products are a conscious trade: durability versus location. Read the product before you tick “multi-region” because it sounded safe.
Segmentation and access controls
Use VPCs (or VNets) and strict network segmentation so data from different regions, and different sensitivity, stays in its lane. That is the same idea as staff versus student on a firewall, applied to cloud.
Practical pattern for a small firm:
- One account or subscription per environment (prod vs test), not one soup
- Separate storage for HR/payroll versus marketing
- Private endpoints for databases; no public IPs “for a week”
- IAM roles with a real need, MFA on every human admin
- No personal Microsoft or Google account as the break-glass Global Admin
Zero trust at this size is not a platform SKU. It is “this identity can see this store, from this network, for this job.” CIS access control still applies in the cloud. A region pin with a world-readable bucket is not compliance.
Encryption everywhere
Turn on encryption at rest and in transit. Leading cloud providers encrypt stored objects and TLS for traffic into the data center. That is the “safe on the truck” metaphor, and it is accurate as a default. It is not the whole job.
You still choose:
- TLS 1.2+ on every public endpoint, including admin
- Server-side encryption on buckets and disks (defaults are good; confirm they are on)
- Who holds the keys: vendor-managed, customer-managed in the cloud KMS, or keys you hold outside the cloud
- Whether backups inherit the same key and region
NIST FIPS 140-3 is the cryptographic-module standard federal systems are measured against. You do not need to be a federal agency to prefer modules that were validated. You do need to know if a “we encrypt” slide means TLS to a public bucket, or a locked store with a managed key and audit logs.
Encryption does not fix a bad IAM role. A stolen admin session decrypts just fine.
Compliance monitoring and proof
Regularly audit the setup. Cloud vendors offer automated checks and, more usefully, independent reports: SOC 2 Type II, ISO 27001, ISO 27018 for public-cloud PII. AWS publishes SOC reports through Artifact. Microsoft puts certificates and SOC reports on the Service Trust Portal. Collect those for the services you actually use.
Two honesty rules:
- The hyperscaler’s SOC 2 is their report. It is not Secure Techies’ report and it is not yours. It tells a customer how AWS or Microsoft run the building. You still have to show how you configured the rooms.
- Do not flash a FedRAMP or CMMC badge you do not hold. We prepare and assess. Accredited assessors issue attestations. Same rule as our compliance service.
What you should keep in a folder a customer can request:
- Region map (which data, which Region, why)
- Screenshot of encryption and public-access blocks
- Vendor SOC/ISO for in-scope services, dated
- Access review: who can still reach that store
- Backup locations and retention
Disaster recovery and retention that respect the map
Make region-specific backup plans. Some privacy programs and some contracts require that data never leave its home jurisdiction, not even in a backup. A DR pair in another country is a transfer. So is a SaaS backup tenant in a different geography. So is a technician downloading a database “just for the restore test” onto a laptop in another state.
Design:
- Snapshots in the same Region, or a second Region you have already approved in writing
- Retention that matches legal hold and deletion rights (CCPA deletion is awkward if your backup lasts seven years with no process)
- A restore test that does not copy production to a personal OneDrive
- An exception log when a vendor has no in-region option
Our backup and disaster recovery and Microsoft 365 backup posts are the operational half. This post is the geography half. Both have to be true at once.
A build order that does not pretend this is a one-time project
Do not treat compliance as an afterthought or a weekend. Build it into the infrastructure, document it, and assume someone will ask for proof.
Suggested order for a Southern California firm that suddenly has EU or multi-state customers:
- Inventory: what personal data you hold, whose it is, which systems.
- Legal and contract: counsel names the transfer tool and any residency promise. We are not your lawyer.
- Region choice on the actual cloud, including logs and backups.
- Segmentation and least privilege.
- Encryption on, public access off, keys named.
- Vendor reports plus your screenshots.
- Quarterly review: new SaaS tools are how maps rot.
Cloud services explained is the buying primer. Vendor risk is how you treat the next SaaS that wants a copy. Infrastructure is who keeps the settings from drifting.
What this looks like when it is done well
You can answer, without improvising:
- Where this customer’s data lives, in which cloud Region
- Who can open it
- Whether a backup copy exists somewhere else, on purpose
- Which vendor report covers the service underneath
- How a deletion or access request would actually run
You cannot honestly answer “we are GDPR certified” because that is not a thing you hang on the wall. You can answer “EU records are in eu-west-1, SCCs are signed, backups stay in-region, here is the screenshot.” That is the adult version of the client’s checklist.
If you are standing up a new tenant or moving a workload and you want that map written before the bits fly, contact Secure Techies. We will tell you what the cloud settings can do. Counsel tells you what the law requires.
Frequently Asked Questions
