Security Policy
Longcloud AI Limited (“Longcloud”) is committed to maintaining the highest standards of security for the software we build, the data we handle, and the infrastructure we manage. This Security Policy outlines our practices, controls, and commitments to protecting client and user data.
Introduction
Security is foundational to everything we build. From the architecture decisions we make at the start of a project to the monitoring we maintain after launch, security is embedded at every layer of our development process. This policy applies to all Longcloud systems, software products, and client engagements.
Infrastructure and Hosting
We leverage enterprise grade cloud infrastructure with industry leading security certifications. Our primary hosting environments are:
2.1 Supabase (AWS Sydney Region)
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.
2.2 Microsoft Azure
For AI workloads and certain enterprise deployments, we utilise Microsoft Azure. Azure holds ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, and SOC 3 certifications, along with GDPR compliance frameworks.
2.3 Cloudflare
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 or to Microsoft Azure instead. Residency requirements are agreed with each client before a platform is chosen.
2.4 Shared Responsibility Model
Security on managed cloud platforms is a shared responsibility, and we think it is worth being explicit about the split. It applies equally to Cloudflare, Supabase and Azure.
- 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, management and rotation of API tokens and secrets, authentication and authorisation logic, 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.
Data Isolation and Row Level Security
3.1 What Is RLS?
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.
3.2 How We Implement RLS
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
On premise and Self-Hosted Deployments
For clients requiring on premise or self hosted solutions, including air gapped environments, we offer the following:
4.1 Secure Deployment Packages
We provide containerised deployment packages (Docker / Kubernetes) with hardened configurations, documented network requirements, and step by step deployment guides for your infrastructure team.
4.2 Secure Integration Plugins
Where our software integrates with third party systems, we build integration connectors that follow least privilege principles, use short lived tokens where possible, and avoid storing credentials in plaintext.
4.3 Air gapped Environments
For high security environments with no external network access, we can deliver software that operates fully offline, with update mechanisms that support manual, verified patch delivery.
4.4 Client Responsibilities
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.
Application Security
5.1 Secure Development Practices
- OWASP Top 10 compliance as a baseline for all applications
- Threat modelling during architecture and design phases
- Peer code review with security considerations as part of the checklist
- Automated static analysis (SAST) integrated into CI/CD pipelines
- Dependency vulnerability scanning (SCA) on all third party packages
- Secrets management, no credentials, API keys, or tokens in source code
5.2 Authentication and Access Control
- Multifactor authentication (MFA) enforced for all administrative and privileged accounts
- Role based access control (RBAC) with least privilege defaults
- Short lived JWT tokens with secure refresh mechanisms
- OAuth 2.0 / OpenID Connect for third party authentication where applicable
- Session management with automatic timeout and secure cookie flags
5.3 Encryption
- 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
- Encryption keys managed through dedicated key management services
5.4 API Security
- All API endpoints require authentication unless explicitly public
- Rate limiting and throttling applied to prevent abuse
- Input validation and output encoding to prevent injection attacks
- API versioning and deprecation policies to manage change safely
Third party and Supply Chain Security
We carefully evaluate all third party libraries, services, and infrastructure providers before incorporating them into our stack. Our evaluation criteria include security certifications, incident history, data processing agreements, and ongoing maintenance track records.
- All third party dependencies are reviewed before adoption
- Automated dependency scanning runs on every build
- Critical vulnerabilities in dependencies are patched within 48 hours of disclosure
- We maintain a software bill of materials (SBOM) for all client deliverables on request
The certifications above are those held by each provider. Formal attestations, such as SOC 2 Type II reports and PCI Attestations of Compliance, are issued by the providers themselves and are generally available under a non-disclosure agreement through their trust portals. If you are completing a vendor risk assessment and need these documents, contact us and we will help you obtain the relevant ones for the platforms your project uses.
Security Incident Response
7.1 Detection and Response
We maintain monitoring and alerting across 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.
7.2 Client Notification
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.
7.3 Post Incident Review
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.
Responsible Disclosure
We welcome responsible disclosure of security vulnerabilities found in our systems, software, or client applications that we manage.
8.1 How to Report
Please send vulnerability reports to:
8.2 Our Commitments to Researchers
- We will acknowledge receipt of your report within 2 business days
- We will investigate and keep you informed of our progress
- We will not pursue legal action against researchers acting in good faith
- We will credit researchers publicly (with their consent) upon resolution
- We aim to resolve critical vulnerabilities within 30 days of confirmed disclosure
8.3 Guidelines
- Do not access, modify, or delete data beyond what is necessary to demonstrate the vulnerability
- Do not perform denial of service attacks or any action that degrades our services
- Do not disclose the vulnerability publicly until we have had a reasonable opportunity to remediate
- Provide sufficient detail for us to reproduce and verify the issue
Organisational Security
- All Longcloud team members complete security awareness training
- Access to production systems is restricted to authorised personnel only
- MFA is mandatory for all internal tools, cloud consoles, and code repositories
- Offboarding procedures include immediate revocation of all system access
- Security policies are reviewed and updated at least annually
- Client data is never used for training AI models or any purpose beyond delivery of agreed services
Compliance and Standards Alignment
We align our security practices with the following frameworks and regulations:
- New Zealand Privacy Act 2020, Information Privacy Principle 5 (data security)
- OWASP Top 10, Application security best practices
- NIST Cybersecurity Framework, Risk identification, protection, detection, response, and recovery
- ISO/IEC 27001 principles, Information security management (aspirational alignment)
- New Zealand Government Cloud Computing Requirements, For government sector clients
- Australian Privacy Act 1988, For Australian clients and data
- GDPR principles, For European clients where applicable
Updates to This Policy
This Security Policy may be updated periodically to reflect changes in our technology, practices, or regulatory environment. The effective date at the top of this document will be updated accordingly.
For significant changes that may affect your engagement with us, we will provide direct notification where reasonably practicable.
Contact Us
For questions about this Security Policy, to report a security concern, or to discuss security requirements for your project, please contact us:
© 2026 Longcloud AI Limited. All rights reserved. · This policy is governed by the laws of New Zealand.