Reditus Data Processing Agreement

Version 1.3. Effective 5 August 2026. This is the edition published at https://www.getreditus.live/dpa. Earlier versions are available on request from the Privacy Contact.

The undersigned:

the Customer, being ________________________________ with its registered office at ________________________________, registered with the Chamber of Commerce under number ________________________________ and legally represented by ________________________________ ("Customer");

and

Reditus B.V., with its registered office at Kapelweg 12, 3951 AC Maarn, Netherlands, registered with the Dutch Chamber of Commerce (KvK) under number 77814487, VAT number NL861156420B01, legally represented by Joran Hofman (Founder) ("Reditus");

have agreed as follows.

Preamble

This Data Processing Agreement ("DPA") sets out the terms on which Reditus processes personal data on behalf of the Customer in providing the Reditus affiliate and partner marketing platform, and identifies the processing Reditus carries out as controller in its own right. It contains the mandatory clauses required by Article 28(3) of the General Data Protection Regulation (EU) 2016/679. It is incorporated by reference into the Reditus Terms of Service and applies automatically to every Customer; the signature block explains how to obtain a countersigned copy.

1. Definitions and interpretation

1.1 "Controller", "Processor", "Data Subject", "Personal Data", "Personal Data Breach", "Processing" and "Supervisory Authority" have the meanings given in Data Protection Law.

1.2 "Data Protection Law" means, as applicable: the GDPR; the Dutch Uitvoeringswet AVG; the UK GDPR and the Data Protection Act 2018, as amended by the Data (Use and Access) Act 2025; the Swiss Federal Act on Data Protection (the "FADP"), overseen by the Swiss Federal Data Protection and Information Commissioner (the "FDPIC"); and the US State Privacy Laws, including the California Consumer Privacy Act as amended (the "CCPA").

1.3 "Customer Personal Data" means personal data Reditus processes on behalf of the Customer in providing the Services, including data the Customer or its users upload, data collected through the Reditus tracking script on the Customer's own websites, and data received from systems the Customer connects. Annex A1 describes it.

1.4 "End Client" means the controller on whose behalf the Customer, itself acting as a processor, processes personal data, and in respect of which Reditus acts as a sub-processor.

1.5 "Privacy Contact" means the Reditus address for data protection notices, Sub-processor objections and assistance requests: privacy@getreditus.live.

1.6 "Restricted Transfer" means a transfer of personal data to a country outside the EEA, the United Kingdom or Switzerland, as applicable, that is only permitted under Data Protection Law if a transfer safeguard is in place.

1.7 "Service Data" means personal data Reditus processes as a controller in its own right in connection with the Services, as described at Annex A2.

1.8 "Services" means the Reditus affiliate and partner marketing platform and any related service provided under the Terms of Service.

1.9 "Standard Contractual Clauses" or "SCCs" means the standard contractual clauses adopted by the European Commission in Implementing Decision (EU) 2021/914 of 4 June 2021, as incorporated and completed at clause 8.

1.10 "Sub-processor" means any processor engaged by Reditus, or by another Sub-processor, to process Customer Personal Data; the approved list is at Annex C Table 1, maintained at https://www.getreditus.live/sub-processors.

1.11 "Terms of Service" means the Reditus Terms of Service at https://www.getreditus.live/terms-of-service, together with any order form or other written agreement for the Services.

1.12 This DPA is incorporated into the Terms of Service and its Annexes form part of it. "Including" means "including without limitation", and a reference to a statute is to it as amended or replaced.

2. Roles and scope

2.1 For Customer Personal Data, the Customer is the controller and Reditus the processor. Where the Customer is itself a processor acting for an End Client, Reditus is a Sub-processor, this DPA applies as if references to the controller were references to the End Client, and the Customer confirms it holds the authorisations needed to engage and instruct Reditus on the End Client's behalf.

2.2 Reditus is an independent controller for Service Data: account administration, billing, security and fraud prevention, product analytics and error diagnostics concerning use of the Services, and compliance with its own legal obligations. Reditus is also an independent controller for the profiles in its own affiliate network, marketplace and recruitment database, until an affiliate joins the Customer's programme, from which point the data inside that programme is Customer Personal Data and Reditus is the Customer's processor for it. Annex A2 describes both activities, which are governed by the Reditus privacy notice rather than by the Customer's instructions. Session replay is captured on the authenticated application solely for error monitoring and bug diagnosis, by Sentry only, configured to mask all text and to block all media; session replay is not enabled in the application's configuration of the product analytics tool. Backend error reports carry no user-context tagging. To the extent any Customer Personal Data is nonetheless captured in telemetry, error payloads or session recordings, it is Customer Personal Data, not Service Data. Nothing in this clause permits Reditus to use Customer Personal Data for its own purposes; clause 10 governs anonymised aggregates.

2.3 The Customer is the controller of its own websites and applications. The Customer, not Reditus, decides whether the Reditus tracking script and its cookies require consent where the Customer operates, obtains that consent where required, and describes the cookies in its own cookie notice; Annex A1 publishes each cookie's name, purpose and lifetime to enable this.

2.4 Reditus processes Customer Personal Data only on the Customer's documented instructions, including for transfers to a third country or an international organisation. The documented instructions are this DPA, the Terms of Service, the Customer's use and configuration of the Services (settings, integrations, the data it sends), and any further lawful written instruction that is technically feasible and consistent with the Services. The Customer controls what personal data it sends. The Customer may send an internal identifier instead of an email address; where the Customer does so and does not connect the Stripe, HubSpot or Calendly integrations, Reditus does not receive the referred person's email address. There is no separate "UID mode" to switch on: the tracking endpoint accepts either identifier and persists both when both are sent, the identifier field is free text and is not enforced to be opaque, and the resulting records are therefore pseudonymous rather than anonymous. Regardless of which identifier is used, the tracking script transmits the full page address including its query string, the referrer and the visitor's IP address, which is truncated on write. A Customer may also integrate through the Reditus API alone, reporting referrals and payments with its own identifiers and without installing the tracking script, which removes the cookie and the browser-side collection.

2.5 If Union or Member State law requires Reditus to process Customer Personal Data other than on the Customer's instructions, Reditus will inform the Customer of that requirement before processing, unless the law prohibits it on important grounds of public interest.

2.6 Reditus will immediately inform the Customer if, in its opinion, an instruction infringes Data Protection Law, and may pause the processing concerned until the Customer confirms, withdraws or amends the instruction.

2.7 The Services are not designed for special categories of personal data (Article 9 GDPR), criminal offence data (Article 10 GDPR) or the personal data of anyone under 18, and the Customer must not send them. If such data nonetheless arrives, Reditus protects it under Annex B, tells the Customer as soon as it becomes aware, and deletes or returns it on instruction.

3. Personnel and confidentiality

3.1 Reditus keeps Customer Personal Data confidential and discloses it only to its authorised personnel, to Sub-processors under clause 9, and where required by law under clause 7. This obligation survives the end of the Terms of Service without limit of time.

3.2 Everyone who may access Customer Personal Data on Reditus's behalf, including employees, directors, contractors, freelancers, temporary and agency staff, and external providers working on Reditus's own systems, signs a non-disclosure agreement, or is bound by an appropriate statutory confidentiality obligation, before access is granted; the obligation survives the engagement, and they are informed of their duties under Data Protection Law and this DPA.

3.3 Reditus limits access to Customer Personal Data to personnel who need it for a defined task, removes access promptly on role change or departure, and will provide data protection and security awareness training to personnel with access.

4. Security

