GDPR при облачни услуги (SaaS) — отговорности и договори
Кратък отговор: Когато използвате облачна услуга (SaaS), Вашата организация е администратор на личните данни, а доставчикът на услугата е обработващ по смисъла на GDPR. Задължени сте да сключите договор за обработване на данни (DPA) по чл. 28 GDPR, да контролирате подизпълнителите (sub-processors) и да осигурите законен механизъм за международен трансфер, ако доставчикът е извън ЕИП. Липсата на DPA е самостоятелно нарушение с глоба до 10 млн. евро — дори ако никога не е имало теч.
Съдържание
- Кой е администратор и кой е обработващ при SaaS
- Задължителен DPA по чл. 28 — какво трябва да съдържа
- Подизпълнители (sub-processors) — веригата на отговорност
- Международни трансфери — AWS, Google, Azure и DPF
- Мерки за сигурност по чл. 32 GDPR
- Насоки на EDPB за облачни услуги
- Практически checklist за IT компании
- Най-честите грешки при облачни услуги
- Често задавани въпроси
Облачните услуги (SaaS, IaaS, PaaS) са неизменна част от бизнеса на всяка съвременна организация. От Google Workspace и Microsoft 365 до специализирани CRM системи, счетоводен софтуер и платформи за електронна търговия — почти всяка компания в България използва поне няколко облачни услуги, които обработват лични данни. Въпреки това огромен брой организации не са наясно с отговорностите си по GDPR при използване на тези услуги. В тази статия разглеждаме какви задължения имате, как да ги изпълните и какви грешки да избегнете.
Кой е администратор и кой е обработващ при SaaS
Правилното определяне на ролите е първата стъпка за спазване на GDPR при облачни услуги. EDPB насоки 07/2020 за понятията „администратор" и „обработващ" дават ясна рамка:
| Роля | Кой е | Какво определя | Пример |
|---|---|---|---|
| Администратор | Вашата организация (клиентът) | Целите и средствата на обработването | Вие решавате какви данни на служители/клиенти да съхранявате в CRM |
| Обработващ | SaaS доставчикът | Обработва данни само по Ваши инструкции | CRM платформата съхранява и обработва данните от Ваше име |
| Съвместен администратор | SaaS доставчик, който определя и собствени цели | И двете страни определят цели и средства | Платформа, която анализира Вашите данни за собствени рекламни цели |
Внимание: Някои SaaS доставчици могат да действат като съвместни администратори (joint controllers), ако използват данните Ви за собствени цели — например за подобряване на алгоритми чрез машинно обучение или за агрегирана аналитика. В такъв случай е необходимо споразумение за съвместно администриране по чл. 26 GDPR, а не само DPA. Проверете внимателно условията за ползване на всеки доставчик.
Задължителен DPA по чл. 28 — какво трябва да съдържа
Чл. 28(3) GDPR изброява осем задължителни елемента, които трябва да присъстват във всеки договор за обработване на данни (DPA) между администратор и обработващ. Без тях DPA е непълен и може да бъде третиран като липсващ при проверка от КЗЛД.
| № | Задължителна клауза | Какво означава на практика |
|---|---|---|
| 1 | Обработка само по документирани инструкции | SaaS доставчикът няма право да обработва данни за собствени цели. Инструкциите Ви трябва да са писмени (вкл. електронни). |
| 2 | Поверителност на персонала | Служителите на доставчика, които имат достъп до данни, трябва да са обвързани със задължение за поверителност. |
| 3 | Подходящи мерки за сигурност (чл. 32) | Криптиране, контрол на достъпа, резервни копия, тестове за уязвимости. Конкретните мерки трябва да са описани в DPA. |
| 4 | Управление на подизпълнители | Предварително разрешение (специфично или общо) за привличане на подизпълнители. При общо: уведомяване + право на възражение. |
| 5 | Съдействие при искания на субектите | Доставчикът трябва да Ви помага да отговаряте на искания за достъп, коригиране, изтриване (чл. 15-22 GDPR). |
| 6 | Съдействие при сигурност, уведомяване, DPIA | Доставчикът трябва да Ви уведоми за теч незабавно и да помогне при оценка на въздействието. |
| 7 | Изтриване или връщане на данни при прекратяване | След прекратяване на договора доставчикът трябва да изтрие или върне ВСИЧКИ лични данни — по Ваш избор. |
| 8 | Одит и инспекции | Доставчикът трябва да предостави цялата информация за доказване на съответствие и да допусне одити. |
Стандартните DPA на големите доставчици. Google, Microsoft, AWS и повечето големи SaaS платформи предоставят готови DPA, които обикновено покриват минималните изисквания на чл. 28. Проблемите възникват при: (1) по-малки доставчици, които нямат DPA или предлагат непълни такива; (2) условия, които позволяват на доставчика да използва данни за собствени цели (аналитика, ML); (3) липса на ясна процедура за уведомяване при теч.
Нуждаете се от преглед на DPA с Вашите облачни доставчици?
- Одит на текущите DPA за съответствие с чл. 28 GDPR
- Изготвяне на DPA за доставчици, които нямат такъв
- Преглед на подизпълнителската верига и международните трансфери
Подизпълнители (sub-processors) — веригата на отговорност
Повечето SaaS доставчици не работят сами — те използват собствени подизпълнители за хостинг, CDN, бекъп, поддръжка и други функции. Чл. 28(2) GDPR регламентира тази верига:
Два режима на разрешаване
| Режим | Как работи | В практиката |
|---|---|---|
| Специфично разрешение | Администраторът одобрява всеки подизпълнител поименно | Рядко при SaaS — доставчиците обикновено не приемат |
| Общо разрешение | Администраторът разрешава принципно + доставчикът уведомява за промени + право на възражение | Стандартният модел при Google, Microsoft, AWS |
При общо разрешение доставчикът е длъжен да:
- Поддържа публичен списък на подизпълнителите (повечето големи доставчици го правят)
- Уведоми Ви предварително при добавяне на нов подизпълнител
- Ви предостави право на възражение — и ако възразите, да Ви даде възможност да прекратите услугата
- Сключи DPA с подизпълнителя, който огледално отразява задълженията от основния DPA
EDPB Opinion 22/2024: Администраторът носи задължение да верифицира, че обработващият реално спазва задълженията си към подизпълнителите. Не е достатъчно просто да подпишете DPA и да „забравите". Периодичните проверки (поне веднъж годишно) са част от принципа за отчетност по чл. 5(2) GDPR.
Практически пример: верига на подизпълнителите на Google Workspace
Сценарий: Българско дружество използва Google Workspace
Администратор: Вашето дружество
Обработващ: Google Ireland Limited (ЕИП)
Подизпълнители: Google LLC (САЩ) + десетки инфраструктурни доставчици в различни държави
Какво трябва да направите:
- Активирайте и приемете DPA от конзолата на Google Admin (Settings → Legal → Data Processing Amendment)
- Проверете подизпълнителите на публичната страница на Google
- Абонирайте се за уведомления при промяна на подизпълнители
- Проверете статуса на Google LLC в EU-US Data Privacy Framework
- Документирайте в ROPA трансфера към САЩ и приложимите гаранции
Международни трансфери — AWS, Google, Azure и DPF
Голяма част от облачните услуги, използвани в България, се предоставят от компании със седалище в САЩ. Глава V на GDPR (чл. 44-49) изисква подходящи гаранции при предаване на лични данни извън Европейското икономическо пространство (ЕИП).
Три основни механизма за трансфер към САЩ
| Механизъм | Статус (2026) | Приложимост |
|---|---|---|
| EU-US Data Privacy Framework (DPF) | В сила от юли 2023 г. (решение за адекватност на ЕК) | Само за US компании, вписани в списъка на dataprivacyframework.gov |
| Стандартни договорни клаузи (SCCs) | Винаги приложими (Решение 2021/914 на ЕК) | За всички трети държави; изискват TIA (Transfer Impact Assessment) |
| Обвързващи корпоративни правила (BCRs) | Одобрени от надзорен орган | За вътрешногрупови трансфери в многонационални компании |
Проверка на DPF статус — стъпка по стъпка
- Посетете dataprivacyframework.gov/s/participant-search
- Потърсете доставчика по име (напр. „Google LLC", „Amazon.com, Inc.", „Microsoft Corporation")
- Проверете статуса: трябва да е „Active"
- Проверете обхвата на сертификацията: „HR data" и/или „Non-HR data"
- Документирайте проверката с дата и screenshot в ROPA
Риск от ново Schrems решение: EU-US Data Privacy Framework е обект на съдебно оспорване от NOYB и други организации. Ако Съдът на ЕС отмени DPF (както стана със Safe Harbor и Privacy Shield), организациите, които разчитат единствено на него, ще останат без правно основание за трансфер. Затова EDPB препоръчва SCCs като резервен механизъм, дори когато DPF е приложим.
Големите трима US cloud доставчици — GDPR статус
| Доставчик | DPF статус | DPA | SCCs | EU Data Residency |
|---|---|---|---|---|
| Google Cloud / Workspace | Active (Google LLC) | Да, в Admin Console | Включени в DPA | Да, EU region selection |
| Microsoft Azure / 365 | Active (Microsoft Corp.) | Да, DPA + Product Terms | Включени автоматично | Да, EU Data Boundary (2023+) |
| AWS (Amazon) | Active (Amazon.com, Inc.) | Да, AWS GDPR DPA | Включени в DPA | Да, EU region (Frankfurt, Ireland, Stockholm) |
Мерки за сигурност по чл. 32 GDPR
Чл. 32 GDPR изисква и администраторът, и обработващият да прилагат „подходящи технически и организационни мерки". При облачни услуги отговорността е споделена — моделът на „споделена отговорност" (shared responsibility model) е стандарт при AWS, Google и Azure:
| Мярка | Отговорност на доставчика | Ваша отговорност |
|---|---|---|
| Физическа сигурност на дата центъра | Да | Не |
| Криптиране при пренос (TLS) | Да | Проверете настройките |
| Криптиране при съхранение (at rest) | Да (обикновено по подразбиране) | Активирайте customer-managed keys, ако е възможно |
| Управление на достъпа (IAM) | Предоставя инструменти | Вие конфигурирате роли и права |
| Двуфакторна автентикация (2FA/MFA) | Предоставя опция | Вие активирате и налагате |
| Резервни копия (backups) | Инфраструктурни бекъпи | Конфигурация + тестване на възстановяване |
| Логове за достъп (audit logs) | Генерира логове | Вие мониторирате и анализирате |
| Обучение на персонала | Не | Да — Ваш служител с достъп трябва да е обучен |
Практически съвет: При проверка КЗЛД ще Ви попита какви мерки за сигурност прилагате. „Използваме Google" не е достатъчен отговор. Трябва да можете да посочите конкретно: какво криптиране, какъв контрол на достъпа, какви логове и как ги мониторирате. Документирайте тези мерки в ROPA.
Насоки на EDPB за облачни услуги
През януари 2023 г. EDPB публикува доклад от координирана проверка на използването на облачни услуги в публичния сектор. Констатациите са приложими и за частния сектор:
Ключови констатации на EDPB (2023)
- Повечето организации нямат адекватни DPA — или няма DPA изобщо, или съществуващите не покриват всички изисквания на чл. 28(3)
- Липса на контрол над подизпълнителите — организациите не следят списъците на подизпълнители и не упражняват правото си на възражение
- Недостатъчна оценка на международните трансфери — не се извършва Transfer Impact Assessment при трансфер към трети държави
- Нереални одитни права — DPA предвижда одит, но организациите никога не го упражняват
- Неясно разпределение на отговорностите — организациите не знаят кои мерки са тяхна отговорност и кои на доставчика
EU Cloud Code of Conduct (2024)
EDPB одобри Code of Conduct за облачни доставчици, който предлага стандартизирана рамка за GDPR съответствие. Доставчици, които се присъединят, се задължават да:
- Поддържат прозрачен списък на подизпълнители с механизъм за уведомяване
- Осигурят възможност за избор на EU/EEA data residency
- Предоставят стандартизиран DPA, покриващ всички изисквания на чл. 28
- Минат независим одит за съответствие
Съвет: При избор на нов SaaS доставчик проверете дали е присъединен към EU Cloud Code of Conduct или CISPE Code of Conduct (за IaaS). Това е силен индикатор за GDPR зрялост.
Практически checklist за IT компании
По-долу представяме стъпките, които всяка организация трябва да следва при въвеждане на нова облачна услуга или при преглед на съществуващите:
Преди започване на използване
- ✓ Определете ролите: администратор ли сте или обработващ (или и двете)
- ✓ Проверете дали доставчикът предлага DPA, покриващ всички 8 елемента на чл. 28(3)
- ✓ Установете къде физически се съхраняват данните (EU/US/друга държава)
- ✓ Проверете DPF статуса на US доставчици на dataprivacyframework.gov
- ✓ Прегледайте списъка на подизпълнители и абонирайте се за уведомления
- ✓ Извършете Transfer Impact Assessment (TIA), ако данните напускат ЕИП
- ✓ Оценете дали е необходима DPIA (чл. 35 GDPR)
- ✓ Документирайте услугата в ROPA
По време на използване
- ✓ Активирайте 2FA/MFA за всички потребители с достъп до лични данни
- ✓ Конфигурирайте минимални права за достъп (principle of least privilege)
- ✓ Мониторирайте логовете за достъп (поне веднъж месечно)
- ✓ Следете уведомленията за промяна на подизпълнители
- ✓ Извършвайте годишен преглед на DPA и мерките за сигурност
- ✓ Тествайте процедурата за възстановяване от бекъп
При прекратяване на услугата
- ✓ Експортирайте всички лични данни преди прекратяване
- ✓ Изискайте писмено потвърждение за изтриване на данните от доставчика
- ✓ Проверете че подизпълнителите също са изтрили данните
- ✓ Актуализирайте ROPA
Най-честите грешки при облачни услуги
- ✗ Използване на SaaS без проверка дали доставчикът има DPA
- ✗ Приемане, че NDA е достатъчен заместител на DPA (не е — GDPR изисква DPA отделно)
- ✗ Игнориране на подизпълнителската верига — „не знам кой друг има достъп"
- ✗ Липса на TIA при трансфер към САЩ (дори при DPF)
- ✗ Разчитане единствено на DPF без SCCs като резервен механизъм
- ✗ Липса на документация за мерките за сигурност — „облачно е, значи е сигурно"
- ✗ Непосочване на трансфери извън ЕИП в ROPA
- ✗ Използване на безплатни (free-tier) SaaS услуги за бизнес данни без преглед на условията
- ✗ Неактивиране на 2FA за администраторски акаунти
- ✓ Прегледайте и активирайте DPA при всеки доставчик (повечето го предлагат онлайн)
- ✓ Абонирайте се за уведомления за подизпълнители
- ✓ Документирайте всеки трансфер в ROPA с посочване на правните гаранции
- ✓ Поддържайте SCCs като резервен механизъм за US доставчици
- ✓ Конфигурирайте EU data residency, когато е налична
- ✓ Активирайте MFA + криптиране + audit logs
Одит на Вашите облачни услуги за GDPR съответствие
- Пълен преглед на DPA с всички SaaS доставчици
- Оценка на международните трансфери и подизпълнителите
- Препоръки за мерки за сигурност и конфигурация
- Актуализация на ROPA с всички облачни услуги
Специални случаи
SaaS доставчик от България или ЕС
Когато доставчикът е в ЕИП, отпада необходимостта от механизъм за международен трансфер. DPA по чл. 28 обаче е все така задължителен — местоположението не освобождава от задължението за договор с обработващия.
Когато Вашата компания е обработващ (IT аутсорсинг)
Ако предлагате SaaS или IT услуги на клиенти, Вие сте обработващият. В този случай трябва да:
- Предложите DPA на клиентите си, покриващ чл. 28(3)
- Поддържате регистър на обработващия по чл. 30(2)
- Получите разрешение от клиента (администратора) за всеки подизпълнител
- Уведомявате клиента незабавно при теч на данни
- Помните, че по чл. 82 GDPR и обработващият носи отговорност за вреди
Multi-cloud и хибридни среди
При използване на множество облачни доставчици (multi-cloud) или хибридна среда (on-premise + cloud) всеки доставчик е отделен обработващ с отделен DPA. Потоците от данни между доставчиците трябва да са картографирани и документирани в ROPA.
Често задавани въпроси
Кой е администратор и кой е обработващ при използване на SaaS?
Вашата организация е администраторът — Вие определяте какви данни да се обработват и за какви цели. SaaS доставчикът е обработващ — той обработва данните по Ваши инструкции. Ако обаче доставчикът използва данните Ви за собствени цели (напр. аналитика, ML), може да се окаже съвместен администратор по чл. 26 GDPR.
Какъв договор трябва да имам с доставчика на облачна услуга?
Задължителен е договор за обработване на данни (DPA) по чл. 28 GDPR. Той трябва да съдържа 8 задължителни елемента: инструкции, поверителност, сигурност, подизпълнители, права на субектите, съдействие при инциденти, изтриване при прекратяване и одитни права. NDA или стандартен търговски договор НЕ замества DPA.
Какво да правя, ако SaaS доставчикът ми е извън ЕС?
Трябва да осигурите законен механизъм за международен трансфер по Глава V GDPR. За US доставчици най-лесно е да проверите дали са вписани в EU-US Data Privacy Framework (dataprivacyframework.gov). Ако не са — необходими са Стандартни договорни клаузи (SCCs) + Transfer Impact Assessment. И при DPF се препоръчват SCCs като резервен механизъм.
Какви са рисковете при подизпълнители (sub-processors) на SaaS?
Всеки подизпълнител е допълнително звено, което може да доведе до теч на данни или неоторизиран достъп. Вие носите отговорност за верификацията на цялата верига. Рисковете включват: подизпълнители в трети държави без адекватни гаранции, липса на DPA между обработващия и подизпълнителя, и промяна на подизпълнители без Вашето знание.
Кой носи отговорност при теч на данни от облачна услуга?
По чл. 82 GDPR и администраторът, и обработващият носят отговорност за вреди. Администраторът е отговорен, ако не е избрал доставчик с достатъчни гаранции или не е осигурил DPA. Обработващият е отговорен, ако е нарушил инструкциите или собствените си задължения. Субектът на данни може да предяви иск срещу всеки от тях.
Мога ли да използвам Google Workspace/Microsoft 365 в съответствие с GDPR?
Да, при правилна конфигурация. И двете платформи предлагат DPA, са вписани в DPF, включват SCCs и предоставят EU data residency опции. Трябва обаче да: (1) активирате DPA; (2) конфигурирате EU data region; (3) активирате 2FA; (4) ограничите достъпа по принципа на минималните права; (5) документирате всичко в ROPA.
Какви мерки за сигурност трябва да изисквам от облачния доставчик?
Минимум: криптиране при пренос (TLS) и при съхранение (AES-256), контрол на достъпа с MFA, логове за одит, редовни тестове за уязвимости, физическа сигурност на дата центровете, уведомяване при инцидент в рамките на 24-72 часа. Проверете и наличието на сертификации: ISO 27001, SOC 2 Type II, CSA STAR.
Как да проверя дали SaaS доставчикът е сертифициран по EU-US DPF?
Посетете dataprivacyframework.gov/s/participant-search и потърсете компанията по име. Статусът трябва да е „Active". Проверете и обхвата — дали покрива „HR data" и/или „Non-HR data" в зависимост от Вашите нужди. Документирайте проверката с дата за целите на отчетността.
Комплексна GDPR консултация за IT компании
- Одит на облачни услуги и DPA
- Изготвяне на ROPA за IT и SaaS бизнес
- Transfer Impact Assessment за международни трансфери
- Подготовка за проверка от КЗЛД
Тази статия отразява правното положение към 26 март 2026 г. Информацията е с информативен характер и не представлява правна консултация. Статусът на EU-US Data Privacy Framework и конкретните DPA на доставчиците могат да се променят. За конкретни въпроси относно Вашата организация се обърнете към квалифициран специалист по защита на личните данни.
Получавайте нови статии директно в пощата си
Практически анализи по GDPR и киберсигурност. Без спам.
Можете да се отпишете по всяко време. Политика за поверителност
Адв. Димитрова е CIPP/E сертифициран специалист по защита на лични данни с дългогодишен опит в правото на ЕС. Адв. Чолаков е експерт по GDPR съответствие, международни трансфери на данни и whistleblowing. Заедно консултират над 90 компании за пълно GDPR съответствие.