Preamble

(1) This Data Processing Agreement ("Agreement") became effective between the Parties upon confirmation by the Controller during account registration.

(2) The subject matter of the agreement is the rights and obligations of the parties in accordance with the respective contract or the GTC (as of August 1st, 2024) (hereinafter: "main contract"). Part of the execution of the Main Contract is the processing of personal data of the Controller by the Processor within the meaning of the General Data Protection Regulation ("GDPR").

(3) To fulfill the requirements of the GDPR, in particular Art. 28 para. 3 GDPR, the parties have concluded the following agreement.

1. Object/Scope and Duration of the Assignment

1.1 As part of the provision of the services to be performed in accordance with the main contract, the processor shall gain access to the personal data of the controller (hereinafter referred to as "client data"). It may only process this data on behalf of and in accordance with the instructions of the controller.

1.2 The type, scope and purpose of the processing of client data by the processor and the categories of data subjects affected by this processing are specified in Annex 1.

1.3 The processor is prohibited from handling client data beyond the processing described in Annex 1.

1.4 The processing of the client data generally takes place in a member state of the European Union ("EU") or another state party to the Agreement on the European Economic Area ("EEA"). Any relocation of the processing of the client data to a country outside the EU/EEA will only take place after prior notification to the controller and only if the special requirements of Art. 44 to 49 GDPR are met.

1.5 The provisions of this Agreement shall apply to all activities that are related to the Main Contract and in which the Processor and its employees come into contact with the Client Data.

1.6 The duration of the processing corresponds to the term of the main contract. The possibility of termination without notice for good cause remains unaffected by this.

2. Powers of the Controller to Issue Instructions

2.1 The processor processes the client data only within the scope of the assignment and exclusively on behalf of and in accordance with the instructions of the controller. In this respect, the controller has the sole right to issue instructions on the type and scope of processing activities (hereinafter also referred to as "right to issue instructions"). If the processor is obliged by the law of the European Union or the Member States to which it is subject to carry out further processing, it shall inform the controller of these legal requirements prior to processing.

2.2 Instructions are generally issued by the controller in writing (e-mail is sufficient); verbal instructions must be confirmed in writing by the controller. The controller may inform the processor of the persons authorized to give and receive instructions by e-mail.

2.3 If the processor is of the opinion that an instruction from the controller violates data protection regulations, it must inform the controller of this. The processor shall be entitled to suspend the implementation of the instruction in question until the controller confirms or amends it.

3. Technical and Organizational Measures

3.1 When processing the client data, the processor must establish security in accordance with Art. 28 para. 3 lit. c, 32 GDPR, in particular in conjunction with Art. 5 para. 1, para. 2 GDPR. Overall, the measures to be taken are data security measures and measures to ensure a level of protection appropriate to the risk with regard to the confidentiality, integrity, availability and resilience of the systems. The state of the art, the implementation costs and the nature, scope and purposes of the processing as well as the varying likelihood and severity of the risk to the rights and freedoms of natural persons within the meaning of Art. 32 para. 1 GDPR must be taken into account. The specific technical and organizational measures implemented by the processor are set out in Annex 2.

3.2 The technical and organizational measures are subject to technical progress and further development. In this respect, the processor is permitted to implement alternative adequate measures. In doing so, the security level of the established measures shall not be compromised.

3.3 At the request of the Controller, the Processor shall demonstrate to the Controller compliance with the technical and organizational measures specified in Annex 2 by providing appropriate evidence.

4. Information and Support Obligations of the Processor

4.1 In the event of disruptions, suspected data protection violations within the meaning of Art. 33 GDPR or violations of contractual obligations of the processor in the processing of the client data by the processor, by persons employed by the processor within the scope of the order or by third parties, the processor shall inform the controller immediately, but at the latest within 24 hours, in writing or electronically. In doing so, the processor shall provide the controller with at least the information specified in Art. 33 (3) GDPR.

