Data Processing Agreement

Effective date: 12 October 2026  ·  Last updated: 12 October 2026

This Data Processing Agreement ("DPA") is between HelpAlive, Inc. ("HelpAlive", "we", "us") and the company or organisation that has accepted the HelpAlive Terms of Service ("Customer", "you"). It explains how we handle your End Users' personal data when we run HelpAlive for you.

1. What this is

• Part of the Terms. This DPA forms part of our Terms of Service (the "Terms"). It applies automatically when you accept the Terms. There is nothing to sign.
• Who it binds. HelpAlive and you. If someone accepts the Terms for a company, it binds that company.
• What it covers. Personal data we process for you as your processor (section 3). Data we handle for ourselves as a controller is covered by our Privacy Policy instead.
• Which document wins. On the processing of personal data, this DPA prevails over the Terms. Where the Standard Contractual Clauses apply (section 16), they prevail over this DPA.
• Law and courts. This DPA is governed by the same law, and disputes go to the same courts, as the Terms (Delaware), except where the Standard Contractual Clauses require otherwise.

2. Definitions

Words defined in the Terms ("Customer", "Customer Data", "End Users", "Service", "assist") mean the same here. A "walkthrough" is the assistant guiding or doing a task for an End User on the page; section 5 of the Terms says when a walkthrough counts as an assist. In addition:

• "Customer Personal Data" means personal data within Customer Data that we process for you to provide the Service. Annex I describes it.
• "Data Protection Laws" means the laws on personal data that apply to that processing, including the EU GDPR (2016/679), the UK GDPR, the Swiss Federal Act on Data Protection ("FADP"), the California Consumer Privacy Act as amended ("CCPA") and other US state privacy laws.
• "Personal Data Breach" means a breach of security that leads to the accidental or unlawful destruction, loss, alteration or unauthorised disclosure of, or access to, Customer Personal Data.
• "Sub-processor" means a third party we engage that processes Customer Personal Data for us.
• "SCCs" means the standard contractual clauses approved by the European Commission in Implementing Decision (EU) 2021/914.
• "UK Addendum" means the International Data Transfer Addendum to the SCCs issued by the UK Information Commissioner, version B1.0.
• "Controller", "processor", "data subject", "personal data", "processing" and "supervisory authority" have the meanings given in the GDPR, or the matching terms in the UK GDPR and the FADP. "Business", "service provider", "personal information", "sell", "share" and "deidentified" have the meanings given in the CCPA.

3. Who does what

• End User data: you are the controller, we are your processor. For Customer Personal Data, you decide why and how it is processed, and we process it for you. Under the CCPA and similar US state laws, you are the business and we are your service provider (section 18).
• If you act for someone else. If you are yourself a processor for a client of yours, we are your sub-processor. You confirm that your client has authorised you to use us on these terms, and you pass its instructions on to us.
• Where we are a controller ourselves. We are an independent controller, not a joint controller with you, for:
  • your staff's account details: names, work emails, sign-in records and team membership;
  • billing details for your workspace;
  • visitors to our website and documentation site, and people we contact about HelpAlive;
  • records we keep to secure the Service and stop abuse, such as sign-in attempts and rate limits.
  Our Privacy Policy describes this processing. De-identified data created from Customer Data is covered by section 11, not by this list.
• Your staff in our dashboard. Our dashboard runs HelpAlive's own script, so we observe your staff's use of it the way the script observes End Users in your app. We do that as controller.
• Your staff in your app. If your staff use your own app while our script is loaded, they are End Users there, and their data is Customer Personal Data.
• The boundary. What End Users type, ask and see in your app is Customer Personal Data, even when a copy of it sits in our server logs. We never treat it as our own.

4. What we process

The Service handles Customer Personal Data in three ways, and treats each one differently. Annex I gives the full description.

A. Usage analytics (always on once the script loads)

Once your app loads our script, it records how End Users use your app:

• pages viewed. Secret-looking parts of the address, and anything after "#", are removed in the browser;
• clicks, with the element's visible label;
• changes to form fields, with the value. Fields the page marks as password, payment card or one-time-code fields, and values shaped like a card number, are blanked;
• form submissions, without values;
• error messages shown on screen, and short excerpts of error replies from your app's own server;
• which elements were on screen;
• custom events you send with track(), as you send them;
• device details, a random browser id, and a visit id that ends after 30 minutes;
• the End User's organisation id and name, and the End User's id, pseudonymised in the browser;
• profile details you choose to pass with identify(): name, email, role, plan and sign-up date.

Before we store these events, automated redaction finds and replaces person names, email addresses, phone numbers, IP addresses, card numbers and US social security numbers in English text. It does not cover ids, page addresses, custom events or End User profile details. It is automated, so it can miss things.

The script never takes screenshots, records the screen, measures keystroke timing or sets cookies.

B. Chat and walkthroughs (only when an End User uses them)

When an End User opens the chat, asks a question or starts a walkthrough, the assistant reads the content of the current page. It does not take a picture of the screen.

• The values shown in form fields are included, except for fields the page marks as password, payment card or one-time-code fields, file-upload and hidden fields, and any value shaped like a card number. For those, the assistant sees only whether they are filled.
• A code typed into a text field the page does not mark is read like any other value.

With the page, the assistant also uses: the End User's question and recent turns of the conversation; the full page address, including its query string; the page title; recent activity during this visit (redacted as section 4A describes); the End User's role, plan and account age, if you provide them; the browser's time zone and local date; and relevant content from your help documents. The email address from the End User's profile is never part of what the AI model receives; an email address or other personal data that is visible on the page, or that the End User types in the chat, can be. The greeting may use their first name.

Apart from the recent activity, this content is not redacted. Automated redaction does not apply to it, because the assistant needs to see the page as it is in order to help. We send it to our AI providers (section 10), and we store chat messages and walkthrough content as they were captured. Only the protected fields listed above are held back.

Our server logs can contain chat messages, walkthrough requests and the page text the assistant read, but not the values typed into form fields. Logs are kept for 30 days.

C. Your help documents

We index the help documents you give us, and the public help pages you ask us to read. We store their text, not the original files, until you remove them. Help documents can contain personal data, such as your staff's names.

5. Your instructions

• We process Customer Personal Data only on your documented instructions, unless a law that applies to us requires otherwise. If it does, we will tell you before we process, unless that law forbids it.
• Your instructions are the Terms, this DPA, and your workspace settings in the dashboard, such as your retention setting. Where you load the script, what you pass to identify() and track(), and the help documents you give us are instructions too.
• For any other instruction, write to support@helpalive.com and we will tell you whether we can follow it.
• We will tell you if, in our opinion, an instruction breaks Data Protection Laws. We do not otherwise check your instructions for legal compliance.

6. Your responsibilities

You are responsible for:

• Lawful basis and notice. Having a lawful basis for the processing in Annex I, and telling your End Users that your app uses HelpAlive and what that means for their data. That includes telling them that an AI assistant reads their page (including the values shown in form fields), that this goes to our AI providers, and that your admins can read their chats and walkthroughs.
• Consent before loading, where required. Getting any consent the law requires before our script loads. The script has no consent mode of its own, so where consent is needed, load the script only after it is given.
• Verified users. Deciding whether to turn on verified users, as the Terms describe.
• Data we should not receive. Not sending us special categories of personal data (such as health data), health records, government ids or criminal-offence data. The assistant reads the values in ordinary form fields; only the protected fields in section 4B and card-number-shaped values are held back. So do not load the script on pages where End Users enter or see this kind of data, and do not pass it, or payment card data, in identify() or track().
• Retention. Choosing the retention period for chat and walkthrough content that suits you (section 17).
• Being clear it is an AI. Not presenting the assistant to End Users as a human.
• Your own data and systems. The accuracy and lawfulness of the data you make available to us, and the security of your own app, accounts and keys.

7. Our people

Everyone we allow to process Customer Personal Data is bound by a duty of confidentiality, knows the rules in this DPA, and gets access only to what their work needs. Today, that is a small number of people on our team who need it to run and support the Service.

8. Security

• Our measures. We protect Customer Personal Data with the technical and organisational measures in Annex II. We may change them, but we will not lower the overall level of protection.
• No certification today. We do not hold a SOC 2 report, an ISO 27001 certification or any other third-party security certification, and we are not certified under the EU–US Data Privacy Framework. Annex II describes what we actually do. We will tell you if this changes.

9. Sub-processors

• General authorisation. You authorise us to use Sub-processors to provide the Service. The current list is at helpalive.com/legal/sub-processors. Annex III copies it as it stands on the date of this version.
• Notice of new ones. We will tell you at least 30 days before a new Sub-processor starts processing Customer Personal Data, by email to your workspace admins and by updating the list.
• Objecting. You can object to a new Sub-processor on reasonable data protection grounds by emailing support@helpalive.com within those 30 days. We will discuss it with you in good faith and look for a solution. If we cannot resolve it, you may end the Terms by telling us, and we will refund, pro rata, any fees you paid in advance for the period after it ends. This refund applies despite anything in the Terms.
• Same protections. We will have written data protection terms with each Sub-processor that are equivalent to this DPA, for the service it provides to us.
• Our responsibility. We remain responsible to you for our Sub-processors' work as if it were our own.

10. Our AI providers

• Who. We use the AI providers listed in Annex III to run the assistant. Which of them handles a given request is our choice and can change.
• How. We send requests with storage turned off where the provider offers it. Each provider normally keeps requests for up to 30 days to monitor for abuse, and longer only where its policies allow it, such as a legal obligation or a request flagged for abuse. Each provider's terms, or its settings for our account, commit it not to use our requests to train its models, and we remain responsible to you for every provider under section 9.
• Changes. Adding a new AI provider is a Sub-processor change under section 9.

11. De-identified data and improving HelpAlive

• What we may do. We may create de-identified data from Customer Data and use it to improve HelpAlive for all customers. You instruct us to do this by accepting this DPA, unless you opt out.
• What "de-identified" means. Data that can no longer reasonably be used to identify, or be linked to, a particular person or household. Where the law no longer treats such data as personal data, this DPA no longer applies to it; until then, it stays protected by this DPA.
• Our commitments. We will take reasonable measures so that de-identified data cannot be linked back to a person or household, keep and use it only in de-identified form, and not try to re-identify it (except to test that our de-identification works). Anyone we share it with must commit to the same. This is our public commitment, as the CCPA requires.
• No shared AI training on personal data. We do not use Customer Personal Data to train AI models shared across customers.
• Opting out. You can opt out at any time by emailing support@helpalive.com. We will then stop creating de-identified data from your Customer Data. Data already de-identified is not affected.
• Who is responsible. Creating de-identified data is processing on your instruction. De-identified data that a law still treats as personal data stays under this DPA and is used only to improve HelpAlive.

12. Requests from End Users and others

• Requests sent to us. If anyone asks us to see, correct, delete or move Customer Personal Data, we will forward the request to you without undue delay. Unless the law requires otherwise, we will only tell them we have passed it on.
• Tools in the dashboard. You can:
  • delete one End User, or one of your End Users' organisations. This deletes their usage data and their chat and walkthrough content, and de-identifies the records that remain (counts are kept). Deletion is complete within 15 minutes;
  • stop collecting data about one End User. New usage data about them is no longer stored.
• Help on request. Exporting one person's data, and other requests the dashboard cannot handle, are handled on request. Email support@helpalive.com. We will act promptly, so that you can meet the deadline the law gives you.
• What remains. If we cannot fully carry out a request, we will tell you what remains, where, and why.

13. Impact assessments and regulators

We will give you reasonable help with data protection impact assessments, and with consulting a supervisory authority before processing, taking into account the nature of the processing and the information available to us. This DPA and its annexes are written to cover most of what you need.

14. Personal Data Breaches

• When we tell you. We will tell you of a Personal Data Breach without undue delay, and no later than 72 hours after we become aware of it, by email to your workspace admins.
• What we tell you. What we know: what happened; the kinds and rough number of people and records affected; the likely consequences; what we have done or plan to do; and who to contact. We send updates as we learn more.
• What we do. We will take reasonable steps to contain and investigate the breach and limit the harm, and help you meet your own duties to notify regulators and people.
• Who notifies. You decide whether to notify regulators and End Users. We will not do it for you unless the law requires it or you ask us to.
• No admission. Telling you about a breach is not an admission of fault.

15. Audits and information

• Information. On request, we will give you the information you reasonably need to show that we meet this DPA, starting with this DPA and its annexes.
• Questionnaire. Once a year, on request, we will answer a reasonable security questionnaire.
• Audits. If the information and the questionnaire do not reasonably show that we meet this DPA, after a Personal Data Breach that affects your Customer Personal Data, or where a law or a supervisory authority requires one, you may audit us, on site or remotely, once in any 12 months, and again after such a breach. You give us 30 days' notice (less after a breach); the audit happens in business hours, is limited to what is needed, protects other customers' data, and is done by you or an independent auditor bound by confidentiality. You pay its cost, unless it finds a material breach of this DPA. The once-a-year limit and the notice period do not restrict an audit that a law or a supervisory authority requires, or one that is urgently justified.
• The SCCs. Where the SCCs apply, this section is how their audit clause (Clause 8.9) is carried out. If the SCCs give you more, they prevail.

16. International transfers

• Where data is. We store Customer Personal Data in the United States. One Sub-processor processes it on a global network, as Annex III shows. You authorise these transfers.
• No Data Privacy Framework. We are not certified under the EU–US Data Privacy Framework, its UK Extension or the Swiss–US Data Privacy Framework. We rely on the mechanisms below.
• EU and EEA. For transfers of Customer Personal Data from the EEA to us, the SCCs are part of this DPA by reference. You are the data exporter and we are the data importer. They apply as follows:
  • Module 2 (controller to processor) applies where you are a controller, and Module 3 (processor to processor) where you are a processor;
  • Clause 7 (docking clause) applies;
  • Clause 9(a): Option 2 (general written authorisation) applies, with 30 days' notice, as in section 9;
  • Clause 11(a): the optional language does not apply;
  • Clause 13: the competent supervisory authority is the one set out in Annex I, Part C;
  • Clause 17: Option 1 applies, with the law of Ireland;
  • Clause 18(b): disputes go to the courts of Ireland;
  • Annexes I, II and III of the SCCs are completed by Annexes I, II and III of this DPA.
  By accepting the Terms, each of us is treated as having signed the SCCs, including their annexes.
• United Kingdom. For transfers from the UK, the UK Addendum is part of this DPA by reference and amends the SCCs as it says. Its Part 1 tables are filled in by reference: Table 1 by the party details in Annex I, Part A; Table 2 by the SCC modules and options above; Table 3 by Annexes I, II and III; and in Table 4, either party may end the UK Addendum as its section 19 allows. Its Part 2 mandatory clauses apply as issued by the Information Commissioner.
• Switzerland. For transfers subject to the FADP, the SCCs apply as above with these changes: the Swiss Federal Data Protection and Information Commissioner is the competent supervisory authority where the FADP applies; references to the GDPR are read as references to the FADP where it applies; and "Member State" in Clause 18(c) is read to include Switzerland, so that data subjects there can bring claims where they normally live.
• If a mechanism fails. If a mechanism in this section stops being valid, we will work with you in good faith to put a valid one in place.

17. Retention, return and deletion

• While you are a customer. We keep Customer Personal Data for the periods in Annex I, which match the retention table in our Privacy Policy. Chat messages and walkthrough content follow your retention setting: 365 days by default, adjustable from 7 to 730 days.
• Your whole workspace. You can ask us at any time to export your data, or to delete your whole workspace, by emailing support@helpalive.com. We do it within 30 days of your request.
• When the Terms end. Ask us within 90 days if you want your Customer Personal Data exported; if you do, we do not delete it until the export has been delivered. Otherwise we delete it no later than 90 days after your subscription ends, or within 30 days of your request if you ask sooner, and confirm by email when it is done.
• Logs and backups. Copies in our server logs expire after 30 days, and copies in backups after about one month. Until then, this DPA still protects them.
• What we may keep. Anything a law requires us to keep, only for as long as it requires, and still protected by this DPA. De-identified data that is no longer personal data (section 11) is kept.

18. US state privacy laws

Where the CCPA or a similar US state privacy law applies, we are your service provider (or processor, as that law may call it). We process Customer Personal Data only for the business purpose of providing, securing and supporting the Service for you, including creating de-identified data as section 11 describes. We will not:

• sell or share Customer Personal Data;
• keep, use or disclose it for any other purpose, including any other commercial purpose, except as the law allows a service provider;
• keep, use or disclose it outside our direct business relationship with you;
• combine it with personal information we receive from anyone else, or collect ourselves, except as the law allows a service provider.

We will meet the obligations the CCPA places on service providers and give Customer Personal Data the level of privacy protection the CCPA requires. You may take reasonable steps to check that we use Customer Personal Data consistently with your obligations (section 15 describes how), and to stop and fix any unauthorised use. We will tell you if we decide we can no longer meet our obligations under the CCPA. We certify that we understand the restrictions in this section and will comply with them.

19. Liability

Each party's liability under this DPA is subject to the limitation of liability in the Terms. This DPA has no separate cap. Nothing in this section limits liability to data subjects under the SCCs, limits liability between the parties under the SCCs or the UK Addendum to the extent a limit would contradict or undermine their liability clauses, or limits any liability the law does not allow to be limited.

20. Changes and how long this lasts

• How long. This DPA applies for as long as we process Customer Personal Data for you, including after the Terms end, until we have deleted it.
• Changes. We may update this DPA when a law requires it, or to reflect a change of Sub-processors. We will tell you by email to your workspace admins at least 30 days before a change takes effect, unless a law requires it to take effect sooner.
• No lowering of protection. No change will reduce the protection this DPA gives Customer Personal Data without your consent.

21. Contact

HelpAlive, Inc., 1111B S Governors Ave Suite 97728, Dover, Delaware 19904, United States · support@helpalive.com

Annex I — Description of the processing

This annex completes Annex I of the SCCs.

A. The parties

• Data exporter: the Customer, as named in its HelpAlive workspace. Contact: its workspace admins. Role: controller, or processor for its own client (section 3). Activities: using the Service in its web app.
• Data importer: HelpAlive, Inc., 1111B S Governors Ave Suite 97728, Dover, Delaware 19904, United States. Contact: support@helpalive.com. Role: processor, or sub-processor. Activities: providing the Service.
• Signature and date: each party is treated as having signed on the date the Customer accepts the Terms.

B. Description of the transfer

Retention

C. Competent supervisory authority

• Customer established in the EEA: the supervisory authority of its member state.
• Customer outside the EEA with a GDPR Article 27 representative: the authority of the member state where the representative is established.
• Customer outside the EEA without one: the authority of the member state where the relevant data subjects are located.
• UK Addendum: the UK Information Commissioner. FADP: the Swiss Federal Data Protection and Information Commissioner.

Annex II — Technical and organisational measures

This annex completes Annex II of the SCCs. It lists the measures in place today. We are a small, early-stage company, and we describe our controls as they are.

• Encryption in transit. Data travels over HTTPS (TLS) between browsers and our services, and when our servers call our providers.
• Encryption at rest. Our databases and their backups are encrypted at rest by our hosting provider.
• Keeping customers apart. Each customer's data is logically separated from other customers' data, and the Service accesses only the data of the customer it is acting for.
• Access. Limited to the few people on our team who need it, who are bound by confidentiality (section 7).
• Dashboard sign-in. Passwords never stored in readable form; emailed verification codes; limits on repeated sign-in attempts; sign-in sessions that end after 30 days, or after 7 days without use.
• Less data from the browser. Password, payment card and one-time-code fields, and card-number-shaped values in form fields, blanked; secret-looking parts of page addresses removed from usage analytics; End User id pseudonymised; no cookies.
• Redaction of usage analytics. Automated redaction before storage, as section 4A describes. Not applied to chat or walkthrough content.
• Limits on what the AI model receives. No values from password, payment card, one-time-code, file-upload or hidden fields, and no card-number-shaped values from form fields; never the email address from the End User's profile (personal data visible on the page, or typed in the chat, can be included). Requests go to our AI providers with storage turned off where the provider offers it.
• Retention limits. The periods in Annex I, including short-lived temporary walkthrough data and a Customer setting for chat and walkthrough content.
• Backups. Regular database backups, kept about one month.
• Logging. Server logs kept 30 days. Logs can contain chat and page text, but not the values typed into form fields (section 4B).
• Deletion tools. Dashboard deletion and stop-collecting, as section 12 describes. Deletion completes within 15 minutes; an interrupted deletion is resumed until it finishes.
• Sub-processors and incidents. As sections 9 and 14 set out.
• Certifications. None today: no SOC 2, no ISO 27001, no Data Privacy Framework certification.

Annex III — Sub-processors

This annex completes Annex III of the SCCs. The current list is always at helpalive.com/legal/sub-processors. This is a copy as of this version of the DPA.

Section 10 describes how our AI providers handle requests. The providers we use only for our own business, listed in part 3 of the sub-processors page, do not process Customer Personal Data.