Security
Security that is built into the system, not described in a brochure.
This page lists the controls that are implemented in Data Accommodation today. We do not claim certifications we do not hold. If your organisation needs more detail for a security review, contact us.
Tenant isolation
One hotel can never see another’s data.
Every hotel organisation shares the platform, so separation cannot depend on each screen remembering to filter. It is enforced underneath, in the data layer.
Enforced in the data layer
Every database read and write on tenant data is automatically restricted to the caller’s organisation and to the properties they may access. Records created are stamped with the organisation; writes aimed at another tenant are refused.Cross-tenant references rejected
A write cannot link to another tenant’s records — for example, booking a room type or charging a folio that belongs to a different organisation.Automated isolation tests
An integration test suite attempts to read, change, pay against and search another tenant’s reservations, guests, folios and rooms — including with API keys and property-scoped users — and runs in continuous integration.Property-level access
Within an organisation, a person limited to one property cannot select or read a sibling property.
Access control
Everyone gets exactly the access their job needs.
Granular permissions
Permissions are defined per action — viewing a guest’s identity number, voiding a charge, approving a purchase order — and checked by the server on every request.Standard and custom roles
Twenty hotel roles are provided, from owner and general manager to housekeeper, waiter and storekeeper. Organisations can build their own.No privilege escalation
People can only grant roles whose permissions they hold themselves, and a property-level administrator cannot grant organisation-wide roles.Scoped API keys
API keys carry an explicit list of permissions, can be limited to one property, can expire, and are stored only as a hash.
Accounts & sessions
Sign-in that resists the common attacks.
argon2id password hashing
Passwords are hashed with argon2id and must be at least ten characters long.Two-factor authentication
Time-based one-time codes (TOTP) from any authenticator app, with hashed recovery codes. The authenticator secret is stored encrypted.Lockout and rate limiting
Accounts lock for 15 minutes after repeated failed sign-ins. Sign-in, password reset and other credential endpoints have a much tighter rate limit than the rest of the API.httpOnly session cookies
Session tokens live in httpOnly cookies that page scripts cannot read, marked Secure in production. Access tokens are short-lived and refresh tokens rotate on every use.CSRF protection
Every state-changing request made with a session cookie must carry a matching CSRF token, compared in constant time.Session control
People can see and revoke their sessions. Changing or resetting a password signs out other sessions, and disabling a user ends theirs immediately.
Audit
A record that cannot be quietly rewritten.
Append-only audit log
Sensitive actions — voids, discounts, refunds, cancellations, role changes, identity reveals — are recorded with who, when, from where and why. A database trigger blocks updates and deletes.Hash-chained
Each audit entry includes the hash of the one before it, per organisation, so any alteration breaks the chain. The chain can be verified on demand.Audited support access
When our staff act inside a customer account, it requires a written reason, uses a time-limited session and is recorded in both the audit log and the security event log.Security events
Failed sign-ins, failed two-factor attempts, invalid webhook signatures and blocked payment replays are logged as security events.
Guest & payment data
Handle the most sensitive data least.
Encrypted identity numbers
Passport and ID numbers are encrypted with AES-256-GCM. Only the last four characters are stored in clear; revealing the full number needs a specific permission and is audited.No card data stored
Card and wallet payments happen on the provider’s hosted checkout. We receive the verified result, never the card number.Idempotent payments
Payment requests carry an idempotency key, so a retried or double-clicked payment is recorded once. Provider confirmations are verified server-side and replays are refused.Guest privacy tools
Export everything held about a guest, or anonymise a guest profile while keeping the financial records the law requires.Your data stays yours
Export guests, reservations, folios, invoices, payments and the audit log at any time. A lapsed subscription becomes read-only; data is not deleted.
Application
Defence in depth at the edges.
Validated input
Every API request body and query is validated against a strict schema before it reaches business logic.Security headers
Content Security Policy, HSTS, frame restrictions, no-sniff and a strict referrer policy on the web application.Separated hosts
The public website, hotel back office, staff app, guest pages and our own platform console are served on separate hosts, and hotel operations are refused on hosts where they do not belong.Data integrity constraints
Double bookings and overlapping room blocks are prevented by database constraints, not just application checks.
What we do not claim
Data Accommodation does not currently hold SOC 2, ISO 27001 or PCI DSS certification, and single sign-on (SAML/OIDC) is not available. Two-factor authentication is chosen by each user rather than enforced per role. Card payments are designed so that card data never touches our systems.
Found a vulnerability? Please report it through our contact form — choose “Something else” and start the message with “Security” — and do not access data that is not yours while testing.
Questions from your IT or security team?
We will walk through how isolation, access control and auditing work in detail.