Як забезпечити документування відповідності вимогам GDPR за допомогою ISMS Copilot

Огляд

Ви дізнаєтесь, як використовувати ISMS Copilot для створення та підтримки комплексної документації щодо відповідності вимогам GDPR – від реєстрів обробки даних та політик конфіденційності до оцінювання впливу на захист даних (DPIA) та процедур реагування на інциденти.

Для кого ця інструкція

Цей посібник призначений для:

• Спеціалістів із захисту даних, які керують програмами відповідності вимогам GDPR
• Фахівців із конфіденційності, які створюють документацію щодо GDPR
• Організацій, що базуються в ЄС та обробляють персональні дані
• Компаній за межами ЄС, які надають послуги резидентам ЄС
• Організацій, які поєднують GDPR з ISO 27001 або SOC 2

Передумови

Перш ніж розпочати, переконайтеся, що у вас є:

• Обліковий запис ISMS Copilot (доступна безкоштовна пробна версія)
• Розуміння того, які персональні дані обробляє ваша організація
• Доступ до існуючих політик конфіденційності та угод про обробку даних
• Знання про потоки даних та сторонніх обробників

Перш ніж розпочати

Розуміння вимог до документації GDPR

Обов'язкова документація

GDPR прямо вимагає наявності таких документів:

Вимоги залежно від ролі

Обов'язки щодо документації відрізняються залежно від ролі:

• Розпорядник даних: Визначає цілі та засоби обробки; відповідає за ROPA, повідомлення про конфіденційність, DPIA, управління згодою
• Виконавець даних: Обробляє дані від імені розпорядника; вимагає DPA, записів про обробку, документації заходів безпеки
• Обидві ролі: Багато організацій виступають розпорядниками для одних видів обробки (наприклад, дані співробітників) та виконавцями для інших (наприклад, дані клієнтів від імені клієнтів)

Крок 1: Налаштування робочого простору GDPR

Створення спеціалізованого робочого простору

1. Увійдіть до ISMS Copilot
2. Створіть новий робочий простір: "Відповідність GDPR - [Назва вашої організації]"
3. Додайте спеціальні інструкції:

Контекст відповідності GDPR:

Організація: [Назва компанії]
Місцезнаходження: [Місце головного офісу, регіони діяльності]
Роль: [Розпорядник даних / Виконавець даних / Обидві ролі]
Галузь: [SaaS, електронна комерція, охорона здоров'я, маркетинг тощо]
Розмір: [кількість співробітників, клієнтів/користувачів з ЄС]

Обробка даних:
- Типи персональних даних: [імена, електронні адреси, IP-адреси, медичні дані, фінансові дані тощо]
- Дані особливої категорії: [Так/Ні – якщо так, вкажіть: медичні, біометричні тощо]
- Цілі обробки: [маркетинг, надання послуг, аналітика тощо]
- Джерела даних: [форми на сайті, API, треті сторони]
- Сторонні обробники: [хмарні провайдери, платіжні системи, інструменти]

Статус відповідності:
- Призначено DPO: [Так/Ні]
- Наявна документація: [перелік наявного]
- Основні прогалини: [сфери, які потребують доопрацювання]
- Інтеграція: [чи також працюєте над ISO 27001/SOC 2]

Налаштування:
- Посилання на конкретні статті GDPR
- Надання тексту, готового для DPA
- Врахування узгодження кількох рамкових стандартів (GDPR + ISO 27001)
- Пропозиції практичних рішень для [стартапу/МСБ/підприємства]

Крок 2: Створення реєстру діяльності з обробки даних (ROPA)

Що таке ROPA і кому він потрібен?

Стаття 30 вимагає від організацій з 250+ співробітниками АБО тих, що обробляють високоризикові/регулярні дані, вести ROPA, який документує всі види обробки персональних даних.

Генерація структури ROPA

Запитайте ISMS Copilot створити шаблон ROPA:

"Створіть шаблон реєстру діяльності з обробки даних (ROPA) відповідно до статті 30 GDPR для [розпорядника/виконавця даних]. Включіть стовпці: Назва діяльності з обробки, Мета обробки, Правова підстава (Стаття 6), Категорії суб'єктів даних, Категорії персональних даних, Категорії отримувачів (хто отримує дані), Передача даних до третіх країн (якщо застосовується), Період зберігання, Заходи безпеки. Поясніть вимоги до кожного стовпця."

Інвентаризація видів обробки

Визначте всі операції з обробки:

"Для [типу компанії: SaaS-платформа, сайт електронної комерції, маркетингове агентство] визначте типові види обробки персональних даних для включення до ROPA. Врахуйте: управління обліковими записами клієнтів, маркетингові комунікації, обробка платежів, підтримка клієнтів, аналітика, управління персоналом, робота з постачальниками. Для кожного виду обробки опишіть, які персональні дані обробляються та з якою метою."

Документування кожного виду обробки

Створіть детальні записи:

"Для нашого виду обробки [управління обліковими записами клієнтів] заповніть запис у ROPA: Назва обробки: 'Реєстрація та управління обліковими записами клієнтів'. Мета: [опишіть]. Правова підстава: [Виконання договору / Законний інтерес / Згода]. Суб'єкти даних: [існуючі клієнти, потенційні клієнти]. Категорії персональних даних: [ім'я, електронна адреса, компанія, IP-адреса, дані про використання]. Отримувачі: [внутрішні команди, хмарний провайдер AWS]. Зберігання: [протягом існування облікового запису + 2 роки]. Безпека: [шифрування під час зберігання/передачі, контроль доступу, MFA]."

Робота з даними особливої категорії

Якщо обробляються конфіденційні дані:

"Ми обробляємо [медичні дані / біометричні дані / дані про расову приналежність] для [мети]. Які додаткові вимоги GDPR застосовуються? Оновіть наш запис у ROPA, включивши: правову умову статті 9 (явна згода, медичні цілі тощо), необхідні посилені заходи безпеки, обґрунтування необхідності та пропорційності, а також оцінку необхідності проведення DPIA."

Крок 3: Розробка повідомлень про конфіденційність та політик

Створення зовнішнього повідомлення про конфіденційність

Вимоги до прозорості статей 13-14:

"Створіть повідомлення про конфіденційність, що відповідає GDPR, для нашого [вебсайту/додатку/послуги], включивши: ідентифікацію та контактні дані розпорядника даних, контактні дані DPO (якщо застосовується), цілі обробки, правову підставу для кожної мети, отримувачів або категорії отримувачів, деталі міжнародних передач, терміни зберігання або критерії, права суб'єктів даних (доступ, виправлення, видалення, обмеження, заперечення, перенесення, відкликання згоди), право подати скаргу до наглядового органу, чи є надання даних договірною/законодавчою вимогою, та деталі автоматизованого прийняття рішень (якщо застосовується). Зробіть його зрозумілим та доступним для неюридичної аудиторії."

Розробка внутрішньої політики конфіденційності

Для співробітників та внутрішніх процесів:

"Створіть внутрішню політику захисту даних для відповідності вимогам GDPR, яка охоплює: сферу застосування та застосовність політики, принципи захисту даних (законність, справедливість, прозорість, обмеження мети, мінімізація даних, точність, обмеження зберігання, цілісність/конфіденційність, підзвітність), ролі та обов'язки (DPO, власники даних, обробники), вимоги до обробки даних (збір, обробка, зберігання, видалення), зобов'язання щодо безпеки, процедури повідомлення про інциденти, процес виконання прав суб'єктів даних, вимоги до навчання та забезпечення виконання політики. Цільова аудиторія: всі співробітники."

Створення політики використання файлів cookie та механізму згоди

Для вебсайтів, що використовують файли cookie:

"Створіть політику використання файлів cookie для нашого вебсайту, яка пояснює: що таке файли cookie, які файли cookie ми використовуємо (необхідні, аналітичні, маркетингові), призначення кожного типу файлів cookie, сторонні файли cookie (Google Analytics тощо), як користувачі можуть керувати налаштуваннями файлів cookie та наслідки відмови від файлів cookie. Також надайте текст банера згоди на використання файлів cookie, що відповідає GDPR: детальні параметри згоди, заборона попередньо встановлених прапорців, легка можливість відмови."

Адаптація до конкретних суб'єктів даних

Різні повідомлення для різних контекстів:

"Створіть окремі повідомлення про конфіденційність для: 1) Відвідувачів вебсайту (перегляд, файли cookie), 2) Облікових записів клієнтів (надання послуг), 3) Підписників маркетингових розсилок (маркетингові комунікації), 4) Кандидатів на роботу (рекрутинг), 5) Співробітників (обробка HR-даних). Для кожного вкажіть: відповідні персональні дані, цілі обробки, правові підстави та терміни зберігання, специфічні для цього типу відносин."

Крок 4: Створення угод про обробку даних (DPA)

Коли потрібні DPA

Стаття 28 вимагає письмових контрактів з будь-якою третьою стороною, яка обробляє персональні дані від вашого імені (виконавці).

Генерація шаблону DPA

Створіть угоду між розпорядником та виконавцем:

"Створіть шаблон угоди про обробку даних (DPA) відповідно до статті 28 GDPR між нашою організацією (розпорядник) та [хмарним сервісом / платіжним процесором / інструментом для email-маркетингу] (виконавець). Включіть обов'язкові положення: предмет та тривалість обробки, характер та мета обробки, типи персональних даних та категорії суб'єктів даних, обов'язки та права розпорядника, обов'язки виконавця (вимоги статті 28(3): обробка лише за інструкціями, забезпечення конфіденційності, впровадження заходів безпеки, залучення суб-виконавців лише за згодою, допомога у реалізації прав суб'єктів даних, допомога у випадку інцидентів безпеки та DPIA, видалення або повернення даних після закінчення контракту, демонстрація відповідності). Зробіть її такою, що має юридичну силу та відповідає GDPR."

Визначення ваших виконавців

Інвентаризація третіх сторін, які обробляють ваші дані:

"Ми використовуємо такі сторонні сервіси: [перелік: AWS, Google Workspace, Stripe, Mailchimp, Zendesk тощо]. Для кожного визначте: чи є вони виконавцями даних або розпорядниками? До яких персональних даних вони мають доступ? Чи потрібна нам з ними DPA? Чи надають вони стандартні DPA? Які додаткові договірні захисти нам потрібні понад їхні стандартні умови?"

Робота з суб-виконавцями

Коли виконавці використовують власних виконавців:

"Наш виконавець [назва постачальника] використовує суб-виконавців для [послуг]. Які вимоги GDPR застосовуються? Складіть текст DPA, що охоплює: загальне дозвіл на суб-виконавців (з повідомленням) проти необхідності конкретного дозволу, відповідальність виконавця за відповідність суб-виконавців, зобов'язання накладати еквівалентні вимоги GDPR на суб-виконавців та наше право на аудит відповідності суб-виконавців."

Крок 5: Проведення оцінювання впливу на захист даних (DPIA)

Коли DPIA є обов'язковим

Стаття 35 вимагає проведення DPIA для обробки, яка ймовірно призведе до високого ризику, включаючи:

• Систематичну та масштабну автоматизовану обробку з юридичними/значними наслідками (профілювання)
• Масштабну обробку даних особливої категорії (медичні, біометричні дані тощо)
• Систематичне спостереження за публічно доступними зонами у великих масштабах (відеоспостереження)
• Нові технології або інноваційні методи обробки

Оцінка необхідності DPIA

Проаналізуйте вашу обробку:

"Ми обробляємо персональні дані для [опишіть діяльність: AI-оцінка клієнтів, додаток для моніторингу здоров'я, розпізнавання облич, поведінкова реклама]. Оцініть, чи потрібне оцінювання впливу на захист даних (DPIA) згідно зі статтею 35 GDPR. Врахуйте: чи є автоматизоване прийняття рішень з юридичними/значними наслідками? Чи є це масштабною обробкою? Чи залучені дані особливої категорії? Чи є систематичне спостереження? Чи використовується нова технологія? Надайте рекомендацію з обґрунтуванням."

Створення шаблону та процесу DPIA

Структуруйте оцінку впливу:

"Створіть шаблон DPIA для відповідності статті 35 GDPR, включивши розділи: опис операцій з обробки та цілей, оцінка необхідності та пропорційності, оцінка ризиків для прав і свобод суб'єктів даних (ймовірність та серйозність), заходи для усунення ризиків (технічні та організаційні), засоби захисту та заходи безпеки, а також демонстрація того, що ризики належним чином пом'якшені. Включіть методологію оцінки ризиків (матриця ймовірність × вплив)."

Проведення DPIA для конкретної обробки

Виконайте оцінку для високоризикових видів діяльності:

"Проведіть DPIA для нашої [AI-платформи аналітики клієнтів]. Деталі обробки: Ми аналізуємо дані про поведінку клієнтів (історія перегляду, шаблони покупок, демографічні дані) за допомогою машинного навчання для прогнозування ризику відтоку та персоналізації маркетингу. Суб'єкти даних: 100 000+ клієнтів з ЄС. Оцініть: Які ризики для прав суб'єктів даних (профілювання, дискримінація, вторгнення в приватне життя)? Які засоби захисту пом'якшують ці ризики (людський контроль, можливість відмови, прозорість, мінімізація даних)? Чи є залишковий ризик прийнятним, чи потрібно перепроектувати обробку?"

Консультації з DPO та зацікавленими сторонами

DPIA вимагають консультацій:

"Для нашого DPIA щодо [виду обробки] з ким ми повинні проконсультуватися? Складіть питання для консультацій з: DPO (оцінка відповідності), суб'єктів даних або їхніх представників (прийнятність обробки та засобів захисту), команди ІТ-безпеки (технічне пом'якшення ризиків), юридичної команди (юридична відповідність) та бізнес-зацікавлених сторін (необхідність та пропорційність). Як ми документуємо результати консультацій?"

Крок 6: Встановлення процедур реалізації прав суб'єктів даних

Розуміння прав суб'єктів даних (статті 15-22)

GDPR надає фізичним особам вісім прав:

1. Право на доступ (ст. 15): Отримати копію своїх персональних даних
2. Право на виправлення (ст. 16): Виправити неточні дані
3. Право на видалення / "Право бути забутим" (ст. 17): Видалити дані за певних обставин
4. Право на обмеження обробки (ст. 18): Обмежити обробку за певних умов
5. Право на перенесення даних (ст. 20): Отримати дані у машиночитному форматі
6. Право на заперечення (ст. 21): Заперечувати проти обробки, особливо для маркетингу
7. Права щодо автоматизованого прийняття рішень (ст. 22): Оскаржувати автоматизовані рішення
8. Право на відкликання згоди (ст. 7(3)): Відкликати згоду так само легко, як і надати її

Створення процедур виконання прав

Документуйте, як ви обробляєте кожне право:

"Створіть процедури обробки запитів щодо прав суб'єктів даних згідно з GDPR, включивши: процес прийому запитів (як користувачі можуть подавати запити, шаблон форми запиту), перевірку особи (як автентифікувати заявника), терміни відповіді (1 місяць як стандарт, продовження з обґрунтуванням), кроки виконання запитів для кожного типу прав, політику оплати (зазвичай безкоштовно, надмірні запити можуть потребувати оплати), критерії відмови (коли запити можуть бути відхилені, як обґрунтувати), вимоги до документування (журналювання всіх запитів та відповідей) та процес ескалації для складних запитів. Зробіть це операційним для команд підтримки клієнтів."

Розробка відповіді на запит про доступ (SAR)

Найпоширеніший тип запитів:

"Для запитів на доступ до даних згідно з GDPR створіть: 1) Формат експорту даних (яку інформацію включати: категорії даних, цілі, отримувачі, терміни зберігання, джерела, автоматизоване прийняття рішень), 2) Формат представлення даних (структурований, зрозумілий, у поширеному форматі), 3) Технічну реалізацію (як витягувати дані користувача з [ваших систем], форматувати їх, доставляти безпечно), 4) Шаблон листа-відповіді з поясненням наданих даних. Переконайтеся, що ми можемо виконувати запити протягом 30 днів."

Робота зі складнощами запитів на видалення

Видалення не завжди є простим:

"Для запитів на право бути забутим вирішіть: Коли ми можемо відмовити (юридичні зобов'язання, договірна необхідність, законні інтереси)? Які дані потрібно видалити, анонімізувати або зберегти? Як видалити з резервних копій? Як повідомити треті сторони, яким ми передавали дані? Як документувати видалення для аудиторського сліду? Створіть дерево рішень для оцінки запитів на видалення."

Крок 7: Розробка процедур повідомлення про інциденти

Розуміння вимог до повідомлень

Обов'язки щодо повідомлення про інциденти згідно з GDPR:

• Стаття 33 - Повідомлення DPA: Повідомляти про інциденти наглядовому органу протягом 72 годин (якщо малоймовірно, що це призведе до ризику)
• Стаття 34 - Повідомлення фізичних осіб: Повідомляти постраждалих осіб без зволікань, якщо існує високий ризик для їхніх прав і свобод

Створення плану реагування на інциденти

Підготуйтеся до інцидентів:

"Створіть процедуру реагування на інциденти з персональними даними згідно з GDPR, включивши: визначення інциденту (що вважається інцидентом з персональними даними), виявлення та звітування (як інциденти виявляються, внутрішня ескалація), оцінку інциденту (оцінка серйозності, ризик для фізичних осіб), робочий процес повідомлення DPA протягом 72 годин (яку інформацію надавати згідно зі статтею 33, шаблон повідомлення), процес повідомлення фізичних осіб (коли потрібно, шаблон комунікації, спосіб доставки), ведення реєстру інцидентів (журналювання всіх інцидентів згідно зі статтею 33(5)), аналіз після інциденту та ролі/обов'язки. Зробіть це дієвим під час тиску часу."

Створення шаблонів повідомлень

Підготуйте шаблони заздалегідь:

"Створіть два шаблони повідомлень про інциденти: 1) Повідомлення DPA (стаття 33), що включає: опис інциденту, категорії персональних даних та приблизну кількість постраждалих осіб, контактну особу (DPO), ймовірні наслідки, заходи, вжиті або запропоновані для усунення інциденту та пом'якшення шкоди. 2) Повідомлення фізичним особам (стаття 34) простою мовою, що описує: характер інциденту, контактну особу, ймовірні наслідки, вжиті/запропоновані заходи, рекомендовані дії для постраждалих осіб. Зробіть шаблони готовими до заповнення деталями інциденту."

Ведення реєстру інцидентів

Документуйте всі інциденти:

"Створіть шаблон реєстру інцидентів з персональними даними, що включає: ID інциденту, Дата виявлення, Дата повідомлення DPA (якщо застосовується), Опис інциденту, Персональні дані, що постраждали (категорії та обсяг), Кількість постраждалих осіб, Першопричина, Заходи з локалізації, Чи потрібно повідомляти DPA (Так/Ні/Оцінка), Чи потрібно повідомляти фізичних осіб (Так/Ні), Рівень ризику (Низький/Середній/Високий), Статус (Відкрито/Розслідується/Вирішено), Уроки. Цей реєстр необхідно вести навіть для інцидентів, які не повідомляються DPA."

Крок 8: Документування управління згодою

Коли згода є доречною

Згода (стаття 6(1)(a)) є ОДНІЄЮ з правових підстав, не завжди обов'язковою:

"Для наших видів обробки [перелік видів діяльності] визначте відповідну правову підставу: Згода (вільно надана, конкретна, усвідомлена, однозначна), Договір (необхідна для виконання договору), Юридичне зобов'язання (вимагається законом), Життєво важливі інтереси (життя або смерть), Публічне завдання (офіційні повноваження) або Законний інтерес (з тестом на збалансування). Для кожного виду діяльності рекомендуйте правову підставу з обґрунтуванням. Коли згода є правильним вибором порівняно з іншими підставами?"

Розробка механізмів дійсної згоди

Вимоги до згоди згідно з GDPR (стаття 7):

"Створіть механізми збору згоди, що відповідають вимогам GDPR: вільно надана (без пакетування, справжній вибір, відсутність негативних наслідків за відмову), конкретна (окремі згоди для різних цілей), усвідомлена (чітка інформація про обробку), однозначна (підтверджувальна дія, заборона попередньо встановлених прапорців), легка для відкликання (так само легко, як і надання), та документована (хто, коли, що, як). Розробіть форми згоди та банери файлів cookie відповідно."

Ведення записів про згоду

Стаття 7(1) вимагає підтвердження згоди:

"Створіть систему ведення записів про згоду, що документує: хто дав згоду (ідентифікатор суб'єкта даних), коли згоду було надано (часова позначка), на що було надано згоду (конкретна мета та опис обробки), як згоду було отримано (версія форми, текст прапорця), використаний механізм згоди (прапорець для підтвердження, явна дія), та статус згоди (активна, відкликана, закінчилася). Як ми зберігаємо та отримуємо ці дані для демонстрації відповідності?"

Крок 9: Проведення оцінювання законного інтересу (LIA)

Коли використовувати законний інтерес

Стаття 6(1)(f) дозволяє обробку для законних інтересів, якщо вони не переважають права суб'єктів даних:

"Поясніть законний інтерес як правову підставу згідно з GDPR. Коли він є доречним порівняно зі згодою або договором? Який трискладовий тест: 1) Тест мети (переслідується законний інтерес), 2) Тест необхідності (обробка необхідна для цього інтересу), 3) Тест на збалансування (інтереси не переважають права суб'єктів даних). Наведіть приклади, коли законний інтерес працює (запобігання шахрайству, прямий маркетинг для існуючих клієнтів, безпека мережі) та коли не працює (дані особливої категорії, дані дітей)."

Проведення тесту на збалансування

Документуйте оцінку законного інтересу:

"Створіть шаблон оцінки законного інтересу, що включає: опис виду обробки, переслідуваний законний інтерес (бізнес-інтерес або інтерес третьої сторони), аналіз необхідності (чи є обробка необхідною, чи існують менш нав'язливі альтернативи), тест на збалансування (характер та джерело законного інтересу, вплив на суб'єкта даних, обґрунтовані очікування, чутливість даних, впроваджені засоби захисту, результат збалансування), висновок (чи можна продовжувати обробку на підставі законного інтересу) та дату перегляду. Зробіть його таким, що витримає перевірку з боку DPA."

Приклад LIA для поширених сценаріїв

Застосуйте рамкову структуру:

"Проведіть оцінку законного інтересу для: надсилання маркетингових електронних листів існуючим клієнтам з пропозиціями подібних продуктів. Законний інтерес: [відносини з клієнтами, комерційний інтерес]. Необхідність: [як це необхідно для бізнесу]. Збалансування: [очікування клієнтів на основі відносин, легка можливість відмови, не чутливі дані, мінімальний вплив на приватність]. Висновок: [чи виправданий законний інтерес]? Які засоби захисту пом'якшують вплив (помітна можливість відписки, центр налаштувань, обмежена частота)?"

Крок 10: Інтеграція GDPR з іншими рамковими стандартами відповідності

Узгодження GDPR та ISO 27001

Багато вимог перетинаються:

"Зіставте вимоги GDPR з контрольними заходами Додатку A ISO 27001:2022. Для кожної вимоги GDPR (безпека даних, контроль доступу, повідомлення про інциденти, мінімізація даних, конфіденційність за замовчуванням) визначте: відповідні контрольні заходи ISO 27001, як впровадження контрольного заходу задовольняє GDPR, які додаткові специфічні для GDPR заходи потрібні понад ISO 27001. Створіть матрицю відповідності, що показує, де один рамковий стандарт задовольняє інший."

Узгодження GDPR та критеріїв конфіденційності SOC 2

Використовуйте критерії конфіденційності SOC 2:

"Як критерії конфіденційності SOC 2 підтримують відповідність GDPR? Зіставте вимоги GDPR (прозорість, права доступу, видалення, згода, DPIA) з критеріями конфіденційності SOC 2 (повідомлення, вибір, доступ, розкриття третім сторонам, безпека, зберігання). Які контрольні заходи служать обом цілям? Яка специфічна для GDPR документація потрібна понад SOC 2 Privacy?"

Створення інтегрованої програми відповідності

Уникайте дублювання роботи:

"Ми прагнемо відповідності як GDPR, так і сертифікації ISO 27001. Розробіть інтегровану програму відповідності, що включає: єдину політику інформаційної безпеки та конфіденційності, об'єднаний аналіз ризиків, що охоплює ризики безпеки та конфіденційності, інтегровану рамкову структуру контрольних заходів, консолідовану програму аудиту, спільне сховище доказів та об'єднаний інформаційний панель відповідності. Як нам документувати один раз та відповідати вимогам кількох рамкових стандартів?"

Поширені помилки в документації GDPR

Наступні кроки після документування

Ви створили комплексну документацію GDPR:

• ✓ Завершено реєстр діяльності з обробки даних (ROPA)
• ✓ Опубліковано повідомлення про конфіденційність та політики
• ✓ Укладено угоди про обробку даних з виконавцями
• ✓ Проведено DPIA для високоризикової обробки
• ✓ Встановлено процедури реалізації прав суб'єктів даних
• ✓ Готові процедури повідомлення про інциденти
• ✓ Документовано управління згодою
• ✓ Завершено оцінки законного інтересу

Підтримка постійної відповідності:

• Оновлюйте ROPA щоквартально та при додаванні нових видів обробки
• Переглядайте повідомлення про конфіденційність щорічно та після змін у обробці
• Проводьте щорічні DPIA для високоризикової обробки
• Відстежуйте обсяги запитів щодо прав суб'єктів даних та час відповіді
• Навчайте персонал вимогам GDPR та процедурам щорічно
• Ведіть реєстр інцидентів та проводьте тренування з реагування на інциденти

Отримання допомоги

• Завантаження документів: Дізнайтеся, як завантажувати політики конфіденційності для аналізу прогалин у GDPR
• Перевірка відповідності: Зрозумійте, як запобігти галюцинаціям ШІ при перевірці рекомендацій щодо GDPR
• Кращі практики: Ознайомтеся з як використовувати ISMS Copilot відповідально для документування конфіденційності