Trust & Security

Draft for review. Items marked [CONFIRM] are unverified, and the insurance section describes cover that must be purchased before it can be stated as fact. See the notes at the end before publishing.

At a glance

• Card details never reach AtTable's servers. They go directly to the payment provider.
• Guests can order without creating an account, so there is less personal data to lose.
• All access is role-based, logged, and scoped to a single organisation.
• We publish our full sub-processor list, including where each one is located.
• We do not hold ISO 27001, SOC 2 or Cyber Essentials, and we do not claim to.
• We do not yet offer multi-factor authentication on staff accounts.

We would rather tell you the last two up front than have you find them in a questionnaire.

1. What we hold

AtTable holds operational data for hospitality venues: menus, orders, table sessions, bookings, payments and refunds, stock and supplier records, and staff shift data. Personal data within that is mostly Guest contact details for bookings and delivery, and staff account records.

We do not hold card numbers, expiry dates or security codes. We do not hold staff bank details or payroll data.

Full detail of the categories is in Annex I of the Data Processing Agreement.

2. Hosting and data residency

• Database and authentication — managed Postgres on Supabase, in the European Economic Area (Ireland) [CONFIRM production region].
• Web application — Vercel. Serverless functions execute in the United States (US East). Requests carrying personal data pass through that region on their way to the EEA database.
• Application programming interface — Railway. Region: [CONFIRM].
• Product analytics — PostHog EU Cloud.

Where processing takes place outside the UK, we rely on UK adequacy regulations or the ICO's International Data Transfer Addendum, supported by a transfer risk assessment. The location and safeguard for every sub-processor is listed in Annex III of the DPA.

We are not able to offer UK-only or EU-only data residency as a contractual commitment today. If that is a hard requirement for you, tell us before you contract.

3. Access control

• Role-based permissions. Owners, admins, managers, servers, kitchen and crew each see only what their role requires. Refunds, payment provider connection and team management are restricted to owner, admin and manager.
• Tenant isolation. Every data path is scoped to the requesting organisation. Probing another organisation's record identifiers returns "not found" rather than "forbidden", so identifiers cannot be enumerated across customers.
• Row-level security is enabled on all application tables as a backstop behind the application's authorisation layer.
• Staff and admin identification codes are stored as salted scrypt hashes and compared in constant time. Account passwords are held by our authentication provider and never stored by us.
• Compromised-password screening against known breach corpora is enabled on all environments.
• IP allowlisting is available for organisations that want to restrict access to their own networks.
• Impersonation of a customer account by our support staff is possible for troubleshooting, is restricted to named personnel, and is written to an immutable audit log every time.

Multi-factor authentication is not currently available on staff accounts. It is on our roadmap. We will not tell a questionnaire otherwise.

4. Encryption

• In transit — TLS on every connection, with HTTP Strict Transport Security enforced on the web application.
• At rest — provided by our database and storage sub-processors.
• Application layer — payment provider access credentials are separately encrypted with AES-256-GCM using authenticated encryption and a per-record nonce, so a database copy alone does not yield working credentials.
• Log redaction — an enforced denylist keeps card numbers, security codes, bank details and national identifiers out of application logs.

5. Payments and card data

Card details are entered into fields hosted and served by the payment provider — Stripe, Square or Clover online, or the physical terminal for card-present payments. Those fields sit in the provider's own frame and are not reachable by our application.

Our servers receive a provider-issued token and a transaction reference. No column for a card number, expiry date or security code exists anywhere in our database. Strong customer authentication challenges happen between the Guest's browser and the provider.

For online payments the venue is the merchant of record on its own connected account. Money settles to the venue. AtTable does not hold customer funds.

The effect is that cardholder data stays inside the payment provider's environment and our systems remain outside cardholder data scope. We do not hold a PCI DSS certification and do not claim one — if you need a formal scope determination, your acquirer issues it.

6. Monitoring and audit

• Access to personal data is logged with the accessor, the category of data, the reason, the IP address and the user agent.
• Administrative actions, billing changes and every movement of money including refunds are written to immutable audit logs.
• Consent changes are appended to a consent history by database trigger, so the record cannot be quietly rewritten.
• Application errors and performance are monitored continuously, configured not to transmit personally identifying information by default.
• Rate limiting is applied to authentication, payment, refund, booking-code and receipt-lookup paths, backed by a shared store so limits hold across instances.
• Inbound webhooks from payment and integration providers are cryptographically signature-verified against the raw request body before anything is processed.

7. Resilience

