Data Processing Agreement / Auftragsverarbeitungsvertrag (AVV)

Version 2026-09-27

This agreement is between Emfara, Inc. and the organisation that holds the DGM One account (the Controller). It is an annex to the Terms of Service at /legal/terms, and it is accepted electronically at sign-up — see Signatures at the end of this document.

Where Emfara cannot perform an obligation today, the clause says so rather than promising it. §§ 4.3, 7.4 and 9.6, and the right-hand column of Anlage 2, are written to be read rather than skipped.

Basis of this text

The clause structure follows the European Commission's standard contractual clauses between controllers and processors under Art. 28(7) GDPR, Commission Implementing Decision (EU) 2021/915 of 4 June 2021. It is adapted from that instrument rather than adopted verbatim, so Emfara does not claim the "pre-approved" status that verbatim adoption confers. The Commission text is reproduced and adapted under the Commission's reuse policy (Decision 2011/833/EU), with the source acknowledged here.

Decision (EU) 2021/915 is a different instrument from Decision (EU) 2021/914, the international transfer clauses, and a US processor serving an EU controller needs both: 2021/915 (or an equivalent AVV) for Art. 28, and 2021/914 Module 2 for Chapter V. Anlage 4 covers the second.

A Controller whose own purchasing terms require its template to govern may propose it; this document is Emfara's statement of what it can commit to, and it is also available as the operative agreement where the Controller has no template of its own.

Companion documents

The documents below support this agreement. Those marked on request are provided to the Controller, and to its data-protection officer or auditor, on request to privacy@emfara.com.

Parties

Auftragsverarbeiter / Processor

Emfara, Inc. Emfara, Inc. · 251 Little Falls Drive, Wilmington, New Castle, DE 19808, USA Delaware · file no. 10577634 Operating the service under the name DGM One (app.dgmone.com, www.dgmone.com)

Contact for this agreement, and privacy contact: Eric Muller — privacy@emfara.com Deputy privacy contact: Frank Alonso — privacy@emfara.com Security-incident contact: security@emfara.com (monitored; see § 8.1 and Anlage 5)

Deliberate wording. Emfara has assessed the Art. 37 GDPR obligation to designate a

Datenschutzbeauftragter and concluded it does not apply at the current scale.

The person named above is Emfara's internal privacy owner and is not a designated

DPO. The title is withheld deliberately, not by oversight: designating a DPO attaches

obligations under Arts. 37–39 that do not otherwise apply, and Emfara does not claim a

status it has not assumed. The assessment is revisited if the processing changes.

Art. 27 GDPR representative in the UnionNot appointed — not required on current facts. Emfara does not target the EU market and does not identify or monitor individual EU users: for offices recorded as being in the EU, EEA, UK or Switzerland, product analytics is organisation-level only and attaches no user id, no email address and no personal profile (see § 16). The position is revisited before any per-person analytics for EU users, and before any EU-targeted marketing.

Verantwortlicher / Controller

The Controller is the customer: the legal entity named in the DGM One account, at the registered address recorded in that account, as entered by the person who accepted this agreement at sign-up. Emfara does not restate those details here — the account record and the acceptance row described under Signatures are the authoritative source, and a transcribed copy in the contract text could drift from them.

The Controller's own privacy contact or data protection officer, where it has one, is the address the Controller gives under Anlage 5. Until it names one, Emfara addresses notices under this agreement to the account's administrator users.

Together the Parties; each a Party.

Preamble

The Controller has engaged the Processor to provide the DGM One dangerous-goods compliance service under the agreement identified in § 1.1 (the Main Agreement). In providing that service the Processor processes personal data on behalf of the Controller within the meaning of Art. 4(8) and Art. 28 GDPR.

This agreement (the AVV) sets out the Parties' obligations under Art. 28(3) GDPR. It forms an annex to the Main Agreement and has no independent existence without it.

Roles. For the processing described in Anlage 1, the Controller is the controller and the Processor is the processor. For a limited set of processing described in § 16, the Processor acts as a controller in its own right; that processing is outside this AVV and is disclosed here so that the Controller can assess it.

§ 1 Subject matter, duration and scope (Gegenstand und Dauer)

1.1 The subject matter of the processing is the provision of the DGM One service under the Main Agreement, which is the Terms of Service at /legal/terms in the version the Controller accepted at sign-up, together with the subscription the Controller holds. Where the Parties have signed a separate written agreement for the service, that agreement is the Main Agreement instead. The Controller's acceptance record (see Signatures) identifies the version of each document it accepted and the moment it did so, and serves as the reference for this AVV.

1.2 This AVV takes effect on the date the Controller accepts it, recorded as accepted_at in the acceptance record described under Signatures, and remains in force for as long as the Processor processes personal data on behalf of the Controller. Obligations that by their nature survive — in particular § 4 (confidentiality), § 9 (deletion and return), § 10 (audit) and § 14 (liability) — survive termination.

1.3 The nature and purpose of the processing, the types of personal data and the categories of data subjects are set out in Anlage 1.

