Data Processing Agreement

Official document: The German version is the official document. If translations differ, the German version prevails. Read the German version.

Version: November 2026 (05.11.2026)

between

the customer using eDoer under a Service Agreement
(“Controller”)

and

Education4All GmbH
Registered office: Hildesheim, Germany
Registered with the commercial register of the Local Court of Hildesheim under HRB 210458
as operator of the “eDoer” learning platform
(“Processor”)

Controller and Processor together referred to as the “Parties”.

This Data Processing Agreement (“DPA”) forms part of the Service Agreement between the Parties.

eDoer is the learning platform and related services operated by Education4All GmbH. In this agreement, references to eDoer describe the Platform and, where legal responsibility is concerned, Education4All GmbH as its operator.

1. Subject Matter and Duration

1.1 This DPA governs the processing of personal data by the Processor on behalf of the Controller in connection with the provision of the eDoer learning platform.

1.2 This DPA applies only to personal data processed by eDoer strictly on behalf of the Controller.

1.3 Processing activities performed by eDoer as an independent controller (see Section 5.4) are not subject to this DPA.

1.4 The Processor provides a multi-tenant learning management platform (“eDoer”) enabling the Controller to:

• Create and manage organizations
• Register and manage users
• Create and manage learning paths, modules, and courses
• Deliver assessments and evaluations
• Issue certificates
• Enable communication within the organization
• Provide in-app notifications and transactional notification email
• Store educational content and related materials
• Configure AI-assisted features, including organization knowledge base files and learner background documents where enabled
• Enable approved third-party document imports where enabled

The Processor processes personal data solely to provide these services.

1.5 Processing shall take place for the duration of the Service Agreement.

Upon termination of the Agreement, personal data shall be deleted or returned in accordance with the provisions of the DPA, unless statutory retention obligations apply.

2. Nature and Purpose of Processing

2.1 Processing is carried out primarily by automated means within secured server infrastructure and may include:

• Collection
• Recording
• Organization and structuring
• Storage
• Retrieval and consultation
• Limited transmission to authorized sub-processors
• AI-based processing where enabled by the Controller
• Import from approved third-party document sources where enabled
• Deletion or anonymization

Processing is limited to what is necessary for the provision of the services.

2.2 The Processor processes personal data for the purpose of:

• Providing and maintaining the learning platform
• Enabling course management and delivery
• Processing assessments and learning progress
• Generating certificates
• Facilitating communication within the organization
• Providing recipient-specific notifications, moderation communications, and transactional notification email
• Storing and organizing educational and reference materials
• Supporting AI-assisted features configured by the Controller, including organization knowledge base files and learner background documents where enabled
• Supporting approved third-party document imports where enabled
• Providing technical support

The data processor does not process personal data for its own marketing purposes or for its own commercial gain. Processing is limited to what is necessary for the provision of the services.

The Processor shall process personal data only on documented instructions from the Controller.

If the Processor considers that an instruction infringes the GDPR or other applicable Union or Member State data-protection law, it shall immediately inform the Controller and may suspend the affected processing until the instruction is confirmed, amended, or withdrawn.

2.3 Patient-Education Intended Purpose

Where enabled by the Controller, eDoer supports patient education and health literacy by helping authorized Users search, retrieve, organize, translate, summarize, and understand educational materials and submitted documents. These functions support comprehension of source information, including medical terminology and instructions already supplied by healthcare professionals.

These functions are intended for education and information access, without an intended medical-device purpose under Regulation (EU) 2017/745 (MDR). They are not intended for diagnosis, prevention, monitoring, prediction, prognosis, treatment or alleviation of disease or injury, or for generating information intended to determine individual diagnostic or therapeutic decisions. This excludes symptom assessment or triage, clinical interpretation of laboratory results or medical images, individual clinical-risk assessment, and recommendations to start, stop, or change treatment or medication.

Existing healthcare-professional instructions may be presented or explained for comprehension, without independently assessing their clinical suitability or recommending changes. Summaries and explanations do not replace the original documents or professional medical assessment. Personalization and progress tracking concern educational needs and understanding, rather than assessment of health status or clinical outcomes.

The Controller shall configure and use the patient-education functionality within this educational scope.

3. Categories of Data Subjects

