Security assessments and testing
Customers are responsible for assessing the security of their own workloads on Thalassa Cloud — applications, virtual machines, Kubernetes clusters, and network configurations within their organisation. Under the shared responsibility model, these tests fall on your side of the boundary.
Thalassa Cloud welcomes structured security testing and is available to assist with planning, coordination, and disaster recovery exercises. This page describes what is permitted, what requires advance notification, and what is not allowed.
Before you begin
Advance notification is required before any security test that could be detected as suspicious activity — including penetration tests, vulnerability scans, authentication brute-force attempts, or failover exercises that generate unusual traffic patterns.
Contact Thalassa Cloud support with the following information before your test window opens:
| Required information | Detail |
|---|---|
| Organisation | Your Thalassa Cloud organisation name and account contact |
| Test contact | Name, email, and phone number of the person responsible during the test window — reachable if our security team needs to reach you |
| Scope | Resources under test: VPC IDs, IP ranges, hostnames, Kubernetes cluster names, API endpoints, and services involved |
| Source IPs | Public IP addresses or CIDR ranges from which testing traffic will originate — including any VPN exit nodes or third-party pentest provider infrastructure |
| Test window | Planned start and end date/time (with timezone) |
| Test type | Penetration test, vulnerability scan, red team exercise, disaster recovery test, or other — with a brief description of techniques planned |
| Third parties | Name of external pentest firm if applicable |
Providing complete source IPs and a reachable contact allows our operations and security teams to distinguish your authorised test from genuine threats. Tests conducted without notification may trigger incident response and could be blocked.
Permitted scope
Security tests may target resources within your organisation’s tenancy that you own and operate:
| In scope | Examples |
|---|---|
| Your VPCs and subnets | Network scanning, firewall rule validation, routing tests |
| Your compute instances | VM vulnerability assessment, OS-level pentesting, configuration review |
| Your Kubernetes clusters | Application pentesting, API server access tests (from authorised sources), workload exploitation attempts within your cluster |
| Your managed services | Database connection security, DNS record validation, application-layer testing against your endpoints |
| Your load balancers and public endpoints | Web application pentesting, TLS configuration review, authentication testing against your applications |
Tests must stay within resources allocated to your organisation. You may not probe, scan, or attempt to access resources belonging to other customers.
Prohibited activities
The following activities are not permitted under any circumstances, even with advance notification:
| Prohibited | Reason |
|---|---|
| Denial-of-service (DoS) and distributed denial-of-service (DDoS) tests | High-volume traffic attacks against any target — including your own resources — can affect shared platform infrastructure and other customers |
| Traffic floods and resource exhaustion | Tests designed to generate excessive load, saturate bandwidth, or exhaust compute, storage, or API capacity |
| Quota and rate limit bypass attempts | Probing or exploiting Thalassa Cloud platform limits, API rate limits, or tenant quotas |
| Testing other customers’ resources | Any access attempt against organisations, VPCs, or services you do not own |
| Platform and control plane testing | Probing Thalassa Cloud APIs, management interfaces, hypervisors, storage backends, or internal infrastructure outside your tenancy |
| Physical and social engineering | Data center access attempts, social engineering of Thalassa Cloud staff, or phishing of platform operators |
| Malware distribution | Deploying malware or command-and-control infrastructure that could affect the broader platform |
If your assessment plan includes activities that might resemble the above — for example, load testing at scale — contact support before scheduling to discuss alternatives. We can often accommodate legitimate performance or resilience testing through coordinated windows and controlled environments.
Thalassa Cloud assistance
We are available to help you run security and resilience exercises successfully:
| Service | How we can help |
|---|---|
| Security test coordination | Review your test plan, confirm scope boundaries, and ensure source IPs are recognised during the test window |
| Disaster recovery testing | Plan failover exercises across availability zones, validate backup and restore procedures, and coordinate timing to minimise risk |
| Business continuity exercises | Support structured tests of your recovery time objectives (RTO) and recovery point objectives (RPO) on the platform |
| Post-test review | Discuss findings that relate to platform behaviour or shared infrastructure, and clarify shared responsibility boundaries |
Contact Thalassa Cloud support to schedule a planning call. For complex exercises — multi-zone failover, large-scale restore tests, or assessments spanning multiple services — early engagement (two weeks or more before the test date) is recommended.
Self-service audit and monitoring
You do not need advance approval to review your own operational and audit data:
- Audit logs — Review and export organisation audit logs for compliance review and access analysis. See Audit logs and Exporting audit logs.
- IAM reviews — Audit user, team, and service account permissions via the console or API. See IAM and RBAC roles.
- Configuration review — Inspect security groups, firewall rules, KMS key policies, and Secrets Manager access policies through standard platform tooling.
These activities are part of normal operations and do not require notification.
Reporting security issues
If you discover a vulnerability in Thalassa Cloud platform infrastructure — not in your own configuration — report it to Thalassa Cloud support with sufficient detail for our security team to investigate. Do not publicly disclose platform vulnerabilities before we have had reasonable time to remediate.