Security & Data Practices

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.

This page summarises how Hamlet hosts, protects, and operates the platform. For enterprise customers and procurement teams who need a more detailed view, a confidential Security & Data Posture document is available on request — contact us at security@hamletco.space.

At a glance

1. 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 (jobs, scheduled tasks, short-lived caches) 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. Encryption

In transit. All traffic to and from the platform is HTTPS-only, with TLS 1.2 or higher enforced platform-wide. We apply HSTS with a one-year max-age, a CORS allowlist restricted to known production origins, and a hardened set of HTTP security response headers (including X-Frame-Options: DENY, Referrer-Policy: same-origin, and a restrictive Permissions-Policy).

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. 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. Access controls and tenant isolation

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

Authorisation. Hamlet implements role-based access control across all application surfaces. Roles include manager, staff, power-user, member, and anonymous (for public booking surfaces).

Tenant isolation. 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. Cross-tenant data access is prevented at the query layer. Physical isolation (dedicated database per customer) is available as an enterprise option on request.

Staff access to production. 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.

Audit trail. Database-level audit triggers record changes to sensitive tables, including the actor, source IP, and timestamp. Sensitive columns (such as stored payment references) are excluded from audit row payloads.

5. Sub-processors

Hamlet uses a small number of trusted sub-processors to deliver the platform — for hosting, payments, communications, analytics, accounting, and related functions.

The current sub-processor list is published at hamletco.space/sub-processors and is updated when sub-processors are added or replaced.

Change notification. We provide 30 days’ prior written notice before adding or replacing a sub-processor that handles customer data. Customers can object to a proposed change 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 (for security or continuity reasons) are notified as soon as practicable, with the rationale.

6. 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 containing customer data continue to age out under the standard 30-day rolling retention window.

Subject access and deletion. Hamlet supports access and deletion requests routed through the customer (the APP entity / controller for end-user data). Our response target for individual subject requests is 30 days from receipt. Full data exports in machine-readable format are available on request at any time during the agreement.

7. Backup and disaster recovery

• Cloud SQL automated backups run daily within a 4-hour window scheduled outside production peak hours.
• Application services run on Google Kubernetes Engine with redundant pods; pod or node failures are recovered automatically by the cluster scheduler with no operator intervention.
• Region-level outages within australia-southeast1 are addressed through manual restore from cross-region backup.
• Restore procedures are runbook-documented and have been exercised.

Material recovery events affecting a customer instance are communicated to the customer’s designated security contact in the same timeframe and through the same channel as security incidents (Section 8).

8. Incident response

For confirmed material security incidents affecting a customer instance, Hamlet will notify the customer’s designated security contact within 72 hours of confirmation. This commitment is 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. Out-of-hours coverage is provided by an engineering on-call rota. Hamlet does not currently operate a 24/7 security operations centre.

Triage and remediation. Incident triage and remediation is owned by Hamlet engineering. The on-call engineer leads the response and engages the platform owner for material incidents.

Customer communication. For material incidents, customer updates are provided no less frequently than every 12 hours until resolution, delivered to the customer’s designated security contact.

Post-incident review. For material incidents, Hamlet produces a written post-incident summary within 10 business days of incident closure, covering scope, timeline, root cause, remediation, and preventive measures.

Customer security inquiries received at security@hamletco.space are acknowledged within one business day.

9. Compliance posture

Hamlet is committed to operating transparently. The following reflects our current posture — we say what we have, and we say what we don’t.

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. Cardholder data is captured by gateway-hosted forms; Hamlet servers receive payment tokens only. PCI-DSS scope: SAQ-A.

GDPR. GDPR coverage is not in scope for AU-only customer instances. Where customer instances handle the personal data of EU or UK residents, Hamlet can provide controller / processor terms and Data Subject Access Request (DSAR) procedures on request.

SOC 2. Hamlet does not currently hold SOC 2 attestation. We maintain internal controls aligned with the 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.

Sub-processor due diligence. Hamlet reviews sub-processors on contract renewal or material change. Customers are notified of new or replacement sub-processors per Section 5.

10. Vulnerability disclosure

Hamlet welcomes responsible disclosure of security vulnerabilities. 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;
• avoid actions that could harm other customers, end users, or the platform (such as denial-of-service testing, data exfiltration, or social engineering of our 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.

11. Where we’re investing

Security is never finished. The following are in active delivery on our platform hardening roadmap:

• short-lived JWT access tokens with refresh-token renewal;
• multi-factor authentication for customer administrator users;
• formal server-side enforcement of password policy and login rate limits;
• expansion of audit logging coverage;
• HSTS preload and includeSubDomains directive;
• ongoing migration of configuration to runtime secrets injection.

Specific delivery commitments for enterprise customers are confirmed in writing on or before each control’s general-availability date.

12. Security contact

For security inquiries, vulnerability disclosure, sub-processor change notifications, and incident reporting:

security@hamletco.space

Monitored by Hamlet platform leadership. Acknowledgement target: one business day.

For procurement teams: a confidential Security & Data Posture document, providing a more detailed view of the controls described on this page, is available on request.

13. Document version

This page is updated when material changes occur to the platform’s security posture, sub-processor list, or commitments described above. Customers can subscribe to security update notifications by emailing security@hamletco.space.