1.4 Order of precedence. In the event of conflict, the following order applies: (1) mandatory law; (2) the standard contractual clauses referenced in Anlage 4; (3) this AVV; (4) the Main Agreement. If the Parties execute the Controller's own AVV template, that template supersedes this document in its entirety and this draft has no contractual effect.

1.5 Language. This agreement is concluded in English, and the English text governs. A German translation is provided on request for convenience; in the event of a discrepancy the English text prevails unless the Parties agree otherwise in text form.

§ 2 Description of the processing

The description required by Art. 28(3) first sentence — subject matter, duration, nature and purpose, type of personal data, categories of data subjects — is set out in Anlage 1 and forms an integral part of this AVV.

The Processor maintains the description and notifies the Controller of material changes before they take effect.

§ 3 Documented instructions — Art. 28(3)(a)

3.1 The Processor processes personal data only on documented instructions from the Controller, including with regard to transfers of personal data to a third country or an international organisation, unless required to do so by Union or Member State law to which the Processor is subject. In that case the Processor informs the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

Deliberate omission. This clause does not contain the broad "unless required by law

or a binding order of a governmental body" carve-out common in US vendor DPAs. The EDPB

(Opinion 22/2024) considers it unlikely that such wording, on its own, satisfies

Art. 28(3)(a) read with Chapter V. Emfara does not copy it into its own paper. See § 11.5

for how Emfara handles a third-country authority request.

3.2 Standing instructions. The Main Agreement together with this AVV and Anlage 1 constitute the Controller's initial documented instructions. Ordinary use of the service by the Controller's authorised users — creating and storing checklists, uploading photographs and documents, capturing signatures, generating PDFs, sending service notifications, exporting reports — is an instruction within that scope.

3.3 Form of further instructions. Further instructions are given in text form (email is sufficient) by a person named in Anlage 5, to the Processor recipient named in Anlage 5. The Processor documents instructions received.

3.4 Unlawful instructions. The Processor immediately informs the Controller if, in its opinion, an instruction infringes the GDPR or other Union or Member State data-protection law. The Processor may suspend performance of that instruction until the Controller confirms or amends it.

3.5 Processor-determined means — disclosed honestly. Certain configuration choices are currently made by the Processor and not by the Controller:

The Controller authorises these means by signing, on the basis of the description in Anlage 1 and Anlage 3, and may object under § 6.4. What exists today, and what does not: every AI-assisted feature is already behind a per-tenant switch enforced server-side, so the Controller can prevent AI processing for its organisation and the election is recorded against its tenant. Analytics is not behind a tenant switch — it is governed by each user's own consent choice (§ 16). The Processor will not describe an organisation-wide analytics switch as available until it is.

3.6 The Processor does not use the personal data processed under this AVV for its own purposes, does not combine it with data from other controllers, and does not use it to train, fine-tune or evaluate any machine-learning model. The audit confirmed no model is trained or fine-tuned anywhere in the product, and the AI sub-processor is contractually bound not to train on the data (see Anlage 3, row 5).

§ 4 Confidentiality — Art. 28(3)(b)

4.1 The Processor ensures that persons authorised to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. That obligation survives the end of their engagement.

4.2 Access to production personal data is limited to personnel who need it to perform the Main Agreement. The technical controls behind this — a cross-tenant superadmin role that cannot be self-granted, a separate requireSuperadmin() gate on every administrative action, and an audit record written against the target tenant whenever an administrator impersonates into it — are described in Anlage 2.

4.3 ⚠ Limitation the Controller should know.Written confidentiality undertakings are not yet in place with every individual and contractor holding production access. The technical gating in § 4.2 is real, but technical gating is an Art. 32 measure, not the Art. 28(3)(b) commitment, and the Processor does not present one as the other.

4.4 The same undertaking is required of any contractor or automated development agent with access to production systems or production data.

§ 5 Security of processing — Art. 28(3)(c), Art. 32

5.1 The Processor implements appropriate technical and organisational measures to ensure a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing, as required by Art. 32(1) GDPR.

5.2 The measures in force are set out in Anlage 2 and in the separate TOM annex it references. Anlage 2 states plainly which measures exist today and which do not.5.3 The Processor may update the measures over time provided the level of protection is not reduced. Material reductions require prior notice to the Controller.

5.4 The Processor reviews the effectiveness of the measures at least annually and after any material change to the service.

§ 6 Sub-processors — Art. 28(2), Art. 28(4)

6.1 General authorisation. The Controller grants the Processor general written authorisation to engage the sub-processors listed in Anlage 3, on the terms of this § 6. The list in Anlage 3 is approved at signature and is kept up to date.

6.2 Flow-down and liability. The Processor imposes on each sub-processor, by written contract, data-protection obligations the same as those in this AVV, in particular sufficient guarantees of appropriate technical and organisational measures. Where a sub-processor fails to fulfil those obligations, the Processor remains fully liable to the Controller for the performance of that sub-processor's obligations (Art. 28(4)).

6.3 Change notice. The Processor notifies the Controller in text form of any intended addition or replacement of a sub-processor at least 30 days before that sub-processor begins processing the Controller's personal data. The notice names the entity, its country of establishment, the processing entrusted to it, and the transfer mechanism where the processing is outside the EEA.