4.2 In the case of Section 4.1, the Processor shall support the Controller to the extent reasonable in the fulfillment of its relevant clarification, remedial and information measures, in particular those pursuant to Art. 34 GDPR, and shall provide the Controller with the necessary information without delay. If this places a disproportionate burden on the Processor's business operations, the controller shall bear the costs of the necessary measures taken by the processor.

4.3 The controller and the processor shall cooperate with the data protection supervisory authority in the performance of their tasks upon request.

4.4 Audits of the processor by the data protection supervisory authority shall be notified by the processor to the controller without undue delay after the processor becomes aware of the intended conduct of such audit, insofar as processing operations under this agreement are concerned.

4.5 The processor shall support the controller in the preparation of a data protection impact assessment in accordance with Art. 35 GDPR and any prior consultation with the supervisory authority in accordance with Art. 36 GDPR where necessary. The controller shall bear the costs of this support.

5. Other Obligations of the Processor

5.1 The processor is obliged to comply with the statutory provisions on data protection and not to disclose the information obtained from the controller's area to unauthorized third parties or expose it to their access. Documents and data must be secured against unauthorized access, taking into account the state of the art.

5.2 The processor shall ensure that confidentiality is maintained in accordance with Art. 28 para. 3 sentence 2 lit. b, 29, 32 para. 4 GDPR. It shall ensure that only employees who are bound to confidentiality and who have previously been familiarized with the data protection provisions relevant to them are deployed when handling Customer Data. The Processor and any person subordinate to the Processor who has access to personal data may only process this data in accordance with the Controller's instructions, including the powers granted in this Agreement, unless they are legally obliged to do so by Union law or the law of the Member States.

5.3 The processor confirms that it has appointed a data protection officer, insofar as there is a legal obligation to do so. The contact details of the data protection officer are:

Wolfgang Thanner

https://www.securiserve.de/securiserve/ Tel.: +49(0) 176-104 174 88 Fax: +49(0) 8801-9139160 kontakt[at]securiserve.de

5.4 The data controller must be informed immediately in writing of any change in the person of the data protection officer.

6. Subcontracted Processing

6.1 Sub-processing within the meaning of this provision shall be understood to be those services that are directly related to the provision of the main service. This does not include ancillary services that the processor uses, e.g. as telecommunications services, postal/transport services, maintenance and user service or the disposal of data carriers as well as other measures to ensure the confidentiality, availability, integrity and resilience of the hardware and software of data processing systems.

6.2 The controller approves the sub-processors named in Annex 3.

6.3 The change of existing sub-processors or the commissioning of new sub-processors is only permitted (i) if the processor notifies the controller of such a change or such a new commissioning in writing or in text form at least 30 days before the start of the sub-processing and (ii) if the controller does not object to the planned change or the planned commissioning by this time.

6.4 If the sub-processor provides the agreed service outside the EU/EEA, Section 1.4 of this Data Processing Agreement shall apply accordingly.

7. Control Rights of the Controller

7.1 The Processor shall ensure that the Controller can satisfy itself of the Processor's compliance with its obligations under this Agreement and Art. 28 GDPR. The Processor undertakes to provide the Controller with the information and evidence necessary for the performance of the checks upon request within a reasonable period of time and, in particular, to provide evidence of the implementation of the technical and organizational measures.

7.2 In the event of justified doubts about the processor's compliance with data protection requirements, the controller shall have the right, in consultation with the processor, to carry out on-site audits itself or have them carried out by auditors to be appointed in individual cases. These inspections must be announced with reasonable advance notice so as not to disproportionately disrupt the processor's business operations.

7.3 If such a review identifies circumstances that require changes to the process flow in order to avoid them in the future, the controller shall inform the processor of the necessary procedural changes without delay.

7.4 Proof of such measures, which do not only concern the specific order, can also be provided by compliance with approved rules of conduct in accordance with Art. 40 GDPR, certification in accordance with an approved certification procedure in accordance with Art. 42 GDPR, current certificates, reports or report extracts from independent bodies (e.g. auditors, internal audit, data protection officer, IT security department, data protection auditors, quality auditors) or suitable certification through IT security or data protection audits (e.g. in accordance with BSI basic protection).

