Оцінка впливу на захист даних (ст. 35 GDPR)

Цей документ опубліковано кількома мовами. У разі будь-яких розбіжностей між мовними версіями обов’язковою є польська версія.

Версія 1.1 · Останнє оновлення: 23 жовтня 2026 року

1. Про що йдеться та чим є ця сторінка

Ця сторінка є оцінкою впливу formexposed на захист даних (DPIA) за ст. 35 GDPR. Спочатку вона відповідає на попереднє запитання, чи взагалі потрібна оцінка впливу, — окремо для кожної операції обробки, а не для сервісу загалом. Якщо відповідь ствердна, вона виконує оцінку за ст. 35(7)(a)–(d): систематичний опис, необхідність і пропорційність, ризики для суб’єктів даних і заходи для їх усунення. Далі наведено залишковий ризик, питання попередньої консультації за ст. 36 та правила перегляду.

Ст. 35 не вимагає публікувати оцінку впливу. Ми публікуємо її з двох причин. По-перше, Клієнтам, які використовують перевірку доставки або сканування захищеної входом частини сайту, для власної оцінки потрібні факти, відомі лише нам; ми в будь-якому разі зобов’язані надавати їх як обробник (ст. 28(3)(f) GDPR). По-друге, наш сканер перевіряє сайти, оператори яких нас не знають. Вони повинні мати змогу прочитати, які ризики ми бачимо для них і людей на їхніх сторінках та що робимо щодо цих ризиків.

Правова природа. Ця оцінка впливу є документацією контролера за ст. 35 GDPR, яку ми публікуємо добровільно. Вона не є частиною жодного договору й не становить жодного запевнення, гарантії чи домовленості щодо якості перед Клієнтами або третіми особами. Які послуги й заходи захисту ми зобов’язані надавати Клієнтам, регулюють Умови надання послуг, Договір про обробку даних і його додатки; щодо цих зобов’язань вони мають перевагу над цією сторінкою. Сторінка описує стан на дату цієї версії. Рівні ризиків та оцінки є нашою власною думкою й не визначають наперед правової оцінки наглядового органу чи суду; заходи, описані як «заплановані», є намірами без зобов’язання щодо дати. Для Клієнтів сторінка є основою власної оцінки, а не юридичною консультацією.

Це перша версія порогової оцінки. Вона розглядає кожну операцію обробки окремо щодо необхідності оцінки впливу й фіксує результат у розділі 3.5.

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

Терміни: оператор — той, хто керує перевіреним сайтом. Клієнт має обліковий запис у formexposed. Відвідувач — той, хто використовує сайт Клієнта, наприклад його контактну форму. Посилання на джерело означає файл, функцію чи налаштування у вихідному коді, виміряні щодо стану системи розроблення 11 жовтня 2026 року.

Ми свідомо встановлюємо одну межу відкритості: відкриті питання захисту наших власних серверів описуються лише загально (R13). Ми називаємо ризик і його рівень, але не шлях до конкретної вразливості; подробиці надамо наглядовому органу на запит.

2. Ролі: хто й щодо чого несе обов’язок

Ст. 35 покладає обов’язок на контролера. formexposed є контролером для одних операцій обробки, обробником своїх Клієнтів для інших і не є ані тим, ані іншим для даних, які наш плагін WordPress і наше розширення TYPO3 зберігають на сайті Клієнта. Відповідь майже на кожне запитання в цьому документі залежить від того, щодо якої ролі його поставлено. Розподіл відповідає Політиці конфіденційності й Договору про обробку даних.

Операція обробки	Роль formexposed	Хто несе обов’язок за ст. 35
Перевірка сторонніх сайтів без вказівок їхнього оператора: безкоштовна перевірка, перевірка потенційного клієнта для агентств, дослідження	Контролер	formexposed
Перевірка доменів в обліковому записі Клієнта: моніторинг, активні тестові надсилання, браузерні сценарії, відкриті файли, пульс форми	Контролер щодо облікового запису й даних перевірок Клієнта; обробник щодо персональних даних третіх осіб, видимих на підтвердженому сайті Клієнта; доки домен не підтверджено — контролер, як у безкоштовній перевірці	formexposed для своєї частини; Клієнт для даних третіх осіб на своєму сайті
Сканування захищеної входом частини сайту з тестовим обліковим записом	Обробник: облікові дані й вміст після входу належать сайту Клієнта	Клієнт; formexposed допомагає
Перевірка доставки з контрольною копією	Обробник	Клієнт; formexposed допомагає
Колективний захист: спільний список доменів посилань із заблокованого спаму	Контролер: ми поєднуємо повідомлення багатьох сайтів, формуємо список і поширюємо його	formexposed
Облікові записи клієнтів, вхід, журнали, підтримка, надсилання пошти, платежі, доказові записи	Контролер	formexposed
Клієнтський портал і щомісячний звіт підписникам агентства	Обробник	Агентство
Дані, які плагін і розширення зберігають на сайті Клієнта (карантин, резервне збереження листів, збережені звернення)	Жодна з ролей: дані ніколи не залишають сайту	Оператор сайту

Звідси випливає розмежування, яке ми зазначаємо прямо, оскільки його часто неправильно розуміють в обидва боки. Коли formexposed є контролером, ми виконуємо оцінку самі й несемо відповідальність за її результат. Коли ми є обробником, ми не можемо виконати оцінку Клієнта замість нього, вирішити за нього питання необхідності або консультуватися з наглядовим органом за ст. 36 від його імені. Те, що ми можемо й повинні зробити, — надати все необхідне: опис за підпунктом (a), виміряні факти щодо ризиків за підпунктом (c) та чесний перелік стану заходів за підпунктом (d). Для перевірки доставки й сканування захищеної входом частини сайту ця сторінка є саме цим.

Клієнт, який без змін приймає розділи про перевірку доставки як власну оцінку впливу, її не виконав. Чи виправдана контрольна копія для його форм, чи слід очікувати там особливих категорій персональних даних і як він інформує своїх відвідувачів — питання, які може вирішити лише він. Розділ 11 підсумовує, що потрібно для цього з’ясувати.

3. Порогова оцінка: чи потрібна оцінка впливу?

3.1 Ст. 35(1) і ст. 35(3)

Ст. 35(1) вимагає оцінки впливу, якщо певний тип обробки, зокрема із застосуванням нових технологій, з урахуванням характеру, обсягу, контексту й цілей обробки ймовірно призводить до високого ризику для прав і свобод фізичних осіб. Ст. 35(3) називає три випадки, коли це зокрема так. Жоден із трьох не відповідає formexposed, і це слід обґрунтувати, а не просто ствердити:

• Підпункт (a) — систематичне й усебічне оцінювання особистих аспектів фізичних осіб на основі автоматизованої обробки, на якому ґрунтуються рішення з правовими наслідками або подібним істотним впливом на них. Ми оцінюємо форми й сайти, а не особисті аспекти людей. Сервіс не приймає рішень із правовим впливом на будь-яку особу. Найближчим є колективний захист: повідомлення з посиланням на домен зі списку потрапляють до карантину на з’єднаних сайтах. Це автоматизований наслідок для повідомлення, а не всебічна оцінка особи; ми розглядаємо це за критерієм «Оцінювання або присвоєння балів» у розділі 3.3.
• Підпункт (b) — масштабна обробка особливих категорій за ст. 9 або даних про кримінальні правопорушення за ст. 10. Не передбачено й не реалізовано. Такі дані все ж можуть надходити до нас одним шляхом: у контрольній копії справжніх повідомлень відвідувачів у перевірці доставки. Це залежить від окремого випадку й не є масштабною обробкою в розумінні цього положення; однак враховується в оцінці ризику (R1).
• Підпункт (c) — систематичний масштабний моніторинг публічно доступної зони. Це означає фізичне спостереження за місцями, а не отримання публічних вебсторінок. Посилатися на це положення як підставу для сканера сайтів було б неправильно.

Тому правильним шляхом є сама ст. 35(1), застосована через дев’ять критеріїв Настанов Робочої групи статті 29 щодо оцінки впливу на захист даних (WP248 rev.01, схвалених Європейською радою із захисту даних), і перелік польського наглядового органу за ст. 35(4) (розділ 3.4).

3.2 Дев’ять критеріїв настанов WP248

Настанови називають дев’ять ознак, які вказують на ймовірний високий ризик. За орієнтовним правилом операція обробки, яка відповідає двом із них, у більшості випадків потребуватиме оцінки впливу. Контролер може дійти іншого висновку в окремому випадку, але тоді повинен обґрунтувати й задокументувати його. І навпаки, одного критерію може бути достатньо. На цій сторінці ми використовуємо такі короткі позначення:

1. C1 — Оцінювання або присвоєння балів, включно з профілюванням і прогнозуванням, наприклад результатів праці, економічного становища, надійності чи поведінки.
2. C2 — Автоматизоване прийняття рішень із правовим або подібним істотним впливом.
3. C3 — Систематичний моніторинг, тобто обробка для спостереження, моніторингу чи контролю суб’єктів даних, зокрема через мережі. Настанови прямо обґрунтовують цей критерій тим, що суб’єкти даних часто не знають, хто збирає їхні дані й для якої мети.
4. C4 — Чутливі дані або дані суто особистого характеру: особливі категорії за ст. 9 і 10, а також дані, розкриття яких істотно впливає на повсякденне життя, включно з електронними комунікаціями, конфіденційність яких слід захищати.
5. C5 — Масштабна обробка даних, виміряна кількістю суб’єктів даних, обсягом і діапазоном даних, тривалістю й географічним охопленням.
6. C6 — Зіставлення або поєднання наборів даних, які походять із різних операцій обробки чи від різних контролерів, способом, якого суб’єкти даних не очікували б.
7. C7 — Дані про вразливих суб’єктів даних, наприклад працівників, дітей, пацієнтів або інших осіб у ситуації нерівності сил.
8. C8 — Інноваційне використання або застосування нових технологічних чи організаційних рішень; у наглядовій практиці використання штучного інтелекту регулярно відносять до цього критерію.
9. C9 — Обробка, що перешкоджає суб’єктам даних здійснювати право або користуватися послугою чи договором.

Ми оцінюємо кожний критерій як «виконується», «граничний випадок» або «не виконується» й обґрунтовуємо оцінку кодом. Граничний випадок не зараховується як виконаний у підсумку, але називається в результаті; коли кілька граничних випадків указують в одному напрямі, ми включаємо операцію обробки до оцінки.

3.3 Оцінка за операцією обробки

P1 — Безкоштовна перевірка без облікового запису (перевірка будь-якого стороннього сайту на запит)

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

• C1 — граничний випадок. Звіт оцінює захист форми рівнем («Незахищено», «Частково захищено», «Захищено») й оцінкою ризику. Для товариства з обмеженою відповідальністю це не стосується фізичної особи. Для фізичних осіб — підприємців і фрилансерів домен може бути пов’язаний з особою, і тоді рівень говорить щось про обачність у її професійній діяльності. Однак оцінюється технічне налаштування, а не поведінка чи характеристики особи. Ми розглядаємо це як граничний випадок.
• C2 — не виконується. Щодо оператора нічого не вирішується. Щодо особи, яка запитує перевірку, застосовуються ліміти за IP-адресою й сеансом (cfg/check_lib.php); відхилена перевірка не має істотного впливу.
• C3 — не виконується. Це одиничне отримання на запит, щонайбільше раз на домен і тиждень (cfg/check_lib.php, налаштування fc_domain_days = 7). За людьми не спостерігають. Однак обставина, яку настанови наводять для обґрунтування C3, — суб’єкти даних нічого не знають про обробку — наявна. Вона враховується в оцінці ризику (R5).
• C4 — не виконується. Зберігаються структура форми й результати перевірки, а не введені значення (scanner/src/crawl.js зберігає для видимих полів лише довжину значення). Початки попередньо заповнених прихованих полів (до 24 символів) і атрибутів даних (до 60 символів) сканер читає лише під час перевірки для виявлення токенів і позначок часу; вони не зберігаються. Знімки екрана можуть випадково показувати людей та імена; сайт медичної практики показує на зображенні її спеціалізацію. Це публічні професійні відомості, а не дані про здоров’я конкретної особи.
• C5 — граничний випадок. Щоденний ліміт — 200 прийнятих перевірок (fc_daily_cap), тобто арифметично до приблизно 73 000 сайтів на рік. На кожному сайті виникає лише кілька елементів персональних даних, а тривалість коротка (30 днів). За вимірюванням у системі розроблення в наборі даних є 2 анонімні перевірки. Сьогодні не виконується; граничний випадок з огляду на спроєктовану потужність.
• C6 — не виконується. Крім отримання сторінок, сервіс запитує вік домену через сервіс RDAP rdap.org (передається лише доменне ім’я; зберігається, із кешуванням, лише дата реєстрації) та виконує визначення DNS. Це технічні відомості про домен, а не поєднання наборів даних про людей.
• C7 — не виконується.
• C8 — виконується в слабкій формі. Автоматизований браузер перевіряє сторінки, а мовна модель на нашому власному сервері класифікує форми, які не розпізнають правила (scanner/src/classify.js). Модель бачить заголовок сторінки, адресу, підписи полів і до 400 символів тексту форми. Вона ніколи не може дозволити надсилання форми.
• C9 — не виконується.

Проміжний результат P1: один критерій у слабкій формі (C8), два граничні випадки (C1, C5). Обов’язку за орієнтовним правилом немає. Оскільки обидва граничні випадки вказують в одному напрямі й суб’єкти даних нічого не знають про обробку, ми включаємо P1 до оцінки.

