Legal · Data Protection Impact Assessment / Ocena Skutków dla Ochrony Danych

A plain-language summary of our DPIA.

Article 35 GDPR requires us to assess the privacy risks of what we do, write down how we mitigate them, and publish the headline. Here it is — without legal jargon, with the formal language alongside.

Last completed · Mar 14, 2026Next review · Sep 2026Version 2.1DPO contact →

We process passports, employment contracts, salary information, and other documents that — together — describe a person’s professional life and immigration status. Under Article 35 of the GDPR, that level of personal data triggers a Data Protection Impact Assessment. This page is the public summary; the full internal DPIA is available to UODO on request and to you, in summary form, by emailing the DPO.

PL · Przetwarzamy paszporty, umowy o pracę, dane wynagrodzenia i inne dokumenty, które razem opisują życie zawodowe i status imigracyjny człowieka. Zgodnie z art. 35 RODO ta skala danych wymaga Oceny Skutków dla Ochrony Danych. Niniejsza strona jest jej publicznym streszczeniem; pełna wewnętrzna OSdOD jest dostępna na żądanie UODO oraz, w formie streszczenia, dla użytkownika po wysłaniu zapytania do IOD.

SECTION 01

What a DPIA is

In plain language
A structured exercise where we map what data we hold, what could go wrong, and what we’ve put in place to prevent it. Required by GDPR for any processing that’s “likely to result in high risk” — which document-heavy immigration work clearly is.
EN

A DPIA (Data Protection Impact Assessment) is a structured analysis under Article 35 GDPR. It maps the personal data you process, evaluates the risks to data subjects, documents the technical and organizational measures you take to mitigate them, and is reviewed by a Data Protection Officer.

UODO (the Polish supervisory authority) lists “processing that includes large amounts of identity documents” among the categories that always require a DPIA. We agreed and ran one before launch.

PL

OSdOD (Ocena Skutków dla Ochrony Danych) to ustrukturyzowana analiza zgodna z art. 35 RODO. Mapuje przetwarzane dane osobowe, ocenia ryzyka dla osób, dokumentuje zastosowane środki techniczne i organizacyjne oraz jest weryfikowana przez Inspektora Ochrony Danych (IOD).

UODO wymienia “przetwarzanie obejmujące dużą ilość dokumentów tożsamości” wśród kategorii wymagających OSdOD. Zgodziliśmy się i wykonaliśmy ją przed startem.

SECTION 02

Why we did one

In plain language
Three triggers under GDPR Art. 35(3): (a) systematic processing of identity documents, (b) cross-border transfers to a non-EEA AI vendor, (c) processing data about a vulnerable group (foreign workers in a country whose language they may not speak fluently).
EN

Triggering criteria from GDPR Article 35(3) and the UODO 2018 list:

  • Identity documents at scale — passports, residence cards, employer letters.
  • AI-assisted processing — automated extraction of fields and confidence scoring (UODO Annex II item 9).
  • Vulnerable data subjects — foreign workers, often in a power-imbalanced relationship with their employer (UODO Annex II item 4).
  • Cross-border transfers — to a US AI provider (Anthropic) under Standard Contractual Clauses.
  • Special-category data, occasionally — medical certificates in family-reunification cases.

Any one of these would justify a DPIA. All five together made it mandatory.

PL

Kryteria z art. 35 ust. 3 RODO i listy UODO z 2018 r.:

  • Dokumenty tożsamości na skalę — paszporty, karty pobytu, listy pracodawcy.
  • Przetwarzanie wspomagane AI — automatyczna ekstrakcja pól i ocena pewności (Załącznik II UODO, poz. 9).
  • Osoby w sytuacji zagrożonej — cudzoziemcy, często w relacji o nierównej władzy z pracodawcą (Załącznik II UODO, poz. 4).
  • Transfery transgraniczne — do dostawcy AI w USA (Anthropic) na podstawie Standardowych Klauzul Umownych.
  • Dane szczególnej kategorii — okazjonalnie zaświadczenia medyczne przy łączeniu rodzin.

