Data Processing Agreement

according to Article 28 of Regulation (EU) 2016/679 (General Data Protection Regulation, "GDPR")

Version 1.0 · valid from 14 November 2026

between

the Customer named in the Order Form ("Controller")

and

bitova GmbH, Samariterstraße 5, 50968 Köln, Germany ("Processor")

1. Subject and duration

1.1 The Processor processes personal data on behalf of the Controller in providing the Maridex service under the Agreement (Order Form, Terms of Service, Service Description and Service Level Agreement). The subject matter, nature and purpose of the processing, the types of personal data and the categories of data subjects are set out in Appendix 1.

1.2 This Data Processing Agreement ("DPA") applies for as long as the Processor processes personal data on behalf of the Controller. It does not end before the deletion under section 11 is complete.

1.3 Terms used in this DPA have the meaning given in the GDPR.

2. Instructions

2.1 The Processor processes personal data only on documented instructions of the Controller, including with regard to transfers to a third country, unless EU or member-state law requires otherwise; in that case the Processor informs the Controller of that legal requirement before processing, unless that law prohibits such information (Article 28 (3) (a) GDPR).

2.2 The Agreement and the Controller's use and configuration of the Service constitute the Controller's complete initial instructions. Examples of configuration are: which documents are stored in which library, which workstations are approved, whether import by email is used, and which chats are deleted. Further instructions are given in text form to security@maridex.app. The Processor documents them.

2.3 The Processor informs the Controller without undue delay if, in its opinion, an instruction infringes the GDPR or other data protection law. It may suspend carrying out the instruction until the Controller confirms or changes it.

2.4 The Processor does not use the personal data for its own purposes, in particular not to train AI models.

3. Confidentiality

The Processor ensures that the persons authorised to process the personal data have committed themselves to confidentiality, or are under an appropriate statutory obligation of confidentiality (Article 28 (3) (b) GDPR). The obligation continues after their work ends. Only persons who need access to perform the Agreement have access.

4. Security of processing

4.1 The Processor takes all measures required under Article 32 GDPR. They are described in Appendix 2 (technical and organisational measures, "TOMs").

4.2 The TOMs are subject to technical progress. The Processor may replace them with adequate alternative measures, provided the level of security does not fall below that of the measures described. Material changes are documented and notified to the Controller in text form.

5. Sub-processors

5.1 The Controller grants the Processor general authorisation to engage other processors ("Sub-processors"). The Sub-processors engaged when this DPA is concluded are listed in Appendix 3 and are deemed approved.

5.2 The Processor informs the Controller in text form at least 30 days in advance of any intended addition or replacement of a Sub-processor. The notice states the name, location, task and, for third countries, the transfer mechanism. The current list is also published at https://docs.maridex.app/security/subprocessors/.

5.3 The Controller may object to the change within 30 days of the notice for justified reasons relating to data protection. Justified reasons include in particular:

1. processing in a third country without appropriate safeguards;
2. inadequate technical and organisational measures;
3. a Sub-processor that is a direct competitor of the Controller.

If the Processor cannot remedy the objection by reasonable measures, the Controller may terminate the Agreement and this DPA without notice, at the latest when the change takes effect. Until then, the Processor does not use the new Sub-processor for the Controller's data.

5.4 The Processor imposes on each Sub-processor, by contract, essentially the same data protection obligations as in this DPA, in particular sufficient guarantees for appropriate technical and organisational measures (Article 28 (4) GDPR). On request, it provides the relevant contract terms; it may redact business secrets that are not relevant to data protection.

5.5 The Processor remains fully liable to the Controller for the performance of the Sub-processors' obligations.

5.6 Services that the Processor uses as ancillary services are not sub-processing within the meaning of this section, provided the provider has no access to personal data of the Controller. Examples are telecommunications, source code hosting and payment processing. The Processor's IT systems for invoicing are such services.

6. Transfers to third countries

6.1 The Processor processes the Controller's data in the EU or EEA. A transfer to a country outside the EU or EEA takes place only if the requirements of Articles 44 to 49 GDPR are met, in particular through:

