Shared responsibility model
Security and operational assurance on Thalassa Cloud follow the industry-standard shared responsibility model. Thalassa Cloud secures the underlying platform — data centers, control plane, storage fabric, and managed service runtimes. You secure what you deploy, configure, and operate on top of it.
This page is written for security leaders, compliance officers, and engineering teams who need a clear ownership map for risk assessments, audits, and architecture reviews.
How the model works
┌─────────────────────────────────────────────────────────────┐
│ Your responsibility │
│ Applications · OS patching · IAM config · VPC design │
│ Workload backups · Data classification · Access reviews │
├─────────────────────────────────────────────────────────────┤
│ Shared (configuration-dependent) │
│ Encryption key ownership · Network rules · HA design │
├─────────────────────────────────────────────────────────────┤
│ Thalassa Cloud responsibility │
│ Physical security · Control plane · Storage replication │
│ Platform backups · Hypervisor · Managed service patching │
└─────────────────────────────────────────────────────────────┘Thalassa Cloud provides the tools — IAM, encryption, network segmentation, audit logs, and security documentation — for you to meet your compliance and risk requirements. How you configure and operate your resources determines your effective security posture.
Responsibility matrix
| Area | Thalassa Cloud | You (the customer) |
|---|---|---|
| Physical security | Data center access control, environmental systems, and facility certifications | — |
| Platform infrastructure | Hypervisor, control plane, storage backend, networking fabric, and managed service runtimes | — |
| Platform software supply chain | Image signing, vulnerability scanning, and verified deployments of platform components | — |
| Identity and access | Authentication infrastructure, IAM service, OIDC federation endpoints | User and team management, RBAC assignments, service account policies, IAM policies |
| Network security | Underlying network isolation, DDoS mitigation at the edge, platform-internal segmentation | VPC design, security groups, firewall rules, VPC-only cluster access |
| Data protection | Encryption at rest and in transit for platform-managed storage and services; platform service backups | Data classification, KMS key management, Secrets Manager usage, workload backups and retention |
| Workload security | Kubernetes control plane hardening, managed database engine patching | Application code, container images, OS patching on IaaS VMs, pod security standards, network policies |
| Availability | Multi-zone replication, storage automatic healing, platform capacity management | HA architecture, multi-zone workload placement, application-level failover |
| Compliance | Platform ISMS, audit logging infrastructure, data residency in the Netherlands | Compliance of your workloads, access reviews, audit log retention and export |
| Incident response | Platform-level incidents affecting shared infrastructure | Incidents within your workloads, misconfigurations, and compromised credentials in your tenancy |
For the engineering practices behind Thalassa Cloud’s side of this model, see Platform security.
By service type
Responsibilities vary slightly depending on which services you use. The table below summarises the split for common offerings.
Infrastructure (IaaS)
| Component | Thalassa Cloud | You |
|---|---|---|
| Virtual machines | Hypervisor, host hardware, availability zone infrastructure | Guest OS patching, application software, VM configuration, security group attachment |
| Block storage | Storage backend, zonal replication (3×), automatic healing, encryption at rest | Volume attachment, snapshots, delete protection, off-site backup strategy |
| Object storage | Storage backend, zonal replication, encryption at rest | Bucket policies, access control, lifecycle rules, off-site backup strategy |
| Networking | Physical and SDN fabric, load balancer platform, NAT gateway runtime | VPC topology, subnet design, routing, firewall rules, what is exposed publicly |
Kubernetes
| Component | Thalassa Cloud | You |
|---|---|---|
| Control plane | API server, etcd (and encryption), scheduler, controller manager, control plane patching and HA | — |
| Worker nodes | Node provisioning, host OS on managed nodes | Workload deployments, container images, RBAC, network policies, pod security standards |
| Add-ons | Platform-managed components (CNI, CSI, ingress controller runtime) | Application configuration, ingress rules, TLS certificates, secrets references |
Managed services
| Service | Thalassa Cloud | You |
|---|---|---|
| DBaaS | Database engine patching, platform HA, underlying storage replication | Database credentials, connection security, backup schedule, schema and data |
| KMS | Key storage, cryptographic operations, key metadata backup | Key creation, access policies, key lifecycle decisions, which data you encrypt |
| Secrets Manager | Secret storage, envelope encryption, platform availability | Secret paths, IAM and access policies, rotation workflows, what values you store |
| DNS | Authoritative nameserver infrastructure, SOA management | Zone content, record configuration, registrar delegation, DNSSEC enablement |
| Prometheus | Managed Prometheus runtime and storage | Metric sources, alerting rules, remote write ACLs, retention requirements |
Backup and retention
Backup scope is one of the most common areas of misunderstanding in shared responsibility models. The split is straightforward:
| Data type | Who backs it up | Details |
|---|---|---|
| Platform services | Thalassa Cloud | Control plane databases, IAM/IDP state, KMS metadata, and internal operational data — within-region and off-site |
| Customer workload data | You | Block storage, object storage, snapshots, and application data are not backed up by default |
Customer storage includes platform-provided durability controls — zonal replication, automatic healing, delete protection, and graceful deletion periods — but these protect against infrastructure failure and accidental deletion, not against logical data loss or regional disasters.
You are responsible for off-site backups when your compliance or disaster recovery requirements require them. Contact Thalassa Cloud support if you need additional managed backup services.
See Backup and data retention for full details.
What this means for your organisation
When evaluating Thalassa Cloud for a security assessment or compliance framework, consider:
- Platform controls — Thalassa Cloud’s ISMS, certifications, and platform security practices cover the infrastructure layer. Request our security documentation or contact support for audit-specific materials.
- Your controls — Document how your organisation configures IAM, networking, encryption, backups, and workload hardening. These determine your effective posture on the platform.
- Security testing — Penetration tests and disaster recovery exercises on your workloads require advance notification. Contact support with source IPs and test scope before you begin.