This Data Processing Addendum (“DPA”) forms part of the agreement (“Agreement”) between the customer identified in the Agreement (“Customer”) and the Cyprus company being incorporated under the intended name KabData (“Provider”) for the KabData Service. Before this DPA becomes effective, Provider’s full registered legal name, Cyprus registration number, registered office, and effective date will be inserted here.

This DPA applies to Provider's processing of Customer Personal Data on Customer's behalf. It does not apply where Provider processes personal data as an independent controller, as described in the KabData Privacy Policy.

1. Definitions

Capitalised terms not defined here have the meanings in the Agreement.

“Applicable Data Protection Law” means each privacy or data-protection law applicable to the processing of Customer Personal Data under the Agreement, including where applicable:

Regulation (EU) 2016/679 (“EU GDPR”);
Cyprus Law 125(I)/2018 on the protection of natural persons with regard to the processing of personal data and the free movement of such data;
the EU ePrivacy rules as implemented in relevant EEA member states;
the UK GDPR, Data Protection Act 2018 and Privacy and Electronic Communications Regulations 2003 (“UK Data Protection Law”);
Israel's Protection of Privacy Law, 5741–1981, as amended, and regulations made under it, including the Privacy Protection Regulations (Data Security), 5777–2017, the Privacy Protection Regulations (Transfer of Data to Databases Abroad), 5761–2001, and the Privacy Protection Regulations (Instructions for Data Transferred to Israel from the European Economic Area), 5783–2023; and
another law expressly identified in an Order Form as applicable to Provider's processing.

“Controller”, “Data Subject”, “Personal Data”, “Personal Data Breach”, “Process”, “Processor” and “Supervisory Authority” have the meanings in Applicable Data Protection Law.

“Customer Personal Data” means Personal Data within Customer Data that Provider Processes on Customer's behalf under the Agreement.

“Restricted Transfer” means a transfer of Personal Data requiring an adequacy decision/regulation, appropriate safeguards or another transfer mechanism under Applicable Data Protection Law.

“Subprocessor” means a Processor engaged by Provider to Process Customer Personal Data on Customer's behalf. It does not include Provider personnel or a Third-Party Service contracted directly by Customer where Provider merely connects to it at Customer's direction.

2. Roles and scope

2.1 Roles

For Customer Personal Data, Customer is the Controller and Provider is the Processor. If Customer is a Processor for another Controller, Customer appoints Provider as a Subprocessor and represents that it is authorised to do so. Each party will comply with the obligations applicable to its role.

Customer is an independent Controller for its selection of data sources, Data Subjects, Authorised Users, permissions, tracking parameters, reports, notifications, integrations and automations. Provider is an independent Controller for its own account administration, business contacts, contracting, billing, legal compliance and Service security, subject to its Privacy Policy.

2.2 Processing details

The subject matter, duration, nature, purpose, Data Subjects and categories of Customer Personal Data are described in Annex 1 and the applicable Order Form.

2.3 Customer instructions

Provider will Process Customer Personal Data only:

on Customer's documented instructions, including the Agreement, Order Forms, Customer's use and configuration of the Service and authorised support requests;
as necessary to provide, secure and support the Service; or
as required by applicable law.

If law requires Processing beyond Customer's instructions, Provider will notify Customer before Processing unless the law prohibits notice. Provider will promptly inform Customer if, in its reasonable opinion, an instruction infringes Applicable Data Protection Law. Provider may suspend the affected Processing until the parties agree a lawful instruction.

Customer is responsible for the lawfulness, fairness, transparency, accuracy and minimisation of Customer Personal Data and its instructions, including giving all required notices and obtaining all required rights and lawful bases.

3. Confidentiality and personnel

Provider will ensure that persons authorised to Process Customer Personal Data:

are bound by contractual or statutory confidentiality duties;
access it only on a need-to-know, least-privilege basis;
receive appropriate privacy and security instructions; and
Process it only in accordance with Customer's instructions, unless required by law.

Provider remains responsible for its personnel's compliance with this DPA.

4. Security

4.1 Measures

Provider will implement and maintain appropriate technical and organisational measures designed to protect Customer Personal Data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure or access, taking into account the state of the art, implementation costs, the nature, scope, context and purposes of Processing and the risks to Data Subjects. Current measures are described in Annex 2.

4.2 Changes

Provider may update security measures provided the overall level of protection is not materially reduced during a paid subscription term. No Annex 2 statement creates a certification, data-residency promise, recovery objective or service level unless expressly stated.

4.3 Customer security responsibilities