P2 — Перевірка потенційного клієнта для агентств

Агентство на тарифі Business із налаштованим власним брендом може замовити пасивну перевірку сайту потенційного клієнта. Воно отримує короткий висновок під своїм брендом і докладний звіт та самостійно передає посилання (cfg/akquise_lib.php). Ми ні до кого не звертаємося.

• C1 — граничний випадок, сильніший, ніж для P1. Короткий висновок прямо призначений як «привід для першої розмови». Отже, оцінка сайту стає основою для комерційного звернення до особи.
• C5 — не виконується. Щонайбільше 30 перевірок на агентство за місяць (prospect_monthly), видалення через 90 днів.
• C8 — виконується в слабкій формі (та сама технологія, що й P1).
• Інші критерії — не виконуються. Висновок представлено під брендом агентства, але не пов’язано з іншими даними про оператора.

Проміжний результат P2: обов’язку за орієнтовним правилом немає; включено з тих самих причин, що й P1, та тому, що мета — залучення клієнтів — має власний ризик (R6).

P3 — Дослідження «Індекс безпеки форм»

Для дослідження перелік сайтів перевіряється пасивно, з обмеженням щонайбільше п’ятьма відкритими завданнями за запуск процесу перевірки стану, який працює кожні п’ять хвилин (cfg/studie_lib.php). Публікуються лише сукупні показники, а сегменти — лише від 20 сайтів із формою (study_min_segment, cfg/studie_lib.php). Сирі дані видаляються під час публікації (cfg/studie_lib.php).

• C5 — граничний випадок, виконується для великих переліків. Розмір переліку не обмежено в коді; обмеження інтенсивності арифметично дозволяє понад тисячу перевірок на день. Дослідження національного ринку охоплює тисячі сайтів, багато з яких ведуть фізичні особи — підприємці. Від такого розміру ми вважаємо критерій виконаним.
• C8 — виконується в слабкій формі.
• C1 — не виконується. Хоча окремий сайт оцінюється, публікується лише сукупний показник; оцінка не слугує для твердження про окремого оператора.
• Інші критерії — не виконуються.

Проміжний результат P3: для досліджень спроєктованого розміру — два критерії (C5, C8). Тому дослідження досягає порогу; formexposed виконує оцінку як контролер. За вимірюванням у системі розроблення досі не створено жодного дослідження.

P4 — Перевірка доменів в обліковому записі Клієнта

Клієнт замовляє регулярні перевірки доменів у своєму обліковому записі. Після доведення права контролювати домен додаються активні тестові надсилання (щонайбільше п’ять за перевірку), пошук відкритих для доступу файлів і налаштовані браузерні сценарії.

• C3 — не виконується. Перевірка запланована й періодична, але стосується власного сайту Клієнта та виконується на його запит, а не для спостереження за людьми.
• C4 — граничний випадок, ні. Пошук відкритих файлів читає щонайбільше перші 8 KB зі шляхів на кшталт /backup.sql або журналу налагодження, щоб за вмістом визначити, чи файл справді відкритий (cfg/dateien_lib.php). Такий фрагмент може містити записи форм, зроблені відвідувачами. Він перевіряється лише в пам’яті й ніколи не зберігається; зберігаються шлях, тип і серйозність.
• C8 — виконується в слабкій формі.
• Інші критерії — не виконуються.

Доданий етап плану дій. Платні звіти, для яких це доступно, можуть містити локально згенерований рекомендаційний текст на основі вибраних результатів перевірки й метаданих сканування. Він зберігається разом із перевіркою й відображається з позначенням ШІ; визначальними залишаються окремі результати перевірки. Він не змінює сайти автоматично й не приймає рішень про людей із правовим або подібним істотним впливом. Саме лише використання мовної моделі не визначає, чи потрібна окрема оцінка впливу. Її вхідні дані, одержувачів, масштаб і залишкові ризики потрібно оцінювати разом з основною перевіркою, зокрема можливе повторення персональних даних з URL або приміток та неправильні рекомендації у звіті, доступному за переданим посиланням. Розділи 7–9 нижче охоплюють цей етап; цей фактичний додаток не стверджує завершеного вимірювання в робочій системі, схвалення власником або нової оцінки залишкового ризику.

Проміжний результат P4: основна технічна перевірка не досягає порогу за описаними вище фактами. Доданий локальний рекомендаційний етап сам по собі не встановлює окремого обов’язку, але попередній пороговий результат не замінює розгляду його фактичних вхідних даних, масштабу, одержувачів і наслідків. Включено тому, що активні тестові надсилання й перевірка файлів залежать від підтвердження, яке ніколи не поновлюється (R7).

P5 — Сканування захищеної входом частини сайту

Для підтвердженого домену Клієнт може зберегти тестовий обліковий запис свого сайту. Сканер входить із ним і читає форми на щонайбільше п’яти визначених сторінках області учасників (cfg/login_lib.php, scanner/src/login.js).

• C4 — граничний випадок. Облікові дані не є даними суто особистого характеру в розумінні настанов, але їх неналежне використання відкриває область учасників. Залежно від сайту після входу може бути конфіденційний вміст, наприклад у порталі учасників чи пацієнтів. Це залежить від Клієнта, а не від нас.
• C8 — не виконується. Автоматизовані входи поширені в сервісах моніторингу.
• Інші критерії — не виконуються.

Проміжний результат P5: обов’язку за орієнтовним правилом немає. Для Клієнтів, чия область учасників показує конфіденційний вміст, це може змінитися; тоді рішення належить їм. Включено через ризики безпеки (R8).

P6 — Перевірка доставки з контрольною копією

Клієнт додає контрольну адресу formexposed як приховану копію до поштових налаштувань своєї форми. Унаслідок цього кожний лист із форми також надходить до нашої контрольної скриньки — і наше тестове повідомлення, і кожне справжнє повідомлення відвідувача. Автоматизоване отримання читає заголовки й перші 8 KB, відносить лист до домену, оцінює SPF, DKIM і DMARC та видаляє його (cfg/zustellung_lib.php).

• C4 — виконується. Те, що відвідувачі пишуть у контактній формі, є електронною комунікацією з підприємством із довільним вмістом. На сайті медичної практики, юридичної фірми, консультативної служби чи школи слід очікувати даних за ст. 9 або даних про дітей. Настанови прямо називають конфіденційні електронні комунікації в межах цього критерію.
• C3 — граничний випадок, радше виконується. Кожне повідомлення планово й безперервно копіюється та автоматично оцінюється без відома відправника. Мета — перевірка поштового шляху, а не спостереження за людьми. Однак обставина, якою настанови обґрунтовують критерій, — суб’єкти даних не знають, хто отримує їхні дані, — повністю наявна, доки Клієнт не інформує своїх відвідувачів.
• C7 — залежно від Клієнта. Пацієнти, клієнти юридичних фірм, кандидати на роботу, батьки й учні часто перебувають у залежності від одержувача свого повідомлення.
• C5 — граничний випадок, ні. Для окремого Клієнта обробка не масштабна. У formexposed копії багатьох Клієнтів сходяться в одній скриньці; це збільшує вагу порушення, а не кількість на одного контролера.
• Інші критерії — не виконуються. Віднесення до домену й тесту не є зіставленням наборів даних про людей; технологія не нова.

Проміжний результат P6: C4 виконується, C3 — граничний випадок і радше виконується, C7 виконується для багатьох типових Клієнтів. Тому в типовій конфігурації виконуються два чи більше критеріїв. Оцінка впливу потрібна — як обов’язок Клієнта, який є контролером. Розділи 6–11 надають йому факти для цього.

P7 — Колективний захист

З’єднані сайти WordPress раз на день повідомляють домени посилань із повідомлень, які зупинив їхній рівень захисту. Домен, який з’являється щонайменше на трьох різних сайтах із щонайменше п’ятьма спрацюваннями протягом семи днів, потрапляє до спільного списку; список надсилається назад усім з’єднаним сайтам, які потім поміщають повідомлення з посиланнями на цей домен у карантин (cfg/swarm_lib.php).

• C6 — виконується. Повідомлення багатьох взаємно незалежних сайтів, тобто різних контролерів, поєднуються й повертаються всім їм як спільний список.
• C1 — виконується тією мірою, якою домен можна пов’язати з фізичною особою. Список є класифікацією як джерела спаму. Настанови називають перевірку за спільною базою шахрайства прикладом цього критерію. Більшість доменів у такому списку належать підприємствам або є одноразовими; однак туди може потрапити домен особи — правомірно чи через навмисно підкладені хибні повідомлення.
• C9 — граничний випадок. Повідомлення з посиланням зі списку не надходить одержувачу негайно, а перебуває в його карантині до розблокування. Воно не втрачається.
• C2 — не виконується. Карантин є автоматизованим наслідком для повідомлення без правового впливу та з розблокуванням людиною-одержувачем.
• Інші критерії — не виконуються. IP-мережі вимкнені (swarm_ip_enabled = 0, cfg/swarm_lib.php).

Проміжний результат P7: два критерії (C6, C1) і один граничний випадок (C9). Порогу досягнуто; formexposed виконує оцінку як контролер. З увімкненими IP-мережами C1 і C6 виконувалися б без обмежень; їх увімкнення потребує нової версії цієї оцінки (розділ 12). За вимірюванням у системі розроблення немає ані повідомлень, ані записів у списку.

P8 — Облікові записи клієнтів, вхід, журнали, підтримка, пошта, платежі

• C1 і C9 — не виконуються. Підозріла поведінка в безкоштовній перевірці призводить до примітки з IP-адресою (cfg/check_lib.php) та, за потреби, відхилення подальших перевірок. Це запобігання зловживанням із незначним впливом, а не оцінювання особистих аспектів.
• Інші критерії — не виконуються. Це звичайні дані сервісу для підприємств.

Проміжний результат P8: оцінка впливу не потрібна. Операції обробки описано в Реєстрі діяльності з обробки.

P9 — Показники плагінів, помилки полів, записувач, значок, клієнтський портал, «Fix it for me»

• Плагін і розширення передають щоденні показники, перелік плагінів і категорії помилок, а плагін WordPress додатково передає домени посилань для колективного захисту (типово ввімкнено) (P7), без вмісту, адрес, імен чи IP-адрес відвідувачів; записувач утримує селектори в браузері адміністратора щонайбільше 15 хвилин. Жоден критерій не виконується.
• Під час завантаження значок передає звичайні дані з’єднання до журналу вебсервера, без cookie. Жоден критерій не виконується.
• Клієнтський портал обробляє адреси електронної пошти підписників із подвійним підтвердженням підписки від імені агентства. Жоден критерій не виконується.
• «Fix it for me» доручає мовній моделі на нашому власному сервері переписати вставлений код форми; код не зберігається. C8 у слабкій формі, більше нічого.

Проміжний результат P9: оцінка впливу не потрібна.

3.4 Перелік польського наглядового органу за ст. 35(4)

Компетентний орган — Голова Управління захисту персональних даних (Prezes Urzędu Ochrony Danych Osobowych, UODO). Голова опублікував перелік видів операцій обробки, які потребують оцінки впливу, у повідомленні від 17 червня 2019 року (Komunikat Prezesa Urzędu Ochrony Danych Osobowych z dnia 17 czerwca 2019 r. w sprawie wykazu rodzajów operacji przetwarzania danych osobowych wymagających oceny skutków przetwarzania dla ich ochrony, Monitor Polski 2019, пункт 666). Перелік зіставляє свої записи з критеріями настанов WP248, наводить приклади й прямо не є вичерпним; він не замінює оцінки за ст. 35(1).

За нашим прочитанням наведені види обробки в переліку за суттю відповідають операціям обробки formexposed:

Вид обробки за переліком (переказ)	Відповідний критерій	Операція обробки в formexposed	Оцінка
Порівняння, оцінювання або висновки на основі аналізу даних із різних джерел	C6	P7 Колективний захист	застосовується
Оцінювання або присвоєння балів, включно з профілюванням	C1	P7 Колективний захист; P1 і P2 як граничні випадки	застосовується до P7
Обробка особливих категорій персональних даних	C4	P6 Перевірка доставки	застосовується залежно від Клієнта
Інноваційне використання або застосування технологічних рішень	C8	P1–P4 (мовна модель для класифікації)	застосовується в слабкій формі
Масштабна обробка	C5	P3 Дослідження	застосовується до великих переліків
Систематичний моніторинг публічно доступних місць, зокрема з розпізнаванням ознак	C3	–	не застосовується: маються на увазі місця, а не сайти

Це зіставлення є прочитанням, а не цитатою; формулювання записів слід звірити з ним під час юридичної перевірки. Воно підтверджує результат розділу 3.3, але не змінює його. Наскільки нам відомо, UODO не опублікувало переліку за ст. 35(5) — операцій обробки, для яких оцінка впливу не потрібна.

3.5 Результат порогової оцінки

