Security & Data

Version 1.0 · Last updated: 9 August 2026 · Written for the person who has to sign this off.

If you are handing a chat assistant your customers' questions, your enquiries and a view of your calendar, you're entitled to know exactly what happens to all of it. This page is the technical answer, in plain English. The legal answer is in the Privacy Policy and the Terms.

Everything below is a description of how the product is actually built today. Where we haven't got something yet, it's in section 10 rather than quietly missing.

1 Encryption

In transit: every request — the widget on your website, your account, our API — travels over HTTPS/TLS. HTTP is redirected, and we send an HSTS header so browsers refuse to downgrade.
At rest: your data sits on encrypted-at-rest infrastructure provided by our host, Render. To be precise about who does what: the encryption is the hosting platform's, not a second layer we've written ourselves on top. We'd rather say that plainly than imply more.
Card details are never encrypted by us because they never reach us — see section 6.

2 Accounts and sign-in

Passwords are stored as scrypt hashes with a per-account salt and compared in constant time. We cannot see your password, and neither can anyone who obtained the file.
New and changed passwords are checked against a length-and-variety policy and a blocklist of the passwords attackers try first.
Sign-in is rate-limited per IP address, and an individual account locks for 15 minutes after 8 failed attempts, so guessing one specific customer's password is not practical.
Sessions are HMAC-signed tokens in httpOnly cookies: 12 hours idle, 30 days maximum. If you think a device is compromised, changing or resetting your password immediately invalidates every existing session, everywhere, including the one on that device.
Email addresses are verified before an account can be used, and password resets are single-use and time-limited.
Administrative access to our own systems is granted by an environment allowlist, not by a flag in the database — so nothing that can be edited through the product can grant anyone admin rights.

3 Separation between businesses

Every business on Dave on Duty has its own separate data store: its own knowledge base, conversations, leads, bookings and settings. Every request is checked against the signed-in account before anything is read or written, so one customer cannot reach another's data by changing an id in a URL. Our own testing includes deliberately attempting exactly that.

Where a business connects WhatsApp or Messenger, the connection is verified against Meta and bound to that business, specifically so that someone pasting another company's page details cannot intercept their messages.

4 What the AI sees, and what it never does

Replies are generated by Claude, made by Anthropic. The message, the conversation so far and the relevant part of your knowledge base are sent to Anthropic's API to produce the answer.
Your data is not used to train any model — not Anthropic's, not ours, not anyone's. Anthropic does not train on data submitted through its API, and we have no model of our own to train.
We never sell personal data, in any form, to anyone.
Dave answers from your material only. When the answer isn't there he is built to say so and hand the question to you rather than guess. No AI can be promised perfect — which is precisely why the designed failure mode is a handover to a human, and why every conversation is logged for you to read.
For allergen, hygiene, medical and safety questions he quotes your own wording and tells the customer to confirm with your team. He is instructed never to tell anyone something is safe.

5 What Dave is allowed to touch

The most reassuring thing about Dave's integrations is how narrow they are. He has no general access to your business — only the specific connections you switch on.

📅 Your calendar: read-only

A connected Google, Outlook or Calendly calendar is read through a read-only busy feed, for one purpose: hiding times you're already busy so Dave never offers a slot you can't do. Nothing is ever written to your calendar. Bookings are recorded in Dave's own system and emailed to you and the customer.

✉️ Email: two addresses only

Dave can email the business owner and the customer in the conversation. That's it. He has no ability to email an arbitrary address, so a visitor cannot use your assistant to send mail to someone else.

📦 Stock & orders: what you upload

On Dave Max he reads the product and order data you provide or the shop connection you authorise. He reads it to answer questions — he doesn't place orders, take payments or change your stock.

🌐 Your website: public pages

The initial scan and the weekly refresh read the public pages of your site, the same ones any visitor or search engine can see. Nothing behind a login.

If you'd like your widget locked to your own domain so the assistant only answers on your website, ask us and we'll set it — it's enforced server-side.