Honest disclosure on the 30-day term. Emfara's own upstream vendors do not all give

Emfara 30 days. PostHog, for example, gives **14 days' notice with a 7-day objection

window** (verified in its DPA, 2026-09-02). Emfara can nevertheless meet a 30-day

commitment to the Controller for its own sub-processor changes, but it cannot always

pass through 30 days' warning of a vendor's onward sub-processor change. Counsel should

decide how to word this so it is accurate rather than aspirational.

6.4 Objection. The Controller may object to a change on reasonable data-protection grounds within the notice period. If the Parties cannot agree a remedy, the Controller may terminate the affected part of the Main Agreement without penalty, effective at the date the new sub-processor would begin processing.

6.5 Information on the chain. On request, the Processor makes available to the Controller the information necessary to identify all of its sub-processors and, so far as it holds it, their onward sub-processors, together with a description of the processing entrusted to each (EDPB Opinion 22/2024, paras 27–29). Two onward chains are still outstanding — those of the AI sub-processor and of the database provider — and the Processor will provide them when obtained rather than assert a chain it has not seen. See Anlage 3.

6.6 A change of hosting region, database region or object-storage jurisdiction is treated as a sub-processor change for the purposes of this § 6.

§ 7 Assistance with data subject rights — Art. 28(3)(e)

7.1 Taking into account the nature of the processing, the Processor assists the Controller by appropriate technical and organisational measures, insofar as this is possible, in fulfilling the Controller's obligation to respond to requests for exercising the data subject's rights under Chapter III GDPR (Arts. 15–22).

7.2 Forwarding. If a data subject contacts the Processor directly in respect of personal data processed under this AVV, the Processor does not respond on the merits. It forwards the request to the Controller without undue delay and in any event within 3 business days, and informs the data subject that the Controller is responsible.

7.3 Response time. On the Controller's request, the Processor provides the assistance needed for the Controller to meet its own one-month deadline under Art. 12(3) GDPR. The Processor acknowledges a request within 2 business days and provides the substantive assistance within 10 business days, unless the request is disproportionate in scope, in which case the Parties agree a schedule.

7.4 ⚠ Limitations the Controller should read before accepting this agreement.

The tooling that would make § 7.3 routine does not exist today. Emfara states the position rather than promising a capability it does not have:

• No export. There is no "give me everything you hold about this person" function

anywhere in the product — no endpoint, no admin screen, no script. The five export routes that exist are keyed by tenant, report or shipment, not by data subject.

• No working erasure. The single administrative "Delete user" control deletes only

authentication rows. For any person who has ever performed work in the product, the database's foreign keys abort the deletion. Photographs, generated PDFs and uploaded certificates are never deleted from object storage by any code path.

• No rectification path for a joined user's email address.
• No restriction-of-processing mechanism (Art. 18).
• The Controller cannot read the full audit log. The tenant-facing activity feed

deliberately withholds the details, IP address, user agent and actor email fields — which are precisely the fields Art. 15 obliges disclosure of.

Until that tooling is built, assistance would be delivered by an Emfara operator running queries by hand against the production database. That is neither auditable nor scalable, and the Processor says so here rather than promising a capability it does not have.

A written data-subject-request procedure is maintained and is available on request. It is a procedure, not a capability: it cannot produce an export that has not been built.

7.5 Charges. Assistance under this § 7 is provided at no charge for requests of reasonable volume and frequency. Where a request is disproportionate in scope, the Parties agree a schedule and, if the work is substantial, a reasonable charge, before the work starts.

§ 8 Assistance with Arts. 32–36 — Art. 28(3)(f)

8.1 Personal data breach — Art. 33(2)

The Processor notifies the Controller of a personal data breach affecting personal data processed under this AVV without undue delay after becoming aware of it, and in any event within 48 hours.

The notification includes, so far as known at the time and supplemented as more becomes known: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point for further information.

The Processor does not notify a supervisory authority or data subjects on the Controller's behalf unless the Controller instructs it to in writing.

⚠ Detection limits the Processor must disclose. As at 2026-09-02:

- Error monitoring is integrated but not presently sending from the browser. The

product is wired for it, with a filter that strips authorisation headers, cookies, API

keys and request bodies, but no client-side configuration key ships in the production

bundle, so browser-side faults are not reported to it today.

- The incident-response procedure is written but is not yet exercised. A severity

scheme and a notification path exist on paper and a monitored security address

(security@emfara.com) is in place; there is no 24/7 on-call rota behind it, and no

drill has been run. The procedure is available to the Controller on request.

- The audit log records writes but not reads. After a read-only compromise, Emfara

could not tell the Controller what was accessed.

- Cross-tenant probes and authentication failures are deliberately not audited, so the

canonical attack signature leaves no application-level trace.

8.2 Security — Art. 32

The Processor assists the Controller in ensuring compliance with Art. 32 by maintaining and making available Anlage 2 and the TOM annex, and by answering the Controller's security questionnaires within a reasonable period.

8.3 Data protection impact assessment — Arts. 35, 36

The Processor assists the Controller, on request and taking into account the information available to it, with a data protection impact assessment and with prior consultation of a supervisory authority.

