Международен трансфер на лични данни — SCCs, DPF и практическо ръководство

Всяка българска компания, която използва облачни услуги, SaaS платформи или аутсорсинг партньори извън ЕИП, извършва международен трансфер на лични данни. Глава V на GDPR поставя строги правила — от решения за адекватност, през стандартни договорни клаузи (SCCs), до Data Privacy Framework. В тази статия разглеждаме всички механизми, стъпка по стъпка.

Рамката на GDPR Глава V (чл. 44–49)

Глава V от GDPR установява основния принцип: лични данни могат да бъдат предадени на трета държава или международна организация само ако нивото на защита не е подкопано. Чл. 44 изрично посочва, че трансферът е допустим единствено при спазване на условията от Глава V.

Механизмите за законосъобразен трансфер са подредени в йерархия:

1. Решение за адекватност (чл. 45) — Комисията е установила, че третата държава осигурява адекватно ниво на защита
2. Подходящи гаранции (чл. 46) — SCCs, BCRs, кодекси за поведение, сертификационни механизми
3. Дерогации (чл. 49) — изключения при липса на горните (изрично съгласие, изпълнение на договор, обществен интерес и др.)

Всяка обработка на лични данни [...] която се състои в предаване или предоставяне за достъп на лични данни, които са обект или ще бъдат обект на обработване след предаването им на трета държава [...] се извършва само при спазване на условията, посочени в настоящата глава. — Чл. 44 GDPR

Решения за адекватност (чл. 45)

Решението за адекватност е най-простият механизъм: Европейската комисия установява, че трета държава осигурява ниво на защита, по същество еквивалентно на това в ЕИП. Трансферът към такава държава не изисква допълнителни гаранции.

Държави с решение за адекватност (към март 2026)

• Пълна адекватност: Андора, Аржентина, Канада (PIPEDA), Фарьорски острови, Гернси, Израел, Остров Ман, Япония, Джърси, Нова Зеландия, Република Корея, Швейцария, Уругвай, Обединено кралство
• Секторна адекватност: САЩ — само за организации, сертифицирани по EU-US Data Privacy Framework (DPF)

EU-US Data Privacy Framework (DPF)

DPF е приет с Решение C(2023) 4745 на Комисията от 10 юли 2023 г. Той заменя отменения Privacy Shield след решението Schrems II (C-311/18). DPF се основава на Executive Order 14086, издадена от президента на САЩ, която въвежда ограничения за достъпа на разузнавателните служби и нов механизъм за правна защита (Data Protection Review Court).

За да проверите дали ваш американски доставчик е DPF-сертифициран, използвайте официалния Data Privacy Framework List.

Стандартни договорни клаузи — SCCs (чл. 46(2)(в))

Стандартните договорни клаузи са най-широко използваният механизъм за трансфер на лични данни извън ЕИП. Те представляват предварително одобрени от Комисията договорни разпоредби, които страните сключват, за да осигурят адекватно ниво на защита.

Актуалните SCCs — Решение 2021/914

На 4 юни 2021 г. Комисията прие нови модулни SCCs с Решение за изпълнение (ЕС) 2021/914, които заменят предишните версии. Новите SCCs имат модулна структура с четири модула:

1. Модул 1: Администратор → Администратор (C2C)

   Когато износителят и вносителят на данни са и двамата администратори. Например: българска компания споделя клиентски данни с партньор в Израел.

   Модул 1, Приложение към Решение 2021/914

2. Модул 2: Администратор → Обработващ (C2P)

   Най-често срещаният сценарий: българска компания (администратор) възлага обработка на подизпълнител в трета държава. Замества и функцията на договора за обработка по чл. 28.

   Модул 2, Приложение към Решение 2021/914

3. Модул 3: Обработващ → Подобработващ (P2P)

   Когато обработващ личните данни ангажира подобработващ в трета държава. Важен за IT аутсорсинг вериги.

   Модул 3, Приложение към Решение 2021/914

