Преглед на договора за обработване на данни спрямо реалната услуга

Договорът за обработване на данни става полезен, когато описанието в него съответства на действителната услуга. Договор, който изглежда пълен, все пак може да описва грешните данни, да пропуска доставчик на поддръжка или да обещава изтриване, което продуктът не може да извърши.

За CTO прегледът свързва правните ангажименти с архитектурата, конфигурацията и оперативните процедури. Колегите от правния отдел или от отдела по защита на данните тълкуват клаузите; инженерите установяват дали тези клаузи описват реалността. Резултатът трябва да е защитимо решение за услугата, подкрепено с доказателства и ясен списък с нерешени условия, а не просто подписан PDF файл.

Установете ролята на доставчика, преди да преглеждате клаузите

Започнете с определяне дали доставчикът действа като обработващ лични данни за съответното обработване. Съгласно ОРЗД обработващият лични данни обработва лични данни от името на администратора. Не всяко отношение с доставчик има тази роля, а един доставчик може да има различни роли за различни дейности.

Хоствана платформа за поддръжка може да обработва клиентски тикети по ваши указания, като същевременно действа като отделен администратор за част от собственото си администриране на акаунти. Ако условията ѝ позволяват и използване на съдържанието на тикетите за независимо определени цели, тази дейност изисква отделен анализ. Наричането на всичко „подобряване на услугата“ не решава въпроса с ролята.

Подгответе кратко описание на обхвата, преди да нанасяте бележки по договора:

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

Договорът за обработване на данни не е правно основание по член 6 и не удовлетворява автоматично изискванията за международно предаване на данни. Тези въпроси остават отделни. Ако самата ви организация е обработващ лични данни, идентифицирайте указанията и условията за разрешение на администратора нагоре по веригата, преди да ангажирате доставчика като подобработващ.

Изградете матрица за преглед по член 28

Член 28 от ОРЗД изисква обвързващ договор или друг отговарящ на условията правен акт, който урежда дейността на обработващия лични данни. Той трябва да описва предмета и срока, естеството и целта, вида лични данни, категориите субекти на данни и правата и задълженията на администратора.

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

Използвайте следната матрица, за да проверите изискваните задължения на обработващия лични данни. Колоната с доказателства съдържа практически препоръки за прегледа, а не законово изискване за получаване на всеки посочен документ.

Обработващият лични данни трябва също незабавно да уведоми администратора, ако според него дадено указание нарушава приложимото право в областта на защитата на данните. Проверете къде отива това уведомление и кой може да реши въпроса.

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

Проследете представителен запис през услугата

Изберете реалистичен запис и го проследете от постъпването до унищожаването. За услуга за поддръжка на клиенти това може да е тикет, съдържащ име, имейл адрес, идентификатор на акаунт и прикачен файл. При тестване предпочитайте синтетични данни.

Картографирайте събирането, постъпването чрез API, основното съхранение, индексирането, анализите, достъпа за поддръжка, експортите, интеграциите, резервните копия и изтриването. Попитайте кои компоненти получават съдържание и кои получават само метаданни. Журналите и диагностичните следи често съдържат идентификатори дори когато основното приложение е с правилно определен обхват.

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

Обърнете специално внимание на функциите, които администраторите могат да активират без участието на отдела за покупки: транскрипция, обогатяване, обобщаване с AI, външни webhooks и записване на сесии за поддръжка. Договор, прегледан за базовия продукт, може да не описва адекватно активираната услуга.

Резултатът може да е проста диаграма на потоците от данни и дневник на несъответствията. Всяко несъответствие трябва да посочва договорното твърдение, наблюдаваното поведение, последицата, собственика и решението. Например „Договорът описва съхранение, контролирано от клиента; диагностичните журнали остават за фиксиран период“ е нещо, по което може да се действа. „Съхранението е неясно“ не е достатъчно, за да се закрие въпросът.

Тествайте обещанията за сигурност спрямо внедряването

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