Customer will configure roles, permissions, exports, integrations and automations appropriately; secure endpoints and credentials; enable multi-factor authentication where proportionate; and notify Provider promptly of suspected compromise. Customer will not include credentials or unnecessary Personal Data in notification text, workflow descriptions or other ordinary text fields.

5. Subprocessors

5.1 General authorisation

Customer gives general written authorisation for Provider to use the Subprocessors listed in Annex 3 and on the then-current KabData Subprocessor List.

5.2 Requirements

Before a Subprocessor Processes Customer Personal Data, Provider will enter into a written agreement imposing data-protection obligations that are no less protective in substance than the obligations applicable to Provider under this DPA, to the extent relevant to the Subprocessor's services. Provider remains responsible for the Subprocessor's performance of those obligations as required by Applicable Data Protection Law.

5.3 Changes and objection

Provider will give at least 30 days' prior notice of a new Subprocessor by email or the published notification method, except where urgent replacement is necessary for security, law or continuity. Customer may object within 15 days on reasonable, documented data-protection grounds. The parties will work in good faith on a commercially reasonable alternative. If none is available, Provider may choose not to use that Subprocessor for Customer or Customer may terminate the materially affected Service before the Subprocessor begins Processing and receive a pro-rata refund of prepaid unused fees for it. This is Customer's exclusive remedy for a valid Subprocessor objection.

5.4 Customer-directed services

AppsFlyer and other accounts contracted and controlled directly by Customer are Customer-directed Third-Party Services rather than Provider-appointed Subprocessors when Provider merely connects to them at Customer's instruction. Provider remains responsible for securing its connector and following Customer's instructions. Optional messaging providers may be Subprocessors where Provider engages them, or Customer-directed providers where Customer connects its own account; Annex 3 must reflect the production arrangement.

6. Assistance with Data Subject rights

Taking into account the nature of Processing, Provider will provide reasonable technical and organisational assistance for Customer to respond to requests to access, correct, delete, restrict, port or object to Processing of Customer Personal Data, or to exercise another applicable right.

If Provider receives a request relating to Customer Personal Data, it will not respond substantively except on Customer's instruction or as required by law. Where reasonably identifiable, Provider will refer the requester to Customer and notify Customer. Customer is responsible for verifying identity, deciding the response and meeting legal deadlines.

Provider may charge reasonable fees for assistance that is unusually burdensome or arises from Customer's systems or instructions, unless the assistance is required because of Provider's breach.

7. Personal Data Breaches

7.1 Notice

Provider will notify Customer without undue delay after becoming aware of a confirmed Personal Data Breach affecting Customer Personal Data. Notice will be sent to Customer's designated security/privacy contact. A failed attempt or event that does not compromise Customer Personal Data is not a Personal Data Breach.

7.2 Information and cooperation

To the extent known and permitted, Provider's notice will describe:

the nature of the breach and affected systems/data;
the categories and approximate number of affected Data Subjects and records;
likely consequences;
measures taken or proposed to contain, investigate and remediate it; and
a contact for follow-up.

Provider may provide information in phases and will reasonably cooperate with Customer's assessment, notification and remediation obligations. Provider's notice is not an admission of fault or liability.

7.3 Customer responsibility

Customer is responsible for notifying Supervisory Authorities, Data Subjects and other parties unless law expressly places that duty on Provider. Provider will not notify them about Customer's breach without Customer's instruction, except where legally required.

8. DPIAs, consultations and records

Taking into account the nature of Processing and information available to Provider, Provider will provide reasonable assistance with Customer's data-protection impact assessment and prior consultation obligations under Articles 35 and 36 EU/UK GDPR or comparable law.

Provider will maintain records of Processing required of it and cooperate with a competent Supervisory Authority as required by law. Customer remains responsible for its own records, assessments and consultation decisions.

9. Demonstrating compliance and audits

9.1 Information

On reasonable written request, Provider will make available information necessary to demonstrate compliance with this DPA, which may include a security summary, questionnaire responses, relevant policies or independent audit/certification reports if then available.

9.2 Audit process

If the information is insufficient, Customer may conduct one audit in any 12-month period, and additional audits following a confirmed Personal Data Breach or a binding request from a Supervisory Authority. Audits must:

be limited to systems and records relevant to Customer Personal Data;
be performed by Customer or an independent auditor that is not a Provider competitor and is bound by confidentiality;
occur on at least 30 days' notice during normal business hours, unless urgent law or a breach requires less notice;
avoid access to other customers' data, penetration testing and disruption; and
comply with Provider's reasonable security requirements.

