Security Statement

This Security Statement describes the technical and organisational measures Kapsule Group Limited ("KapsuleHost") implements to protect the data hosted on our platform. It is referenced by the Data Processing Agreement and is updated from time to time to reflect improvements to our security posture.

Our core principle is defence in depth: we layer multiple independent controls so that no single failure exposes customer data.

We maintain documented information security and privacy policies, reviewed at least annually and updated when material changes to the platform or threat landscape require it.

A designated Privacy Officer holds responsibility for data protection compliance. Security responsibilities are assigned to named individuals on the infrastructure team.

All personnel receive privacy and security training on induction and annually thereafter. Personnel with access to production systems are subject to background checks where permitted by law.

Security incidents and near-misses are recorded, reviewed, and used to improve controls on an ongoing basis.

Access to production systems and customer data is governed by strict role-based access controls built on least-privilege principles: personnel are granted only the access they need to perform their specific role.

Mandatory two-factor authentication (2FA) is enforced for all personnel with access to production infrastructure, the hosting control panel, source code, and cloud provider consoles.

Access rights are reviewed periodically and revoked promptly on role change or departure. Access events and privilege escalations are logged.

Production and non-production environments are strictly separated. Customer environments are logically isolated from each other within the hosting platform.

All administrative access to production servers is authenticated via SSH key pairs; password-based SSH authentication is disabled.

All data in transit between customers and our platform is encrypted using TLS 1.2 or higher. TLS certificates are issued automatically and renewed before expiry.

Off-site backups are encrypted using restic with AES-256. Encryption keys are stored separately from backup data and backed up offline. Loss of the key makes backup data unrecoverable, which is why keys are held in multiple secure offline locations.

Encrypted backups are stored with an independent object storage provider in the Oceania region, providing geographic separation from our primary hosting infrastructure.

Application secrets, API keys, and credentials are stored in restricted-permission files on the servers that use them, accessible only to the service account that requires them, and are never embedded in source code or committed to version control. Infrastructure and backup secrets are additionally protected using SOPS with age encryption.

Every production surface, including our marketing website, the customer control panel, our API, and customer-hosted sites, is protected by a web application firewall (ModSecurity with the OWASP Core Rule Set) running on our own infrastructure. Our marketing website is additionally protected by a web application firewall at our CDN edge, running in blocking mode. Edge-layer protection covers customer-hosted sites served through our CDN. It does not extend to the customer control panel or our API.

Customer sites are isolated from each other and from shared platform services at the network layer, not merely by separate filesystem accounts and processes. Kernel-level firewall rules (nftables), keyed to each process's own system account rather than to any application logic, block every non-administrative process, including every customer site's own application code, from reaching the shared database port or any other site's own application-server port. This has been verified by driving real connection attempts from inside a live site's own execution context, in both directions: blocked for an ordinary site process, permitted for system administration. The same mechanism also blocks non-administrative access to internal cloud-infrastructure service endpoints that a site process should never be able to reach. It does not yet extend to every shared service: the platform's shared caching service is protected by per-site credentials scoped to that site's own data, but is not yet additionally blocked at the network layer the way the database and application-server ports are; extending the same firewall protection to it is a planned enhancement to our security programme.

Operating systems, platform software, and application dependencies are patched on a regular cadence. Security updates are applied automatically via unattended-upgrades, usually within a day of release. For critical security patches, including any that require manual intervention such as a reboot or that are not yet available through automated updates, our committed ceiling is 7 days from release. Internet-facing infrastructure is scanned for known vulnerabilities on a regular basis.

Firewall rules restrict inbound access to the minimum necessary ports and services. Unnecessary services are disabled by default.

Periodic penetration testing is conducted by independent qualified testers. Material findings are remediated and retested.

Authentication attempts, account and configuration changes, and actions taken by our own personnel on customer accounts are logged to a centralised, append-only database audit trail, retained for a minimum of 90 days. Infrastructure and system-level logs (web server, firewall, and operating system logs) are retained locally on each production server, accessible only to authorised personnel, and are additionally shipped hourly to an independent, write-once off-site store with a 90-day retention lock: once written, a log archive cannot be deleted or overwritten by anyone, including us, for that period, so a compromised server cannot erase evidence of what happened on it.

Platform health and security signals are monitored 24x7. Alerts are routed to on-call personnel for immediate investigation.

We maintain a documented incident response plan with defined severity levels, escalation paths, and communication procedures. The plan is reviewed and tested at least annually.

In the event of a confirmed Notifiable Privacy Breach affecting Customer Personal Information, we will notify affected customers within 72 hours of becoming aware, as required by the Privacy Act 2020 and the Data Processing Agreement.

Sentry is used for real-time error tracking and application performance monitoring across the platform stack.

Customer site files, databases, and email data are backed up daily to off-site object storage in the Oceania region using restic. Backups are encrypted at rest with AES-256.

Backup retention is a minimum of 30 days on all paid plans. Higher plans retain backups for longer: 90 days, 1 year, or 7 years, depending on the tier purchased. See the Service Level Agreement for plan-specific retention details.