Приложението трябва да обяснява достатъчно, за да може услугата да бъде оценена, без да изисква разкриване на подробности, чувствителни от гледна точка на експлоатиране. Дайте приоритет на изолацията между наемателите, привилегирования достъп, удостоверяването, криптирането, устойчивостта, възстановяването, управлението на уязвимостите и тестването. Идентифицирайте контролите, които управлява доставчикът, и настройките, които вашият екип трябва да конфигурира.

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

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

Сертификатите и докладите за увереност могат да подкрепят оценката, но техният обхват е важен. Проверете услугата, юридическото лице, периода на оценката, изключенията и отговорностите на клиента. Доклад за доставчика на хостинг не е доказателство за всяка контрола в SaaS приложението, а сертификацията не установява съответствие с ОРЗД. Вижте оценяване на доказателствата за увереност в сигурността за по-широкия преглед на доказателствата.

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

Проследете веригата от подобработващи и оценете предаването на данни отделно

Член 28, параграф 2 изисква предварително конкретно или общо писмено разрешение за включването на друг обработващ лични данни. При общо разрешение обработващият трябва да информира администратора за планирани добавяния или замени и да му предостави възможност да възрази. Член 28, параграф 4 изисква съответните задължения за защита на данните да бъдат прехвърлени надолу по веригата; първоначалният обработващ остава изцяло отговорен пред администратора за изпълнението на тези задължения от подобработващия.

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

Оценете механизма за промени:

• Достига ли уведомлението до наблюдаван адрес или до назначен собственик?
• Има ли достатъчно информация и време за оценка на предложената промяна?
• Как се подава и решава възражението?
• Какво се случва, ако няма приемлива алтернатива?

Договорно право, което никой не може да упражни на практика, е предупредителен знак. Абонирайте подходящия екип и запишете кой оценява уведомленията.

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

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

Направете задълженията за съдействие изпълними

Уведомяване за нарушения и предаване на инцидента

Съгласно член 33, параграф 2 обработващият лични данни трябва да уведоми администратора без ненужно забавяне, след като узнае за нарушение на сигурността на личните данни. Администраторът отделно преценява уведомяването на надзорния орган, което се изисква без ненужно забавяне и, когато това е осъществимо, не по-късно от 72 часа след узнаването, освен ако не съществува вероятност нарушението да породи риск за правата и свободите на физическите лица.

Не давайте на обработващия срока на администратора като негов период на изчакване по подразбиране. Практичният договор трябва да установява своевременно първоначално уведомление, посочени канали и последователни актуализации. Договорената цел за уведомяване е оперативна препоръка; тя не замества законовия стандарт.

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

Тествайте предаването с настолно упражнение. Потвърдете, че уведомлението достига до екипите за реагиране при инциденти и до проверяващите по защита на данните и извън нормалното работно време, а не само до мениджър на акаунта.

Искания на субекти на данни

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

Договорете пътя за отговор и очакваното време за обработка. Администраторите обикновено имат един месец, за да отговорят на искане, при спазване на условията на ОРЗД за удължаване; съдействието на доставчика трябва да оставя време за проверка на самоличността, правна оценка и сигурно предоставяне. Доставчикът обикновено трябва да насочва към вас исканията, свързани с обработването по вашите указания, вместо самостоятелно да решава техния изход.

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

Връщане, изтриване и резервни копия

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

Проверете пълнотата на експорта, формата, периода на наличност и дали са изключени прикачени файлове или конфигурация. При изтриването разграничете активните записи, кешовете, репликите, журналите и резервните копия. Ако изтриването на резервните копия следва планиран цикъл, документирайте периода, ограниченията на достъпа и мерките, които предотвратяват повторното въвеждане на изтрити записи чрез възстановяване.

Попитайте как се доказва завършването и как се идентифицира съхранението, изисквано от закона. Избягвайте да разчитате на „акаунтът е закрит“ като доказателство, че личните данни са премахнати.

Прегледайте правата на одит, отговорността и нерешените клаузи

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

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

