Data Processing Addendum

Eyadera LLC · Exhibit A to the Master Services Agreement · Version 1.4 (21 Oct 2026) · published at /legal/dpa

This Data Processing Addendum ("DPA") forms part of the Master Services Agreement (the "MSA") between Eyadera LLC ("Eyadera") and the Client named in the MSA or Order ("Client"). It applies whenever Eyadera processes Client Personal Data. If it conflicts with the MSA or an Order on the processing of personal data, this DPA prevails.

1. Definitions

• "Client Personal Data": personal data (any information relating to an identified or identifiable individual) contained in Client Data that Eyadera processes for Client under the MSA. Typical examples: names, job titles, work emails and phone numbers of Client staff, customers and suppliers as they appear in orders, quotes, work orders, emails and system exports; written interview answers and interview chat transcripts.
• "Data Protection Laws": all privacy and data-protection laws that apply to a party's processing of Client Personal Data, which may include US state privacy laws (such as the California Consumer Privacy Act, as amended, the "CCPA") and, where applicable to a party, the EU General Data Protection Regulation 2016/679 ("GDPR") and Spain's Organic Law 3/2018 ("LOPDGDD").
• "Subprocessor": a third party Eyadera engages that processes Client Personal Data.
• "Security Incident": a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Client Personal Data.
• "controller", "processor", "business", "service provider" and "processing" have the meanings given in the applicable Data Protection Laws.

2. Roles and instructions

2.1 Client is the controller (or "business") and Eyadera is the processor (or "service provider") of Client Personal Data.

2.2 Eyadera processes Client Personal Data only on Client's documented instructions. The MSA, the Orders and this DPA are Client's complete instructions. Eyadera will tell Client if it believes an instruction breaks Data Protection Laws.

2.3 Details of processing

2.4 US state law service-provider terms. Client discloses Client Personal Data to Eyadera only for the limited and specified business purposes in section 2.3. Eyadera will: (a) not sell or share Client Personal Data (as "sell" and "share" are defined in the CCPA and similar laws); (b) not retain, use or disclose it for any purpose other than the business purposes in section 2.3 (which include creating Learnings under section 2.5 and the other uses these laws allow a service provider, such as improving the quality of its services without using personal information to perform services for others), including any other commercial purpose, or outside the direct business relationship between Client and Eyadera; (c) not combine it with personal data Eyadera receives from or on behalf of others, or collects from its own interactions with individuals, except as those laws allow; (d) comply with the obligations that apply to it under those laws and give the same level of privacy protection they require; (e) notify Client if it determines it can no longer meet those obligations; and (f) allow Client, on notice, to take reasonable and appropriate steps to stop and remediate unauthorized use of Client Personal Data, and to ensure Eyadera uses it consistently with Client's obligations (section 10 sets out how). Eyadera certifies that it understands and will comply with these restrictions.

2.5 Learnings. Client instructs Eyadera, as part of the Services, to create Learnings (MSA section 7.7) by removing all personal data and identifying detail. Learnings contain no Client Personal Data. Eyadera takes reasonable technical and organizational measures so that Learnings cannot be linked to an individual, will not try to re-identify anyone, and requires the same of anyone it shares Learnings with. Where data has been de-identified in this way, it is "deidentified" information under the CCPA and similar laws and anonymous information under the GDPR and UK GDPR, and is outside this DPA. If Eyadera ever finds personal data in a Learning, it deletes the data. Learnings are stored separately from Client Personal Data, and Eyadera may use them to develop its own tools and models, including to train them in future, on accounts it owns (MSA section 9.3). This does not change section 3.4(a) or the deletion periods in section 8.

3. AI processing

3.1 Eyadera uses AI models to process Client Data as part of the Services. AI use is a condition of signing the Order; there is no option to perform the Services without AI (MSA section 9.2).

3.2 Eyadera accesses AI models only through providers on its Approved AI Provider List (Annex 1, row "AI service providers"), through their commercial API services under business terms, never through consumer apps, and never with Client Data in any service whose terms allow the provider to train on it.

3.3 AI service providers. Eyadera uses only AI service providers engaged under business/API terms that prohibit training on Client Data, listed on Eyadera's Approved AI Provider List (available on request, updated with notice). The list names each provider, the service used, its business data terms, its training and retention position as checked by Eyadera, and the date last checked. Eyadera re-checks a provider's terms before adding it and at least every 6 months. Each provider on the list is a Subprocessor under section 6 and Annex 1, and additions or replacements follow the notice process in section 6.2 and 6.3.