• Learners (students)
• Teachers / curators
• Organization administrators
• Patients and other healthcare service users, including authorized relatives or carers participating in patient education, where applicable
• Healthcare professionals and authorized healthcare staff, where applicable
• Other authorized users designated by the Controller

4. Categories of Personal Data

Data processing may involve personal data, a list of the used categories can be found in Annex I.1.

The Services do not require special categories of data under Article 9 GDPR for standard educational use. Where patient-education functionality is enabled by the Controller, the Services may intentionally process data concerning health within the meaning of Articles 4(15) and 9 GDPR for the educational purposes described in Section 2.3.

Special-category data may also appear in free text, messages, attachments, learner background documents, imported files, or AI inputs. The Controller shall not submit or authorize such data unless it has documented an applicable Article 6 lawful basis and Article 9(2) condition, the purpose, affected features, access restrictions, retention, and any required DPIA. Where Article 9(2)(h) is relied upon, the requirements of Article 9(3) and applicable professional-secrecy law must also be satisfied.

The safeguards in Annex II apply to this processing.

5. Roles of the Parties

5.1 The Controller determines the purposes and means of processing educational data within the platform.

5.2 The Processor processes personal data exclusively on behalf of the Controller pursuant to Article 28 GDPR.

5.3 The Parties classify each processing activity according to their actual determination of its purposes and essential means. The Parties do not intend joint controllership for the processing described in Annex I; if they jointly determine a separate activity, they shall conclude and make available the essence of an Article 26 arrangement before that activity begins.

5.4 eDoer acts as an independent controller only for distinct processing whose purposes and essential means it determines, including account and tenant security, fraud and abuse prevention, system stability and infrastructure monitoring, consent-based browser telemetry, consent and contract evidence, organization subscription billing, statutory financial administration, mandatory platform communications, and legal compliance. Such processing is governed by eDoer’s Privacy Policy and controller RoPA and is outside this DPA.

5.5 Where Marketplace Services are enabled, eDoer acts as an independent controller for the marketplace purposes it independently determines, including platform commissions, reconciliation, platform security, fraud and loss prevention, platform audit records, and statutory financial administration. Seller, Stripe, and eDoer roles for onboarding, checkout, payment, refunds, disputes, and compliance are determined per activity under the applicable agreements and actual allocation of purposes and essential means. Any processor or joint-controller activity must be documented before activation.

5.6 Learning-path enrollment, access, progress, assessment, and certification data arising after a marketplace purchase remain processed on the Controller’s documented instructions under this DPA. A marketplace purchase reference and entitlement status may be linked to the learner record solely to grant, suspend, restore, or revoke the corresponding access.

5.7 Where a notification or transactional email is generated from educational or organizational activity controlled by the Controller, eDoer processes the notification content and delivery data on the Controller’s documented instructions. Processing by eDoer for its own account security, billing, legal obligations, fraud prevention, or mandatory platform administration remains outside this DPA and is described in the Privacy Policy.

5.8 The Controller is responsible for establishing a lawful basis and, where applicable, an Article 9 condition; providing Articles 13 and 14 information; determining lawful retention and access; ensuring the accuracy and proportionality of instructions; managing permissions; and completing any required DPIA or prior consultation.

5.9 Where Users may be minors, the Controller shall document the applicable authorization, age-appropriate transparency, safeguarding, and feature-configuration requirements. eDoer remains responsible for these obligations for processing in which it acts as controller.

6. AI-Assisted Features

6.1 The platform may use AI services to support educational features, including:

• Learning path generation
• Educational content generation and assistance
• Exam generation
• Retrieval and grounding based on organization knowledge base files
• Personalized assistance using learner background documents where enabled

6.3 The Processor does not intentionally transmit learner performance data, assessment results, progress tracking data, or platform account identifiers as separate structured AI inputs. However, such data may be contained in content, files, prompts, attachments, or background documents intentionally submitted by the Controller or an authorized user for AI processing.

6.4 The Processor applies data-minimization measures to AI processing. Special-category data is processed only in accordance with Section 4.

6.5 Where approved document-source integrations such as e.g. Roxtra are enabled by platform-level administration and the Controller, the Processor may process the connecting user’s integration username and encrypted credential material to authenticate with the third-party source, search documents, and import selected files into eDoer.

6.6 Imported third-party files are stored in eDoer and thereafter processed like other files uploaded to the platform under the Controller’s instructions.