8. Rights of the Data Subjects

8.1 The Processor shall support the Controller with appropriate technical and organizational measures to the extent possible in fulfilling the Controller's obligations under Art. 12 to 22 and Art. 32 to 36 GDPR. It shall provide the controller with the requested information about client data without delay, but at the latest within seven (7) working days, unless the controller itself has the relevant information.

8.2 The processor may not rectify, erase or restrict the processing of data processed on behalf of the controller without authorization, but only in accordance with documented instructions from the controller. If a data subject contacts the processor directly in this regard, the processor shall immediately forward this request to the controller and await the controller's instructions. The processor will not actively contact the data subject without corresponding individual instructions.

9. Deletion and Return of Personal Data

9.1 Copies or duplicates of the client data are not created without the knowledge of the controller. Excluded from this are backup copies, insofar as they are necessary to ensure proper data processing, as well as data required to comply with statutory retention obligations.

9.2 After completion of the contractually agreed work or earlier at the request of the Controller - at the latest upon termination of the main contract - the Processor shall hand over to the Controller all documents, processing and usage results and data files that have come into its possession in connection with the contractual relationship or, with the prior consent of the Controller, destroy them in accordance with data protection regulations, unless there is an obligation to store this personal data under Union law or the law of the Member States. In this case, the Processor shall immediately inform the Controller of such obligations. The provisions set out in this Section 9.2 shall apply equally to test and scrap material. The log of the deletion must be presented upon request.

9.3 Documentation that serves as proof of proper data processing in accordance with the contract must be retained by the processor beyond the end of the contract in accordance with the respective retention periods. The Processor may, for its own exoneration, hand these over to the Controller upon termination of the Agreement.

9.4 The processor is obliged to treat the data it has become aware of in connection with the main contract confidentially, even after the end of the main contract.

10. Liability

The liability of the parties is based on the main contract.

11. Final Provisions

11.1 The parties agree that the defense of the right of retention by the Processor within the meaning of Section 273 BGB with regard to the data to be processed and the associated data carriers is excluded.

11.2 If the Customer Data at the Processor is jeopardized by seizure or confiscation, by insolvency or composition proceedings or by other events or measures of third parties, the Processor shall inform the Controller without undue delay, unless it is prohibited from doing so by court or official order. In this context, the processor shall immediately inform all competent bodies that the controller has exclusive decision-making authority over the data.

11.3 Amendments and supplements to this agreement must be made in writing. This also applies to the waiver of this formal requirement.

11.4 In case of doubt, the provisions of this agreement shall take precedence over the provisions of the main contract. Should individual provisions of this agreement prove to be invalid or unenforceable in whole or in part or become invalid or unenforceable as a result of changes in legislation after the conclusion of the contract, this shall not affect the validity of the remaining provisions. The invalid or unenforceable provision shall be replaced by a valid and enforceable provision that comes as close as possible to the meaning and purpose of the invalid provision.

11.5 This agreement is subject to German law. The exclusive place of jurisdiction is Frankfurt am Main.

Note - This agreement is concluded electronically together with the GTC when registering an account.

Annex 1 - Type, Scope, Purpose and Order Processing

This document lists all data processed by Omnifact according to type, scope, purpose and external order processing. The document serves as an appendix to our agreement on commissioned data processing (DPA). All service providers named here are listed in detail in the DPA.

Processing of Personal Data

Annex 2 to the DPA - Persons authorized to issue and receive instructions

Omnifact GmbH, Hansaallee 154, 60320 Frankfurt, Germany

The following person(s) is/are authorized to issue instructions to the Controller with regard to the data processing covered by this Data Processing Agreement:

Name:

Position:

Availability within the company:

The following person(s) at the Processor is/are authorized to receive instructions regarding the data processing subject to this Data Processing Agreement:

Name: Patrick Helmig, Florian Reifschneider

Position: CEO / CTO (both managing directors)

