Data Processing Agreement

Version: 0.1-draft Effective date: not yet in force (draft) Status: Draft pending review by a qualified Romanian lawyer before use. Do not sign or publish in this form.

1. Parties, Scope and Incorporation

1.1. This Data Processing Agreement ("DPA") is entered into between:

(a) ALTTAB PROFIT SRL, a limited liability company incorporated in Romania, with its registered seat at Str. Doamna Oltea nr. 70, Sector 2, Bucharest, postal code 020231, Romania, registered with the Trade Register under no. J2004020548403, EUID {{EUID}}, sole registration code (CUI) RO17030480, share capital {{SHARE_CAPITAL}}, operating the 1ads platform available at https://app.1ads.net (the "Company"); and

(b) the customer identified in the Order Form (the "Customer"),

each a "Party" and together the "Parties".

1.2. This DPA forms part of, and is incorporated into, the Terms of Service (terms-of-service.md) and each Order Form signed by the Parties (together, the "Agreement"). It applies when, and to the extent that, the Company processes Customer Personal Data on behalf of the Customer in providing the Platform.

1.3. This DPA takes effect on the later of (i) not yet in force (draft) and (ii) the date on which the Order Form referencing the Agreement is signed by both Parties. It applies for as long as the Company processes Customer Personal Data, including after the Agreement ends (see Section 16).

1.4. The Platform is offered only to businesses, under a closed access program. The Customer confirms that it acts for purposes related to its trade, business, craft or profession and is not a consumer.

2. Definitions and Interpretation

2.1. Capitalised terms not defined in this DPA have the meaning given in the Agreement. The terms "controller", "processor", "data subject", "personal data", "processing", "personal data breach", "pseudonymisation" and "supervisory authority" have the meanings given in the GDPR.

2.2. In this DPA:

• "Account Data" means personal data the Company processes as controller to manage the business relationship and the Customer's account: access-request information, contact and signatory details, Authorized User identity and login data, billing, invoicing and payment data, support communications, and security data, as described in the Privacy Policy (privacy-policy.md).
• "Agency Customer" means a Customer that is an advertising, marketing or similar agency using the Platform to provide services to its own clients.
• "AI Features" means the Platform functionality that uses artificial intelligence models, including the AI chat, the "Performance Guardian", "Trend Radar" and "Web Intelligence" automations, AI-assisted drafting and AI image generation.
• "AI Providers" means the Sub-processors that provide AI model inference to the Company, listed in Annex 3.
• "Applicable Data Protection Law" means the GDPR; Romanian Law no. 190/2018 implementing the GDPR; Romanian Law no. 506/2004 on the processing of personal data and the protection of privacy in the electronic communications sector; and any other European Union or EU Member State data protection law applicable to the processing under this DPA.
• "Authorized Users" means the individuals the Customer authorizes to access the Platform under the Customer's account, including the Customer's employees and contractors and, for Agency Customers, the End Client representatives the Customer invites (for example to the client approval portal).
• "Business Day" means a day other than a Saturday, Sunday or public holiday in Romania.
• "Customer Data" means all data submitted, uploaded, connected, imported or generated by or for the Customer or its Authorized Users through the Platform, including data retrieved from Third-Party Platforms at the Customer's direction, prompts and Outputs. Customer Data does not include Account Data or Usage Data.
• "Customer Personal Data" means the personal data contained in Customer Data.
• "DPF" means the EU-U.S. Data Privacy Framework recognised by Commission Implementing Decision (EU) 2023/1795.
• "End Client" means a client of an Agency Customer on whose behalf the Agency Customer uses the Platform.
• "GDPR" means Regulation (EU) 2016/679 (General Data Protection Regulation).
• "Order Form" means the ordering document signed by the Company and the Customer that references the Terms of Service and sets out the subscribed plan, fees and any special terms.
• "Outputs" means content produced by the AI Features for the Customer, such as analyses, recommendations, proposed changes, texts and images.
• "Platform" means the 1ads software-as-a-service platform, including the web application at https://app.1ads.net, the client approval portal, white-label instances, the public REST API and the MCP server.
• "Restricted Transfer" means a transfer of personal data to a country outside the European Economic Area ("EEA") that is not covered by an adequacy decision under Article 45 GDPR.
• "SCCs" means the standard contractual clauses annexed to Commission Implementing Decision (EU) 2021/914, including Module 2 (controller to processor), Module 3 (processor to processor) and Module 4 (processor to controller).
• "Security Incident" means a personal data breach (as defined in the GDPR) affecting Customer Personal Data processed by the Company or its Sub-processors.
• "Sub-processor" means any processor engaged by the Company to process Customer Personal Data.
• "Third-Party Platforms" means the services the Customer connects to the Platform and which the Customer uses under its own agreements with their providers, including advertising platforms (such as Google Ads, Meta, TikTok, LinkedIn, Microsoft Advertising and Amazon Ads), analytics services (such as Google Analytics 4, Adobe Analytics and Google Search Console), e-commerce and CRM systems (such as Shopify, WooCommerce, HubSpot, Salesforce and Pipedrive) and social networks (such as Facebook, Instagram, Threads, TikTok, LinkedIn, YouTube, X and Pinterest).
• "Usage Data" means metering, billing, configuration, performance and security telemetry about the use of the Platform (for example counts of AI credits, automation runs and API calls), excluding the content of Customer Data.

2.3. "Including" means "including without limitation". Headings are for convenience only. References to a law include that law as amended or replaced.

3. Roles of the Parties

3.1. Company as processor. For Customer Personal Data, the Customer is the controller (or, under Section 3.2, a processor) and the Company is the Customer's processor.

3.2. Agency Customers: processor-to-processor chain. Where an Agency Customer uses the Platform for an End Client that is the controller of the relevant personal data:

(a) the Agency Customer acts as the End Client's processor and the Company acts as the Agency Customer's sub-processor;

(b) the Agency Customer warrants that it has obtained, and will keep in force, the End Client's prior written authorization (Article 28(2) and (4) GDPR) for engaging the Company and the Sub-processors listed in Annex 3, and that its contract with the End Client imposes data protection obligations no less protective than those in this DPA;

(c) the Agency Customer's instructions to the Company are deemed to be the End Client's instructions as relayed by the Agency Customer. The Agency Customer is responsible for passing on to the End Client any notice the Company gives under this DPA (including notices of new Sub-processors and of Security Incidents) and for relaying any End Client instruction or objection;

(d) the Company takes instructions only from the Agency Customer. Actions taken by End Client representatives as Authorized Users (for example approvals given in the client approval portal) are treated as actions of the Agency Customer;

(e) white-label features (custom logo, domain or email sender) do not change the roles of the Parties. The Agency Customer remains responsible for informing its End Clients that the Company and its Sub-processors process their data;

(f) the Agency Customer shall not agree with any End Client data protection obligations that must be flowed down to the Company under Article 28(4) GDPR and go beyond this DPA, unless the Company has agreed to them in writing;

(g) if the Agency Customer has ceased to exist in law or in fact, or has become insolvent, the Company may follow the End Client's documented instructions to return or delete the End Client's Customer Personal Data.