6.7 Third-party source systems designated by the Controller for search and import are not sub-processors engaged by the Processor unless expressly listed in Annex III.

6.8 Annex III describes the principal stages of AI processing, including preprocessing, OCR, embeddings, retrieval, summaries, generation, voice/video model calls, and storage. Processing may begin on source indexing before a chat request. The Processor shall keep a current processing schedule describing the applicable processing arrangements and safeguards and make it available to the Controller.

6.9 Organization-specific AI deployments require a separate agreement before activation. Once activated, all AI model processing shall use the agreed deployment.

6.10 A provider contracted by the Processor is its sub-processor. A provider contracted directly by the Controller is the Controller's processor under a separate Article 28 agreement; eDoer's connection and disclosure require the Controller's documented instructions.

7. Sub-Processors

7.1 The Controller authorizes the Processor to engage sub-processors.

7.2 Sub-processors may include:

• Cloud hosting providers
• Object storage providers
• Email service providers
• Infrastructure and security providers
• AI service providers
• Automated data-gathering providers used on demand for approved source-import and preprocessing flows (currently Decodo for webpage extraction and certain YouTube metadata and transcript requests)

7.3 The Processor shall:

• Enter into written agreements with sub-processors in accordance with Article 28 GDPR
• Impose by written contract the same data-protection obligations required by Article 28(3) GDPR, including documented instructions, confidentiality, security, assistance, deletion or return, and audit support,
• Remain fully liable for sub-processor’s performance

7.4 For every AI content-processing stage, the Processor shall use only approved enterprise/API terms prohibiting the provider's use of submitted content and outputs for its own model training. Training opt-ins, content-bearing feedback, and preview/labs services without that protection shall not be used for Controller data. This restriction does not mean that no data is retained: approved security/abuse monitoring, service state, and legally required records remain subject to the provider-specific limits in Annex III.

7.5 The Processor shall notify the Controller in writing, including by email, of any intended addition or replacement of a sub-processor at least three (3) working days before the proposed sub-processor begins processing the Controller’s Personal Data. The notice shall identify the sub-processor, its processing activities and locations, and applicable data-protection safeguards. A longer notice period shall be provided where reasonably necessary to enable meaningful assessment of the proposed change.

The Controller may object within the notified period on reasonable data-protection grounds. If no objection is received within that period, the Processor may proceed under the Controller’s general written authorisation. If the Controller objects, the Parties shall seek a practicable resolution. The Processor shall not implement the disputed change in respect of the Controller’s Personal Data pending resolution. If no resolution is available, the Controller may terminate the affected Service before the change takes effect.

Where an urgent security or availability need requires an earlier change, the Processor may seek the Controller’s specific written authorisation to implement it before the notice period expires.

7.6 The Processor shall proactively supply and keep current a register of the entire processing chain, including all tiers of onward sub-processors, their legal names, addresses, contact persons (name, position, and contact details), activities, and allocation of responsibilities. The Controller shall receive updates and information necessary to assess sufficient guarantees, retention, transfers, and provider authorization. Provider sub-processor lists support this register but do not replace identifying the recipients used for the Controller's actual services. This obligation reflects EDPB Opinion 22/2024.

8. International Transfers

8.1 Where personal data is transferred outside the EU/EEA, the Processor ensures appropriate safeguards under Chapter V GDPR.

8.2 Primary processing by a sub-processor in the EU/EEA is not treated as a third-country transfer. Where personal data is transferred onward outside the EU/EEA, the applicable safeguards may include the European Commission Standard Contractual Clauses and the EU-US Data Privacy Framework where available and applicable.

• Standard Contractual Clauses apply where required for an onward third-country transfer.
• The EU-US Data Privacy Framework will be used where available and legally applicable.

Further details can be found in Annex III.

8.3 The Processor maintains and documents a Transfer Impact Assessment.

9. Security Measures

The Processor implements appropriate technical and organizational measures, including:

• Encrypted transmission (TLS)
• Role-based access control
• Organization-level data isolation through architecture
• Logging of administrative access
• Encryption of stored third-party integration credentials
• Incident response procedures

A summary of technical and organizational measures is attached as Annex II.

10. Data Subject Rights

• The Processor shall assist the Controller in responding to requests under Articles 15–22 GDPR.
• The Controller remains responsible for responding to such requests.

11. Personal Data Breach