4.1 Reditus implements and maintains appropriate technical and organisational measures to protect Customer Personal Data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure and unauthorised access, as Article 32 GDPR requires, including the measures in Annex B.

4.2 Reditus may update the measures in Annex B as technology and threats change, and may replace an individual measure, provided the replacement is equivalent or stronger and the overall level of security does not fall below the standard described in that Annex.

4.3 Reditus applies the principles of data protection by design and by default to its product and features. Concrete outputs of that approach in the current Services: client IP addresses truncated at the point of collection, to a /24 network for IPv4 and a /40 prefix for IPv6, in referral event records; no device fingerprinting in the tracking script or the referral widget, and no use of localStorage or sessionStorage; no cookie for ordinary visitors, because the attribution cookie is written only when an attribution parameter is present in the address; a server-side allowlist at the tracking endpoint, which reads a fixed set of fields and discards everything else (Annex A1, "Passthrough"); configurable cookie lifetime; masking by default of referred people's email addresses shown to affiliates, which the Customer may switch off per partnership; and application-level encryption of affiliate IBANs, API tokens and integration secrets (Annex B).

The Customer may also send an internal identifier instead of an email address; where it does so and does not connect the Stripe, HubSpot or Calendly integrations, Reditus does not receive the referred person's email address. That identifier is free text and is not enforced to be opaque, so the records remain pseudonymous rather than anonymous, and the tracking script still transmits the full page address, the referrer and a truncated IP address. A Customer may go further and integrate through the Reditus API alone, without installing the tracking script, which removes the cookie and the browser-side collection.

4.4 Security at the Customer's end is the Customer's responsibility. In particular, the Customer keeps its API keys, tokens, passwords and other credentials for the Services confidential and rotates them if compromise is suspected, secures the devices, systems and websites from which the Services are accessed or on which the tracking script runs, and applies the principle of least privilege to its own users' access to the Services.

5. Assistance

5.1 Affiliate records, referred-lead records and the associated tracking and commission data are findable in the platform and exportable as described at clause 13.2. There is no self-service deletion in the Services: neither the Customer nor an affiliate can delete an account or remove stored payout details from the interface. Deletion of an individual record, and deletion of an account, is therefore carried out by Reditus administrators on request, free of charge, within the timescales in clause 5.2.

5.2 Taking into account the nature of the processing, Reditus will assist the Customer, by appropriate technical and organisational measures, in responding to data subject requests: access, rectification, erasure, restriction, portability, objection, withdrawal of consent, and Article 22 GDPR requests concerning automated decision-making. Reditus acknowledges an assistance request within 2 business days, responds substantively within 5, and where the Customer works to a one month deadline under Article 12(3) GDPR, in time to meet it.

5.3 If a data subject contacts Reditus directly about Customer Personal Data, Reditus will not respond substantively; it confirms receipt, refers the person to the Customer, and forwards the request to the Customer within 5 business days.

5.4 Reditus will give reasonable assistance with data protection impact assessments (Article 35 GDPR), prior consultation (Article 36 GDPR), the Customer's obligations under Articles 32 to 34 GDPR, and supervisory authority enquiries concerning the processing in Annex A1.

5.5 Ordinary assistance under this clause is free. Reditus may charge a reasonable fee where a request is manifestly unfounded, excessive or repetitive, or requires more than eight person-hours of engineering time in any twelve month period; it gives a written estimate first, starts no chargeable work without written approval, and never uses cost to delay assistance needed for a statutory deadline.

6. Personal Data Breach

6.1 Reditus will notify the Customer of a Personal Data Breach affecting Customer Personal Data without undue delay, and in any event within 48 hours of becoming aware of it, so that the Customer can meet its own 72 hour deadline under Article 33(1) GDPR. Awareness begins when any member of Reditus personnel has a reasonable degree of certainty that such an incident has occurred; internal triage does not postpone it.

6.2 So far as available, the notification describes the nature of the breach, the categories and approximate numbers of data subjects and records concerned, the likely consequences, the measures taken or proposed, and the Reditus contact point; anything not yet available follows in phases without further undue delay.

6.3 Reditus will provide a written root cause analysis within 30 days of containment and will cooperate with the Customer's investigation, mitigation and notifications.

6.4 Reditus will not notify a supervisory authority or data subjects on the Customer's behalf unless the Customer instructs it or the law requires it, in which case Reditus tells the Customer first where lawful. A notification under this clause is not an admission of fault. Unsuccessful attempts that do not compromise Customer Personal Data, such as port scans, failed logins and blocked denial of service attempts, are not individually notified.

6.5 Shorter window for regulated Customers. Where the Customer is subject to an early-warning duty under the NIS2 Directive, the Dutch Cyberbeveiligingswet or an equivalent national implementation, and tells Reditus so in writing, the period in clause 6.1 is 24 hours instead of 48 for that Customer, from the same moment of awareness. No order form, negotiation or fee is required; the written notice is enough. A period shorter than 24 hours has to be agreed in an order form. This clause is the contractual basis for the same commitment published at https://www.getreditus.live/security.

7. Government requests

If a public authority, court or law enforcement body requests Customer Personal Data, Reditus will first attempt to redirect the requester to the Customer as controller, and will notify the Customer promptly unless legally prohibited, in which case it will use reasonable efforts to obtain a waiver so it can share what it lawfully can, as soon as it lawfully can. Reditus reviews each request, challenges one that appears unlawful, overbroad or not issued under a valid legal procedure, and suspends disclosure while a challenge is pending where lawful. If compelled, Reditus discloses only the minimum necessary, keeps a record of every binding request, and shares information about them with the Customer to the extent lawfully permitted. Reditus provides no government with direct, unrestricted or bulk access to Customer Personal Data and hands over no encryption keys for that purpose.

8. Cross-border transfers

8.1 The production data store for Customer Personal Data is in the European Union: the application runs on Hetzner Online GmbH infrastructure in Nuremberg, Germany, and the primary application database is provided by Supabase Pte. Ltd in an EU region (Frankfurt, Germany). Supabase provides the database only. Authentication is self-hosted inside the Reditus application (Devise) and is not a managed service of the database provider. File and object storage is Cloudflare R2, not Supabase. Supabase contracts through a Singapore entity, so that leg relies on the Standard Contractual Clauses rather than on data location alone. Several Sub-processors process limited categories outside the EEA or under a non-EEA contracting entity; Annex C Table 1 names each and its transfer mechanism.

8.2 The Standard Contractual Clauses are incorporated by reference and apply to every Restricted Transfer of Customer Personal Data, completed as follows. Module Two applies where the Customer is a controller; Module Three where the Customer is a processor acting for an End Client. The optional docking clause at Clause 7 is enabled. Under Clause 9(a), Option 2 (general written authorisation) applies, with the 30 day notice period and objection mechanics in clause 9 of this DPA. The optional language in Clause 11 is not used. Under Clause 13 and Annex I.C, the competent supervisory authority is that of the EEA Member State in which the data exporter is established or, for an exporter not established in the EEA but within Article 3(2) GDPR, the authority determined under Clause 13(a); Clause 13 does not operate under Module Four. Under Clause 17 the Clauses are governed by Netherlands law; under Clause 18 disputes go to the courts of the Netherlands. Annex I of the Clauses is completed by the party details in this DPA and Annex A1; Annex II by Annex B; Annex III by Annex C Table 1. Where Reditus returns or discloses Customer Personal Data to a Customer established outside the EEA and outside an adequate country, Module Four applies to that leg with the same completions so far as they are capable of applying to that Module. Acceptance of the Terms of Service constitutes signature of the Standard Contractual Clauses, including their Annexes, by both parties.

