Skip to content
RentDariRentDari

Data security

In force since6 min read

This page describes the technical and organisational measures actually in place to protect the data entrusted to RentDari. It serves as our reference under Article 32 of the General Data Protection Regulation and complements our privacy policy, our list of sub-processors and our data processing agreement.

We confine ourselves here to what is in place. This document describes neither intentions nor a roadmap.

1. Hosting and data location

RentDari's application infrastructure — compute, database and file storage — is hosted in the European Union. That is where our customers' data is processed and stored.

Our communication and monitoring providers are configured on their European points of presence: transactional email is sent from ZeptoMail's European infrastructure, product usage analytics goes to PostHog's European instance, error monitoring to Sentry's German instance, and smart locks go through Tuya's European endpoints.

A few services remain established outside the European Union — push notification delivery, mapping, and distribution of mobile application updates. They are listed one by one, with the exact nature of the data concerned, on the Sub-processors page. The corresponding transfers are governed by the European Commission's standard contractual clauses.

2. Encryption and transport

Traffic between your browser, our mobile application and our servers is encrypted in transit using TLS. Certificates are issued and renewed automatically, and no interface is exposed unencrypted.

Connections to the database and calls to each of our providers likewise travel over encrypted channels, with an explicit timeout on every outbound call.

Data at rest is encrypted by the infrastructure providers that host it — managed database and object storage.

Session cookies are issued with the browser's security attributes in production and expire after thirty days.

3. Authentication and access control

  • Passwords are stored as hashes; they are never stored in clear text and cannot be read by anyone, including our own team.
  • Two-factor authentication via an authenticator application (TOTP) is available on every account.
  • Sign-in by one-time code sent by email uses a six-digit code, valid for ten minutes, limited to five attempts.
  • Sessions are held in a dedicated store and can be revoked immediately, individually or all at once.
  • API keys can be created for the REST integration: only a fingerprint of the key is retained, and the full value is displayed once only, at creation.
  • Public entry points — guest check-in, account deletion requests, forms — are rate-limited per IP address.

4. Workspace isolation

RentDari is a multi-tenant platform: each customer's data is isolated by workspace. This isolation is enforced server-side, as each request is resolved, and not by the interface: a request cannot reach another workspace's data, however it is phrased.

Roles then determine what each member sees inside a workspace. Owners get a portal restricted to their own properties, and service providers a portal restricted to their own assignments.

5. Guest identity documents

Online check-in may lead a guest to submit an identity document. These documents are handled differently from every other file:

  • They are placed in a private storage area and are never made public at any point.
  • The database holds only the object's internal path, never a publicly reachable address.
  • They can be viewed only through signed links valid for fifteen minutes, generated on demand.
  • Only two parties can view them: the customer managing the property, and the guest themselves from their own check-in link.
  • Until an authorised person opens it, the public interface exposes only the fact that a document is present, not its content.

These documents and the associated check-in information are retained for the duration of the contractual relationship. The customer, as controller, may request their deletion at any time at [email protected]; we act on it within thirty days.

Check-in and the arrival guide are reachable by the guest through a personal link, protected by an unguessable random token with a limited validity period.

Sensitive details of a stay — door code, key-box location, Wi-Fi password — are never placed in the body of an email. Only the link travels; the content appears only once the link is opened, and according to the release rules the customer has set.

7. Payments

RentDari subscriptions are collected through Stripe. Card details are entered on a Stripe-hosted page: no card data passes through our servers and none is stored there.

Guest payments are not collected by RentDari. The platform records only the status declared by the customer — paid, partial, pending — for tracking purposes.

8. Integrations and external interfaces

  • Incoming notifications from our distribution and pricing partners are signature-verified before being processed; an unsigned notification is rejected.
  • iCal calendar addresses entered by a customer are fetched behind a guard against requests to internal addresses, with a timeout and a maximum size.
  • The calendar we publish outward contains only busy periods and the property name: no guest data.
  • Smart-lock credentials belong to the customer: RentDari holds no platform-wide key for that service.
  • Access through the MCP protocol to an artificial-intelligence tool requires an explicit OAuth authorisation, revocable by the customer at any time.

9. Logging and usage analytics

We track product usage and the technical health of the platform using analytics and monitoring tools. What is sent to each is described service by service on the Sub-processors page; in particular, error traces and analytics events contain the address of the page concerned.

Session recording is disabled on every guest-facing page — check-in, arrival guide, online booking — as well as on the legal pages.

10. Backups and continuity

The database runs on a managed offering: its backup and restoration are provided by that service, at the frequency and retention period of the subscribed plan.

Every release of the application is published under a unique code fingerprint, which allows a return to an earlier version without rebuilding.

We do not publish a quantified service-level commitment (RPO/RTO). A customer who needs one as part of a procurement process is welcome to write to us.

11. Incidents and data breaches

In the event of a personal data breach, RentDari informs the customer without undue delay after becoming aware of it, in accordance with Article 33 of the GDPR. The notification describes the nature of the breach, the categories and approximate volume of data and people affected, the likely consequences, and the measures taken or proposed.

As RentDari acts as a processor, it falls to the customer, as controller, to notify their supervisory authority and, where applicable, the data subjects. We provide them with the information they need.

12. Development and team access

  • Access to production systems is limited to the people who need it to operate the service.
  • Infrastructure secrets are held outside the source code, in the runtime platform's secret store.
  • Changes are reviewed before going to production and deployed by an automated pipeline from an identified version.
  • Everyone with access to the data is bound by a confidentiality obligation.

13. Certifications

RentDari holds neither an ISO/IEC 27001 certification nor a SOC 2 report at this time. We prefer to write that plainly rather than leave it ambiguous: the measures described on this page are the ones genuinely in place, and they have not been audited by an independent third party.

We do, however, answer the security questionnaires sent by our customers and their principals. Write to [email protected].

14. Reporting a vulnerability

If you believe you have found a security flaw, write to [email protected] with what is needed to reproduce it. We acknowledge receipt within three working days and keep you informed of how it is handled.

We will take no action against anyone researching a vulnerability in good faith, without degrading the service, without accessing other people's data beyond what is needed to demonstrate the issue, and without disclosure before a fix.