Trust and Security

1. Where data lives

Our application, its databases, object storage and backups run on Amazon Web Services in the eu-west-2 (London) region. Three things sit outside it, and all three are in the table below: inbound email is received by Amazon SES in eu-west-1 (Ireland); the model that writes a chat answer is called through an EU cross-region inference profile, so the inference itself may be served from any AWS region in that profile; and a WhatsApp message passes through Meta's WhatsApp Business Platform before it ever reaches us. The embedding model that indexes a customer's content is not on a cross-region profile and runs in eu-west-2.

We will not tell you that data never leaves the United Kingdom, because it would not be true. What we can tell you is that it does not leave AWS to reach a model provider. Two different models are involved and they are not in the same place. The one that writes the answers is Anthropic's Claude, called on Amazon Bedrock through an EU cross-region inference profile — its identifier begins eu. — so a request may be served from any AWS region covered by that profile. The one that turns text into vectors, so that a question can find the right page, is Amazon's own Titan Text Embeddings V2, which is not on a cross-region profile and runs in eu-west-2. Both run on Bedrock inside our own AWS account, which is why Anthropic is not a sub-processor of ours. AWS is.

If UK-only or EU-only residency is a condition of your buying, raise it before you sign rather than during an audit. It is a deployment decision, and we would rather have that conversation early.

2. Sub-processors

These are the third parties that process customer data on our behalf. Where the processing-location column does not name a region, it is because we have not confirmed one in writing — or, in one case, because we cannot establish it at all. We would rather leave the gap visible than print a guess on a page a security team is going to rely on.

We give at least 30 days' notice before adding or replacing a sub-processor, so that there is time to object. To be told when this list changes, email privacy@puglieseweb.com and ask to be added to the sub-processor notice list.

3. We do not train models on your content

Customer email content, chat and WhatsApp messages, and content crawled from customer websites are not used to train or fine-tune any model, ours or anyone else's. That is not only our undertaking: inference runs on Amazon Bedrock, and AWS's terms for Bedrock are that inputs and outputs are not used to train the underlying models and are not shared with the model provider. We do not sell that content, share it, or otherwise make it available to anyone for that purpose.

Content is sent to the model only in order to answer the message in front of it, and only for as long as that request takes. Messages from the website widget additionally pass through a Bedrock guardrail — a prompt-attack and content filter — before the model sees them.

4. Encryption

Data is encrypted at rest everywhere with AES-256, and in transit with TLS on the web and API endpoints: the CDN in front of the website redirects a plain-HTTP request to HTTPS, and the APIs answer over TLS only. One endpoint is not like the others, and we would rather say so than let you read "every public endpoint" and assume it covers this: inbound email. Our SES receipt rule accepts opportunistic TLS — a sending mail server that offers TLS gets it, and one that offers none is still accepted rather than refused — so a message can reach us over a hop we do not control and cannot encrypt. That is the ordinary trade-off for receiving mail from the whole internet. Encryption at rest is not all under one key either, and we would rather be precise than tidy: our DynamoDB tables are encrypted with keys held in AWS Key Management Service and managed by AWS, while our S3 buckets — inbound email and its attachments, and images a visitor uploads — are encrypted with keys S3 manages. Backups inherit the encryption of the store they are taken from. We do not operate a customer-managed key today, and we do not claim one.

That is the whole claim, stated without adjectives. "Bank-grade" and "military-grade" are marketing terms with no technical meaning, and their presence on a security page tells a reader nothing they can verify.

5. Retention and deletion

How long each store keeps what it holds. The windows differ, and one number covering all of them would be simpler and wrong:

• Content crawled from a customer's website has no expiry date. It is replaced when the site is crawled again — a page that has gone from the site is archived on the next complete crawl — and it is deleted when the account is deleted, which erases that customer's content, crawl configuration and crawl history together.
• Conversation transcripts from the chat widget and from WhatsApp expire 90 days after they are written. Three things qualify that number, because on its own it would overstate what we do. The expiry is stamped on each record as it is written, so it governs the records written from now on: a conversation stored before the window was set — or, on WhatsApp, before this channel stamped one at all — keeps whatever it was given at the time, and no automatic process goes back over the records already written. Conversations created from our own staff portal rather than by a visitor carry no expiry stamp. And a conversation an operator pins is deliberately exempt, which is how somebody keeps one that matters: pinning removes the expiry from the conversation record, and unpinning sets it again to 90 days from that moment. Be precise about what a pin holds, though — it clears the expiry on the conversation record and on replies written while it is pinned, and the messages already stored under it keep the expiry date they were given when they were written.
• Email correspondence held in our inbox is kept for 24 months after the last activity on the thread, and a daily sweep then deletes it outright — the thread, its messages and its attachments together. One exemption: a compliance hold recorded on the thread keeps it until the date on the hold passes, or indefinitely while a legal hold is live. The raw message that Amazon SES stores when it is received expires after 30 days.
• On a written deletion request we delete within 30 days and confirm in writing once it is done. A deleted record can still be present in point-in-time backups for up to 35 days afterwards, which is the backup window we keep; those copies expire on their own and the application cannot read them.

6. Breach notification

If we become aware of a personal data breach affecting a customer's data, we notify that customer without undue delay and in any event within 72 hours of becoming aware of it. The first notice carries what we know at the time — what happened, which data is involved, and what we are doing about it — and we follow it with updates as the picture firms up. We do not wait for the investigation to finish before telling you.

7. Authentication and access control

• Customer sign-in is handled by a single Amazon Cognito user pool, with email and password or sign-in with Google or Apple.
• Authorisation is scoped per tenant: the token carries the tenant and the role it was issued for, and the API checks it on every request.
• Nothing deploys to production with a long-lived AWS key: the pipelines assume a deployment role through GitHub's OIDC provider, and the role's trust policy names the repositories allowed to assume it. Human administrative access is limited to named individuals — that one is a matter of how we run the account rather than a control we can show you in code, so weigh it accordingly.
• Management actions taken against our production AWS account are recorded in AWS CloudTrail by the organisation's trail, which delivers into a separate log-archive account rather than into the account being audited.

8. The crawler

Ema reads a customer's own website so that it can answer from it. A crawl runs only after that customer has proved control of the domain — with a DNS TXT record, a token file served from the site, a token in the homepage, or an attestation recorded by a member of our staff where the authorisation is held on paper. The crawler's identity, its rate limits, what it does when robots.txt cannot be read, and every way to block it are documented in full here: EmaIngestBot.

9. Reporting a vulnerability

Our contact details and disclosure preferences are published at /.well-known/security.txt. Report privately to security@puglieseweb.com and give us a reasonable period to fix the issue before disclosing it.

That commitment is not decoration. The Computer Misuse Act 1990 makes unauthorised access to a computer a criminal offence and offers no public-interest defence for security research, so a researcher in the United Kingdom takes on real personal exposure simply by telling us that our service is broken. If we do not say plainly that we will not pursue them, the rational thing for them to do is stay quiet — which leaves the flaw in our product. We would much rather hear about it.

/.well-known/security.txt

10. Insurance

PuglieseWeb LTD maintains professional indemnity and cyber liability insurance appropriate to the services we provide.

11. Contact

For questions about anything on this page, or a security questionnaire you need completed: