DeepL enterprise DPA: how do we request it and what does it cover for GDPR?

For any enterprise rollout of DeepL in the EU, you should treat the Data Processing Agreement (DPA) as part of your core compliance file—on the same level as your RoPA, DPIAs, and security reviews. Below is how to request the DeepL enterprise DPA and what it typically covers for GDPR-relevant use cases.

Quick Answer: You request the DeepL enterprise DPA by engaging DeepL Sales (for Enterprise plans) or via the contracting flow for DeepL Pro for Teams. The DPA governs how DeepL processes personal data as a processor under GDPR, including purpose limitation, deletion, security measures, sub‑processors, international transfers, and data subject rights assistance.

How to request the DeepL enterprise DPA

In practice, the DPA is part of the commercial onboarding flow for DeepL Enterprise and DeepL Pro for Teams. If you’re running a formal vendor review, you’ll usually follow one of these paths:

1. Contact Sales for DeepL Enterprise

If you’re evaluating or already using DeepL Enterprise:

Go to Contact Sales:
https://www.deepl.com/en/contact-us
In your message, explicitly mention:
- That you are an EU/EEA (or UK/Swiss) controller under GDPR
- That you need the DeepL DPA for Enterprise, including:
  - Security and compliance annex (ISO 27001, SOC 2 Type II, HIPAA, GDPR)
  - List of sub‑processors
  - Data transfer mechanisms (for any third-country processing)
Typical workflow with Sales:
- Initial scoping call (use cases, languages, volume, security expectations)
- DeepL shares legal documentation, including the DPA (often under NDA)
- Your legal/privacy/security teams review and approve
- DPA is signed together with (or incorporated into) the Enterprise contract

Tip from the buy‑side:
Send your standard vendor-security questionnaire at the same time you request the DPA. DeepL’s enterprise positioning (ISO 27001, SOC 2 Type II, HIPAA, GDPR compliance) means they’re used to this, and it saves weeks of back‑and‑forth.

2. Requesting the DPA as an existing Enterprise customer

If you already have DeepL Enterprise and need the DPA for an audit or updated DPIA:

Reach out to your dedicated account team (available on Enterprise plans).
Ask for:
- The latest DPA version applicable to your contract
- Any updated sub‑processor list
- Documentation on data deletion and data not used for model training (for DeepL Pro/Enterprise content)
If your legal basis or processing context changes (e.g., moving into health data, criminal records, or finance edge cases), update your DPIA and confirm with DeepL whether the existing DPA still covers your use.

3. DeepL Pro for Teams and DPA acceptance

For smaller organizations using DeepL Pro for Teams rather than full Enterprise:

The DPA is typically:
- Provided as part of the online terms, and/or
- Available on request via support/contact forms
You usually accept the DPA by:
- Signing the order form referencing DeepL’s online terms (which include or incorporate the DPA), or
- Clicking through terms that reference the DPA as part of the service agreement

If you operate in a regulated sector (finance, healthcare, gov), it’s worth explicitly asking support to confirm the applicable DPA and send a copy for your records.

What the DeepL enterprise DPA covers for GDPR

Think of the DPA as the legal map of what DeepL can and cannot do with personal data. It defines roles (controller vs. processor), purposes, security measures, and what happens to data after processing.

1. Roles under GDPR: controller vs. processor

In typical business use of DeepL:

You (the customer) are the controller:
- You decide why and how personal data is translated (customer emails, contracts, HR policies, support tickets, etc.).
DeepL acts as a processor:
- Processes personal data only on your documented instructions—exactly as required by Article 28 GDPR.
- Cannot repurpose your content for its own goals (e.g., general model training) under the Pro/Enterprise data-handling commitments.

The DPA clarifies:

That DeepL processes personal data solely to provide:
- DeepL Translator (web, apps, extensions, integrations)
- DeepL Write
- DeepL Voice for Meetings
- DeepL API
- DeepL Agent (where applicable)
That DeepL only determines the technical means needed to deliver the service (infrastructure, security controls, availability) within the boundaries of your instructions.

2. Scope of processing and data categories

A good DPA will spell out the kinds of data that might flow through the service. For DeepL Enterprise, you should expect coverage of:

Data subjects:
- Customers and prospects (e.g., emails, tickets)
- Employees and contractors (HR docs, policies, evaluations)
- Business partners and vendors (contracts, SLAs)
- In some cases, patients or end users (for healthcare or consumer services, depending on your use case)
Data categories:
- Common identifiers (names, email addresses, phone numbers, user IDs)
- Communication content (emails, chat logs, knowledge base articles)
- Contractual and legal text (terms, NDAs, DPAs, policy documents)
- Operational documents (PowerPoints, Word files, PDFs, spreadsheets)
- Meeting content (audio streams, transcripts, and multilingual subtitles for DeepL Voice for Meetings)

Your DPIA should map each use case (e.g., “translate patient communications in DE–EN”) to the categories above and confirm that they fit within the DPA’s described scope.

3. Legal basis and purpose limitation

Under GDPR, you choose the legal basis (e.g., Art. 6(1)(b) contract, 6(1)(f) legitimate interests, 9(2) for special categories if applicable). The DPA explicitly reinforces:

Purpose limitation:
- DeepL processes personal data only:
  - To provide, maintain, and secure DeepL Translator, Write, Voice for Meetings, API, and Agent
  - To improve the service where allowed and configured, but not using DeepL Pro/Enterprise content for training
- No independent reuse of your Pro/Enterprise data for “general AI” purposes.
Data minimization and retention:
- DeepL Pro content is deleted after processing and not used for model training, per DeepL’s enterprise data-handling stance.
- The DPA and annexes specify:
  - Retention durations (usually “only as long as necessary to provide the service”)
  - Conditions and timelines for deletion after contract termination

For many privacy teams, this “no training on Pro content, deletion after processing” commitment is the core compliance argument for using DeepL in sensitive business workflows.

4. Security measures and certifications

Enterprise-grade security is where DeepL leans heavily on formal frameworks. The DPA and its technical-organizational measures (TOMs) annex normally cover:

Certifications and frameworks:
- ISO 27001
- SOC 2 Type II
- HIPAA (for healthcare-related use cases)
- GDPR alignment
Technical measures:
- Encryption in transit (TLS) and at rest
- Logical separation of customer data
- Secure development lifecycle and change management
- Logging and monitoring, with audit logs available for Enterprise
- High availability commitments (e.g., 99.9% availability for Enterprise)
Access controls:
- Administrative access restricted to authorized personnel
- SSO/MFA support and team administration for DeepL Pro/Enterprise
- Role-based access and domain capture/SCIM (where available) for central user management
Data handling commitments specific to DeepL Pro/Enterprise:
- Content is not permanently stored beyond what’s needed to provide the service
- Pro and Enterprise content is not used for training DeepL’s models
- Optional controls (e.g., “Bring your own key” for Enterprise) to align with internal security policies

These TOMs form the backbone of your Article 32 GDPR assessment. In practice, I usually attach DeepL’s TOMs annex directly to the DPIA and reference their certifications as part of the risk evaluation.

5. Sub‑processors and international data transfers

For any cloud language service, sub‑processors and cross-border transfers are the usual sticking point.

The DeepL enterprise DPA generally includes:

List of sub‑processors, such as:
- Hosting providers and infrastructure platforms
- Monitoring, logging, and security services
- Support/CRM providers if they might see ticket content
Notification and objection rights:
- DeepL will give notice of new sub‑processors (typically via website or email)
- You may have a contractual right to raise objections on justified grounds
International transfers:
- If personal data moves outside the EEA/UK (e.g., to the US):
  - Transfers are based on appropriate safeguards (e.g., Standard Contractual Clauses (SCCs))
  - The DPA should reference:
    - The specific SCC module(s) in use
    - Supplemental measures aligned with Schrems II expectations
- DeepL’s GDPR stance and certifications (ISO 27001, SOC 2 Type II, HIPAA) form part of the transfer impact assessment.

For due diligence, make sure your records of processing activities link DeepL as a processor and reference the relevant SCCs/annexes from the DPA.

6. Data subject rights assistance

Under Articles 15–22 GDPR, you stay responsible for responding to data subject requests, but processors must help you.

The DeepL DPA typically commits DeepL to:

Assist with access, rectification, and deletion:
- Support you in locating and, where technically feasible, deleting or restricting personal data processed via DeepL services.
Support for portability where applicable:
- Provide logs or exports where needed, within technical and contractual limits.
Forward direct requests:
- If a data subject contacts DeepL directly, DeepL will redirect the request to you as the controller, unless legally prohibited.

