This checklist details ten criteria to check before signing with a backend as a service (BaaS), with the precise question to ask each supplier for each.
The most often forgotten criterion is the nationality of the supplier, distinct from the location of its servers. An American parent company remains subject to the CLOUD Act even if its data runs on servers in France or Germany. Our comprehensive guide to GDPR and EU sovereignty details this legal distinction in depth; This checklist focuses on the operational points to check during a supplier assessment.
The essentials
- A checked “EU region” box only covers part of the risk: the nationality of the company hosting your data matters just as much in the face of the CLOUD Act.
- The DPA (article 28 GDPR) is mandatory as soon as a supplier processes data on your behalf, regardless of the size of your company.
- Isolation between clients is not an implementation detail: a shared table with tenant_id does not offer the same guarantees as a dedicated database per project.
- A “roadmap” certification is not a certification obtained: require the signed audit report, not a marketing promise.
- Access, erasure and portability rights must be exercisable in self-service: a supplier who responds with custom SQL script slows down your own compliance.
- Self-hosting eliminates the contractor but shifts the entire operational burden of security and breach notification to your team.
Data location and nationality of the provider
Two separate facts determine your legal exposure: where the data is stored, and what is the legal nationality of the company hosting it. The GDPR governs the first point. The American CLOUD Act governs the second.
This text authorizes the American federal authorities to request data from any company incorporated under American law, including its subsidiaries. This applies even when this data is hosted on servers physically located in Europe. A “hosted in the EU” badge on a marketing site says nothing about the nationality of the parent company.
Aurabase is a French company, Aurabase SAS, based in Paris. Its production infrastructure runs on Hetzner data centers in Nuremberg, Falkenstein (Germany) and Helsinki (Finland): EU sovereignty. Two distinct facts, legal headquarters and location of servers, not to be confused in the same diligence.
The question to ask any supplier: is your parent company registered outside the EU, even if your servers are in Europe?
The DPA: what Article 28 of the GDPR requires
The GDPR requires a written contract between you, the data controller, and your supplier, subcontractor: this is article 28. Without this document, you are not in compliance, regardless of the technical seriousness of the supplier elsewhere.
A valid DPA specifies the purpose and duration of the processing, the categories of data and data subjects, and the list of subcontractors. It also details the security measures applied and the assistance obligations in the event of a user request. Finally, it determines the fate of the data at the end of the contract: deletion or restitution.
Aurabase publishes a signable DPA directly from the Studio, built on the standard contractual clauses adopted by the European Commission (decision 2021/914). Our article dedicated to the DPA of a backend as a service details clause by clause what to check before signing.
The list of subcontractors must be public and notified
Article 28 GDPR also requires your subcontractor to list its own subcontractors: host, payment gateway, transactional email service. Any change must be notified to you, with a right to object.
Demand this list in writing and check that each critical subcontractor, in particular the host, is also based in the EU. Otherwise, the subcontracting chain recreates the CLOUD Act exposure you sought to avoid by changing your primary supplier.
The isolation between your data and that of other customers of the same supplier determines the extent of a leak in the event of a bug. Three architectures exist, with very different guarantees.
The most common model, a large shared table with a tenant_idcolumn, is also the most fragile. A poorly written RLS policy, or a query without a filter clause, can expose several clients at once. A per-project basis, with its own connection role, eliminates this class of bug: the boundary is set at the connection level, not an WHERE clause that a developer could forget.
On this point, each Aurabase project receives its own Postgres database, with its own connection role scoped by search_path injected from the JWT at the gateway level. Between two organizations, isolation becomes physical: dedicated Postgres cluster, separate Kubernetes namespace. Full details on the Securitypage.
Technical security: encryption, audits, bug bounty
The GDPR imposes “appropriate technical and organizational measures” (article 32), without listing a precise standard. In practice, three concrete elements to verify: encryption in transit and at rest, the existence of an independent audit program, and a documented vulnerability reporting channel.
Aurabase encrypts exchanges in TLS 1.3 and data at rest in AES-256, with a BYOK option (keys managed by you via AWS KMS or HashiCorp Vault) on the Enterprise plan. The public bug bounty program, hosted on huntr.dev/aurabase, pays from €200 to €10,000 depending on the severity of the flaw found. The coordinated disclosure policy lasts 90 days. A supplier without a documented reporting channel, by definition, has no independent audits underway.
Rights of data subjects: self-service or manual script?
Articles 15, 17 and 20 of the GDPR guarantee your end users a right of access, erasure and portability of their data. The question to ask your BaaS: can these rights be exercised in self-service, or do they require a tailor-made SQL script for each request?
It is you, the data controller, who remains legally obliged to respond within 30 days, even if the underlying infrastructure is opaque. A provider that requires a manual script for every request slows down your own response time. At Aurabase, export and deletion are accessible from Studio → Settings → Privacy, or via privacy@aurabase.cloud for more complex cases.
Violation notification: legal deadline versus contractual commitment
The GDPR requires the data controller, you, to notify a violation to its supervisory authority within 72 hours of becoming aware of it (article 33). This period only starts when you are informed by your supplier.
The supplier's contractual commitment to notify is therefore as important as the legal deadline itself. Ask for the maximum contractual deadline that it undertakes to respect to notify you of an incident, and what this notification must include: nature of the violation, categories and approximate volume of data concerned. This figure must be written in black and white in the DPA, not just mentioned orally before sales.
Certifications: obtained, or roadmap?
A certification announced on a marketing site is not the same as a certification obtained. Many BaaS providers communicate a “compliance roadmap” (SOC 2, ISO 27001) without having initiated the corresponding third-party audit.
On this specific point, transparency matters more than the announcement itself. Aurabase's Security page explicitly states that no third-party certification is committed to date, and publishes its roadmap on a dedicated Trust Center rather than displaying an unearned badge. Systematically require the signed audit report, not just the name of the standard in question, before considering a certification for granted from any supplier.
Self-hosting: Full compliance has an operational cost
Self-hosting your own Postgres eliminates the question of subcontractor, but does not automatically resolve GDPR compliance. Responsibility for security, encrypted backups, patching, and breach response remains entirely with you.
For a team without an SRE dedicated to Postgres security, an EU Sovereign BaaS with signed DPA shifts some of this operational burden to an audited third party, without sacrificing jurisdiction. Our comparison self-hosting vs EU sovereign BaaS quantifies this compromise for a small team.
The ten criteria and the question to ask
A condensed version, useful in supplier evaluation meetings or to build your own audit grid.
| Criterion | Question to ask the supplier |
|---|---|
| Location AND nationality | Where are the servers, and where is the parent company of the provider registered? |
| DPA (article 28 GDPR) | Is the subcontracting contract signed, or only mentioned in pre-sales? |
| List of subcontractors | Is it public, up to date, with notice in case of change? |
| Data isolation | Shared table with a tenant_id column, or dedicated base per client? |
| Encryption | TLS in transit, AES at rest, BYOK option available? |
| Independent audit | Active bug bounty or dated external pentest, with documented reporting channel? |
| GDPR rights (access, erasure, portability) | Can be exercised in self-service, or only via manual script on request? |
| Breach Notification | What maximum contractual period is written in black and white in the DPA? |
| Certifications | Obtained with a signed audit report, or only as a roadmap? |
| Responsible for compliance | Audited EU sovereign BaaS, or self-hosting with the operational burden assumed internally? |
FAQ: GDPR compliance and choosing a BaaS
Next step
None of these ten criteria is sufficient in isolation to guarantee GDPR compliance for a backend as a service. It is their combination, verified point by point rather than deduced from a marketing badge, which builds a serious supplier evaluation.
For the complete legal nuance between hosting region and supplier nationality, head to our GDPR and EU sovereignty guide. For details of the technical security measures mentioned in criteria 4 and 5, the Aurabase Security page remains the up-to-date reference.