The Processor shall notify the Controller without undue delay after becoming aware of a personal data breach affecting personal data processed under this DPA and shall provide available information necessary for Articles 33 and 34 GDPR, including the nature of the breach, affected data and data-subject categories, approximate scale where known, likely consequences, mitigation, and a contact point. Information may be supplied in phases as the investigation progresses. The Processor shall document the incident, preserve relevant evidence, cooperate with the Controller, and assist with obligations under Articles 32–36 GDPR, including DPIAs and prior consultation.

12. Deletion and Return of Data

Upon termination of the Service Agreement, the Processor shall:

• At the Controller’s choice, delete or return personal data and delete remaining copies, unless applicable law requires continued storage
• Retain data only where legally required

Personal data remaining in backups shall be isolated from ordinary use, protected, and deleted on the documented backup lifecycle. If deletion is temporarily impossible, the Processor shall continue to apply this DPA and process the data only for restoration, security, or a documented legal requirement.

12.1 Unless the Controller gives a lawful documented instruction requiring earlier deletion, or applicable law requires longer storage, the Processor applies the following standard technical retention schedule to personal data processed under this DPA:

• Soft-deleted AI conversations and their associated messages, generation-job records, and usage records are permanently removed after a recovery period of up to 30 days.
• Completed AI generation-job records and per-call token-usage records are retained for 90 days.
• Temporary generated-image output expires after 1 hour and is removed with its temporary job record by scheduled cleanup.
• Derived AI indexes, raw OCR/extraction artifacts, normalized passages, summary caches, and necessary source mappings are retained while the underlying source exists. Deletion of the source triggers removal from the retrieval system and associated artifacts/caches; failed or delayed removals are remediated so deletion is completed within 30 days. Completed removal-job metadata is retained for 90 days.
• Rotated AI service log files are retained for no more than 14 days and may be deleted sooner through size-based rotation. Other processor-side operational logs containing Controller personal data are retained for no more than 90 days unless a shorter operational period applies.
• Expired verification tokens are removed 30 days after expiry; read or seen notifications after 90 days; unread and unseen notifications after 180 days; terminal notification-email delivery records after 180 days; and consent audit records and the minimal completed user-erasure audit ledger after 730 days.

12.2 The database retention process runs once per day and once when the privacy worker starts. AI-service cleanup runs at shorter intervals to enforce temporary-image and AI-record expiry. These schedules do not delay a valid data subject or Controller deletion instruction where earlier deletion is required and technically possible.

12.3 Encrypted database backups are created daily and retained for 7 days on a rolling basis. Deleted data is not restored to ordinary use. Before a restored backup serves production traffic, applicable deletion records are reapplied. A documented legal hold or statutory obligation may suspend deletion only for the affected data and required period, with access restricted accordingly.

13. Audit Rights

13.1 The Processor shall make available information necessary to demonstrate compliance with Article 28 GDPR and this DPA.

13.2 The Processor shall allow for and contribute to audits, including inspections, as required by Article 28(3)(h) GDPR, with reasonable notice where appropriate and measures protecting confidentiality, security, and other customers’ data.

13.3 Current independent audit reports or certifications may be used to satisfy reasonable audit requirements where they provide sufficient relevant assurance, without limiting the Controller’s rights where additional verification is required.

14. Liability

Liability is governed by the Service Agreement and Article 82 GDPR.

Annex I – Processing Description

This Annex forms part of the Data Processing Addendum between the Parties.

1. Categories of Personal Data

The processing may involve the following categories:

1.1 Identification and Account Data

• Name
• Email address
• User role
• Organizational affiliation
• Additional user profile and account attributes defined by the Controller, including custom field values

1.2 Educational Data

• Enrollment information
• Learning progress
• Assessment results
• Submitted assignments
• Completion status

1.3 Certification Data

• Name
• Grade or completion status
• Date of issuance

1.4 Communication Data

• Topics and messages within path, curator-only, and direct-conversation scopes

• Replies, mentions, reactions, attachments, topic participants and scope, and read-state timestamps

• Reports, reporter identity, report reason, shared-thread choice, status, moderation action and actor, and related timestamps

• Where a reporter elects to share a thread, the relevant discussion may become accessible to an otherwise authorized moderator for review of the pending report

1.5 Files and Reference Materials