1. an adequacy decision of the European Commission, including the EU–US Data Privacy Framework for certified recipients; or
2. the standard contractual clauses of the European Commission (Implementing Decision (EU) 2021/914), together with any necessary supplementary measures.

6.2 Appendix 3 states for each Sub-processor whether data may be transferred to a third country, and on what basis.

6.3 If the Controller is established outside the EU or EEA, the parties also conclude the standard contractual clauses, module 4 (processor to controller), for the provision of the data to the Controller. bitova provides them on request.

7. Rights of data subjects

7.1 Taking into account the nature of the processing, the Processor supports the Controller with appropriate technical and organisational measures in fulfilling requests of data subjects under Articles 12 to 23 GDPR (Article 28 (3) (e) GDPR). These include in particular requests for access, rectification, erasure, restriction and data portability.

7.2 The Service lets the Controller handle most requests itself. Its administrators can view, change and deactivate users, delete chats and export documents and the audit log. Where the Controller cannot do so itself, the Processor provides the support within 10 business days of the request.

7.3 If a data subject contacts the Processor directly, the Processor forwards the request to the Controller without undue delay and does not respond to it itself, unless the Controller instructs it to.

7.4 The audit log cannot be changed (section 2.2 no. 9 of the Service Description). Where a request for erasure or rectification concerns entries in the audit log, the Processor and the Controller agree on how to proceed. Possible measures are restricting the processing or adding a correcting entry.

8. Personal data breaches

8.1 Notification. The Processor notifies the Controller of any personal data breach affecting the Controller's data. It does so without undue delay, and at the latest within 24 hours after becoming aware of it. The notification goes by email to the security contact named in the Order Form, and additionally by phone if the breach is severe.

8.2 Content. As far as available, the notification contains the information under Article 33 (3) GDPR:

1. the nature of the breach, including, where possible, the categories and approximate number of data subjects and data records concerned;
2. the name and contact details of a contact person at the Processor;
3. the likely consequences of the breach;
4. the measures taken or proposed to address the breach and to mitigate its possible adverse effects.

Where not all information is available at once, the Processor provides it in stages without undue further delay. The first notification is not delayed for this reason.

8.3 Measures. The Processor takes the measures necessary without undue delay to secure the data, to mitigate possible adverse effects and to prevent repetition, and coordinates them with the Controller.

8.4 Support. The Processor supports the Controller in its obligations under Articles 33 and 34 GDPR, in particular with all information the Controller needs for its notification to the supervisory authority within 72 hours and for informing data subjects.

8.5 No notification on the Processor's own initiative. The Processor does not notify supervisory authorities or data subjects on behalf of the Controller without the Controller's instruction, unless it is itself legally obliged to do so.

8.6 Documentation. The Processor documents every personal data breach affecting the Controller's data, including the facts, the effects and the remedial measures taken, and makes the documentation available to the Controller.

8.7 Costs. Each party bears its own costs, unless the breach was caused by a breach of this DPA or of the GDPR by the other party.

9. Further support

Taking into account the nature of the processing and the information available to it, the Processor supports the Controller in complying with its obligations under Articles 32 to 36 GDPR (Article 28 (3) (f) GDPR). These are security of processing, data protection impact assessments and prior consultation of the supervisory authority. For this purpose, the Processor provides in particular the description of the processing (Appendix 1), the TOMs (Appendix 2) and the list of Sub-processors (Appendix 3).

10. Records and data protection officer

10.1 The Processor maintains a record of the processing activities it carries out on behalf of controllers (Article 30 (2) GDPR).

10.2 Contact for data protection at the Processor: security@maridex.app.

11. Deletion and return

11.1 After the end of the provision of the Service, the Processor deletes all personal data of the Controller, at the Controller's choice, or first returns it and then deletes it (Article 28 (3) (g) GDPR). It deletes existing copies as well, unless EU or member-state law requires the personal data to be stored.

11.2 Return and deletion follow section 11 of the Terms:

1. export of the documents with all revisions and metadata, and of the audit log, in a structured, machine-readable format;
2. deletion of the entire customer system, including the database, files and backups, within 30 days after the end of the retrieval period;
3. written confirmation of the deletion.

11.3 Local copies on the onboard workstations are under the Controller's control. They are removed when a workstation is disconnected in the dashboard or the application is uninstalled (section 11.6 of the Terms).