Операція обробки	Виконується	Граничний випадок	Результат
P1 Безкоштовна перевірка	C8 (слабко)	C1, C5	не обов’язкова; включено
P2 Перевірка потенційного клієнта	C8 (слабко)	C1	не обов’язкова; включено
P3 Дослідження	C8 (слабко), C5 для великих переліків	–	потрібна (обов’язок formexposed)
P4 Перевірка доменів Клієнта	C8 (слабко)	C4 (перевірка файлів)	не обов’язкова; включено
P5 Сканування захищеної входом частини сайту	–	C4	не обов’язкова; включено; для Клієнта залежно від вмісту
P6 Перевірка доставки	C4; C7 залежно від Клієнта	C3 (радше виконується), C5	потрібна (обов’язок Клієнта; ця сторінка допомагає за ст. 28(3)(f))
P7 Колективний захист	C6, C1	C9	потрібна (обов’язок formexposed)
P8 Облікові записи, журнали, підтримка, платежі	–	–	не потрібна
P9 Показники плагінів, значок, портал, «Fix it for me»	C8 (слабко, лише «Fix it for me»)	–	не потрібна

Результат щодо ст. 35(1): для окремих операцій обробки formexposed потрібна оцінка впливу. Вона потрібна для колективного захисту й досліджень спроєктованого розміру, і formexposed виконує її як контролер. Для перевірки доставки вона потрібна в типовій конфігурації, але як обов’язок Клієнта; formexposed надає основу. Для інших перевірок сторонніх і власних сайтів вона не обов’язкова. Однак ми включаємо їх, оскільки вони використовують ту саму технологію, кілька граничних випадків указують в одному напрямі, а суб’єкти даних — оператори без облікового запису й особи на перевірених сторінках — нічого не знають про обробку. Для облікових записів, журналів, підтримки й платежів оцінка не потрібна.

Тому розділи 6–10 застосовуються до P1–P7. Якщо твердження стосується лише однієї з цих операцій обробки, це позначено.

4. Фахівець із захисту даних: оцінка за ст. 37

Фахівця із захисту даних не призначено. Ст. 37(1) однаково зобов’язує контролера й обробника; тому це наше власне питання. Три законодавчі випадки:

Ст. 37(1)	Умова	Результат
підпункт (a)	Орган або установа публічної влади	Не застосовується; LW IT Solutions Company Lukas Wójcik є приватним одноосібним підприємством.
підпункт (b)	Основна діяльність складається з операцій обробки, які потребують регулярного й систематичного масштабного моніторингу суб’єктів даних	Основна діяльність — перевірка й моніторинг сайтів і форм, регулярно й систематично. Однак людей не відстежують: сканер не спостерігає за поведінкою, а перевірка доставки оцінює листи лише щодо доставки й автентичності. Не виконується.
підпункт (c)	Основна діяльність складається з масштабної обробки даних за ст. 9 або 10	Не за задумом. Особливі категорії можуть надходити до нас через контрольну копію перевірки доставки; це випадково, а не основна діяльність. Не виконується.

Тому, за нашою оцінкою, обов’язку призначати такого фахівця немає. Чи вимагає польське право призначення понад це за ст. 37(4) — відкрите питання юридичної перевірки. Оскільки фахівця із захисту даних не призначено, консультація за ст. 35(2) не застосовується. Якщо юридична перевірка встановить обов’язок призначення, консультацію призначеного тоді фахівця із захисту даних буде отримано перед схваленням цієї оцінки (розділ 12). Контактна особа для запитань щодо цієї оцінки — власник за адресою contact@lukaswojcik.com.

5. Метод, джерела й обмеження цієї версії

Факти в цьому документі походять із вихідного коду застосунку й сканера, схеми бази даних, кількості рядків і налаштувань системи розроблення, виміряних 11 жовтня 2026 року. Доступ до бази даних і серверів здійснювався лише для читання. Якщо вимірювання суперечить наміру, зокрема твердженню в наших власних правових документах, ми повідомляємо вимірювання. Ми не застосовуємо схвалених кодексів поведінки за ст. 40, дотримання яких потрібно було б враховувати за ст. 35(8).

• Виміряно систему розроблення. Сервіс ще не запущено. Тому показники малі й частково є артефактами тестування: 112 перевірок, 110 із них без домену Клієнта; 432 знімки екрана; 2 домени, 1 із них підтверджений; жодної ввімкненої перевірки доставки; жодного збереженого тестового облікового запису для сканування захищеної входом частини сайту; жодного дослідження; жодних повідомлень у колективному захисті. Вимірювання слід повторити перед запуском і регулярно після нього.
• Не виміряно в цій версії й потрібно додати перед схваленням: конфігурацію робочої системи, зокрема чи та як налаштована контрольна скринька та чи налаштована там пара ключів для сканування захищеної входом частини сайту; чи програмне забезпечення мовної моделі журналює запити; стан адміністрування серверів (R13); договір із постачальником електронної пошти.
• Неможливо було виміряти, скільки справжніх повідомлень відвідувачів проходитиме через контрольну копію й із яких галузей будуть Клієнти. Обидва чинники визначають вагу R1 і R2, і їх слід встановити після запуску.
• Посилання на джерела вказують на файли й функції у вихідному коді системи розроблення. Визначальною є описана функція, а не її розташування у файлі.

Цей документ є чернеткою. Його ще не схвалено контролером (розділ 12), а два його висновки — оцінка масштабу для P1 і P3 та вага перевірки доставки — залежать від показників, які з’являться лише після запуску.

6. (a) Систематичний опис операцій обробки й цілей

6.1 Як побудована система перевірок

formexposed працює на власних серверах у Польщі без зовнішнього хостинг-провайдера: вебсервер із застосунком і базою даних та сервер сканування зі службою перевірок і локальною мовною моделлю, обидва в одній внутрішній мережі. Перевірка відбувається так:

1. Застосунок створює завдання в базі даних — з урахуванням лімітів і блокувань у розділі 6.3.
2. Служба перевірок на сервері сканування отримує завдання, вдруге перевіряє список блокування, імена хостів і для анонімних перевірок вік домену та запускає ізольований контейнер саме для цього завдання: власна мережа з власними правилами фільтрації, без спеціальних привілеїв, файлова система лише для читання, ліміти пам’яті й процесів та часовий ліміт (scanner/src/worker.js).
3. Усередині контейнера автоматизований браузер отримує щонайбільше вісім публічних сторінок: спочатку головну, потім переважно сторінки контактів, відомостей про постачальника й підтримки. Заздалегідь він читає robots.txt; виключення для FormExposedBot або всіх сканерів, яке охоплює головну сторінку, завершує перевірку, так само як недоступний robots.txt або серверна помилка під час отримання (scanner/src/net.js). Заборони для окремих підшляхів не враховуються окремо. Пульс форми, отримання підтвердження, інструмент заголовків і пошук відкритих файлів не читають robots.txt. Додатково до восьми сторінок є до трьох сторінок із натисканням «Відхилити» в банері cookie, до трьох сторінок у вигляді для телефона, активні проби для підтверджених доменів і до п’яти сторінок після входу; сторінки завантажуються послідовно, а не паралельно. Кожен запит браузера, включно з перенаправленнями й вбудованим вмістом, проходить фільтр, що відхиляє приватні мережі й інші порти.
4. Контейнер записує результат і знімки екрана до тимчасового каталогу. Служба перевірок передає результат і зображення застосунку через внутрішню мережу й видаляє тимчасовий каталог, навіть після помилки (scanner/src/worker.js).
5. Застосунок обробляє результат, для доменів Клієнтів порівнює його з попередньою перевіркою й повідомляє про зміни адресатам, яких налаштував Клієнт.

6.2 Що зберігає сканер — і чого не зберігає

Елемент	Що зберігається	Що не зберігається	Посилання на джерело
Сторінки	Адреса, стан HTTP, заголовки, Content Security Policy, запитані сторонні хости (щонайбільше 120)	Вміст сторінки як текст або HTML	scanner/src/crawl.js
Поля форм	Тип, назва, підпис, текст-заповнювач, обов’язковість, видимість, довжина наявного значення	Значення полів; для прихованих полів перші 24 символи значення лише читаються під час перевірки (для виявлення токенів)	scanner/src/crawl.js
Адреси одержувачів у формі	лише домен	адреса	scanner/src/crawl.js
Скрипти	Перелік із контрольною сумою; адреси й початковий текст без ідентифікаторів облікових записів рекламних та аналітичних сервісів	Ідентифікатори облікових записів і пікселів	scanner/src/crawl.js
Засоби підслуховування	які рекламні пікселі й інструменти запису завантажуються до й після натискання «Відхилити» в банері cookie та чи маскують вони введення	Ідентифікатори облікових записів у цих сервісах	scanner/src/mitleser.js, scanner/src/einwilligung.js
Текст форми	до 400 символів надходить до локальної мовної моделі, якщо правила не розпізнають тип	Розкриття третім особам; зберігання тексту	scanner/src/classify.js
Знімки екрана (сканер)	видима область першої сторінки; для кожної видимої форми — зображення елемента форми	–	scanner/src/crawl.js
Знімки екрана (активна перевірка)	Зображення сторінки відповіді на тестове надсилання; додатково стан, адреса призначення, заголовок і перші 300 символів її тексту	–	scanner/src/active.js
Знімки екрана (браузерні сценарії)	Зображення форми із зафарбованими полями введення, стиснене, щонайбільше 32 KB	Введення	scanner/src/browser.js
Після входу	як для полів форм вище	Знімки екрана, cookie, посилання	scanner/src/login.js

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

6.3 Хто запускає перевірку й що тоді застосовується

Ініціатор	Рівень довіри в завданні	Тестові надсилання	Результат доступний через	Видалення
Хтось вводить домен на головній сторінці (безкоштовна перевірка)	anonymous	ні	Звіт за випадковим посиланням	30 днів, включно із зображеннями (cfg/check_lib.php)
Плагін або розширення без облікового запису	plugin	ні	Звіт за випадковим посиланням	30 днів
Агентство для потенційного клієнта	registered	ні	Короткий висновок і звіт за випадковим посиланням	90 днів (cfg/akquise_lib.php)
Клієнт, домен без підтвердження	registered	ні	Обліковий запис; звіт за випадковим посиланням	13 місяців, остання перевірка зберігається
Клієнт, домен із підтвердженням	verified	так, щонайбільше п’ять за перевірку	Обліковий запис; звіт за випадковим посиланням	13 місяців, остання перевірка зберігається (cfg/fristen_lib.php)
Дослідження	internal	ні	лише сукупні показники після публікації	під час публікації; без публікації немає часового обмеження (R4)
Внутрішня перевірка постачальником із командного рядка	internal; для наших власних тестових і демонстраційних доменів також «verified»	ні; із рівнем «verified» — так (лише наші власні тестові й демонстраційні домени)	лише внутрішньо	немає часового обмеження (R4)

Перед безкоштовною перевіркою розташовано кілька рівнів (cfg/check_lib.php): аварійна зупинка; reCAPTCHA; той самий домен щонайбільше раз на сім днів (після цього показується наявний звіт); ліміти за IP-адресою, сеансом (як хеш-значення, ніколи не сам ідентифікатор сеансу) і всім сервісом за день; список блокування з відмов від перевірок і robots.txt; перевірка того, що домен указує на публічні адреси; блокування дуже нових доменів або доменів невідомого віку. Аномалії — багато різних доменів з однієї IP-адреси, багато запитів за короткий час — фіксуються з IP-адресою й спричиняють сигнал без вмісту (cfg/check_lib.php).

6.4 Перевірка доменів в обліковому записі Клієнта

Клієнт доводить, що має право контролювати домен: записом DNS, метатегом, файлом або через наш плагін (cfg/verify_lib.php). Лише після цього домен вважається підтвердженим. Планувальник моніторингу планує регулярні перевірки лише для активних доменів із моніторингом і підтвердженням (cfg/monitor_lib.php).

• Активні тестові надсилання прив’язані до двох умов: застосунок установлює активний режим для Клієнтів лише для підтверджених доменів (для наших власних тестових і демонстраційних доменів постачальник може створити перевірку з рівнем «verified» внутрішнім інструментом командного рядка), а служба перевірок знову перевіряє рівень довіри й аварійну зупинку fc_active_enabled (scanner/src/worker.js). Надіслати можна лише форму, яку правила з високою впевненістю розпізнають як загальну контактну форму, яка не має обов’язкових полів для реальних персональних даних і домен якої не схожий на орган влади, освітній заклад, клініку, медичну практику, поліцію чи суд (scanner/src/classify.js). Мовна модель не може дозволити надсилання форми (scanner/src/classify.js). За перевірку надсилається щонайбільше п’ять надсилань (fc_active_max_posts), чітко позначених, із відправником dummy@formexposed.com, адресою в .invalid для перевірки валідації електронної пошти та нешкідливим додатковим рядком заголовка для виявлення ін’єкції заголовків (scanner/src/active.js).
• Браузерні сценарії перевіряють налаштовані сценарії форм у браузері до моменту безпосередньо перед надсиланням. Дозволено лише запити GET і HEAD; усе інше переривається, як і адреси, що містять слова виходу, видалення, купівлі чи оплати (scanner/src/browser.js). Для перевірки обов’язкові поля заповнюються вигаданими значеннями, які ніколи не залишають браузера.
• Відкриті файли шукаються щотижня, лише для підтверджених доменів, зі щонайбільше одним отриманням на шлях, щонайбільше 8 KB, і вміст ніколи не зберігається (cfg/dateien_lib.php).
• Незалежна друга проба підготовлена й типово вимкнена (browser_probe_enabled = 0). Якщо її ввімкнути, вона отримувала б лише домен, адресу, селектор, кроки й вибір браузера, ніколи облікові дані, знімки екрана чи дані відвідувачів (cfg/formular_probe_lib.php).

6.5 Сканування захищеної входом частини сайту