Każde z tych kryteriów uzasadniałoby OSdOD. Wszystkie pięć razem czyniły ją obowiązkową.

SECTION 03

What data we process

In plain language
Identity, employment, immigration, billing — the same list as in our Privacy Policy. The DPIA looks at it from a “what could go wrong” angle rather than “why we collect it.”

We process eight categories of personal data, listed and explained in Privacy §2. For DPIA purposes we group them by sensitivity:

  • High sensitivity: passport scans, residence-card scans, salary papers, family relationships, medical certificates (when applicable).
  • Medium sensitivity: employment contracts, employer letters, prior immigration history, billing/invoice data.
  • Low sensitivity: name, email, language preference, account-usage data.

Volumes (April 2026 baseline): approximately 4 200 active client accounts; 18 000 documents stored; 47 employer-vault organisations; ~120 staff messages exchanged per business day.

SECTION 04

Risks we identified

In plain language
Eight risks made the register. Three were rated high (unauthorized access to passport scans, accidental cross-tenant data leakage, AI vendor breach), four medium, one low.
Severity scaleHighMediumLow
SECTION 05

Risk register & mitigations

Each risk below shows what could go wrong, our pre-mitigation rating, what we built to address it, and the residual rating after the mitigation.

Risk
Initial
Mitigation
Residual
R-01 · Unauthorized access to passport scans
Stolen credentials, session hijack, or insider misuse.
High
AES-256 at rest. Short-lived signed URLs (5 min). Optional TOTP 2FA. Role-based access internally; least-privilege; 90-day credential rotation; audit log of all admin reads.
Low
R-02 · Cross-tenant data leakage
HR user from one company seeing workers from another.
High
Strict tenancy on every query; row-level security in the database keyed to company_id; integration tests that fail if any endpoint returns data outside the active tenant; quarterly red-team review.
Low
R-03 · AI vendor (Anthropic) breach or model retention
Document content leaving the EU and being retained by a third party.
High
Standard Contractual Clauses (Decision 2021/914). Contractual no-train assurance with Anthropic. Document content encrypted in transit. Only redacted/extracted fields sent where possible; full document only when document-level review is needed.
Medium
R-04 · Phishing impersonating Juralex specialists
Bad actor pretending to be Anna by email or phone to extract documents.
Medium
All sensitive requests (re-uploads, document changes) only via the in-app inbox, never email. SPF/DKIM/DMARC enforced on juralex.pl domain; explicit user education ("we will never call asking for your password").
Low
R-05 · Account takeover via password re-use
Users reusing passwords leaked elsewhere.
Medium
HaveIBeenPwned check on registration and password reset; rate limiting on login; optional 2FA; new-device email alerts; sessions invalidated on password change.
Low
R-06 · Data leakage via support staff
Specialist sharing client information outside the platform (e.g. by mistake, by social-engineering).
Medium
Access on a need-to-know basis; per-case audit logs of every staff view; mandatory privacy training annually; written confidentiality clauses in employment contracts; quarterly random audit of staff message threads.
Low
R-07 · Excess retention
Documents kept beyond what's necessary, increasing breach impact.
Medium
Retention rules codified per category (Privacy §4); automated deletion jobs; 30-day account-deletion sweep; 5-year accounting records the only long-term hold.
Low
R-08 · Failure to notify a breach within 72h
Delayed escalation under Art. 33 GDPR.
Low
On-call rota for security incidents; incident-response runbook; pre-drafted UODO notification template; tabletop exercise twice a year.
Low
SECTION 06

Residual risk

In plain language
After all mitigations, one risk remains at “medium” — the AI vendor case. We’ve contained it but we can’t reduce it to “low” without dropping AI-assisted document review entirely. We accept that residual risk and review it quarterly.
EN

