Sabee security whitepaper.

Executive summary

Sabee is a cloud property management platform operated by Sabee Cloud OÜ, an Estonian company acting as data controller and, for certain processing activities on behalf of customers, data processor under the General Data Protection Regulation. Sabee's infrastructure, application security programme, and organisational controls are built around a single premise: guest and property data belongs to the operator, and our job is to protect it with the same seriousness a bank applies to a ledger, not the seriousness a typical SaaS vendor applies to a support ticket.

This whitepaper documents our corporate governance around data protection, our infrastructure architecture, our encryption and access-management approach, our application security and vulnerability-management programmes, our monitoring and incident-response posture, our backup and business-continuity planning, our sub-processor and vendor-risk practices, and the compliance framework we operate under today alongside the roadmap we are executing toward.

Corporate structure & data-protection governance

Sabee Cloud OÜ is registered in Tallinn, Estonia (reg. 14975208), and is subject to the supervisory authority of the Estonian Data Protection Inspectorate (Andmekaitse Inspektsioon, AKI) for GDPR compliance matters. Sabee has appointed a Data Protection Officer with formal reporting lines to the executive team, independent of the engineering and commercial functions whose activities the DPO is responsible for overseeing.

The DPO owns the data-protection impact assessment process for new features that touch personal data, maintains the record of processing activities required under GDPR Article 30, and is the point of contact for data subject rights requests, supervisory authority correspondence, and customer due-diligence questionnaires. Governance decisions with material data-protection implications — a new sub-processor, a new data flow, a change to retention policy — require DPO sign-off before release.

Infrastructure architecture

Sabee's production infrastructure runs on Amazon Web Services, with Frankfurt (eu-central-1) as the primary operating region and Dublin (eu-west-1) configured as the disaster-recovery region. No customer data is processed or stored outside the European Union or European Economic Area as part of Sabee's standard service delivery.

Every production workload runs inside a dedicated Virtual Private Cloud with strict network segmentation. Application and database tiers sit in private subnets with no direct internet route; the only internet-facing components are a hardened load-balancer tier and a small number of explicitly defined ingress points, each behind a web application firewall. All infrastructure is defined and provisioned through Terraform, meaning environment configuration is version-controlled, peer-reviewed, and reproducible rather than manually clicked together in a console — a change to a security group or an IAM policy goes through the same pull-request review as application code.

Compute resources are horizontally scaled and stateless wherever the architecture allows, so individual instance failure does not threaten data integrity or availability, and scaling under load does not require manual intervention. Databases run in a managed, multi-AZ configuration with synchronous replication to a standby within the primary region and asynchronous replication to the disaster-recovery region.

Encryption

All customer data is encrypted at rest using AES-256, with key management handled through AWS Key Management Service (KMS). Database volumes, object storage, and backup snapshots are encrypted by default as a platform-wide policy, not an opt-in setting — there is no data store in production that holds customer data unencrypted at rest.

All data in transit, whether between a browser and the Sabee application, between Sabee and a connected OTA or payment processor, or between internal services, is encrypted using TLS 1.3. TLS 1.2 and earlier protocol versions are not accepted on any public endpoint. HTTP Strict Transport Security is enforced with preload, and certificate management is automated to eliminate expiry-related outages.

Beyond platform-wide encryption at rest, specific categories of personal data — government identification numbers captured for hotel registration compliance, and payment-related tokens — receive an additional layer of field-level encryption at the application layer, using envelope-encrypted data keys distinct from the storage-layer encryption keys. This means that even a hypothetical compromise of underlying storage access would not, on its own, expose these fields in readable form.

Access management

Internal staff access to production systems is governed through Okta as our single sign-on provider, with every employee account requiring hardware-token multi-factor authentication for access to production-adjacent systems. Password-only authentication is not accepted for any system that touches customer data.

Engineers do not hold standing access to production infrastructure. Access to production systems, including database consoles and infrastructure management tools, is granted just-in-time through a bastion access system: an engineer requests a time-boxed session with a stated justification, a second engineer approves it, and the session is logged in full, including commands executed, for later audit. Standing production credentials are treated as a control failure whenever discovered and are removed on discovery.

Role-based access control governs every internal system, following the principle of least privilege — an employee's access reflects the minimum set of systems and data required for their current role, and access grants tied to a previous role are removed on role change, not merely supplemented. A formal quarterly access review requires every system owner to re-certify who holds access to their system, with automatic escalation for accounts that have not been reviewed within the quarter.