Customer bears audit costs unless the audit identifies a material breach by Provider, in which case Provider will bear its reasonable internal costs and promptly remediate. The parties will first use remote/documentary audit methods where reasonably sufficient.

10. Return and deletion

During the subscription term, Customer may use available export functionality. On termination or expiry and Customer's written election, Provider will return or delete Customer Personal Data as described in the Agreement, unless law requires retention.

After the agreed export period, Provider will delete Customer Personal Data from active systems and routine backups according to its documented deletion cycle. Data retained by law or in isolated backups will remain protected, will not be used for another purpose and will be deleted when the retention requirement or backup cycle ends.

The intended launch commitments are:

post-termination export availability: 30 days;
deletion from active systems: within 30 days after the export window;
deletion/expiry from Hetzner's seven daily rolling Cloud Backups: generally within seven daily backup cycles after active deletion; and
AppsFlyer raw data, including raw-event archives: a 12-month rolling maximum from the relevant event date during an active subscription, followed by deletion within the active-system period after termination.

At Customer's reasonable request, Provider will confirm completion in writing. Customer is responsible for deleting data held in Customer-controlled Third-Party Services.

11. Restricted Transfers

11.1 Cyprus/EEA to Israel

Provider is intended to be incorporated in Cyprus and to operate with personnel in Cyprus and Israel. Once incorporated, a Cyprus/EEA-to-Israel transfer covered by the European Commission's adequacy decision for Israel may rely on Article 45 EU GDPR without additional transfer safeguards. The parties will monitor the continuing applicability and scope of the decision.

11.2 Other transfers

Provider will not make a Restricted Transfer unless it uses a valid mechanism under Applicable Data Protection Law. Depending on the transfer, this may include:

an applicable adequacy decision or regulation;
the European Commission Standard Contractual Clauses adopted by Implementing Decision (EU) 2021/914 (“EU SCCs”);
the UK International Data Transfer Addendum to the EU SCCs or UK International Data Transfer Agreement;
an exception/derogation permitted by law; or
another approved mechanism.

For transfers from Israel, Provider will comply with the Privacy Protection Regulations (Transfer of Data to Databases Abroad), 5761–2001, including obtaining required contractual commitments for onward recipients where applicable.

11.3 EU SCCs if required

If a transfer from Customer to Provider requires the EU SCCs and no other valid mechanism covers it, the parties will execute or are deemed to incorporate the unmodified EU SCCs using:

Module Two (Controller to Processor) when Customer is Controller, or Module Three (Processor to Processor) when Customer is Processor;
Clause 7 (docking) included;
Clause 9, Option 2 (general written authorisation), with the notice period in section 5.3;
the competent Supervisory Authority determined under Clause 13;
the laws of the Republic of Cyprus for Clause 17; and
the courts of the Republic of Cyprus for Clause 18.

Annexes 1–3 of this DPA will populate the corresponding SCC annexes to the extent applicable. The EU SCCs prevail over conflicting terms. The parties will complete a transfer impact assessment and supplementary measures where required.

11.4 UK transfers

If a transfer is restricted under UK Data Protection Law and not covered by UK adequacy regulations, the parties will execute the then-current UK transfer mechanism. Required table information will be drawn from the Agreement and Annexes 1–3. The UK transfer mechanism prevails for that transfer.

11.5 Government requests

Unless prohibited, Provider will notify Customer of a legally binding government demand for Customer Personal Data. Provider will review the demand, challenge it where there are reasonable legal grounds, disclose only the minimum legally required and document the response as required by applicable transfer safeguards.

12. US state privacy laws

To the extent a US state privacy law applies and recognises a “service provider”, “processor” or “contractor” role, Provider will act in that role for Customer Personal Data. Provider will not sell or share Customer Personal Data for cross-context behavioural advertising; retain, use or disclose it outside the business purposes in the Agreement; or combine it with personal data received from another person except as permitted by law to provide and secure the Service. Customer may take reasonable steps to ensure compliant use and require remediation consistent with section 9.

13. Liability and conflict

Liability arising under this DPA is subject to the limitations and exclusions in the Terms, applied in aggregate across the Agreement, except to the extent Applicable Data Protection Law prohibits limitation. If this DPA conflicts with the Terms on Processing of Customer Personal Data, this DPA controls. If the EU SCCs or UK transfer mechanism applies and conflicts with this DPA, that mandatory transfer instrument controls for the relevant Restricted Transfer.

14. Duration

This DPA starts when Provider first Processes Customer Personal Data and continues until Provider has deleted or returned it in accordance with section 10. Confidentiality, security and transfer protections continue for retained Customer Personal Data.

