Security and Data Protection

Infrastructure and encryption

Client Reservation uses Firebase and Google Cloud services for authentication, database, file storage and server-side processing. Application traffic is sent over HTTPS. Google states that customer content is encrypted at rest and in transit between its facilities. Firebase also states that its services encrypt data in transit using HTTPS and encrypt relevant service data at rest.

Firebase publishes provider-level compliance information, including ISO 27001 and SOC 1, SOC 2 and SOC 3 evaluations across Firebase services, with additional ISO 27017 and ISO 27018 coverage for some services. These are assurances relating to the Firebase/Google infrastructure used by Client Reservation; they do not mean that Client Reservation itself is independently certified under those standards.

Official information: Google Cloud encryption and Firebase privacy and security.

Identity, roles and access control

Administrative access requires an authenticated Firebase account. The platform then applies role-based and contextual checks before making business data available.

Access is separated between:

• Business owners, who can manage their own active business and venues.
• Staff login accounts, whose access is granted separately for each feature and each venue. A missing or restricted permission provides no access.
• Authorised Client Reservation personnel, whose access is limited to assigned businesses and approved support or platform-administration functions.
• Customers and guests, who receive only the customer-facing or public-booking capabilities appropriate to them.

Access is enforced in both the application and the server-side security layer. Firebase Security Rules evaluate requests made by browser and mobile clients, while privileged server operations independently authenticate the caller and verify their role, business, venue and feature permissions. This avoids relying on a hidden button or page redirect as the security boundary.

Firestore documentation confirms that every request from a web or mobile client is evaluated against the configured security rules. See Firestore Security Rules.

Business and venue isolation

Business data is logically separated by business identifier. A user who belongs to one restaurant cannot use that access to read another restaurant's private customers, bookings or management data.

Venue access is checked independently because a business may have several venues with different staff permissions. Access is allowed only where the user, business and venue remain active and authorised.

When access to a business or venue is suspended or revoked, operational access is blocked. Authorised Client Reservation personnel retain only the access required for approved support and platform-administration functions.

Customer information

Customer profiles are business-wide within one restaurant business. This allows the same customer profile to be used when that customer books at different venues belonging to that business, but it does not make the profile available to other restaurant businesses.

Authorised restaurant users may need customer details such as name, contact information, customer-provided notes, allergy information and booking history to provide the service. Staff permissions control whether a staff member may manage customer records. Where the booking workflow only needs an existing profile, restricted staff cannot use it to create a new permanent customer profile.

Customers and authorised restaurant administrators can currently update the same customer-provided notes associated with that restaurant's profile.

Where customer self-service editing is available, database rules allow changes only to appropriate profile fields. Customers cannot use the profile editor to alter protected information such as:

• email identity linked to the authentication account;
• VIP status or business-assigned tags;
• ownership, role or access-control fields; or
• internal system and administrative metadata.

Routine removal of a customer in the application archives the profile so that linked booking records are not deleted unexpectedly.

Public and guest booking security

Unauthenticated guests may make a booking where a venue permits guest bookings. They are not given general database access.

The public booking site reads a deliberately limited public representation of a business and venue. Full business documents, staff data, customer lists and private table-layout information are not exposed publicly. Availability and allocation decisions are performed or verified by server-side functions.

Secure session controls and server-side checks are used to protect bookings and reduce double booking. A public booking reference by itself is not sufficient authority to access or modify a booking.

Public booking and availability requests are validated and rate-limited. Duplicate-processing controls help prevent repeated requests from unintentionally creating the same booking or related operation more than once.

Payments and deposits

Client Reservation uses Stripe Checkout and Stripe Connect for applicable payment and deposit workflows. Payment sessions are created by the server after the relevant business, venue, booking and caller checks have been completed.

Customers enter card information into Stripe's payment interface. Client Reservation does not store full card numbers or card security codes. Stripe states that it is certified as a PCI Level 1 service provider and encrypts sensitive data both at rest and in transit. Stripe also explains that Checkout hosts payment inputs within Stripe's domain, so card details do not pass through the merchant's own servers.

The platform verifies Stripe event signatures before accepting payment events and uses duplicate-processing controls for payment and refund operations.

Payment security is a shared responsibility. Each business remains responsible for maintaining its Stripe account, completing any Stripe-requested PCI validation and protecting access to its Stripe dashboard.

Official information: Security at Stripe.

Images and file storage

Cloud Storage access is restricted by path, user role and intended use. Upload rules validate information such as file type, size and ownership context.

Customer profile photographs and private company reference images are stored as private files. Before the application displays one of these files, the server confirms that the signed-in user is allowed to see the associated business data and then issues a short-lived image URL. This avoids relying on permanent public bearer links for private images.

Public-facing assets are kept separate. Venue photographs, logos and other approved images may be public where they are intentionally needed before sign-in or on guest booking pages.

Uploaded images are validated and checked before approval, and temporary files are removed according to defined retention periods. Firebase Storage Security Rules provide server-enforced controls over file paths and can validate upload metadata such as content type and size. See Cloud Storage Security Rules.

Email, password reset and website-form protection

Password-reset emails are generated through protected server-side flows, allowing the correct business branding while keeping email delivery credentials on the server. Requests are validated and rate-limited to reduce abuse.

Public contact and demonstration-request forms use validated POST requests. Submitted fields are constrained and escaped before being inserted into email content, reducing the risk of injected markup. Browser requests are restricted to approved website origins, with server-side validation, rate limiting and duplicate-request controls also applied.

Marketing email unsubscribe links are signed so that altered links cannot change unsubscribe preferences.

Session revalidation and revoked access

Administrative sessions are revalidated at security-relevant times to confirm that access remains authorised.

If a server-confirmed change shows that a user, business, staff membership, feature or venue has been revoked, the affected data and functionality are blocked. While verification is unresolved, access remains protected.

Monitoring, duplicate protection and retention

The platform records structured, redacted security events to help identify and investigate access or verification issues. Support incidents include a reference that can help connect a customer report with relevant diagnostics.

Device details and user-supplied diagnostics are added only through a user-consented support process.

Temporary security and operational records have defined expiry periods and are removed automatically. Booking and customer records follow separate product, contractual and legal retention requirements.

Secure account administration

Creating, removing and restoring staff access is handled by authenticated server-side operations. Removing a member of staff blocks their access to that business.

Customer and booking records are handled separately in accordance with the applicable privacy and retention requirements. Browser clients cannot create privileged system accounts or promote their own roles.

Shared security responsibilities

The platform provides technical controls, but each customer also has an important role in protecting data. Businesses should:

• use strong, unique passwords and protect access to email accounts used for password recovery;
• grant staff only the venues and features required for their work;
• remove staff access promptly when employment or responsibilities change;
• protect shared devices with the device's operating-system lock and keep browsers and operating systems current;
• review access to the connected Stripe account and complete Stripe's security and compliance tasks; and
• report unexpected account activity or suspected data exposure promptly.

Ongoing security work

Client Reservation applies a least-privilege and defence-in-depth approach, but security is an ongoing process rather than a one-time feature. Rules, server endpoints, provider configuration and access flows are reviewed and updated as the service evolves.

Questions about security, privacy, data location, retention, subprocessors or a customer-specific security questionnaire can be sent to the Client Reservation support team.