Передумови: функцію налаштовано, домен підтверджений, Клієнт має платний тариф і є власником або адміністратором робочого простору (cfg/login_lib.php); він підтверджує, що обліковий запис тестовий із якомога меншими правами (cfg/login_lib.php).

1. Ім’я користувача й пароль негайно шифруються на вебсервері відкритим ключем сервера сканування: одноразовий ключ для кожного запису (X25519), виведення ключа (HKDF-SHA256), AES-256-GCM, прив’язка до домену (cfg/login_lib.php). Лише служба перевірок на сервері сканування має закритий ключ (scanner/src/geheim.js). Той, хто має вебсервер, базу даних або резервну копію, має лише шифротекст.
2. Інтерфейс показує лише перший символ і довжину імені користувача (cfg/login_lib.php). Облікові дані ніколи не відображаються, не записуються до журналів і не видаються через API.
3. Для перевірки застосунок додає шифротекст до завдання. Служба перевірок розшифровує його, негайно очищає поле в завданні й передає облікові дані контейнеру лише через стандартне введення, ніколи як аргументи командного рядка (scanner/src/worker.js). Залишки в перерваних завданнях очищає процес перевірки стану через одну годину (cfg/login_lib.php).
4. Усередині контейнера браузер входить. Він перериває роботу, якщо сторінка входу перенаправляє на інший хост, форма входу містить CAPTCHA (ми не обходимо CAPTCHA) або поле пароля залишається видимим після надсилання (scanner/src/login.js). Потім він очищає поле пароля в пам’яті сторінки й забуває облікові дані (scanner/src/login.js).
5. Він читає щонайбільше п’ять визначених Клієнтом сторінок того самого домену. Адреси зі словами виходу, видалення, вилучення чи скасування блокуються (scanner/src/login.js). Після входу нічого не надсилається, знімки екрана не робляться, а cookie й посилання не потрапляють до результату (scanner/src/login.js).
6. Видалення остаточне: шифротекст перезаписується випадковими даними тієї самої довжини, рядок видаляється, а завдання в очікуванні очищаються (cfg/login_lib.php). Коли домен видаляється, рядок автоматично зникає через зовнішній ключ.

6.6 Перевірка доставки

Перевірка доставки відповідає на запитання, чи справді надходить лист із контактної форми, та оцінює його ознаки автентичності. Вона необов’язкова, типово вимкнена й потребує налаштованої контрольної скриньки (cfg/zustellung_lib.php).

1. Якщо Клієнт її вмикає, домен отримує випадкову мітку. Клієнт додає контрольну адресу з цією міткою як приховану копію у своїй формі.
2. Відтоді кожний лист із форми також надходить до контрольної скриньки: наші позначені тестові надсилання й усі справжні повідомлення відвідувачів. Листи надходять безпосередньо до скриньки в Namecheap, Inc. (Private Email), Phoenix, Arizona, USA — вони надходять лише якщо записи MX нашого домену вказують туди; через пересилання, наприклад у реєстратора домену Namecheap, Inc., вони не доходять до скриньки — і залишаються там до отримання.
3. Процес перевірки стану отримує пошту зі скриньки кожні п’ять хвилин (srv/cron_status.php). Для кожного листа він читає заголовки й щонайбільше перші 8 KB тексту, не позначаючи листи прочитаними (cfg/zustellung_lib.php).
4. Із заголовків він визначає мітку й тим самим домен, а з тексту, за потреби, — ідентифікатор нашого тесту (cfg/zustellung_lib.php). Зберігаються час, домен і, за потреби, ідентифікатор тесту (cfg/zustellung_lib.php) протягом 180 днів (cfg/zustellung_lib.php).
5. Із заголовків він оцінює SPF, DKIM і DMARC та зберігає результат при домені: результати перевірок, домен адреси відправника, домени підписів та адресу поштового сервера надсилання (cfg/zustellung_lib.php). Якщо результат погіршується, Клієнту одноразово надсилається сповіщення, яке може називати домен відправника (cfg/zustellung_lib.php).
6. Потім він позначає кожний отриманий лист для видалення, зокрема й той, який неможливо віднести до домену, та видаляє його зі скриньки наприкінці запуску (cfg/zustellung_lib.php). Якщо запуск переривається раніше, листи залишаються до наступного успішного запуску.
7. Підтвердженням доставки вважається лише копія саме відповідного тесту (cfg/zustellung_lib.php). Якщо вона не надходить протягом трьох годин (delivery_wait_h), сервіс повідомляє «Доставки немає».

Текст справжніх повідомлень ніколи не записується до бази даних, так само як адреса відвідувача. Однак обидва читаються: під час отримання перші 8 KB кожного листа завантажуються в пам’ять для пошуку ідентифікатора тесту.

6.7 Колективний захист

1. Рівень захисту плагіна WordPress зупиняє повідомлення як спам і підраховує домени посилань у ньому. Раз на день плагін повідомляє нам ці домени з кількістю спрацювань, щонайбільше 60 на день; без адрес, тексту й IP-адрес (cfg/swarm_lib.php).
2. Раз на день ми формуємо з цього список: домен потрапляє до нього, якщо протягом семи днів про нього повідомили щонайменше три різні сайти з щонайменше п’ятьма спрацюваннями (swarm_min_sites, swarm_window_days, cfg/swarm_lib.php). Великі сервіси з фіксованого списку винятків і домени наших Клієнтів, у кожному випадку включно з піддоменами, ніколи не потрапляють до списку (cfg/swarm_lib.php).
3. Список надходить усім з’єднаним сайтам із відповіддю на щоденне повідомлення. Їхній рівень захисту поміщає повідомлення з посиланнями на домени зі списку до карантину, а не кошика.
4. Те, що більше не з’являється в новому списку, випадає з нього; повідомлення видаляються через 30 днів (cfg/swarm_lib.php).
5. IP-мережі (/24 або /48) підготовлені, але вимкнені до завершення юридичної перевірки (cfg/swarm_lib.php).

6.8 Використання штучного інтелекту

Мовна модель працює на нашому власному сервері сканування, а не в постачальника ШІ. Вона використовується в трьох місцях: у службі перевірок класифікує форми, тип яких не розпізнають правила; при цьому бачить заголовок сторінки, адресу сторінки, підписи кнопок надсилання, типи, назви, підписи й тексти-заповнювачі полів та до 400 символів тексту форми (scanner/src/classify.js). До неї звертаються лише якщо правила повертають «невідомо»; форми, класифіковані в такий спосіб, ніколи не надсилаються й не враховуються в оцінці та висновку. Оцінка, висновок, запобігання зловживанням, колективний захист і правила спаму — фіксовані правила, а не ШІ. У «Fix it for me» вона переписує вставлений код форми; код не зберігається. Для відповідних перевірок доменів у платних облікових записах вона також генерує план дій за пріоритетами з імені хоста, загального результату й оцінки, CMS, відповідного типу форми й адреси сторінки, визначеного плагіна та вибраних невдалих або неясних результатів перевірки. Запит тимчасово зберігається у внутрішній черзі завдань і видаляється після отримання або планового очищення записів, старших за одну годину. Згенерований текст, мова, стан і позначка часу зберігаються з результатом сканування за його правилами зберігання. Звіт позначає план як зведення ШІ й визначає окремі результати перевірки як авторитетні; план не змінює сайту чи результату сканування. Модель не приймає рішень про людей. Більше про це — на сторінці Регламент ЄС про ШІ: як formexposed використовує ШІ.

6.9 Правові підстави

Операція обробки	Правова підстава
P1 Безкоштовна перевірка: перевірка запитаного домену; ліміти й запобігання зловживанням	щодо особи, яка запитує, — ст. 6(1)(b); щодо оператора й зображених осіб — ст. 6(1)(f); запобігання зловживанням — ст. 6(1)(f)
P2 Перевірка потенційного клієнта	Ст. 6(1)(f) (законний інтерес агентства та formexposed)
P3 Дослідження	Ст. 6(1)(f)
P4 Перевірка доменів Клієнта	Ст. 6(1)(b) щодо Клієнта; для даних третіх осіб на його сайті — вказівки Клієнта за ст. 28
P5 Сканування захищеної входом частини сайту	Вказівки Клієнта за ст. 28; правова підстава Клієнта
P6 Перевірка доставки	Вказівки Клієнта за ст. 28; правова підстава Клієнта (у нашому запропонованому тексті для Клієнтів — ст. 6(1)(f))
P7 Колективний захист	Ст. 6(1)(f) (спільний захист від спаму на багатьох сайтах)

Наш законний інтерес у P1–P3 полягає в тому, щоб показувати операторам та їхнім постачальникам послуг слабкі місця форм до використання їх для спаму чи зловживань і надавати сервіс. Дані походять із публічно доступних джерел. Зважування інтересів визначено в розділі 7; чи обґрунтовує ст. 6(1)(f) перевірку сторонніх сайтів на запит — відкрите питання юридичної перевірки.

6.10 Одержувачі й передавання до третіх країн

Одержувач	Що	Операція обробки	Стан
Ніхто поза formexposed	Результати перевірок, знімки екрана, класифікація мовною моделлю	P1–P5	Служба перевірок і мовна модель працюють на наших власних серверах; у шляху перевірки сканера не знайдено викликів третіх осіб, крім самого перевіреного сайту, сервісів, вміст яких він вбудовує (як для будь-якого відвідувача), та сервісу RDAP rdap.org для віку домену (лише доменне ім’я); спостерігачів моніторингу перелічено в наступному рядку
Кожен, хто знає посилання	Звіт із результатами перевірки й знімками екрана	P1, P2, P4	випадкове посилання зі 128 бітами (cfg/check_lib.php), сторінки з noindex (www/report.php)
Сервіси, до яких звертається моніторинг домену Клієнта	DNS-списки блокування (SpamCop, PSBL, Mailspike, SURBL): домени й IP-адреси серверів, без даних відвідувачів; Google Web Risk лише якщо налаштовано: адреса головної сторінки; служби позначок часу Certum і DigiCert: лише хеш-значення журналу доказів; RDAP через реєстр IANA: лише доменне ім’я; сторінки стану постачальників: нічого не передається; wpvulnerability.net: ідентифікатор плагіна (без версії) чи теми та версія WordPress	P4	використовуються; подробиці в Реєстрі діяльності з обробки й на сторінці Субобробники
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Контрольні копії, включно зі справжніми повідомленнями відвідувачів	P6	Договір ще не укладено; місце обробки й механізм передавання ще належить перевірити
Namecheap, Inc. (USA)	Реєстратор і DNS; до налаштування скриньки — пересилання загальних листів, адресованих на наш домен, а не контрольних копій (вони надходять до скриньки лише через записи MX, спрямовані безпосередньо на неї)	– (без контрольних копій)	Механізм передавання належить перевірити
Канали сповіщень, вибрані Клієнтом (електронна пошта, вебхук, Slack, Discord, Microsoft Teams, Google Chat, Telegram)	Подія, домен, посилання; для перевірки автентичності — домен відправника, якщо він не належить сайту	P4, P6	адресат, вибраний Клієнтом; частково поза ЄС. Ми надсилаємо повідомлення Telegram через нашого бота; механізм передавання для цього — відкрите питання юридичної перевірки
Усі з’єднані сайти	Список доменів посилань	P7	через відповідь плагіну
Друга проба	Домен, адреса форми, селектор, кроки	P4	вимкнено

6.11 Зберігання: виміряне, а не заплановане

Видалення переважно відбувається вночі о 03:00 у процесі перевірки стану (srv/cron_status.php, cfg/fristen_lib.php); повідомлення колективного захисту й рядки потенційних клієнтів видаляються щодня з 04:00, відповідності перевірки доставки — під час кожного отримання; анонімні звіти й звіти потенційних клієнтів видаляються за датою спливу строку дії (cfg/check_lib.php). Знімки екрана видаляються з диска разом зі своїм скануванням (cfg/fristen_lib.php).

Дані	Строк за кодом	Посилання на джерело	Результат перевірки
Безкоштовна перевірка включно із зображеннями	30 днів	cfg/check_lib.php	діє
Перевірка потенційного клієнта включно із зображеннями	90 днів	cfg/akquise_lib.php; srv/cron_status.php (рядки потенційних клієнтів)	діє
Перевірки домену Клієнта	13 місяців; остання зберігається, доки існує домен	cfg/fristen_lib.php	діє
Результати браузерних сценаріїв включно із зафарбованими зображеннями	13 місяців	cfg/fristen_lib.php	діє
Дані видаленого домену	негайно; залишки — вночі	cfg/fristen_lib.php (fe_domain_loeschen(), fe_fristen_lauf())	діє, включно з переліком скриптів і змінами скриптів, які понад це не мають власного строку зберігання (див. Реєстр діяльності з обробки)
Дослідження: сирі дані включно із зображеннями	під час публікації	cfg/studie_lib.php	без публікації немає часового обмеження; перелік перевірених хостів залишається без часового обмеження навіть після публікації
Внутрішні перевірки без домену й без звіту	немає	–	не видаляються; виміряно: 85 перевірок із 369 зображеннями від 22 вересня 2026 року (R4)
Відповідності перевірки доставки	180 днів	cfg/zustellung_lib.php	діє
Результат перевірки автентичності при домені	до наступного результату або видалення домену	cfg/zustellung_lib.php	перезаписується, без часового обмеження
Контрольні копії у скриньці	до наступного успішного отримання (п’ятихвилинний інтервал)	cfg/zustellung_lib.php	копії й резервні копії в постачальника скриньки не перевірені
Облікові дані для сканування захищеної входом частини сайту	до видалення Клієнтом або видалення домену; у завданні щонайбільше до кінця запуску, залишки — через одну годину	cfg/login_lib.php	діє; у резервних копіях лише як шифротекст до 14 днів
Повідомлення в колективному захисті	30 днів	cfg/swarm_lib.php	діє
Ліміти безкоштовної перевірки (IP, країна, хеш сеансу)	7 днів	srv/cron_status.php	діє
Примітки про підозрілу поведінку з IP-адресою	90 днів після усунення	srv/cron_status.php	неусунені примітки без часового обмеження; виміряно: 3 примітки, усі усунені
IP-адреса, країна, браузер щодо відмови від перевірок	12 місяців; виключення залишається	cfg/fristen_lib.php	діє
Резервні копії бази даних	14 днів	cfg/backup_lib.php	діє; резервні копії наразі зберігаються в тому самому місці, що й база даних, і окремо не шифруються; зашифрована копія в другій локації запланована (R13)