• Uploaded files
• Organization knowledge base files and related reference materials where enabled
• Learner background documents where enabled
• Imported files from approved third-party document sources where enabled

1.6 Optional Integration Data

• Third-party document-source username for each user
• Encrypted credential material required to authenticate and import files
• Import metadata and logs
• External source URLs (including path/query information), YouTube video or playlist identifiers, language preferences, retrieval parameters, and retrieved webpage content or public metadata/transcripts where Decodo-assisted import or preprocessing is used

1.7 Technical Data

• Timestamps
• Log information necessary for system operation
• IP address (where technically required)

Special-category data is not required for standard educational use but may appear in User-submitted or imported content. Where patient-education functionality is enabled, health data may be intentionally processed as described in Section 1.10 of this Annex. The Controller shall identify the applicable Article 9 GDPR condition and documented instructions before authorizing such processing. The Processor applies role-based access, tenant isolation, encrypted transport, support-access controls, minimization, deletion instructions, and the other measures in Annex II.

1.8 Marketplace-Derived Learning Access Data (where enabled)

• Learner user identifier

• Purchased learning path and access-entitlement status

• Purchase reference and fulfillment, suspension, or revocation timestamps

• No payment-card, bank-account, or seller-verification documents are intentionally stored in the educational learner record

1.9 Notification and Email Delivery Data

• Recipient user and Organization identifiers; event type and category; activity-derived payload and context; destination; and created, updated, read, seen, and deletion timestamps
• Notification-email category preferences and whether optional email is enabled
• Scheduled delivery time, delivery status and skip reason, attempt count, provider message identifier, reconciliation key, acceptance, sent, skipped and failed timestamps, and error information
• Email sender and recipient, subject, text and HTML body, and attachments where applicable

1.10 Health and Patient-Education Data — Where Enabled

For the educational purposes described in Section 2.3, processing may include:

• Medical and healthcare documents containing medical history, recorded diagnoses, symptoms, laboratory and test results, medication, prescription, or treatment-related information
• Healthcare-provider instructions and patient-education materials relating to identifiable individuals
• Health information contained in submitted messages, attachments, voice inputs, prompts, and AI conversations
• AI-generated summaries, explanations, responses, and derived retrieval data that contain or reveal information about an individual’s health
• Enrollment, questionnaire responses, and learning activity where they reveal information about an individual’s health

Processing is subject to Section 4, the Controller’s documented instructions, and the safeguards in Annex II. These data categories do not extend the Platform’s intended purpose to the clinical functions excluded by Section 2.3.

2. Instruction Limitation

The Processor shall process personal data exclusively on documented instructions of the Controller and shall not determine the purposes or essential means of processing under this Annex.

Annex II – Technical and Organizational Measures

This Annex describes the technical and organizational measures implemented by the Processor to ensure an appropriate level of security.

1. Organizational Measures

1.1 Governance and Responsibility

• Clear internal allocation of data protection responsibilities
• Management oversight of data protection compliance
• Documented privacy and security policies
• Access to production systems limited to authorized personnel only

1.2 Confidentiality Obligations

• All personnel are bound by confidentiality agreements
• Access to personal data restricted on a need-to-know basis
• Role-based access management enforced

1.3 Training and Awareness

• Staff involved in development and operations receive data protection and security awareness training
• Developers are instructed in data minimization principles, especially for AI integrations and third-party document imports

2. Access Control

2.1 Logical Access Control

• Role-Based Access Control (RBAC)
• Authentication required for all administrative actions
• Strong password requirements
• Password hashing using industry-standard algorithms (e.g., bcrypt/argon2)

2.2 Administrative Access

• Administrative access limited to authorized personnel
• Super-admin access only for:
  • Technical troubleshooting
  • Security investigation
  • Documented support requests
• Administrative actions are logged
• Access subject to internal approval procedures where applicable

3. Infrastructure Security

3.1 Hosting Environment

• Application, file storage, and database servers are hosted on infrastructure provided by Hetzner in EU data center locations
• Firewalls restrict unnecessary inbound connections
• Database servers are not publicly exposed

3.2 Network Security

• All external communication encrypted via TLS (HTTPS)
• Application traffic routed through bunny.net's EU-only reverse proxy/CDN; traffic filtering and associated CDN processing take place exclusively within the EU
• DDoS mitigation and traffic filtering enabled
• Secure DNS configuration