8.3 For transfers subject to the UK GDPR, the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses, version B1.0, issued by the Information Commissioner, is incorporated by reference; its tables are deemed completed with the information in this DPA, and either party may end it as set out in Section 19 of its Mandatory Clauses.

8.4 For transfers subject to the FADP, the Clauses apply as amended for Switzerland: the competent supervisory authority is the FDPIC, references to the GDPR are read as the FADP to the extent it governs the transfer, data subjects in Switzerland may bring proceedings there, and, if and to the extent the FADP again protects data relating to legal entities, the Clauses apply to that data on the same terms.

8.5 If an adequacy decision that a transfer relies on is invalidated, suspended or lapses, the Standard Contractual Clauses apply to that transfer automatically from that date, without further action by either party. Where a Sub-processor also holds an EU-US Data Privacy Framework certification, Annex C Table 1 records it as a supplementary fact only; the Clauses remain the mechanism relied on.

9. Sub-processors

9.1 The Customer gives Reditus a general written authorisation to engage the Sub-processors listed at Annex C Table 1 and any Sub-processor added under this clause. This clause governs only Sub-processors, that is vendors that process Customer Personal Data; tools Reditus uses for its own business that never touch Customer Personal Data are not Sub-processors and can change without notice under this clause.

9.2 At least 30 days before a new Sub-processor begins processing Customer Personal Data, Reditus will publish a dated update in the Reditus trust centre updates feed, update the published list, and email the Customer's designated privacy or administrative contact. The objection window runs from whichever notice arrives last. The Customer keeps its designated contact current in the Services.

9.3 The Customer may object within 14 days, on reasonable grounds relating to data protection, by writing to the Privacy Contact. Reditus will work in good faith to resolve the objection, and will not permit the objected-to Sub-processor to process that Customer's data while it is unresolved. If the objection cannot be resolved within 30 days, the Customer may terminate the affected part of the Services (or, where it cannot reasonably be separated, the whole of the Services) on written notice, without penalty, with a pro-rated refund of prepaid fees covering the period after termination. On a termination under this clause Reditus also provides, at no charge, the export described at clause 13.2, including the operational assembly of the per-resource exports into a complete set, and reasonable transition assistance during the export window. Reditus is not obliged to abandon a planned change for other Customers; termination with the refund, export and assistance above is the Customer's remedy.

9.4 Where a change of Sub-processor is needed urgently to preserve the availability, security or integrity of the Services, or because an existing Sub-processor stops providing its service, Reditus may appoint a replacement immediately and give notice as soon as practicable, stating why advance notice was not practicable; the 14 day objection window then runs from that notice and clause 9.3 applies in full.

9.5 Before a Sub-processor begins processing, Reditus will enter into a written contract imposing the same data protection obligations as set out in this DPA, and in any event obligations no less protective, in particular sufficient guarantees of appropriate technical and organisational measures, including the applicable transfer safeguard where the Sub-processor is outside the EEA. Reditus holds or is completing such contracts with each Sub-processor listed in Annex C Table 1. For the entries in that table marked "newly disclosed", the written contract and, where required, the transfer safeguard are still being put in place; Annex C Note 6 records what remains to be confirmed and executed.

9.6 Where a Sub-processor fails to fulfil its data protection obligations, Reditus remains fully liable to the Customer for those obligations, as Article 28(4) GDPR requires.

10. AI and anonymised aggregates

10.1 No training on Customer Personal Data. Reditus does not use Customer Personal Data to train, fine-tune or otherwise improve any general-purpose AI model, foundation model or other machine learning model, whether its own or a third party's. Any AI service provider that processes Customer Personal Data is a Sub-processor, is named in Annex C Table 1 under the notice procedure in clause 9 before it begins or continues processing, and is bound to terms that prohibit training on Customer Personal Data and require zero retention, or a short and stated retention period for abuse monitoring only. Reditus gives that undertaking directly for the vendors it contracts with itself. Where a model is reached through an intermediary platform rather than contracted directly, Reditus is bound under clauses 9.5 and 9.6 to secure the equivalent undertaking through that chain and remains fully liable to the Customer for it; the specific confirmation still outstanding for the pipeline described at clause 10.2 is recorded there.

10.2 The AI pipeline that exists today. Reditus operates an AI lead-discovery and affiliate-matching pipeline, and it does involve a processing chain that must be disclosed. The pipeline is brokered through n8n Cloud, an automation platform. n8n receives the Customer's search criteria and ideal-customer-profile criteria and returns AI-generated match scores, confidence scores, rankings and written match reasons, computed over candidate contact records that contain names, email addresses, job titles and LinkedIn handles. Those scores and reasons are surfaced to the Customer in the Services. The model applied inside the pipeline is Google's Gemini API, called from within n8n rather than directly by the Reditus application. Hunter Web Services, Inc. supplies work-email discovery and verification for candidates, also called from within n8n, and the enriched personal data is stored in Reditus's own systems. DataForSEO OU supplies public web and search data about candidate sites and companies, and returns site and company data rather than personal data. The candidate records are Reditus's own recruitment data, for which Reditus is the controller (Annex A2), and they sit in a second, separate database project (Annex C Table 2). n8n Cloud is listed in Annex C Table 1 as a Sub-processor, on the conservative view, because it is the broker for the whole pipeline, because it receives Customer-supplied criteria, and because the webhook that returns its output stores the full unfiltered response body in the Reditus database.

10.3 Outputs about people. Where the Services produce a score, match, ranking or suggestion about a person, that output is provided for the Customer to act on: Reditus does not make decisions producing legal or similarly significant effects on data subjects on the Customer's behalf.

10.4 Anonymised aggregates. Reditus may create irreversibly anonymised, aggregated data from Customer Personal Data to operate, secure, analyse and improve the Services and to produce benchmarks, only where no individual can be singled out, linked or inferred. Reditus will not attempt re-identification, will not use aggregation as a route around the training prohibition above, will not publish any statistic derived from fewer than 20 Customers or 20 programmes, and will not publish or disclose aggregated data in a form that identifies the Customer, its affiliates, its leads or its referred customers without the Customer's prior written consent.

11. Data subject requests and third-party rights

11.1 Data subject requests that reach Reditus directly are handled and forwarded under clause 5.3; Reditus cooperates with supervisory authority enquiries concerning Annex A1 processing under clause 5.4.

11.2 Except for data subjects' rights under the Standard Contractual Clauses and Data Protection Law, no third party may enforce this DPA.

12. Term and termination

This DPA takes effect on the effective date above, or when the Customer first accepts the Terms of Service if later, and remains in force for as long as the Terms of Service do, and thereafter for as long as Reditus processes Customer Personal Data. Any provision that should by its nature survive to protect Customer Personal Data survives termination.

13. Data return and destruction

13.1 On the Customer's written request, and in any event on termination or expiry of the Terms of Service, Reditus will, at the Customer's choice, either return Customer Personal Data or delete it, and will then delete existing copies unless Union or Member State law requires retention.

13.2 The Customer can export its data using the export features of the platform during the term and for 60 days after termination or expiry, during which Reditus keeps the account read-only at no charge. Those features are per-resource: the platform offers CSV export for individual resources, a JSON API and webhooks. There is no single "export everything" archive. A complete export of Customer Personal Data is therefore an operational commitment Reditus fulfils on request, assembling the per-resource exports, rather than a self-service product feature. On request, Reditus provides Customer Personal Data in a structured, commonly used, machine-readable format such as CSV or JSON within 30 days; the same path serves Article 20 GDPR portability. Reditus completes the chosen return or deletion within 30 days of the Customer's choice, or within 30 days of the end of the export window if no choice is made, and in any event deletes Customer Personal Data from live systems no later than 120 days after termination or expiry.