Availability within the company: patrick@omnifact.ai / florian@omnifact.ai

Annex 3 - Technical and Organizational Measures

1. General Information

Data protection and IT security are a central component of our daily work at Omnifact GmbH. We continuously supplement and optimize our measures for IT security and the protection of your data. This document represents a current excerpt of the measures with which we protect personal data.

The scope of this document relates to the processing of personal and other customer data. Omnifact operates an Information Security Management System (ISMS) according to ISO/IEC 27001:2022, which has been certified since April 14, 2026. The certificate and further evidence can be accessed at https://trust.omnifact.ai.

2. Catalog of Technical and Organizational Measures

2.1 Access Control

All customer data on the Omnifact platform is processed in Microsoft Azure, Region Germany West Central (Frankfurt). A detailed description of the physical security measures in Azure data centers can be found here: https://learn.microsoft.com/en-us/azure/security/fundamentals/physical-security

When processing support requests and preparing quotations, the names and e-mail addresses of contact persons in your company - no data from the Omnifact platform - are processed in Google Workspace. A description of Google's physical security measures can be found here: https://cloud.google.com/docs/security/physical-to-logical-space

Our office at Hansaallee 154, 60320 Frankfurt am Main, is located in a multi-tenant office building. The building is locked outside business hours; access is via physical keys with documented key allocation. No productive customer data is processed or stored on office equipment - only development and test systems.

2.2 Access Control

2.2.1 Physical Access Control

See section Access Control - access to systems on which customer data is processed is the sole responsibility of Microsoft Azure or Google Workspace.

2.2.2 Authentication Methods

• Central identity management via Microsoft Entra ID for Azure and Google Workspace as identity providers for internal tools.
• Multi-factor authentication (MFA) is mandatory for all central systems:
  • Microsoft Azure / Entra ID (mandatory)
  • Google Workspace (2SV enforced organization-wide)
  • GitLab (2FA enforced)
  • 1Password (Authenticator App + Security Key)
  • Cloudflare (MFA enabled)
• Password manager requirement: All employees use 1Password; strong password policy with minimum length of 16 characters and complexity requirements.
• Private/public key authentication for code changes (Git/GitLab).
• Secure credential management for CI/CD and cloud deployments: Secrets in Azure Key Vault, integration in Pulumi-IaC and GitLab CI.
• Customer authentication: SAML 2.0 including Azure AD / Microsoft Entra ID; automatic session locking on inactivity.

2.2.3 Management of User Accounts

• User accounts are managed centrally (Entra ID, Google Workspace).
• Single Sign-On (SSO) is used if supported by the respective service.
• Documented onboarding and offboarding process; access is deactivated within 24 hours or at the latest on the next working day upon offboarding.
• Inventory of all accesses; at least annual review of authorizations.
• Logging of administrative activities in Entra ID, Google Workspace, GitLab and Azure.

2.3 Access Control

2.3.1 Authorization Concepts

• Least Privilege Principle - Users only receive the authorizations necessary for their role.
• Developers have no access to production data.
• Privileged Access Management on production resources is via Azure PIM (Privileged Identity Management) - no standing administrator rights, time-limited activation (max. 1 hour) with documented justification.
• Dedicated administrator accounts; the break-glass account is monitored (Sev-1 alarm on every login).
• Administrators are documented; changes are logged.
• Changes to code exclusively according to the dual-control principle via GitLab Merge Requests with Branch Protection.
• Regular review of authorizations (at least annually).
• Within the Omnifact platform:
  • Role-based authorizations (Platform: User/Admin; Spaces: User/Admin, optionally Knowledge Base Manager)
  • Scoping of authorizations to the organization (client separation, see Separation Requirement)

2.3.2 Database Access

• Application access via a dedicated service account with minimal rights.
• Human access to productive databases exclusively via Microsoft Entra Authentication - each accessing person authenticates with their individual Azure AD identity.
• Network access to the production environment exclusively via NetBird Mesh-VPN with Just-in-Time approval: Production access is requested via an automated Slack workflow, granted for a limited time, documented with justification and automatically revoked.