Risk R-03 (AI vendor) cannot be reduced to “low” without removing AI-assisted document review, which would degrade service quality (slower turnarounds, more human error). The DPO and Management Board accepted the residual medium rating in March 2026, conditional on:

  • Quarterly review of the no-train assurance and Anthropic’s published security posture.
  • Continued exploration of EU-resident alternative AI providers; we will switch when one is comparably capable.
  • Continued minimisation: send only what’s needed for the specific quality check, never bulk uploads.

No prior consultation with UODO was required (the residual risk is not “high” within the meaning of Art. 36 GDPR), but we informed UODO of this DPIA at registration and the assessment is available on request.

PL

Ryzyko R-03 (dostawca AI) nie da się obniżyć do “niskiego” bez rezygnacji z weryfikacji dokumentów wspomaganej AI, co obniżyłoby jakość usługi. IOD i Zarząd zaakceptowali rezydualne “średnie” w marcu 2026 r. pod warunkiem:

  • Kwartalnego przeglądu gwarancji nieuczenia oraz publikowanego stanu bezpieczeństwa Anthropic.
  • Dalszego badania alternatyw AI z siedzibą w UE; przełączymy się, gdy znajdziemy porównywalną.
  • Dalszej minimalizacji: wysyłamy tylko to, czego wymaga konkretna kontrola jakości; nigdy zbiorczo.

Wstępna konsultacja z UODO nie była wymagana (ryzyko rezydualne nie jest “wysokie” w rozumieniu art. 36 RODO), niemniej zgłosiliśmy OSdOD przy rejestracji i ocena jest dostępna na żądanie.

SECTION 07

Sub-processors

In plain language
The full sub-processor list is in Privacy §5. Each one was reviewed during the DPIA — security posture, EU residency, DPA in place, exit plan if needed.

Each sub-processor was assessed for: jurisdiction (EU-residency preferred), security posture (SOC 2, ISO 27001, or equivalent), DPA in place, ability to support data-subject rights requests within our 30-day window, and exit costs (how hard it would be to switch). The full list, roles, and jurisdictions are on Privacy → Sub-processors; updates are notified 30 days in advance per Privacy §12.

AI-assist sub-processor
added 2026-05-11

Anthropic PBC (Claude API)

We use Anthropic’s Claude API to generate plain-English explanations for the validation findings shown on a case (e.g. “your contract looks fixed-term — indefinite is recommended”). The model receives only the rule-engine output, the document type, and the application path — never the raw document text, applicant name, email, or any other identifying field. This is decision-assist only; the platform does not use Anthropic for any automated decision-making within the meaning of GDPR Art. 22.

Jurisdiction
USA · DPA in place (Anthropic Commercial Terms)
Data sent
Metadata only — no document text, no PII
Retention
Anthropic does not train on API inputs · no long-term retention
Exit plan
Feature degrades gracefully — service returns to rule-engine-only output if the key is removed
SECTION 08

DPO & supervisory authority

MK
Data Protection Officer · IOD
Marta Krawczyk
dpo@juralex.pl · responds within 5 business days · independent of the management board, reports directly to the Board.

The DPO is Marta Krawczyk, registered with UODO. She is independent of the management board, has direct reporting lines to the Board, and her contract cannot be terminated for performance of DPO duties (per Article 38(3) GDPR). She owns the full DPIA, runs the quarterly review, and is the contact point for both data subjects and the supervisory authority.

Polish supervisory authority: Prezes Urzędu Ochrony Danych Osobowych, ul. Stawki 2, 00-193 Warszawa, uodo.gov.pl, +48 22 531 03 00.

SECTION 09

Changes to this DPIA

The DPIA is reviewed every six months and on any of the following triggers: a new sub-processor handling sensitive data, a change in the AI provider, a notifiable data breach, a change in the categories of data we collect, or material new guidance from UODO or the EDPB. Each review is signed off by the DPO and the management board; the public summary on this page is updated to match.

Juralex sp. z o.o. · KRS 0000935712 · NIP 525-000-12-34
Questions? dpo@juralex.pl