Клаузите за отговорност изискват отделна търговска оценка. Обезщетението по член 82 зависи от условията за отговорност в регламента; обработващите лични данни не носят автоматично отговорност за всеки пропуск на администратора. Когато няколко страни носят отговорност съгласно член 82, правилата може да ги изложат на отговорност за цялата вреда, за да се гарантира ефективно обезщетение. Договорният таван не ограничава законовите права на физическите лица. Неговият ефект върху разпределението и възстановяването между страните изисква правен преглед.

Ако доставчикът откаже изменения, разграничете три изхода:

• Изясняване: получете авторитетна формулировка или доказателство, които разрешават неяснотата.
• Условно приемане: одобрете законосъобразно споразумение с документиран търговски или оперативен остатъчен риск и конкретни предпазни мерки.
• Без продължаване: спрете или препроектирайте обработването, когато изискваните задължения остават неизпълнени.

Приемането от ръководството не може да направи незаконосъобразно споразумение законосъобразно. Длъжностното лице по защита на данните, когато е определено, съветва и наблюдава независимо; отговорният бизнес собственик взема решенията за услугата с принос от правния отдел и отдела по защита на данните. Не възлагайте на длъжностното лице по защита на данните отговорността за определяне на целите или средствата на обработването.

Проверете AI функциите като допълнителни пътища на обработване

AI функциите въвеждат входни данни, резултати и междинни артефакти, които по-старите приложения може да не описват. Прегледайте подканите, извлечените документи, embeddings, генерираните отговори, обратната връзка, записите от наблюдението за злоупотреби и достъпа за човешки преглед, когато е приложимо.

Установете дали клиентските данни се използват за обучение или подобряване на модели, чии цели обслужва това и кое юридическо лице извършва обработването. „Без обучение“ не е равнозначно на „без съхранение“, и нито едно от двете обещания не доказва, че журналите за поддръжка или записите от наблюдението не съдържат лични данни.

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

Записвайте договорния ангажимент и доказателствата за конфигурацията заедно. Всяка нова цел изисква собствена оценка на ролята и законосъобразността; договорът за обработване на данни не осигурява това правно основание. Приложимостта на Акта за изкуствения интелект също е отделен въпрос, а не нещо, което се удовлетворява с подписването на условия за обработващ лични данни.

Практически пример: софтуер за поддръжка с незадължително обобщаване

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

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

Прегледът води до четири конкретни действия:

1. Допълнете обхвата. Добавете прикачените файлове, диагностичните идентификатори и обработването с AI към описанието; проверете дали доставчикът използва част от съдържанието за собствени цели.
2. Изяснете веригата от доставчици. Получете идентичността на доставчика на модела, местата на обработване, ангажиментите за съхранение и обхвата на разрешението. Оценете съответните предавания отделно.
3. Валидирайте поведението през жизнения цикъл. Прекарайте синтетичен тикет през експорт и изтриване. Получете обяснение за съхранението на резервните копия и диагностичните данни, вместо да приемате, че изтриването на тикета премахва всяко копие.
4. Поставете условие за пускане. Дръжте обобщаването деактивирано, докато договорът и потокът от данни за него не бъдат прегледани. Установете маршрутизирането на уведомленията за нарушения и промените в подобработващите преди производствената употреба.

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

Запазете решението и го преразгледайте, когато услугата се промени

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

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

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

Нужен ли е саморъчен подпис на договора?

Член 28, параграф 9 изисква писмена форма, включително в електронен формат. Саморъчният подпис по същество не се изисква. Запазете доказателство за обвързващо приемане и за действащата версия; помолете правните проверяващи да разрешат несигурността относно включването онлайн или противоречащи си условия.

Трябва ли всеки подобработващ да бъде посочен в договора за обработване на данни?

Член 28 не предписва фиксиран списък в самия документ. Поддържаният списък може да подкрепи разрешението, при условие че споразумението осигурява изискваната информация, уведомленията за промени и възможността за възражение. Запазете списъка, който е релевантен за вашия преглед.

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