4. Модул 4: Обработващ → Администратор (P2C)

   По-рядък случай: обработващ в ЕИП връща данни на администратор в трета държава. Среща се при обратния поток от аутсорсинг.

   Модул 4, Приложение към Решение 2021/914

Задължителни стъпки при използване на SCCs

След решението Schrems II (C-311/18) на Съда на ЕС от 16 юли 2020 г., сключването на SCCs само по себе си не е достатъчно. Трябва да:

1. Изберете правилния модул (или комбинация от модули) според ролите на страните
2. Попълните приложенията — описание на трансфера, категории данни, получатели, технически мерки
3. Извършите Transfer Impact Assessment (TIA) — анализ на законодателството на държавата-получател
4. Приложите допълнителни мерки при необходимост — криптиране, псевдонимизация, договорни гаранции
5. Документирайте целия процес за accountability по чл. 5(2)

Задължителни корпоративни правила — BCRs (чл. 47)

BCRs (Binding Corporate Rules) са вътрешни политики за защита на данни, одобрени от надзорен орган, които позволяват трансфер в рамките на група предприятия или група от предприятия, извършващи съвместна стопанска дейност.

• Предимства: покриват всички трансфери в групата с един документ; гъвкавост; доказват корпоративен ангажимент
• Недостатъци: одобрението отнема 12–18 месеца; скъпо и сложно; подходящо само за големи мултинационални групи
• Процедура: подаване до водещ надзорен орган → становище на ЕКЗД → одобрение от всички засегнати органи

За повечето български компании BCRs не са практичен вариант. SCCs остават по-достъпната алтернатива.

Дерогации по чл. 49

Когато няма решение за адекватност и няма подходящи гаранции, чл. 49 допуска трансфер в ограничени случаи:

• Изрично съгласие — субектът е информиран за рисковете и изрично се е съгласил (чл. 49(1)(а))
• Изпълнение на договор — трансферът е необходим за изпълнение на договор между субекта и администратора (чл. 49(1)(б))
• Важен обществен интерес — признат в правото на Съюза или на държавата-членка (чл. 49(1)(г))
• Установяване, упражняване или защита на правни претенции (чл. 49(1)(д))
• Жизненоважни интереси — когато субектът е физически или правно неспособен да даде съгласие (чл. 49(1)(е))

България и IT аутсорсинг — типични сценарии за трансфер

България е един от водещите IT аутсорсинг хъбове в Европа с над 80 000 IT специалисти. Това създава уникални сценарии за международен трансфер на данни:

Типичен сценарий 1: Българска IT компания разработва софтуер за клиент от САЩ

• Американският клиент е администратор, българската компания е обработващ
• Данните се трансферират от САЩ към България (ЕИП) — няма ограничение по Глава V
• Но ако българската компания използва подизпълнител в Индия — Модул 3 (P2P) SCCs + TIA

Типичен сценарий 2: Българска компания използва облачни услуги (AWS, Azure, GCP)

• Ако дата центърът е в ЕИП (напр. Frankfurt, Ireland) — няма трансфер
• Ако доставчикът е DPF-сертифициран (Google, Microsoft, AWS) — покрит от решението за адекватност
• Ако има достъп от екип в трета държава за поддръжка — има трансфер, дори данните да са в ЕИП

Типичен сценарий 3: Български онлайн магазин с международни доставчици

• Платежен процесор (Stripe, PayPal) — обикновено DPF-сертифициран за US трансфер
• Email маркетинг (Mailchimp, Klaviyo) — проверете DPF статуса; ако няма — SCCs
• Аналитики (Google Analytics) — DPF-покрит, но препоръчително е и GA4 с EU-only data residency
• CRM (HubSpot, Salesforce) — проверете DPF + SCCs двоен подход

Transfer Impact Assessment — стъпка по стъпка

