Trust: assurance, attestations and the shared responsibility line
The Trust domain is about assurance: what Exoscale can evidence about its own operations, and how you turn that evidence into answers for a customer, auditor or procurement team. It is distinct from compliance, which is about which regimes you meet - Trust is about whether the claims are verifiable and how the provider behaves when things go wrong.
What trust is built from
Trust rests on published attestations (ISO/IEC 27001 and its cloud extensions ISO/IEC 27017 and 27018, plus privacy-focused ISO/IEC 27701 where in scope), independent audit reports, a public status page, a vulnerability disclosure channel, and a data processing agreement with a sub-processor list. It also rests on structural facts: the provider is European, its data centres sit in identified countries, and its ownership and jurisdiction are knowable - which matters when a customer's legal team asks who could be compelled to hand over data.
Shared responsibility
Exoscale secures facilities, hypervisor, network fabric and managed-service engines. You secure identity and access, security group rules, guest OS patching, application code, data classification and backup testing. Most "cloud breach" postmortems are customer-side misconfiguration; the exam wants each control placed on the correct side of the line.
Worked example
A prospect asks: "Where does our data live, who can access it, and what happens if you are acquired?" Reasoning: answer location with the zone and country of each resource - volumes, buckets and DBaaS are zone-scoped, so the answer is concrete; answer access with the sub-processor list and DPA; answer acquisition with change-of-control and data-return clauses. Back all three with current evidence: certificate scope, audit report date, and your own access logs.
Traps
Treating a certificate as covering every service in every zone; answering "we are ISO 27001" when the question was about data location; confusing the platform's controls with your own; and quoting a certification whose current report you cannot produce.
Compliance and Data Residency: zones, GDPR/FADP roles and evidence
This domain tests the legal and architectural side of "where is the data": choosing zones that satisfy residency, evidencing compliance, and avoiding designs that quietly move data across borders.
Residency is a property of resources
Exoscale zones are country-specific, and the resources that hold data - block volumes and snapshots, Object Storage buckets, DBaaS services and their backups, custom templates - are created in a zone. Residency is therefore decided at creation time by the zone you pick, not by a setting you toggle later. Swiss data goes to CH-GVA-2 or CH-DK-2; EU data to DE-FRA-1, DE-MUC-1, AT-VIE-1, BG-SOF-1 and comparable zones. Control-plane metadata (accounts, billing, IAM) is a separate question from customer data and should be described accurately rather than hand-waved.
The compliance toolkit
Under GDPR you are usually the controller and Exoscale the processor: a DPA, documented instructions, breach notification, sub-processor transparency and deletion on exit. Swiss customers add the FADP. Sector rules (financial supervision, health data) may require extra contractual or technical controls. Keep records: data inventory by zone, retention schedule, deletion evidence, and the list of who has access.
Worked example
A Swiss bank requires customer data to stay in Switzerland with no unapproved support access. Reasoning: deploy compute, block volumes, buckets and DBaaS in CH-GVA-2, plus a second copy in CH-DK-2 for resilience - both Swiss. Avoid any cross-zone copy into a non-Swiss zone, and keep log export inside Switzerland, because shipping logs to a third-country SIEM is the classic residency leak. Document the support-access process and sub-processor list in the DPA annex, and record the deletion procedure for offboarding.
Traps
Replicating backups to another region "for safety" and calling it compliant; assuming DNS or a CDN changes data location (metadata versus payload matters); forgetting that logs, traces and snapshots are data too; and treating a certificate as a substitute for a data inventory.