13.3 Customer Personal Data may remain in backups after deletion from live systems, because backups are overwritten on a rolling 7 day cycle rather than edited. Data in backup is isolated from production, used for nothing, and restored only for disaster recovery, in which case Reditus re-applies the deletion. Reditus confirms deletion in writing on request.

13.4 Where law requires retention, for example for tax or accounting, Reditus retains only what the law requires, for as long as it requires, tells the Customer what and why, and processes it for no other purpose. Retention periods per category are in the schedule at Annex A1.

14. Records and audit

14.1 Reditus maintains the Article 30(2) GDPR record of categories of processing carried out for the Customer and makes the relevant part available to the Customer or a supervisory authority on request.

14.2 On written request, no more than once in any twelve month period unless Data Protection Law requires otherwise or following a material change to Annex B or Annex C Table 1, Reditus will make available the information needed to demonstrate compliance with Article 28 GDPR and this DPA: Annex B, the current Sub-processor list, the security overview at https://www.getreditus.live/security, and written responses to a reasonable security questionnaire within 15 business days.

14.3 Reditus will allow for and contribute to audits, including inspections, by the Customer or an auditor it mandates. Reditus is fully remote and has no facility of its own in which Customer Personal Data is processed, so an inspection is conducted remotely, by video conference and document review; for assurance about a Sub-processor's data centre, Reditus passes the request on and shares what its contract allows. An inspection requires 30 days' written notice, runs at most once in any twelve month period, and is subject to confidentiality; that limit, and the limit in clause 14.2, do not apply where a supervisory authority requires it or after a confirmed Personal Data Breach affecting the Customer's data. The Customer bears its own costs and the reasonable costs of Reditus's time beyond what Reditus already publishes; the auditor may not be a competitor whose principal business is affiliate, referral or partner-marketing software.

15. Warranties

15.1 Reditus warrants that it and anyone acting on its behalf will process Customer Personal Data in compliance with Data Protection Law and this DPA.

15.2 The Customer warrants that it has and will maintain a lawful basis for the processing it instructs, that the required notices have been given and any required consents obtained, and that its instructions comply with Data Protection Law.

16. Liability

Each party's total aggregate liability arising out of or in connection with this DPA is limited to the greater of the limit of liability in the Terms of Service and the fees paid or payable by the Customer in the twelve months before the first event giving rise to the liability; liability under this DPA is capped, not excluded, and no exclusion of liability in the Terms of Service applies to it. Nothing in this DPA or the Terms of Service limits either party's liability for a breach of Data Protection Law to the extent the law does not permit it to be limited, including liability to data subjects under Article 82 GDPR. The applicable cap limits, but does not disclaim, Reditus's responsibility for its Sub-processors under Article 28(4) GDPR.

17. US state privacy laws

Where Reditus processes personal information subject to a US State Privacy Law on the Customer's behalf, Reditus is the service provider or processor, the Customer the business or controller, and the disclosure of personal information to Reditus is neither a sale nor a share. Reditus will not sell personal information or share it for cross-context behavioural advertising; will not retain, use or disclose it for any purpose other than providing the Services, or outside the direct business relationship; and will not combine it with personal information from another source, except in each case where the applicable law expressly permits it. Reditus certifies that it understands these restrictions and will comply with them, and will notify the Customer if it can no longer do so, upon which the Customer may take reasonable steps to stop and remediate unauthorised use. Where Reditus creates deidentified data it will not attempt to reidentify it and will bind recipients to the same; the advertising and analytics on Reditus's own websites is Reditus's own controller processing, disclosed in the Reditus privacy notice, not processing on the Customer's behalf.

18. Order of precedence, amendments, applicable law and venue

18.1 For the processing of personal data, this DPA prevails over the Terms of Service to the extent of any conflict; executed Standard Contractual Clauses prevail over this DPA for the transfers they cover.

18.2 Reditus may amend this DPA; each version carries a version number and an effective date. Reditus will give at least 30 days' notice, by email to the Customer's designated contact and by an update in the Reditus trust centre, of any amendment that materially reduces the Customer's rights; the Customer may object on reasonable data protection grounds and, if the objection is not resolved within 30 days, terminate on the terms in clause 9.3. Changes required by Data Protection Law take effect when the law requires. Where the Customer has signed an order form, the version in effect on its date applies for its term, except for changes required by law. Nothing in this clause varies the Standard Contractual Clauses.

18.3 This DPA and its execution are governed by Dutch law. The Rechtbank Midden-Nederland has exclusive jurisdiction over any dispute arising out of or in connection with this DPA, without affecting the forum elected in the Standard Contractual Clauses or a data subject's right to bring proceedings where Data Protection Law allows.

Signature block

No Customer signature is needed. This DPA is incorporated by reference into the Terms of Service and applies automatically; acceptance in electronic form satisfies Article 28(9) GDPR. Reditus has signed it in advance; a Customer that needs a countersigned copy can request one from the Privacy Contact with its legal entity name, registered address and company number.

Signed for Reditus B.V.: Joran Hofman, Founder, at Maarn, Netherlands, on 5 August 2026, for version 1.3. Each version carries its own version number, effective date and signature date, as clause 18.2 requires.

Signed for the Customer (only where a countersigned copy is requested):

Name: ________________________________ Title: ________________________________

Date: ________________________________ Signature: ________________________________

---

Annex A1: Processing activities where Reditus is Processor or Sub-processor

| Type | Description | |---|---| | Business purposes | Providing the Services as described in the Terms of Service. | | Subject matter | Operating the Customer's affiliate, referral or partner programme: enrolling and managing affiliates and advocates, tracking clicks and referrals, attributing signups and purchases to the referring affiliate, calculating commissions, executing payouts. | | Nature | Collection, recording, storage, retrieval, use, disclosure by transmission to the Sub-processors in Annex C Table 1 and to systems the Customer connects, alignment, restriction, erasure, destruction. | | Purpose | Account administration; affiliate enrolment and verification; tracking and attribution; commission calculation and payout execution; self-referral and paid-advertising fraud detection; programme reporting; transactional email; support; marketplace listing where enabled; platform security and integrity. | | Duration | The term of the Terms of Service, then only for the periods in the retention schedule below. | | Frequency | Continuous; tracking and attribution events are processed in real time. | | Sensitive data | None. The Services are not designed for Article 9 or Article 10 data or the data of anyone under 18, and clause 2.7 instructs the Customer not to transmit them. | | Obligations and rights of the Customer | As set out in this DPA, in particular clauses 2, 5, 13 and 14, and in the Terms of Service: the Customer determines the purposes and means, owns the lawful basis, the data subject notices and the cookie-consent decision for its own websites, and decides what data its website transmits to Reditus. |

Data subject groups.

