Data processing agreement

1. Parties and scope

This Data Processing Agreement (the “DPA”) is between Perpetio OÜ (“Reachpool”, “we”, “us”) and the customer that has accepted our Terms of Service (the “Customer”, “you”). It applies whenever we process Customer Personal Data in providing the Service, and meets the requirements of Article 28 of the GDPR.

Company

Perpetio OÜ

Registry code

14661567

VAT number

EE102136393

Address

Harju maakond, Tallinn, Kesklinna linnaosa, Kaupmehe tn 7-120, 10114, Estonia

Email

hello@reachpool.ai

2. Definitions

Words defined in the Terms have the same meaning here. “Controller”, “processor”, “data subject”, “personal data”, “personal data breach”, “processing” and “supervisory authority” have the meanings the GDPR gives them. In addition:

“GDPR”

Regulation (EU) 2016/679, the General Data Protection Regulation.

“Data Protection Law”

The GDPR and the laws implementing or supplementing it, and, where they apply to the processing, the UK GDPR and the Swiss Federal Act on Data Protection.

“Customer Personal Data”

Personal data in Customer Data that we process for you, as Annex I describes.

“Subprocessor”

A third party we engage to process Customer Personal Data, as Annex III lists.

“SCCs”

The Standard Contractual Clauses adopted by Commission Implementing Decision (EU) 2021/914.

3. Roles

You are the controller of Customer Personal Data and we are your processor. Where you act for your own client, as agencies often do, your client is the controller, you are its processor, and we are your subprocessor: you confirm that your client has authorized you to engage us on these terms, and you pass on its instructions to us. You remain our only point of contact, and we act on your instructions alone.

For your Users’ account details and the other data our Privacy policy describes as ours, we are an independent controller, and this DPA does not apply. Each party will comply with the Data Protection Law that applies to it.

4. Processing on instructions

We process Customer Personal Data only on your documented instructions. Your instructions are the Agreement, how you set up and use the Service (your campaigns, Senders, imports, integrations and settings), and other written instructions we agree to. We will tell you if we believe an instruction breaks Data Protection Law. If EU or Member State law requires us to process Customer Personal Data otherwise, we will tell you before we do, unless that law forbids it.

5. The Customer’s obligations

You are responsible for the lawfulness of the processing you instruct. In particular:

• you have a lawful basis for the processing and for contacting each lead, and, where you rely on legitimate interests, you have assessed them;
• you give data subjects the information Articles 13 and 14 of the GDPR require, in good time;
• you have the authority to operate each Sender and the agreement of its Account Holder;
• you do not use the Service to process special categories of personal data or data about children, and you honor objections, using the exclusion list where it helps; and
• your instructions comply with Data Protection Law.

6. Confidentiality

We give access to Customer Personal Data only to staff who need it to provide, support or secure the Service, and each of them is bound by a duty of confidentiality.

7. Security

We implement and maintain the technical and organizational measures in Annex II, which are designed to ensure a level of security appropriate to the risk, as Article 32 of the GDPR requires. We may change them as technology and risks change, but never so as to lower the overall level of protection.

8. Subprocessors

You give us general authorization to engage Subprocessors. Annex III lists the current ones. We bind each Subprocessor by a written contract to data protection obligations that protect Customer Personal Data at least as well as this DPA, and we remain liable to you for their performance. A CRM you connect, such as HubSpot or Pipedrive, receives data on your instruction under your own contract with it, and Google only signs Users in: neither acts as our Subprocessor, though Annex III names them so you see every recipient.

We will tell your owners by email at least 14 days before we add or replace a Subprocessor, and update Annex III. You may object on reasonable data protection grounds within those 14 days. We will then try in good faith to resolve the objection, for example by not using the new Subprocessor for your data. If we cannot, you may end the affected part of the Service without penalty and receive a refund of fees you prepaid for the time after it ends. When a Subprocessor must be replaced urgently to keep the Service running or secure, we will tell you as soon as we can, and the same right to object applies.

