Як забезпечити безпеку даних за допомогою DPA?

Як власник бізнесу, ви несете відповідальність за вибір партнера, який отримує доступ до персональних даних компанії. Уявіть, що ви наймаєте компанію для створення системи CRM для E-commerce. Розробка такого рішення передбачає, що IT-фахівці отримають доступ до персональних даних клієнтів. І ви, і IT-компанія, повинні гарантувати їхню безпеку. Це правило прописано в GDPR, де зазначено, що обидві сторони відповідають за обробку.

Щоб забезпечити захищеність даних, аутсорсинговій IT-компанії потрібно провести внутрішній аудит та забезпечити високий рівень кібербезпеки. У них має бути чітко визначена політика конфіденційності всередині компанії. І, нарешті, вони мають бути готові підписати DPA (Data protection agreement). У статті розберемося навіщо бізнесу DPA і як укласти угоду.

Що таке Data protection agreement?

DPA – це угода щодо обробки даних. Договір допомагає компаніям переконатись, що всі дії з обробки даних відповідають політиці GDPR. Підписуючи документ, обидві сторони захищають дані проекту, отримують стратегію запобігання та усунення витоку даних.

Кому потрібно підписувати DPA?

Існує 3 сценарії роботи із зовнішніми підрядниками.

1. Обробки персональних даних не відбувається. Наприклад, IT-компанія проводить UX/UI-дослідження та розробляє прототип додатку для банку. Такий виконавець не отримує доступу до персональних даних клієнтів банку, а отже, DPA не потрібен.
2. Процесор обробляє дані, але доступ до них обмежений. У команди IT-компанії є доступ до баз даних у зашифрованому вигляді, тому в цьому випадку немає необхідності підписувати DPA.
3. Постачальник обробляє дані від імені контролера. Наприклад, українська аутсорсингова IT-компанія отримує замовлення від клієнта з ЄС на розробку програми для керування даними медичного закладу. Очевидно, що їм потрібний доступ до особистої інформації пацієнтів. У такому разі обов'язково підписувати DPA. Окрім цього, до старту робіт за проектом, компанії потрібно адаптувати внутрішні процеси під вимоги угоди та пройти GDPR Compliance.

Що написати в DPA?

У розділі 3 статті 28 GDPR закріплено перелік положень, які обов'язково мають бути в DPA. Нижче розкажемо деталі на прикладі угоди між замовником (контролером) та IT-компанією (процесором).

• Обробка за письмовими інструкціями контролера

Процесор може обробляти персональні дані лише відповідно до задокументованих інструкцій контролера.

У квітні 2022 року CHIL наклав 1,500,000 EUR штрафу на DEDALUS BIOLOGY. Компанія розробила IT-рішення для управління лабораторіями. 3000 приватних та 30 державних лабораторій придбали ліцензії на програмне забезпечення. У 2021 році стався витік особистих даних 491 840 пацієнтів, які продавалися у даркнеті. Під час перевірки CHIL встановили, що DEDALUS BIOLOGY отримала більший обсяг інформації, ніж потрібно, та опрацювала дані з порушенням інструкцій.

Такі ситуації призводять до мільйонних штрафів. Щоб їх уникнути, GDPR документи повинні містити детальний опис обсягу обробки та заходів безпеки.

• Усі, хто має доступ до даних, відповідають за порушення інструкцій

Процесор надає доступ до персональних даних тільки тому персоналу, який взяв на себе зобов'язання дотримуватися конфіденційності. Крім цього, команду потрібно регулярно навчати та укладати з кожним із них DPA.

• Залучення субпроцесора можливе після погодження з контролером

Дозвіл на залучення нових співробітників чи підрядників має бути письмовим. У DPA важливо прописати умови залучення субпроцесорів. IT-компанія може передати на субпідряд обробку персональних даних за умови, якщо:

1. залучає субпроцесорів від свого імені за письмовим договором, але інформує замовника про доповнення та заміни у команді;
2. відповідає за порушення субпроцесорів;
3. оцінює методи забезпечення безпеки та конфіденційності субпроцесора до старту роботи, щоб встановити, що він здатний забезпечити високий рівень захисту персональних даних, якого вимагає DPA;
4. публікує список команди на дату набрання чинності DPA або надає інформацію за запитом.