| Group | Data categories | Source | |---|---|---| | Customer personnel and account users | Name; business email address; authentication credentials (stored only as hashes); company name and domain; role and permissions; IP address and user agent recorded on each session record; session timestamps; in-product activity; support chat content, including the email address transmitted to the in-product support chat provider to identify the logged-in user; billing contact details and subscription status. Reditus does not receive or store payment card numbers: card details go directly to Stripe Payments Europe, Limited, which is the only payment processor Reditus uses. | The Customer, at signup and in the product. | | The Customer's affiliates and advocates | Name; email address; company name, website and domain; affiliate and advocate identifiers; authentication credentials (stored as hashes); IP address; tracking UUID; commission balances and payout history; payout identifiers, being the PayPal email address used for payouts, the affiliate's IBAN where the affiliate is paid by direct bank transfer or through Wise, and a tax identifier where one is supplied; marketing channels and profile information where supplied; support messages; read-only data from connected accounts (YouTube, Google Analytics 4 and LinkedIn), revocable by the affiliate. | The affiliate directly; the Customer, where it invites or imports affiliates; the affiliate's connected accounts. | | Leads and customers referred through a tracked link | The tracking UUID (a random version 4 UUID generated in the visitor's browser, held in the _gr_id first-party cookie); IP address, truncated on write; click and referral events including the referrer and the full page address with its query string; Google advertising parameters (gclid, gad_source, gad_campaignid) parsed from that stored address to detect paid-advertising traffic; the Customer's own uid where sent, which is free text and not enforced to be opaque; a free-form session value (sid) where sent; email address and name where the Customer chooses to send them; the HubSpot visitor token and Calendly event and invitee identifiers where those integrations are in use; subscription and transaction events from the Customer's connected Stripe account; calculated commission amounts. | The Customer's website and product via the tracking script; the Customer's Stripe account; the Customer's systems via the Reditus API and webhooks. |

Passthrough. The tracking script transmits the full page address including its query string, the referrer and the visitor's IP address, so the Customer's own URL structure decides part of what reaches Reditus. Server side, however, there is a fixed allowlist: the tracking endpoint reads only the fields evt, ref, url, ip, grid, m_email, m_uid, m_source, m_cal_event, m_cal_user, m_hub_utk, customer_id, affiliate_slug, cslug, ctype, pk, rl and sid, and discards everything else. Within that allowlist the Customer still controls the personal data content, because m_email carries an email address, m_uid and sid are free text, and url carries whatever the Customer's own query string contains. Stored page addresses are additionally parsed for Google advertising parameters (gclid, gad_source, gad_campaignid) to flag paid-advertising traffic. Where the Customer runs the Reditus script together with a HubSpot form or meetings widget, or with a Calendly booking widget, on the same page, the integration transmits the end user's email address by default; a Customer that does not want that disables the integration and sends an internal identifier instead.

Internal identifiers instead of email addresses. The Customer may send an internal identifier instead of an email address; where the Customer does so and does not connect the Stripe, HubSpot or Calendly integrations, Reditus does not receive the referred person's email address. This is not a separate product mode: the endpoint accepts either identifier and stores both when both are sent, Reditus's own installation documentation asks Customers to send both, and the in-app snippet builder offers the email field. The identifier is free text and is not enforced to be opaque, so the resulting data is pseudonymous, not anonymous, and the tracking script transmits the full page address, the referrer and a truncated IP address in every configuration in which it runs. A Customer may instead integrate through the Reditus API alone, without installing the tracking script, which removes the cookie and the browser-side collection.

Cookies. Three first-party cookies are involved. None of the three sets the Secure, SameSite or HttpOnly attributes. The tracking script uses no localStorage and no sessionStorage.

| Cookie | Set by | Contents | Lifetime | |---|---|---|---| | _gr_id | The tracking script, and only when an attribution parameter is present in the address, so an ordinary visitor who arrives without one receives no cookie | An eleven-field payload: the random version 4 attribution UUID, captured campaign and source values, the Customer's own internal uid where sent, and a free-form sid value | 60 days by default, configurable from 1 to 119 days. The expiry is refreshed on each qualifying visit (a sliding window), so actual retention on a returning visitor's device can exceed the configured period | | _gr_cookietest | The referral widget, not the tracking script | A cookie-support check; no personal data | Transient | | _gr_referral_widget | The referral widget, where the Customer enables it | Held in cleartext: the advocate's email address, first name, last name, company name, company identifier, product identifier, and an authentication token (a JWT) | 30 days |

Retention schedule. Where a period is marked open, Reditus retains that category no longer than necessary for the purposes above, and in any event deletes or irreversibly anonymises it within 12 months after the end of the Terms of Service (backups: 12 months from the backup date, subject to row 9), subject to clause 13.4.

| # | Category | Retention | |---|---|---| | 1 | Customer account and user records | For the life of the Customer account, because the records power the Customer's and affiliates' dashboards and reporting. On termination, exported and deleted under clause 13 (60 day export window, deletion within the 120 day longstop); earlier deletion on request to the Privacy Contact. | | 2 | Affiliate and advocate records | Deleted when the Customer account is deleted: account deletion cascades to the account's programmes, advocates, enrolments and related records. Deleting a programme does not cascade. Advocate records belong to the Customer account rather than to a single programme, and the Services provide no route to destroy a referral programme, so programme-level deletion cannot be relied on to remove affiliate data. Two carve-outs survive account deletion: generated reports are retained, and payout records are not deleted but have their link to the deleted person removed. Account deletion is administrator-initiated by Reditus on request under clause 5.1; there is no self-service deletion. | | 3 | Raw click, visit and referral events | Client IP addresses are truncated at the point of collection, to a /24 network for IPv4 and a /40 prefix for IPv6. Event records are retained for the life of the account and deleted with it, because they underlie the Customer's and affiliates' reporting. There is no separate anonymisation job that runs at the end of the cookie window. | | 4 | Conversion, subscription and commission records | Raw Stripe webhook payloads: deleted by a scheduled job once older than 2 days. The general webhook event store has no scheduled cleanup and is retained until the account is deleted. Legacy Paddle data survives from the period before the migration to Stripe: raw Paddle webhook payloads in the paddle_webhooks table, and Paddle customer records holding email addresses and names in the paddle_customers table. The Paddle connection is switched off, no Customer uses it, and Paddle is not a Sub-processor; the two stores are legacy personal data and are scheduled for deletion. Derived conversion and commission records: for the life of the programme and account (they underlie commission calculations and dashboards), then deleted under rows 1 and 2. Where a commission links to a payment receipt, Reditus stores only a link into the Customer's own Stripe account, shown to the Customer alone; the receipt itself is not stored by Reditus. | | 5 | Payout identifiers (PayPal email address, IBAN, tax identifier) | Deleted when the affiliate record is deleted. Affiliates cannot remove their own payout details: the Services expose no delete action for a stored payment method, and there is no self-service account deletion for affiliates or Customers. Removal is administrator-initiated by Reditus on request under clause 5.1. The IBAN is encrypted at application level; the PayPal email address and the tax identifier are stored in plaintext. Each identifier is collected for a payout rail that is actually in use: commissions are paid through PayPal, through direct bank transfer to the affiliate's IBAN, and through Wise. | | 6 | Payout transaction records | Until the account is deleted, which is administrator-initiated on request under clause 5.1 rather than self-service. On deletion the payout record itself is retained with its link to the deleted person removed, as row 2 states; records that form part of Reditus's own statutory accounting are kept for 7 years under Dutch law. | | 7 | Support conversations | In-product support chat on the authenticated application runs on HubSpot Conversations and receives the logged-in user's email address with a signed identification token; the chat and product feedback widget on the getreditus.live marketing site runs on Featurebase (CORDNET OU). Conversations are kept for the duration of the relationship and deleted with the account or on request. | | 8 | Product analytics, error diagnostics and session recordings | Session replay runs in Sentry only, with all text masked and all media blocked; it is not enabled in the product analytics tool. Analytics and error events: retained while the account is active, deleted with it. | | 9 | Backups | 7 days: daily snapshots with rollback to any day in the preceding 7 days; deleted data ages out with that window. No longer-term or off-platform archive exists (confirmed 4 August 2026). | | 10 | Cookies | _gr_id 60 days by default, configurable 1 to 119 days, on a sliding window that is refreshed on each qualifying visit, so real retention on a returning device can exceed the configured period; _gr_cookietest transient, set by the referral widget; _gr_referral_widget 30 days |