3.4 What Eyadera promises, and what it does not. Eyadera promises that (a) it will not use Client Data to train, fine-tune or improve any AI model; (b) it will not opt in to any provider data-sharing or training programme for accounts that process Client Data; (c) it will use only endpoints or settings that do not store Client Data beyond the provider's standard abuse-monitoring window, or will delete stored items when the work is done; and (d) it will not use Client Data in any AI service whose terms permit training on it. Eyadera will not process Client Data with an AI provider until a zero-data-retention arrangement is in place for the service used (Annex 1). Without one, providers typically keep inputs and outputs for a limited period set by their terms; the retention position of each provider is stated on the Approved AI Provider List.

3.5 Every Deliverable is reviewed by a person at Eyadera before delivery.

4. Eyadera personnel

Eyadera limits access to Client Personal Data to people who need it to perform the Services and who are bound by written confidentiality duties. Today that is Eyadera's Managing Member only. Before any other person accesses Client Personal Data, Eyadera binds them in writing to confidentiality and to data-protection terms at least as protective as this DPA. Any other person who is not an Eyadera employee is added as a Subprocessor under section 6.

5. Security

5.1 Eyadera maintains the measures in Annex 2. Eyadera does not hold SOC 2, ISO 27001 or any other security certification and does not claim to.

5.2 Eyadera may update the measures if the overall level of protection does not decrease.

6. Subprocessors

