Security & Data Practices
1. Overview
This page summarises the technical and organisational measures applied to personal data processed through BookingPilot, operated by the BookingPilot project (legal entity registration in progress, Albania). It reflects our internal Data Protection Impact Assessment and incident-response documentation, and is published for transparency as part of the Data Processing Agreement (/dpa).
2. Technical and organisational measures
The technical and organisational measures applied to personal data processed through the Service comprise the following: (a) tenant isolation, by means of row-level security enforced on every database table, such that each Property's records are reachable only by its active members and internal tables carry no public grants; (b) encryption at rest, stored card details and guest identity-document numbers being encrypted with keys held in an isolated vault, decryption occurring only inside the database and plaintext reaching staff solely through the card-reveal flow described at (d); (c) encryption in transit, by means of TLS on all connections; (d) card-reveal controls, full card data being masked by default and reveal requiring a one-time verification code emailed to the requesting staff member, each successful verification authorising reveals for thirty minutes and every request, grant, denial and purge being written to an internal audit log; (e) access control, staff access being scoped by role and membership (owner, admin, front desk, housekeeping), with a session inventory permitting per-device revocation and passwords held only as salted hashes; (f) automated retention and deletion, scheduled jobs enforcing the published retention schedule without manual intervention; (g) secrets management, credentials and keys being held in managed secret stores and never in code or client bundles; (h) change management, data-layer changes being versioned and reviewed; and (i) incident response, a documented runbook defining classification, containment, assessment and notification procedures.
3. Tenant isolation and access control
Every table in the Service's database enforces row-level security scoped to property membership: staff accounts can reach only records belonging to properties in which they hold an active membership, and internal tables are not exposed to anonymous callers at all. Roles (owner, admin, front desk, housekeeping) further limit what each staff member can do. Every sensitive write is checked server-side, and anonymous requests carry no access to tenant data.
The single anonymous entry point into the Service is the guest pre-check-in facility: each reservation carries a unique, unguessable link token, possession of which permits the holder to view the reservation's dates and the guest's first name and to submit identity-document, arrival and contact details for that reservation alone. The link endpoint returns no previously submitted personal data, is unavailable for reservations that have been cancelled or whose stay has ended and for properties whose account is closed, and writes through the same encryption scheme that protects identity document numbers recorded by staff.
4. Payment card data
Card details are encrypted at rest with keys held in an isolated vault and are decrypted only inside the database layer. Card data is displayed masked to the last four digits by default; revealing the full details requires a one-time verification code emailed to the requesting staff member, a successful verification authorising reveals for thirty minutes, and every request, grant, denial and administrative action is recorded in an internal access log. Card security codes are erased automatically within fourteen days of capture or on the day following checkout, whichever occurs first, and full card details are erased ninety days after checkout. Guest identity document numbers are protected under the same at-rest encryption scheme.
5. Authentication and session security
Sign-in supports one-time email codes, passwords and third-party OAuth sign-in. Passwords are held only as salted cryptographic hashes; passwords set by a property administrator must be at least twelve characters, and an administrative reset revokes the target account's existing refresh tokens server-side, is written to the audit log, and notifies the affected account by email. Each signed-in device is registered in an active-session list visible to the account holder, recording last-activity time, device identity and an approximate city/region-level location and timezone derived from IP address; individual sessions can be revoked, and revoked sessions cease to work within minutes. Session records are erased on the schedule described herein.
6. Retention and deletion
We retain personal data only for such periods as are necessary for the purposes described in this notice, after which the data is erased or anonymised. The following retention periods apply, enforced by scheduled automated jobs rather than by manual policy: card security codes (CVC) are erased no later than fourteen days after capture or on the day following checkout, whichever occurs first; full card details are erased ninety days after checkout, the last four digits being retained for reconciliation and dispute purposes; card-reveal verification codes are retained for no more than twenty-four hours, each code additionally expiring after five minutes and being usable once only, with a successful verification authorising card reveals for thirty minutes; the card-access audit trail recording every card reveal, erasure and export is retained for one year, the minimum period required for payment-card security auditing; guest conversation messages are retained for two years, and the Property may delete a conversation at any time, in which case its messages and attachments are erased immediately; erasure of a guest also erases that guest's conversation messages outright, including staff replies within the same threads; automation queue rows for ninety days; activity-log (audit) rows for one hundred and twenty days; staff session records for thirty days of inactivity or seven days following revocation, whichever occurs first; AI assistant conversations for ninety days; the email suppression list recording opt-outs and delivery failures, retained for as long as is necessary to honour the opt-out or to protect delivery integrity, on the basis of legitimate interest; consent records for the duration of the account as immutable accountability evidence; support tickets and attachments, the staff directory and channel-synchronisation data until such time as the Property deletes them or the account is closed; conversations held through the public support chat are retained only for as long as necessary to handle the enquiry and any follow-up, and are erased upon request or when the conversation is deleted; push subscriptions until the permission is withdrawn or the account is closed, stale subscriptions being additionally purged after ninety days; data-subject request records for one year following resolution; marketing campaign delivery records for one year; sign-up verification codes for one day; and guest profiles, reservations and payment records until such time as the Property deletes them or the account is closed. Diagnostic and application logs are retained only for the short operational periods determined by the hosting provider and are not used for profiling or disclosed for secondary purposes. Upon closure of an account a thirty-day deletion window applies, following which the property record and all associated data, including stored files, are deleted, save where a longer period is required by law or by the rotation schedule of encrypted backups.
7. Infrastructure and sub-processors
We engage a limited number of third-party service providers in the operation of the Service. Each such provider is bound by a data processing agreement or equivalent contractual safeguards, and each receives only the minimum data necessary for the performance of its designated function.
The categories of provider so engaged are the following: (a) database hosting, authentication, file storage and realtime messaging, with processing performed in the European Union (Ireland) and access to all Service data at rest, under a data processing agreement incorporating Standard Contractual Clauses and with the primary processing site located within the European Union; (b) transactional and guest-facing email delivery, with processing in the United States, receiving recipient address, message content and delivery telemetry, under a data processing agreement supported by certification under the EU-US Data Privacy Framework and Standard Contractual Clauses; (c) artificial intelligence inference for the staff assistant and the public support chat, with processing in the United States, receiving prompts and responses submitted through those features, under a data processing agreement incorporating Standard Contractual Clauses, configured for zero data retention and without training on customer data; (d) channel-management synchronisation of availability, rates and bookings with online travel agencies, with processing in the United Kingdom, receiving guest and reservation data for the channels selected by the Controller, under a data protection addendum and on the basis of the United Kingdom adequacy decision; (e) push-notification delivery effected through the service operated by the recipient's browser vendor, which may be located outside the European Economic Area, receiving the push endpoint, cryptographic keys and notification payload, under the browser vendor's own terms, the endpoint being generated by the user's device; and (f) optional third-party sign-in (OAuth), with processing in a location dependent on the provider, transmitting the authentication request and returning basic account attributes such as email address, under the provider's own terms and only at the user's initiative; and (g) content delivery, static-site hosting, automated-traffic screening and IP geolocation for session security, with processing on a global edge network including the United States, receiving visitor IP addresses and browser request data on every page load, of which solely a coarse city-level location derived from the IP address is retained in session records, under a data processing addendum incorporating Standard Contractual Clauses.
The identity of each provider comprised within the categories described above, together with a copy of the safeguards applicable to it, is made available to Controllers upon request addressed to privacy@bookingpilot.al and accompanies the Data Processing Agreement. We notify Controllers at the email address registered on the account before engaging or replacing any provider, and the Controller may object on reasonable data-protection grounds; where we cannot reasonably accommodate a justified objection, the Controller may terminate the account.
8. Incident response
A documented incident-response runbook defines classification, containment, assessment and notification steps. As processor we notify affected Properties without undue delay, targeting twenty-four hours, so that they can meet their own seventy-two-hour authority-notification deadlines; incidents are logged internally even where notification thresholds are not met. Suspected vulnerabilities or incidents may be reported confidentially to security@bookingpilot.al; our disclosure contact is additionally published at /.well-known/security.txt in accordance with RFC 9116.
9. Data-subject rights tooling
Properties can export a guest's record as a structured JSON document and can erase a guest, anonymising reservation snapshots, scrubbing payment names and deleting the profile, directly within the Guests area. Optional guest-facing communications include a one-click unsubscribe honoured by a suppression list, while messages necessary for the fulfilment of a booking are always delivered; consent to terms, privacy notice and marketing is recorded server-side at sign-up.
10. Organisational measures
Access to production systems is limited to the minimum personnel necessary and is governed by least-privilege credentials; secrets are held in managed secret stores rather than in code; changes to the data layer are versioned and reviewed; and the compliance documentation referenced on this page is maintained as part of the Service's operating procedures.