2.3.3 Further Measures

• Backups and replicas of customer data remain exclusively within the Azure infrastructure in the EU (Frankfurt).
• All services are configured so that the data is stored "encrypted at rest" (AES-256). This applies to PostgreSQL, Blob Storage and all other persistent Azure services.
• Security and configuration monitoring via Microsoft Defender for Cloud across all four Azure subscriptions.

2.4 Transfer Control

2.4.1 Transmission

• Data transmission is fundamentally encrypted (HTTPS/TLS) - both between client and platform and between internal services.
• Unless deactivated by the customer, all prompts and files are cleansed of personal data by our privacy filter prior to transmission to the LLM provider (placeholder replacement).
  • Exception: Information and behavioral instructions to the LLM stored by the user in the profile; the affected fields are marked transparently.
• Users can actively unmask masked fields if required for the use case.
• Non-public services are secured within the cloud infrastructure via Network Security Groups (NSGs) and Private Endpoints.
• Publicly accessible endpoints are protected by Cloudflare (Web Application Firewall and DDoS protection).

2.4.2 Data Carrier

• All notebooks and desktops have activated hard disk encryption.
• Mobile Device Management (MDM) and endpoint protection (anti-malware) are active on all end devices.
• Inventory of all end devices via MDM.

2.5 Input Control

2.5.1 Documentation of the Input

• Data cannot be created, modified or deleted without authentication and authorization.
• Operations within the Omnifact platform are clearly assigned to users.
• Audit logging of administrative activities (user status changes, resource deletions) is implemented; the system can be expanded for further events. Logs are retained for at least 90 days, transmitted and stored encrypted, and are protected against modification during the retention period (append-only).
• Time synchronization: All systems use UTC for consistent timestamps across log sources.
• Monitoring: Azure Application Insights with ML-based anomaly detection, Azure Monitor Networks, Defender for Cloud.

2.6 Order Control

2.6.1 Provider Selection

• Providers are checked prior to commissioning as part of our documented vendor management process:
  • Fulfillment of data protection requirements (GDPR, third-country guarantees if applicable)
  • Existence of an ISMS (preferably according to ISO 27001)
  • Security posture, certifications, references
• Special feature LLM providers:
  • We strive to provide LLM providers promptly and broadly.
  • If offered by the provider, we conclude a DPA with this provider.
  • If this is not possible, the circumstance is documented transparently as an annex to our DPA with our customers.
  • Customers can independently activate or deactivate LLM providers for their organization and adapt the available services to their needs.
• Provider changes are communicated to our customers in good time.
• DPAs with all GDPR-relevant providers have been concluded.

2.6.2 Omnifact as a Contractor