9. Data subject requests

If a data subject asks us to exercise their rights over Customer Personal Data, we will pass the request to you without undue delay and not answer it ourselves, except to tell the data subject that we have passed it on. Taking into account the nature of the processing, we help you answer such requests: through the Service’s own functions, such as exclusion lists and the API, and, where those are not enough, by finding, exporting, correcting or deleting the data at your written request within 30 days.

10. Personal data breaches

We will tell you of a personal data breach affecting Customer Personal Data without undue delay, and in any case within 48 hours after we become aware of it. We will give you what you need to meet your own duties under Articles 33 and 34 of the GDPR, as far as we know it: the nature of the breach, the categories and approximate number of data subjects and records concerned, its likely consequences, and the measures taken or proposed. Where we do not yet know everything, we will send what we know and follow up. We will act at once to contain the breach and limit its effects. We will not notify authorities or data subjects of a breach of Customer Personal Data on your behalf unless you ask us to or the law requires it. Telling you of a breach is not an admission of fault.

11. Other assistance

Taking into account the nature of the processing and the information available to us, we will help you with data protection impact assessments and prior consultations with supervisory authorities that concern the Service. Where such help goes beyond giving you the information in this DPA and our documentation, we may charge reasonable costs, agreed in advance.

12. Deletion and return

While the Agreement lasts, you can export Customer Personal Data through the Service and its API, and we delete specified data at your written request within 30 days, as section 9 describes.

When the Agreement ends, an owner can ask us for an export of Customer Personal Data for 30 days. After those 30 days we delete Customer Personal Data from the Service, and the backups that still hold it are replaced within a further 14 days. Senders’ LinkedIn sessions and browser profiles are deleted when the Agreement ends. We keep Customer Personal Data longer only where EU or Member State law requires it, and then only for as long as it does. On request, we confirm the deletion in writing.

13. Information and audits

We make available to you the information needed to demonstrate compliance with this DPA: this DPA and its annexes, and, once a year, answers to a reasonable security questionnaire. If that information is not enough to demonstrate compliance, or a supervisory authority requires it, you may audit our compliance yourself or through an independent auditor who is not our competitor and is bound by confidentiality. An audit takes place no more than once in 12 months unless a breach or an authority requires it, with 30 days’ notice, during business hours, at your cost, and without access to other customers’ data. For our Subprocessors, we provide their own audit reports or certifications in place of an audit of their premises.

14. International transfers

We store Customer Personal Data in the European Union, in Germany. We transfer it outside the European Economic Area only where Article 45 or 46 of the GDPR allows it: to a country with an adequacy decision (including a recipient certified under the EU–US Data Privacy Framework), or under the SCCs, with additional safeguards where needed. Annex III shows where each Subprocessor processes data.

Where we transfer Customer Personal Data to a Subprocessor outside the European Economic Area without an adequacy decision, we do so under Module 3 (processor to processor) of the SCCs, which we have concluded with that Subprocessor. Where you are established outside the European Economic Area, Module 4 (processor to controller) of the SCCs is incorporated into this DPA by reference for the data we return or make available to you. The SCCs are governed by Estonian law, disputes under them go to the courts of Estonia, and the competent supervisory authority is the Estonian Data Protection Inspectorate. For transfers from the United Kingdom or Switzerland, the SCCs apply as amended by the UK Addendum or by the Swiss Federal Data Protection and Information Commissioner’s requirements.

15. Liability

Each party’s liability under this DPA is subject to the limits in the Terms, as far as Data Protection Law allows. Nothing in this DPA limits either party’s liability to data subjects under Article 82 of the GDPR.

16. Term and precedence