3.3 Database Security

• Database access restricted to application layer
• No public database endpoints
• Access credentials stored securely using environment variables
• Regular updates and patching of system software

4. Data Isolation (Multi-Tenant Architecture)

• Strict organization-level data separation enforced at application layer
• Authorization checks implemented on all data access endpoints
• No cross-organization data access is permitted except for documented, authorized, time-limited support or security access described in this DPA
• AI requests are tenant-isolated (no cross-tenant data mixing)

5. Encryption

• TLS 1.2+ enforced for all external traffic
• Encrypted API communication with approved sub-processors (including OpenAI, Google Cloud, Mistral AI, and Amazon Simple Email Service (Amazon SES))
• Third-party integration credentials stored in encrypted form
• Signed or time-limited file URLs used for non-public file access where applicable

6. Backup and Recovery

• Daily automated database backups

• Rolling backup retention of 7 days

• Secure storage of backup files

• Backup access restricted to authorized personnel

• Documented restoration and continuity procedures

• Periodic validation that backups required for recovery can be restored

• Protected deletion of backups after the 7-day lifecycle

• Reapplication of applicable deletion records before a restored backup serves production traffic

7. Logging and Monitoring

• Application error logging enabled

• Security-relevant events logged

• Administrative access logged

• Rotated AI service file logs retained for no more than 14 days, subject to earlier size-based rotation

• Other processor-side operational logs containing Controller personal data retained for no more than 90 days unless a shorter period applies

• Logs protected against unauthorized modification

• Documented incident classification, escalation, containment, evidence preservation, and post-incident review

• Risk-based review and testing of the effectiveness of technical and organizational measures

• Periodic access review, vulnerability remediation, and security-update processes

8. Development and Testing Controls

• Development and production environments logically separated
• AI analytics disabled in development environments
• Test data does not intentionally contain production personal data
• Deployment processes controlled

9. Data Minimization in AI Processing

• AI processing is limited to:
  • Educational content
  • Learning path metadata
  • Examination texts
  • Voluntarily submitted free-text requests
  • Organization knowledge base files, learner background documents, and User-submitted files or attachments authorized for AI processing
  • Where patient-education functionality is enabled, health information necessary to process the specific User request
• No intentional transmission as separate structured AI inputs, subject to Section 6.3, of:
  • Learner performance data
  • Assessment results
  • Account identifiers
• Special-category data is not required for standard educational AI functionality. Where patient-education functionality is enabled by the Controller, health data may be transmitted to authorized AI sub-processors only where necessary for the specific User request, on the Controller’s documented instructions, and subject to Section 4.
• Approved AI terms prohibit provider model training with submitted content and outputs under Section 7.4.
• Individual AI API calls may transmit full documents, document/image bytes, retrievable source URLs, passages, queries, audio, or authorized context. Indexing, extraction, and summary jobs may run asynchronously and store derived artifacts; AI processing is not limited to interactive chat request-response calls.

10. Physical Security

• Physical security is managed by the infrastructure providers actually used for the Services, including Hetzner, BunnyWay d.o.o. (bunny.net), and the AWS entities supporting Amazon SES in Europe (Frankfurt), as identified in the current sub-processor register
• Providers maintain industry-standard physical access controls

11. Regular Review

• Technical and organizational measures reviewed periodically
• Adjusted based on:
  • Risk assessment
  • Infrastructure changes
  • Regulatory developments

Annex III – List of Sub-Processors

A. AI stages and applicable provider profiles

For Organization content the Controller remains controller and Education4All GmbH processor. The eDoer-appointed recipients below are sub-processors under Article 28; customer-appointed providers are addressed separately in Section 6.10. Only stages necessary for the enabled feature are used. Each row is subject to the location, retention, training, and transfer terms in the named profiles below and the processing schedule maintained under Section 6.8.

The Processor shall not use Controller content for independent model training. Hosting and technical service records are limited to providing, securing, and administering the approved services. Provider ZDR does not remove the Processor's retained source material or outputs. Provider-side content retention is distinguished below from account, billing, security, and legally required records. The processing/transfer register records their purposes, applicable role, periods, access locations, and onward recipients; an EU content-residency commitment alone does not cover them.

B. eDoer-appointed provider profiles