3.3. Company as controller. The Company acts as an independent controller for Account Data, for Usage Data and for data relating to visitors of https://1ads.net. This processing is governed by the Privacy Policy (privacy-policy.md) and the Cookie Policy (cookie-policy.md), not by this DPA. The Company also acts as controller when it processes limited Customer Personal Data where required by law, or where strictly necessary to secure the Platform, prevent abuse or establish, exercise or defend legal claims (for example, retaining audit logs that record actions taken in the Platform). Such processing remains subject to Section 7 where Third-Party Platform terms restrict it.

3.4. Third-Party Platforms are not Sub-processors. The providers of Third-Party Platforms are the Customer's own service providers or independent controllers. They are not Sub-processors of the Company. Data flows to and from Third-Party Platforms on the Customer's instruction, through connections the Customer authorizes. The Customer is responsible for its agreements with those providers and for its use of their services. The Company is not responsible for how Third-Party Platforms process data once it has been delivered to them at the Customer's instruction.

3.5. The details of the processing are set out in Annex 1.

4. Customer's Responsibilities

4.1. The Customer is responsible for the lawfulness of the processing of Customer Personal Data and of its instructions. In particular, the Customer shall:

(a) have a valid legal basis under Article 6 GDPR (and, where applicable, Article 9 GDPR) for each processing activity it instructs, including server-side conversion uploads and the processing of social media comments and direct messages;

(b) provide data subjects with the information required by Articles 13 and 14 GDPR and obtain any consent required, including consent required under Law no. 506/2004 for cookies or similar technologies on its own properties and any consent or consent signal required by Third-Party Platforms for advertising measurement or personalisation;

(c) not submit to the Platform, unless agreed in writing in an Order Form: special categories of personal data (Article 9 GDPR), personal data relating to criminal convictions and offences (Article 10 GDPR), national identification numbers, payment card data, or personal data of children whom the Customer knows to be under the age of digital consent;

(d) when sending identifiers for conversion measurement, provide only the identifiers that the relevant Third-Party Platform accepts and that the Customer is entitled to share, normalised and hashed as required by that platform, or allow the Platform to hash them before transmission;

(e) configure the Platform appropriately, including roles and permissions, approval workflows, retention settings that the Platform makes configurable, SSO and MFA, and keep its credentials and API keys secure;

(f) avoid entering more personal data into AI prompts, briefs or uploaded files than is necessary for the task;

(g) comply with the Acceptable Use Policy (acceptable-use-policy.md), including the prohibition on using the Platform for political or social-issue advertising in the EU within the meaning of Regulation (EU) 2024/900.

4.2. The Customer shall inform the Company without undue delay if it becomes aware that any processing under this DPA infringes Applicable Data Protection Law.

5. Company's Processing Obligations

5.1. Documented instructions. The Company processes Customer Personal Data only on the Customer's documented instructions, unless required to do otherwise by EU or Member State law to which the Company is subject. In that case the Company informs the Customer of the legal requirement before processing, unless the law prohibits this on important grounds of public interest. The Customer's documented instructions are:

(a) the Agreement, including this DPA and the Order Form;

(b) the Customer's configuration and use of the Platform, including the actions of Authorized Users (such as connecting a Third-Party Platform, running an automation, approving a proposed change or scheduling a publication); and

(c) other written instructions that the Customer gives and the Company accepts in writing as consistent with the Agreement.

5.2. Unlawful instructions. The Company informs the Customer immediately if, in its opinion, an instruction infringes Applicable Data Protection Law. The Company may suspend the affected processing until the Customer confirms or changes the instruction. The Company is not obliged to perform a legal review of the Customer's instructions.

5.3. Instructions outside scope. Instructions that require processing beyond the features of the Platform may be subject to a change to the Order Form, including fees agreed in advance.

5.4. No use for the Company's own purposes. The Company shall not:

(a) sell or rent Customer Personal Data, or disclose it to third parties except as permitted by this DPA;

(b) use Customer Personal Data for its own purposes, including for advertising, profiling, building or enriching profiles, or for any other customer;

(c) use Customer Data to train, fine-tune or otherwise improve AI models, whether its own or a third party's.

5.5. AI Providers and model training. The Company uses AI Providers through their commercial API services. Under the API terms that apply to the Company on the effective date of this DPA, the AI Providers do not use API inputs and outputs to train their models unless the API customer opts in. The Company shall not opt in to any such use for Customer Data. The Company has requested zero data retention arrangements from Anthropic. Until and unless such an arrangement is confirmed and applies to the services used, the AI Provider's standard retention periods apply, as summarised in Annex 3. Before using for the AI Features any model that Anthropic designates as a "Covered Model" (for which a minimum retention period applies and zero data retention is generally not available), the Company will notify the Customer under Section 10. The Company does not guarantee the practices of AI Providers beyond their contractual commitments to the Company. It will inform the Customer under Section 10 of any change to these commitments that materially reduces the protection of Customer Personal Data.

5.6. Aggregated and de-identified data. The Company may create aggregated or de-identified statistics from Usage Data to operate, secure and improve the Platform, provided that the result does not identify the Customer, any Authorized User or any data subject. The Company shall not derive such statistics from data obtained from Third-Party Platforms where the terms of that platform prohibit it (see Section 7).

5.7. Records. The Company maintains a record of processing activities carried out on behalf of the Customer as required by Article 30(2) GDPR.

6. AI Features and Human Approval

6.1. Proposals, not actions. The AI Features analyse Customer Data and generate Outputs, including proposals for changes to campaigns on Third-Party Platforms (such as budget, status, bid or creative changes). The AI Features do not carry out changes on the Customer's advertising accounts by themselves. A change is carried out only after an Authorized User with the necessary role approves it, or under an auto-approval policy configured by the Customer within the hard limits enforced by the Platform. Auto-approval policies are disabled during the Access Program (access-program-terms.md, Section 8.5), without exceptions.

6.2. Publishing. Trend Radar concepts are never published automatically. Organic posts and replies are published to Third-Party Platforms only as initiated, scheduled or approved by Authorized Users in accordance with the Customer's approval workflow configuration.

6.3. Audit trail. Every proposal, approval, rejection and executed action is recorded in the Platform's audit log, with the identity of the approving Authorized User recorded in pseudonymised form (Annex 2).

6.4. No decisions about individuals. The AI Features are designed to support decisions about marketing activities. They are not designed to make decisions about individual data subjects that produce legal or similarly significant effects within the meaning of Article 22 GDPR. The Customer shall not use them for that purpose.

6.5. AI-generated content. The Platform embeds machine-readable provenance information (C2PA content credentials) in AI-generated images, adds a machine-readable indicator to AI-generated text that leaves the Platform through exports, the API or the MCP server (ai-transparency-notice.md, Section 5), and sets the AI-content labels offered by the Third-Party Platforms where they are available. The Customer remains responsible, as deployer and publisher, for the transparency obligations that apply to content it publishes, including under Article 50 of Regulation (EU) 2024/1689 (AI Act).

7. Third-Party Platform Data Requirements

7.1. The Company accesses Third-Party Platforms as an application developer and is bound by their developer terms and policies. Where those terms impose stricter limits on storage, use, combination or deletion of data than this DPA, the Customer instructs the Company to apply the stricter limits. In particular:

(a) Meta. Platform Data received from Meta (Facebook, Instagram, Threads) is processed only on behalf of and at the direction of the Customer that connected it, and not for the Company's own purposes or another customer's purposes. It is kept logically separate from other customers' data, is never pooled across customers and is never sold. The Company deletes it when the Customer or the relevant user asks, when the Customer no longer has an account, or when it is no longer needed. The Company promptly informs the Customer of any communication from Meta concerning a user's request.