Замовник може заперечувати проти заміни спеціаліста у команді і протягом визначеного терміну повідомити про це. Але в DPA має бути пункт про форс-мажорну заміну. IT-компанія може замінити субпроцесора без попередження, якщо потрібно діяти негайно. Наприклад, розробник звільняється.

Залучення до роботи підрядників без дозволу контролера може закінчитися штрафом. Так, у травні 2022 року Wens Experience SRL заплатила 1500 EUR за те, що залучила співробітника до обробки даних без письмового дозволу, а значить порушила вимоги статті 28 GDPR.

• Виконання заходів безпеки за статтею 32 GDPR

Ось перелік заходів безпеки: анонімізація та шифрування; забезпечення постійної конфіденційності, цілісності, доступності та стійкості систем та сервісів обробки; своєчасне відновлення доступу до даних та тестування ефективності заходів. Перед початком робіт IT-компанія має реалізувати такі заходи.

У кейсі DEDALUS BIOLOGY компанія заплатила штраф 1,500,000 EUR ще й тому, що порушила статтю 32 GDPR. CHIL виявили, що компанія не має спеціальної процедури перенесення даних, відсутнє шифрування та автоматичне видалення даних після перенесення, а також автентифікація для доступу до загальнодоступної зони FTP-сервера.

• Сприяння контролеру

Наприклад, процесор співпрацюватиме з контролером під час розгляду запитів від суб'єктів даних чи регулюючих органів.

• Видалення даних

Клієнт може доручити експортувати, вилучати або видалити особисті дані, що залишилися на серверах.

• Надання інформації для демонстрації дотримання зобов'язань

Клієнт або його аудитор може перевіряти середовище та методи забезпечення безпеки. У DPA радимо деталізувати алгоритм та терміни аудиту. Наприклад, контролер повідомляє про аудит електронною поштою за 60 днів. Періодичність перевірок не може перевищувати 1 раз на рік. Час аудиту обмежується трьома робочими днями. Сторони можуть домовитися, що перевірка проводиться у режимі он-лайн. І не забудьте визначити, хто несе витрати на аудит.

А тепер розберемо структуру документа докладніше.

IT-юристи Stalirov&Co розробляють DPA у форматі основної угоди та додатків до неї, які визначають предмет, типи та мету обробки персональних даних, категорії суб'єктів даних, технічні та організаційні заходи. Про кожен із розділів розповімо докладніше.

Предмет та категорії персональних даних

Якщо IT-компанія розробляє програмне забезпечення для онлайн-банкінгу, то суб'єктами даних будуть клієнти банку. Розробники отримують доступ до таких типів даних: ім'я, номери телефонів, адресу електронної пошти, часовий пояс, адресні дані, доступ до системи/дані про використання/авторизацію, фінансові та банківські реквізити, номер кредитної картки.

Для кожного кейсу список відрізнятиметься.

Цілі обробки

Список цілей може бути таким:

• використання персональних даних для налаштування, експлуатації, моніторингу та забезпечення функціональності програмного продукту;
• спілкування із суб'єктами даних;
• зберігання персональних даних у дата-центрах;
• оновлення програмного продукту;
• резервне копіювання персональних даних;
• комп'ютерна обробка персональних даних, включаючи передачу, пошук та доступ;
• доступ до мережі передачі даних.

Технічні та організаційні заходи

У DPA для аутсорсингової IT-компанії IT-юристи Stalirov&Co прописали такий перелік заходів.