Annex A2: Processing activities where Reditus is a Controller

| Type | Description | |---|---| | Service Data | Account administration, billing and invoicing, security and fraud prevention, product analytics and error diagnostics concerning the use of the Services, and compliance with Reditus's own legal obligations. Reditus decides the purposes and means and is accountable in its own right. | | Network, marketplace and recruitment-database profiles | Profiles in the Reditus affiliate network, marketplace and recruitment database, until an affiliate joins the Customer's programme. Two populations: registered affiliates, who created a Reditus account and accepted the Reditus affiliate terms, and non-registered candidates, compiled from publicly available sources, whose Article 14 notice is section 6 of the Reditus privacy notice. Candidate records (name, email address, job title, LinkedIn handle and company data) are held in a second, separate database project and are scored and enriched by the pipeline described at clause 10.2. | | Data subject types | Customer account users (Service Data); affiliates and candidate affiliates in the Reditus network (profiles). | | Duration | As set out in the Reditus privacy notice. | | Governing document | The Reditus privacy notice at https://www.getreditus.live/privacy-policy. This processing is not on the Customer's instructions and not governed by this DPA; it is described here for transparency about marketplace profiles. |

Annex B: Security measures

Technical and organisational measures protecting Customer Personal Data, stated as they exist today.

| Type | Description | |---|---| | Physical access controls | Reditus operates no data centre and has no facility of its own; production data resides in the facilities of the infrastructure providers in Annex C Table 1. Hetzner Online GmbH holds ISO/IEC 27001:2022, certified by SOCOTEC Certification Deutschland GmbH, covering its hosting services and data centres; Supabase Pte. Ltd states that it holds SOC 2 Type 2 and ISO/IEC 27001. Those certifications belong to those providers: Reditus holds no security certification of its own and does not present a provider's certificate as its own. | | Encryption in transit | All Reditus web properties, the application, the API and the tracking endpoint are served over HTTPS; TLS is terminated at the Cloudflare edge. | | Encryption at rest | Customer Personal Data at rest is held in the managed database (Supabase) and in Cloudflare R2 object storage, both of which apply encryption at rest to the underlying storage media. This protects the storage media; it does not prevent access by the infrastructure providers in Annex C Table 1 and does not stop an attacker holding an authorised application session. | | Application-level field encryption | Above the storage layer, specific fields are encrypted by the application itself using Rails ActiveRecord Encryption, so their values are not readable in a database dump or by a database-level reader: affiliate IBANs, API key tokens, and Customer-held integration secrets including payment-provider secrets, webhook signing secrets and Slack access tokens. Affiliate PayPal email addresses and tax identifiers are not encrypted at field level. | | Authentication and session management | Authentication is self-hosted in the Reditus application (Devise); it is not a managed service of the database provider. Passwords are stored only as bcrypt hashes, cost factor 11, in Reditus's own database. API session tokens are stored as SHA-256 hashes, not bcrypt, and expire two weeks after issue; expiry is enforced when a token is read, and expired session rows are not currently purged from the database. Each session record stores the IP address and the user agent it was created from. | | Access control and least privilege | The platform enforces role-based separation between merchant users and affiliates, with permissions at user and organisation level; a Customer's users see only their own account, and an affiliate only their own referrals, commissions and payouts. Personnel access to production is limited to those who need it for their role and removed promptly on role change or departure. | | Data segregation | Customer data is logically segregated per account through application-level access controls: authorisation is enforced in the application layer by Pundit policies, applied on a mandatory basis so that an unauthorised action fails rather than defaults open. Tenants share a single database schema and there is no database row-level security; the control is the application layer, and this Annex does not describe it as anything stronger. | | Pseudonymisation and minimisation | The _gr_id referral identifier is a randomly generated version 4 UUID created in the visitor's browser, derived from nothing about the visitor or their device. The tracking script and referral widget perform no device fingerprinting, and use no localStorage and no sessionStorage. Two honest caveats: the tracking pixel is an image request, so ordinary request headers carry the User-Agent string and the source IP address; and IP address is used for fraud correlation, truncated to a /24 network for IPv4 and a /40 prefix for IPv6 at the point of writing. No attribution cookie is written for a visitor who arrives without an attribution parameter. A Customer may send an internal identifier instead of an email address, within the limits stated at clause 4.3. | | Output minimisation | Email addresses of referred people shown to affiliates are masked by default. The Customer controls this: full visibility can be switched on for a given partnership. Masking is the default state and unmasking is the Customer's decision, not Reditus's. | | Integrity of commission records | Commission state is managed by a state machine, and each commission carries the timestamp of its current state. Reditus does not maintain a full state-transition history for commissions or payouts: the state timestamp is overwritten on each transition, payout payments have no state machine, and a payout payment record is deleted outright if all of its commissions are rejected. Append-only audit logs do exist for campaign enrolment events and for administrator impersonation events. | | Build pipeline | Changes go through version-controlled repositories and continuous integration. Deployment to production runs automatically on merge to the master branch; the gate is merge review and branch protection in the source control system, not a separate manual deployment step. Every build runs static security testing (Brakeman) and linting (RuboCop, ESLint), plus an RSpec test suite whose line coverage is approximately 95%. Coverage is measured but not enforced: no build fails on a coverage drop. Dependency vulnerability scanning does not currently run; it is disabled in both the CI pipeline and the pre-commit hooks pending a framework upgrade. | | Rate limiting and abuse controls | Application-level rate limiting (Rack::Attack) is enabled in production, with six throttles covering authentication and other sensitive endpoints. Fraud detection on referral events covers self-referral by matching email address, self-referral by IP range, and detection of paid-advertising traffic. There is no duplicate detection, and the flags are advisory only: nothing is automatically rejected on the basis of them. IP address is processed for these purposes, not to build cross-site profiles. | | Edge protection | All Reditus properties sit behind Cloudflare, providing DNS, reverse proxying and network-layer DDoS mitigation. | | Environment separation | Production data copied into the staging environment is anonymised by an automated task that fails if it meets a column that has not been classified for personal data. This protects the staging environment. It is not a data-subject erasure mechanism and is not offered as one. | | Backups | Daily snapshots of the production database with rollback to any day in the preceding 7 days, taken by the managed database service. | | Monitoring | Frontend errors and exceptions on the authenticated application are captured by Sentry, whose session replay is configured to mask all text and block all media; there is no Sentry agent in the backend. Backend errors are captured by Honeybadger, used for error tracking only: its log-ingestion product is disabled, application logs are written to standard output rather than shipped to it, and error reports carry no user-context tagging. Product analytics run in PostHog, where session replay is not enabled. Database and background-job monitoring run on self-hosted tooling. Alerts are reviewed by engineering. | | Incident response | Personal Data Breaches are handled under clause 6: notification within 48 hours of awareness, written root cause analysis within 30 days of containment. |

Reditus may replace any individual measure as clause 4.2 provides. Planned improvements are published at https://www.getreditus.live/security and move into this Annex only when implemented.

Annex C: Sub-processors and other vendors