(b) LinkedIn. Profile data and social activity data of LinkedIn members (other than authenticated Authorized Users), such as commenters on the Customer's page, are cached for no more than 24 hours. This is shorter than the 48 hours LinkedIn allows for member social activity data. Such data is displayed only to Authorized Users associated with the relevant LinkedIn page or account, is not exported, is not sent to AI Providers or made available through the API or the MCP server, is not combined with other data to build or enrich profiles or leads, and is not used for advertising, sales or recruiting purposes. Aggregated advertising and page reporting data is kept for no more than one year, in line with LinkedIn's data storage requirements.

(c) Google and YouTube. Use of data received from Google APIs complies with the Google API Services User Data Policy, including its Limited Use requirements. Data received from the YouTube API Services is refreshed or deleted at least every 30 days and is deleted within the periods required by the YouTube API Services Developer Policies after authorization is revoked.

(d) Shopify. The Company handles protected customer data in line with Shopify's API terms and acts on Shopify's mandatory privacy webhooks (customer data requests, customer redaction and shop redaction).

(e) Other platforms. The terms of TikTok for Developers, the Microsoft Advertising API, the Amazon Ads API, the X Developer Agreement and the other Third-Party Platforms apply in the same way.

7.2. The retention periods that result from these requirements are listed in the Data Retention Schedule (data-retention-schedule.md).

8. Confidentiality of Personnel

8.1. The Company ensures that every person it authorizes to process Customer Personal Data (employees, contractors and Sub-processor personnel) has committed to confidentiality or is under an appropriate statutory obligation of confidentiality.

8.2. Access to Customer Personal Data is limited to personnel who need it to provide, support or secure the Platform. Such personnel receive training on data protection and security appropriate to their role. Access is removed promptly when it is no longer needed.

8.3. Company personnel do not access the content of Customer Data except: (a) to provide support the Customer has requested; (b) to investigate a security event, abuse or a suspected breach of the Agreement; or (c) where required by law. Such access is logged.

9. Security of Processing

9.1. Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of the processing, as well as the risks for data subjects, the Company implements and maintains the technical and organisational measures described in Annex 2. These measures meet the requirements of Article 32 GDPR. Measures marked "planned" in Annex 2 are not yet implemented and are not part of the Company's commitments until the Company notifies the Customer that they are in place.

9.2. The Company may update the measures in Annex 2 as technology and risks evolve, provided that the overall level of security is not reduced.

9.3. The Customer is responsible for the security measures that are within its control. These include managing Authorized Users and their roles, enforcing SSO or MFA, protecting API keys and MCP client credentials, and reviewing proposed changes before approving them.

9.4. As of the effective date of this DPA, the Company does not hold any third-party security certification or attestation (such as ISO/IEC 27001 or a SOC 2 report). The Company will inform the Customer if it obtains one.

10. Sub-processors

10.1. General written authorization. The Customer gives the Company a general written authorization to engage Sub-processors. The Sub-processors authorized on the date of the Order Form are those listed in Annex 3 and published in the Sub-processor List (subprocessors.md). Some Sub-processors are engaged only if the Customer enables the related feature or connector (marked "optional" in Annex 3).

10.2. Sub-processor obligations. The Company engages each Sub-processor under a written contract that imposes data protection obligations no less protective than those in this DPA, in particular sufficient guarantees for appropriate technical and organisational measures, as required by Article 28(4) GDPR. The Company remains fully liable to the Customer for each Sub-processor's performance of its data protection obligations.