The following profiles form part of the Controller's authorization under Section 7. Data-processing agreements are in place with the listed providers. The processing schedule maintained under Section 6.8 records the applicable service configurations, retention periods, deletion procedures, and exceptions. The Processor shall ensure that retention is limited to the purposes and periods specified in that schedule and the applicable data-processing terms. Any retention required by law shall be limited to the data and duration required by that law. The profiles specify:

1. Address
2. Service
3. Location
4. Transfer mechanism
5. Retention and deletion for AI processing, where relevant
6. Contractual role and training restriction for AI processing, where relevant

For each profile, primary EU/EEA processing does not itself require a Chapter V transfer mechanism. For any third-country access or onward transfer, the Processor must verify the actual recipient and use an applicable adequacy decision, valid DPF participation for the recipient/service concerned, or the applicable 2021 SCC module, with a transfer assessment and supplementary measures where required. Contracting in the EU alone does not establish the processing location. The register under Section 7.6 contains contact-person details and onward sub-processor identities; the Processor shall keep it current and proactively supply updates to the Controller.

OpenAI Ireland Ltd.

1. 117-126 Sheriff Street Upper, Dublin 1, D01 YC43, Ireland
2. Document/query embeddings, RAG summaries and synthesis, chat/planning, text/image generation and visual review, transcription, spoken playback/video narration, and enabled native search or retrieval
3. The Processor shall identify the applicable processing, storage, support, and onward-access locations in the register under Section 7.6. Any processing involving third-country access or transfers is subject to the safeguards in item 4 and Section 8.
4. For non-EEA access/onward transfers: the recipient-specific safeguard described above under the applicable OpenAI data-processing terms
5. Content processed for API abuse monitoring may be retained for up to thirty (30) days, subject to applicable legal and security exceptions. Stored Responses application state is subject to a default retention period of thirty (30) days. Files and hosted retrieval state may remain until deletion is initiated, after which the applicable service-specific deletion periods apply. The Processor shall document the authorized endpoints and models, storage settings, cache periods, deletion procedures, and any additional retention arising from image/file safety review or enabled tools in the processing schedule. See OpenAI data controls.
6. eDoer-appointed sub-processor for Controller content under the applicable Article 28 terms; no provider model training with inputs/outputs under Section 7.4. Separate provider account/security processing must be identified by activity in the register.

Mistral AI

1. 15 rue des Halles, 75001 Paris, France; service contact: support@mistral.ai
2. Document OCR, layout/content extraction and generated image descriptions through eDoer RAG; receives document/image bytes or a retrievable source URL according to format, including any personal data in the source
3. EU residency enabled, using the EU OCR endpoint
4. No Chapter V transfer for EU processing itself; any non-EEA support/access or onward transfer requires the recipient-specific safeguard described above under Mistral's DPA
5. ZDR enabled for the stateless OCR API: request/response content is not retained after processing under the supported endpoint terms. This does not promise zero operational/billing/legal records and does not cover stateful file uploads. The current OCR path sends inline data or a source URL rather than creating a Mistral Files API object. eDoer stores raw/normalized extraction artifacts under Section 12. See Mistral ZDR coverage.
6. eDoer-appointed sub-processor for source content under Mistral's DPA. Model-training opt-out/no-training terms must remain in force separately from ZDR; no content-bearing feedback or unprotected labs/preview models under Section 7.4.

Google Cloud (Google LLC / Google Ireland Ltd.)

1. Gordon House, Barrow Street, Dublin 4, Ireland
2. Configured Google Cloud/Gemini chat/planning, text/image generation, visual review and enabled native grounding/search, including approved fallback calls
3. EU residency enabled for the configured production AI services; account/system data, support and onward access require separate mapping
4. For non-EEA access/onward transfers: the recipient-specific safeguard described above under the applicable Google Cloud data-processing terms; the register identifies the exact contracted entity and onward recipients
5. Retention of abuse-monitoring records and service state is governed by the applicable Google Cloud data-processing and service-specific terms. Implicit in-memory and durable caches are retained for no longer than twenty-four (24) hours after being written. Where Google Search grounding is enabled, the applicable query and contextual-information logs may be retained for up to three (3) days under the published service terms. Before enabling a feature, the Processor shall document its applicable retention periods, cache controls, stored content, deletion procedures, and any exceptions in the processing schedule. See Google Cloud retention controls and abuse monitoring.
6. eDoer-appointed sub-processor for Controller content under the Google Cloud data-processing terms; no model training without customer permission, which eDoer does not give for these flows. Separate provider account/security processing must be identified by activity in the register.