6.1 Client authorizes the Subprocessors in Annex 1. Eyadera binds each Subprocessor to data-protection terms that protect Client Personal Data at least as well as this DPA (in practice, the Subprocessor's standard data processing terms) and remains responsible for its performance.

6.2 Eyadera gives Client at least 15 days' notice by email before adding or replacing a Subprocessor, and updates Annex 1 at /legal/dpa. If compliance with applicable data-protection law requires it, Client may object in writing within that period, and the parties will discuss the objection in good faith. An objection does not give Client a right to a refund or to end an Order with a refund.

6.3 Approved AI Provider List. The Approved AI Provider List is part of Annex 1. Adding or replacing a provider on that list is a change of Subprocessor under section 6.2: Eyadera emails Client at least 15 days before the new provider processes any Client Personal Data, with the provider's name, location, service and business data terms, and Client may object as described in section 6.2. Removing a provider needs no notice. Client may ask for the current list at any time at info@eyadera.com, and Eyadera sends it within 5 business days. If Client objects to a provider, Eyadera will, where practical, not use that provider for Client's work instead of ending the Order.

7. Assistance and rights requests

Eyadera will, taking into account the nature of the processing: (a) promptly forward to Client any request from an individual about Client Personal Data and not respond itself except to redirect the individual to Client; (b) help Client respond to such requests; and (c) give Client reasonable information to help it with data-protection impact assessments and consultations with authorities. Help that takes more than 4 hours in a calendar year may be charged as a fixed fee that Eyadera quotes, and Client approves, in advance.

8. Deletion and return

8.1 Diagnostic: Eyadera deletes Client's files and answers within 90 days after the report is delivered, or within 30 days after a refund under section 5.1 or 5.2 of the Diagnostic order form, or sooner on written request. Fresh exports Client sends for the day-90 re-measure (due by day 105 after the report is delivered) are deleted within 30 days after Eyadera delivers the comparison (by day 120 after the report is delivered). Other Services: within 30 days after the Order ends. In each case Client may ask for a copy of its data before deletion.

8.2 Eyadera may keep (a) a copy of the Deliverables it delivered, to answer questions about them and to run the day-90 re-measure (day 0 is the day the report is delivered; comparison by day 120), unless Client asks for deletion; (b) invoices, contracts and records the law requires; (c) copies in Subprocessors' backups until they are overwritten in the Subprocessor's normal backup cycle; and (d) Learnings, which contain no Client Personal Data (section 2.5). Kept data in (a) to (c) stays subject to this DPA.

8.3 On request, Eyadera confirms deletion in writing.

9. Security Incidents

9.1 Eyadera notifies Client without undue delay, and in any event within 48 hours, after becoming aware of a Security Incident affecting Client Personal Data.

9.2 The notice describes, as far as then known: what happened; the data and approximate number of individuals affected; likely consequences; and what Eyadera has done and proposes to do. Eyadera updates Client as it learns more, takes reasonable steps to contain and remedy the incident, and cooperates with Client's own notifications. Eyadera does not notify regulators or individuals about Client Personal Data on Client's behalf without Client's agreement, unless the law requires it.

9.3 Notifying a Security Incident is not an admission of fault.

10. Audits

Eyadera makes available the information reasonably needed to show compliance with this DPA, including written answers to a reasonable security questionnaire once a year. If that is not enough to meet a legal requirement, Client may audit Eyadera's compliance once a year, at Client's cost, on 30 days' notice, during business hours, in a way that does not compromise other clients' confidentiality; remote document review is the default.

11. International transfers and the GDPR

11.1 Where data goes. Client Personal Data comes from US businesses and is stored with the providers in Annex 1, which are US companies; Supabase and Vercel are used in US regions. Eyadera's Managing Member works from Spain, so Client Personal Data is accessed from Spain.

11.2 GDPR. Because its Managing Member works from Spain, Eyadera applies the GDPR to its own processing: as processor for Client Personal Data, and as controller for its own business contacts. This DPA covers the processor terms in GDPR Article 28(3) (instructions, confidentiality, security, subprocessors, assistance, deletion and audits).

11.3 What that means for Client. A US Client without EU operations does not become subject to the GDPR because it uses Eyadera. Where data moves from Eyadera to a Subprocessor outside the EU, Eyadera uses only Subprocessors that offer a transfer mechanism recognized under GDPR Chapter V, such as certification under the EU-US Data Privacy Framework or the European Commission's Standard Contractual Clauses in their data processing terms.

11.4 Client will not send Eyadera personal data of individuals in the EU or UK without telling Eyadera first, so that the parties can agree any additional terms needed.

12. Term

This DPA lasts as long as Eyadera processes Client Personal Data.

Annex 1: Subprocessors

A. Authorized Subprocessors

Eyadera may use one or more providers from the Approved AI Provider List, including several in parallel to review the same Deliverable. Until Eyadera tells Client in writing that its Diagnostic intake application is used for Client's engagement, Client files go only to Google Drive (above), and Supabase and Vercel receive no Client Personal Data. Eyadera keeps the Supabase project and the Vercel functions in US regions and gives notice under section 6.2 before moving either outside the US.

B. Not Subprocessors for Client Personal Data (listed so Client knows they exist): Firstbase (registered agent and postal mail); Zoho Corporation (Zoho Sign e-signature: names, emails and signatures of the people who sign contracts with Eyadera); Apollo.io and Smartlead (outreach): they handle prospect contact data, not Client Data.

Annex 2: Security measures

1. All Eyadera systems that hold Client Data are established cloud services that encrypt data in transit (TLS) and at rest, according to their published security documentation.
2. Access to Client Data is limited to Eyadera's Managing Member and any person bound under section 4.
3. Multi-factor authentication is enabled on every account that holds Client Data (email, file storage, CRM, AI provider consoles, hosting).
4. Every device used to access Client Data uses full-disk encryption and a screen lock.
5. Client files are stored only in the storage location named in Annex 1, in a folder per client, not on removable media.
6. The Diagnostic needs no logins to Client systems: Client exports files and removes what is not needed. Eyadera asks for minimized exports where possible.
7. Eyadera does not ask for and will not accept passwords or system credentials for the Diagnostic or for Advisory. For First Fix work it uses only named accounts that Client creates for Eyadera and can revoke, with the lowest access the written scope needs (read-only unless the scope says otherwise) and multi-factor authentication. Credentials are never sent by email or chat, never stored in documents, code or AI tools, and are kept only in Eyadera's password manager. Access ends when the work ends: Client disables the account and Eyadera deletes its stored copy within 5 Business Days and confirms this in writing.
8. AI models are used only through business API services with the no-training terms in section 3.
9. API keys and secrets are kept in a secrets manager or the provider's secret store, never in code repositories or documents, and any key that has been exposed is rotated.
10. Client Data is not used for marketing, examples or samples. Eyadera's samples use fictional companies.
11. Deletion periods in section 8 are tracked per engagement.
12. Eyadera keeps a written incident log and checks provider security alerts.

Not claimed: SOC 2, ISO 27001 or any other certification; penetration testing; 24/7 monitoring.

Version 1.4 (21 Oct 2026)