Restore procedures are documented in our internal runbooks and tested periodically. The platform team conducts restore drills to validate backup integrity.

The KapsuleHost platform codebase (including configuration and provisioning scripts) is backed up daily to private GitHub repositories in the kapsulenz organisation, providing an independent recovery path for the platform itself.

Disaster recovery procedures for each infrastructure component are documented with target recovery times specific to that component: up to 8 hours for the hosting server, scaled to the volume of customer data being restored; 2 to 4 hours for the mail platform; and 4 hours for the customer portal.

All personnel with access to customer data are bound by confidentiality obligations, either by contract or by law.

We maintain written data processing agreements with all sub-processors. These agreements require sub-processors to implement protections no less protective than those in our Data Processing Agreement, including confidentiality, security, and limited-purpose processing obligations.

Our sub-processor list is reviewed at least annually for continued suitability. Sub-processors are assessed against our minimum security requirements before engagement.

The current list of sub-processors is published at kapsulehost.com/legal/sub-processors.

Production servers are operated in third-party data centres. We do not own or operate a data centre, so physical security, environmental controls, power redundancy and fire suppression are the facility operator's responsibility, and our agreements with infrastructure sub-processors require protections no less protective than those in our Data Processing Agreement. We do not publish the country of individual production servers: our capacity moves as we add regions, and a location published once is wrong the day it changes without anybody editing it. The sub-processors we engage are listed at kapsulehost.com/legal/sub-processors.

Physical access to server hardware is restricted to authorised data centre personnel. KapsuleHost personnel do not have routine physical access to production hardware; all administrative access is performed remotely over encrypted channels.

Decommissioned storage media is securely wiped or destroyed in accordance with the data centre operator's procedures before reuse or disposal.

Application secrets, API keys, and sensitive configuration values are stored in restricted-permission files on the servers that use them and are never committed to source code repositories. Infrastructure and backup secrets are managed separately using SOPS with age encryption.

Pre-release testing includes functional, regression, and security-focused test runs. Changes to authentication, payment, or data-handling flows receive additional scrutiny.

Customer-facing input is validated and sanitised at all application boundaries. We apply standard defences against OWASP Top 10 risks including SQL injection, cross-site scripting, and cross-site request forgery.

KPanel authentication: passwords are hashed with Argon2id (memory-hard, resistant to GPU cracking). New passwords are checked against the Have I Been Pwned database via k-anonymity prefix lookup before acceptance. Sign-in supports TOTP-based two-factor authentication, SMS one-time codes, and hardware passkeys (WebAuthn/FIDO2). OAuth sign-in is supported via Google, GitHub, Apple Sign In, and Discord. Google and Apple Sign In are verified against the provider's own JWKS endpoint; GitHub and Discord do not publish a JWKS endpoint for OAuth sign-in, so those two are verified instead by calling the provider's own account API directly with the access token it issues. Sign-in attempts are rate limited per IP address, and repeated failed attempts against a single account are locked out for a period. Session tokens are cryptographically random and cryptographically signed, and expire after 30 days of inactivity.

Customer data is logically segregated at the hosting, database, and application layers. Each customer's files and databases are isolated under separate system accounts, with no cross-customer access.

Email is isolated and protected on its own terms. Every mailbox is a separate account, isolated by our mail server's access controls, and signs in with its own credentials. Our mail servers accept only TLS 1.2 and TLS 1.3: TLS 1.0 and 1.1 are refused on every mail port, over both IPv4 and IPv6. We do not offer unencrypted IMAP or POP3 at all, and no sign-in method of any kind is offered before a connection is encrypted. The server-to-server mail port does not offer sign-in at all. Five failed sign-ins within five minutes block the connecting IP address for an hour, and the mail server independently blocks IP addresses behind repeated abusive connections. Mailbox data is stored on encrypted volumes (AES-256-XTS), and mail backups are encrypted. Every domain we host mail for gets its own DKIM signing keys, in both RSA and Ed25519, together with an SPF record. Our own domain, kapsulehost.com, publishes a DMARC policy of reject and an SPF policy that ends in -all, so receiving servers that check DMARC refuse mail that forges it. It also publishes an enforced MTA-STS policy with TLS reporting, which tells sending servers to deliver mail to us only over an encrypted connection to a verified certificate.

When a customer terminates their service, Customer Personal Information is made available for export for 30 days, then permanently deleted from live systems. Encrypted backup copies are purged on the next scheduled rotation cycle, within 30 days of deletion from live systems.

Documented data deletion procedures ensure that data is removed from all relevant systems, including live databases, caches, and application storage, not just the primary datastore.

Procedures for handling Data Subject requests (access, correction, deletion) are documented and tested. KPanel export tools allow customers to retrieve their data at any time during the service term.

If you have questions about our security practices, or wish to report a suspected vulnerability, please contact us at privacy@kapsulehost.com.

Kapsule Group Limited, New Zealand.