Security & data practices

Built for the people
who trust you with their data.

Hamlet is built and operated for the people who run shared workspaces, and the members, guests and staff who pass through them every day. Protecting their data, and yours, is foundational to what we do.

At a glance
Operating entity
Vicinia Pty Ltd (ABN 70 653 966 637), trading as Hamlet — Australian-incorporated
Hosting
Google Cloud Platform, australia-southeast1 (Sydney)
Data residency
Primary customer data stored in Australia. Encrypted backups in GCP asia multi-region by default; AU-only backup region available on request.
Encryption
TLS 1.2+ in transit · AES-256 at rest
Payments
Tokenised gateways. PAN and CVC never stored. PCI-DSS scope: SAQ-A
Tenant model
Per-customer logical isolation; dedicated database available on request
Backup retention
30-day rolling · 7-day point-in-time recovery
Availability target
99.5% measured monthly. Contractual SLAs available on enterprise plans.
Incident notification
Within 72 hours of confirmation, aligned with the AU Privacy Act NDB scheme
Sub-processor changes
30 days prior written notice with right to object

For enterprise customers and procurement teams who need a more detailed view, a confidential Security & Data Posture document is available on request — security@hamletco.space.

  1. 01

    Hosting and data residency

    Hamlet runs on Google Cloud Platform in the australia-southeast1 (Sydney) region. All production compute and primary customer data storage are located in Australia.

    Application compute runs on Google Kubernetes Engine. Customer data is stored in Google Cloud SQL for PostgreSQL. User-uploaded files are stored in Google Cloud Storage, also in australia-southeast1. Asynchronous workloads run on a managed Redis layer.

    Inbound traffic terminates at a TLS-terminating GCP HTTP(S) load balancer. Application services run on the cluster's private network and are not directly addressable from the public internet.

    Encrypted database backups are stored in the GCP asia multi-region by default. For enterprise customers requiring AU-only backups, a customer-managed AU-only backup region can be configured on request.

  2. 02

    Encryption

    In transit: all traffic to and from the platform is HTTPS-only, with TLS 1.2 or higher enforced platform-wide. HSTS with a one-year max-age, a CORS allowlist restricted to production origins, and a hardened set of HTTP security response headers.

    At rest: customer data in Cloud SQL and Cloud Storage is encrypted with AES-256 using GCP-managed keys. Customer-managed encryption keys (CMEK) are available for enterprise customer instances on request and can be scoped to a customer-controlled GCP project.

  3. 03

    Payments and PCI-DSS

    Hamlet integrates with tokenised payment gateways: Worldpay (via IntegraPay) in Australia and Stripe elsewhere. Cardholder data is captured directly by gateway-hosted forms in the browser. Hamlet servers receive payment tokens only.

    PAN and CVC are never stored on Hamlet infrastructure. Card data never enters Hamlet's network or storage. PCI-DSS scope: SAQ-A.

  4. 04

    Access control and tenant isolation

    End-user authentication uses signed JSON Web Tokens (RS256). Passwords are hashed using bcrypt and never stored in cleartext. Login attempts are subject to per-account and per-IP rate limiting.

    Role-based access control across all application surfaces: manager, staff, power-user, member, and anonymous (for public booking surfaces).

    Each customer operates within a dedicated tenant boundary on shared infrastructure. Logical isolation is enforced at the query layer — every database query and mutation is filtered by the tenant identifier derived from the authenticated user's JWT. Physical isolation (dedicated database per customer) is available as an enterprise option on request.

    Hamlet engineering access to production systems follows the principle of least privilege. Production database access is mediated by Google Cloud SQL Auth Proxy and requires Google Workspace authentication. Database-level audit triggers record changes to sensitive tables.

  5. 05

    Sub-processors

    Hamlet uses a small number of trusted sub-processors for hosting, payments, communications, analytics, accounting and related functions. The current list is published at /sub-processors.

    We provide 30 days' prior written notice before adding or replacing a sub-processor that handles customer data. Customers can object in writing within that notice period; if we can't resolve the objection through reasonable discussion, the customer may terminate the affected service without penalty. Emergency replacements are notified as soon as practicable, with the rationale.

  6. 06

    Data retention and deletion

    Customer data is retained for the duration of the customer agreement. Audit records are retained for the operational life of the platform. Cloud SQL automated backups are retained for 30 days on a rolling basis. Point-in-time recovery is available within the most recent 7 days.

    On termination: customer data is purged from active databases within 30 business days of termination through a documented engineering procedure. Removal is confirmed in writing to the customer's designated security contact. Backups continue to age out under the standard 30-day rolling retention window.

    Hamlet supports subject access and deletion requests routed through the customer. Response target: 30 days from receipt. Full data exports in machine-readable format are available on request at any time during the agreement.

  7. 07

    Backup and disaster recovery

    Recovery point objective: 5 minutes within the 7-day PITR window, 24 hours beyond that. Recovery time objective: 4 hours for full database restoration from PITR snapshot. Availability target: 99.5% measured monthly.

    Cloud SQL automated backups run daily within a 4-hour window scheduled outside production peak hours. Application services run on GKE with redundant pods; pod or node failures are recovered automatically. Region-level outages are addressed through manual restore from cross-region backup. Restore procedures are runbook-documented and have been exercised.

  8. 08

    Incident response

    For confirmed material security incidents affecting a customer instance, Hamlet notifies the customer's designated security contact within 72 hours of confirmation, aligned with the Notifiable Data Breaches scheme under Part IIIC of the Privacy Act 1988 (Cth).

    Detection: server-side errors and integration failures are forwarded to a monitored internal notification channel reviewed during business hours by an on-call engineer, with out-of-hours coverage via an engineering on-call rota. Hamlet does not currently operate a 24/7 SOC.

    For material incidents, customer updates are provided no less frequently than every 12 hours until resolution. A written post-incident summary is produced within 10 business days of incident closure. Customer security inquiries received at security@hamletco.space are acknowledged within one business day.

  9. 09

    Compliance posture

    Australian Privacy Act 1988 and the Australian Privacy Principles: Hamlet operates in alignment with the APPs. Privacy notices and consent flows are configurable per customer instance.

    PCI-DSS: Hamlet's payment integrations operate on tokenised gateways. PCI-DSS scope: SAQ-A.

    GDPR: not in scope for AU-only customer instances. Where customer instances handle personal data of EU or UK residents, Hamlet can provide controller / processor terms and DSAR procedures on request.

    SOC 2: Hamlet does not currently hold SOC 2 attestation. We maintain internal controls aligned with SOC 2 Type I trust principles and can provide a controls overview on request. Formal attestation is on our roadmap, prioritised against enterprise customer demand.

    ISO 27001: Hamlet does not currently hold ISO 27001 certification and is not actively pursuing it.

  10. 10

    Vulnerability disclosure

    Hamlet welcomes responsible disclosure. Reports submitted to security@hamletco.space are triaged on the same channel as customer-initiated security inquiries.

    We ask reporters to provide enough detail for us to reproduce the issue, allow a reasonable remediation window before public disclosure, and avoid actions that could harm other customers, end users, or the platform (denial-of-service testing, data exfiltration, or social engineering of staff).

    We don't currently operate a public bug bounty program, but we acknowledge serious good-faith disclosures publicly (with permission) and won't take legal action against researchers who follow this guidance.

Document version

Version 1.0 · 11 May 2026 · Initial public release. This page is updated when material changes occur to the platform's security posture, sub-processor list, or commitments described above.

Security contact

Talk to Hamlet security.

Vulnerability disclosure, sub-processor change notifications, incident reporting, procurement questions. Acknowledgement target: one business day.