TIA (Оценка на въздействието при трансфер) е изискване, произтичащо от Schrems II и разяснено в Препоръки 01/2020 на ЕКЗД. Целта е да оцените дали законодателството на държавата-получател позволява ефективното прилагане на избрания механизъм за трансфер.

Стъпка по стъпка checklist

1. Картографирайте трансферите

   Идентифицирайте ВСИЧКИ потоци от данни извън ЕИП: кои данни, къде отиват, на кого, защо. Включете и непреки трансфери (подобработващи на вашия обработващ).

   Стъпка 1 — Препоръки ЕКЗД 01/2020

2. Определете механизма за трансфер

   За всеки трансфер определете: адекватност, SCCs, BCRs или дерогация. Ако няма решение за адекватност — SCCs са стандартният избор.

   Стъпка 2 — Препоръки ЕКЗД 01/2020

3. Оценете законодателството на третата държава

   Ключови въпроси: Има ли закони, позволяващи масово наблюдение? Има ли независим надзорен орган? Има ли ефективни правни средства за защита? Конкретно за САЩ — FISA 702, EO 12333, CLOUD Act.

   Стъпка 3 — Препоръки ЕКЗД 01/2020

4. Приложете допълнителни мерки (ако е необходимо)

   Технически: криптиране при транзит и в покой (ключът остава в ЕИП), псевдонимизация, split processing. Договорни: задължения за уведомяване при заявки от държавни органи, ангажимент за оспорване. Организационни: политики за достъп, обучение.

   Стъпка 4 — Препоръки ЕКЗД 01/2020

5. Документирайте и преразглеждайте периодично

   Съхранявайте TIA документацията като част от вашия GDPR одит. Преразглеждайте при промяна на законодателството, при нов доставчик или при промяна на вида данни. Минимум — веднъж годишно.

   Стъпка 5 + чл. 5(2) GDPR accountability

Финален TIA checklist

• Идентифицирани са всички потоци от данни извън ЕИП
• За всеки поток е определен механизъм за трансфер
• Законодателството на държавата-получател е анализирано
• Оценен е рискът от достъп на държавни органи
• Определено е дали защитата е „по същество еквивалентна" на ЕИП
• Допълнителни технически мерки са идентифицирани и приложени
• Допълнителни договорни мерки са включени в SCCs (Приложение II)
• Организационни мерки са документирани
• Определена е дата за следващ преглед
• TIA е одобрена от DPO / юридически отдел

Великобритания след Brexit

На 28 юни 2021 г. Комисията прие решение за адекватност за Обединеното кралство (Решение C(2021) 4800), което позволява свободен трансфер на данни от ЕИП към Великобритания.

• Срок: решението съдържа „sunset clause" с първоначален срок от 4 години — до юни 2025 г., с автоматично подновяване. Към март 2026 г. решението е все още в сила.
• Рискове: бъдещи промени в UK Data Protection Act (реформата чрез Data Protection and Digital Information Act) могат да подкопаят адекватността
• UK International Data Transfer Agreement (IDTA): UK има собствени SCCs (IDTA), одобрени от ICO, за трансфери ОТ Великобритания към трети държави
• UK Extension to EU SCCs: като алтернатива на IDTA, UK признава и EU SCCs с UK Addendum

Не забравяйте: при нарушение на сигурността на данни, трансферирани извън ЕИП, задължението за уведомяване на КЗЛД в 72 часа по чл. 33 остава изцяло ваша отговорност като администратор — независимо къде се е случил инцидентът.

Адв. Десислава Димитрова & Адв. Йордан Чолаков

Dimitrova, Cholakov & Partners · Innovires

Адв. Димитрова е CIPP/E сертифициран специалист по защита на лични данни с дългогодишен опит в правото на ЕС. Адв. Чолаков е експерт по GDPR съответствие, международни трансфери на данни и whistleblowing. Заедно консултират над 90 компании за пълно GDPR съответствие.