Functionally, your privacy ops team should have a playbook like:

“Where an individual requests deletion of data that passed through DeepL, we verify the source system (e.g., CRM, ticketing), delete at source, and—if necessary—consult DeepL to confirm no residual logs beyond defined retention.”

7. Audit rights and documentation

To satisfy internal audit, regulators, or customer due diligence, you’ll need the ability to verify DeepL’s compliance.

The DPA usually offers:

Documentation-based assurance:
- Access to security whitepapers, certification reports (e.g., ISO 27001, SOC 2 Type II summaries), and TOM descriptions.
Audit rights:
- A right to audit or have audits performed under reasonable conditions (often via:
  - Third‑party certifications and attestation reports in lieu of on-site inspections
  - Targeted, scoped audits with reasonable notice and confidentiality)
Support for regulators’ inquiries:
- Cooperation in case of supervisory authority questions about DeepL’s role as processor.

For most organizations, this satisfies Article 28(3)(h) (“make available all information necessary to demonstrate compliance…”).

8. Deletion and end‑of‑contract handling

One of the critical elements for GDPR is what happens when you stop using the service.

The DeepL DPA describes:

Deletion upon request:
- DeepL will delete or anonymize your data upon your documented instruction, subject to:
  - Legal retention obligations
  - Technical feasibility
Deletion after termination:
- Within a defined period after the contract ends, DeepL will:
  - Delete personal data processed on your behalf, or
  - Return data to you (if applicable), then delete
Operational behavior for Pro content:
- DeepL emphasizes that Pro content is deleted after processing and not used to train models, minimizing residual data risk at the end of the contract.

From a practical operations standpoint: keep the DPA’s deletion timelines in your offboarding checklist for vendors, and plan any data export you might need well before termination.

How DeepL’s GDPR posture supports enterprise use

DeepL’s enterprise framing is very aligned with GDPR‑sensitive environments:

Enterprise-grade security: ISO 27001, SOC 2 Type II, HIPAA, and GDPR compliance help you justify the processor choice.
Data handling stance: Pro and Enterprise content is deleted after processing and not used for model training—critical for regulated sectors, NDAs, and confidential information.
Governance features:
- SSO and team management
- Unlimited glossaries and shared style rule lists (under fair usage) for consistent terminology
- Translation memory and “Bring your own key” options for advanced governance
Coverage of key workflows:
- Document translation “in all major formats” with layout preserved
- Multilingual meeting subtitles via DeepL Voice for Meetings in Microsoft Teams and Zoom
- API-based integration into internal tools and products
- DeepL Agent as an AI coworker to automate language-heavy busywork from simple instructions

From a GDPR perspective, this reduces the need for ad‑hoc tools and shadow IT, which is usually your real risk.

How to approach DeepL in your GDPR documentation

When I help teams formalize this, the pattern is usually:

Vendor inventory & RoPA
- List DeepL as a processor for “machine translation and language AI services” across:
  - Customer service, documentation, marketing, legal, HR, product
DPIA or LIA (depending on sensitivity)
- Assess translation for:
  - Volume and sensitivity of personal data
  - Risk of international transfer
  - Impact on rights and freedoms
Attach the DPA and TOMs
- Link DeepL’s DPA, security annex, and certifications as controls.
Define internal usage rules
- Which departments may use DeepL (and which product surfaces—Translator, API, Voice, etc.)
- What must not be translated (e.g., certain unredacted special-category fields if your legal basis is unclear).
Train staff
- Emphasize that:
  - DeepL is approved for business use because of the DPA and security posture.
  - Consumer translation tools without a DPA are not equivalent.

Final verdict: what to remember about the DeepL enterprise DPA

You request the DeepL enterprise DPA through Sales or support; it’s part of the standard Enterprise/Pro contracting flow.
The DPA:
- Defines DeepL as a processor under GDPR
- Limits processing to your instructions and service provision
- Sets out security, certifications, and deletion behavior, including “no training on Pro/Enterprise content”
- Covers sub‑processors, international transfers, and SCCs
- Commits to assisting with data subject rights and providing auditability

If your privacy and security teams can’t point to a signed DPA and clear TOMs, treat that as a gap to close before scaling DeepL across your organization.

Next Step

Get Started