7. (b) Оцінка необхідності й пропорційності

Мірилом є зазначені цілі: показати операторам, чи захищені їхні форми від спаму й зловживань (P1–P5), перевірити, чи надходять листи з форм і чи виглядають автентичними (P6), та спільно захищатися від спаму на багатьох сайтах (P7). Ці цілі правомірні. Питання за ст. 35(7)(b) вужче: чи потрібна саме ця обробка на таку глибину для мети й чи пропорційне втручання користі?

Компонент	Необхідний для мети?	Пропорційний у реалізованому вигляді?
Отримання кількох публічних сторінок, структури форм, виявлених заходів захисту	Так. Без них немає результату перевірки.	Так. Щонайбільше вісім сторінок (плюс перегляди з розділу 6.1), заборона головної сторінки в robots.txt дотримується, без значень видимих полів, адреси одержувачів лише як домен.
Знімок екрана кожної форми	Так, як доказ у звіті: оператор бачить, яку форму мають на увазі.	Переважно. Поля порожні, оскільки сканер нічого не вводить. Однак зображення показує оточення елемента форми без зафарбовування (R3).
Знімок екрана головної сторінки	Не потрібний для самого результату перевірки. Він слугує для впізнавання перевіреного сайту у звіті.	Лише обмежено; подальша мінімізація запланована. Головні сторінки часто показують людей: фотографії команд, контактних осіб, відгуки клієнтів з іменами. Див. R3 і розділ 9.3.
Читання значень прихованих полів (перші 24 символи, лише під час перевірки)	Так: за ними виявляються токени й позначки часу.	Так. Зберігається лише результат виявлення, а не значення, також після входу (R8).
Сторінка відповіді на тестове надсилання (зображення й 300 символів тексту)	Так, як доказ того, як відповіла форма.	Так. Відповідь стосується нашого позначеного тестового повідомлення без персональних даних.
Класифікація мовною моделлю	Корисна, не необхідна: без неї більше форм залишаються «невідомими».	Так. Локально, без розкриття, без права надсилання.
Локальний план дій із вибраних результатів перевірки й метаданих сканування	Корисний для визначення пріоритетів усунення проблем, не необхідний для отримання окремих результатів перевірки.	Обмежений наявними метаданими сканування й щонайбільше 18 різними невдалими чи неясними результатами перевірки, без знімків екрана чи введених значень полів у запиті до моделі. План рекомендаційний і позначений як згенерований ШІ; визначальними залишаються окремі результати перевірки. URL і примітки все ще можуть містити персональні дані, а згенерований текст зберігається за строками сканування й доступний кожному, хто має посилання. Ці обмеження зменшують розкриття, але не доводять фактичної правильності (R10).
Активні тестові надсилання	Так. Чи працює захист, стає зрозуміло лише після тестування.	Так, із лімітом і позначенням. Однак передумова — підтвердження контролю — ніколи не поновлюється (R7).
Пошук відкритих файлів	Так, для Клієнта, чиї дані форм можуть бути там відкритими.	Так. Лише підтверджені домени, щонайбільше 8 KB, вміст ніколи не зберігається.
Сканування захищеної входом частини сайту	Так, для форм в області учасників, які інакше залишилися б неперевіреними.	Переважно. Шифрування й видалення ретельно реалізовані; однак вхід приймає незашифровані з’єднання й хибні сертифікати (R8).
Контрольна копія справжніх повідомлень відвідувачів	Не для підтвердження доставки. Воно спирається лише на копію нашого тесту (cfg/zustellung_lib.php). Справжні повідомлення надходять разом із нею, оскільки прихована копія у формі не розрізняє тест і справжнє повідомлення. Вони корисні для перевірки автентичності (SPF, DKIM, DMARC), оскільки показують фактичний шлях надсилання.	Частково. Вміст не зберігається, але читається й залишається в постачальника скриньки, договір із яким ще відкритий, до отримання (R1, R2). Менш втручальна конструкція технічно можлива: за допомогою нашого плагіна приховану копію можна було б обмежити позначеними тестовими повідомленнями (розділ 9.3).
Зберігання домену відправника справжніх повідомлень	Частково: показує, чи надсилає форма з адресою відвідувача як відправником (часта причина класифікації як спам).	Умовно. Для особи з власним доменом домен є персональними даними й надходить у сповіщенні Клієнту та його каналам (R1).
Спільний список доменів посилань	Так. Спам-посилання, яке одночасно з’являється на багатьох сайтах, є сильним сигналом, якого окремий сайт не має.	Так, із мінімальними кількостями, винятками й карантином замість видалення. IP-мережі не були б пропорційними без нової оцінки.
Сирі дані дослідження	До оцінювання — так.	Без максимального строку — ні (R4).
Звіт за випадковим посиланням	Так. Передавання звіту, наприклад постачальнику послуг, який доглядає за сайтом, є метою безкоштовної перевірки.	Так. Випадкове посилання зі 128 бітами, noindex, безкоштовний звіт лише як витяг (cfg/check_lib.php, FE_FREE_DETEKTOREN), видалення через 30 днів.

Правомірність. Для P1–P3 і P7 ми покладаємося на ст. 6(1)(f). На користь зважування: дані публічні й отримуються так само, як будь-яким відвідувачем; нічого не надсилається; персональні дані випадкові й незначні; строки короткі; оператор може виключити подальші перевірки сканером через заборону головної сторінки в robots.txt і будь-яку подальшу перевірку через нашу сторінку відмови від перевірок, негайно й без підтвердження; користь — захищена форма — також належить оператору та його відвідувачам. Проти: оператор нічого не дізнається про перевірку, звіт призначений для третіх осіб, а для фізичних осіб — підприємців він оцінює особу. Ми вважаємо зважування обґрунтованим, доки заходи з розділу 9.1 залишаються чинними; юридичне підтвердження ще очікується.

Інформування суб’єктів даних (ст. 13 і 14). Ми інформуємо операторів і людей на перевірених сторінках через сторінку сканера, зазначену в ідентифікаторі кожного отримання, через Політику конфіденційності й сторінку відмови від перевірок. Індивідуально повідомити людей, які випадково з’являються на знімку екрана, можна було б лише після їх ідентифікації — що було б додатковим, серйознішим втручанням. У цій частині ми покладаємося на ст. 14(5)(b). Відвідувачів, чиї повідомлення проходять через контрольну копію, інформує Клієнт; цього вимагає Договір про обробку даних, і ми надаємо для цього текстовий блок.

Мінімізація даних (ст. 5(1)(c)). Вона видима в багатьох місцях і закладена в код: без значень полів, адреси одержувачів лише як домен, ідентифікатори облікових записів в адресах скриптів приховані, без вмісту контрольної копії в базі даних, без знімків екрана після входу, лише домени в колективному захисті. У двох місцях подальша мінімізація можлива й запланована (розділ 9.3): для знімка головної сторінки без зафарбовування та домену відправника справжніх повідомлень.

Обмеження зберігання (ст. 5(1)(e)). Із 27 вересня 2026 року нічний запуск дотримується строків Політики конфіденційності для даних Клієнтів і очищає дані, що залишилися без пов’язаного домену з попереднього періоду (cfg/fristen_lib.php). Відкритими залишаються два шляхи без часового обмеження: внутрішні перевірки й неопубліковані дослідження (R4).

Точність (ст. 5(1)(d)). Результат перевірки може бути помилковим: форма здається незахищеною, оскільки захист завантажується лише після взаємодії, або брандмауер поводився зі сканером інакше, ніж із відвідувачем. Для оператора, сайт якого публічно поширюється як «Незахищено», це питання репутації. Тому звіт називає метод, показує докази й указує межі перевірки ззовні.

Результат щодо пропорційності: перевірка сторонніх і власних сайтів у реалізованому вигляді загалом пропорційна. У трьох місцях потрібне поліпшення, яке можна здійснити звичайними засобами й для якого заплановано заходи (розділ 9.3): знімки головної сторінки, внутрішні перевірки без часового обмеження й незашифрований вхід для сканування захищеної входом частини сайту. Перевірка доставки пропорційна для тестової копії й перевірки автентичності; щодо справжніх повідомлень відвідувачів це діє лише доки їхній вміст не зберігається, шлях через постачальника скриньки договірно забезпечений і Клієнт інформує відвідувачів. Сьогодні другого з цих трьох пунктів бракує.

8. (c) Оцінка ризиків для прав і свобод суб’єктів даних

Оцінюється ризик для суб’єктів даних, а не для formexposed. Імовірність оцінюється як малоймовірна, можлива, ймовірна або реалізована; «реалізована» означає, що подія не є прогнозом, а виміряним станом. Серйозність оцінюється як обмежена, істотна, серйозна або дуже серйозна залежно від того, що особа може втратити: конфіденційність повідомлення, контроль над обліковим записом, ділову репутацію, можливість здійснити право. Рівень випливає з обох чинників і описує поточний стан із заходами з розділу 9.1.

№	Ризик	Операція обробки	Імовірність	Серйозність	Рівень
R1	Справжні повідомлення відвідувачів у контрольній копії, включно з можливими особливими категоріями	P6	Реалізована після ввімкнення	Серйозна	Високий
R2	Шлях контрольної копії через постачальника скриньки без укладеного договору й із можливим зв’язком із третьою країною	P6	Ймовірна, доки немає договору	Серйозна	Високий
R3	Знімки екрана сторонніх сайтів без зафарбовування	P1–P4	Ймовірна	Обмежена	Середній
R4	Дані перевірок і знімки екрана без шляху видалення	P3, внутрішні перевірки	Реалізована	Істотна	Високий
R5	Перевірка й публічна оцінка сторонніх сайтів без відома оператора; неналежне використання як інструмента розвідки	P1	Можлива	Істотна	Середній
R6	Перевірка потенційного клієнта як основа небажаних звернень	P2	Ймовірна	Обмежена	Середній
R7	Підтвердження контролю ніколи не поновлюється	P4, P5	Можлива	Істотна	Середній
R8	Облікові дані й вміст під час сканування захищеної входом частини сайту	P5	Можлива	Серйозна	Середній; високий для реальних облікових записів
R9	Активні тестові надсилання й перевірка файлів на сайті Клієнта	P4	Малоймовірна	Істотна	Низький
R10	Класифікація мовною моделлю	P1–P4	Малоймовірна	Обмежена	Низький
R11	Спільний список блокування з повідомлень багатьох сайтів	P7	Можлива	Обмежена	Від низького до середнього; високий з IP-мережами
R12	Звіти й знімки екрана за публічним посиланням	P1, P2, P4	Можлива	Обмежена	Низький
R13	Слабкі місця інфраструктури: резервні копії, доступ до серверів, сервер сканування	усі	Можлива	Серйозна	Високий
R14	Права суб’єктів даних для осіб, які нас не знають	P1–P6	Ймовірна	Обмежена	Низький

R1 — Справжні повідомлення відвідувачів у контрольній копії

Це найсерйозніший ризик сервісу, і він виникає не через помилку, а через конструкцію. Прихована копія у формі не розрізняє наше тестове повідомлення й повідомлення відвідувача. Якщо Клієнт вмикає перевірку доставки, кожне повідомлення, надіслане через цю форму, надходить до нашої контрольної скриньки (cfg/zustellung_lib.php). Отримання читає заголовки й перші 8 KB тексту в пам’ять для пошуку нашого ідентифікатора тесту (cfg/zustellung_lib.php). Для звичайної контактної форми це означає ім’я, адресу електронної пошти, номер телефона й повне повідомлення.

Що пише відвідувач, залежить від нього, а поле спонукає до особистого вмісту: запит на прийом з описом симптомів до медичної практики, виклад правового спору до юридичної фірми, заява на роботу, звернення щодо дитини до школи. Наші правові документи зазначають, що копії «не повинні містити жодних особливих категорій персональних даних». Це прохання до Клієнта, а не захисний захід: ані він, ані ми не знаємо заздалегідь, що напише відвідувач.

До цього належать два побічні шляхи. По-перше, перевірка автентичності зберігає при домені домен адреси відправника (cfg/zustellung_lib.php). Якщо форма надсилає з адресою відвідувача як відправником, це домен відвідувача — незначущий для великого поштового постачальника, але персональні дані для особи з власним доменом. Цей домен також з’являється у сповіщенні, що надходить Клієнту й вибраним ним каналам (cfg/zustellung_lib.php). По-друге, зберігається адреса поштового сервера надсилання (cfg/zustellung_lib.php); зазвичай це сервер сайту, а не відвідувача.