10.3. Notice of changes. The Company notifies the Customer of any intended addition or replacement of a Sub-processor at least 30 days in advance. Notice is given by email to the notification contact named in the Order Form (or, if none is named, to the Customer's account owner), and the Sub-processor List is updated at the same time. The notice states the Sub-processor's identity, location, the processing it will perform and the transfer mechanism. Where a replacement is urgently needed for security or service continuity reasons, the Company may make it with shorter notice. In that case it notifies the Customer as soon as possible, and the Customer's objection right under Section 10.4 still applies.

10.4. Right to object. The Customer may object to a new or replacement Sub-processor on reasonable grounds relating to data protection by writing to privacy@1ads.net within 30 days of the notice. The Parties will then discuss the objection in good faith. The Company may propose an alternative, such as a configuration that avoids the Sub-processor for the Customer or a change to the affected feature. If no solution is agreed within 30 days of the objection, the Customer may terminate the affected Order Form, or the part of it that cannot be provided without the Sub-processor, by written notice. In that case the Company refunds any prepaid fees for the terminated part covering the period after termination. If the Customer does not object within the 30-day period, the Sub-processor is deemed authorized.

10.5. Agency Customers. An Agency Customer is responsible for informing its End Clients of Sub-processor changes and for relaying any objection from them under Section 10.4.

11. International Transfers

11.1. The Platform is hosted in the EU, on the Company's own on-premises Kubernetes cluster in Romania (EU), which the Company operates itself under its FirstIT brand. The Platform's databases, secrets management, background job queue, identity provider (sign-in, SSO and MFA), error tracking and LLM observability run inside that cluster.

11.2. The Company makes a Restricted Transfer of Customer Personal Data only in compliance with Chapter V GDPR, on the basis of: (a) an adequacy decision, including the DPF where the recipient's certification is active and covers the transfer; or (b) the SCCs, together with a transfer impact assessment and any supplementary measures it identifies; or (c) another mechanism permitted by Article 46 GDPR.

11.3. The SCCs are incorporated as set out in Annex 4, which also summarises the Company's transfer impact assessment.

11.4. If a transfer mechanism is invalidated or ceases to apply, the Company will rely on an alternative valid mechanism (for example, the SCCs in place of the DPF). If no such mechanism is available, it will suspend the affected transfer and inform the Customer.

11.5. The Company may in future offer an option to restrict AI processing to the EU for certain plans. Such an option is not available as of the effective date of this DPA. It will apply only if and when it is expressly included in an Order Form.

12. Assistance with Data Subject Requests

12.1. Taking into account the nature of the processing, the Company assists the Customer, through appropriate technical and organisational measures, in responding to requests from data subjects exercising their rights under Chapter III GDPR (access, rectification, erasure, restriction, portability and objection).

12.2. The Platform provides self-service functions for the Customer to find, export and delete Customer Personal Data, and to disconnect Third-Party Platforms. Where these functions are not sufficient, the Company provides reasonable additional assistance on request. Assistance that goes beyond the Platform's standard functionality may be charged at reasonable rates agreed in advance, unless the request results from the Company's breach of this DPA.

12.3. If the Company receives a request directly from a data subject in relation to Customer Personal Data, it will not respond to the substance of the request without the Customer's authorization, except to confirm that the request has been forwarded. It forwards the request to the Customer without undue delay and in any event within five (5) Business Days, where it can identify the Customer concerned. Where the request concerns data received from Meta, the Company also informs the Customer of any related communication from Meta (Section 7.1(a)).

12.4. The public page Data Deletion Instructions (data-deletion-instructions.md) explains how data subjects and Authorized Users can request deletion and revoke access to Third-Party Platforms.

13. Assistance with DPIAs, Prior Consultation and Compliance

13.1. Taking into account the nature of the processing and the information available to it, the Company provides reasonable assistance to the Customer with:

(a) data protection impact assessments under Article 35 GDPR and prior consultations with supervisory authorities under Article 36 GDPR, where these relate to the Customer's use of the Platform;

(b) the Customer's compliance with its obligations under Articles 32 to 34 GDPR.

13.2. This assistance is provided primarily by making available this DPA, Annex 2, the Sub-processor List, documentation describing the AI Features and their data flows, and answers to reasonable security and privacy questionnaires (no more than once per 12 months unless a material change or Security Incident justifies more frequent requests).

14. Personal Data Breach Notification

14.1. Notification. The Company notifies the Customer of a Security Incident without undue delay, and in any event within 48 hours after becoming aware of it. The Company becomes aware when it has a reasonable degree of certainty that a Personal Data Breach affecting Customer Personal Data has occurred.

14.2. Content. The notification includes, to the extent then known: (a) the nature of the Security Incident, including the categories and approximate number of data subjects and records concerned; (b) the name and contact details of the Company's contact point; (c) the likely consequences; and (d) the measures taken or proposed to address the Security Incident and to mitigate its possible adverse effects. Where it is not possible to provide all information at the same time, the Company provides it in phases without undue further delay.

14.3. Channel. Notification is sent by email to the security or notification contact named in the Order Form (or, if none is named, to the Customer's account owner) and, where practical, also through the Platform.

14.4. Cooperation. The Company takes reasonable steps to contain, investigate and remedy the Security Incident. It cooperates with the Customer and provides reasonably requested information so that the Customer can meet its obligations under Articles 33 and 34 GDPR. The Customer is responsible for notifying the competent supervisory authority and affected data subjects where required. The Company does not notify supervisory authorities or data subjects about a Security Incident affecting Customer Personal Data on the Customer's behalf unless the Customer instructs it to or the law requires it.

14.5. No admission. Notification of, or response to, a Security Incident is not an acknowledgement of fault or liability.

14.6. Unsuccessful attempts or activities that do not compromise the security of Customer Personal Data are not Security Incidents. Examples include pings, port scans, blocked login attempts and denial-of-service attempts that do not lead to unauthorized access.

15. Requests from Public Authorities

15.1. If a public authority (including a law enforcement or intelligence authority) asks the Company for access to Customer Personal Data, the Company will:

(a) try to redirect the authority to request the data directly from the Customer;

(b) notify the Customer promptly, unless the law prohibits it, so that the Customer can seek a protective order or other remedy;

(c) review the legality of the request and challenge it where, after careful assessment, there are reasonable grounds to consider it unlawful; and

(d) disclose only the minimum data required to comply with a binding request.

15.2. Annex 4 sets out further commitments for requests concerning data transferred outside the EEA.

16. Return and Deletion of Customer Personal Data

16.1. During the term. The Customer may export Customer Data and delete it at any time using the Platform's functions or the API. Data that Third-Party Platform terms require to be deleted sooner (Section 7) is deleted within those shorter periods.

16.2. On termination. When the Agreement or an Order Form ends:

(a) the Company stops syncing data from Third-Party Platforms for the affected account. It deletes the stored OAuth tokens and, where the Third-Party Platform offers this, revokes them;

(b) for 30 days after the end date (the "Export Window", as defined in Section 25.2 of the Terms of Service), the Company gives the Customer's administrators, on request, read-only access to Customer Data or an export of it in a commonly used, machine-readable format;

(c) after the Export Window, the Company deletes Customer Data from its active systems within 30 days. Residual copies in backups are overwritten or expire no more than 14 days after that. Until they expire, backups are protected in accordance with Annex 2 and are not used for any purpose other than disaster recovery;

(d) on written request, the Company confirms the deletion in writing.

16.3. Retention required by law. Section 16.2 does not apply to Customer Personal Data that EU or Member State law requires the Company to keep. Such data remains protected under this DPA, is processed only for the purpose required by law and is deleted when the legal retention period ends.

16.4. Agency Customers. An Agency Customer may delete an End Client's Workspace at any time during the term. Sections 16.2(c) and 16.3 then apply to that Workspace's data.

16.5. This Section applies without prejudice to the Customer's rights to switch provider and to port data under Regulation (EU) 2023/2854 (Data Act), as set out in the Terms of Service (terms-of-service.md).

16.6. Retention periods for each data category are set out in the Data Retention Schedule (data-retention-schedule.md).

17. Audits and Information

17.1. Documentation first. On written request, the Company makes available to the Customer all information reasonably necessary to demonstrate compliance with Article 28 GDPR and this DPA. This includes the current version of Annex 2, the Sub-processor List, relevant policies, summaries of security testing (where available) and answers to a reasonable security questionnaire. If the Company obtains a third-party certification or audit report, it may provide it to satisfy audit requests to the extent it covers the relevant controls.

17.2. Audits. If the information provided under Section 17.1 is not reasonably sufficient to demonstrate compliance, the Customer may conduct an audit, including an inspection, itself or through an independent auditor. The following conditions apply:

(a) no more than once in any 12-month period, unless a supervisory authority requires it or a Security Incident has occurred within the previous 12 months;

(b) on at least 30 days' written notice, with a proposed scope and plan agreed in advance;

(c) during Business Days and normal business hours, remotely where possible, and without unreasonably disrupting the Company's operations;

(d) by an auditor who is bound by written confidentiality obligations and is not a competitor of the Company;

(e) without access to other customers' data, to information subject to third-party confidentiality obligations, or to third-party facilities, including those of Sub-processors and of any third-party data centre that houses the Company's servers. For these, the Company provides the Sub-processor's own audit reports or certifications where available;

(f) at the Customer's cost, unless the audit reveals a material breach of this DPA by the Company, in which case the Company bears its own costs and the reasonable costs of the audit.

17.3. The Customer shares the audit report with the Company. Each Party keeps the audit findings confidential. The Company remedies any confirmed non-compliance without undue delay.

17.4. Nothing in this Section limits the powers of a supervisory authority or the audit rights that apply under the SCCs. For the SCCs, the Parties agree that this Section describes how those audit rights are exercised.

18. Liability

18.1. Each Party's liability arising out of or in connection with this DPA, whether in contract, tort or otherwise, is subject to the exclusions and limitations of liability in the Terms of Service (terms-of-service.md). This DPA and the Agreement have a single, aggregate liability cap. They do not create separate caps.

18.2. Section 18.1 does not limit: (a) either Party's liability to data subjects under Article 82 GDPR or under the third-party beneficiary rights in the SCCs; (b) liability that cannot be limited or excluded under applicable law, including liability for intentional misconduct or gross negligence under Article 1355 of the Romanian Civil Code; or (c) any other matter the Terms of Service exclude from the liability cap.

18.3. Where both Parties are responsible for the same damage to a data subject, each Party may recover from the other the part of the compensation that corresponds to the other Party's share of responsibility, as provided in Article 82(5) GDPR.

19. Term and Termination

19.1. This DPA remains in force as long as the Company processes Customer Personal Data on behalf of the Customer.

19.2. Sections 14, 15, 16, 17, 18 and 22 survive the termination of the Agreement for as long as the Company or its Sub-processors hold Customer Personal Data.

20. Order of Precedence

20.1. If there is a conflict between the documents that apply to the processing of Customer Personal Data, the following order of precedence applies:

(a) the SCCs, where they apply under Annex 4;

(b) special terms in an Order Form that expressly name the Section of this DPA they modify, provided that they do not reduce the protection required by Article 28 GDPR;

(c) this DPA;

(d) the Terms of Service and the other documents forming the Agreement.

20.2. For all matters other than the processing of personal data, the order of precedence in Section 3.3 of the Terms of Service applies.

21. Changes to this DPA

21.1. The Company may update this DPA to reflect changes in Applicable Data Protection Law, guidance or decisions of supervisory authorities or courts, the requirements of Third-Party Platforms, or changes to the Platform that do not reduce the protection of Customer Personal Data. It gives at least 30 days' notice by email, unless a shorter period is required by law.

21.2. Changes to Sub-processors follow Section 10 and do not require an amendment of this DPA.

21.3. Any change that materially reduces the protection of Customer Personal Data requires the Customer's written agreement.

22. Governing Law and Jurisdiction

22.1. This DPA is governed by Romanian law. This applies without prejudice to the provisions of the SCCs on governing law and jurisdiction (Annex 4).

22.2. Disputes arising out of or in connection with this DPA are subject to the exclusive jurisdiction of the competent courts of Bucharest, Romania. This is subject to the mandatory rights of data subjects and the competence of supervisory authorities.

23. Express Acceptance of Specific Clauses

23.1. The Parties acknowledge that this DPA is part of the Company's standard terms. Under Articles 1202 and 1203 of the Romanian Civil Code, the following clauses take effect against the Customer only if the Customer expressly accepts them in writing. The Order Form (see order-form-template.md) contains a dedicated express-acceptance statement for this purpose:

(a) Section 5.2 (the Company's right to suspend processing of instructions it considers unlawful);

(b) Section 10.3 and Section 10.4 (Sub-processor changes by notice and the deemed authorization if no objection is raised);

(c) Section 16.2 (deletion of Customer Data after the Export Window);

(d) Section 17.2 (limitations on audits);

(e) Section 18 (limitation of liability by reference to the Terms of Service);

(f) Section 21.1 (the Company's right to amend this DPA by notice);

(g) Section 22 (governing law and choice of jurisdiction).

24. Miscellaneous

24.1. Notices. Notices to the Company under this DPA are sent to privacy@1ads.net, with a copy to support@1ads.net for contractual notices. Security Incident reports and vulnerability disclosures to the Company are sent to ops@1ads.net. The Company's data protection contact is: {{DPO_CONTACT}}.

24.2. Severability. If any provision of this DPA is invalid or unenforceable, the remaining provisions remain in effect. The invalid provision is replaced by a valid provision that comes closest to its purpose.

24.3. Language. This DPA is drafted in English, with a Romanian translation. The language rules in Section 28.1 of the Terms of Service apply: if the versions differ, the English version prevails, except where Romanian law mandatorily requires the Romanian language.

24.4. Signature. The Order Form, and with it this DPA, is signed with a handwritten signature or a qualified electronic signature, as set out in Section 28.2 of the Terms of Service.

Annex 1 – Description of the Processing

A. Parties and roles

B. Subject matter

Provision of the 1ads Platform: connecting the Customer's Third-Party Platforms, consolidating and analysing marketing, analytics, sales and social data, providing the AI Features, proposing and (after approval) executing changes on Third-Party Platforms, generating creatives, scheduling and publishing content, managing approval workflows, and related support.

C. Duration

For the term of the Agreement, plus the Export Window and the deletion periods in Section 16 and in the Data Retention Schedule (data-retention-schedule.md).

D. Nature of the processing

Collection through APIs authorized by the Customer; recording; storage; organisation and structuring; consultation; analysis and combination within the Customer's tenant (for example, matching orders to campaigns to compute cross-channel return on investment, profit and incrementality), except where Third-Party Platform terms prohibit combination (Section 7); processing by AI models; generation of Outputs; transmission to Third-Party Platforms at the Customer's instruction (such as campaign changes, publications, replies and conversion uploads); pseudonymisation and hashing; restriction; erasure.

E. Purposes of the processing

1. Reporting and analytics across advertising, analytics, e-commerce, CRM and social channels.
2. Calculating return on investment and profit (including cost of goods sold, refunds and cash-on-delivery refusals) and estimating incrementality.
3. Performance Guardian: analysing campaigns against the Customer's KPI targets and proposing changes.
4. Trend Radar: detecting public trends and proposing advertising or post concepts, subject to a brand-safety gate.
5. Web Intelligence: reading public web pages that the Customer designates or that are relevant to the Customer's market.
6. AI chat assistance and AI-generated creatives.
7. Scheduling and publishing organic content and managing comments and direct messages on the Customer's social profiles.
8. Approval workflows, including the client approval portal.
9. Server-side conversion uploads to Third-Party Platforms (such as Google Data Manager API, Meta Conversions API and LinkedIn Conversions API).
10. Access through the API and the MCP server, white-label delivery, customer support, security, and audit logging.

F. Categories of data subjects

1. Authorized Users (the Customer's staff and contractors, agency staff, End Client representatives), to the extent they appear in Customer Data (for example in chats, approvals, comments and audit logs).
2. Users of the Customer's Third-Party Platform accounts (for example names and emails of advertising account managers returned by the APIs).
3. The Customer's (or End Client's) customers and prospects whose data is contained in e-commerce orders and CRM records the Customer connects.
4. Social media users who interact with the Customer's pages and profiles (commenters, people who send direct messages, people mentioned in posts), including LinkedIn members.
5. Individuals depicted or named in creative assets, briefs or prompts provided by the Customer (for example models, influencers or spokespersons).
6. Individuals whose personal data appears incidentally on public web pages or in public trend sources processed at the Customer's direction (for example public figures named in news).

G. Categories of personal data

1. Identification and contact data: name, email address, phone number, username or handle, profile picture URL, job title, company, as provided by the Customer or returned by Third-Party Platforms.
2. Order and customer data: order ID, customer ID, order date and value, products, currency, discounts, refunds, cash-on-delivery refusal status, delivery locality or region, and the identifiers needed to link orders to campaigns (for example click identifiers such as gclid, fbclid or ttclid, and UTM parameters).
3. Hashed identifiers: normalised and SHA-256-hashed email addresses and phone numbers, and other match keys accepted by a Third-Party Platform (see Section I.1).
4. Event data for conversion uploads, where supplied by the Customer: event name and time, value, IP address, user agent and platform cookie identifiers (for example Meta's fbp and fbc).
5. Social interaction data: comment and direct message content, timestamps, public profile name and identifier, reactions, and mentions.
6. Advertising account data: account, campaign and creative identifiers and metrics, and names and emails of account users. This data is generally not personal data except where it identifies individuals.
7. AI interaction data: prompts, uploaded files, retrieved context, Outputs, feedback, and approval comments.
8. Creative assets: images, videos and texts supplied by the Customer or generated for it, which may depict or name individuals.
9. Pseudonymised identifiers of Authorized Users in audit logs.

H. Special categories of data

None intended. The Customer shall not submit special categories of data (Section 4.1(c)). Free-text content such as comments and direct messages may incidentally reveal special categories of data (for example health information mentioned by a commenter). Such content is processed only as necessary to display and manage it, under the short retention periods in Section I.2. The Customer is responsible for moderating it.

I. Special notes

1. Hashed identifiers. Hashing is pseudonymisation, not anonymisation. Hashed identifiers remain personal data and are protected as such. They are used only to transmit conversion events to the Third-Party Platform the Customer designates. The Company does not match them against other data sets, does not use them for any other customer and does not keep them longer than stated in the Data Retention Schedule. The Customer is responsible for the legal basis, for transparency and for any consent signals required by the receiving Third-Party Platform.
2. Comments and direct messages. These are third-party personal data. By default they are retained for 30 days after they are retrieved. The Customer may change this period within the limits the Platform makes available, subject always to any shorter limit imposed by the relevant Third-Party Platform.
3. LinkedIn member data. Profile and social activity data of LinkedIn members who are not Authorized Users is cached for no more than 24 hours and is subject to the restrictions in Section 7.1(b). LinkedIn member identifiers (URNs) may be kept for longer, as LinkedIn permits, only to the extent needed for de-duplication and audit.
4. Meta Platform Data. Meta Platform Data is segregated per Customer and processed only on that Customer's behalf (Section 7.1(a)).
5. OAuth tokens. Tokens granting access to Third-Party Platforms are credentials, not content. They are encrypted with the HashiCorp Vault Transit engine under a key derived per tenant, connection and provider, can be decrypted only by an isolated token service, are never sent to AI models and are never written to logs (Annex 2).
6. AI processing. To answer a request or run an automation, the Platform sends the AI Providers the instructions and the excerpts of Customer Data needed for that task. LinkedIn member data is never sent to AI Providers (Section 7.1(b)). Personal data is minimised where the task allows it, and observability traces are processed with PII redaction (Annex 2).

J. Frequency

Continuous, for the term of the Agreement, according to the Customer's use of the Platform and the schedules of its automations (for example hourly, every 12 hours or daily).

K. Retention

As set out in Section 16 and the Data Retention Schedule (data-retention-schedule.md).

L. Processing by Sub-processors

As set out in Annex 3, for the purposes and data categories listed there and for the duration of the Agreement.

Annex 2 – Technical and Organisational Measures

*[Drafting note: before signature, the founder and the technical lead must confirm that each measure below is implemented in production as described. Measures marked [TBC – confirm before signature] have not yet been confirmed; the same items are marked [TBC] in security-overview.md. Before any Order Form is signed, each such item must either be confirmed (and the marker removed in BOTH documents at the same time), or be marked [Planned – not yet implemented], or be deleted. Measures marked "planned" are subject to Section 9.1.]*

1. Governance and risk management

1.1. A designated person is responsible for information security and data protection. Contact: ops@1ads.net for security matters and privacy@1ads.net for data protection matters. 1.2. Written security, access-control, incident-response, retention and vendor-management policies, reviewed at least annually. 1.3. A risk assessment before new processing activities, new AI Features or new Sub-processors are introduced. 1.4. No third-party certification is currently held (Section 9.4).

2. Hosting and physical security

2.1. The Platform runs on the Company's own on-premises Kubernetes cluster in Romania (EU), which the Company operates itself under its FirstIT brand. It does not run in a public cloud, and no third party operates the cluster, so there is no hosting Sub-processor (Annex 3). The servers are located at {{DATACENTER_FACILITY}}. [TBC – confirm before signature: physical access control, power, cooling and fire protection of the facility.] 2.2. The PostgreSQL databases, the secrets management system (HashiCorp Vault), the background job queue (graphile-worker, on PostgreSQL) and the identity provider (Keycloak, for sign-in, SSO and MFA) run inside the cluster. They are not exposed directly to the public internet; only the edge web server (Caddy) is, and it publishes only the website, the application, the API and the Keycloak sign-in pages. The Keycloak administrative interface is reachable only from an allowlist of addresses (Section 6.5). Error tracking uses the self-hosted Sentry instance that the Company operates, under its FirstIT brand, in the same infrastructure [TBC: confirm network exposure of the Sentry endpoint and the network-policy rule that lets api and worker report to it].

3. Tenant isolation

3.1. Every record of Customer Data carries a tenant identifier and, where it belongs to a client workspace, a workspace identifier. Isolation between customers, and between workspaces of the same customer, is enforced in the database through PostgreSQL row-level security (RLS) policies per tenant and per workspace, in addition to application-level authorization checks. The application's database roles are not superusers and do not have the BYPASSRLS attribute, so they cannot bypass these policies. Only the backup role has the BYPASSRLS attribute, so that complete database dumps can be made. That role is read-only (PostgreSQL's built-in pg_read_all_data role), cannot modify data and is used only by the nightly backup job. [TBC – confirm first successful backup and restore] The public access-request form uses a separate role that can only insert access requests. Each request and each background job runs in the context of a single tenant. 3.2. For Agency Customers, each End Client is a separate workspace within the Agency Customer's tenant. Access to it can be restricted to designated Authorized Users. 3.3. Data from Third-Party Platforms whose terms require segregation (in particular Meta Platform Data) is never pooled or used across tenants. 3.4. Tenant isolation controls are covered by automated tests that run in the deployment pipeline. [TBC – confirm before signature]

4. Identity and access management

4.1. Authorized Users. Sign-in, SSO and MFA are provided by the Company's self-hosted identity provider (Keycloak). Single sign-on is available by federation with the Customer's own identity provider (for example Okta, Microsoft Entra ID, Google Workspace or OneLogin), which is the Customer's provider and not a Sub-processor. Automatic directory synchronisation is not available at launch. Multi-factor authentication is mandatory for all users who do not sign in through SSO. Brute-force detection is enabled on the identity provider. [TBC – confirm before signature] 4.2. Role-based access control (RBAC) at tenant and workspace level, including separate permissions to view data, propose changes, approve changes and administer the account. 4.3. Session expiry and the ability for the Customer's administrators to revoke sessions and remove users. 4.4. API and MCP access. OAuth 2.1 for the MCP server, scoped API credentials, rate limiting, and revocation by the Customer. 4.5. Company personnel. Production access is limited to a small number of named personnel, on a least-privilege basis. It requires MFA, is logged and is reviewed at least quarterly. Access is removed promptly when personnel leave or change role. [TBC – confirm before signature]

5. Encryption and key management

5.1. In transit over public networks. All public endpoints of the Platform are served over TLS by the edge web server, with Let's Encrypt certificates and HTTP Strict Transport Security (HSTS). Connections from the Platform to Third-Party Platforms and Sub-processors use TLS. Minimum version TLS 1.2. [TBC – confirm before signature] 5.2. Inside the cluster. Traffic between components inside the private cluster network (for example application to PostgreSQL, token service to Vault) is currently not encrypted. It is carried on a single private network and restricted by default-deny network policies (Section 6.1). Encryption of this internal traffic (Cilium WireGuard or TLS) is [Planned – not yet implemented] and is scheduled before general availability. 5.3. At rest. Database backups are encrypted with age before they are written to the backup storage (Section 9.1). The dump stream from the database to the backup job crosses the internal cluster network, which is not yet encrypted (Section 5.2). Encryption at rest of the servers' disks, including the database volumes: [TBC – confirm with infrastructure owner. Until confirmed, no encryption at rest of disks is claimed.] 5.4. OAuth tokens. Tokens are encrypted with the HashiCorp Vault Transit engine (AES-256-GCM) under a key derived for each tenant, connection and provider. The key material never leaves Vault. Only an isolated token service, with a narrowly scoped Vault policy, can request encryption or decryption, and only for the tenant and connection concerned at the time of an API call. Tokens are never sent to AI models, never displayed to users after connection and never written to logs. [TBC – confirm before signature: exclusion of tokens from logs and error reports] 5.5. Secrets (database credentials, API keys for Sub-processors) are stored in Vault, not in source code or container images, and each component receives only its own secrets. Secrets are rotated after any suspected compromise. [TBC – confirm before signature: periodic rotation and Vault audit logging.]

6. Network security

6.1. Kubernetes network policies deny all traffic by default and then allow, for each component, only the connections it needs (for example, only the application components and the backup job may reach PostgreSQL, and only the token service may reach Vault). 6.2. Outbound internet traffic from Platform workloads is limited by network policy to public addresses and to the ports each component needs (HTTPS, which also carries the Amazon SES API calls used to send email, and SMTP submission to Amazon SES where a component, such as the identity provider, sends email over SMTP). Private, link-local and internal network ranges are blocked, which mitigates server-side request forgery. A destination allowlist through an egress proxy is [Planned – not yet implemented]. 6.3. Web Intelligence reads only publicly accessible pages. It respects robots.txt and text-and-data-mining opt-outs and does not log in to websites or bypass access controls. 6.4. Protection against denial-of-service and abuse through rate limiting and network protections at the edge of the Company's infrastructure. [TBC – confirm before signature: upstream DDoS protection] The public access-request form is protected by a hidden honeypot field and form timing, without a third-party CAPTCHA, and the applicant acknowledgement email is limited to one per address per 24 hours. 6.5. Administrative interfaces of the identity provider are reachable from the internet only from an allowlist of addresses.

7. Logging, monitoring and audit

7.1. Audit log. An append-only audit log records security-relevant and business-relevant events. These include sign-ins, permission changes, connections and disconnections of Third-Party Platforms, AI proposals, approvals and rejections, executed changes on Third-Party Platforms, publications, data exports and deletions, and administrative access by Company personnel. Authorized User identities are pseudonymised in the log. The integrity of the log is anchored to immutable (write-once) storage, so that any later alteration can be detected. [TBC – confirm before signature] Customer administrators can view the audit log for their tenant. 7.2. Operational monitoring and alerting of availability, errors and security events. [TBC – confirm before signature] Error tracking (Sentry, self-hosted in the Company's infrastructure) runs server-side only and is configured to scrub personal data and secrets before events are stored. [TBC – confirm before signature] 7.3. LLM observability (Langfuse, self-hosted in the Company's cluster) is configured with PII redaction, and with retention as set out in the Data Retention Schedule.

8. AI-specific safeguards

8.1. Human approval. AI Features propose and do not act. Changes on Third-Party Platforms are executed only after approval by an Authorized User with the required role, or under a Customer-configured auto-approval policy within hard caps enforced by the Platform (for example maximum budget changes). Auto-approval is disabled during the Access Program (access-program-terms.md, Section 8.5), without exceptions. Multi-step approval (agency, then client) is available. 8.2. Prompt-injection safeguards. Content from untrusted sources (web pages, comments, direct messages, trend sources, uploaded files) is treated as data, not as instructions. It is clearly separated from system instructions. AI tool permissions are limited to the tenant, the user's role and the task. Proposals generated by AI are validated against schemas and policy rules before they are shown for approval. AI models cannot access OAuth tokens or execute changes directly. 8.3. Brand safety. Trend Radar applies a brand-safety gate: sensitive trends are blocked or require approval by a senior Authorized User, and concepts are never published automatically. 8.4. Minimisation. Only the data needed for a task is sent to AI Providers. Credentials are excluded, and personal data is redacted from observability traces. 8.5. Provider selection. The Company uses AI Providers' commercial API services that do not use API data for model training by default, and has requested zero data retention where offered (Section 5.5). 8.6. Content provenance. AI-generated images carry C2PA content credentials, AI-generated text carries a machine-readable indicator when it leaves the Platform through exports, the API or the MCP server, and Third-Party Platform AI labels are set where supported. [TBC – confirm before signature: text marking]

9. Availability, backup and recovery

9.1. Nightly logical backups (dumps) of the PostgreSQL databases, made with a read-only database role. Each dump is encrypted with age (X25519) before it is written to network storage in the same facility in Romania (EU), which is a separate failure domain from the database disk. Only the public key is present in the cluster; the private key needed for restoration is kept offline. Backups are retained for no more than 14 days and then deleted automatically. [TBC – confirm first successful backup and restore] The recovery point is up to 24 hours; database replication with continuous archiving is [Planned – not yet implemented]. 9.2. Restoration from backup is tested periodically. [Confirm frequency; planned quarterly.] 9.3. Background jobs and schedules run on a job queue stored in PostgreSQL (graphile-worker). Failed jobs are retried a limited number of times, and each job records its progress so that a retry does not repeat a step already completed, such as executing an approved action twice. [TBC – confirm before signature] 9.4. The cluster has several nodes, and workloads can be rescheduled on another node if one fails. The PostgreSQL database currently runs as a single instance on local storage. [Confirm.]

10. Secure development and change management

10.1. Source code is kept under version control. Changes are peer-reviewed [TBC – confirm before signature], and production deployments run through a CI/CD pipeline (Jenkins) with GitOps reconciliation (Flux) from version-controlled configuration. 10.2. Automated container image vulnerability scanning (Trivy) in the build pipeline, and dependency vulnerability scanning. Vulnerabilities are fixed according to severity. [TBC – confirm before signature; confirm target remediation times, for example critical within 7 days.] 10.3. Separate development, staging and production environments. Production Customer Data is not used in non-production environments unless it has been anonymised. [TBC – confirm before signature] 10.4. Periodic security testing, including independent penetration testing at a frequency appropriate to the risk. [Confirm whether and when a first penetration test will take place.] 10.5. A vulnerability disclosure channel at ops@1ads.net.

11. Incident response

11.1. A documented incident response procedure covering detection, triage, containment, eradication, recovery, notification (within 48 hours to the Customer, Section 14) and post-incident review. [TBC – confirm before signature] 11.2. A record of all Security Incidents, including facts, effects and remedial action, as required by Article 33(5) GDPR.

12. Personnel

12.1. Confidentiality commitments for all personnel and contractors (Section 8). 12.2. Security and data protection training at onboarding and at least annually. [TBC – confirm before signature] 12.3. Access revoked on the last working day of personnel who leave.

13. Data minimisation, retention and deletion

13.1. Retention periods are enforced by automated deletion jobs as set out in the Data Retention Schedule, including 24 hours for LinkedIn member data, a 30-day default for comments and direct messages, and no more than 14 days for database backups. 13.2. Deletion of Customer Data on request and at the end of the Agreement (Section 16). 13.3. OAuth tokens are deleted, and revoked where the Third-Party Platform supports it, when a connection is removed.

14. Sub-processor management

14.1. Due diligence on privacy and security before engagement. Written data processing terms, including SCCs where required. Periodic review. 14.2. Transfer impact assessments for Restricted Transfers (Annex 4).

Annex 3 – Sub-processors

The current list of Sub-processors, with entity, location, purpose, data categories and transfer mechanism, is published in the Sub-processor List (subprocessors.md). The list in force on the date of the Order Form forms part of this Annex 3 and is summarised below as of version 0.1-draft.

Components that run inside the Company's own infrastructure are not Sub-processors: the PostgreSQL databases, HashiCorp Vault, the graphile-worker job queue, the Keycloak identity provider, the self-hosted Sentry error tracker and the self-hosted Langfuse LLM observability tool. The Company operates this infrastructure itself, under its FirstIT brand. The identity providers the Customer uses for single sign-on (for example Okta, Microsoft Entra ID, Google Workspace or OneLogin) are the Customer's own providers, with which the Platform federates; they are not Sub-processors.

Anthropic retention. API inputs and outputs are deleted within 30 days by default. Content flagged for usage-policy violations may be kept longer (up to 2 years), and trust and safety classification scores may be kept for up to 7 years. Zero data retention has been requested (Section 5.5). Models that Anthropic designates as "Covered Models" require retention of at least 30 days and are generally not eligible for zero data retention; the Company will notify the Customer under Section 10 before using such a model for the AI Features.

DataForSEO OÜ (Estonia), SerpApi, LLC (USA) and GNews (entity to be confirmed) supply public search, trend and news data to the Company. They receive only queries, not personal data; they are not Sub-processors and are listed in subprocessors.md for transparency.

The Third-Party Platforms are not Sub-processors (Section 3.4).

Annex 4 – International Transfers

1. Transfer map

1.1. Customer Personal Data is stored in the EU, on the Company's on-premises infrastructure in Romania (EU). Authentication (Keycloak), error tracking (Sentry), LLM observability (Langfuse) and the job queue are self-hosted there and involve no transfer. Restricted Transfers occur only when the data is processed by a Sub-processor located outside the EEA, or accessed from there, as identified in Annex 3 and subprocessors.md. These Sub-processors are currently located in the USA (Anthropic, OpenAI where processing occurs in the USA, and Firecrawl). Transactional email is processed by Amazon SES in the EU (Ireland); any access by AWS entities from outside the EEA is covered by the SCCs in the AWS data processing addendum and, where the entity is certified, by the DPF. [TBC: confirm that the Company's administrators do not access the infrastructure remotely from outside the EEA.] Transfers to Switzerland (Windsor.ai) and to Canada (Unified.to, for commercial organisations subject to PIPEDA) are covered by adequacy decisions of the European Commission.

1.2. Where the Customer is established in the EEA, the transfer from the Customer to the Company is not a Restricted Transfer.

2. Transfer mechanisms

2.1. DPF. For a U.S. Sub-processor that holds an active DPF certification covering the relevant data, the transfer relies on the adequacy decision for the DPF (Commission Implementing Decision (EU) 2023/1795). The Company checks each certification on the official DPF List before relying on it and at least annually afterwards. [Drafting note: verify the DPF status of Anthropic PBC, OpenAI, SideGuide Technologies, Inc. and Amazon Web Services, Inc. before publication.] In Latombe v Commission (Case T-553/23, judgment of 3 September 2025), the EU General Court dismissed an action for annulment of the DPF adequacy decision. An appeal was brought before the Court of Justice (Case C-703/25 P). The Company monitors the outcome. The SCCs serve as a fallback (Section 2.4).

2.2. SCCs, Module 3 (processor to processor). Where the Company, acting as processor or sub-processor, transfers Customer Personal Data to a Sub-processor in a third country without an adequacy decision, the Company and the Sub-processor enter into the SCCs, Module 3. In most cases these are incorporated in the Sub-processor's data processing agreement.

2.3. SCCs, Module 2 (controller to processor). Where the Company, as controller, transfers Account Data to a processor in a third country without an adequacy decision, Module 2 applies. Authentication data stays in the EU, because the identity provider is self-hosted. This processing is described in the Privacy Policy.

2.4. Fallback. Where a Sub-processor is DPF-certified and has also signed the SCCs, the SCCs apply automatically if the DPF ceases to be a valid transfer mechanism.

2.5. Customers outside the EEA: SCCs, Module 4 (processor to controller). Where the Customer is established in a third country without an adequacy decision, and the Company (as an EU processor) transfers Customer Personal Data to the Customer, the SCCs, Module 4, are incorporated by reference into this DPA. The Company is the "data exporter" and the Customer is the "data importer". If the Customer is an Agency Customer established in such a third country and acts as processor for its End Clients, the SCCs, Module 3, apply in the same way, with the Company as data exporter. [Drafting note: Module 4 or Module 3 is needed only where the data received by the Company is subject to the GDPR. Lawyer to confirm.]

2.6. UK and Swiss data. Where Customer Personal Data subject to the UK GDPR or the Swiss Federal Act on Data Protection is transferred onward to a third country, the SCCs apply with the UK International Data Transfer Addendum or the adaptations required by the Swiss Federal Data Protection and Information Commissioner, as applicable.

3. Options selected in the SCCs incorporated by this DPA (Module 4 and, where relevant, Module 3)

4. Transfer impact assessment (summary)

4.1. Scope. The Company has assessed transfers to the U.S. Sub-processors listed in Annex 3. [Drafting note: the full written TIA must be completed and kept on file. This is a summary.]

4.2. Data transferred. Mostly business data (advertising performance metrics, campaign settings, aggregated analytics) with limited personal data. That personal data consists of: prompts and context excerpts sent for AI inference, which may include personal data such as comment text (never LinkedIn member data) or order-level data where a task requires it; and URLs and public page content for crawling. Authorized User identity data for authentication is not transferred, because the identity provider is self-hosted in the EU. OAuth tokens are never sent to AI Providers. Hashed identifiers for conversion uploads are not sent to AI Providers. They go directly to the Third-Party Platform the Customer designates.

4.3. Laws of the destination country. U.S. law allows public authorities to access data held by certain service providers, including under Section 702 of the Foreign Intelligence Surveillance Act and Executive Order 12333. Executive Order 14086 introduced necessity and proportionality limits and a redress mechanism (including the Data Protection Review Court). The European Commission considered these safeguards when it adopted the DPF adequacy decision, and they apply to all data transferred from the EU, whatever transfer tool is used. The assessment also considers developments affecting U.S. oversight bodies, including the changes to the composition of the Privacy and Civil Liberties Oversight Board in 2025, and the grounds raised in Case C-703/25 P. If these developments materially weaken the safeguards, the Company will apply additional supplementary measures or suspend the affected transfers (Section 11.4).

4.4. Supplementary measures. (a) Encryption in transit over public networks (TLS 1.2 or higher) for all transfers to Sub-processors. (b) Data minimisation: only task-relevant excerpts are sent, credentials are excluded, and personal data is redacted from observability traces. (c) Short retention at AI Providers: requested zero data retention, and otherwise the provider's standard retention period. (d) Contractual commitments by Sub-processors to notify and challenge government access requests where legally possible. (e) The Company's own commitments in Section 15. (f) Storage of the primary data set in the EU, on the Company's own infrastructure in Romania (EU), with encrypted database backups. Encryption at rest of the servers' disks: [TBC – confirm with infrastructure owner].

4.5. Conclusion. Given the nature of the data, the minimisation and retention measures and the safeguards under U.S. law described above, the Company considers that the transferred data will receive a level of protection essentially equivalent to that guaranteed in the EU. The assessment is reviewed at least annually, when a Sub-processor changes, and when there are relevant legal developments (including the outcome of Case C-703/25 P).

4.6. The Customer may request a copy of the full transfer impact assessment, subject to confidentiality.