Hetzner Online GmbH / Hetzner Finland Oy

1. Industriestr. 25; 91710 Gunzenhausen; Germany

2. Application, object storage and database hosting, including eDoer AI/RAG, self-hosted Qdrant, extraction artifacts, summary caches, and local media/video processing

3. Germany / Finland (EU)

4. Not applicable

5. eDoer-held sources, raw/normalized extractions, vectors, mappings, summaries and outputs follow Section 12 and the underlying source lifecycle; provider security/service metadata follows the applicable hosting agreement and approved register.

6. eDoer-appointed infrastructure sub-processor under Article 28; hosting does not authorize independent AI model training with Controller content.

BunnyWay d.o.o. (bunny.net)

1. Dunajska cesta 165, 1000 Ljubljana, Slovenia (EU); contact: support@bunny.net
2. Reverse proxy, Content Delivery Network (CDN), TLS termination, traffic filtering and DDoS protection; processing of IP addresses, request/connection metadata and content passing through the service as necessary for delivery and security
3. European Union only for eDoer's configured CDN, including traffic filtering and associated processing
4. Not applicable to this EU-only CDN processing; no third-country transfer is part of this route. Any later change involving third-country access or onward transfers requires prior review under Sections 7 and 8.
5. In eDoer’s Bunny CDN configuration, only CDN request logs with anonymised IP addresses are retained, for three (3) days. No permanent logs are stored.
6. eDoer-appointed infrastructure sub-processor under Article 28 and bunny.net's data-processing agreement; no authorization for independent model training with Controller content. DPA information (agreement available in the bunny.net account dashboard); provider sub-processor list; privacy information. Actual onward recipients remain subject to the register under Section 7.6.

Amazon Web Services EMEA SARL

1. 38 Avenue John F. Kennedy, L-1855 Luxembourg; infrastructure affiliates and onward sub-processors are listed in the register under Section 7.6.
2. Transactional and notification email delivery through Amazon Simple Email Service (Amazon SES)
3. Europe (Frankfurt), Germany (eu-central-1)
4. No Chapter V transfer for processing in Frankfurt itself. Non-EEA access or onward transfers are governed by the accepted AWS Data Processing Addendum, including its Standard Contractual Clauses where applicable.

Decodo (UAB “Data troops”)

1. Švitrigailos str. 34, Vilnius, Lithuania
2. On-demand Web Scraping API used for webpage extraction (including the webpage fallback path) and certain YouTube playlist, video metadata, and transcript retrieval flows; receives requested URLs including path/query information, necessary retrieval parameters, and fetched source content
3. Lithuania (EU); request routing may involve infrastructure or requested public sources in other countries depending on the target and service configuration
4. Not applicable for processing in Lithuania; Standard Contractual Clauses or another lawful Chapter V safeguard apply where required for onward transfers
5. Processing of retrieved content is governed by the accepted Decodo Data Processing Agreement.
6. eDoer-appointed source-retrieval sub-processor under Article 28, limited to the approved source-extraction or import request; no authorization to reuse Controller content for independent model training. Public source operators' own processing is governed separately by their terms.

Whereby AS

1. Gate 1 no. 107, 6700 Måløy, Norway; privacy contact: legal@whereby.com
2. Whereby Embedded video rooms and room administration, including participant display names, eDoer user identifiers, room details, and connection metadata. Recording is disabled.
3. Account data is stored in Ireland (EU). Live media uses Whereby's default regional routing through its global infrastructure; eDoer does not use an EU/EEA-only routing restriction. Usage data may be processed in Ireland and the United States.
4. No Chapter V transfer for EEA processing itself. Whereby's Privacy Policy provides for Standard Contractual Clauses for US transfers.
5. No audio/video recordings are stored through eDoer's Whereby configuration. Account and room data are kept until account or room deletion, subject to applicable legal requirements; other service records follow Whereby's published privacy terms.
6. Under the standard Whereby DPA, Whereby acts as a processor for the covered account and room administration. Its standard terms classify live-media transmission and related traffic/usage processing as Whereby's controller activity, governed separately by its Privacy Policy. This Annex covers Whereby only to the extent it processes Controller data as a sub-processor.