Security

Security and data protection

Your property's calendar, guest details and payment records live with us. This page explains how that data is protected, who can see it, and what happens when something goes wrong.

There is no such thing as an accidentally deleted record

No record written to the database is ever permanently deleted. A delete deactivates the record and everything attached to it; the interface behaves as if it were gone, but the data stays. Issued invoices and payment records are under statutory retention anyway.

Deactivated records are listed on their own screen and can be restored.
Restoring is an ownership action, not a section permission — it reopens old invoices, payments and bank details.
Confirmation dialogs list exactly what will be deactivated and where it can be restored from.

Who can see what

Permissions are section-based and enforced on the server. Hiding a button in the interface is not authorisation; an unauthorised request is rejected server-side.

An endpoint with no entry in the permission map is REJECTED by default — if a permission line is forgotten when a new endpoint ships, it fails closed rather than open.
Read and write are separate permissions; accounting, reservations and property management are separate sections.
Some actions cannot be done with a section permission at all and require account ownership (restoring a deactivated record, handing over channel rate/availability control).
Every screen shows which user you are working as, and actions are written to an audit log.

Channel credentials

Where a sales channel's credentials are needed, they are stored encrypted on the server with AES-256-GCM and are never sent back to the panel — the panel only sees whether a password is on file.

Booking.com never asks for your password: you add us as a user in the extranet and keep using your own login and two-factor authentication.
Taking over channel management requires a separate, explicit approval; without that stamp it is not considered handed over, and you can withdraw it at any time.
Leaving the field blank keeps the stored password; deleting it is a separate action.

Payments and card data

Collection runs over licensed, 3D Secure and PCI-DSS compliant infrastructure. Card details are processed on that infrastructure; the panel does not hold card numbers.

3D Secure verification, SSL-encrypted transport.
Collections, refunds and payout movements are recorded and reported.

Outbound requests

Operations that reach outside — such as listing import — all pass through a single guarded layer. That layer protects both you and us.

Only allow-listed domains are contacted; redirects are followed manually and the list is re-checked at every hop.
Connections to internal network addresses are blocked; size and time limits are applied on decompressed data.
Accepted content types are enumerated — saying "any image" would mean accepting a file that carries script.

Transparency

When something breaks, we do not hide it.

Service status is published on a public page.
What changed in the product is written up on the product updates page.
Processing of personal data is covered by the privacy policy; our relationship with the hotel is set out in the Hotel General Terms.

If you found a vulnerability

Write to us. We take reports seriously, fix verified findings and get back to you. We ask that you give us a reasonable window to fix it before sharing the issue with third parties.

Send a security report

System status Privacy policy Hotel General Terms Product updates

This page describes the product's security approach; infrastructure details and internal control documents are not published. For an enterprise review, contact our sales team.