Стаття 30 хоче реєстр. А не папку.

Що це заміняє

• Ваш реєстр за статтею 30 — таблиця, якої не торкалися рік.
• DPIA написали як документ, підшили і забули.
• Тридцять днів на відповідь по запиту, який упав у спільну скриньку.

Що ви робите тут

• 1Ведіть реєстр за статтею 30 як дані.Кожна операція обробки — рядок, який ви створюєте й редагуєте, тож на запит наглядового органу відповідає сам реєстр.Record of Processing Activities
• 2Проведіть DPIA через перегляд.Створіть, відредагуйте, перегляньте іменовану оцінку. Рішення щодо високоризикової обробки стає записом, який ви відкриєте наступного року.DPIA
• 3Розкладіть запит субʼєкта даних на задачі.Запит розпадається на список задач і закривається згенерованою відповіддю — простір відкривається за окремим дозволом, а не з меню.DSAR response builder
• 4Реєструйте кожного процесора, якому передаєте дані.Процесори, згоди і список субʼєктів даних лежать поруч із записами за статтею 30, а не в трьох окремих трекерах.Processor register
• 5Згенеруйте політику конфіденційності для публікації.Генератор політик видає документ, який віддає ваш сайт, і ведеться він там само, де реєстр.Policy generator
• 6Випустіть банер cookie звідти ж.Конструктор банерів пише повідомлення; текст згоди перестає розходитися із записом обробки, що стоїть за ним.Cookie banners

Що змінюється

• Один набір даних покриває операції обробки, DPIA, згоди і процесорів: чотири артефакти, одне місце для оновлення.
• Запит субʼєкта даних стає розкладом на задачі і згенерованою відповіддю в тому самому записі.
• Генератор політик і конструктор банерів заміняють два документи, які ви вели руками.

Де роль закінчується

Приватність, комплаєнс і папери навколо них. Ви шукатимете реєстр ризиків, екрани активів чи Trust Center — жодне з трьох не ваше.