anonym.legal

By · Last updated 2026-06-05

Назад до блогуGDPR та відповідність

Провал аудиту GDPR: роздробленість інструментів для ПДн

Аудитор запитує про засоби виявлення ПДн. Відповідь «ми використовуємо п'ять різних інструментів» — не та, яку він хоче почути. Ось чому міжплатформна узгодженість є вирішальною.

June 5, 20266 хв читання
GDPR auditcompliance controlsPII tool consistencyDPA investigationtechnical measures

Провал аудиту GDPR: роздробленість інструментів для ПДн

Оновлено для 2026 року.

Аудитор задає одне запитання: «Які технічні заходи захищають персональні дані?» Неправильна відповідь: «Ми використовуємо п'ять різних інструментів». Ось чому п'ять інструментів не витримують аудиту GDPR — і як виглядає правильна відповідь.

Момент аудиту

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

Питання: «Які засоби контролю використовує ваша організація для захисту персональних даних під час їх обробки співробітниками?»

Спеціаліст з відповідності: «Наші юристи використовують надбудову Word. Співробітники служби підтримки — розширення Chrome. Команда з даних має Python-скрипт. Для разових запитів будь-хто може використовувати вебзастосунок.»

Інспектор: «Це один інструмент? Той самий рушій? Однакове охоплення?»

Спеціаліст з відповідності: «Ні. Вони працюють по-різному.»

Ось тут аудит ускладнюється.

Чому роздроблені інструменти не відповідають статті 32

Стаття 32 GDPR вимагає «відповідних технічних та організаційних заходів». Стандарт має дві складові.

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

Доказовість. Заходи мають бути доказовими. Стаття 5(2) — принцип підзвітності — вимагає від контролерів «бути здатними продемонструвати відповідність». Це означає докази послідовного контролю. Не максимально можливі зусилля. Саме послідовний контроль.

Роздроблені інструменти не витримують перевірки на доказовість. Інструмент A виявляє 285 типів сутностей. Інструмент B — 50. Інструмент C — 200, але з іншими пороговими значеннями. Ви не можете довести послідовний захист на основі такого набору. Можна лише показати, що в деяких контекстах запускалися певні інструменти.

Висновок OЗД щодо роздрібнених інструментів звучить так: «Технічні засоби захисту ПДн є непослідовними між різними робочими процесами. Це створює прогалини в охопленні та унеможливлює централізований перегляд журналу аудиту.»

Проблема прихованих прогалин

Часто ви не знаєте, де є прогалини в охопленні, доки не станеться порушення.

Припустімо, інструмент B (який використовує команда з даних) не виявляє національні ідентифікаційні номери ЄС. Інструмент A (який використовують юристи) — виявляє. Ця прогалина невидима під час звичайної роботи. Файли обробляються. Жодних сповіщень. Нічого підозрілого.

Прогалина виявляється, коли:

  • Національний ідентифікатор ЄС з'являється у файлі, обробленому командою з даних
  • Цей файл передається без засобів контролю
  • Суб'єкт даних виявляє розкриття і подає скаргу до GDPR

Тепер OЗД виявляє прогалину. Команда з даних використовувала інструмент з іншим охопленням, ніж інші команди. Прогалина, яку треба було виявити й усунути.

Єдине охоплення виправляє це. Ті самі типи сутностей виявляються в усіх контекстах. Прогалини стають видимими — нуль виявлень сутності X у будь-якому робочому процесі — замість того, щоб бути прихованими.

Читайте статтю GDPR, стаття 32 та моніторинг інструментів ШІ про те, що аудитори шукають у технічних засобах контролю.

Як виглядає правильна відповідь на аудиті

Спеціаліст з відповідності, який використовує єдину платформу, відповідає інакше.

«Ми використовуємо одну платформу для виявлення ПДн у всіх робочих процесах. Юристи, агенти служби підтримки та інженери з даних використовують один і той самий рушій виявлення. Інтерфейси відрізняються — надбудова Word, розширення Chrome, настільна програма — але модель і налаштування однакові. Усі операції обробки записуються в централізований журнал аудиту. Наше налаштування охоплює 285+ типів сутностей із пресетами відповідно до юрисдикції. Я можу надати дані за будь-який потрібний вам часовий проміжок.»

Ця відповідь:

  • Конкретна. Називає платформу та пояснює багатоплатформне налаштування.
  • Послідовна. Фраза «той самий рушій виявлення» безпосередньо відповідає на питання про охоплення.
  • Доказова. Централізований журнал аудиту означає готовність доказів за першим запитом.

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

Стандарт міжплатформної узгодженості

Для надійного виконання вимог статті 32 необхідні такі мінімальні вимоги.

Узгодженість виявлення:

  1. Та сама модель або API виявлення на всіх платформах
  2. Однакове охоплення типів сутностей — якщо вебзастосунок перевіряє 285 сутностей, настільна програма теж повинна
  3. Однакові порогові значення достовірності — жоден інструмент не є м'якшим чи суворішим для того самого типу сутностей
  4. Однакові замінні токени для тих самих типів сутностей
  5. Централізований журнал аудиту на всіх платформах

Вимоги до документації:

  • Знімок конфігурації: поточне охоплення сутностей і порогові значення
  • Історія змін: що змінилось і коли
  • Доказ охоплення: усі платформи використовують те саме налаштування

Це можна реалізувати для набору з кількох інструментів. Але це потребує формального управління конфігурацією та регулярних перехресних аудитів інструментів. Єдина платформа робить відповідь простою: «Ось налаштування. Воно застосовується скрізь. Ось журнал аудиту.»

Дивіться ширший огляд міжплатформної узгодженості у статті Міжплатформна відповідність ПДн: Mac, Linux, Windows.

Практичний перехід: від роздробленості до єдності

Крок 1: Картування інструментів та охоплення

  • Складіть список інструментів за командами та робочими процесами
  • Задокументуйте, які типи ПДн виявляє кожен інструмент
  • Знайдіть прогалини — що виявляє інструмент A, а інструмент B пропускає?

Крок 2: Визначення стандарту охоплення

  • На основі ваших зобов'язань — типи сутностей GDPR, PHI за HIPAA, категорії CCPA
  • Встановіть один стандарт, що застосовується до всіх робочих процесів

Крок 3: Вибір єдиної платформи

  • Чи може вона розгортатися у вебі, на настільному комп'ютері, у Word та браузері?
  • Чи відповідає вона вашому стандарту охоплення?
  • Чи надає вона централізований журнал аудиту?

Крок 4: Міграція

  • Починайте з робочих процесів найвищого ризику
  • Переходьте команда за командою й вимикайте застарілі інструменти в міру переходу
  • Фіксуйте міграцію у своєму журналі відповідності

Роздробленість інструментів — одна з найпоширеніших прогалин у засобах контролю GDPR, яку виявляють аудити. Про те, як вона проявляється в розподілених командах, читайте у статті Дистанційна робота та GDPR: непослідовність платформ.

Джерела

Готові захистити свої дані?

Почніть анонімізувати PII з 285+ типами сутностей на 48 мовах.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.