Who owns compliance in a managed database service?
TL;DR: the cloud provider secures the infrastructure, the managed provider operates the database inside it, and you remain accountable for the data. Under GDPR you stay the controller no matter who runs the server. Under HIPAA your provider is a business associate and needs a signed BAA, as does every subcontractor it uses. Under SOC 2 your provider's report covers your provider's controls, not your environment. Get the split written into the contract as a named RACI with evidence obligations, or you have bought operations, not compliance.
Outsourcing a database moves the work. It does not move the obligation. Every managed database contract splits compliance duties across three parties, and most contracts describe that split badly or not at all. The gap gets discovered during an audit, a breach notification, or a customer security questionnaire, which are the three most expensive moments to discover anything.
This article sets out who actually owns what across SOC 2, HIPAA, and GDPR when a third party operates your database, what changes when the database runs in your cloud account rather than the provider's, and the specific contract language that closes the gap before an auditor finds it.
The three-layer split nobody writes down
There are three parties in a managed database arrangement and each one holds a different slice.
The cloud provider secures the physical facilities, the hardware, the hypervisor, and the managed service layer it sells you. AWS publishes this as the shared responsibility model and states plainly that customer responsibilities "vary depending on the services" chosen and how those services are integrated into the customer environment (AWS risk and compliance whitepaper). Azure and Google Cloud publish equivalent models. The important part is the last clause: the line moves depending on what you buy.
The managed database provider operates the engine. Patching, configuration, encryption settings, access control implementation, backup execution, restore testing, monitoring, and incident response. This is where most of the day-to-day control evidence is generated, and where most contracts are vaguest.
You remain accountable to the regulator, the auditor, and your own customers. You define the policy, you classify the data, you decide retention, you answer the questionnaire, and you carry the fine.
The failure pattern is not that one of these three parties refuses a duty. It is that all three assume one of the others has it. Encryption key rotation is the classic example. The cloud provider offers the key management service, the managed provider configures it, and nobody owns rotating the key on a schedule, because it was never written down as anyone's job.
GDPR: you stay the controller
If you decide why and how personal data is processed, you are the controller, and appointing a processor does not transfer that. GDPR Article 28 requires that processing by a processor be governed by a written contract that sets out the subject matter, duration, nature and purpose of processing, the types of personal data, and the categories of data subjects (Art. 28 GDPR).
Two clauses in Article 28 matter more than the rest for a managed database deal.
First, the processor may not engage another processor without your written authorization, and where it does, it must impose the same data protection obligations on that sub-processor by contract (ICO guidance on processor contracts). A managed database provider that uses an offshore night shift, a third-party monitoring platform, or a backup vault in another region has sub-processors. Ask for the list. If the provider cannot produce a current sub-processor register on request, the Article 28 chain is already broken.
Second, the processor must assist you with your own obligations: security, breach notification, data subject requests, and impact assessments. "Assist" in a real contract means a named response time and a named contact, not goodwill.
Data residency belongs in this section too. Where the database sits, where the backups sit, and where the engineers who can read the data sit are three separate questions, and only the first one usually appears in a sales conversation.
HIPAA: the BAA, and the BAA behind the BAA
If protected health information touches the database, your managed provider is a business associate and a written business associate agreement is required. HHS sets out what that contract must do: establish permitted uses and disclosures, require appropriate safeguards including the HIPAA Security Rule requirements for electronic PHI, require the business associate to report any use or disclosure not provided for by the contract including breaches of unsecured PHI, and require the business associate to make PHI available as needed to satisfy your obligations (HHS, business associate contracts).
The clause buyers miss is the subcontractor chain. A business associate that passes PHI to a subcontractor must have a BAA with that subcontractor, and the obligations flow down. HHS also requires that where a party knows of a pattern of activity constituting a material breach of the agreement, it must take reasonable steps to cure it and, failing that, terminate the agreement if feasible (HHS). That is a termination right you are entitled to and that most managed service contracts quietly omit.
Practical test: ask your provider for its signed BAA template and its subcontractor list in the same email. A provider that has one but not the other has a gap in the chain.
SOC 2: their report is not your report
A SOC 2 Type II report tells you that an auditor tested a defined set of controls at a defined service organization over a defined period. It says nothing about your environment.
Every SOC 2 report also carries complementary user entity controls: the things the report explicitly assumes you are doing at your end for the provider's controls to be effective. Access reviews, offboarding, key custody, network restrictions. Auditors read that section. Buyers usually do not.
Three questions turn a SOC 2 conversation into evidence:
- What is in scope? A report scoped to the provider's corporate IT does not cover the team operating your database cluster.
- What is the period? A Type II covering a window that ended eleven months ago tells you about a team that may no longer exist.
- What are the complementary user entity controls, and who at our end owns each one? If nobody has read that list, your provider's clean report does not help you.
A provider that hands over a report and treats the conversation as finished is selling reassurance. A provider that walks you through the exceptions and the user entity controls is selling operations.
What changes when the database runs in your account
The deployment model moves the compliance line more than any contract clause.
In a SaaS control plane, your data lives in the provider's account, under the provider's tenancy, with the provider's key management, logging, and network policy. Your audit evidence is whatever the provider chooses to expose. Your data residency is whatever their regions allow. Your exit is whatever their export tooling supports.
In an in-your-account deployment, the database runs inside your own cloud account. Your tenancy, your keys, your CloudTrail or equivalent audit log, your network boundary, your retention policy. The provider operates within it under your access policy. That difference has three concrete compliance consequences:
- Evidence. Audit logs are generated in an account your auditor can already see, so evidence collection does not depend on a provider ticket.
- Residency. You choose the region because it is your account.
- Revocation. Access can be withdrawn by you, immediately, without provider cooperation. That is a control an auditor can test.
Our managed database services page describes this model directly: deployments sit within customer accounts, so ownership and visibility stay with the customer while the provider works inside the customer's established policies.
There are 25 questions worth asking before signature in 25 questions to ask before signing a managed database contract, and the availability half of the same problem is covered in what a 99.99% SLA actually commits your provider to.
How Maxima Consulting handles the split
Maxima Consulting is a managed cloud operator and engineering partner that runs SRE, and Day-2 operations for software vendors and enterprises.
For compliance specifically, the operating model is deliberately boring. Deployments run inside the client's own cloud accounts, so the client keeps the tenancy, the keys, the audit trail, and the ability to revoke access. Security policies and access management rules are aligned to the client's internal standards and to the applicable regulatory requirements, with the client's policy set as the input rather than a provider template imposed on top. Operations run 24/7/365 follow-the-sun from Kraków and Pune, which matters here because breach notification clocks do not pause overnight. Maxima is CMMI Maturity Level 3 appraised.
If you cannot currently produce a control-by-control owner list for your database estate, schedule a discovery session. The first output of a review is that list, whether or not you end up changing providers.
FAQ
Who is responsible for compliance in a managed database service?
All three parties hold part of it. The cloud provider secures the infrastructure and its own managed service layer. The managed provider operates the database, applies patches, configures encryption and access control, and runs backups. You remain accountable to the regulator and your customers for policy, data classification, retention, and reporting. The split has to be written down control by control, because unassigned controls are the ones that fail an audit.
Does using a managed database provider make us HIPAA compliant?
No. It makes your provider a business associate, which requires a signed business associate agreement covering permitted uses, safeguards under the HIPAA Security Rule, and breach reporting. Compliance remains yours. Check that your provider also holds business associate agreements with any subcontractor that can reach protected health information, because the obligations flow down the chain and gaps there are still your exposure.
Are we still the data controller under GDPR if a provider runs our database?
Yes. If you determine why and how personal data is processed, you are the controller and your provider is a processor. GDPR Article 28 requires a written contract defining the processing, and the processor cannot engage a sub-processor without your written authorization. Ask for a current sub-processor register, the assistance obligations for breach notification and data subject requests, and where backups physically reside.
Is our provider's SOC 2 report enough for our audit?
It covers your provider's controls at your provider's scope for a defined period. It does not cover your environment. Every report also lists complementary user entity controls, meaning the things it assumes you are doing for those controls to work. Check the scope, check the period end date, and assign an owner at your end to each complementary control before treating the report as evidence.
Does running the database in our own cloud account change our compliance position?
It changes three practical things. Audit evidence is generated in an account your auditor can already access, so collection does not depend on a provider ticket. Data residency is your choice because the region is yours. And access revocation is a control you hold directly and an auditor can test. The provider still operates the database; it operates inside your boundary rather than its own.