• Контроль фізичного доступу - це запобігання доступу сторонніх до приміщень, де розташовані системи обробки даних. Наприклад, будівлі та офіси захищені за допомогою системи доступу за смарт-картками. Крайні точки входу до будівлі обладнані сертифікованою системою ключів. Окремі території захищаються за допомогою спеціальних профілів доступу, відеоспостереження, систем охоронної сигналізації та біометричних систем контролю доступу. Обладнання фізичної безпеки (датчики руху, камери) регулярно проходить технічне обслуговування. Гості та відвідувачі будівель повинні зареєструватися на стійці реєстрації.
• Система контролю та управління доступом. При наданні доступу до конфіденційних систем використовується кілька рівнів авторизації. Весь персонал отримує доступ до систем з унікальним ідентифікатором. Коли співробітник звільняється, його права доступу анулюються. Усі паролі повинні відповідати мінімальним вимогам та зберігатися у зашифрованому вигляді. Обмін паролями заборонено, а система вимагає їх регулярної зміни. Мережа компанії захищена від мережі загального користування брандмауерами. Компанія використовує актуальне антивірусне програмне забезпечення в точках доступу до мережі, а також на всіх файлових серверах та робочих станціях. Віддалений доступ до корпоративної мережі та критичної інфраструктури захищений строгою автентифікацією.
• Контроль доступу до даних. IT-фахівці отримують доступ лише до тих даних, до яких мають право. При цьому дані не можуть бути прочитані, скопійовані, змінені або видалені без дозволу. Команда має доступ до інформації, яка потрібна для виконання тасків. IT-компанія використовує концепції авторизації, які документують процеси доступів та призначені ролі для кожного облікового запису. Встановлення несхваленого програмного забезпечення заборонено.
• Контроль передачі. Рух даних внутрішніми мережами та між IT-компанією та замовником має бути захищений.
• Контроль введення даних – це можливість ретроспективно перевірити та встановити, чи були дані введені, змінені чи видалені із систем обробки та ким.
• Контроль доступності. Персональні дані мають бути захищені від випадкового знищення чи втрати. Для реалізації мети компанія використовує регулярні процеси резервного копіювання та джерела безперебійного живлення (ДБЖ, акумулятори, генератори). Аварійні процеси та системи регулярно тестуються.
• Контроль цілісності даних. Компанія запроваджує багаторівневу стратегію захисту від модифікацій. Використовує брандмауери, антивірусне програмне забезпечення та проводить зовнішнє та внутрішнє тестування на проникнення.

Standard Contractual Clauses

SCC слід підписувати, якщо дані виводяться за межі Європейської економічної зони, до країн, де немає достатнього рівня безпеки.

Писати SCC самостійно не потрібно. Просто підпишіть вже розроблений Європейською комісією стандартизований документ. Цього вимагає стаття 46 GDPR. Але не всі виконують це правило.

Французька будівельна компанія Futura International у 2019 році отримала штраф у 500 000 EUR. Компанія передавала дані до Кот-д'Івуару, Марокко, Тунісу через програмне забезпечення Profibus. Між Futura Internationale та підрядником був договір, але він не включав усі необхідні умови про транскордонну передачу даних. Все тому, що Futura International вирішили розробити свої документи, а не скористалися SCC.

Хто заплатить штраф за порушення GDPR: контролер чи процесор?

Компаніям важливо пам'ятати, що передаючи обробку даних підрядникам, вони вважаються контролерами та несуть відповідальність не лише за власну відповідність вимогам GDPR, а й за дотримання правил процесорами.

Перекласти відповідальність на процесора не вдасться. Хоча багато компаній намагалися. Наприклад, у 2020 році British Airways і Marriott стверджували, що у витоку даних винні не вони, а сторонні постачальники послуг. Але аргумент не взяли до уваги, і кожній компанії довелося заплатити штрафи більше 20 млн. EUR.

З іншого боку, процесор несе відповідальність, якщо не виконує вимог регламенту, або виходить за рамки інструкцій від контролера. Таке правило прописане у статті 82 GDPR. Так компанія DEDALUS BIOLOGY була процесором, але заплатила 1,500,000 EUR штрафу за отримання більшого обсягу інформації, ніж вимагалося за інструкцією.

І контролер, і процесор можуть убезпечити себе від несправедливих штрафів, якщо DPA між ними буде детально описувати об'єкти та цілі обробки, організаційні та технічні заходи безпеки.