The Processor will produce a DPIA support pack — processing description, data flows, technical and organisational measures, and the Processor's own risk analysis — that the Controller can incorporate into its own assessment.

The Processor draws the Controller's attention to four aspects of the processing that a German controller will need to assess and that Emfara flags unprompted:

1. Photographs taken in warehouse and loading environments, which incidentally capture

staff.

1. Handwritten signature images stored together with the signer's IP address and user

agent, insert-only, currently with no retention sweep at all.

1. AI-based extraction of document contents by a US sub-processor.
2. Employee-performance data. The system records which named inspector accepted or

rejected which shipment, with timestamps; per-call AI usage is recorded against named employees; and an AI feature that generates per-employee retraining assessments exists in the codebase. In Germany this engages § 26 BDSG and, under § 87(1) Nr. 6 BetrVG, the works council's co-determination right — because the test is whether the technology is objectively capable of monitoring performance, not whether that is its purpose. This is normally the longest item on the calendar. Start the works-council conversation first, not last. The Processor will support the Controller's works-council process with the documentation the council needs.

8.4 Art. 36 prior consultation

If the Controller is required to consult a supervisory authority, the Processor provides the information within its control that the authority requires.

§ 9 Deletion or return at the end of processing — Art. 28(3)(g)

9.1 Controller's choice. At the end of the provision of services relating to processing, the Processor shall, at the Controller's choice, delete or return all personal data processed on behalf of the Controller, and delete existing copies, unless Union or Member State law requires storage of the personal data. The Controller communicates its choice within 30 days of the end of the service; absent a choice, the Processor deletes.

9.2 Return format. Where the Controller elects return, the Processor provides a complete export of the Controller's personal data in a structured, commonly used and machine-readable format — one file per source data set, plus a manifest of the object-storage files (photos, generated PDFs, uploaded certificates) with retrieval links — within 30 days of the request.

9.3 Deletion. Where the Controller elects deletion, or after a return has been confirmed complete, the Processor deletes the personal data from its production systems and from object storage within 30 days, and confirms the deletion in writing, listing the data sets and record counts deleted.

9.4 Backups and sub-processors. Personal data present in backup copies is deleted in accordance with the ordinary backup rotation and is not restored except for disaster recovery; the Processor confirms the date by which backup copies containing the data will have expired. The Processor instructs its sub-processors to delete accordingly and, where the sub-processor's own terms govern, states the applicable period (for example, the AI sub-processor's contract provides for deletion within 30 days of termination).

9.5 Statutory retention. Where Union or Member State law requires the Processor to retain personal data, the Processor informs the Controller of the provision relied on, retains only what that provision requires, restricts processing of that data to the purpose of the retention, and deletes it when the period expires.

A correction the Processor makes against itself. Emfara's current retention policy is

grounded solely in a US rule — 49 CFR 172.201(e), two years from the date the

shipping paper is provided to the initial carrier. That is not a basis under Art. 17(3)(b),

which requires a legal obligation under Union or Member State law. It also expresses a

minimum with no maximum, which is the opposite shape of what Art. 5(1)(e) requires.

The EU-side bases — the ICAO Technical Instructions as incorporated by Commission

Regulation (EU) No 965/2012, and § 257 HGB / § 147 AO for commercially relevant documents

9.6 ⚠ The most important limitation in this document — please read it.Neither branch of § 9 can be performed today by an automated routine. This is stated here, in the clause itself, because papering over it would convert a compliance gap into a misrepresentation. Deletion and return are carried out by Emfara on the Controller's request, by hand, and the limitations of that are:

• Deletion fails on database constraints. The tenant-deletion routine deletes exactly two

rows — the billing record and the tenant record. Seven foreign keys declared ON DELETE RESTRICT reference the tenant, so for any customer that ever created a shipment, a NOTOC, a CTPAT assessment, a TSA attestation or an integration token, the deletion throws an error and does nothing. For a customer that used none of those, the deletion succeeds and leaves everything behind: submissions, photographs, users, password hashes and audit rows carry a plain-text tenant column with no foreign key, so they survive as orphaned but fully intact records.

• Object storage is never purged. There is exactly one deletion call site against object

storage in the entire codebase, and it serves a 90-day job-artefact sweep. Checklist photographs, generated PDFs and uploaded training certificates have no deletion path at all. Photographs orphan during ordinary use, not only on an erasure request.

• There is no export. No tenant-scoped export routine exists, so the "return" branch has

no implementation either.

• Device copies are out of reach. Personal data, including signature images and

photographs, persists in browser storage on inspectors' devices with no time limit and no remote purge.

The Processor accepts the obligation in §§ 9.1–9.5 as drafted, performs it on request today by manual means, and is building the automated capability. Until that exists, a Controller that requires a certified, evidenced purge at the end of the contract should say so in writing, and Emfara will agree a documented procedure and a completion date with it.

Emfara's deletion concept (Löschkonzept) is available on request. It marks the same gaps as this clause; read it alongside § 9, not instead of it.

§ 10 Audit and inspection — Art. 28(3)(h)

10.1 The Processor makes available to the Controller all information necessary to demonstrate compliance with the obligations laid down in Art. 28 GDPR, and allows for and contributes to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller.