12. Audits

12.1 The Processor makes available to the Controller all information necessary to demonstrate compliance with Article 28 GDPR. It allows for and contributes to audits, including inspections, conducted by the Controller or by an auditor mandated by it (Article 28 (3) (h) GDPR).

12.2 Evidence is primarily provided through documentation. Examples are this DPA with its appendices, answers to security questionnaires, and the reports and certificates of the Sub-processors, such as the ISO/IEC 27001 certificates of the data centres.

12.3 In addition, the Controller may carry out an audit:

1. once per calendar year, and in addition after a personal data breach affecting its data or at the request of a supervisory authority;
2. with 30 days' notice in text form, during business hours and without disrupting operations;
3. by an auditor bound to professional secrecy who is not a competitor of the Processor.

The protection of other customers' data and of the Processor's business secrets must be safeguarded.

12.4 Each party bears its own costs of an audit. If an audit reveals a material breach of this DPA by the Processor, the Processor bears the reasonable costs of the audit.

13. Liability

Liability towards data subjects is governed by Article 82 GDPR. Between the parties, the liability provisions of the Agreement (section 12 of the Terms) apply, as far as legally permissible.

14. Final provisions

14.1 In case of conflict, this DPA takes precedence over the other contract documents as regards the processing of personal data.

14.2 Amendments to this DPA require text form. This DPA may also be concluded in an electronic format (Article 28 (9) GDPR).

14.3 This DPA is governed by German law. The place of jurisdiction follows section 20.4 of the Terms.

---

Appendix 1 – Description of the processing

1. Subject matter and purpose

Provision of the Maridex document system to the Controller (Service Description):

• storing, versioning, previewing and searching the Controller's documents;
• distributing them to the Controller's vessels;
• answering questions from the documents with the AI assistant;
• importing documents by email (if agreed);
• recording the audit log;
• support.

2. Nature of the processing