Application security

Sabee's software development lifecycle incorporates security review at multiple stages rather than as a final gate before release. Every pull request runs through static application security testing (SAST) as part of the CI pipeline, flagging common vulnerability classes (injection, insecure deserialization, hardcoded secrets) before a human reviewer even looks at the diff. Dynamic application security testing (DAST) runs against staging environments on a scheduled basis, probing the running application for the kind of vulnerabilities that only appear at runtime.

Dependency scanning runs continuously against every service's package manifest, flagging known-vulnerable libraries and, where an automated and low-risk upgrade path exists, opening a pull request automatically. Our secure SDLC requires a peer code review for every change, security-focused review for any change touching authentication, authorization, payment handling, or personal data fields, and a documented threat-modelling pass for any new feature that introduces a new data flow or new external integration surface.

Vulnerability management & penetration testing

Sabee commissions an annual external penetration test performed by a CREST-certified third-party firm, covering the web application, API surface, and infrastructure configuration. Findings are triaged by severity, with critical and high findings tracked to remediation on an expedited timeline and verified by the same firm in a follow-up retest. A summary of the most recent penetration test is available to prospective and existing customers under NDA.

In addition to the annual external test, an internal security team runs quarterly vulnerability assessments against production infrastructure and the application surface, using both automated scanning tooling and manual review of higher-risk areas identified from the prior quarter's findings. Sabee also operates a private, invitation-based bug bounty programme through HackerOne, engaging a curated pool of external researchers on an ongoing basis rather than relying solely on point-in-time testing engagements.

Monitoring & logging

Production systems are monitored continuously through Datadog for infrastructure and application performance metrics, and Loggly for centralized log aggregation. Logs covering authentication events, data access, administrative actions, and infrastructure changes are retained in immutable storage for 400 days, satisfying both our own incident-investigation needs and the longer-tail audit requirements several of our Enterprise customers have specified in due-diligence reviews.

A security information and event management (SIEM) layer correlates log data across services and infrastructure to detect anomalous patterns — unusual authentication behaviour, unexpected data-export volume, access pattern deviations from an established baseline — and raises alerts to the on-call security engineer. Alert thresholds are tuned on an ongoing basis to balance sensitivity against alert fatigue, with every true-positive incident feeding back into detection-rule refinement.

Backup & disaster recovery

Sabee's backup strategy is built around a 15-minute recovery point objective (RPO) in typical operating conditions and a 4-hour recovery time objective (RTO) for a full regional failover. Database backups are continuous, encrypted, and replicated cross-region from the Frankfurt primary to the Dublin disaster-recovery region, so a regional infrastructure failure does not represent a single point of failure for customer data.

Disaster-recovery failover is not a theoretical capability — it is tested through a quarterly restore drill in which the engineering team executes an actual failover to the disaster-recovery region against a non-production replica of the current production dataset, measuring real RTO and RPO against the documented targets and logging any deviation as an action item for the following quarter.

Business continuity

Sabee's business continuity plan (BCP) covers not only infrastructure failure but organisational continuity — loss of access to primary office locations, key-person unavailability, and third-party service disruption from critical vendors including our cloud provider and payment processing partners. The BCP is tested annually through a tabletop exercise involving the executive team and functional leads across engineering, customer success, and operations.

Leadership succession is explicitly documented as part of the BCP: defined backup decision-makers are identified for each executive function, so an incident affecting any single leader does not stall incident response, customer communication, or operational continuity. The plan is reviewed and updated at least annually, or immediately following any real incident that exposes a gap.

Incident response

Sabee maintains a 24×7 on-call rotation for production-affecting incidents, staffed by engineers with the authority and access to begin remediation immediately rather than escalating through a multi-step chain before action can start. A documented incident-response playbook defines severity classification, escalation paths, internal communication cadence during an active incident, and post-incident review requirements.

Where an incident involves, or is reasonably suspected to involve, a breach of personal data, Sabee commits to notifying affected data controllers (our customers) within 24 hours of confirming the nature of the incident, consistent with our obligations under the Data Processing Addendum and GDPR Article 33's onward-notification expectations. Every incident, regardless of ultimate severity, receives a written post-incident review documenting root cause, timeline, and remediation actions, with relevant findings shared with affected customers on request.

Sub-processors & vendor risk

