Talkguest security whitepaper.

1. Data classification

Talk with Guest handles three broad classes of data. Guest personal data — names, contact points, stay history, payment tokens, preferences and messages — is treated at the highest sensitivity. Hotel operational data — rates, availability, forecasts, staff assignments, financials — is treated at a hotel-confidential sensitivity. Platform metadata — request logs, deployment metrics, aggregate benchmarks — is treated at a business-internal sensitivity.

Each class has different encryption keys, different access boundaries, and different retention policies. Guest personal data is encrypted with per-tenant keys that never touch a shared keyring; hotel operational data uses per-region keys that isolate residency; platform metadata uses a global platform key that never protects customer identifiable information.

2. Encryption in transit

Every network hop is TLS 1.3 with modern cipher suites and forward secrecy. TLS 1.2 is available for legacy OTA connectors that have not yet migrated, and only for those specific outbound routes; every path that reaches a guest browser, a customer staff device or a Talkguest reception app is TLS 1.3 or the connection fails.

HSTS is enforced on every hostname the platform owns, with a two-year duration and preload submission. Certificates are issued through automated ACME renewal; the manual override path requires two Talkguest engineers to co-sign.

3. Encryption at rest

Database volumes, object storage buckets, log archives and backup snapshots are encrypted at rest with AES-256-GCM. Keys are held in a hardware-backed KMS in the primary EU region, with automated rotation every 90 days for platform-wide keys and every 30 days for per-tenant keys. Old key material is retained for the minimum period required to decrypt encrypted backups within the backup retention window, then destroyed.

4. Network isolation

The production environment is a private VPC with no inbound path except through the platform load balancer and a hardened bastion. Every service is placed in a subnet that maps to its trust level; the database layer accepts connections only from the application layer, the application layer accepts connections only from the ingress layer, and the ingress layer accepts connections only from the internet through the load balancer.

Egress is filtered on a positive-allowlist of the exact hostnames the platform needs to reach — OTAs, payment providers, mail servers, monitoring vendor. A new egress destination requires a change ticket signed by an engineering lead.

5. Secrets management

Production credentials are stored in a KMS-backed secrets manager, never in code repositories, never in configuration files on disk. Application services read secrets at boot into ephemeral memory; no service persists a plaintext secret across a process restart. Credential rotation is scheduled for every production secret at least every 90 days and can be triggered on-demand within a few minutes.

Staff never touch production credentials directly. Access to production systems is mediated by session-scoped tokens issued through the internal identity provider, and every issuance is audit-logged.

6. Access control

Every human that touches production is subject to WebAuthn multi-factor authentication with hardware security keys; SMS-based factors and time-based OTP codes are explicitly not accepted as sole factors. Access is granted by role, not by named individual; a role can access a specific class of data for a specific purpose, and role membership is reviewed every quarter.

Emergency access — used when an on-call engineer must diagnose a production issue with elevated privileges — is time-boxed to four hours, requires a second engineer to co-approve, and creates a mandatory postmortem note reviewed by the security lead.

7. Backup strategy

The primary database is backed up continuously through write-ahead log shipping to encrypted object storage in a separate EU region. Point-in-time recovery is available for the last 30 days at a five-minute granularity; snapshot restore is available for the last 12 months at a daily granularity. Object storage buckets have versioning and object-lock enabled to prevent tampering.

Every backup is decrypted and mounted into a scratch environment on a weekly rotation to verify the restore path. A backup that has not been restored is a backup that does not exist, and we count restore verifications, not backup creations, in our internal metric.

8. Incident response

Talk with Guest operates a 24/7 on-call rotation with two engineers per shift and a security duty officer available for elevated incidents. Every incident above severity 3 (customer impact greater than one property) has a named incident commander from the first minute, published in the internal status channel and mirrored to affected customers.

Postmortems are published in customer-visible language within seven days of resolution. Postmortems are non-punitive by policy: the goal is to change the system, not to punish the operator. Historical postmortems are available to any customer on request.

9. Audit trail

Every write to a customer tenant produces an audit line that records the actor (user or service), the action, the target object, the before-and-after values, the source IP, the user-agent, and the request identifier that ties it to the ingress log. Audit lines are retained for 24 months by default and can be extended to 84 months on request for regulatory reasons.

Customers can query their own audit trail through the platform UI and through the API. Talkguest staff access to a customer's audit trail requires an explicit reason logged into the internal audit trail — the audit trail is itself audited.

10. Vulnerability disclosure

Security researchers who report a vulnerability in good faith are protected from legal action by our vulnerability disclosure policy. Reports are triaged within two business days, acknowledged with a case number, and eligible for bug-bounty rewards on the published scale — €200 for a low-severity finding through €5,000 for a critical finding on the platform authentication surface. Report to abuse@talk.mindbery.org with reproduction steps.

11. Third parties (subprocessors)

Every third party that processes customer data on behalf of Talk with Guest is listed in the subprocessor register with the country of processing, the purpose, and the safeguards in place. Changes to the register are announced with 30 days' notice. The register is available on request to any customer.

12. Business continuity

The platform has been engineered to survive the failure of any single availability zone in the primary EU region. In the event of a primary-region outage, we can promote the secondary EU region into service in under two hours; the promoted region carries the last 24 hours of writes from the write-ahead log stream, with a data-loss window of no more than five minutes for any tenant.

13. Retention & deletion

Guest personal data is retained for the operationally required period (typically for the reservation lifetime plus statutory retention for tax and legal purposes — a rolling six years in Portugal). Right-to-be-forgotten requests are actionable through the platform UI: a guest profile marked for erasure has personally identifying fields tokenised in the database and purged from backups on the standard rotation.

When a tenant leaves Talkguest, we return all tenant data on request within 30 days, then delete it — including from backups on the standard rotation — within a further 60 days. A signed deletion certificate is issued if requested.

14. Contact

Security questions: abuse@talk.mindbery.org. Privacy and data subject rights: privacy@talk.mindbery.org. Named DPO: Rita Ferreira Marques, dpo@talk.mindbery.org. Enterprise customers can request the extended annex with per-control mapping to ISO 27001 and SOC 2 controls.