GDPR при облачни услуги (SaaS) — отговорности и договори
Кратък отговор: Когато използвате облачна услуга (SaaS), Вашата организация е администратор на личните данни, а доставчикът на услугата е обработващ по смисъла на GDPR. Задължени сте да сключите договор за обработване на данни (DPA) по чл. 28 GDPR, да контролирате подизпълнителите (sub-processors) и да осигурите законен механизъм за международен трансфер, ако доставчикът е извън ЕИП. Липсата на DPA е самостоятелно нарушение с глоба до 10 млн. евро — дори ако никога не е имало теч.
Съдържание
- Кой е администратор и кой е обработващ при SaaS?
- Какво трябва да съдържа DPA по чл. 28 GDPR?
- Кой отговаря за подизпълнителите (sub-processors)?
- Как се уреждат трансферите към AWS, Google и Azure?
- Какви мерки за сигурност изисква чл. 32 GDPR?
- Какво казва EDPB за облачните услуги?
- Практически контролен списък за IT компании
- Кои са най-честите грешки при облачни услуги?
- Често задавани въпроси
Облачните услуги — SaaS (софтуер като услуга), IaaS (инфраструктура като услуга), PaaS (платформа като услуга) се използват от почти всеки бизнес днес. От Google Workspace и Microsoft 365 до специализирани CRM системи, счетоводен софтуер и платформи за електронна търговия — почти всяка компания в България използва поне няколко облачни услуги, които обработват лични данни. Въпреки това много организации подценяват задълженията си по GDPR при работа с тези услуги по GDPR при използване на тези услуги.
Кой е администратор и кой е обработващ при SaaS?
Директен отговор: При SaaS Вашата организация е администратор — Вие определяте целите и средствата на обработването. Доставчикът обработва данните само по Ваши документирани инструкции и затова е обработващ. Ако използва данните и за собствени цели, например за аналитика или машинно обучение, той става съвместен администратор и е нужно споразумение по чл. 26 GDPR.
Преди подписване на договор трябва да определите дали Вие сте администратор, доставчикът — обработващ, или двамата сте съвместни администратори. EDPB насоки 07/2020 за понятията „администратор" и „обработващ" дават ясна рамка:
| Роля | Кой е | Какво определя | Пример |
|---|---|---|---|
| Администратор | Вашата организация (клиентът) | Целите и средствата на обработването | Вие решавате какви данни на служители/клиенти да съхранявате в CRM |
| Обработващ | SaaS доставчикът | Обработва данни само по Ваши инструкции | CRM платформата съхранява и обработва данните от Ваше име |
| Съвместен администратор | SaaS доставчик, който определя и собствени цели | И двете страни определят цели и средства | Платформа, която анализира Вашите данни за собствени рекламни цели |
Внимание: Някои SaaS доставчици могат да действат като съвместни администратори (joint controllers), ако използват данните Ви за собствени цели — например за подобряване на алгоритми чрез машинно обучение или за агрегирана аналитика. В такъв случай е необходимо споразумение за съвместно администриране по чл. 26 GDPR, а не само DPA. Проверете внимателно условията за ползване на всеки доставчик.
Какво трябва да съдържа DPA по чл. 28 GDPR?
Директен отговор: Чл. 28(3) GDPR изброява осем задължителни клаузи: обработване само по документирани инструкции, поверителност на персонала, мерки за сигурност по чл. 32, управление на подизпълнителите, съдействие при искания на субектите, съдействие при теч и DPIA, изтриване или връщане на данните при прекратяване и допускане на одити. Непълен DPA КЗЛД приема за равностоен на липсващ.
Чл. 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)?
Директен отговор: Чл. 28(2) GDPR допуска подизпълнител само с предварително разрешение — специфично, поименно, или общо. При общото разрешение доставчикът поддържа публичен списък, уведомява предварително за всеки нов подизпълнител, дава Ви право на възражение и сключва огледален DPA. По EDPB Opinion 22/2024 Вие сте длъжни да верифицирате това, а не само да подпишете.
Всеки голям 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?
Директен отговор: Глава V на GDPR (чл. 44-49) изисква подходящи гаранции при предаване на данни извън ЕИП. За американските доставчици механизмите са три: EU-US Data Privacy Framework (в сила от юли 2023 г., само за вписани компании), стандартни договорни клаузи по Решение 2021/914 заедно с TIA, и обвързващи корпоративни правила за вътрешногрупови трансфери.
Повечето облачни услуги, които ползват българските фирми, идват от американски компании. Глава 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"
- Документирайте проверката с дата и екранна снимка в ROPA
Риск от ново Schrems решение: EU-US Data Privacy Framework е обект на съдебно оспорване от NOYB и други организации. Ако Съдът на ЕС отмени DPF (както стана със Safe Harbor и Privacy Shield), организациите, които разчитат единствено на него, ще останат без правно основание за трансфер. Затова EDPB препоръчва SCCs като резервен механизъм, дори когато DPF е приложим.
Големите трима доставчици на облачни услуги от САЩ — 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 задължава и администратора, и обработващия да прилагат подходящи технически и организационни мерки. При облачните услуги отговорността е споделена: доставчикът отговаря за физическата сигурност на дата центъра, криптирането и инфраструктурните резервни копия, а Вие — за конфигурацията на достъпа, налагането на 2FA, мониторинга на логовете и обучението на персонала.
Чл. 32 GDPR изисква и администраторът, и обработващият да прилагат „подходящи технически и организационни мерки". При облачни услуги отговорността е споделена — моделът на „споделена отговорност" (shared responsibility model) е стандарт при AWS, Google и Azure:
| Мярка | Отговорност на доставчика | Ваша отговорност |
|---|---|---|
| Физическа сигурност на дата центъра | Да | Не |
| Криптиране при пренос (TLS) | Да | Проверете настройките |
| Криптиране при съхранение (at rest) | Да (обикновено по подразбиране) | Активирайте customer-managed keys, ако е възможно |
| Управление на достъпа (IAM) | Предоставя инструменти | Вие конфигурирате роли и права |
| Двуфакторно удостоверяване (2FA/MFA) | Предоставя опция | Вие активирате и налагате |
| Резервни копия (backups) | Инфраструктурни резервни копия | Конфигурация + тестване на възстановяване |
| Логове за достъп (одитни журнали) | Генерира логове | Вие мониторирате и анализирате |
| Обучение на персонала | Не | Да — Ваш служител с достъп трябва да е обучен |
Практически съвет: При проверка КЗЛД ще Ви попита какви мерки за сигурност прилагате. „Използваме Google" не е достатъчен отговор. Трябва да можете да посочите конкретно: какво криптиране, какъв контрол на достъпа, какви логове и как ги мониторирате. Документирайте тези мерки в ROPA.
Какво казва EDPB за облачните услуги?
Директен отговор: През януари 2023 г. EDPB публикува резултатите от координирана проверка на облачни услуги в публичния сектор. Основните констатации са липсващи или непълни DPA, липса на контрол над подизпълнителите, неизвършен Transfer Impact Assessment, неупражнени одитни права и неясно разпределение на отговорностите. Изводите важат и за частните компании.
През януари 2023 г. EDPB публикува резултатите от координирана проверка на облачни услуги в публичния сектор. Изводите важат и за частните компании:
Ключови констатации на EDPB (2023)
- Повечето организации нямат адекватни DPA — или няма DPA изобщо, или съществуващите не покриват всички изисквания на чл. 28(3)
- Липса на контрол над подизпълнителите — организациите не следят списъците на подизпълнители и не упражняват правото си на възражение
- Недостатъчна оценка на международните трансфери — не се извършва Transfer Impact Assessment при трансфер към трети държави
- Неупражнени одитни права — DPA предвижда одит, но организациите никога не го упражняват
- Неясно разпределение на отговорностите — организациите не знаят кои мерки са тяхна отговорност и кои на доставчика
EU Cloud Code of Conduct (одобрен от белгийския надзорен орган през май 2021 г.)
EDPB одобри браншови Code of Conduct, който уеднаквява как облачните доставчици доказват съответствие с GDPR. Доставчици, които се присъединят, се задължават да:
- Поддържат прозрачен списък на подизпълнители с механизъм за уведомяване
- Осигурят възможност за избор на EU/EEA data residency
- Предоставят стандартизиран DPA, покриващ всички изисквания на чл. 28
- Преминават независим одит за съответствие
Съвет: При избор на нов SaaS доставчик проверете дали е присъединен към EU Cloud Code of Conduct или CISPE Code of Conduct (за IaaS). Това е силен индикатор за GDPR зрялост.
Практически контролен списък за 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 го замества. След тях идват игнорирането на подизпълнителската верига, липсата на TIA при трансфер към САЩ, разчитането само на DPF без SCCs като резервен механизъм, недокументираните мерки за сигурност, непосочените трансфери в ROPA и неактивираното 2FA за администраторските акаунти.
- ✗ Използване на SaaS без проверка дали доставчикът има DPA
- ✗ Приемане, че NDA е достатъчен заместител на DPA (не е — GDPR изисква DPA отделно)
- ✗ Игнориране на подизпълнителската верига — „не знам кой друг има достъп"
- ✗ Липса на TIA при трансфер към САЩ (дори при DPF)
- ✗ Разчитане единствено на DPF без SCCs като резервен механизъм
- ✗ Липса на документация за мерките за сигурност — „облачно е, значи е сигурно"
- ✗ Непосочване на трансфери извън ЕИП в ROPA
- ✗ Използване на безплатни (free-tier) SaaS услуги за бизнес данни без преглед на условията
- ✗ Неактивиране на 2FA за администраторски акаунти
- ✓ Прегледайте и активирайте DPA при всеки доставчик (повечето го предлагат онлайн)
- ✓ Абонирайте се за уведомления за подизпълнители
- ✓ Документирайте всеки трансфер в ROPA с посочване на правните гаранции
- ✓ Поддържайте SCCs като резервен механизъм за US доставчици
- ✓ Конфигурирайте EU data residency, когато е налична
- ✓ Активирайте MFA + криптиране + одитни журнали
Одит на Вашите облачни услуги за GDPR съответствие
- Пълен преглед на DPA с всички SaaS доставчици
- Оценка на международните трансфери и подизпълнителите
- Препоръки за мерки за сигурност и конфигурация
- Актуализация на ROPA с всички облачни услуги
Какво важи при доставчик от ЕС, аутсорсинг и multi-cloud?
Директен отговор: Когато доставчикът е в ЕИП, отпада механизмът за международен трансфер, но DPA по чл. 28 остава задължителен. Ако сами предлагате SaaS или IT услуги, Вие сте обработващият и носите отговорност за вреди по чл. 82 GDPR. При multi-cloud всеки доставчик е отделен обработващ с отделен DPA.
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/IEC 27001:2022, 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 за международни трансфери
- Подготовка за проверка от КЗЛД
Статията е актуализирана на 15 август 2026 г. (редакционна актуализация); правната рамка е проверена към 26 март 2026 г. Информацията е с информативен характер и не представлява правна консултация. Статусът на EU-US Data Privacy Framework и конкретните DPA на доставчиците могат да се променят. За конкретни въпроси относно Вашата организация се обърнете към квалифициран специалист по защита на личните данни.
Получавайте нови статии директно в пощата си
Практически анализи по GDPR и киберсигурност. Без спам.
Можете да се отпишете по всяко време. Политика за поверителност
Адв. Димитрова е CIPP/E сертифициран специалист по защита на лични данни с дългогодишен опит в правото на ЕС. Адв. Чолаков е експерт по GDPR съответствие, международни трансфери на данни и whistleblowing. Заедно консултират над 90 компании за пълно GDPR съответствие.