Імовірність — реалізована після ввімкнення. Питання не в тому, чи надходять справжні повідомлення, а в тому, скільки. За вимірюванням у системі розроблення функцію не ввімкнено для жодного домену. Серйозність — серйозна. Конфіденційність повідомлення підприємству важлива для багатьох людей, і для деяких типових Клієнтів слід очікувати даних за ст. 9. Серйозність пом’якшується тим, що вміст не потрапляє до бази даних, залишається у скриньці лише ненадовго й не читається жодною особою в formexposed. Рівень — високий.

R2 — Шлях контрольної копії через постачальника скриньки без укладеного договору

Перш ніж наше отримання побачить контрольну копію, вона перебуває у скриньці в Namecheap, Inc. (Private Email), Phoenix, Arizona, USA. Вона надходить туди лише якщо записи MX нашого домену вказують безпосередньо на цю скриньку; пересилання в реєстратора домену Namecheap, Inc. не є проміжною ланкою контрольних копій (через пересилання вони не доходять до скриньки). Для ланки, що залишається, договірні домовленості ще відкриті: договір із постачальником скриньки не укладено, місця зберігання, субобробників і строки резервних копій не встановлено, а питання, чи потрібне та чи застосовується для його місця обробки рішення про належний рівень захисту або стандартні договірні положення, відкрите. Для наших власних транзакційних листів це питання побудови договору. Для контрольних копій воно серйозніше: це дані, які ми отримуємо як обробник, а кожен постачальник послуг на шляху — субобробник, за якого ми відповідаємо за ст. 28(4).

Крім того, «видалено після отримання» стосується лише нашого погляду на скриньку. Чи зберігає постачальник видалені листи у власних резервних копіях або кошику й як довго, не перевірено. Якщо отримання переривається, листи залишаються до наступного успішного запуску (cfg/zustellung_lib.php); якщо процес перевірки стану відмовляє, вони залишаються безстроково. Нарешті, захист самого отримання — один із пунктів для перевірки в робочій системі перед запуском (розділ 9.3).

Імовірність — ймовірна, доки немає договору: кожна контрольна копія проходить цим шляхом. Серйозність — серйозна з тих самих причин, що й R1. Рівень — високий. Контрольний список налаштування застосунку повідомляє про відсутню скриньку як попередження; блокування перевірки доставки без задокументованого договору немає.

R3 — Знімки екрана сторонніх сайтів без зафарбовування

Сканер робить знімок екрана видимої області першої сторінки й зображення елемента форми кожної видимої форми (scanner/src/crawl.js). При цьому нічого не зафарбовується. Для браузерних сценаріїв це інакше: там поля введення маскуються перед знімком екрана (scanner/src/browser.js). Тому «очищені» лише зображення браузерних сценаріїв, а не сканера й не зображення сторінки відповіді активної перевірки.

Оскільки сканер нічого не вводить, поля форм порожні. Однак головна сторінка малого підприємства часто показує власника, команду, відгуки клієнтів з іменами й фотографіями або вікно чату із зображенням працівника. Усе це публічне; знімок екрана перетворює це на копію, що зберігається в нас, з’являється у звіті й може передаватися з посиланням.

Імовірність — ймовірна. У наборі даних системи розроблення виміряно 432 знімки екрана. Серйозність — обмежена: вміст уже публічний, а строки перевірок без облікового запису короткі. Рівень — середній, оскільки зображені особи не знають про це, а зображення головної сторінки не потрібне для результату перевірки.

R4 — Дані перевірок і знімки екрана без шляху видалення

Нічний запуск видаляє перевірки двома шляхами: через дату спливу строку дії звіту (cfg/check_lib.php) і через строк перевірок домену Клієнта (cfg/fristen_lib.php, лише для перевірок із доменом). Перевірка, яка не має ані звіту, ані домену, проходить крізь обидві сітки. Це перевірки з рівнем довіри «internal»: дослідження й перевірки, які постачальник створює з командного рядка.

• Дослідження видаляють сирі дані під час публікації (cfg/studie_lib.php). Якщо дослідження ніколи не публікується — через замалу кількість сайтів із формою (тоді cfg/studie_lib.php відмовляє в публікації) або тому, що його залишили без продовження, — перевірки, форми, окремі результати виявлення й знімки екрана залишаються без часового обмеження.
• Внутрішні перевірки з командного рядка взагалі не мають шляху видалення. Виміряно 11 жовтня 2026 року: 85 таких перевірок сторонніх сайтів із 978 формами й 369 знімками екрана, найстаріша від 22 вересня 2026 року, жодна не має звіту чи домену.
• Примітки про підозрілу поведінку в безкоштовній перевірці містять IP-адресу й видаляються через 90 днів після усунення (srv/cron_status.php). Примітка, яку ніколи не усунули, залишається. Виміряно: три примітки, усі усунені.

Імовірність — реалізована. Ці 85 перевірок — не сценарій, а наявні дані. У системі розроблення це перевірки польового тесту; той самий код діє в робочій системі. Серйозність — істотна: для цих даних немає строку зберігання. Щодо принципу обмеження зберігання (ст. 5(1)(e)) це відкрите питання із запланованим заходом (розділ 9.3, пріоритет «спочатку»), яке зачіпає саме людей, що нічого не знають про перевірку. Внутрішні перевірки описано в Реєстрі діяльності з обробки; Політика конфіденційності ще не називає їх окремо (розділ 9.4). Рівень — високий.

R5 — Перевірка й публічна оцінка сторонніх сайтів без відома оператора

Будь-хто може замовити перевірку будь-якого публічно доступного сайту без облікового запису й без жодного зв’язку з ним. Оператор не повідомляється. Результатом є звіт, який оцінює сайт як «Незахищено», «Частково захищено» або «Захищено» і який бачить кожен із посиланням. Для суб’єктів даних можливі два наслідки. Фізична особа — підприємець отримує оцінку публічно, хоча б лише для одержувачів посилання, і вона може бути помилковою. А звіт показує спамеру, яку форму можна заповнити без перешкод.

Цьому протистоїть низка блокувань (cfg/check_lib.php): щонайбільше одна перевірка домену за сім днів, потім той самий звіт; ліміти за IP-адресою й сеансом; щоденний ліміт усього сервісу; без перевірок дуже нових доменів, типових для зловживань; примітка й сигнал для підозрілої поведінки; robots.txt і відмова від перевірок, перевірені двічі (cfg/check_lib.php і в службі перевірок). Безкоштовний звіт є витягом: показує лише основні результати перевірки, а не докази всіх детекторів. І він не говорить нічого, чого бот не міг би сам з’ясувати за секунди, — незахищена форма видима ззовні.

Імовірність — можлива. Серйозність — істотна для фізичної особи — підприємця, чия форма стає ціллю після звіту або чия оцінка помилкова. Рівень — середній.

R6 — Перевірка потенційного клієнта як основа небажаних звернень

В інтерфейсі перевірка потенційного клієнта описана як «привід для першої розмови». Як агентство використовує короткий висновок, вирішує воно саме; технічно воно може надіслати його й оператору, який цього не запитував. Ми ні до кого не звертаємося (cfg/akquise_lib.php), а Умови надання послуг зобов’язують агентство дотримуватися правил реклами й залучення клієнтів. Однак небажаний лист із висновком є прямим маркетингом навіть між підприємствами, що в Польщі (ст. 398 Закону про електронні комунікації (Prawo komunikacji elektronicznej, PKE)) та Німеччині (§ 7(2) німецького Закону проти недобросовісної конкуренції (Gesetz gegen den unlauteren Wettbewerb, UWG)) потребує попередньої згоди. Інтерфейс не звертає на це уваги; тексти перевірки потенційного клієнта говорять лише про «пасивність» і «список відмов від перевірок».

Імовірність — ймовірна, оскільки функція слугує залученню клієнтів, і ми не можемо перевірити, чи одержувач надав згоду. Серйозність — обмежена: для оператора це надокучливий маркетинговий лист з оцінкою його сайту. Рівень — середній. Ризик полягає в поведінці агентства; оскільки функція походить від нас, запланована примітка в інтерфейсі (розділ 9.3).

R7 — Підтвердження контролю ніколи не поновлюється

Активні тестові надсилання, пошук відкритих файлів і сканування захищеної входом частини сайту потребують доведення Клієнтом права контролювати домен. Це підтвердження перевіряється один раз (cfg/verify_lib.php) і більше ніколи. У коді немає шляху, за яким домен втрачає підтвердження. Якщо домен змінює власника, агентство завершує доручення або оператор видаляє запис DNS, перевірки продовжуються — аж до щоденних, із до п’ятьма тестовими надсиланнями та, якщо збережено, входом тестового облікового запису, про який новий оператор може не знати. Натомість перенести підтвердження на інший хост перейменуванням неможливо: ім’я хоста домену з підтвердженням контролю не можна змінити.

Імовірність — можлива: зміни доменів і доручень є повсякденними для агентств. Серйозність — істотна для нового оператора й його працівників, які отримують позначені тестові повідомлення та чий сайт без їхньої згоди перевіряють на відкриті файли. Рівень — середній. Тестові повідомлення самі пояснюють себе й посилаються на сторінку сканера та відмову від перевірок; відмова також діє проти перевірок Клієнтів.

R8 — Облікові дані й вміст під час сканування захищеної входом частини сайту

Шифрування облікових даних ретельно реалізоване: вебсервер більше не може прочитати їх після збереження, база даних і резервна копія містять лише шифротекст, запис прив’язаний до домену, облікові дані потрапляють до контейнера лише через стандартне введення й потім очищаються з пам’яті (розділ 6.5). Залишаються дві прогалини; третій пункт стосується лише читання, а не зберігання.

• Незашифрований вхід дозволено. Перевірка адреси дозволяє http поряд із https (cfg/login_lib.php, scanner/src/login.js). Якщо Клієнт указує сторінку входу з http, ім’я користувача й пароль передаються через інтернет у відкритому вигляді під час кожної перевірки.
• Помилки сертифіката не зупиняють входу. Наразі вхід не переривається, коли сертифікат сайту Клієнта недійсний (scanner/src/login.js). Тому сертифікат не повністю захищає облікові дані на шляху до сайту Клієнта. Переривання за помилок сертифіката заплановано (розділ 9.3, пріоритет «спочатку»).
• Значення прихованих полів після входу читаються, а не зберігаються. Сканер читає перші 24 символи значення прихованих полів (scanner/src/crawl.js), і та сама функція видобування працює після входу (scanner/src/login.js). Там приховані поля часто містять номер облікового запису, ідентифікатор користувача чи адресу електронної пошти облікового запису, до якого виконано вхід; однак до карти полів і результатів перевірки потрапляють лише назва поля, тип, підпис і результат виявлення.

До цього додається те, чого код не може запобігти: Клієнт підтверджує, що використовує тестовий обліковий запис із якомога меншими правами (cfg/login_lib.php), але може ввести справжній обліковий запис адміністратора. Сторінки, які потім читає сканер, визначає Клієнт; адреси зі словами виходу й видалення блокуються, але інші дії, які сайт запускає простим запитом, — ні.

Імовірність — можлива. Серйозність — серйозна, якщо зачеплено обліковий запис із широкими правами; тоді область учасників із даними всіх користувачів відкрита. Рівень — середній для тестового облікового запису з невеликими правами, високий для реального. За вимірюванням у системі розроблення жодного тестового облікового запису не збережено.

R9 — Активні тестові надсилання й перевірка файлів на сайті Клієнта

Тестове надсилання надходить людям, які читають листи з форм Клієнта, — його працівникам чи постачальнику послуг. Воно не містить персональних даних: відправник — dummy@formexposed.com, текст і тема позначені й зазначають ідентифікатор перевірки (scanner/src/active.js). Ризик полягає в помилковій класифікації: якби сканер сприйняв форму заяви, бронювання чи консультації як контактну, тестове повідомлення потрапило б до процесу з наслідками. Цьому протистоять суворі правила дозволу надсилання (scanner/src/classify.js), блокування доменів органів влади, освітніх закладів, клінік, медичних практик, поліції й судів (scanner/src/classify.js) і виключення мовної моделі з цього рішення (scanner/src/classify.js). Із відповіді зберігаються стан, адреса призначення, заголовок, 300 символів тексту й зображення; вони стосуються нашого тестового повідомлення.

Перевірка файлів читає щонайбільше 8 KB із типових шляхів. Якщо там справді відкритий дамп бази даних, ці 8 KB можуть містити записи форм, зроблені відвідувачами. Вони лише перевіряються на сигнатуру й відкидаються (cfg/dateien_lib.php); зберігаються шлях, тип і серйозність.

Імовірність — малоймовірна. Серйозність — істотна. Рівень — низький. За вимірюванням у системі розроблення в наборі даних є одна активна перевірка без прийнятого надсилання.

R10 — Класифікація мовною моделлю

Для форм, які не розпізнають правила, мовна модель отримує заголовок сторінки, адресу, тексти кнопок, описи полів і до 400 символів тексту форми (scanner/src/classify.js). Це може включати ім’я, наприклад «Ваша контактна особа: …». Вона працює на нашому власному сервері; у коді ніщо не надходить до третьої особи. Чи журналює програмне забезпечення моделі запити, не перевірено. Її результат визначає лише відображений тип форми й не може дозволити надсилання; помилкова класифікація призводить до гіршого результату перевірки, а не до дії.

Імовірність — малоймовірна. Серйозність — обмежена. Рівень — низький.

R10 — Додатковий етап плану дій