• Automated backups with point-in-time recovery on the managed database. Retention: [CONFIRM].
• Idempotency keys prevent a retried payment or refund from being processed twice.
• Development, staging and production are separate environments. Production personal data is not copied into development or staging.
• Availability targets and service credits are contractual for customers on a Master Service Agreement. See Schedule 1 of the MSA.

8. Secure development

• Automated pre-deployment checks for database privilege regressions, row-level-security coverage, cross-tenant access defects and schema drift.
• Dependencies are kept current and monitored for known vulnerabilities.
• Least-privilege access to production, limited to named personnel.

[CONFIRM — the pre-deployment checks are implemented but are not currently enforcing on every deployment path. Do not describe them as gating until that is fixed.]

9. Security assessment

An authorised security assessment of the platform was completed in August 2026, covering authorisation, tenancy isolation, database privileges and mail authentication.

It found genuine issues, including database-level permissions that were broader than intended. All findings were remediated and independently re-verified, and controls were added to the deployment process to catch the same class of defect in future.

Log review over the available window found no evidence that the issues had been exploited. We will not state more strongly than that: the log retention window did not cover the entire period, so absence of evidence is what we have, and we would rather say so than overstate it.

A summary of the assessment and the remediation is available under NDA. Email security@attable.io.

10. Sub-processors

We publish the complete list, with location and safeguard, in Annex III of the Data Processing Agreement. It currently includes Supabase, Vercel, Railway, Stripe, SumUp, Square, Clover, Resend, Cloudinary, PostHog, Sentry, OpenAI, Anthropic, Google and Companies House.

Customers get 30 days' notice before we add or replace a sub-processor, with a right to object on reasonable data protection grounds.

11. Reporting a vulnerability

Email security@attable.io. Tell us what you found, how to reproduce it, and how to reach you.

We will acknowledge within 2 business days, keep you updated, and will not pursue legal action against anyone who researches in good faith, avoids privacy violations and service degradation, and gives us reasonable time to fix the issue before disclosing it.

We do not currently run a paid bug bounty, but we will credit you if you would like us to.

12. Incident response

We maintain a documented incident response process. Where a personal data breach affects a customer's data, we notify that customer without undue delay and within 48 hours of becoming aware, with the information they need for their own regulatory notification. Contractual detail is in clause 10 of the DPA.

Where we are the controller — our own account, billing and security data — we notify the ICO within 72 hours where the breach is likely to result in a risk to people's rights, and affected individuals where the risk is high.

13. Certifications

We hold no third-party security certification at present. Specifically, we do not hold and do not claim ISO/IEC 27001, SOC 2 Type I or Type II, Cyber Essentials, Cyber Essentials Plus, or PCI DSS certification.

What we can give you instead: this page, a completed security questionnaire, the DPA with its full sub-processor list and technical measures, and the August 2026 assessment summary under NDA.

14. Insurance

[CONFIRM — this section must not be published until the policies are bound. See the notes below.]

AtTable maintains cyber liability and professional indemnity insurance with a reputable insurer. Cover includes data breach response and notification costs, third-party liability for loss of data, business interruption arising from a security incident, and regulatory defence costs.

• Cyber liability: £[AMOUNT] per claim, £[AMOUNT] aggregate
• Professional indemnity: £[AMOUNT] per claim
• Public liability: £[AMOUNT] per claim
• Employers' liability: £5,000,000

A certificate of insurance is available to customers on request from legal@attable.io. Insurance obligations are contractual for customers on a Master Service Agreement — see clause 10 of the MSA.

15. Contact

• Security and vulnerability reports: security@attable.io
• Data protection: privacy@attable.io
• Questionnaires, DPAs and certificates: legal@attable.io
• Post: SAVV8 LIMITED, 71-75 Shelton Street, Covent Garden, London, WC2H 9JQ, United Kingdom

---

Notes for AtTable — remove before publishing

1. Do not publish section 14 until the insurance is actually bought. Cyber liability and professional indemnity are products you buy from a broker. Stating cover you do not hold on a public trust page is a misrepresentation that a customer would rely on, and it is exactly the representation an insurer would later use to decline. Either bind the policies and fill in the limits, or delete section 14 and say cover is being arranged.
2. Confirm the production Supabase region, Railway's region, the Sentry region and the backup retention period.
3. Fix or remove the pre-deployment checks claim in section 8 — the checks exist but are not enforcing on every deployment path.
4. Resolve the ip-api.com dependency before publishing the sub-processor list, and either remove it or contract for it. It is listed in the DPA annex as under review.
5. Confirm HSTS is actually set in production. It is not configured in the repository and is presumed to be a hosting platform default. Verify with a response header check before claiming it in section 4.