Table 1: Approved Sub-processors of Customer Personal Data

Maintained at https://www.getreditus.live/sub-processors. Entries marked (newly disclosed) are existing engagements named here for the first time, not new appointments, so the clause 9.2 notice period is not triggered by their appearance in this list.

| Name (legal entity) | Purpose | Location | Transfer mechanism | |---|---|---|---| | Hetzner Online GmbH | Hosting of the application, API and supporting infrastructure | Nuremberg, Germany | None (EEA) | | Supabase Pte. Ltd | Primary application database only. Supabase does not provide file storage or authentication for the Services. | Frankfurt, Germany (Singapore contracting entity) | SCCs, Module Three (no Singapore adequacy decision; data rests in the EU) | | Amazon Web Services, as sub-sub-processor beneath Supabase (newly disclosed) | Underlying cloud infrastructure on which the Supabase EU project runs. AWS is not a direct Reditus vendor; see Note 4. | | Inherited through the Supabase contract and the SCCs referenced in the Supabase row | | Cloudflare, Inc. | DNS, CDN, WAF, TLS termination and edge compute; object storage (Cloudflare R2) holding files uploaded through the Services; and hosting and serving of the Reditus tracking script | Global edge network; TLS terminates at the point of presence nearest the visitor | SCCs, Module Three; EU-US Data Privacy Framework self-certification as a supplementary fact | | Stripe Payments Europe, Limited | Payment processing and, where the Customer connects its Stripe account, reading transaction data to attribute commissions | European Economic Area | None (EEA) at the top level | | PayPal (Europe) S.à r.l. et Cie, S.C.A. | Affiliate commission payouts, the default payout rail. Reditus stores the affiliate's PayPal email address and uses it to pay commissions; there is no automated PayPal API integration in the Services. Commissions are paid on three rails in all: PayPal, direct bank transfer to the affiliate's IBAN, and Wise. The direct transfer leg runs through Reditus's own bank account, so it is not a Sub-processor disclosure; the other two rails are the two rows here. | European Economic Area | None (EEA) | | Wise Europe SA | Affiliate commission payouts on the Wise rail, one of the three rails described in the PayPal row. Payouts here are initiated operationally rather than through an API integration in the Services. Affiliate IBANs are stored in the affiliate record and encrypted at application level. | European Economic Area | None (EEA) | | Twilio Inc., trading as Twilio SendGrid | Transactional email sent by the Services, and synchronisation of contact records for Reditus's marketing email | United States | SCCs, Module Three | | Functional Software, Inc., doing business as Sentry | Frontend error tracking and diagnostics for the authenticated application, including session replay configured to mask all text and block all media. There is no Sentry agent in the backend. | United States (Sentry US region) | SCCs, Module Three; EU-US Data Privacy Framework self-certification as a supplementary fact | | PostHog, Inc. | Product and website analytics. Identified profiles carry the user's email address, full name, account MRR and plan. Session replay is not enabled in the application's PostHog configuration. | Frankfurt, Germany, at rest, through an EU ingestion endpoint; United States contracting entity, and the analysis interface is served from a United States host | SCCs, Module Three (data rests in the EU; US contracting entity) | | Honeybadger Industries LLC | Backend error tracking only. Its log-ingestion product is disabled, application logs are written to standard output rather than shipped to Honeybadger, and error reports carry no user-context tagging. | United States | SCCs, Module Three | | Plane Software, Inc. | Issue tracking, where Reditus creates its tickets. A ticket can contain the identity and contact details of the person who raised it, together with whatever they included in their report, and nothing beyond that. | United States (Delaware entity, hosted cloud service running on Amazon Web Services) | SCCs, Module Three | | HubSpot (newly disclosed) | Two roles in which HubSpot receives Customer Personal Data. (a) In-product support chat: the chat widget is mounted on every page of the authenticated application and identifies the visitor with a signed token, so it receives the email address of every logged-in user. (b) CRM synchronisation: affiliate and advocate records (name and email address) are synchronised from the Services into Reditus's own HubSpot CRM. HubSpot's third role, the integration a Customer connects to its own HubSpot account, is a different legal relationship and is covered by Note 1, not by this row. | See Note 6 | See Note 6 | | Calendly (newly disclosed) | Server-side resolution of a booking invitee's name and email address for attribution. Where the Customer connects its own Calendly account, Note 1 also applies to that leg. | See Note 6 | See Note 6 | | User.com (newly disclosed) | Notification and messaging service receiving referral, lead and advocate email addresses, names and countries from the Services | See Note 6 | See Note 6 | | Slack (newly disclosed) | Internal Reditus notifications generated by the Services, roughly thirty message types including affiliate creation and commission payment events, which carry affiliate identifying data into Reditus's internal Slack workspace | See Note 6 | See Note 6 | | LinkedIn (newly disclosed) | The OAuth connection an affiliate makes to their own LinkedIn account, from which the Services read and store the affiliate's profile data in a dedicated store. Listed here on the conservative view: as Note 7 explains, the direction of travel makes this an affiliate-authorised read grant rather than an onward disclosure by Reditus, but the connection is implemented in the Services and the profile data it returns is retained, so Reditus discloses it as a Table 1 entry rather than argue itself out of the listing. LinkedIn's separate role in Reditus's own marketing is covered by Note 2. | See Note 6 | See Note 6 | | Paragon (newly disclosed) | Embedded integration platform running in the authenticated frontend, through which Customer integrations are configured and data is brokered | See Note 6 | See Note 6 | | n8n Cloud (newly disclosed) | Automation platform brokering the AI lead-discovery and affiliate-matching pipeline described at clause 10.2. It receives the Customer's search and ideal-customer-profile criteria, calls the model and the enrichment vendors, and returns scored matches; the inbound webhook stores the full unfiltered response body. Listed here on the conservative view of the role split. | See Note 6 | See Note 6 | | Google Tag Manager, operated by Google (newly disclosed) | Tag container loaded in the authenticated application in production (container GTM-PSMWBCS). A tag container can load further third-party tags, so the set of scripts it introduces is a configuration choice rather than a fixed list. | See Note 6 | See Note 6 |

Table 2: Vendors for which Reditus is the controller

These are not Sub-processors of Customer Personal Data and are not covered by the clause 9 notice and objection procedure. They are set out here because they are live, and because a vendor placed in this table has to be disclosed in the Reditus privacy notice instead. Note 5 records the placement decisions and what the privacy notice has to pick up. This table and section 8.1(b) of the Reditus privacy notice are the same list, rendered from one source; where the two ever differ, the published sub-processor page at https://www.getreditus.live/sub-processors is canonical.