This DPA lasts as long as we process Customer Personal Data. If it conflicts with the Terms, this DPA prevails on the protection of personal data; where the SCCs apply, they prevail over this DPA. This DPA is governed by the law, and subject to the courts, that the Terms name. We may update it as the Terms describe, and never so as to lower the protection of Customer Personal Data, except where the law requires a change.

17. Annex I: Details of the processing

“Subject matter”

Providing the Service: running LinkedIn outreach for the Customer through its Senders.

“Duration”

The term of the Agreement, and then the export and deletion period in section 12.

“Nature”

Collection through the Customer’s Senders and imports; storage; organization; retrieval and display; use to send connection requests, messages and InMails, to write AI first lines, to label replies and to find business email addresses; transmission to the Customer’s CRM and webhooks; export; deletion.

“Purposes”

The Customer’s campaigns, shared inbox, reporting, lead enrichment and integrations, and the support and security of the Service.

“Data subjects”

The Customer’s leads and prospects; the Account Holders of its Senders; the people who appear in conversations; and the Customer’s and its clients’ staff where they appear in Customer Data (for example as the assignee of a conversation).

“Personal data”

LinkedIn profile data (name, headline, current role and company, location, profile address and identifiers, public profile content); contact details the Customer imports or finds, such as a business email address; communications (connection notes, messages, InMails and replies, with their times); campaign and activity data (steps, statuses, acceptances, labels, tags, notes, meetings booked); for Account Holders, their LinkedIn session cookies, browser profile, account name and profile address, and the account’s health events; and CRM identifiers.

“Special categories”

None intended. The Customer must not configure processing of special categories of personal data, although leads may volunteer such data in their messages.

“Frequency”

Continuous, while the Agreement lasts.

“Retention”

As section 12 sets out.

18. Annex II: Technical and organizational measures

Hosting. The platform and its database run on servers in Germany; the storage for browser profiles, support captures and backups is in Germany too.

Encryption. Connections to the console, the API and our Subprocessors use TLS. Senders’ LinkedIn sessions and proxy credentials are encrypted with a key per customer, held in a dedicated secrets vault, and the keys can be rotated. Browser profiles and support captures are encrypted with AES-256-GCM, and database backups with AES-256, before they leave our servers.

Separation of customers. Every table that holds customer data is protected by database row-level security, so a request reads only its own customer’s rows. Within a customer, workspaces keep each client’s data apart, and a client viewer sees one workspace only. Only the services that operate browsers and proxies may read sessions and proxy credentials.

Access by Users. There are no passwords: Users sign in with a single-use email link valid for 15 minutes, or with Google. Access follows roles (owner, admin, member, client viewer). API keys are long random values that we keep only as hashes; each is limited to one workspace and can be revoked at any time.

Access by our staff. Only named staff can use support tools. A read-only view of a customer’s console lasts at most 30 minutes and needs a recorded reason; every staff action is written to an audit log that the platform cannot change or delete. Configuration secrets are kept in a self-hosted secrets manager, not in code.

LinkedIn accounts. No LinkedIn password is ever requested or stored, and no security check is solved for an Account Holder. Each Sender connects through one fixed proxy in its own country, and a rate-limit engine that no setting can override caps every action.

Minimization. Logs never contain LinkedIn cookies, proxy credentials, message text or leads’ email addresses. Reply labels are made from message text alone, without names or profiles, and AI providers are used with data collection refused.

Availability and recovery. The database is archived continuously, at least once a minute, with daily backups, so it can be restored to any moment of the last one to two weeks under a documented recovery procedure. Service health is monitored with alerts, and our status page shows the current state.

Development. Changes are reviewed and tested automatically before release, and commits are scanned for secrets.

Incidents. Alerts reach the team on call, documented procedures guide the response, and breaches are reported as section 10 requires.

Deletion. Removing a Sender deletes its session and browser profile and releases its proxy at once; the rest is deleted as section 12 sets out.

19. Annex III: Subprocessors

We use these Subprocessors, each only for what is listed. We will update this list as section 8 describes.