Для платних звітів, у яких це доступно, та сама локальна модель також генерує рекомендаційні кроки з вибраних результатів перевірки й метаданих сканування. На відміну від класифікації, вивід є зведенням природною мовою, що зберігається зі скануванням. Імена хостів, адреси сторінок і примітки можуть містити персональні дані, які модель може повторити. Неправильна рекомендація може спонукати читача послабити захист або зробити непотрібну зміну; передавання посилання на звіт може розкрити повторені персональні дані іншому одержувачу. Код не виконує рекомендації автоматично, не змінює оцінки чи висновку й не перевіряє фактичної правильності тексту. Він обмежує довжину введення й виводу, позначає зведення як згенероване ШІ та зазначає визначальність окремих результатів перевірки. Це засоби контролю, а не доказ правильності рекомендацій або анонімності звіту. Попередня оцінка ймовірності й серйозності для класифікації сама по собі не оцінює цей доданий етап генерації; його залишковий ризик потрібно оцінювати з фактичними даними й використанням основної перевірки.

R11 — Спільний список блокування з повідомлень багатьох сайтів

Домен у списку спричиняє потрапляння повідомлень із посиланнями на нього до карантину на всіх з’єднаних сайтах. Якщо домен належить особі — майстру, фотографу, автору блогу, — її повідомлення з посиланням на власний сайт надходять одержувачам із запізненням. Такий домен може потрапити до списку через його використання спамерами або тому, що хтось навмисно надсилає на кілька сайтів повідомлення, які не проходять захист і містять цей домен.

Цьому протистоять (cfg/swarm_lib.php): мінімум три різні сайти й п’ять спрацювань протягом семи днів; фіксовані винятки для великих сервісів; ніколи не домени наших Клієнтів; ручне видалення інструментом на сервері; карантин замість видалення; щоденна перебудова списку, з якого випадає те, про що більше не повідомляють. Ті, кого це стосується, не можуть бачити список і не мають власного шляху вимагати видалення, крім звернення до нас.

Імовірність — можлива. Серйозність — обмежена, оскільки нічого не втрачається й одержувач може розблокувати повідомлення. Рівень — від низького до середнього. З увімкненими IP-мережами було б зачеплено мережі цілих постачальників, IP-адреси є персональними даними, а серйозність зросла б до істотної: високий.

R12 — Звіти й знімки екрана за публічним посиланням

Звіти безкоштовної перевірки, перевірки потенційного клієнта й перевірок доменів Клієнта доступні без входу за випадковим посиланням. Посилання містить 128 бітів випадковості, і його неможливо вгадати (cfg/check_lib.php). Сторінки мають noindex, застосунок надсилає політику referrer, яка передає лише джерело (www/.htaccess), а знімки екрана надаються лише разом зі звітом, до якого належать; інший номер зображення повертає «не знайдено» (www/shot.php). Ризик не криптографічний, а людський: посилання передається, копіюється в заявку, поширюється в чаті. Той, хто його відкриває, фіксується лише в журналі доступу до сторінок як будь-який перегляд (60 днів), де саме посилання з’являється лише в замаскованому вигляді; списку читачів кожного звіту немає.

Імовірність — можлива. Серйозність — обмежена, оскільки звіт показує лише публічну інформацію й строк його дії спливає через 30 або 90 днів відповідно; звіти доменів Клієнтів залишаються доступними, доки існує перевірка (13 місяців, остання довше). Рівень — низький.

R13 — Слабкі місця інфраструктури

Наведені питання позначено відкритими в нашому внутрішньому пакеті перевірки й не прикрашено тут. Ми описуємо їх настільки точно, наскільки Клієнтам потрібно для власної оцінки, але не настільки, щоб опис показував нападнику шлях; подробиці надамо наглядовому органу на запит.

• Резервні копії бази даних наразі зберігаються в тому самому місці, що й база даних, і окремо не шифруються; зашифрована копія в другій локації запланована (cfg/backup_lib.php). До того часу вони не захищають від втрати локації, а той, хто отримує базу даних, отримує й резервні копії. Облікові дані для сканування захищеної входом частини сайту містяться в них лише як шифротекст.
• Немає шифрування бази даних у стані зберігання. Винятки — поля, зашифровані окремо (облікові дані тестових облікових записів, секрет двофакторного входу).
• З’єднання в нашій внутрішній мережі не є наскрізно зашифрованими.
• Адміністрування серверів. Безпека адміністративного доступу до наших серверів ще не відповідає стандарту, який ми плануємо для експлуатації; посилення захисту адміністрування серверів триває.
• Середовище перевірки. Сервер сканування відкриває сторонні сайти в браузері. Контейнери перевірок ізольовані — власна мережа, без спеціальних привілеїв, лише читання, обмеження (scanner/src/worker.js). Розділення середовища перевірки й інших частин сервісу далі посилюється (розділ 9.3).

Імовірність — можлива. Серйозність — серйозна, оскільки в разі надзвичайної ситуації все було б зачеплено одночасно. Рівень — високий. Окремі питання можна усунути звичайними засобами (розділ 9.3).

R14 — Права суб’єктів даних для осіб, які нас не знають

Той, хто випадково з’являється на знімку екрана або чиє повідомлення пройшло через контрольну копію, зазвичай не знає про наше існування. Навіть якщо знає, не має ключа до «своїх» даних: ми зберігаємо їх не за особою, а за доменом і перевіркою. Відповісти на запит доступу за ст. 15 ми можемо лише якщо особа назве домен; тоді можемо переглянути наявні перевірки й зображення. Щодо справжніх повідомлень відвідувачів немає чого розкривати, оскільки ми їх не зберігаємо, — крім домену відправника з R1. Відмова від перевірок діє лише для операторів домену, а не зображених осіб; для них залишається шлях через contact@lukaswojcik.com.

Імовірність — ймовірна як структурна ситуація. Серйозність — обмежена, оскільки дані короткочасні й не організовані за особами. Рівень — низький.

9. (d) Заходи для усунення ризиків

Кожний захід має стан, і ці стани не декоративні. Реалізовано сьогодні — перевірено означає: прочитано в коді системи розроблення й, за можливості, виміряно щодо бази даних. Частково означає: механізм існує, але ще не повністю досягає мети. Заплановано означає: запропоновано цією оцінкою й не реалізовано; чи й коли — вирішує власник. Ще належить визначити — це процедури й рішення, яких не замінює жоден код. Оцінка впливу, яка подає заплановані заходи як реалізовані, втрачає цінність саме в ситуації, у якій потрібна.

9.1 Реалізовано сьогодні — перевірено

Захід	На що спрямований	Посилання на джерело
Сканер читає robots.txt перед кожною перевіркою; виключення, що охоплює головну сторінку, недоступний robots.txt або серверна помилка завершують перевірку (підшляхи не враховуються окремо; пульс, отримання підтвердження, інструмент заголовків і пошук файлів його не читають)	R5, правомірність	scanner/src/net.js
Відмова від перевірок без підтвердження, негайно чинна для домену й варіанта з www, для анонімних перевірок, потенційних клієнтів, досліджень і перевірок Клієнтів (поточний моніторинг завершується з наступною запланованою перевіркою); перевіряється двічі (застосунок і служба перевірок); скасовується лише нами на запит із підтвердженням	R5, R7, ст. 21	cfg/check_lib.php; cfg/akquise_lib.php; cfg/studie_lib.php; scanner/src/worker.js
Безкоштовна перевірка: аварійна зупинка, reCAPTCHA, одна перевірка домену за тиждень, ліміти за IP-адресою й сеансом, щоденний ліміт, без нових доменів, лише публічні адреси, примітка й сигнал без вмісту за аномалій	R5	cfg/check_lib.php
Для лімітів сеанс зберігається лише як хеш-значення, ніколи не ідентифікатор сеансу	Мінімізація	cfg/check_lib.php
Без значень полів (початки прихованих полів і атрибутів даних лише читаються під час перевірки, розділ 6.2); адреси одержувачів лише як домен; ідентифікатори облікових записів в адресах скриптів приховані	Мінімізація	scanner/src/crawl.js
Безкоштовний звіт є витягом: лише основні результати перевірки, без доказів усіх детекторів	R5	cfg/check_lib.php, FE_FREE_DETEKTOREN
Звіти за 128-бітним випадковим посиланням, noindex, зображення лише для власного звіту, поза публічним вебкаталогом; посилання з’являється в журналі доступу до сторінок лише в замаскованому вигляді	R12	cfg/check_lib.php; www/report.php; www/shot.php
Видалення: анонімні звіти через 30 днів, потенційні клієнти через 90 днів, перевірки Клієнтів через 13 місяців (остання для кожного домену зберігається, доки існує домен), дані видаленого домену негайно (винятки див. у розділі 6.11), зображення щоразу разом із ними	Обмеження зберігання	cfg/check_lib.php; cfg/fristen_lib.php
Дослідження: публікація лише сукупних показників, сегменти лише від 20 сайтів із формою, сирі дані видаляються під час публікації	R4 частково, P3	cfg/studie_lib.php
Контейнери перевірок: власна ізольована мережа, без спеціальних привілеїв, лише читання, ліміти пам’яті й процесів, часовий ліміт; фільтр проти приватних цілей для кожного запиту, service worker заблоковані й з’єднання WebSocket закриті, щоб ніщо не обходило фільтра; запити вебсервера лише через вебпорти й лише до точно перевіреної заздалегідь публічної адреси	R13	scanner/src/worker.js; scanner/src/net.js
Активна перевірка для Клієнтів лише для підтвердженого домену (внутрішньо також для наших власних тестових і демонстраційних доменів) та з увімкненим перемикачем аварійної зупинки, перевірено двічі; щонайбільше п’ять надсилань; лише чітко розпізнані контактні форми без обов’язкових персональних даних; без доменів органів влади, освітніх закладів, клінік, медичних практик, поліції чи судів; мовна модель не може нічого дозволити; тестове повідомлення без персональних даних, позначене, із посиланням на сторінку сканера й відмову від перевірок	R9	scanner/src/worker.js; scanner/src/classify.js; scanner/src/active.js
Браузерні сценарії: лише GET і HEAD, небезпечні адреси заблоковані, вигадані значення не залишають браузера, зображення із зафарбованими полями введення	R3 (для цих зображень), R9	scanner/src/browser.js
Перевірка файлів: лише підтверджені домени, одне отримання на шлях, щонайбільше 8 KB, вміст ніколи не зберігається	R9	cfg/dateien_lib.php
Друга проба: типово вимкнена; отримувала б лише фіксований перелік нешкідливих елементів із підписом	Одержувачі	cfg/formular_probe_lib.php
Сканування захищеної входом частини сайту: лише підтверджений домен, платний тариф, власник або адміністратор, підтвердження «тестовий обліковий запис»; шифрування відкритим ключем сервера сканування, прив’язка до домену; облікові дані ніколи не відображаються, не журналюються й не видаються через API; передавання лише через стандартне введення; поле в завданні очищається негайно, залишки — через одну годину; без знімків екрана, надсилань, адрес виходу чи видалення, переривання на CAPTCHA; остаточне видалення з перезаписом	R8	cfg/login_lib.php; scanner/src/login.js; scanner/src/geheim.js; scanner/src/worker.js
Перевірка доставки: типово вимкнена; отримання читає лише заголовки й 8 KB без позначення прочитання; вміст і адреса відвідувача ніколи не потрапляють до бази даних; кожний отриманий лист видаляється, включно з тими, які неможливо віднести до домену; відповідності видаляються через 180 днів; підтвердження лише через копію саме цього тесту	R1, R2	cfg/zustellung_lib.php
Колективний захист: лише домени, IP-мережі вимкнені; мінімальні кількості; винятки для великих сервісів і доменів Клієнтів; карантин замість видалення; список перебудовується щодня; повідомлення видаляються через 30 днів	R11	cfg/swarm_lib.php
Мовна модель на нашому власному сервері без права надсилання	R10	scanner/src/classify.js
Тариф дій: локальна генерація з вибраних результатів перевірки, без знімків екрана чи введених значень полів у запиті до моделі; обмежені кількість результатів і довжина приміток; очищений звичайний текст з обмеженою довжиною; видиме позначення ШІ, окремі результати перевірки визначальні; без автоматичних змін сайту чи рішень щодо оцінки/висновку	R10 частково; неправильні поради й випадкові персональні дані залишаються можливими	cfg/plan_lib.php; www/report.php
Сигнали через Telegram містять лише фіксоване речення без змінних	Одержувачі	cfg/check_lib.php
Щотижневий тест відновлення резервної копії зі сповіщенням у разі невдачі	Доступність	cfg/backup_lib.php; srv/cron_status.php

9.2 Частково — наявне, але ще не досягає мети

