Security Policy

Our primary database and backend platform is Supabase, hosted on Amazon Web Services (AWS) in the ap-southeast-2 (Sydney) region. This ensures data residency within Australia and New Zealand’s geographic region. Supabase maintains SOC 2 Type II certification and ISO 27001 compliance.

Some client applications are built on Cloudflare’s developer platform: Cloudflare Pages for static and Progressive Web App hosting, paid Workers and Pages Functions for serverless API compute, and Cloudflare D1 as the application database. Requests are served from Cloudflare’s global edge network, which provides TLS termination, automatic certificate management, and DDoS mitigation at the network layer as standard.

All of these products sit within Cloudflare’s core compliance scope. They are covered by SOC 2 Type II, ISO/IEC 27001:2022, ISO/IEC 27018:2019 (protection of personally identifiable information in public clouds), PCI DSS 4.0 Level 1, and FedRAMP Moderate authorisation.

• Stateless edge compute, Workers and Pages Functions process requests in memory at the edge rather than on a long-lived web server, so there is no local persistence of request data to secure or dispose of.
• Encrypted database storage, Cloudflare D1 is built on SQLite and inherits Cloudflare’s encryption-at-rest architecture. Access is scoped to the specific Worker or Pages Function that owns the binding.
• Data residency, Cloudflare’s network is global by design. Where a client requires data to remain within a jurisdiction we either pin storage to compliant geographic boundaries using Cloudflare’s regional restrictions, or deploy that project’s data store to Supabase in the AWS Sydney region instead. Residency requirements are agreed with each client before a platform is chosen.

Our own website and some client frontends are delivered through Vercel. Vercel operates a global edge network that serves static assets from the location closest to the visitor and runs serverless functions on demand. TLS termination, certificate issuance and renewal, and HTTPS enforcement are handled by the platform on every domain.

• Vercel holds a SOC 2 Type 2 attestation covering security, confidentiality and availability, and is certified to ISO/IEC 27001:2022.
• Application layer only, Vercel serves and runs the application. Persistent data lives in Supabase or Cloudflare D1, not on the hosting platform.
• Isolated builds and stateless functions, each deployment is built in an isolated environment from a specific commit, and serverless functions process each request without sharing local state between invocations.
• Secrets management, API keys and service credentials are held as encrypted environment variables rather than in source code.

Security on managed cloud platforms is a shared responsibility, and we think it is worth being explicit about the split.

• Our platform providers are responsible for physical, network and infrastructure security: data centre access, hardware, the network path, DDoS mitigation, hypervisor and runtime isolation, and encryption at rest.
• Longcloud is responsible for everything at the application layer: the code we write in Workers, Pages Functions and server routes, safe database query construction and access rules, and keeping dependencies patched.

A certification held by a platform provider does not by itself secure an application built on it. The controls described in sections 3 and 5 are how we meet our side of this split.

Where a product includes AI features, requests are sent to commercial model providers, currently Anthropic (Claude), OpenAI and Google (Gemini). The provider for a given project is agreed with the client. Where a client requires that no data leaves a defined boundary, we deploy self-hosted or on-premise models instead, as described in section 4.

Two further providers handle limited, specific tasks for our own website and some client applications. Neither holds a primary copy of client data.

• Upstash (serverless Redis), used to rate limit our public API routes and prevent abuse. For each request to a protected route we store the visitor’s IP address as part of a temporary counter key, together with request timestamps. Entries expire automatically, and no later than 30 minutes after a visitor’s last request. No form content, account data or client records are stored in it. Our Upstash database is hosted on Amazon Web Services in the ap-southeast-2 (Sydney) region. The Upstash plan we use does not include access to its SOC 2 report or contractual compliance commitments, which is why we keep what it holds to this short-lived rate limiting data.
• Formspree (form delivery), used to deliver contact form enquiries to our team by email. Each submission is saved to our own Supabase database first and then forwarded to Formspree, which sends the notification. Formspree therefore receives the content of the enquiry: the name, email address, phone number, company, service interest, budget, timeline and message the visitor entered. Formspree is a United States company hosting on Amazon Web Services in the United States. It encrypts stored data with AES-256, requires TLS 1.2 or higher in transit, holds a SOC 2 Type II report, and uses Standard Contractual Clauses for cross-border transfers.

Row Level Security (RLS) is a database level access control mechanism that restricts which rows of data a user or application role can read or modify. RLS policies are enforced at the database engine level, not at the application layer, making them significantly more robust than application level filtering alone.

For all multitenant SaaS applications and any system handling sensitive client data, Longcloud implements RLS as a default architectural pattern. Each user or tenant can only access rows of data that belong to them, enforced by the database regardless of how the query is constructed at the application level.

• All tables containing user or tenant data have RLS policies enabled by default
• Policies are tested during development and as part of our QA process
• Administrative access is restricted to authorised roles with auditable access logs
• RLS policies are documented and reviewed as part of security sign off on each release

For self hosted deployments, the client is responsible for securing the underlying server infrastructure, operating system patching, network perimeter controls, and physical security. Longcloud will provide security guidance but cannot be responsible for the client managed infrastructure layer.

• Threat modelling during architecture and design phases
• Secrets management, no credentials, API keys, or tokens in source code

• Multifactor authentication (MFA) enforced for all administrative and privileged accounts
• Role based access control (RBAC) with least privilege defaults
• OAuth 2.0 / OpenID Connect for third party authentication where applicable
• Session management with automatic timeout and secure cookie flags

• All data in transit encrypted via TLS 1.2 or higher
• All data at rest encrypted using AES-256 or equivalent
• Database backups encrypted before storage

• All API endpoints require authentication unless explicitly public

We monitor our managed infrastructure. Security events are logged, correlated, and escalated according to severity. Our incident response process follows the NIST framework: Prepare → Detect → Contain → Eradicate → Recover → Learn.

In the event of a confirmed security incident that affects client data, Longcloud will notify affected clients within 72 hours of discovery. Notifications will include: the nature of the incident, data potentially affected, actions taken to contain and remediate, and recommended steps for the client.

Following every significant security incident, we conduct a blameless post incident review. Findings are documented and used to improve our controls, processes, and monitoring. A summary can be provided to affected clients on request.

Please send vulnerability reports to:

We do not run a paid bug bounty programme and do not offer rewards for reports. Reports that consist only of automated scanner output, such as missing optional security headers or email and DNS configuration checks, without a demonstrated security impact, are out of scope and may not receive a reply.