10.2 Documentation first. The Processor satisfies § 10.1 in the first instance by providing: this AVV and its Anlagen; the TOM annex; the sub-processor list; the record of processing under Art. 30(2); the transfer impact assessments; and a completed security questionnaire.

10.3 On-site and remote audits. Beyond documentation, the Controller may audit once per calendar year, and additionally after a personal data breach affecting the Controller's data or where a supervisory authority requires it, on 30 days' written notice, during business hours, without unreasonable disruption, and subject to confidentiality undertakings by the auditor. The Controller may mandate a third-party auditor; the Processor may object to a specific auditor only on reasonable grounds, in particular where the auditor is a competitor. The final decision on the auditor rests with the Controller (EDPB Guidelines 07/2020).

10.4 Scope. An audit may cover the functioning of the systems used, the security measures, how retention requirements are met, data location, transfers, who has access to data, the recipients, and the sub-processors used.

10.5 Certifications. An audit obligation may be satisfied by a current third-party certification or attestation report where one covers the relevant scope.

⚠ Honest statement of what exists. As at 2026-09-02 Emfara holds **no ISO 27001

certification, no SOC 2 report, no TISAX assessment, and no independent penetration

test has ever been performed**. There is no security whitepaper and no trust page. The

Art. 30(2) record does not exist. So § 10.5 offers the Controller nothing today, and

§ 10.2 can only be met in part.

What does exist is real engineering evidence — see Anlage 2 — and the Processor will

10.6 Costs. Each Party bears its own costs. The Processor may charge for its reasonable time on audits beyond the first per year.

§ 11 International transfers — Chapter V

11.1 Personal data processed under this AVV is processed in the United States. The specific locations, recipients and safeguards are set out in Anlage 4.

11.2 The Controller instructs the Processor to transfer personal data to the United States for the purposes described in Anlage 1, subject to the safeguards in Anlage 4.

11.3 The transfer is made on the basis of the standard contractual clauses adopted by Commission Implementing Decision (EU) 2021/914 — Module 2 (controller to processor) between the Controller as data exporter and the Processor as data importer, and Module 3 (processor to processor) for onward transfers to sub-processors.

11.4 How the clauses are incorporated. The Module 2 clauses are incorporated into this AVV by reference and take effect when the Controller accepts it, with their annexes populated as follows: Annex I.A (parties) by the Parties section and the acceptance record under Signatures; Annex I.B (description of the transfer) by Anlage 1; Annex I.C (competent supervisory authority) by the authority competent for the Controller as exporter; Annex II (technical and organisational measures) by Anlage 2; and Annex III (sub-processors) by Anlage 3. Where the Controller requires a separately signed copy of the clauses, Emfara provides and signs one on request to privacy@emfara.com.

Emfara's own upstream position is on the same footing: all nine vendors have DPAs in force by incorporation carrying the 2021 clauses — no signature is outstanding from any of them, and the evidence is archived and available on request.

11.5 Government access requests. If the Processor receives a legally binding request from a public authority for personal data processed under this AVV, it will, unless legally prohibited: notify the Controller without undue delay; challenge the request where there are reasonable grounds to consider it unlawful; and disclose the minimum amount of data permissible on a reasonable interpretation of the request. Where notification is prohibited, the Processor will use best efforts to obtain a waiver and will document its efforts.

11.6 Transfer impact assessment. The Processor maintains a transfer impact assessment for each of the nine recipients, as required of the exporter by Clause 14(d) of the 2021 SCCs. The facts in each are established and verified; the legal analysis is being completed with counsel, taking the AI recipient first. They are made available to the Controller, to its data protection officer and to a supervisory authority on request, in the state they are in.

11.7 The Processor informs the Controller if it becomes unable to comply with the safeguards in Anlage 4, and the Controller may then suspend the transfer or terminate the affected part of the Main Agreement.

§ 12 Record of processing — Art. 30(2)

The Processor maintains a record of all categories of processing activities carried out on behalf of the Controller and makes it available to the Controller and, on request, to a supervisory authority.

The record (Verzeichnis von Verarbeitungstätigkeiten) is maintained and is provided on request to privacy@emfara.com. The exemption in Art. 30(5) is not relied on, because the processing is regular rather than occasional.

§ 13 Controller's obligations

13.1 The Controller is responsible for the lawfulness of the processing it instructs, for the legal basis under Art. 6 (and Art. 9 where applicable), and for providing the information required by Arts. 13 and 14 to its data subjects.

13.2 The Controller is responsible for the lawfulness of the personal data it or its users upload to the service, including personal data appearing in shipping documents relating to third parties (shippers, consignees, signatories, emergency contacts).

13.3 The Controller ensures that instructions under § 3 are given only by the persons named in Anlage 5 and keeps that list current.

13.4 The Controller confirms that it has satisfied any works-council or employee- representation requirements applicable to its deployment of the service.

§ 14 Liability, term and termination

14.1 Liability is governed by Art. 82 GDPR and by the liability provisions of the Main Agreement, save that liability may not be limited below the level required by mandatory law.

14.2 This AVV terminates automatically on termination of the Main Agreement, subject to § 1.2 and § 9.

