Privacy Notice — DGM One
Datenschutzhinweise nach Art. 13 und Art. 14 DSGVO
This notice explains what personal data we process when you use DGM One (app.dgmone.com), when your employer uses it, or when your name appears on a shipping document that someone processes through it. It also explains the choices and rights you have.
We have written it to be understood by an inspector, a procurement reviewer and a data protection officer alike. Where the honest answer is "not yet", we say so.
Last updated: 27 September 2026 · Version 2026-09-27Applies to: the DGM One web and offline application at app.dgmone.com, and the account, billing and support processes around it. Does not yet apply to: www.dgmone.com (our marketing website).
1. Who we are, and how to reach us
1.1 Controller (Verantwortlicher)
Emfara, Inc. Emfara, Inc., a Delaware corporation · 251 Little Falls Drive, Wilmington, New Castle, DE 19808, USA Delaware file no. 10577634 Eric Muller
Email for all data protection matters: privacy@emfara.com
1.2 Our privacy contact (Ansprechpartner für den Datenschutz)
Eric Muller privacy@emfara.com
*We have not appointed a Data Protection Officer / Datenschutzbeauftragter under Art. 37 GDPR.* We assessed this and concluded that no appointment is mandatory at our current scale: our core activity is not large-scale monitoring of data subjects, and we do not process special categories of data on a large scale. We have instead named an internal privacy owner (above) who is accountable for this notice and for handling your requests. If our processing grows or changes, we will reassess this.
1.3 EU representative (EU-Vertreter nach Art. 27 DSGVO)
None appointed — not required on our current facts. Emfara, Inc. is established in the United States. It does not target the EU market, and it does not identify or monitor individual users in the EU: for offices recorded as being in the EU, EEA, UK or Switzerland, product analytics is organisation-level only and attaches no user identifier, no email address and no personal profile (section 6.2).
We state the test we applied rather than only the conclusion, so that you can check it. We will appoint a representative before we enable per-person analytics for users in the EU, or market the service to the EU. Until then, please contact us directly at privacy@emfara.com, and note that our not having a representative does not reduce any of your rights under section 12 or your right to complain under section 13.
1.4 UK representative
None appointed, for the same reason and on the same test. Users in the United Kingdom are treated exactly as users in the EU for the purposes of section 6.2: no user identifier and no email address is sent.
2. Two different roles — please read this first
DGM One is business software sold to organisations. Depending on the data, we act in one of two different legal roles. This distinction decides who you should approach, and it is the first thing a data protection officer will ask about.
| We are a processor (Auftragsverarbeiter) | for everything your employer or contracting organisation puts into the product: your user account, the checklists you complete, the photos you take, your signature, the shipment and document records. Your employer decides why that data exists and how long it is kept. We only act on their documented instructions. |
| We are the controller (Verantwortlicher) | for a smaller set of processing that we decide on for our own purposes: billing, product analytics, error monitoring, security and abuse prevention, and marketing enquiries from our website. |
Where we are a processor, address your request to your employer or the organisation whose DGM One account you use. They are the controller. We will support them — Art. 28(3)(e) GDPR — and we will not act on your data without their instruction.
Where we are the controller, address your request to us, using the contact details in section 1.
Sections 4 and 5 say, for each purpose, which role we are in.
One point in that split deserves naming. Product analytics is processing we carry out for our own purposes, over our customers' employees. That makes us the controller for it, not a processor — which is why it is the one thing in this notice that asks for your consent rather than your employer's instruction, and why nothing analytics-related happens until you choose it. Section 6.2 describes exactly what is and is not collected.
3. Whose data we process, and where it comes from
We process personal data about four groups of people.
- Users of DGM One — inspectors, preparers, administrators and managers at our
customers. Data comes from you and from your employer when they create your account.
- People named in documents and shipments — shippers, consignees, signatories, the
emergency-response contact on a Notification to Captain, the captain who acknowledges it, named site or office leads. We usually receive this data from our customer, not from you. This notice is your Art. 14 information; see section 3.1.
- Prospects and visitors — people who request a demonstration at
app.dgmone.com/demo
or enquire about the product.
- Billing and account contacts — the person who signs your organisation up and pays.
3.1 If your name appeared on a document (Art. 14 GDPR)
If you are a shipper, consignee, signatory or emergency contact named on an air waybill, a Shipper's Declaration for Dangerous Goods, a safety data sheet, a permit or a Notification to Captain, your name — and often your business address, telephone number and handwritten signature — may be recorded in DGM One and read by our AI extraction system (section 7). We did not obtain that data from you. We obtained it from our customer, who obtained it from the shipping documentation for your consignment.
The categories we hold about you are listed in section 4. We do not have your contact details in a form that lets us write to you individually, and contacting every person named on every shipping document would involve disproportionate effort within the meaning of Art. 14(5)(b) GDPR. This public notice is how we provide that information instead.
4. What personal data we process
The list below reflects what the system actually stores, verified against the code on 2026-09-02.
4.1 Account and identity data
Full name; work email address (which is unique across the whole platform); password, as a cryptographic hash — never in readable form; profile image if you set one; role and permissions; the organisation and office you belong to; account status, including whether your account has been deactivated and the reason recorded for it.
4.2 Login and session data
IP address; browser and device identification string (user agent); session expiry; and, where an administrator with platform-wide rights has accessed the product on behalf of a user, a record of that access.
4.3 Checklist, inspection and shipment records
The core business record. Inspector name; place of inspection; inspection date; shipper and consignee names and, where they appear, their addresses; air waybill and shipment reference; origin and destination; your answers to each checklist item together with any free-text note you typed; your handwritten signature, captured as an image; the time you started and the time you signed, which together show how long the inspection took; and the reason recorded when a submission was rejected and redone.
Signature records are stored separately as well, together with the IP address and user agent of the device used to sign. These signature records are insert-only and are never modified or deleted by any part of the system.
4.4 Photographs and generated documents
Photographs taken during an inspection — the declaration form, packages, overpacks, damage evidence, acceptance photos, loading and seal captures. These frequently show paperwork bearing names, addresses and signatures, and may incidentally show staff. Also the PDF checklists we generate from your submission, which embed your name and your signature image, and any training certificates uploaded to the product, which typically carry the holder's name and signature.
Location and device metadata (EXIF, including GPS) are stripped from every photograph in your browser, before the image is uploaded to us. We never receive it.
4.5 Documents you upload for automated analysis
Shipper's Declarations, safety data sheets, UN 38.3 test reports, shipping papers and permits, as PDFs or images, and everything the AI system reads out of them. See section 7.
4.6 Training, certification and performance-adjacent data
Dangerous-goods training certificates: type, edition, issue and expiry dates, scope, and the certificate file itself. Reminder history, including whether you opened a reminder. Preparer profiles: role label, join date, status. Records of every AI suggestion you accepted or rejected, with your reasoning where you gave one, and every time you overrode an automated check, with your stated reason. Per-user AI usage records with timestamps, which taken together form an activity timeline for an identified employee.
For one optional feature that is switched off for every customer today, we generate AI-assisted training recommendations for a named individual based on their 90-day pass rate and most frequently failed checklist items. See section 8.
4.7 Contacts held in shipment and compliance records
Emergency-response contact name and telephone number; captain name and acknowledgment signature on a Notification to Captain; named office leads; permit holder name and the address the permit was granted to; free-text notes attached to shipments, watchlist entries and assessments; the original filenames of documents you upload, which routinely contain personal names.
4.8 Audit and security records
Every privileged action, recorded with the acting user, the organisation, the action, the object acted on, an IP address, a user agent and structured details which, on some paths, include an email address. This log is insert-only.
For anti-abuse purposes on sign-up and on our public API endpoints we store a cryptographic hash of the IP address, never the address itself.
4.9 Billing data
Company name, administrator name and email, seat count, plan, subscription and customer identifiers held at our payment provider, and the verbatim event payloads our payment provider sends us, which include billing name, email, address and tax identifiers. Card numbers never reach our systems. They are handled entirely by Stripe.
4.10 Enquiry and demonstration data
If you request a demonstration, we store your real name and your real email address as you typed them, a hashed IP address, which link or QR code you arrived from, and how many times you have returned, with first and last visit timestamps.
4.11 Product analytics data
Only if you have chosen "Allow analytics". Nothing described here is collected before that choice, and you can withdraw it at any time (section 6.2).
What is collected: your organisation identifier, the pages you visit, automatically captured interactions such as clicks and form submissions, a small set of named product events, and your IP address, from which our analytics provider derives an approximate location.
Whether you are identified as a person depends on where your office is recorded as being:
- Offices in the EU, EEA, UK or Switzerland: organisation and feature usage only. **No
user identifier, no email address and no personal profile** is sent.
- Offices elsewhere (for example the United States or Mexico): your user identifier
and your work email address are sent in addition, so that usage can be attributed and a support question answered.
We do not make video-style recordings of your screen, and we do not collect your browser console output. Credential-looking values in a web address are replaced before the address is sent. See section 6.2 for the detail.
4.12 Data on your own device
If you use DGM One offline, your device stores your draft checklists, your photographs as raw image files and your signature image in the browser's local database. This data stays on your device until it is synchronised. Records that have synchronised are deleted from the device 24 hours later.Signing out clears device-local data. Your draft checklists, your photograph previews and any records that have already synchronised are removed from the device when you sign out — from every sign-out control, including the one in the sidebar and in the mobile navigation drawer. This matters on a shared warehouse tablet: the next person to sign in does not inherit your work.
Records still waiting to sync are deliberately kept, including across sign-out. They are the only copy of that inspection, and deleting them would destroy your work. While they are waiting they are locked to the inspector who created them.
4.13 Special categories of data
We do not intentionally process special categories of personal data (Art. 9 GDPR). We do not ask for health, biometric, religious, political or trade-union data.
Two honest caveats. A handwritten signature is a strong personal identifier and is biometric-adjacent, although it is not, on its own, biometric data used for the purpose of uniquely identifying a person within the meaning of Art. 9. And free-text note fields and photographs are unstructured: we cannot technically prevent a user typing, or photographing, something that falls into a special category. Please do not enter health or other sensitive personal information into free-text fields.
5. Why we process it, and on what legal basis
| # | Purpose | Our role | Data | Legal basis |
|---|---|---|---|---|
| 1 | Providing the DGM One service: accounts, checklists, submissions, photographs, PDFs, offline sync | Processor for our customer | 4.1–4.5, 4.7, 4.12 | Our customer's basis, on their instruction (Art. 28). Our own basis for the contract with them: Art. 6(1)(b) |
| 2 | Authenticating you and keeping your session | Processor | 4.1, 4.2 | Art. 6(1)(b); technically necessary storage |
| 3 | Training and certification tracking, expiry reminders | Processor | 4.6 | Our customer's basis, on their instruction |
| 4 | AI extraction from shipping and safety documents | Processor, with Anthropic as sub-processor | 4.5, 4.7 | Our customer's basis, on their instruction. See section 7 |
| 5 | Audit logging of privileged actions | Mixed — processor for our customer's accountability, controller for our own security monitoring | 4.8 | Art. 6(1)(f): our legitimate interest in detecting misuse and being able to reconstruct what happened |
| 6 | Security, rate limiting, bot and abuse defence at sign-up | Controller | hashed IP, browser signals | Art. 6(1)(f): our legitimate interest in protecting the service and our email reputation |
| 7 | Transactional email — invitations, password resets, certificate expiry reminders, watchlist alerts | Processor for customer-triggered mail; controller for account and security mail | name, email, message content | Art. 6(1)(b) and Art. 6(1)(f) |
| 8 | Billing, subscriptions, seats, and our own accounting and tax records | Controller | 4.9 | Art. 6(1)(b) and Art. 6(1)(c) |
| 9 | Product analytics | Controller | 4.11 | Consent, obtained through the analytics choice described in section 6.2 — § 25(1) TDDDG for the storage on your device and Art. 6(1)(a) GDPR for the processing. Nothing is collected before you choose, and you can withdraw at any time |
| 10 | Error monitoring | Controller | user id, organisation, correlation identifiers | Art. 6(1)(f). Not currently enabled in production. See section 6.3 |
| 11 | Demonstration requests and sales follow-up | Controller | 4.10 | |
| 12 | Establishing, exercising or defending legal claims; responding to lawful requests | Controller | as relevant | Art. 6(1)(f); Art. 6(1)(c) where a legal obligation applies |
5.1 Our legitimate interests, stated
Where we rely on Art. 6(1)(f), our interests are: keeping the service secure and available; being able to reconstruct who did what after an incident; preventing abuse of our sign-up and email infrastructure; and, for error monitoring, being able to detect and fix faults. We have weighed these against your interests and consider the processing proportionate, in particular because IP addresses are hashed wherever the purpose allows it, and because error monitoring is restricted by a technical filter to an explicit allow-list of identifiers.
You have the right to object to any processing based on Art. 6(1)(f). See section 12.
6. Cookies, tracking, and analytics
6.1 What is stored on your device
| What | Purpose | Lifetime | Requires your consent? |
|---|---|---|---|
| Session cookie | Keeps you logged in | Session, 7 days maximum | No — strictly necessary |
| Service-worker cache (offline app) | Lets the app work offline, which is why you installed it | Until cleared | No — strictly necessary for a function you requested |
Offline database (oryx-offline) | Your draft checklists and photographs, held on your device | Until synced, then 24 hours; unsynced items are kept | No — strictly necessary, but disclosed here |
ph_…_posthog cookie plus browser storage | Product analytics. Written only after you choose "Allow analytics" | 365 days | Yes |
| Demo form prefill | Remembers what you typed on the demonstration form | Until cleared | Yes |
6.2 Product analytics — what we collect, and what we do not
We use PostHog, hosted in the United States, to understand which features are used and where people get stuck. Nothing here is used for advertising, and nothing is sold to anyone.
Nothing analytics-related runs until you choose "Allow analytics". Before that choice, no analytics identifier is written to your device — no cookie, no localStorage entry, no sessionStorage entry — and no request is made to the analytics provider at all. The software that would do it is not initialised. Refusing is exactly as easy as accepting, and ignoring the question is not consent.
Session replay is switched off. We do not make video-style recordings of your screen, and we do not collect your browser console output. Replay would capture rendered text, which in this product means shipper and consignee names and the contents of dangerous-goods declarations, so it is disabled rather than merely masked.
It was switched off on 27 September 2026. A small number of recordings captured before that date — all of our own staff and partner-office testers, none of a customer's EU personnel — remain with the analytics provider until they expire under its 30-day retention. We are not adding to them.
Credentials in web addresses are removed before the address is sent. Where a query-string parameter's name looks like a credential — it contains token, secret, password, key, code, auth, session, signature, credential or email — its value is replaced with `redacted`. The parameter name is kept, so we can still see that an invitation link was opened without ever seeing the invitation token.
Whether you are identified as a person depends on where your office is. This is a deliberate split, not a technical accident:
| Your office is recorded as being in | What is sent |
|---|---|
| The EU, the EEA, the UK or Switzerland | Your organisation identifier and your feature usage. No user identifier, no email address, no personal profile. You are not identified as an individual |
| Anywhere else — for example the United States or Mexico | The above, plus your user identifier and your work email address, so usage can be attributed and a support question answered |
The decision follows the country recorded for your office, not where you personally happen to be at the time. An office with no country recorded is treated as if it were in the EU — the more protective of the two options.
Withdrawing your choice. There is a working control on the cookie policy page at /legal/cookies. Withdrawing stops collection immediately, clears the identifiers already stored in your browser, and returns you to the undecided state so you can choose again. Withdrawal does not affect the lawfulness of what was processed before it (Art. 7(3) GDPR).
The gap we still have, stated plainly.IP anonymisation is not enabled on our PostHog project. Your IP address therefore reaches the provider, and the provider derives an approximate location from it. We are not presenting that as acceptable; we are telling you because it is true. Event data is retained for a nominal 12 months.
Legal basis. Your consent: § 25(1) TDDDG for the storage on and reading from your device, and Art. 6(1)(a) GDPR for the processing that follows. For this processing we are the controller, not a processor for your employer, so you can come to us directly.
Every cookie and storage key involved is listed in the cookie policy at /legal/cookies.
6.3 Error monitoring
Our error monitoring tool (Sentry) is integrated in our code, with a filter that removes authorisation headers, cookies, API keys and request bodies, and restricts what is sent to an explicit allow-list of identifiers.
It is not switched on in our production environment. No error data is being sent to Sentry today. We describe it here because it is present in the software you run and because we intend to enable it; when we do, this notice will be updated first.
6.4 Bot protection
Our sign-up page uses Cloudflare Turnstile to distinguish people from automated scripts. Cloudflare receives your IP address and browser signals for this check. We store only a hash of your IP address, never the address itself.
7. AI processing of your documents — read this section
This is the processing least obvious to a reader, and the most sensitive. We describe it in full.
7.1 What happens
When a document is uploaded to DGM One for automated analysis — a Shipper's Declaration for Dangerous Goods, a safety data sheet, a UN 38.3 test report, a shipping paper, a permit — or when certain photographs are analysed, the document itself is transmitted to Anthropic, PBC in the United States and processed by a Claude model.
Concretely, for a Shipper's Declaration we send rendered images of up to eight pages and ask the model to transcribe the shipper and consignee blocks verbatim. That means the following leaves our infrastructure and enters Anthropic's:
- Shipper's full name and address
- Consignee's full name and address
- Telephone numbers
- The name of the person who signed the declaration, and the signing date
- The image of the page, including the handwritten signature on it
- Free text, notes and any other personal data visible on the page
The same pattern applies to safety data sheets, battery test reports, shipping papers and permits, and to package and label photographs sent for analysis.
7.2 On what basis, and who decides
We act as a processor here. Our customer — your employer — decides to run documents through the extraction feature and is the controller for it. Anthropic acts as our sub-processor. The feature is controlled by a per-customer setting and can be switched off for an entire organisation.
7.3 What Anthropic may and may not do with it
Established from Anthropic's contractual terms as at 2026-09-02, and archived as evidence:
- Anthropic does not train its models on this data. This is a contractual commitment,
not a setting.
- Anthropic processes it only to return the extraction result to us.
- Anthropic retains inputs and outputs for up to 30 days on its United States
infrastructure by default, then deletes them. Longer retention can apply where Anthropic's own legal obligations or trust-and-safety processes require it.
- On termination, Anthropic deletes all copies within 30 days, subject to legal
retention carve-outs.
7.4 Where it goes, and why that matters
Anthropic's first-party API offers no EU data residency. This processing takes place in the United States. It is covered by Standard Contractual Clauses (section 10), not by the EU–US Data Privacy Framework — Anthropic is not certified under that framework.
7.5 What we store afterwards
The raw extraction result is cached for 24 hours and then deleted. Extracted values are written into the shipment record and are then kept for as long as that record is kept (section 11). The source document is kept for 90 days for document-analysis jobs.
7.6 What the AI does not do
- It does not make decisions about people. Every AI output on the inspection path is
a suggestion about a shipment or a document, presented to a human who accepts, rejects or edits it before signing. Confidence is deliberately never reported as certainty.
- It does not profile you from your documents.
- **We do not use your documents, your photographs or your inspection records to train
any model**, ours or anyone else's.
7.7 A separate, optional feature that does concern a person
One feature — AI-assisted training recommendations — analyses a named individual's 90-day pass rate, repeat-failure rate and most frequently failed checklist items, and produces suggested training. See section 8. It is switched off for every customer organisation today. It is mentioned here so that the description is complete.
8. Automated decision-making and profiling
We do not carry out automated decision-making that produces legal effects concerning you or similarly significantly affects you, within the meaning of Art. 22(1) GDPR.
Two clarifications, because both are the kind of thing a reader should be told without having to ask.
Automated shipment approval. The product contains an optional mode that can approve a consignment without a human when every check has passed. The subject of that decision is a consignment, not a person. It is switched off for every customer today.
Training recommendations — this is profiling. The optional feature described in 7.7 evaluates aspects of a named employee's performance at work. That is profiling within the meaning of Art. 4(4) GDPR. The formal decision to assign training remains with a human administrator, so we do not consider Art. 22 to be engaged — but we state the feature plainly because employees are entitled to know it exists. The design deliberately forbids the model from characterising the person, requires human resources and legal sign-off before it can be enabled for any organisation, and displays a permanent "AI-generated, not validated by a regulatory expert" banner on every recommendation.
9. Who receives your data
We do not sell personal data. We do not share it for advertising. We share it with the service providers below, each of which acts as our processor or sub-processor under a written data processing agreement (Auftragsverarbeitungsvertrag, AVV) incorporating the EU Standard Contractual Clauses.
| Provider | What it does for us | Personal data it sees | Where it processes it |
|---|---|---|---|
| Vercel Inc. (US) | Hosting and application compute | All request data in transit; IP address and user agent in runtime logs; session cookie | United States — region iad1, Virginia |
| Supabase (US) | Primary database | Accounts, sessions with IP and user agent, submissions, inspector names, signatures, audit log | United States — us-east-1 |
| Cloudflare, Inc. (US) | Object storage (R2) for photographs, generated PDFs and certificates; content delivery; bot protection at sign-up (Turnstile) | Uploaded images and generated documents; for the bot check, IP address and browser signals | Default (non-EU) jurisdiction; global edge |
| Anthropic, PBC (US) | AI classification and extraction from documents (section 7) | Document contents: shipper and consignee names and addresses, telephone numbers, signatory names, page images | United States |
| Functional Software, Inc. (Sentry, US) | Error monitoring | User and organisation identifiers, correlation identifiers | United States — integrated, but no configuration key ships in the production bundle today, so nothing is sent from your browser |
| Resend (US) | Transactional email | Recipient name and email address, message content | United States |
| Google LLC (Google Workspace, US) | Our own email and office tools. It sees your data only if you correspond with us, or if a document is attached to that correspondence | Names, work email addresses, correspondence content and attachments | United States |
| PostHog Inc. (US) | Product analytics (section 6.2) — no session recording | Organisation identifier and feature usage; user identifier and work email address only for offices outside the EU, EEA, UK and Switzerland; IP address and the approximate location derived from it | United States |
| Stripe, LLC (US / Ireland) | Payment processing | Name, email, billing address. Card data never reaches us | United States / Ireland |
All nine agreements are in force, incorporated into the terms we accepted, and we hold archived copies with the date they were retrieved. The same list, with the transfer mechanism for each recipient, is Anlage 3 of our data processing agreement at /legal/dpa.
We will also disclose personal data where we are legally required to, or where it is necessary to establish, exercise or defend legal claims.
9.1 Changes to this list
We publish an addition to, or a replacement of, a provider in this list at least 30 days before that provider begins processing, and a customer organisation may object in writing during that period. The list is published as Anlage 3 of the data processing agreement at app.dgmone.com/legal/dpa, and the version of it in force at any time is the one shown there.
10. International transfers (Drittlandtransfer)
All of the personal data described in this notice is processed in the United States. We do not currently operate any EU-hosted instance of DGM One. We are stating this plainly rather than describing what we intend to build.
The United States is not the subject of an adequacy decision that covers all of our providers. Our transfers therefore rely on Standard Contractual Clauses — the European Commission's standard data protection clauses under Implementing Decision (EU) 2021/914 — which form part of the agreement we have with each provider, together with the UK International Data Transfer Addendum where UK data is involved.
We deliberately do not rely on the EU–US Data Privacy Framework. We checked the official register directly rather than taking a vendor's word for it. Supabase and Anthropic are not certified under the Framework — and between them those two hold every durable record and the most sensitive document contents in the system. Cloudflare and Sentry are active participants; we name those two because we verified them, and we do not make the claim for any other provider in the list.
Our transfer position therefore rests on the Standard Contractual Clauses for every provider, certified or not. A safeguard that covers part of a chain is not a safeguard for the chain — and this is also the position that survives the appeal currently pending before the Court of Justice against the Framework (Case C-703/25 P).
10.1 What this means in practice
United States law permits public authorities to compel disclosure by US providers in circumstances that have no exact equivalent in EU law. That risk is real and we do not minimise it. The measures we apply to reduce it are: HTTPS-only transport; hashing IP addresses wherever the purpose allows it; stripping location metadata from photographs before upload; restricting what error monitoring may transmit to an explicit allow-list; and a contractual commitment from our AI provider not to train on your data and to delete it within 30 days.
We maintain a transfer impact assessment for each of the nine providers, as SCC Clause 14(d) requires of us as exporter. The facts in each are established and verified; the legal analysis is being completed with counsel, taking Anthropic first because it is the hardest. We provide them to a customer, its data protection officer or a supervisory authority on request, in the state they are in.
You may request a copy of the relevant safeguards from us using the contact details in section 1.
11. How long we keep your data (Löschkonzept)
The table below states what actually happens today. Where nothing deletes the data, we say so.
| Data | Retention today | Status |
|---|---|---|
| Cached AI extraction results | 24 hours | Enforced |
| Documents uploaded for analysis, and their source PDFs | 90 days | Enforced for document-analysis jobs |
| Battery and permit verification jobs | 90 days after a manual deletion step that is not currently performed | Not effective in practice |
| Notifications | 30 days after you dismiss them, or an explicit expiry | Enforced; a notification never dismissed and with no expiry is kept indefinitely |
| Sessions | Expire after 7 days | Expired rows, including IP address and user agent, are not deleted and accumulate |
| Audit log | A 2-year deletion rule exists in the software | Switched off in production. Audit records, including IP addresses, are currently kept indefinitely |
| Submissions, checklist answers, inspector names, signatures | No deletion. Kept indefinitely | Our documentation states a minimum of 2 years, derived from a US dangerous-goods record-keeping rule (49 CFR 172.201(e)), and no maximum |
| Photographs and generated PDFs in object storage | No deletion path exists in any part of the system | Verified gap |
| Signature records with IP address and user agent | Insert-only, never deleted | Verified gap |
| Per-user AI usage records | No deletion | Verified gap |
| Demonstration enquiries (name, email) | No automatic expiry | Manual deletion only |
| Account and billing records | Kept for the duration of the contract, then as required for accounting and tax | 2 years from the date the shipping paper is provided to the initial carrier — 49 CFR 172.201(e) (US). An EU controller states its own basis, e.g. § 257 HGB / § 147 AO. |
| Session recordings | 30 days. Session replay was switched off on 27 September 2026 and no new recordings are made. A small number captured before that date remain with the provider until they expire — see section 6.2 | Provider retention setting |
| Analytics events | Nominally 12 months | Enforcement unconfirmed |
| Data held by our AI provider | Up to 30 days | See section 7.3 |
| Data on your own device | Synced records deleted after 24 hours; unsynced records kept until they sync | Enforced |
| Database backups | 7 daily snapshots held by our database provider, in the same US region | Point-in-time recovery is off, and there is no independent copy outside the provider |
About the rows that say "no deletion". Several rows above describe data for which no automatic deletion runs today. We publish that rather than hide it. Two things are worth knowing alongside it. First, the records concerned are inspection records that a dangerous-goods regulation requires us to keep for a minimum period in any event, and the service began operating in 2026, so nothing has yet reached the end of that minimum. Second, deletion on request is carried out — by us, by hand, reaching object storage as well as the database — for any customer or data subject who asks (section 12.1). We are implementing retention ceilings so that it happens without anyone having to ask, and this table will state them when they run.
12. Your rights
Under the GDPR you have the following rights. They apply to the controller — so where we act as processor for your employer, exercise them against your employer, who will instruct us (section 2).
- Right of access (Art. 15) — to know whether we process your data, and to receive
a copy of it together with the information in this notice.
- Right to rectification (Art. 16) — to have inaccurate data corrected and
incomplete data completed.
- Right to erasure (Art. 17) — to have your data deleted where one of the grounds in
Art. 17(1) applies.
- Right to restriction of processing (Art. 18) — to have processing limited while a
dispute about accuracy or lawfulness is resolved.
- Right to data portability (Art. 20) — to receive the data you provided, in a
structured, commonly used, machine-readable format, and to have it transmitted to another controller where technically feasible.
- Right to object (Art. 21) — to object at any time, on grounds relating to your
situation, to processing based on our legitimate interests (Art. 6(1)(f)); and to object at any time, without needing a reason, to processing for direct marketing.
- Rights in relation to automated decision-making (Art. 22) — including the right to
obtain human intervention. See section 8.
- Right to withdraw consent (Art. 7(3)) — where processing is based on your consent,
you may withdraw it at any time, with effect for the future. Withdrawal does not affect the lawfulness of processing before it.
We will respond within one month of receiving your request, extendable by two further months for complex requests, and we will tell you if we extend. Exercising these rights is free of charge.
We are also required, where feasible, to inform every recipient of your data of a rectification, erasure or restriction (Art. 19), and to tell you who those recipients are if you ask.
12.1 What we can and cannot do today — stated honestly
**This section describes real limitations. Please read it before relying on the rights
above.**
- We have no self-service export. An access or portability request is fulfilled by our
engineers querying the database by hand. It works, but it is manual, and it depends on a person being available.
- Erasure is not fully implemented. The account-deletion function in the product
removes login records only, and fails for any user who has ever completed work in the product, because the database's integrity rules prevent it. Photographs, generated PDFs and certificates are not deleted from our object storage by any part of the system. An erasure request today requires manual work and we cannot yet guarantee it reaches every copy.
- We have no mechanism for restriction of processing. Art. 18 would be honoured, today,
by an administrator deactivating the account and by an internal instruction not to process further. That is a procedural control, not a technical one.
- We do not maintain a recipient registry, so the Art. 19 notification obligation is
currently fulfilled by hand from the list in section 9.
- Analytics consent can be withdrawn in the product, from the control on the cookie
policy page at /legal/cookies (section 6.2). Withdrawal takes effect immediately and clears the identifiers stored in your browser. If you also want the events already collected about you deleted at the provider, ask us and we will do it.
None of this limits your rights. Where a right applies to us, we honour it — by hand if that is what it takes, and within the Art. 12(3) deadline. We are building self-service export, an automated erasure path that reaches object storage and device-local copies, and a restriction mechanism; the sentences above will change when they exist, and not before.
12.2 How to make a request
Write to privacy@emfara.com. We may ask you for information to confirm your identity — we will ask for the minimum necessary, and we will not use it for anything else. We answer within one month (Art. 12(3) GDPR), and tell you if we need longer and why.
13. Your right to complain to a supervisory authority
You have the right to lodge a complaint with a data protection supervisory authority (Art. 77 GDPR), in particular in the EU or EEA Member State where you live, where you work, or where you believe the infringement took place. You do not have to contact us first, although we would prefer the chance to put things right.
Because we are established in the United States and have not appointed an Art. 27 representative (section 1.3), there is no single lead authority for us in the EU. That works in your favour rather than against it: you may complain to the authority for your own country, region or workplace, and you do not need to find ours first. If you tell us where you are, we will give you that authority's current contact details.
For readers in Germany, the competent authority is the Landesdatenschutzbehörde for the federal state in which you live or work. For readers in the United Kingdom, it is the Information Commissioner's Office.
14. Are you required to provide this data?
- Your account data (name, work email, password) is required by contract: without
it we cannot create an account and you cannot use DGM One. There is no statutory obligation on you to provide it, but there is no service without it.
- Inspection data — your name as inspector, your answers and your signature — is
required for the record to have evidential value. Your employer, and in many cases dangerous-goods regulation, requires an identified, signed record. Without a signature the checklist cannot be completed.
- Documents you upload are voluntary in the sense that you choose to use the analysis
feature; the underlying documents are required by dangerous-goods regulation, not by us.
- Demonstration enquiries are entirely voluntary. If you do not give us your name and
email address, we simply do not create the demonstration account.
- Analytics is not necessary for the service at all. See section 6.2.
15. How we protect your data (technische und organisatorische Maßnahmen — TOM)
The measures below are ones we have verified in our own code and infrastructure. We list only what exists.
- Strict separation between customer organisations. A request for another
organisation's record returns "not found", never "forbidden" — so the existence of another customer's data is not even disclosed. This is enforced by a dedicated suite of 135 automated tests that must pass before any change is released. It is the strongest control we have.
- IP addresses are hashed, not stored, in the three places where only abuse detection
requires them.
- Location and device metadata are removed from every photograph in your browser
before upload.
- **Personal access tokens for our integration interface are stored only as cryptographic
hashes**, shown once, never recoverable. (Bearer tokens issued through the interface's OAuth flow are stored differently, as our authentication library requires; that is a hardening item recorded in our internal register, not a claim we make here.)
- Our integration interface applies a deliberate personal-data filter: the submission
tool returns a projection that excludes raw answers, and the audit-log tool excludes IP address, user agent, email address and detail fields.
- Strong browser security headers: a full Content Security Policy, HTTP Strict
Transport Security with a two-year lifetime, and clickjacking and MIME-sniffing protection.
- An insert-only audit log of privileged actions, which cannot be edited after the fact.
- Encryption in transit. All browser traffic is HTTPS-only, enforced by a two-year
HSTS policy, and transfers to our object storage are encrypted. Our database provider enforces TLS on its side; we have not independently verified from our own configuration that our application refuses a non-TLS connection, so we do not claim it here.
- Encryption at rest is provided by our managed database and object-storage providers,
under their own key management. We do not offer customer-managed encryption keys, and we neither hold nor control the keys ourselves.
- A permanent filter on error monitoring that removes authorisation headers, cookies,
API keys and request bodies.
15.1 What we do not have
We would rather you learn this here than discover it later.
- No multi-factor authentication and no enterprise single sign-on. Authentication is
email and password only. This includes our own platform-wide administrator account.
- No external penetration test has ever been performed.
- No SOC 2 report and no ISO 27001 certificate. There is no such thing as a "GDPR
certificate", and we do not claim one.
- No point-in-time recovery, and no backup copy outside our database provider. The
provider's managed backups do work — seven daily snapshots with 7-day retention — but they sit in the same US region as the live database, and there is no independent copy elsewhere.
- No published recovery-time objective. We have not tested a restore often enough to
stand behind a number, and we would rather publish none than publish one we cannot evidence.
- No EU data residency. Everything runs in the United States; see section 10.
- No self-service export or deletion tooling. Export and deletion are carried out by us
on request — see section 12.1.
- Data on your own device is not encrypted by the application beyond the protection
your operating system and browser profile provide.
Our technical and organisational measures are also set out, control category by control category with the same gaps stated, in Anlage 2 of the data processing agreement at /legal/dpa. A fuller annex is available to a customer, its data protection officer or its auditor on request to privacy@emfara.com.
16. Children
DGM One is business software for dangerous-goods professionals. It is not directed at children and we do not knowingly process the personal data of anyone under 16.
17. Changes to this notice
We will update this notice when our processing changes, and we will change the version and date at the top. Where a change materially affects you — a new category of data, a new purpose, a new recipient, or a new country — we will tell affected users before it takes effect rather than relying on you to re-read the page.
Version history
| Version | Date | Change |
|---|---|---|
| 2026-09-27 | 27 September 2026 | First published version. Analytics is now behind a prior consent choice with a working withdrawal control; session replay switched off; credential-shaped values removed from addresses before they are sent; person-level identification limited to offices outside the EU, EEA, UK and Switzerland; device-local data cleared at sign-out. |
18. Related documents
Published, at app.dgmone.com/legal:
- Terms of Service —
/legal/terms - Data Processing Agreement (AVV), with its annexes, including the sub-processor list
(Anlage 3) and the technical and organisational measures (Anlage 2) — /legal/dpa
- Cookie and similar-technologies policy —
/legal/cookies - This notice —
/legal/privacy
Available on request to privacy@emfara.com, to a customer, its data protection officer or its auditor: the fuller technical and organisational measures annex; the record of processing activities (Verzeichnis von Verarbeitungstätigkeiten, Art. 30); the deletion concept (Löschkonzept); the data-subject-request and incident procedures; the vendor data-processing and transfer register; and the transfer impact assessments.
The version of this notice in force at any time is published at `app.dgmone.com/legal/privacy`. Previous versions are retained and are provided on request.