• Provision of a DPA with current information on the GDPR-compliant procedure.
• Auditing by customers possible by arrangement.
• ISMS according to ISO/IEC 27001:2022 implemented and certified (certificate and further evidence: https://trust.omnifact.ai).
• External Data Protection Officer (Wolfgang Thanner) established; reporting processes for data protection violations documented.

2.7 Availability Control

2.7.1 Physical Availability

See section Access Control. The production database is operated as an Azure PostgreSQL Flexible Server with Zone-Redundant High Availability.

2.7.2 Data Backup

• The retention of our customers' data can be set by the administrator of an organization.
• Database backups:
  • Point-in-Time Recovery (PITR): daily snapshots + continuous WAL archiving, 30 days retention, Microsoft-managed storage accounts (isolated from customer access). RPO approx. 5 minutes, RTO approx. 2 hours.
  • Weekly pg_dump backups in Azure Backup Vault as a fallback for scenarios in which Azure PITR is not available.
• Blob Storage: Soft delete with 14-day retention.
• Backups are encrypted (in-transit and at-rest, AES-256) and stored utilizing zone/geo-redundancy of the cloud provider.
• Restoration from backups is tested at least annually in the development environment; results are documented (Data Recovery Test Log).
• Deployments and configurations are rolled out automatically via Infrastructure-as-Code (Pulumi) and GitLab CI/CD to staging and production systems, with mandatory approval before production. This minimizes human error and enables short-term recovery in other Azure availability zones.
• Deletion:
  • The deletion of chats, users and organizations is technically implemented and documented.
  • The deletion of users including their profiles can be initiated by the administrator of an organization.
  • The deletion of an organization can be requested via our support (support@omnifact.ai); deletion takes place within 30 days unless statutory retention obligations prevent this.
  • Backups are automatically deleted after the documented retention period expires.

2.7.3 Business Continuity

Omnifact has a documented Business Continuity and Disaster Recovery Policy as well as an annually tested disaster recovery procedure. The strategy includes:

• Operation in multiple Azure availability zones (Zone-Redundant HA for the production database).
• Automation of infrastructure (Pulumi IaC) and deployments allows short-term recovery in other availability zones.
• Regular recovery tests for backups (annually, last on 2026-02-26 for PITR and pg_dump).
• Documented incident response and disruption response procedure with clear roles (Tech Leadership, external DPO).
• System availability SLA: 99.9%.

2.8 Separation Requirement

2.8.1 Separation by Type of Data and Processing

• We distinguish between customer data and internal data. Customer data is fundamentally treated like personal data.
• Exception: User prompts are transmitted to the selected LLM provider after applying our privacy filter. Users can actively unmask masked fields (e.g. if the knowledge of an LLM about a specific company is to be used).

2.8.2 Client Separation

• Our data model is divided according to clients (organizations).
• User roles and authorizations apply exclusively within a client and do not extend to other organizations.

2.8.3 Separation of the Systems

• Production, staging and development environments are completely separate (separate Azure Resource Groups: omnifact-prod, omnifact-dev, omnifact-test).
• No shared data between the environments.
• We do not test with customer data - only synthetic or anonymized data is used.
• User accounts for the individual environments are separate.
• Developers have no access to production systems.

2.9 Continuous Improvement

• Security scanning: SAST (Semgrep), dependency scanning (Gemnasium / SBOM), IaC scanning (KICS) run in every GitLab CI/CD pipeline; cloud posture management via Microsoft Defender for Cloud.
• Penetration tests: Annual external penetration tests with documented remediation.
• Training: Regular security awareness trainings for all employees.
• Management review: At least annual ISMS management reviews.
• Internal audits: Defined internal audit program; external surveillance audits as part of the ISO-27001 certification.

2.10 Miscellaneous

Privacy Filter The Omnifact Privacy Filter is based on an ensemble approach that combines two complementary detection methods:

• A custom-trained Small Language Model (SLM) for Named Entity Recognition (NER), which contextually detects personal entities such as names of persons and companies, addresses and free-text identifiers.
• Rule-based RegEx heuristics that reliably capture structured patterns such as email addresses, phone numbers, IBAN numbers and other standardized identifiers.

The combination of both methods achieves a high detection rate with a simultaneously low false-positive rate. Detected entities are replaced by placeholder tokens before the prompt or document is transmitted to the LLM provider. After receiving the LLM response, the placeholders are automatically translated back into the original values, so that users receive a complete and readable answer.

The entire filtering process takes place exclusively within the Omnifact platform on infrastructure in Germany (Azure Region Germany West Central, Frankfurt). Sensitive data never leaves the controlled environment before masking is complete.

Annex 4 - Approved Sub-processors

This document lists all sub-processors required by Omnifact for processing.

1. General Processing

1.2 LLM Providers (Beyond General Processing)

Important notes:

• We also enable the use of providers, such as Groq, that do not yet offer GDPR-compliant DPAs and do not operate their service via a legal entity in the EEA. Please therefore check whether the providers you have activated in your organization meet your own data protection requirements.
• If you use your own API key via the Omnifact platform, the regulations agreed with the LLM provider apply to processing by the LLM provider. In this case, please ensure that a DPA is available if this is necessary for your purposes.