| Name (legal entity) | Purpose | Personal data involved | Location | |---|---|---|---| | CORDNET OU (registry code 14748498), Kaluri tee 4-32, Viimsi vald, trading as Featurebase | The chat and product feedback widget on the getreditus.live marketing site, processing in the Netherlands, Germany and Ireland. The in-product chat on the authenticated application is HubSpot Conversations (Table 1). | Marketing-site visitors and prospects who open a chat or post feedback | Estonia (entity of establishment) | | POSITIVE GROUP SALES SOLUTIONS SAS, trading as NoCRM.io | Reditus's internal sales CRM. The entry sits in this table rather than Table 1 because it carries Reditus's own account-relationship data, not affiliate or referred-lead data held for a Customer. | Reditus's own prospects and its own customer account contacts, synchronised automatically from the Services | Hem, France | | Hunter Web Services, Inc. | Work-email discovery and verification for candidate affiliates in the recruitment pipeline. The call is made inside n8n and the enriched personal data is stored in Reditus's own systems. | Candidate name, email address and LinkedIn profile | Delaware, United States | | Google, for the Gemini API | The model called inside the n8n pipeline to score, rank and explain candidate matches | Candidate contact records: name, email address, job title, LinkedIn handle | See Note 6 | | DataForSEO OU (company number 14502291), Vesivarava tn 50-201, Tallinn | Public web and search data about candidate sites and companies, and search and AI-answer data for the public tools on the Reditus marketing site | None in the recruitment pipeline: site and company data only. The public tool passes the free-text category a visitor types in | Estonia, with operations at 63 Profesora Otamanovskoho Street, Kharkiv, Ukraine. Ukraine has no EU adequacy decision, so the Standard Contractual Clauses are required and the Estonian registration alone is not sufficient | | Supabase Pte. Ltd, second project (newly disclosed) | A second, separate database project holding the AI recruitment pipeline's data, including scraped, non-registered candidate profiles. Distinct from the production application database in Table 1. | Candidate contact records: name, email address, job title, LinkedIn handle, plus company data | See Note 6 | | Google Ireland Limited, for the browser Google Analytics 4 tag | Reditus's own product analytics on the authenticated application interface. Does not run on the marketing site. | Online identifiers, page addresses and IP address, with IP dropped at the EU collection endpoint | Ireland (entity). Collected in the EU and then forwarded to Google servers in the United States, which is not EU residency | | Google Analytics 4, operated by Google, server-side (newly disclosed) | Reditus's own analytics: the Reditus backend sends a server-side event when a Customer installs the tracking script. Distinct from the browser tag above and from the Google Analytics 4 property an affiliate may connect to their own account. | | See Note 6 | | Google Cloud EMEA Limited | Google Workspace: staff email, documents, spreadsheets and calendar | Business contact data of anyone Reditus corresponds with | Ireland, with Google LLC (United States) as a listed sub-processor for data centre operations | | Dealfront Finland Oy, trading as Leadfeeder Finland, with Dealfront Group GmbH (Karlsruhe, Germany) as parent | IP-based company identification of visitors to Reditus's own web properties | Visitor IP address, the reverse lookup of the IP owner, and page addresses | Finland, with a German parent. Dealfront's own chain reaches United States recipients under the Clauses | | Sanity (contracting entity to be established: Sanity US Inc. or Sanity AS) | Content management for the Reditus marketing site | Author profiles and named case-study contacts | United States or Norway. Content stored on Google Cloud in Belgium | | Mintlify, Inc. | Hosting of docs.getreditus.live | Documentation visitor telemetry | United States | | SaaSflow OU, trading as Guideflow | Interactive product demo embeds on the Reditus marketing pages | Visitor identifiers set by the demo player, approximate location from IP address | Estonia | | Better Stack, Inc. | Uptime and availability monitoring, and the public status page at status.getreditus.live | Name, email address and IP address of status-page visitors and subscribers | United States. The status page itself is served from Hetzner in Germany | | Deluxe Custom Apps LLC, trading as GlockApps | Receipt of email authentication (DMARC) reports for the Reditus domains | Email authentication metadata, including sending IP addresses, and, where forensic reporting is enabled, recipient email addresses | United States | | Sprinto (contracting entity to be established: Sprinto Inc. or Sprinto Technology Private Limited) | Compliance automation and the Reditus trust centre | Published compliance content, plus the email address of anyone requesting a document through the trust centre | United States or India | | Open Exchange Rates | Currency conversion rates for commission and payout amounts | None | See Note 6 | | GitLab | Source control and continuous integration | None from production; the repositories hold no production personal data, though the pipeline holds deployment secrets | See Note 6 |

Notes:

1. Integrations the Customer connects are not Reditus Sub-processors. Where the Customer connects its own HubSpot, User.com, Slack, Calendly, Google Analytics, YouTube or LinkedIn account, or its own systems via the Reditus API and webhooks, that vendor is the Customer's processor: Reditus sends the data to the Customer's own account with a vendor the Customer chose. Several vendors appear both here and in Table 1, and the distinction is which account the data lands in. HubSpot is the clearest case: the Customer-connected OAuth integration pushes data into the Customer's HubSpot portal and is governed by this Note, while the in-product support chat and Reditus's own CRM synchronisation push data into Reditus's HubSpot portal and are governed by Table 1.

2. Reditus's own marketing. Google Ads and LinkedIn advertising run on Reditus's own web properties for Reditus's own marketing, as independent controllers, and are disclosed in the Reditus privacy notice, not here. LinkedIn is not marketing-only: it also appears in Table 1 for the affiliate OAuth connection, from which the Services read and store an affiliate's LinkedIn profile data.

3. Purely internal tooling. Vendors that process no personal data connected with the Services and hold no production data, such as internal workspace and documentation tools, are maintained in Reditus's internal vendor register rather than in this Annex. The three borderline cases the audit raised, Better Stack, Open Exchange Rates and GitLab, have been placed in Table 2 as a deliberate call rather than left to a general note.

4. Amazon Web Services and Cloudflare R2. The Reditus application uses the aws-sdk-s3 and fog-aws libraries, but these speak the S3 protocol to Cloudflare R2, not to Amazon Web Services. AWS appears in this Annex only underneath other vendors, as the cloud beneath the Supabase EU project and as the cloud on which Plane's hosted service runs, never as a direct Reditus vendor.

5. For the privacy notice. The following entries sit in Table 2 rather than Table 1, which means the Reditus privacy notice, not this Annex, is where they must be disclosed to data subjects: Featurebase (marketing-site chat and feedback), NoCRM.io, Hunter Web Services, Inc., Google (Gemini API), DataForSEO OU, the second Supabase project holding scraped candidate profiles, the browser and server-side Google Analytics 4 properties, Google Workspace, Dealfront / Leadfeeder, Sanity, Mintlify, Guideflow, Better Stack, GlockApps, Sprinto, Open Exchange Rates and GitLab. Every one of them now has a named row in privacy notice section 8.1(b); the audit's point about Better Stack, Open Exchange Rates and GitLab was that the call had to be conscious and written down, and naming them in both places is how that is discharged. The second Supabase project and the Gemini pipeline also bear on the Article 14 notice for non-registered candidates.

6. Still to be established.

7. Two placement calls, recorded rather than assumed. LinkedIn sits in Table 1 even though the affiliate OAuth connection runs in the opposite direction from an ordinary onward disclosure: the affiliate authorises Reditus to read their own profile, so LinkedIn is the source rather than the recipient, which is the reasoning section 8.4 of the privacy notice applies to YouTube and Google Analytics. Reditus lists it in Table 1 anyway, because the connection is implemented in the Services, the returned profile data is stored against the affiliate record, and a listing that is arguably too generous costs a Customer nothing while an omission costs it an Article 28 finding. Google Tag Manager sits in Table 1 for a different reason: the container loads on authenticated pages used by the Customer's affiliates, and because a tag container can introduce further tags without any change to the Reditus application, the honest classification is the one that gives the Customer the clause 9 notice and objection right over it. Version 1.0 carried Google Tag Manager only in the controller-side table; that has been corrected here and in the privacy notice together.

---

*End of the Reditus Data Processing Agreement, version 1.3 (concise edition), effective 5 August 2026. This concise edition is the edition published at https://www.getreditus.live/dpa and the only edition Reditus offers for signature. Reditus B.V., Kapelweg 12, 3951 AC Maarn, Netherlands, KvK 77814487, VAT NL861156420B01.*