Annex 1 — Details of Processing

A. Parties

Data exporter / Customer

Name: As stated in the Order Form or Agreement
Address: As stated in the Order Form
Contact: Customer's account owner or designated privacy contact
Role: Controller, or Processor where it uses KabData for another Controller
Signature/date: Agreement or Order Form acceptance

Data importer / Provider

Name: KabData — Cyprus company under formation; full registered legal name to be inserted
Cyprus registration number: To be inserted after incorporation
Registered address: To be inserted after incorporation
Current correspondence address: Cyprus, Cyprus
Privacy contact: [email protected]
Role: Processor/Subprocessor
Signature/date: Agreement or Order Form acceptance

B. Subject matter and purposes

Hosting and operation of the KabData B2B SaaS platform, including:

AppsFlyer API and authorised-browser retrieval, storage, normalisation, aggregation and display;
attribution, event, revenue, geographic and fraud reporting;
publisher roles, permissions and token sharing;
deals, payout metadata, caps, wishlists and tracking links;
CSV generation and exports;
customer-configured notifications through enabled channels;
customer-configured automations and system-tool execution;
support, troubleshooting, security, backup and recovery; and
deletion, return and legal compliance.

C. Nature of Processing

Collection, receipt, access, retrieval, recording, organisation, structuring, storage, adaptation, parsing, aggregation, matching, filtering, querying, display, transmission, export, restriction, archiving, deletion and destruction.

D. Duration and frequency

Frequency: Continuous and recurring, based on user actions, scheduled synchronisation and configured workflows.
Duration: The applicable subscription plus the agreed export/deletion period and any legally required retention.
Integration credentials: Until removed, rotated, connection deletion or organisation deletion.
Temporary exports/logs: According to the retention schedule in the Privacy Policy and Provider's documented retention controls.

E. Categories of Data Subjects

Depending on Customer's configuration:

Customer and Affiliate personnel, contractors, administrators and members;
publishers, affiliates, agencies, advertisers and their personnel;
app users and prospective app users represented in AppsFlyer reports;
recipients of invitations and notifications;
customer business contacts; and
individuals whose identifiers or events Customer or its app sends to AppsFlyer.

F. Categories of Customer Personal Data

Identity/contact: name, business email, company, role, business contact details and invitation data.
Access/permission: organisation membership, role, publisher identifiers, permission dimensions/values and token shares.
Online/technical: IP address, device/network attributes, advertising/device identifiers, customer user ID, timestamps, session and request metadata.
Attribution/marketing: app ID, media source, campaign, channel, ad/ad-set, site/sub-parameters, clicks, impressions, installs and conversions.
App activity: event name/time/value, revenue, purchase/conversion metadata and customer-selected event parameters.
Location: country/region and any location field Customer makes available in a raw report.
Fraud/security: fraud, rejection/blocking, anomaly and Protect360 information.
Commercial: deal, payout model/amount, cap, tracking link, offer and wishlist information to the extent linked to a person.
Communications/integrations: notification text, recipient/channel/workspace/chat identifiers and connected-service metadata.
Automation: workflow definitions, configurations, validation results and action logs.
Credentials/secrets: encrypted AppsFlyer/API/login/TOTP/session data and connected-service tokens, where enabled.
Raw report data: any additional Personal Data included by Customer or AppsFlyer in authorised raw-data reports.

G. Special categories and sensitive data

The Service is not designed for special-category data, children's data, precise location, payment-card data, government identifiers, protected health information or biometric data. Customer must not submit such data unless expressly authorised in an Order Form or written amendment that specifies lawful basis, safeguards, access, retention and transfer conditions.

Fraud signals, financial/revenue information, credentials and persistent identifiers may be considered sensitive or “special sensitivity” information under some laws and will be protected accordingly.

H. Customer instructions for deletion

Customer may delete users, memberships, integrations, records or an organisation through supported controls or an authorised request. Organisation deletion is intended to remove tenant-scoped active data and storage artifacts. The production workflow and operational verification must meet the periods in section 10 before they are published.

Annex 2 — Technical and Organisational Measures

The measures below describe the controls intended to apply when this DPA becomes effective.

1. Governance and access

Privacy and security requests received at [email protected], with a named internal owner, deputy and escalation process to be documented before launch.
Access limited to authorised personnel based on job responsibility and confidentiality duties.
Customer-facing role model: organisation administrator, member and publisher, with publisher data further filtered by assigned permission values.
Organisation membership checked before tenant initialisation and switching.
Customer responsibility for role assignment and periodic review.
Platform-super-administrator access separated from ordinary tenant membership; support impersonation restricted and logged in application logs.