14.3 The Controller may terminate this AVV and the affected part of the Main Agreement where the Processor is in material breach of this AVV and has not remedied it within a reasonable period, or under § 6.4 or § 11.7.

§ 15 Miscellaneous

15.1 Governing law and venue. This AVV is governed by the law that governs the Main Agreement — the law of the State of Delaware, USA, under the Terms of Service — save that nothing in this clause deprives a data subject or a supervisory authority of any right or forum available to them under the GDPR or under the law of the Controller's own country, and the standard contractual clauses referenced in Anlage 4 are governed as those clauses themselves provide. A Controller that requires German law and a German venue for this AVV may agree it in writing; Emfara does not treat that as an unusual request.

15.2 Written form. Amendments require text form. This includes any amendment to this clause.

15.3 Severability. If a provision is or becomes invalid, the remainder is unaffected and the Parties will replace the invalid provision with one that comes closest to its economic purpose.

15.4 Anlagen. Anlagen 1–5 form an integral part of this AVV.

§ 16 Processing where Emfara is a controller, not a processor — disclosure

This section is not part of the Art. 28 arrangement. It is disclosed because a Controller is entitled to know every function of the service that sends personal data outward, including data about its own employees, and because "calling home" clauses in enterprise purchasing terms make it a contractual question.

For the following, Emfara determines the purposes and means and therefore acts as a controller in its own right:

Why the analytics row is worded that way. Attaching product usage to a named

individual, for Emfara's own purposes, is what would turn product analytics into

behavioural monitoring of an identifiable person — and for a person in the EU that is the

Art. 3(2)(b) trigger. Emfara therefore does not identify individuals in offices recorded

as being in the EU, EEA, UK or Switzerland; the decision follows **the country recorded

for the office**, not where the person happens to be at the time, and an office with no

country recorded is treated as if it were in the EU. Tenant-level attribution carries the

product signal Emfara acts on without attaching it to a named person.

What is not offered. Analytics and error monitoring are not behind a per-tenant

feature flag. They are governed by the visitor's own analytics choice, which is the

control that actually applies. A Controller that requires analytics to be suppressed for

its whole organisation regardless of each user's choice should raise it in writing; that

is not a switch that exists in the product today.

Anlage 1 — Description of the processing (Verarbeitungsbeschreibung)

Art. 28(3) first sentence; also serves as Annex I.B to the 2021/914 clauses.

1. Subject matter

Provision of the DGM One software-as-a-service platform for dangerous-goods air-freight compliance: acceptance checklists, photographic evidence, document extraction and validation, generated compliance PDFs, certification tracking and the associated audit record.

2. Duration

For the term of the Main Agreement, plus the deletion or return period in § 9, plus any statutory retention period identified under § 9.5.

3. Nature of the processing

Collection, recording, organisation, structuring, storage, adaptation, retrieval, consultation, use, disclosure by transmission to the sub-processors in Anlage 3, alignment, restriction, and erasure or destruction (subject to § 9.6).

4. Purpose of the processing

Solely the provision of the service to the Controller under the Main Agreement. The purpose is dangerous-goods compliance checking and documentation: performing and recording dangerous-goods acceptance checks, evidencing compliance, extracting data from shipping documents, generating compliance documentation, notifying users, tracking training certification, providing support, and maintaining the security and integrity of the service.

5. Categories of data subjects

6. Types of personal data

7. Special categories of personal data (Art. 9)

None is processed. The audit examined the four candidates and recorded a reasoned verdict:

• Handwritten signatures — personal data, not Art. 9 as currently implemented. Only the

composited raster image is stored. No stroke timing, velocity or pressure series is captured, and no signature is ever compared to verify identity, so the Art. 4(14) "specific technical processing … which allow or confirm unique identification" test is not met. If a future feature ever stores the dynamic stroke data or performs signature matching, this becomes Art. 9 data and needs an Art. 9(2) condition. Anlage 1 must be updated in the same change.

• Photographs — personal data, not Art. 9. No facial processing is performed anywhere.
• Deactivation status and reason — not Art. 9, but employment data with a free-text field.
• AI retraining assessments — not Art. 9, but profiling of a natural person's performance

at work under Art. 4(4).

No health, genetic, racial or ethnic, political, religious, trade-union, sex-life or sexual-orientation data is processed. Dangerous-goods classification data concerns substances, not people.

Instruction. No special-category data is intended to be processed. The Controller instructs its users not to upload special-category data into free-text fields, notes or photographs, and Emfara has no technical means of preventing it if they do.

8. Frequency

Continuous, for the term of the Main Agreement.

9. Retention

Governed by § 9 and by the Controller's instructions. The current state is disclosed in § 9.5 and § 9.6: a US-law minimum with no maximum, and several data sets with no automated deletion path — deletion is carried out by Emfara on request. Emfara's deletion concept (Löschkonzept) records the same position and is available on request.

Retention rules that are implemented and verified: notification records are deleted 30 days after dismissal; document-extraction artefacts expire after 24 hours; three document-verification workflows delete their object-storage artefacts on a 90-day sweep. An audit-log retention sweep exists in code but is switched off in production.

