GDPR · чл. 28 · Договор за обработка

DPA за България: осемте задължителни клаузи, българската специфика и червените флагове в договори от чужди доставчици

Не общ преглед на чл. 28 от GDPR. Подробен наръчник за български юристи, ДЛЗД и хора от procurement, които ежеседмично четат, договарят и подписват Data Processing Agreement-и - и трябва да знаят кои клаузи са задължителни, кои са „меки" в практиката на КЗЛД, и кои конкретни формулировки в стандартните DPA на AWS, Microsoft, Google, Stripe, Salesforce, HubSpot и Slack се отклоняват от българската регулаторна реалност.

Най-важното накратко

• Чл. 28, ал. 3 от GDPR изисква осем задължителни клаузи във всеки писмен договор между администратор и обработващ. Липсата дори на една от тях е самостоятелно нарушение, независимо дали е имало пробив на лични данни
• В 5 от 7 анонимизирани наказателни постановления на КЗЛД през последните 24 месеца основната или утежняваща причина за санкцията беше липса на DPA с поне един ключов доставчик (имейл маркетинг, облачен хостинг, счетоводен софтуер, CRM, маркетингова платформа)
• Българската специфика, която НЕ е изрично писана в GDPR, но е практика на КЗЛД: езикът на договора (български или двуезичен с превод при поискване), българската юрисдикция като алтернатива при спор от субект, 72-часовият срок за уведомление на КЗЛД започва от момента, в който администраторът узнае, не когато обработващият го уведоми, и срокът за уведомление от обработващ към администратор не може да бъде по-дълъг от 24 часа на практика
• Стандартните DPA на големите облачни доставчици (AWS, Microsoft, Google, Stripe, Salesforce) имат три структурни проблема от гледна точка на български администратор: ограничено право на одит (само писмен въпросник веднъж годишно), уведомление за нови sub-processor-и без задължение за съгласие, и юрисдикция в Ирландия или Делауеър без алтернативна защита за български субект на данни
• Готов шаблон с осемте клаузи плюс пет приложения (sub-processor inventory, технически и организационни мерки, инцидентен протокол, шаблон за уведомление, exit процедура) намалява времето за подготовка на нов DPA от 8-15 часа правна работа до 1-2 часа само за персонализация. Цена на правна помощ за DPA от 0 до готов: 850 до 2 800 лв. на договор, или 4 800 лв. за пакет от 8 шаблона за компанията
• Червените флагове в DPA от чужди доставчици са разпознаваеми с 15-минутен преглед: липса на конкретен срок за уведомяване при инцидент (вместо това „без неоправдано забавяне"), pooled audit без право на индивидуален одит, uncapped liability waiver от страна на обработващия, sub-processor списък във вид „виж страницата ни в интернет" без задължение за уведомяване при промяна, и липса на cryptographic erasure attestation в exit клаузата

Чл. 28, ал. 3 от GDPR е базовата нормативна точка. Изисква писмен договор (включително електронен) между администратор и обработващ, който съдържа осем конкретни елемента. Тези осем елемента са задължителни за валидност на договора - тяхното отсъствие или неконкретност означава, че договорът не покрива изискването на чл. 28 GDPR, дори ако между страните има подписан документ.

Във всичките 30+ DPA, които сме преглеждали в последните 24 месеца, грешките не са в самото изброяване, а в конкретността. Доставчиците често цитират изискването на чл. 28 със собствените думи на регламента („обработващият спазва принципите на GDPR") вместо да дадат конкретно действие (например „обработващият уведомява администратора за всеки нов sub-processor поне 30 дни предварително"). Конкретността е тестът, който инспектор на КЗЛД ще приложи при проверка.

1.1. Клауза за документирани указания (буква а)

Тази клауза изисква обработващият да обработва лични данни само по документирани указания на администратора, включително относно трансфер на лични данни към трета държава или международна организация. Конкретното на практика: обработващият няма право самостоятелно да решава какво да прави с данните - например да ги използва за подобряване на собствените си алгоритми, за маркетинг към свои клиенти, или за обединяване с други данни.

Червен флаг в стандартни DPA: клаузи от типа „обработващият може да използва анонимизирани данни за подобряване на услугата" или „обработващият може да агрегира данни от различни клиенти за статистически цели". Тези формулировки противоречат на изискването „само по документирани указания". КЗЛД ги тълкува като отделна обработка от обработващия като администратор за собствени цели.

Български контекст: Указанията могат да са в самия DPA, в общите условия на услугата, или в отделни писмени документи. Имейл от администратора до обработващия е валидно писмено указание. Препоръчителна практика: основните указания (цел, обхват, срок, забранени действия) се записват в DPA или в приложение към него; промените се документират по имейл от оторизирано лице.

1.2. Клауза за поверителност на персонала (буква б)

Обработващият гарантира, че лицата, които обработват лични данни от негово име, са поели задължение за поверителност или са обвързани с подходящо законово задължение за поверителност. Конкретното: служителите на обработващия трябва да имат подписана NDA, конфиденциална клауза в трудовия си договор, или да са обвързани с професионална тайна (например медицински персонал, адвокати).

Доказателствено изискване при одит: при KZLD проверка обработващият може да бъде поискан да покаже подписани NDA образци (анонимизирани) или клаузи от трудовите договори на ключови служители с достъп до клиентски данни. Липсата на такива документи се счита за нарушение, дори ако DPA-то ги изисква на хартия. Препоръчителна практика: ежегодно опресняване на NDA при подновяване на трудовия договор или при значителна промяна на ролята.

1.3. Клауза за технически и организационни мерки (буква в, препраща към чл. 32)

Обработващият предприема всички подходящи мерки по чл. 32 GDPR. Тази клауза задължително трябва да има приложение с конкретно описание на мерките - не общи фрази. КЗЛД отказва да приеме формулировки от типа „обработващият прилага индустриални стандарти за сигурност" без конкретен списък.

Минимално съдържание на приложението за технически и организационни мерки:

• Контрол на физическия достъп до сървърни помещения (RFID карти, видеонаблюдение, журнали)
• Контрол на логическия достъп (MFA, role-based access control, ротация на пароли)
• Криптиране в покой (AES-256 за бекъпи и архивиране) и в трансфер (TLS 1.2 минимум)
• Логиране на достъпа и автоматизирани alerting механизми
• Бекъп политика с тестване на възстановяване минимум веднъж годишно
• Управление на уязвимости с месечно сканиране и патчинг
• Обучение на персонала по сигурност при подписване на трудов договор и ежегодно опресняване
• Сертификации (ISO 27001, SOC 2 Type 2, CSA STAR) ако са приложими

Червен флаг: приложение, което препраща към „политиката за сигурност, публикувана на сайта на обработващия" без копие в DPA-то и без задължение за уведомление при промяна. Това позволява на обработващия едностранно да отслабва мерките без знание на администратора.

1.4. Клауза за sub-processor управление (буква г)

Това е една от най-често погрешно записаните клаузи. GDPR изисква обработващият да не наема друг обработващ (sub-processor) без предварително конкретно или общо писмено разрешение от администратора. При общо разрешение обработващият информира администратора за всички планирани промени относно добавяне или замяна на други обработващи, като дава възможност на администратора да възрази срещу такива промени.

Каскадно правило: обработващият налага на sub-processor-а същите задължения по чл. 28, които има самият той - включително същата защита на лични данни, същите технически мерки, същото право на одит. Обработващият остава пълноценно отговорен пред администратора за изпълнението от sub-processor-а.

Червен флаг 1: Изречение от типа „обработващият може да добавя нови sub-processor-и във всеки момент, текущият списък е достъпен на www.provider.com/subprocessors". Това на практика лишава администратора от право на възражение, защото няма механизъм за уведомление - администраторът трябва сам да проверява страницата. Препоръчителна формулировка: уведомление по имейл към определен контакт на администратора поне 30 дни преди добавянето, с право на писмено възражение в рамките на 14 дни.

Червен флаг 2: Изречение „в случай на възражение, обработващият може да прекрати DPA с 30-дневно предизвестие". На практика това означава, че администраторът няма реално право на възражение - ако възрази, плаща с прекратяване на услугата. Препоръчителна формулировка: обработващият осигурява алтернативен sub-processor или, ако такъв не е възможен, страните преговарят добросъвестно поне 60 дни преди прекратяване.

1.5. Клауза за подпомагане на администратора (букви д и е)

Обработващият подпомага администратора с подходящи технически и организационни мерки за изпълнение на задълженията на администратора към субектите на данни (право на достъп, право на изтриване, право на преносимост, право на коригиране и т.н. по чл. 12-22 GDPR), за DPIA при високорискова обработка, и за уведомяване при инциденти.

Конкретен SLA за подпомагане при искания на субекти: Препоръчителен е срок 5 работни дни за стандартни искания (достъп, изтриване, преносимост). Без конкретен срок в DPA-то, обработващите често отговарят с до 30 дни, което поставя администратора в нарушение на чл. 12, ал. 3 GDPR.

Конкретен срок за уведомление при инцидент: Препоръчителен е 24 часа от установяване на инцидента от страна на обработващия. Това дава на администратора около 48 часа да изпрати уведомление до КЗЛД в рамките на 72-часовия срок по чл. 33 GDPR. Често срещано в стандартни DPA: „без неоправдано забавяне" (vague) или „48 часа" (вече предизвиква риск от просрочване).

Червен флаг: Изречение „обработващият подпомага администратора за разумна такса". Без таван и без определение на „разумна", тази клауза в практиката се превръща в платена услуга. Препоръчителна формулировка: подпомагане без допълнителна такса в обем до 20 часа на месец, над този праг се прилага ставка от X лв./час с предварително писмено одобрение.

1.6. Клауза за връщане или унищожаване (буква ж)

При прекратяване на услугите обработващият, по избор на администратора, връща или унищожава всички лични данни, освен ако правото на ЕС или на държава членка изисква съхранението на личните данни (например данъчно или счетоводно законодателство).

Конкретно очаквано съдържание:

• Срок за избор от страна на администратора (препоръчителен: 30 дни от прекратяване)
• Формат на връщане (препоръчителен: стандартен експортен формат с описание на полетата)
• Метод на унищожаване (cryptographic erasure за облачни услуги, NIST 800-88 за носители)
• Срок за изпълнение (препоръчителен: 60 дни от инструкцията на администратора)
• Attestation от страна на обработващия (писмено потвърждение, че унищожаването е извършено)
• Изключения за бекъп копия с автоматично изтриване и без ново достъпване

Червен флаг: Стандартна формулировка „обработващият ще унищожи данните в рамките на 180 дни от прекратяване". Това оставя бекъп копия на разположение в случай на ново достъпване и не дава attestation. Препоръчителна формулировка: 60-дневен срок за първично унищожаване с writen attestation, и cryptographic erasure на бекъп копията в следващия пълен цикъл на ротация (обикновено 90 дни).

1.7. Клауза за достъп и одит (буква з)

Обработващият предоставя на администратора цялата информация, необходима за демонстриране на спазването на задълженията по чл. 28, и допуска и съдейства за одити, включително инспекции, провеждани от администратора или от друг одитор, посочен от администратора.

Стандартни модели в практиката:

• Писмен въпросник веднъж годишно (минимум за повечето SaaS) - 50-150 въпроса, обработващият отговаря в 30-45 дни
• Прилагане на трета страна одит (SOC 2 Type 2, ISO 27001, CSA STAR Level 2) - администраторът получава копие от доклада с конфиденциална клауза
• Pooled audit (група клиенти споделят правото на одит, един одит покрива всички) - типично за големи cloud доставчици, спорно за български контекст
• Индивидуален одит на място - резервиран за големи администратори или след инцидент, изисква предварително уведомление 30-60 дни

Червен флаг 1: Pooled audit, който заменя индивидуалния одит без алтернатива. Препоръчителна формулировка: pooled audit като стандарт, плюс право на индивидуален одит при пробив на данни или при обоснован риск, поет от администратора, със 60-дневно предизвестие. Червен флаг 2: Право на одит „за разумна такса от обработващия" без таван. Препоръчителна формулировка: един одит на 24 месеца безплатен, допълнителни одити в рамките на същата година с таван 4 000 лв.

1.8. Клауза за известие при противоречие (буква з, второ изречение)

Обработващият незабавно информира администратора, ако дадено указание според негова преценка нарушава GDPR или други разпоредби на ЕС или националното законодателство за защита на данни. Тази клауза е сравнително рядко използвана в практика, но има значение - обработващият има право да отказва изпълнение на указание, ако смята, че то противоречи на GDPR, без да е в нарушение на договора.

Практическо приложение: Ако администраторът поиска от обработващия да изпрати лични данни на трета страна без правно основание (например на маркетинг агенция без съгласие на субектите), обработващият има задължение да откаже и да писмено уведоми. Същото важи и при искане да се запазят данни след срока на съхранение, който самият администратор е дефинирал.

Чл. 28 GDPR е минимумът. Българската регулаторна практика добавя няколко специфики, които не са изрично записани в регламента, но се прилагат от КЗЛД при проверки и в становищата. Тези специфики идват от Закона за защита на личните данни (ЗЗЛД), от секторни закони (Закона за електронните съобщения, Закона за защита на потребителите) и от съдебната практика на Административен съд София град.

2.1. Език на договора

GDPR не изисква конкретен език за DPA. ЗЗЛД и Законът за защита на потребителите изискват българско съдържание за информация към субектите на данни, но самият DPA може да е на който и да е език, разбираем за двете страни. Стандартна практика в български контекст: ако и двете страни са български или ако българската страна е администраторът, договорът е на български. Ако обработващият е чуждестранен и страните не настояват, договорът е на английски.

Практически тест: при поискване от КЗЛД администраторът трябва да предостави превод на DPA-то на български в рамките на 14 дни. Това означава, че при DPA на чужд език, администраторът трябва да има готов превод или достъп до бърз правен превод. За често използвани DPA (AWS, Microsoft, Google) има готови български преводи от професионални правни бюра, които струват 200-600 лв. за пълен превод.

2.2. Юрисдикция и приложимо право

Чуждестранните стандартни DPA често имат клауза за юрисдикция в Ирландия (за европейските клонове на AWS, Google, Microsoft), Делауеър (за американски доставчици), или Англия. От гледна точка на администратор-страна по договора това е по-малък проблем - администраторът има правен капацитет да води дело в чужда юрисдикция, ако необходимо. Но субектът на данни (физическо лице, чиито данни се обработват) има право да предяви иск пред съда по своето местожителство (чл. 79, ал. 2 GDPR и чл. 18 от Регламент Брюксел I-bis).

Какво да изисквате в DPA: Изрична клауза, че субектът на данни може да предяви иск пред български съд, дори когато общата юрисдикция на договора е друга. Тази клауза е стандартна в стандартните договорни клаузи (SCC 2021/914 на ЕК), приложение I, параграф 11. Ако обработващият е извън ЕС, искането за SCC 2021/914 е задължително; ако е в ЕС, може да се ползва само Module 2 от SCC за administrator-processor контекст, но клаузата за юрисдикция на субекта обикновено се прилага.

2.3. Срок за уведомление от обработващия към администратора при инцидент

GDPR изисква обработващият да уведоми администратора „без неоправдано забавяне" (чл. 33, ал. 2). Това е vague формулировка. КЗЛД и Административен съд София град тълкуват „без неоправдано забавяне" за обработващ-към-администратор като максимум 24 часа от установяване на инцидента. Над 24 часа е „неоправдано забавяне" с тежест на нарушение, ако последствието е, че самият администратор е изпратил уведомление до КЗЛД със закъснение.

Препоръчителна формулировка за DPA: „Обработващият уведомява администратора в писмена форма (имейл към ДЛЗД или друг определен контакт) в рамките на 24 часа от установяване на инцидент, който засяга или потенциално засяга личните данни на администратора. Уведомлението съдържа минимум: характер на инцидента, категории и приблизителен брой засегнати субекти, последствия, мерки, предприети или планирани от обработващия." Този текст в DPA-то превръща неконкретен срок в конкретно договорно задължение.

2.4. Кой подава нотификация към КЗЛД при пробив на данни

Чл. 33 GDPR задължава администратора да уведоми КЗЛД в 72 часа от узнаване. Обработващият няма пряко задължение към КЗЛД - неговото задължение е да уведоми администратора. На практика се случва, че обработващи доставчици сами уведомяват местен надзорен орган (например европейския им клон уведомява ирландския Data Protection Commission). Това НЕ освобождава българския администратор от задължението да уведоми КЗЛД, ако засегнатите субекти са в България.

Препоръчителна формулировка за DPA: „Страните потвърждават, че задължението за уведомяване на КЗЛД по чл. 33 GDPR се изпълнява от администратора. Обработващият не подава самостоятелно уведомление до КЗЛД относно инцидент, освен ако не е директно задължен от приложимото законодателство и предварително не уведоми администратора писмено." Това избягва дублирани и противоречиви уведомления, които утежняват инцидента.

2.5. Конкретно посочване на държавата на сървъра

DPA-то трябва конкретно да посочи в коя държава се обработват данните. Това има три практически последствия: (1) активира SCC 2021/914 ако държавата е извън ЕС/ЕИП и не е в списъка на адекватните държави; (2) задължава Transfer Impact Assessment след Schrems II за всеки трансфер към САЩ или други държави с програмиран държавен достъп; (3) дава информация на КЗЛД за географската локация при проверка.

Червен флаг в стандартни DPA: формулировки от типа „данните се обработват в съответната географска зона на доставчика" без конкретно посочване. Изисквайте: списък на държавите по име, с приоритет на ЕС/ЕИП. Ако обработващият не може да гарантира конкретна локация (например cloud доставчик с автоматично балансиране на натоварването), изисквайте: списък на държавите от които може да бъде обработена услугата, и допълнителни мерки за всяка от тях (SCC, TIA).

Стандартните DPA на големите облачни доставчици (AWS, Microsoft, Google, Stripe, Salesforce, HubSpot, Slack, Cloudflare, Atlassian) са технически коректни от гледна точка на чл. 28 GDPR, но имат структурни характеристики, които пренасят непропорционално много риск върху администратора. Това не са злонамерени клаузи - те са продукт на стандартизация и на различен мащаб (доставчик с милиони клиенти не може да предложи индивидуален одит на всеки). Но за български администратор, който подписва такова DPA, разпознаването на тези характеристики е критично, защото в почти всички случаи има възможност за допълнителна добавка (DPA addendum) или за компенсиращи мерки.

Петте най-чести червени флага, които ще намерите в стандартни DPA на големите доставчици:

Готовият шаблон, който предлагаме на нашите клиенти, има 12 раздела плюс 5 приложения. Това не е „по-голям" или „по-усложнен" договор от стандартния - просто конкретизира всяка от осемте задължителни клаузи в практически приложимо съдържание. Целта е DPA-то да може да се покаже на инспектор от КЗЛД с увереност, че всеки въпрос за конкретно действие има конкретен отговор в текста.

Основните разлики на този шаблон спрямо стандартен GDPR-генератор от интернет са в три точки:

Разлика 1: Конкретни срокове, не „без неоправдано забавяне". Всеки срок в DPA-то е конкретен (24 часа за уведомление при инцидент, 5 работни дни за подпомагане при искания на субекти, 30 дни за уведомление при нов sub-processor, 60 дни за връщане или унищожаване, 14 дни за превод). КЗЛД оценява конкретността при проверка.

Разлика 2: Приложение 2 е попълнено, не препратка. Техническите и организационни мерки са изброени конкретно в DPA-то (или в приложение към DPA-то), не като препратка към политика на сайта на обработващия. Това гарантира, че мерките не могат да бъдат отслабени едностранно от обработващия без писмено уведомление и съгласие.

Разлика 3: Българска юрисдикция като алтернатива за субект на данни. Дори когато общата юрисдикция на договора е друга (Ирландия, Делауеър, Англия), субектът на данни запазва право да предяви иск пред български съд. Тази клауза идва от SCC 2021/914, но често липсва в други стандартни DPA.

Компания от 50-150 души има в типичен случай 12-25 външни доставчика, които обработват лични данни. Заетите DPA позиции в момента на първоначална оценка са обикновено 2-4, останалите 8-21 са с „предлагано DPA от доставчика, но не подписано от наша страна". Тук е концентрирана 70 на сто от риска при КЗЛД проверка.

Седмица 1 (дни 1-7): Inventory. Списък на всички външни доставчици, които имат достъп до лични данни. Източник: списък на всички външни услуги, плащани в последните 12 месеца (от финансовия отдел) плюс списък на всички SaaS приложения, които служителите използват с фирмен имейл. Категоризация на доставчиците в три групи:

• Критични: доставчици с достъп до клиентски лични данни или специални категории (медицински, финансови, политически възгледи). Примери: основен CRM, имейл маркетинг платформа, счетоводен софтуер, hosted ERP, HR система.
• Важни: доставчици с достъп до данни на служители или ограничен достъп до клиентски данни. Примери: вътрешен communication tool (Slack, Teams), file sharing (Dropbox, Google Drive), payroll, project management (Asana, Jira).
• Опционални: доставчици с достъп само до агрегирани или анонимизирани данни. Примери: анализ на трафика на сайта (Google Analytics с IP anonymization), CDN (Cloudflare без user data).

Резултат: Excel или Notion таблица с име на доставчика, тип услуга, категория, какви данни обработва, дали има DPA, дата на DPA, държава на сървъра.

Седмица 2 (дни 8-14): Преглед на съществуващи DPA. За всеки от съществуващите DPA, прилагане на 10-точковия чек-лист от Раздел 4. Маркиране на флаговете и нуждата от addendum. За много стари DPA (преди 2018 г.) - подмяна с нов вариант, не addendum.

Резултат: Списък на DPA с три статуса - „работещ" (0-2 флага), „нужен addendum" (3-4 флага), „нужна подмяна" (5+ флага).

Седмица 3 (дни 15-21): Подписване на липсващи DPA. За критични и важни доставчици без DPA - изтегляне на стандартния DPA от портала на доставчика, попълване, подписване. За много от големите доставчици (AWS, Microsoft, Google, Stripe) процесът отнема 15-30 минути на доставчик. За по-малки доставчици - може да се наложи изпращане на нашия шаблон. Acceptance rate за външни шаблони: 30-50 на сто. За останалите - преговори или приемане на тяхното с addendum.

Резултат: Подписани DPA с всички критични доставчици (приоритет 1), повече от 80 на сто от важните доставчици (приоритет 2).

Седмица 4 (дни 22-30): Архив и процеси. Централен архив на всички DPA в SharePoint, Google Drive, Notion, или специализиран GDPR инструмент (OneTrust, TrustArc). Метаданни за всеки DPA: страни, дата на подписване, срок на договора, дата на следваща ревизия, статус (работещ / нужен преглед / просрочен), отговорник в компанията.

Процес за нови доставчици: преди подписване на основния договор с нов доставчик с достъп до лични данни, ДЛЗД или юрисконсултът преглежда DPA-то на доставчика, прилага 10-точковия чек-лист, и одобрява или иска addendum. Този процес отнема 30-60 минути на нов доставчик. Ежегоден преглед: тримесечен ритъм на проверка дали има нови sub-processor-и, дали техническите мерки са актуални, дали има промени в географията.

Как Атлант Сикюрити помага

DPA преглед и портфолио за вашата компания за 30 работни дни

За компании, които имат 10+ външни доставчика с достъп до лични данни и искат структуриран DPA архив, провеждаме фокусирана 30-дневна работа. В края имате: пълен inventory на доставчиците с категоризация, преглед на всичките съществуващи DPA с 10-точков чек-лист, подписани DPA с всички критични доставчици, addendum-и за DPA с по-малко от 80 на сто покритие, и централен архив с тримесечен ритъм на преглед.

• Фиксирана цена от 3 200 лв. за компания до 25 души с до 10 доставчика, от 6 400 лв. за 25-100 души с до 25 доставчика, от 12 800 лв. за 100-300 души с до 50 доставчика
• Доставка: inventory таблица с всички доставчици и категоризация, 10-точков чек-лист за всеки DPA, подписани DPA с критичните доставчици, addendum шаблони за останалите, централен архив в SharePoint или Notion, тримесечен ритъм за поддръжка
• Старши консултанти с правен и технически профил - всичко минава през лицензиран ДЛЗД
• Безплатна първоначална 30-минутна оценка - на нея ви казваме приблизителния брой DPA с флагове и обхвата на работата

Резервирайте 30-минутна безплатна оценка →

DPA-то не е формалност. Това е документът, който в момент на инцидент, KZLD проверка, корпоративен due diligence или съдебен спор определя кой носи каква отговорност и в какъв обем. Една клауза за уведомление в 24 часа вместо „без неоправдано забавяне" може да е разликата между уведомление до КЗЛД в срок (без отделна санкция) и просрочено уведомление (утежняващо обстоятелство, което в реални случаи увеличава основната глоба с 40-120 на сто). Една клауза за индивидуален одит при пробив може да е разликата между документиран отговор на „как точно е станало" и догадки в публично пространство.

Структурата на работата е дискретна. Не изисква непрекъсната оперативна сигурност или специализиран екип. Изисква системно прилагане на 10-точков чек-лист към всеки DPA, конкретни приложения вместо препратки към сайтове, и тримесечен ритъм на преглед. Един отговорник в компанията (ДЛЗД, юрисконсулт, мениджър по съответствие) може да поддържа портфолио от 25-50 DPA с 6-10 часа работа в месец.

Ако имате DPA в работа, очаквана KZLD проверка, корпоративен клиент с въпросник, или просто искате структуриран подход към DPA портфолиото си, резервирайте 30-минутна безплатна оценка или пишете на alexander@atlantsecurity.com.