6 Payments

Card payments and subscriptions are handled by Stripe, a PCI-DSS Level 1 payment processor. Card numbers never reach our servers — we never see them, store them or transmit them, and changing a card or cancelling happens inside Stripe's own portal. We hold a customer reference and the plan you are on, nothing more.

We also never take money automatically. There is no card on file during your free trial, top-ups require your explicit approval each time, and no allowance is ever auto-charged.

7 Getting your data out, and deleting it

Export, any time, in one click: Plan & billing → Download all my data gives you a single JSON file containing your settings, knowledge sources, conversations, leads, bookings and enquiries. No ticket, no waiting, no export fee.
Deletion: when an account closes, its data is kept for 90 days so you can come back or take a copy, then deleted. Ask sooner and we delete it sooner.
Retention of everything else — transcripts, live conversation memory, support messages, accounting records — is set out row by row in Privacy, section 11.
It's your data, not ours. The conversations, leads and bookings belong to your business. We hold them on your instructions and use them for nothing of our own.

8 Application security

A Content-Security-Policy on every response, plus HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy. Foreign scripts, framing and base-tag hijacking are blocked at the browser.
Chat and public endpoints are rate-limited, and every plan has a conversation allowance, so nobody can run up your bill or exhaust the service by hammering the widget.
Visitor input is escaped before it is rendered, and business settings are constrained to an allowlist of fields — a customer cannot promote their own plan or inject content by editing a request.
Dependencies are audited on every single push: our build fails if any dependency carries a high-severity advisory. That gate is why we upgrade libraries the week an advisory lands rather than the quarter.
A test suite runs on every push, and an automated check every hour confirms the live service is up and answering.
We publish a security.txt so researchers know where to send a problem.

9 If something goes wrong

If a breach affects personal data and is likely to risk people's rights, we will report it to the ICO within 72 hours and tell affected customers without undue delay — including what happened, what data was involved and what we're doing about it. As a processor for your visitors' data, we tell you promptly so you can meet your own obligations, because that clock is yours, not ours.

We would rather write an awkward email than a quiet one.

10 What we haven't got yet

The honest bit

Security pages usually only list wins. Here is what a careful buyer should know we don't have, because you'd find out eventually and it's better you hear it from us:

No SOC 2 or ISO 27001 certification. Those are serious, expensive audits and we are a new, small business. We haven't done them, and we won't imply otherwise with a badge.
No third-party penetration test yet. We run our own security testing — access control, privilege escalation, cross-tenant access, injection and prompt-injection attempts — before releases, and we'd welcome an independent test. If your organisation requires one before signing, talk to us.
Support is Monday to Friday, UK time. There is no 24/7 on-call rota. The service is monitored automatically around the clock; the humans are not.
We're small. That's a genuine security trade-off, in both directions: a very short list of people can touch production, and there is no large team to spread the load. You should weigh both.

11 Paperwork for your compliance file

Data-processing terms (UK GDPR Article 28): included in the Terms, Annex A — subject matter, duration, instructions, confidentiality, security, sub-processors, assistance, deletion and audit. They apply automatically to every customer. Need it as a separate signed document for your records? Email us and we'll send one.
Sub-processor list: Privacy, section 9 — the one to reproduce in your own privacy notice. We update that page before we ever add to it.
International transfers: Privacy, section 10 — standard contractual clauses plus the UK International Data Transfer Addendum.
Wording for your own privacy notice covering the chat assistant: ask and we'll send you a paragraph you can paste in.
Your regulator: the UK Information Commissioner's Office, whom you may complain to at any time.

12 Reporting a security problem

Found something? Please tell us before telling the internet, and we will not be difficult about it. Email support@daveonduty.co.uk with "SECURITY" in the subject, or use the details in our security.txt. We'll acknowledge, fix what needs fixing, and credit you if you'd like the credit.

Anything on this page you want explained further, or evidenced, ask — Help & support.