Collecting, recording, organising, structuring, storing, adapting (conversion for preview, text extraction, generating search indexes and vector embeddings), retrieving, using, disclosing by transmission (to the Controller's Users and workstations, and to the AI service), restricting and erasing.

3. Duration

For the term of the Agreement and until deletion under section 11.

4. Categories of data subjects

1. Users of the dashboard (the Controller's office staff and other persons authorised by it).
2. Crew members and other persons on board who use the onboard workstations.
3. Persons named in the Controller's documents, for example employees, crew members, contact persons of customers, suppliers, authorities, classification societies and surveyors.
4. Senders and recipients of emails forwarded to the import address (if import by email is used), and persons named in them.

5. Types of personal data

6. Special categories of personal data

The Service is not designed to process special categories of personal data (Article 9 GDPR) or data relating to criminal convictions (Article 10 GDPR). Documents that the Controller stores may nevertheless contain them. An example is medical fitness certificates of seafarers, which contain health data. In that case, the Controller is responsible for the lawfulness of the processing; the TOMs in Appendix 2 apply.

7. Place of processing

The Controller's system: in the data centre stated in the Order Form (by default Germany). Other locations: see Appendix 3.

---

Appendix 2 – Technical and organisational measures (Article 32 GDPR)

Status: 14 November 2026. These measures apply to every customer system.

1. Confidentiality

1.1 Physical access control

1. The servers run in data centres of Hetzner Online GmbH in Germany, certified according to ISO/IEC 27001:
   • electronic access control;
   • video surveillance;
   • security staff around the clock.
2. bitova has no physical access to the servers and does not keep Customer Data on its own premises.

1.2 System access control

1. Network:
   • a separate server and private network for each customer;
   • from the internet, only the encrypted web address (HTTPS) is reachable;
   • a firewall at the infrastructure provider permits administrative access (SSH) only from the fixed addresses of bitova's operations team.
2. Administrative access: only with personal SSH keys; password login is disabled.
3. Office users: sign in through the Controller's Microsoft Entra ID (single sign-on, with the Controller's multi-factor authentication policies).
4. Onboard workstations:
   • each workstation authenticates with its own Ed25519 key pair, created on the workstation and protected by the operating system;
   • it must be approved by an office user after comparing a pairing code;
   • it receives short-lived access tokens only;
   • it can be disconnected at any time.
5. Protection against attacks:
   • a web application firewall checks every request;
   • intrusion prevention blocks attacking addresses, including virtual patches for known vulnerabilities;
   • rate limits apply. The rules are updated automatically every day.

1.3 Data access control

1. Roles in the dashboard: viewer, editor, administrator.
2. Libraries limit the data per vessel:
   • each workstation only receives the Fleet library and its own vessel's library;
   • this is enforced in every database query and file request, and applies to the assistant on board as well.
3. Inside the system, each component can reach only the components it needs (separate internal networks).
4. Secrets (database passwords, keys) are stored encrypted and passed to services as protected secrets, not in configuration files.
5. Administrative access by bitova's staff is limited to the operations team and is needed for operation and support.

1.4 Separation control

1. One system per customer: own server, network, database, file storage, keys and web address.
2. Development and test systems use synthetic data only, never Customer Data.

1.5 Pseudonymisation

Not applicable to the purpose of the Service (managing documents). The audit log identifies users and workstations by internal identifiers.

2. Integrity

2.1 Transfer control

1. In transit:
   • all connections are encrypted with TLS 1.2 or newer;
   • unencrypted requests are redirected;
   • HTTP Strict Transport Security is enabled.
2. Files:
   • files are identified by their SHA-256 hash;
   • the hash is checked on upload, on transfer to the workstations, and on the workstation before use.
3. Email import:
   • the transmission from the email service to the customer system is signed with a separate key for each customer;
   • unsigned, expired or altered deliveries are rejected.

2.2 Input control

1. The audit log records sign-ins, uploads, publications, withdrawals, workstation approvals and disconnections, synchronisations, file exports on board and questions to the assistant.
2. The audit log is append-only:
   • changes and deletions are prevented at database level;
   • each entry contains the hash of the previous entry, and the chain can be verified.
3. Revisions of documents are never changed or deleted.

3. Availability and resilience

1. Backups of the database:
   • every night, encrypted, at a separate location;
   • kept 14 days, 8 weeks and 12 months;
   • integrity checked weekly.
2. Files: versioned storage at a separate provider, so earlier versions can be restored.
3. Virus scanning: every uploaded file and email attachment is scanned before it is stored; if scanning fails, the file is refused.
4. Monitoring:
   • automatic monitoring around the clock (services, certificates, backups, protection rules);
   • bitova's team is alerted.
5. Updates:
   • security updates of the operating system are installed automatically every day;
   • systems are scanned daily for known vulnerabilities, and findings are fixed with priority;
   • third-party components are kept up to date through an automated process.
6. Offline operation: the vessels keep a complete copy of their current documents, so reading on board continues even if the system is unavailable.

4. Procedures for regular testing, assessment and evaluation

1. Infrastructure as code: the configuration of every system is versioned and checked automatically before it is rolled out.
2. Automated tests for security-relevant functions run on every change, among them:
   • read-only enforcement on board;
   • workstation pairing and disconnection;
   • integrity of the audit chain;
   • limitation of the assistant to the documents.
3. Restore tests of the backups: before each customer goes live, and after every major change.
4. The TOMs are reviewed at least once a year and after every security incident.

5. Organisational measures

1. Staff and freelancers with access to Customer Data:
   • are committed to confidentiality and data protection;
   • are trained when they start and regularly afterwards.
2. Need-to-know: access is granted only as far as needed, and withdrawn without delay when no longer needed.
3. A documented procedure for handling security incidents and personal data breaches, including notification to the Controller within 24 hours (section 8 of the DPA).
4. Sub-processors are selected according to their data protection and security measures and bound by contract (section 5 of the DPA).
5. Deletion: the customer system is deleted completely when the Agreement ends (section 11 of the DPA). Logs are deleted automatically: web server logs after 14 days, application logs after 31 days.

---

Appendix 3 – Sub-processors

Status: 14 November 2026.

Not Sub-processors of bitova:

• Microsoft Entra ID: the Controller's own identity provider, used under the Controller's own contract with Microsoft.
• An Own AI Provider of the Controller (section 6.4 of the Terms): engaged by the Controller itself.