10. Processing on the data subject's own device

The mobile application stores checklist data, photographs and signature images in browser storage on the user's device to support offline operation. This is disclosed to the data subject in the cookie and similar-technologies policy at /legal/cookies § 6.

Signing out clears that data from the device — draft checklists, photograph previews and records that have already synchronised — on every sign-out control.

Records that have not yet synchronised are deliberately kept, including across sign-out. They are the only copy of that inspection, and deleting them would destroy a field inspector's work. While parked they are locked to the inspector who created them.

Those unsynchronised records have no automatic expiry, and there is no remote purge. If the inspector never signs in on that device again, the record — including shipper and consignee details, the signature image and the photographs — remains in that device's storage until the device's data is cleared. Confidentiality at rest on the device depends on the device's own encryption and on the Controller's device management; Emfara applies no encryption of its own at that layer. Both points belong in the Controller's own DPIA.

Anlage 2 — Technical and organisational measures (TOM), Art. 32

These are the measures Emfara actually operates, stated at the level of detail a German reviewer expects — ein AVV ohne konkrete TOM ist unvollständig. A pointer to Art. 32 alone does not satisfy a supervisory authority, so each control category below says what is in place and what is not. The gaps are in the same table as the controls on purpose: a TOM annex that lists only strengths is marketing, not evidence. A fuller annex is maintained by Emfara and is provided to the Controller, its data protection officer or its auditor on request.

Anlage 3 — Sub-processors (Unterauftragsverarbeiter)

Approved on acceptance of this agreement, under the general authorisation in § 6.1.

All nine data-processing agreements below are already in force by incorporation into the terms Emfara accepted with each vendor. No vendor signature is outstanding and none is required. Archived copies, with the date each was fetched, are held by Emfara and are provided to the Controller on request.

Notes the Controller should read

• Transfers rest on the 2021 EU standard contractual clauses, together with the **UK

International Data Transfer Addendum and the Swiss adaptations, in every case — not on the EU–US Data Privacy Framework. The reason is specific: Supabase and Anthropic are not certified under the Framework, verified directly against the official register rather than taken from vendor marketing, and between them they hold every durable record and the most sensitive document contents in the system. Cloudflare and Sentry are active participants; Emfara states that for those two only, and relies on the clauses regardless, so that its position does not change if the Framework's status does. See Anlage 4**.

• The country column says United States for every row. Several of these vendors offer EU

regions. Emfara does not use them today. Stating a vendor's capability as if it were Emfara's current state would be misleading, so this annex states current state only.

• Change notice: 30 days, with the caveat in § 6.3.
• Onward sub-processors. Each recipient's own sub-processor list is obtained and provided

to the Controller on request. For Supabase and Anthropic the onward list is still outstanding; Emfara will provide it when obtained rather than assert a chain it has not seen.

• Zero Data Retention has not been agreed with the AI recipient. It would convert 30-day

US retention of shipper and consignee data into transient processing, and Emfara's call pattern is eligible for it. It is listed as a planned supplementary measure in Anlage 4, not as an existing control.

Per-tenant disablement. The AI modules — declaration extraction, document intelligence, SDS validation, battery verification, the assistants — are each behind a per-tenant feature flag enforced server-side: with the flag off the endpoint returns 404 and no data reaches the AI sub-processor for that tenant.

One exception, stated so the Controller does not rely on a control that is not there. The optical-character-recognition helper that reads a photographed declaration (/api/ocr/extract) is not behind a tenant flag. When a low-confidence field needs resolving it sends that photograph to the AI sub-processor, gated only on an API key being configured for the service as a whole. A Controller who wants no images reaching the AI sub-processor at all cannot achieve that today by switching its own flags off; it must ask Emfara, in writing to privacy@emfara.com, to disable the capability for its tenant. Emfara will confirm in writing when it is done. Bringing this route behind the same per-tenant flag as the modules is on the roadmap. Analytics and error monitoring are not behind a tenant flag. Analytics is governed by each visitor's own consent choice (§ 16); error monitoring is Emfara's own legitimate-interest processing. A Controller that needs either suppressed organisation-wide should raise it in writing rather than assume a switch exists.

Anlage 4 — Transfers and safeguards (Drittlandtransfer)

1. Where the data is

All personal data processed under this AVV is in the United States. Compute in Virginia, the database in us-east-1, object storage in a non-EU-jurisdiction bucket, AI processing in the US, email and payments in the US. No compute runs in the EU, including all sixteen scheduled jobs. This is stated first because concealing it is the fastest way to fail a German review.

2. Transfer mechanism — the 2021 SCCs, not the Data Privacy Framework

The transfer story rests on the SCCs, deliberately — not on the EU–US Data Privacy Framework. The reason is specific and was verified directly against the official DPF register on 2026-09-02, not taken from vendor marketing:

Supabase and Anthropic are NOT LISTED on the DPF register. Between them they hold

every durable record and the most sensitive document contents in the system.

Secondary sources claiming otherwise are wrong; the register was queried directly.

Cloudflare and Sentry are active participants in the Framework. That does not change the analysis, because the two recipients that are not certified are the two that matter most, and because a safeguard that applies to only part of the chain is not a safeguard for the chain. Emfara relies on the clauses for every recipient, including the certified ones.