Sabee maintains a current, published list of sub-processors involved in service delivery — infrastructure providers, payment processing partners, monitoring and logging tooling, and customer-communication tooling. Every sub-processor is contracted under a Data Processing Agreement incorporating Standard Contractual Clauses where applicable, and is subject to an annual vendor risk re-assessment covering their own security posture, certifications, and any material changes to their processing activities.

Customers are notified of any new sub-processor addition in advance, consistent with the notice period specified in our Data Processing Addendum, and retain the right to object to a new sub-processor under the terms of that agreement. Sabee does not add a sub-processor with access to customer personal data without completing this review and notice process.

Compliance framework

Sabee's information security programme is designed around GDPR Article 32's requirements for the security of processing — encryption, ongoing confidentiality/integrity/availability, resilience of processing systems, and a process for regularly testing and evaluating the effectiveness of technical and organisational measures. Beyond GDPR, our programme is aligned with the ISO 27001 information security management standard, with formal certification targeted for 2026. SOC 2 Type II is on our roadmap for 2027, reflecting increasing demand from customers expanding into markets where that attestation is a standard procurement requirement.

For payment-related data, Sabee operates under PCI DSS SAQ-A scope: card data is never handled, transmitted, or stored directly by Sabee's own systems, with card capture delegated entirely to our PCI Level 1-certified payment service provider partners. This scoping decision — rather than pursuing broader PCI certification for card handling we do not perform — reflects a deliberate choice to minimise the surface area of sensitive card data across our platform entirely.

Physical security

Sabee does not operate its own data centres; all production infrastructure runs on Amazon Web Services, which maintains its own physical security programme across biometric access control, 24×7 on-site security personnel, environmental controls, and redundant power and connectivity. AWS's data-centre attestations — including ISO 27001, SOC 1/2/3, and PCI DSS Level 1 service provider status — are available through AWS's own compliance documentation and are incorporated by reference into our own security posture for the infrastructure layer.

Personnel security

All Sabee employees undergo a background check appropriate to their role and jurisdiction prior to starting, with enhanced checks for roles with access to production systems or customer data. Every employee signs a confidentiality and non-disclosure agreement as a condition of employment, covering both customer data and Sabee's own proprietary information.

Security awareness training is mandatory for all employees at onboarding and refreshed annually, covering phishing recognition, secure handling of customer data, incident-reporting procedures, and acceptable use of company systems. Employees in roles with elevated system access receive additional role-specific security training covering secure coding practices, infrastructure access discipline, and incident response responsibilities.

Change management

Every production change follows a peer-review process: no engineer deploys their own unreviewed code to production. Deployments use a blue-green strategy, routing traffic to a new environment only after automated health checks pass, with an automated rollback path if error rates or latency exceed defined thresholds following a release. This minimises the blast radius of any single bad deploy and removes the need for a manual, high-pressure rollback decision under incident conditions.

Infrastructure changes follow the same discipline as application code — proposed as a Terraform pull request, reviewed by a second engineer, and applied through the automated pipeline rather than manual console changes, preserving a complete audit trail of who changed what infrastructure configuration and when.

Cryptography key management

Encryption keys are managed through AWS KMS using envelope encryption: data is encrypted with a data key, and the data key itself is encrypted with a master key that never leaves the KMS hardware security module boundary. This means raw key material is never directly accessible to application code or engineering staff. Key rotation for master keys is performed on a quarterly cadence, and access to key-management operations is restricted to a small number of authorised infrastructure roles, itself subject to the same quarterly access review as every other system.

Data lifecycle

Customers retain ownership and control over their own data retention rules within Sabee — a property can configure how long guest records, reservation history, and communication logs are retained, consistent with their own regulatory obligations and business needs. Where a customer requests deletion, or where a retention period they have configured expires, Sabee executes a hard delete on the standard schedule: 30 days for most operational data categories, extending to 90 days for categories retained temporarily in backup snapshots pending the natural backup rotation cycle. Deleted data is not recoverable once this cycle completes.

Responsible disclosure

Sabee welcomes reports of potential security vulnerabilities from independent researchers and the wider security community. Reports can be sent to security@sabee.esesun.com, with a PGP key (key ID 0xA1B2C3D4E5F60789) available on request for researchers who wish to encrypt sensitive report details. Reports are triaged within one working day, and researchers who identify a valid, previously unreported vulnerability are eligible for recognition and, where applicable, a reward through our HackerOne programme.

This whitepaper is reviewed and updated regularly as our security programme evolves. For the most current version, a signed copy for procurement purposes, or any question not answered here, contact our security team directly.