2. Tenant isolation

Single PostgreSQL database with logical tenant isolation using tenant_id on business records.
Global tenant query scopes on tenant-owned models and explicit scoping/authorisation checks for other integration/system tables.
Tenant-aware background-job initialisation and per-tenant queues/guards.
Composite tenant-aware constraints and tests for critical publisher access paths.

3. Authentication and session security

Password hashing through Laravel's supported password-hashing mechanism.
Password-strength validation and password-confirmation controls for sensitive settings.
Email verification.
Optional time-based one-time-password two-factor authentication with encrypted secrets/recovery codes.
Login and 2FA rate limiting.
Session rotation on authentication, HTTP-only session cookies, configurable Secure and SameSite attributes, and CSRF protection.
OAuth access controls and throttling for the authenticated MCP interface.

4. Encryption and secret handling

TLS/HTTPS for Service access and supported outbound provider/API connections.
Application-level encryption at rest for supported AppsFlyer tokens, crawler credentials/TOTP/session state, Microsoft Teams secrets/refresh tokens, Slack bot tokens and user 2FA secrets.
Secrets excluded from model serialization and redacted from crawler/test output.
Production secrets supplied through protected environment/configuration rather than source code, with access limited to authorised operations personnel.

5. Network and application security

CSRF validation for state-changing web requests, with narrowly scoped authenticated webhook exceptions.
Rate limits on authentication, onboarding, MCP and system-tool endpoints.
Allowed-host/base-URL restrictions for AppsFlyer API connections to reduce server-side request forgery/exfiltration risk.
Request validation, route authorisation and resource scoping.
TLS, hosting-provider network protections, configured firewalls and Cloudflare edge controls.
Dependency review, security updates, secure-development practices and risk-based security testing.

6. Logging, monitoring and incident handling

API, synchronisation, crawler, workflow/system-tool and application logs appropriate to the feature.
Redaction of credentials, cookies, tokens, sensitive URLs and filesystem paths from crawler protocol/report output.
Operational health and queue monitoring.
Time-bounded retention for API, sync, crawler, crawler-test and failed-job logs.
Incident-response and breach-assessment procedures, escalation contacts, evidence preservation and notification workflow.

7. Availability, backup and recovery

Scheduled background jobs with uniqueness/overlap controls and tenant guards.
Private export/object storage with temporary authorised download controls where configured.
Raw-event monthly partitioning and archive verification before a hot partition is dropped.
Hetzner Cloud Backups are created daily for servers located in Germany, with seven rolling backup slots. The oldest backup is deleted after the next backup is successfully created. Provider must verify recovery procedures and restore tests. Hetzner identifies encryption at rest for Cloud Server backups as the customer's responsibility, so encryption of these backups is not represented as implemented until Provider configures and verifies an appropriate customer-controlled measure.
No contractual SLA, RPO or RTO is created unless an Order Form states it.

8. Data minimisation and lifecycle

User-selectable roles and publisher-level filters.
Filtered/versioned AppsFlyer browser storage state; unrelated analytics/ad-network cookies excluded from stored crawler sessions.
Temporary crawler reports/runtime state cleaned after bounded periods.
Export files automatically expire after seven days.
Scheduled pruning for API, sync, crawler, crawler-test and failed-job records.
Tenant deletion service removes tenant database records, tenant queues where supported, private files, exports, logos, tokens and crawler artifacts.
AppsFlyer raw-data maximum: 12 months from the relevant event date during an active subscription; tenant archives are deleted within the active-system deletion period after termination.

9. Subprocessor and personnel controls

Due diligence proportionate to vendor risk.
Written confidentiality and data-protection terms.
Transfer mechanism and location review.
Access revocation on role or employment change.
Periodic security/privacy training and access review.

10. Testing and assurance

Automated unit, feature, integration and security-oriented tests for authentication, tenancy, permissions, crawler redaction, onboarding, OAuth/MCP and deletion paths.
Change review and controlled deployment process.
Periodic risk assessment and testing required by the applicable Israeli database security level.

Annex 3 — Subprocessors

Provider’s current authorised subprocessors, their purposes, relevant data, locations, and status are listed on the KabData Subprocessor List. That list is incorporated into this DPA. Customer-directed providers are identified separately because they are ordinarily engaged by Customer rather than appointed by Provider.

Provider will maintain the list and handle additions or replacements under section 5, including the applicable advance-notice and objection process.