An SCC-primary posture has a second advantage: it survives the appeal pending before the Court of Justice in Case C-703/25 P with no rework. The General Court dismissed the Latombe challenge on 2025-09-03 and the DPF is currently valid, but an appeal is pending and no hearing date has been announced.

3. Transfer impact assessment — Clause 14(d)

Signing a vendor's DPA does not discharge the exporter's assessment obligation, and a supervisory authority may require its production. Emfara maintains an assessment for each of the nine recipients. The facts in each are established and verified; the legal analysis is being completed with counsel, and the AI recipient is taken first because it is the hardest and the most consequential. They are provided to the Controller, to its data protection officer or to a supervisory authority on request, in the state they are in.

4. Supplementary measures — in place and planned

In place and verified:

• GPS and device metadata stripped from every photograph in the browser before upload.
• IP addresses hashed rather than stored raw in three places.
• A PII firewall on the integration surface.
• Contractual no-training and 30-day deletion with the AI recipient; Irish governing law;

that vendor holds ISO 27001, ISO 42001 and SOC 2 Type II.

• TLS in transit; a strict content-security policy and two-year HSTS.

Planned, and honestly not yet done:

• Redact before sending to the AI recipient. Crop or mask the personal-data boxes

client-side — an EDPB-recognised supplementary measure, and there is working precedent in this codebase for exactly this crop technique on another feature.

• Zero Data Retention on the AI account.
• EU regions for hosting, database, storage, analytics and error monitoring.

5. The AI leg has no configuration-only EU fix

The AI vendor's first-party API offers no EU data residency, and no setting in Emfara's account can create one. Emfara states this unprompted rather than letting a reviewer discover it. Three real routes exist, and Emfara will discuss any of them with a Controller for which EU processing of document contents is a requirement: redact the personal-data boxes before sending; run the same models in an EU region through a major cloud provider's managed service; or route extraction through an EU-hosted platform. None is in place today.

6. Sequencing warning for the Controller

Three region choices are irreversible once made — the database region, the object-storage jurisdiction, and the error-monitoring organisation region. Each requires a new resource and a data migration. Every EU customer onboarded onto the current US resources makes that migration larger. If EU residency matters to the Controller, it should be decided before onboarding, not after.

7. Review

Reassessed on any vendor DPA change, sub-processor change or hosting-region change, on any development in Case C-703/25 P, and at least annually.

Anlage 5 — Authorised instruction-givers (Weisungsberechtigte Personen)

Instructions under § 3 are given and received only by the persons identified below. Each Party keeps its own entry current and notifies the other in text form of any change.

Controller — authorised to issue instructions

Because this agreement is concluded by self-service acceptance rather than by negotiation, the Controller is not asked to fill in a table here. Instead:

• The Controller's **authorised instruction-givers are the users holding the administrator

role in its DGM One account**, as recorded in the account at the time the instruction is given. The account record is the list, and the Controller keeps it current by managing its own administrators.

• The Controller may narrow or extend that list, or name specific individuals with their

roles, email addresses and telephone numbers, by notice in text form to privacy@emfara.com. Emfara records the notice against the account and acts on it from the date of receipt.

• The Controller's data protection officer or privacy contact, where it has one, is

likewise notified to privacy@emfara.com. Emfara addresses notices under this agreement to that contact once given, and to the account's administrator users until then.

Processor — authorised to receive instructions

Processor's privacy contact (internal privacy owner — not a designated DPO, see Parties): Eric Muller — privacy@emfara.com

Processor's security-incident contact, for § 8.1: security@emfara.com — a monitored address rather than an individual's inbox, so that a notification does not depend on one person being available.

Processor's Art. 27 representative in the Union: Not appointed — not required on current facts. Emfara does not target the EU market and does not identify or monitor individual EU users: for offices recorded as being in the EU, EEA, UK or Switzerland, product analytics is organisation-level only and attaches no user id, email address or personal profile (§ 16). This is revisited before any per-person analytics for EU users, or any EU-targeted marketing.

Signatures

This agreement is concluded electronically. Art. 28(9) GDPR requires the contract to be in writing, including in electronic form, and does not require a handwritten signature. Emfara therefore does not ask the Controller to sign and return a copy, and there is nothing to countersign.

How execution is evidenced. When the Controller's representative ticks the acceptance box at sign-up, Emfara writes one row to its legal_acceptances table recording tenant_id, document, version, accepted_by_name, accepted_by_email, ip_hash, user_agent and accepted_at. That row is the evidence that this agreement was executed, by whom, on which version of the text, and at what moment in UTC. There is no separate signed copy, and none is needed. The Controller may request a copy of its own acceptance rows at any time from privacy@emfara.com.

Versioning. The version recorded is the version string shown at the top of this document. If the substance of this agreement changes, that string changes with it, and earlier acceptances continue to point at the text that was actually accepted — so a Controller's acceptance row always identifies the exact wording it agreed to. Previous versions are retained and are provided on request.

Document control

Previous versions of this agreement are retained. The version each Controller accepted is recorded against its account and is provided on request.