The article
Your cloud provider's compliance page lists HIPAA, PCI DSS, SOC 2 and GDPR, and it is tempting to send that page to your auditor and call it done. Those reports cover the provider's data centers, hardware and services. The accounts, roles, keys, logs and backups you configured are yours to prove.
My team of 70+ specialists builds and runs software for clients in healthcare and fintech, and most of what we deliver as cloud compliance solutions is that second half: setting up AWS, Azure or Google Cloud so regulated data stays inside its rules, and keeping the evidence that it still does.
Cloud compliance solutions: the short version
| Question | Answer |
|---|---|
| Who answers for what | The provider for its share, you for your configuration and use: the shared responsibility model |
| What we configure | Accounts and roles, encryption and keys, logs, backups, settings checked against a benchmark, and regulated data kept to the services the provider's terms cover |
| Which rules | HIPAA, PCI DSS, SOC 2 or GDPR, whichever apply to your data |
| Who signs off | A CPA firm for SOC 2; for PCI DSS, a QSA or your own questionnaire; legal questions go to your counsel |
| Price | Estimated before work starts; the first call and the rough estimate are free |
The provider's share and yours
This is the split I would draw on a first call with a team that keeps regulated data in the cloud. Forward it to whoever owns your cloud account.
| Area | The provider covers | You cover, and we set up | What an auditor asks to see |
|---|---|---|---|
| Data centers and hardware | Yes, in its own reports | Nothing to build | The provider's reports |
| Contract terms | A BAA for the services it lists | You sign the right terms; we keep regulated data in covered services only | The signed agreements and the list of services in use |
| Accounts and access | The identity tools | Separate accounts, roles, multi-factor sign-in, access reviews | Role lists and review records |
| Encryption | Encryption services and managed keys | Encryption turned on everywhere, and rules for who may use the keys | Settings reports and key policies |
| Logs | The logging services | What gets logged, how long it is kept, who may delete it | Retention settings and log samples |
| Backups | The backup services | Retention, a copy in a separate account, restore tests | Restore test records |
| Drift | Benchmark tools | Checks that run all the time, and alerts | Reports over time |
Of four company pages Google showed me for "cloud compliance solutions" in October 2026, one mentions the shared responsibility model; none mentions a business associate agreement, and none says a backup should be restored to prove it works. Four pages are a small sample; ask your own provider and your own team the same questions.
Cloud security and compliance solutions start with identity
Identity is where we start, because every other control assumes you know who can do what:
- regulated data in its own accounts or projects, apart from development and testing;
- roles instead of shared logins, multi-factor sign-in for every person, and no daily work under the root account;
- access reviewed on a schedule, with a record of every review;
- secrets in a secret store, never in the code.
We are a cloud compliance company that also writes the software. When a gap sits in the application, such as health data written into a log, our developers fix it there. More on that side in cloud security.
HIPAA compliance for cloud services
Health data in the cloud needs a business associate agreement (BAA) with the provider, services the BAA covers, and safeguards you configure yourself. The provider covers its share; we set up yours.
Each of the three big providers offers a BAA for a listed set of services, and AWS, for one, tells customers to keep health data only in the services its agreement lists. A service outside the list is outside the agreement, so the list gets checked before a new service goes live. HHS guidance adds two points: a provider that stores encrypted health data without the key still needs a BAA, and HIPAA itself does not forbid storage outside the United States with a BAA in place, though the risks vary by location.
On RxPhoto, a platform built for HIPAA work that stores 80m+ before-and-after photos for clinics (per rxphoto.com), we worked on the backend, the web front end and the API behind the mobile app. Photos go straight into the patient's record on a secure cloud portal, and an audit log lets administrators follow every user action. The rest of the HIPAA work, from the risk analysis to the policies, is on HIPAA compliance.
GDPR compliance in cloud services
GDPR does not require EU-only hosting. It requires that a transfer of personal data outside the EU meets the conditions of its Chapter V, such as an adequacy decision or standard contractual clauses, and that your cloud provider works as a processor under a contract of the kind article 28 spells out. Which transfer basis fits is a question for your counsel; keeping the data and its copies in the regions that basis allows is ours.
Article 32 is the engineering part: encryption, the ability to restore personal data in good time after an incident, and regular testing of the measures. The rest of the regulation is on GDPR compliance.
Backups that hold up in an audit
If you are comparing the best compliance-focused cloud backup services, compare three settings rather than brands:
- retention as long as your rules require, and no longer;
- a copy in a separate account that a compromised administrator cannot delete;
- a restore test on a schedule, with a record of how long it took.
A backup nobody has restored is a hope, not evidence. We set this up as part of cloud backup, and the restore test is how we check the copies.
Advice before you build
The cheapest moment for cloud and regulatory compliance consulting is before the first resource is created: which services are allowed for your data, which region it must stay in, and what your auditor will look for. Fixing a wrong region later means a migration; settling it at this stage takes a few conversations. Rules differ by data:
- Defense. DFARS 252.204-7012 requires a cloud service that holds covered defense information to meet FedRAMP Moderate or equivalent requirements; CMMC has the rest.
- Finance. For banks, lenders and fintech, financial services cloud compliance depends on your license; ask your compliance advisor which record-keeping and vendor-oversight duties apply to it.
- Data that may not leave its country. For AI Call Center in the UAE, every call is processed inside the country, on local servers with locally hosted models.
Our cloud and regulatory compliance services then keep it that way: settings checked against a benchmark all the time, drift flagged and evidence collected as the work happens. The software side of that is compliance automation.
What the price of our cloud compliance services depends on
- how many accounts, subscriptions or projects you run, and how many environments;
- which rules apply: one framework or several;
- whether the setup is new or already running; a running one starts with a check against a benchmark;
- whether you want us to run it afterwards as managed cloud services.
The first call and the rough estimate are free. Our clients rate us 5.0 on Clutch from 26 verified reviews, as of September 2026, and not one review is negative.
Next to cloud compliance
Cloud compliance is one of our regulatory compliance services, next to PCI DSS for card data and cloud and cybersecurity consulting for teams planning what to build next.
Tell us what data is in your cloud and which rules apply to it. We answer new requests within 30 minutes on weekdays, 9 am to 6 pm Miami time, then reply with the gaps we would check first and a rough estimate, free.
