Security

We describe what we run. We do not publish performance numbers or audit claims.

One instance for each hotel

• A separate Google Cloud project for each hotel, with its own application on Cloud Run and its own PostgreSQL database on Cloud SQL.
• Keys and passwords kept in Google Secret Manager.
• No data path between two hotels.

Where it runs

Each instance runs in one Google Cloud region, agreed with the hotel before setup.

Protecting data

• Encryption at rest (Google Cloud default) and in transit (TLS).
• Selected guest fields encrypted inside the application with AES-256-GCM.
• Card numbers are typed into Stripe's form. AURI never sees or stores them.
• Daily database backups with point-in-time recovery.

Access

• Passwords stored as bcrypt hashes.
• Separate roles for staff and administrators.
• Sessions held on the server, with a set lifetime.
• API keys with their own permissions.
• Staff actions on guest records written to an audit log.

Guest data requests

• Export one guest's data, bookings and consents as a JSON file.
• Anonymise a guest: personal details removed, booking records kept for the accounts.
• Consent records store when the guest agreed or withdrew, and to which version of the notice.

How releases are checked

Before a change is merged, automated tests run and the gosec and govulncheck scanners look for security problems.

What we do not claim

• No security certification. AURI does not hold SOC 2 or ISO 27001.
• No independent security audit or penetration test.
• No uptime or speed figures.

Documents on request

On request we send the security whitepaper, the data processing agreement template and the list of sub-processors.