Data Processing Agreement

1. Scope and roles

1.1This Data Processing Agreement ("DPA") forms part of the agreement between PuglieseWeb LTD ("we", "us", "our") and the business that uses our services ("you"). It is incorporated into the version of our Terms of Service accepted with it; the current Terms are always available here: Terms of Service (https://www.puglieseweb.com/terms).

1.2You accept this DPA together with the Terms, and it does not need to be signed separately. For a business using Evrella, your organisation's owner accepts both in the console, for the versions shown there; for our other services, you accept them when you create an account. This version applies from when it is accepted; until then, any earlier version accepted for your organisation continues to apply. If we process Customer Personal Data for your organisation before any version of this DPA has been accepted for it, this version governs that processing until a version is accepted. It changes only as section 14 describes.

1.3This DPA applies to the personal data we process on your behalf when we provide our software services to you, including Evrella — for example the messages your website visitors send your assistant, the contact details they choose to leave with you, and the appointments they book ("Customer Personal Data").

1.4For Customer Personal Data you are the controller and we are your processor. Where we process personal data for our own purposes — your account and sign-in details, billing, the record of your acceptance of the Terms and this DPA, and keeping our services secure and working — we are the controller, this DPA does not apply, and that processing is described in our Privacy Policy (https://www.puglieseweb.com/privacy).

1.5If you accept the Terms on behalf of a business, you confirm that you are authorised to bind it. If you set up or manage an organisation for another business — as an agency or reseller, for example — you confirm that you hold that business's authority to give the instructions in this DPA on its behalf.

2. Definitions

2.1In this DPA: (a) "Data Protection Law" means the UK GDPR and the Data Protection Act 2018 and, where they apply to the processing, Regulation (EU) 2016/679 (the "EU GDPR") and the laws that implement or supplement it. (b) "Controller", "processor", "data subject", "personal data", "personal data breach" and "processing" have the meanings given to them in Data Protection Law. (c) "Services" means the services we provide to you under the Terms. (d) "Sub-processor" means a third party we engage to process Customer Personal Data. (e) "Standard Contractual Clauses" means the clauses annexed to Commission Implementing Decision (EU) 2021/914.

3. Your instructions

3.1We process Customer Personal Data only on your documented instructions, unless the law we are subject to requires otherwise — in which case we tell you before processing, unless that law forbids it. Your instructions are the Terms, this DPA, and the choices you make when you set up and use the Services: for example which website your assistant answers on, what it may read, where enquiries are sent and whether it takes bookings.

3.2We tell you promptly if, in our opinion, an instruction infringes Data Protection Law.

3.3You are responsible for the lawfulness of the processing you instruct: for having a lawful basis for it, for telling the people whose data it is — your website's privacy notice should mention the assistant and what happens to what people write in it — and for not setting the Services up to ask for special categories of personal data or for children's data.

4. Details of the processing

4.1Subject matter and duration: the provision of the Services to you, for as long as we provide them and until Customer Personal Data is deleted or returned under section 12.

4.2Nature and purpose: receiving, storing and answering messages; generating answers with AI models from the content you approve; capturing the enquiries and bookings people make, summarising them and passing them to you; and protecting the Services against abuse — in each case only to provide the Services to you. We do not use Customer Personal Data to train or fine-tune AI models, and we do not sell it.

4.3Data subjects: (a) Visitors to your website who use your assistant. (b) People who contact your business through a channel you connect to the Services, such as WhatsApp or email. (c) People who leave their contact details with you or book an appointment with you. (d) Anyone whose personal data appears in the website content or documents you ask us to read.

4.4Categories of personal data: (a) The content of messages and conversations, including anything a person chooses to write or send, such as an image. (b) Contact details and answers a person gives: for example their name, email address, phone number, their message and their answers to the questions you set. (c) Appointment details: the date, time, service booked and any notes. (d) Technical data used to deliver and protect the Services: a pseudonymous visitor identifier, IP address, browser and device information, and the address of the page a message was sent from. (e) Personal data contained in the website content and documents you ask us to read. (f) Records of how an enquiry or booking was handled, such as when it was received and whether it was answered, and the summary of an enquiry that an AI model writes for you.

4.5Special categories of personal data: none are required, and you must not set the Services up to ask for them. A person may still volunteer them in what they write; we process such data only as part of the messages that carry it.

5. Confidentiality

5.1Everyone we authorise to process Customer Personal Data is bound by a duty of confidentiality. Our staff access it only as far as they need to in order to provide, support and secure the Services, including in the support sessions described in section 4 of the Terms.

6. Security

6.1We implement and maintain appropriate technical and organisational measures to protect Customer Personal Data, as Article 32 of the UK GDPR and the EU GDPR requires. The measures in place — where data is hosted, encryption, retention and deletion, and access control — are described in the sections of our Trust and Security page on those subjects. Those sections, and the page's list of Sub-processors, form part of this DPA as sections 16 to 20. The page itself is here: Trust and Security (https://www.puglieseweb.com/trust).

6.2We may change those measures as technology and threats change, but we will not reduce the overall level of protection they give Customer Personal Data.

7. Sub-processors

7.1You give us general authorisation to engage Sub-processors. The list of our current Sub-processors, the service each provides and where it processes data forms part of this DPA and is published here: Trust and Security (https://www.puglieseweb.com/trust#sub-processors).

7.2We give at least 30 days' notice before a new or replacement Sub-processor starts processing Customer Personal Data: we update that list and email your organisation's owner, naming the Sub-processor and the service it will provide. We also send the notice to anyone else you ask us to, such as your data protection officer; to arrange that, write to privacy@puglieseweb.com.

7.3You may object to a new Sub-processor on reasonable data protection grounds by replying to the notice or by writing to privacy@puglieseweb.com, preferably within the notice period so that we can consider your objection before the change takes effect. We will discuss your objection in good faith. If we cannot reasonably avoid using that Sub-processor to process Customer Personal Data, you may stop using the Service concerned, or end your agreement with us, by telling us, and we will refund any fees you have paid in advance for the period after it stops.

7.4We impose on each Sub-processor, by contract, data protection obligations that give Customer Personal Data the same protection as this DPA, and we remain responsible to you for how each Sub-processor performs them.

8. International transfers

8.1We host the Services mainly in the United Kingdom. Some Sub-processors process data in other countries, as the list in section 7 shows.

8.2Where Customer Personal Data is transferred outside the United Kingdom — or, for data subject to the EU GDPR, outside the European Economic Area — to a country that is not covered by adequacy regulations or an adequacy decision, the transfer is made under a safeguard that Data Protection Law recognises, such as the Standard Contractual Clauses together with the UK International Data Transfer Addendum.

8.3Where you are established in the European Economic Area, transfers of Customer Personal Data from you to us in the United Kingdom rely on the European Commission's adequacy decision for the United Kingdom while one is in force.

8.4If no such decision is in force, the Standard Contractual Clauses, module two (controller to processor), are incorporated into this DPA for those transfers, with you as data exporter and us as data importer. Clause 7 does not apply; option 2 of clause 9 applies, with the notice period in section 7; the optional wording in clause 11 does not apply; the competent supervisory authority under clause 13 is the one for your establishment; clauses 17 and 18 choose the law and the courts of the Member State in which you are established or, if that law does not allow for third-party beneficiary rights, those of Ireland; and Annexes I to III are completed by sections 1 and 4 of this DPA, by sections 16 to 20 of this DPA and by the list of Sub-processors in section 17. If the clauses conflict with this DPA, the clauses prevail.

9. Requests from data subjects

9.1Taking into account the nature of the processing, we help you by appropriate technical and organisational measures, as far as possible, to respond to people exercising their rights under Data Protection Law. If a person contacts us directly about Customer Personal Data, we do not answer the request ourselves, other than to tell them to contact you, and we pass it on to you without undue delay.

10. Personal data breaches

10.1We notify you without undue delay, and in any event within 72 hours, after becoming aware of a personal data breach affecting Customer Personal Data. We send the notice to your organisation's owner. It carries what we know at the time — the nature of the breach, the categories and approximate number of people and records concerned, its likely consequences, and the measures taken or proposed — and we follow it with further information as it becomes available.

10.2We take reasonable steps to contain and investigate the breach and to reduce its effects. Notifying you of a breach is not an admission of fault or liability.

11. Assistance, records and audits

11.1Taking into account the nature of the processing and the information available to us, we give you reasonable assistance with data protection impact assessments, and with prior consultation of a supervisory authority, that relate to the Services.

11.2We keep a record of the processing we carry out on your behalf, and we make available to you the information necessary to demonstrate compliance with this DPA — including our Trust and Security page and answers to reasonable security questionnaires.

11.3If that information is not enough to demonstrate compliance, or a supervisory authority requires it, you or an independent auditor you appoint may audit our compliance with this DPA: once in any 12 months unless a personal data breach has occurred, on at least 30 days' written notice, during business hours, without disrupting the Services, under a duty of confidentiality, and at your own cost. An auditor must not be our competitor.

12. Deletion and return

12.1When you close your account, or we stop providing the Services to you, we wait 30 days before deleting Customer Personal Data, so that a closure made by mistake can be undone, and then delete it within a further 30 days, unless the law requires us to keep it. We confirm the deletion in writing if you ask. Until it is deleted, you may ask us in writing for a copy of it in a commonly used, machine-readable format.

12.2While you use the Services, Customer Personal Data is kept and deleted as described in the retention section of our Trust and Security page. A deleted record can remain in backups for up to 35 days afterwards; those copies expire on their own and the Services cannot read them. The retention section is here: Trust and Security (https://www.puglieseweb.com/trust#retention).

12.3To ask for deletion or a copy, write to privacy@puglieseweb.com.

13. Liability and precedence

13.1Our liability arising out of or in connection with this DPA is subject to the limitations and exclusions of liability in section 10 of the Terms, including the separate limit for data protection claims in section 10.6 of the Terms, to the extent Data Protection Law allows.

13.2If this DPA conflicts with the rest of the Terms, this DPA prevails as regards the processing of Customer Personal Data.

14. Changes and governing law

14.1We may change this DPA only in the way section 13 of the Terms describes: we email your organisation's owner at least 30 days before a material change takes effect, and a material change applies to you only once your organisation's owner accepts it; continuing to use the Services is not acceptance. We will not make a change that reduces the protection this DPA gives Customer Personal Data unless Data Protection Law or a supervisory authority requires it. Two kinds of new version are not material changes: one that records a new or replacement Sub-processor, which follows section 7 instead and takes effect when the notice period there ends; and one that only updates the description of our security measures under section 6.2.

14.2This DPA is governed by the law of England and Wales, like the Terms, except where Data Protection Law or the Standard Contractual Clauses require otherwise. Which language version of this DPA is authoritative is decided by section 15.2 of the Terms.

15. Contact

15.1To ask about this DPA, to object to a Sub-processor, to have Sub-processor notices sent to another address as well, or to ask for Customer Personal Data to be deleted or returned, write to:

15.2PUGLIESEWEB LTD Registered office: 10 Upper Wheatfield, Hook, England, RG27 9YR privacy@puglieseweb.com Company No. 17078772, registered in England and Wales

16. Trust and Security: Where data lives

16.1Our application, its databases, object storage and backups run on Amazon Web Services in the eu-west-2 (London) region. Some things sit outside it, and all of them 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; a WhatsApp message passes through Meta's WhatsApp Business Platform before it ever reaches us; and a phone call Evrella answers is carried by Twilio in Ireland and turned into text by AssemblyAI in the European Union, while Cartesia turns the text of Evrella's replies into speech in the United States. The server that connects a call to those services runs on AWS in eu-west-2. The embedding model that indexes a customer's content is not on a cross-region profile and runs in eu-west-2.

16.2We 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 the models that write answers and index content. 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.

17. Trust and Security: Sub-processors

17.1These 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 because we cannot see where the provider processes the data. That gap is in what we know, not in the protection: each provider processes the data under its own data processing terms, and where it sends the data to a country without adequacy, those terms provide a transfer safeguard that UK and EU data protection law recognise, such as adequacy under the EU–US Data Privacy Framework and its UK Extension for a certified recipient, or standard contractual clauses with the UK Addendum. We would rather leave the gap visible than print a guess on a page a security team is going to rely on.

17.2Amazon Web Services EMEA SARL Service: Cloud hosting, compute, databases, object storage and backups; inbound and outbound email (Amazon SES); chat inference and text embeddings (Amazon Bedrock). The chat model is Anthropic's Claude and the embedding model is Amazon's Titan; both run inside our own AWS account, which is why Anthropic is not a sub-processor of ours Processing location: eu-west-2 (London), United Kingdom, with two exceptions: received mail and its raw storage are in eu-west-1 (Ireland), and chat inference goes through an EU cross-region profile, so a request may be served from any AWS region within it

17.3Meta Platforms (WhatsApp Business Platform) Service: Carriage of WhatsApp messages. Every WhatsApp message a visitor sends us, and every reply we send back, passes through Meta's platform. It is not involved in the chat widget or in email Processing location: Not confirmed. The messages traverse Meta's own infrastructure and we have no visibility of where that processing happens; see the note above the table

17.4Stripe Service: Payment processing when someone buys through the chat widget or the portal. Stripe receives the payer's email address and takes the card details on its own checkout page; it receives no conversation content and nothing crawled from a website Processing location: Not confirmed — see the note above the table

17.5Sentry Service: Application error tracking and diagnostics in the customer portal and the product applications. It is not loaded on this website Processing location: European Union. Sentry's data region is fixed when the organisation is created and cannot be changed afterwards; ours is the EU region

17.6Twilio Service: Carriage of the phone calls Evrella answers on a business's Evrella number, and of the onward call when Evrella puts a caller through to the business at the caller's request. The caller's voice passes through Twilio to our voice server; Twilio does not record it. Twilio keeps a log of each call: the number calling, the number called, the time and the length. When a business asks for an Evrella number, Twilio also holds the registration details UK rules require for it: the business's name, company number, address and website, and the name, work email and phone number of the person the business authorises Processing location: Calls and call logs: Ireland (Twilio IE1). Number-registration details: United States (Twilio US1)

17.7AssemblyAI Service: Speech-to-text for the phone calls Evrella answers. It receives the caller's voice while the call is happening and returns the text. It keeps neither the audio nor the text afterwards and does not use them to train its models Processing location: European Union (AssemblyAI EU endpoint)

17.8Cartesia Service: Text-to-speech for the phone calls Evrella answers. It turns the text of Evrella's replies into her voice. It receives that reply text only, which can include a caller's name or a booking time, and never the caller's voice Processing location: United States

17.9We give at least 30 days' notice before adding or replacing a sub-processor, so that there is time to object: we email the owner of every customer organisation, and anyone else a customer has asked us to notify. To add an address, email privacy@puglieseweb.com.

18. Trust and Security: Encryption

18.1Data 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.

19. Trust and Security: Retention and deletion

19.1How long each store keeps what it holds. The windows differ, and one number covering all of them would be simpler and wrong: (a) 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. (b) Conversation transcripts from the chat widget, from WhatsApp and from phone calls expire 180 days after they are written, or 365 days on the Business and Custom plans. Three things qualify those numbers, because on their own they 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 180 days from that moment, or 365 days on the Business and Custom plans. 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. A call recording, which a business may switch on for its calls, is deleted after the 30, 60 or 90 days the business chooses, and is never kept longer than 90 days. (c) 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. (d) 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.

20. Trust and Security: Authentication and access control

20.1(a) Customer sign-in is handled by a single Amazon Cognito user pool, with email and password or sign-in with Google or Apple. (b) 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. (c) 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. (d) 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.