Захід	Чому ще не повністю ефективний
«Очищені» знімки екрана	Зафарбовуються лише зображення браузерних сценаріїв. Зображення сканера — головна сторінка й елементи форм — та зображення сторінки відповіді активної перевірки — ні (R3).
Строки для даних перевірок	Діють для анонімних перевірок, потенційних клієнтів і Клієнтів; не для внутрішніх перевірок і неопублікованих досліджень; неусунені примітки про аномалії без часового обмеження (R4).
Видалення контрольних копій	Діє з нашого боку скриньки. Якщо запуск переривається, листи залишаються; що постачальник скриньки зберігає у власних резервних копіях, не перевірено (R2).
Захист облікових даних під час сканування захищеної входом частини сайту	Сильний у стані зберігання й у службі перевірок; не на шляху до сайту: http дозволено, помилки сертифіката ігноруються (R8).
Підтвердження контролю	Перевіряється один раз і потім діє назавжди; однак ім’я хоста домену з підтвердженням контролю неможливо змінити, щоб підтвердження не перейшло до іншого хоста (R7).
Інформування суб’єктів даних	Наявне для операторів через сторінку сканера, ідентифікатор, Політику конфіденційності й відмову від перевірок; для відвідувачів у перевірці доставки залежить від використання Клієнтом текстового блоку; застосунок цього не перевіряє.
Прохання до Клієнтів не включати особливі категорії в контрольну копію	Зазначено в правових документах, але технічно не підтримано: під час налаштування застосунок не запитує тип сайту й не попереджає про домени, схожі на охорону здоров’я, право чи освіту (R1).

9.3 Заплановано — не реалізовано

Захід	На що спрямований	Пріоритет
Шлях видалення внутрішніх перевірок: видаляти перевірки без домену й без звіту після фіксованого строку (пропозиція: 30 днів); видаляти сирі дані дослідження щонайпізніше через фіксований строк після завершення, навіть без публікації (пропозиція: 90 днів); одноразово видалити наявні 85 перевірок із 369 зображеннями	R4	Спочатку
Увімкнути перевірку доставки лише після укладення договору з постачальником скриньки, документування місць зберігання, субобробників і строків резервних копій, з’ясування механізму передавання для постачальника скриньки й спрямування записів MX нашого домену безпосередньо на скриньку; до того часу тримати функцію заблокованою в робочій системі	R2	Спочатку
Перевірити безпеку отримання пошти зі скриньки в робочій системі й задокументувати перед увімкненням перевірки доставки	R2	Спочатку
Сканування захищеної входом частини сайту лише через https і з чинним сертифікатом; відхиляти адреси http; помилки сертифіката під час входу як причина переривання	R8	Спочатку
Не зберігати значення прихованих полів після входу (лише назву, тип і довжину) — уже реалізовано саме так, без подальшого кроку	R8	Виконано
Обмежити контрольну копію тестовими повідомленнями там, де використовується плагін або розширення: прихована копія лише для надсилань із нашим ідентифікатором тесту	R1	Високий
Не зберігати домен відправника справжніх повідомлень і не записувати його в сповіщення, якщо він не є ані доменом сайту, ані доменом відомого сервісу надсилання; натомість у сповіщенні — «сторонній домен відправника»	R1	Високий
Попередження під час налаштування перевірки доставки для доменів, схожих на охорону здоров’я, право, соціальні послуги чи освіту, з посиланням на власну оцінку впливу Клієнта	R1	Високий
Регулярно поновлювати підтвердження контролю (пропозиція: перед кожною активною перевіркою перевіряти, чи досі існує запис DNS, метатег, файл або з’єднання плагіна; інакше продовжувати пасивно й повідомляти Клієнта)	R7	Високий
Припинити фотографувати головну сторінку або робити це лише із зафарбованими зображеннями й обличчями; обмежити зображення форм елементом форми (як сьогодні) й маскувати поля введення як для браузерних сценаріїв	R3	Високий
Примітка в інтерфейсі перевірки потенційного клієнта: надсилання короткого висновку без запиту електронною поштою чи телефоном є прямим маркетингом навіть між підприємствами й потребує попередньої згоди (ст. 398 польського Закону про електронні комунікації; у Німеччині § 7(2) UWG, хоча для дзвінків підприємствам достатньо презюмованої згоди)	R6	Високий
Інфраструктура: завершити посилення захисту адміністрування серверів; зашифрована резервна копія в другій локації; шифрувати з’єднання у внутрішній мережі на всьому шляху; далі посилювати розділення сервера сканування й застосунку	R13	Високий
Строк для неусунених приміток про аномалії (пропозиція: усунення протягом 30 днів, інакше видалення IP-адреси)	R4	Середній
Сторінка чи форма, через яку можна запитати видалення домену з колективного захисту	R11, R14	Середній
Перед увімкненням IP-мереж у колективному захисті: нова версія цієї оцінки	R11	Умова
Зафіксувати, чи програмне забезпечення мовної моделі зберігає запити, і якщо так — вимкнути ці журнали	R10	Низький

9.4 Процедури й рішення, які ще належить визначити

Крім технічних заходів захисту, ст. 35(7)(d) вимагає процедур. Вони ще не визначені:

• Порушення захисту персональних даних. Виявлення: власник, сповіщення застосунку про помилки, повідомлення через канал повідомлення про вразливості або contact@lukaswojcik.com. Рішення щодо повідомлення UODO протягом 72 годин (ст. 33(1)): власник. Інформування відповідних Клієнтів як контролерів: без невиправданої затримки, за можливості протягом 48 годин, як обіцяно в Договорі про обробку даних. Слід визначити: письмовий опис процедури й перше навчальне відпрацювання; для перевірки доставки додатково — як встановити, яких Клієнтів зачіпає порушення в постачальника скриньки.
• Галузі. Слід визначити: чи пропонувати перевірку доставки, пропонувати з попередженням або виключити для сайтів охорони здоров’я, права, соціальних послуг та освіти.
• Внутрішні перевірки. Слід визначити: для чого постачальник використовує внутрішні перевірки з командного рядка, хто може їх створювати й як довго залишаються результати; а також чи потрібно, крім Реєстру діяльності з обробки, називати їх у Політиці конфіденційності.
• Дослідження. Слід визначити: хто складає переліки, із яких джерел, із яким максимальним розміром, а також перевірку перед кожним дослідженням щодо відповідності припущенням цієї оцінки.
• Думки суб’єктів даних (ст. 35(9)). Для цієї версії їх не запитували. Ст. 35(9) вимагає запитувати їх лише «коли це доречно»; за нашою оцінкою, наразі тут це не так. Оператори перевірених сайтів і відвідувачі сайтів Клієнтів не мають власного каналу до нас; цільове звернення до них саме було б новою обробкою їхніх даних, а сервіс ще не запущено, тому групи фактичних суб’єктів даних ще немає. Їхні інтереси враховуються опосередковано: через robots.txt і відмову від перевірок, через короткі строки й те, що вміст контрольних копій не зберігається. Під час кожного перегляду за розділом 12 ми знову розглядаємо доречність запитування їхніх думок, наприклад через відгуки на сторінці сканера чи від Клієнтів перевірки доставки.

10. Залишковий ризик і попередня консультація за ст. 36

Ст. 36(1) вимагає попередньої консультації з наглядовим органом, якщо оцінка впливу вказує, що обробка призвела б до високого ризику за відсутності заходів контролера для його зменшення. Тому питання не в тому, чи виявлено високі ризики — їх чотири, — а в тому, чи залишається високий ризик після впровадження заходів.

Для операцій обробки, щодо яких formexposed є контролером (P1–P4, P7), високі ризики R4 і R13 можна усунути звичайними засобами: шляхом видалення й очищенням наявних даних, зашифрованою резервною копією поза локацією та посиленням захисту двох серверів. Із заходами з 9.3 вони знижуються до низького–середнього рівня. R3, R5, R6 і R7 перебувають на середньому рівні та знижуються до низького із запропонованими заходами. Колективний захист без IP-мереж залишається на низькому–середньому рівні. Для цієї частини попередня консультація не показана, якщо заходи з позначками «спочатку» й «високий» реалізовані перед запуском. Якщо будь-який із цих заходів не реалізований до запуску, для відповідної операції обробки залишається високий ризик. Тоді цю операцію буде розпочато лише після реалізації заходу або спочатку буде проведено консультацію з UODO за ст. 36(1).

Для перевірки доставки (P6) ситуація інша з причини, яку жодний захід повністю не усуває: що пише відвідувач, залежить від нього. З укладеним договором, захищеним отриманням, обмеженням тестовими повідомленнями за можливості та відмовою від домену відправника R2 знижується до низького, а R1 — до середнього. Для Клієнтів, чиї відвідувачі типово надають дані за ст. 9, R1 усе ж може залишатися високим. Тоді обов’язок консультації належить Клієнту як контролеру, а не formexposed. Наша рекомендація таким Клієнтам — не налаштовувати контрольну копію для загальної контактної форми, а лише для форм без чутливого вмісту, або відмовитися від перевірки доставки.

Залишковий ризик, зазначений чесно. Сьогодні із заходами з 9.1 чотири ризики високі: R1 і R2 (перевірка доставки), R4 (дані перевірок без шляху видалення) і R13 (інфраструктура). Із заходами з 9.3 R2, R4 і R13 знижуються до низького–середнього рівня. R1 залишається середнім і постійно залежить від рішень Клієнтів. Жоден з інших ризиків після заходів не перевищує середнього.

Ст. 36 не є покаранням, а консультація — не визнанням провини. Це шлях, який Регламент передбачає для ситуації, коли корисна процедура несе ризик, що не повністю контролюється контролером. Клієнт, який хоче використовувати перевірку доставки для повідомлень із даними про здоров’я, знайде тут факти для цього рішення.

11. Що потрібно Клієнтам для власної оцінки впливу (ст. 28(3)(f))

Для перевірки доставки й сканування захищеної входом частини сайту контролером є Клієнт. Ця сторінка надає йому опис (розділи 6.5 і 6.6), ризики з нашого погляду (R1, R2, R8) і стан заходів (розділ 9). Лише Клієнт може відповісти на наведені запитання:

1. Що пишуть мої відвідувачі? Чи слід очікувати надходження через форму даних про здоров’я, релігію, походження, членство в профспілці, сексуальну орієнтацію, кримінальні правопорушення або дітей? Тоді оцінка впливу для контрольної копії зазвичай потрібна, а використання контрольної копії для цієї форми слід переглянути.
2. Чи потрібна мені контрольна копія всіх повідомлень? Для доведення надходження нашого тестового повідомлення достатньо копії саме цього повідомлення. Якщо форма дозволяє, налаштуйте приховану копію лише для тестових повідомлень.
3. Як я інформую своїх відвідувачів? Цього вимагає Договір про обробку даних; Текст політики конфіденційності для Вашого сайту описує шлях копії й нашу роль.
4. Яку правову підставу я маю? Наш запропонований текст називає ст. 6(1)(f) (надійне отримання звернень). Для даних за ст. 9 самої цієї підстави недостатньо.
5. Які канали сповіщень я вибираю? Сповіщення перевірки автентичності можуть називати домен відправника. Той, хто надсилає сповіщення до чат-сервісів поза ЄС, передає його туди.
6. Для сканування захищеної входом частини сайту: чи справді тестовий обліковий запис є тестовим із мінімально необхідними правами? Чи доступна сторінка входу лише через https? Чи бачить тестовий обліковий запис дані інших користувачів? Якщо так, на яких із визначених сторінок?
7. Коли я видаляю? Перевірку доставки й тестовий обліковий запис можна будь-коли вимкнути й видалити; тоді тестовий обліковий запис безповоротно перезаписується.

Додаткові документи для оцінки Клієнта: Договір про обробку даних, технічні та організаційні заходи, перелік субобробників і Реєстр діяльності з обробки. Ми відповідаємо на запитання про окремі факти за адресою contact@lukaswojcik.com.

12. Перегляд, версія й схвалення

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

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

Пункт	Запис
Контролер	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland · NIP 7252266190 · contact@lukaswojcik.com
Компетентний наглядовий орган	Prezes Urzędu Ochrony Danych Osobowych (UODO), ul. Moniuszki 1A, 00-014 Warszawa, Poland
Фахівець із захисту даних	Не призначений; оцінка за ст. 37 у розділі 4
Основа фактів	Вихідний код застосунку й служби перевірок, схема бази даних, кількість рядків і налаштування системи розроблення, виміряні 11 жовтня 2026 року, лише для читання
Пов’язані документи	Політика конфіденційності, Договір про обробку даних, Технічні та організаційні заходи, Субобробники, Реєстр діяльності з обробки, Регламент ЄС про ШІ, Допустиме використання та зловживання, FormExposedBot, Відмова від перевірок
Версія	1.1 від 23 жовтня 2026 року; фактичний додаток про локальний етап плану дій до першої версії від 11 жовтня 2026 року
Перегляди за ст. 35(11)	23 жовтня 2026 року: перегляд вихідного коду доданого локального етапу плану дій. Вхідні дані, зберігання, ролі, рекомендаційний вивід і реалізовані заходи захисту додано до відповідних розділів; завершеного вимірювання в робочій системі чи нової оцінки залишкового ризику не стверджується. Попередні вимірювання від 11 жовтня 2026 року й наведений нижче стан схвалення залишаються незмінними. Подальші перегляди вносяться сюди з датою, причиною й результатом.
Схвалення	Ще не схвалено. Схвалення власником після юридичної перевірки й рішення щодо заходів із розділу 9.3 та питань із розділу 9.4. Зовнішню консультацію із захисту даних досі не запитували.

Одна завершальна думка належить документу, а не супровідному листу. Частини formexposed, які найдалі заходять у чужі домени, — тестові надсилання й вхід із чужими обліковими даними — реалізовані з найбільшою обережністю: дві умови, жорсткі ліміти, шифрування, що закриває доступ навіть нам. Ризики цієї оцінки переважно в іншому: у тому, що надходить випадково, — справжні повідомлення в прихованій копії, люди на знімку екрана, перевірки, які більше ніхто не видаляє. Це сприятлива вихідна позиція, оскільки випадкове можна зупинити без зміни сервісу.