Реєстр діяльності з обробки (ст. 30 GDPR)

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

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

1. Як читати цей реєстр

Це реєстр діяльності з обробки за ст. 30 GDPR для formexposed. Це не політика конфіденційності й не маркетинг. Його завдання — показати наглядовому органу, Клієнту, який перевіряє нас як обробника, або наступній особі, яка має відповісти на запитання, що фактично обробляється, де зберігається, хто це отримує й як довго воно залишається. Ми публікуємо його, оскільки сервіс, що перевіряє й відстежує форми, сам повинен бути відкритим до перевірки.

Його написання визначали три правила.

1. Виміряне, а не заплановане. Твердження про поля даних, строки зберігання, одержувачів або заходи захисту з’являється лише там, де його підтверджує програмний код, схема бази даних або вимірювання. Заплановане називається «запланованим». Те, що типово вимкнене, називається «типово вимкненим». Де ми не можемо щось довести, ми про це говоримо.
2. Зберігання зазначено двічі. Один раз для кожної діяльності з обробки й один раз у розділі 6 як загальну картину: який нічний запуск видаляє які дані та яких даних не охоплює. Реєстр, який заявляє строк зберігання, що застосовується лише до частини даних, гірший за той, який називає відкрите питання.
3. Відкриті питання зазначено в тексті, а не у виносці. Розділ 8.1 перелічує ще не реалізовані заходи, розділ 10 — відкриті питання із запланованими заходами. Реєстр є робочим інструментом, а не сертифікатом.

Поля даних замість назв таблиць. Для кожної діяльності з обробки ми перелічуємо збережені дані як поля звичайною мовою. Назва таблиці бази даних стоїть у дужках, щоб аудитор міг знайти місце, наприклад «спроби входу (login_attempts)». Переліки полів виведено зі схеми бази даних, а не з пам’яті.

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

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

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

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

2. Суб’єкт і чому цей реєстр має дві частини

Поле	Запис
Суб’єкт	LW IT Solutions Company Lukas Wójcik, одноосібне підприємство, зареєстроване в польському реєстрі підприємницької діяльності (CEIDG); власник Lukas Wójcik
Адреса	al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland
Податкові ідентифікатори	NIP 7252266190, VAT ID PL7252266190
Контакт	contact@lukaswojcik.com; вікно підтримки (знак питання в навігації); сторінка контактів
Сервіс	formexposed: перевірка, моніторинг і захист контактних форм на сайтах (застосунок на formexposed.com, цільова сторінка на form.exposed)
Представник за ст. 27 GDPR	Не застосовується. Суб’єкт має місце здійснення діяльності в Союзі (Польща).
Фахівець із захисту даних	Не призначений. Оцінка за ст. 37 наведена в розділі 9.
Компетентний наглядовий орган	Prezes Urzędu Ochrony Danych Osobowych (UODO, польський орган захисту даних), ul. Moniuszki 1A, 00-014 Warszawa
Хостинг	Наші власні сервери в Польщі: один вебсервер із застосунком і базою даних та один сервер сканування з локальною мовною моделлю в тій самій внутрішній мережі. Без стороннього дата-центру чи хмарного постачальника.

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

• Контролер (Частина B, ст. 30(1)). Ми самі є контролером даних наших власних Клієнтів і членів їхніх команд (обліковий запис, вхід, оплата, підтримка, журнали), відвідувачів нашого власного сайту, перевірок без облікового запису (безкоштовна перевірка, інструмент заголовків, дослідження, перевірка потенційного клієнта) і запобігання зловживанням.
• Обробник (Частина A, ст. 30(2)). Щодо персональних даних третіх осіб, які Клієнт вносить до сервісу або які виникають під час надання нами послуги Клієнту, ми діємо від імені Клієнта: копії реальних листів із форм у перевірці доставки, підписники клієнтського порталу Клієнта, одержувачі його сповіщень, люди, які випадково видимі на перевірених сторінках Клієнта, облікові дані його тестового облікового запису та код форми, який Клієнт вставляє. Підставою є Договір про обробку даних, який укладається з кожним Клієнтом під час реєстрації.
• Лише на боці Клієнта. Деякі функції плагіна WordPress і розширення TYPO3 обробляють дані виключно на сайті Клієнта, і дані ніколи не надходять до нас (карантин, резервне збереження листів, арифметична задача, налаштування зберігання, локальні лічильники, записувач). Це не наша обробка, тому вони не з’являються в жодній частині. Однак ми описуємо їх наприкінці Частини A, щоб межа була видимою.

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

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

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

3. Частина A — ст. 30(2): обробка від імені Клієнтів

A.0 Залучені сторони

Поле	Запис
Обробник	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland; contact@lukaswojcik.com
Контролери	Клієнти formexposed: підприємства й агентства, які мають домени у своєму обліковому записі й використовують функції, у яких виникають дані третіх осіб. Для агентств контролером додатково може бути власний клієнт агентства; тоді агентство діє як обробник щодо цього клієнта, а ми — як подальший обробник.
Перелік контролерів	Частина цього реєстру, яка ведеться в електронній формі (ст. 30(3) GDPR) у системі сервісу й не відтворюється в цій публічній версії, оскільки містить персональні дані Клієнтів і застарівала б із кожним новим Клієнтом: власник кожного робочого простору з ім’ям, адресою електронної пошти й компанією з облікового запису клієнта (адреса й номер платника ПДВ — лише в Stripe) (users, workspaces, workspace_users), а також домени робочого простору (domains). Ми надаємо його наглядовому органу як витяг на запит.
Представники й фахівці із захисту даних контролерів	У системі немає спеціального поля для цього. Якщо Клієнт призначив представника за ст. 27 GDPR або фахівця із захисту даних, він може повідомити нам про них; ми зберігаємо повідомлення разом із переліком контролерів.
Представник обробника	Не застосовується (місце здійснення діяльності в Польщі).
Фахівець із захисту даних	Не призначений (розділ 9).
Вказівки	Вказівка випливає з Договору про обробку даних і налаштувань Клієнта: Клієнт вмикає перевірку доставки, налаштовує адресатів сповіщень, зберігає тестовий обліковий запис і налаштовує клієнтський портал. Без цієї дії відповідна обробка не відбувається.
Технічні та організаційні заходи	Розділ 8 і сторінка Технічні та організаційні заходи застосовуються до кожної діяльності з обробки в Частині A. Спеціальні заходи зазначені у відповідному записі.

A.1 Перевірка доставки — контрольна копія листів із форм

Поле	Запис
Мета	Перевірка того, чи фактично надсилається лист із контактної форми Клієнта та як він автентифікується (SPF, DKIM, DMARC, узгодженість доменів). Після прийнятого активного тестового надсилання його копія повинна надійти до контрольної скриньки протягом налаштовуваного часу очікування (наразі 3 години); інакше виникає сповіщення «Тестовий лист не отримано». Заголовки також використовуються для визначення автентичності листа з форми, поштового сервісу й адреси надсилання для перевірки списків блокування.
Передумова	Платний тариф, підтверджений домен, увімкнено Клієнтом. Клієнт додає власну контрольну адресу з ідентифікатором (у формі «delivery+identifier@…») як приховану копію до сповіщення своєї форми. Без налаштованої контрольної скриньки функція недоступна.
Категорії суб’єктів даних	Відвідувачі сайту Клієнта, які надсилають його форму; особи, чиї дані відвідувач записує в повідомлення; працівники Клієнта, які з’являються в заголовках як одержувачі.
Категорії персональних даних	У контрольній скриньці (у постачальника поштових послуг): повна копія кожного листа з форми, включно з реальними зверненнями з ім’ям, адресою електронної пошти, номером телефона й довільним текстом, до видалення. Читається під час отримання: заголовки й щонайбільше перші 8 KB тіла. У базі даних: час отримання, відповідність домену та, за потреби, тестовому запуску (delivery_log); найновіший результат автентифікації для домену з результатами SPF, DKIM і DMARC, узгодженістю доменів, доменом відправника, доменами підпису й адресою поштового сервера надсилання (поле автентифікації домену в domains). Вміст, тема й адреса відвідувача-відправника не записуються до бази даних.
Примітка щодо домену відправника	Якщо форма зазначає адресу відвідувача як відправника (помилкове налаштування, яке перевірка має виявити), результат автентифікації містить домен цієї адреси, а не саму адресу. Якщо відвідувач використовує особистий домен, це також може бути персональними даними. Він перезаписується під час наступного отримання.
Джерело	Форма на сайті Клієнта через приховану копію, додану Клієнтом.
Правова підстава (визначається контролером)	Визначається Клієнтом. Наш запропонований текст для політики конфіденційності Клієнта обґрунтовує копію ст. 6(1)(f) GDPR (законний інтерес у надійному отриманні звернень). Клієнт інформує своїх відвідувачів про цей потік даних; Договір про обробку даних зобов’язує його до цього.
Одержувачі	Постачальник поштових послуг, який обслуговує контрольну скриньку (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). Копія надходить туди безпосередньо: вона надходить лише якщо записи MX нашого домену вказують на цю скриньку (це перевіряє передстартовий контрольний список); через пересилання вона не доходить до скриньки. На сторінці домену Клієнт бачить лише час, відповідність домену й результат автентифікації. Якщо результат автентифікації погіршується, сповіщення Клієнту й вибраним ним каналам називає домен відправника, якщо він не належить сайту (A.3, 4.1).
Третя країна	Залежить від постачальника поштових послуг; див. розділ 4. Договір із запланованим постачальником і підставу передавання ще не задокументовано.
Зберігання	Після успішної обробки лист позначається для видалення й видаляється зі скриньки в тому самому запуску, навіть якщо його неможливо віднести до жодного домену. Отримання запускається разом із перевіркою стану кожні п’ять хвилин, доки моніторинг увімкнено в адміністративній області (srv/cron_status.php, cfg/zustellung_lib.php). Якщо отримання чи видалення не вдається, лист залишається у скриньці до наступного успішного запуску. Те саме отримання видаляє відповідності в delivery_log через 180 днів. Результат автентифікації існує, доки існує домен.
Що доводить підтвердження	Лише отримання в контрольній скриньці копії, віднесеної до конкретного тестового запуску. Воно не доводить ані отримання фактичним одержувачем, ані запису в CRM. Власного підтвердження від HubSpot не пропонується.
Технічні та організаційні заходи	Розділ 8. Зокрема: вміст оцінюється лише в пам’яті; тіло, тема й повні адреси відправників не зберігаються; видалення незалежно від успішності віднесення до домену.

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

A.2 Клієнтський портал і щомісячний звіт підписникам

Поле	Запис
Мета	Агентство (тариф Business) показує своїм клієнтам стан їхніх доменів під власним брендом (портал за випадковою адресою, за бажанням із паролем, за бажанням на власному піддомені агентства). Там клієнт може замовити щомісячний звіт електронною поштою. Звіт надсилається від імені агентства.
Категорії суб’єктів даних	Клієнти агентства та їхні працівники, які замовляють звіт; особи, які відкривають портал.
Категорії персональних даних	Підписник: адреса електронної пошти, мова, ідентифікатор підтвердження, час замовлення й IP-адреса на момент замовлення, час підтвердження (подвійне підтвердження підписки), час відписування, останній місяць надсилання (client_subscribers). Портал: назва, вибір доменів, випадковий ідентифікатор, пароль лише як хеш, особа, яка його створила, час, відкликання (client_portals). Відвідування порталу відображаються в журналі переглядів сторінок (B.2).
Джерело	Вводиться самими підписниками в порталі.
Правова підстава (визначається контролером)	Згода підписника, отримана через процедуру подвійного підтвердження підписки; контролером є агентство. Ми не пишемо нікому, хто самостійно не підписався й не підтвердив підписку.
Одержувачі	Агентство (бачить своїх підписників); постачальник поштових послуг (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) для листа підтвердження й звіту.
Третя країна	Через постачальника поштових послуг; див. розділ 4.
Зберігання	Нічний запуск видалення (cfg/fristen_lib.php, частина «підписники порталу»): ніколи не підтверджені замовлення — через 30 днів; підписники, що відписалися, — через три роки після відписування як підтвердження попередньої згоди. Підтверджені підписники, які не відписалися, залишаються, доки існує робочий простір агентства. Відкликаний портал лише блокується, а не видаляється; його підписники більше не отримують звітів, але їхні дані залишаються (розділ 10). Портали й підписники негайно видаляються разом із робочим простором (fe_arbeitsbereich_daten_loeschen()). Надіслані звіти залишаються у вихідній пошті 30 днів (B.25).
Технічні та організаційні заходи	Розділ 8. Зокрема: пароль порталу лише як хеш, спроби вгадування обмежені (десять на портал та IP-адресу, 50 на портал за 15 хвилин); відписування одним натисканням у кожному листі; портал показує лише стан і ключові показники, без окремих результатів перевірки з доказами.

A.3 Одержувачі сповіщень Клієнта, особи, що підтверджують отримання, та відповідальні особи

Поле	Запис
Мета	Повідомлення про несправності й зміни адресатам, яких Клієнт налаштовує для домену: електронна пошта, вебхук, Slack, Discord, Microsoft Teams, Google Chat, Telegram. Для кожного адресата — негайно або зібрано щодня чи щотижня, а також адресати лише для ескалацій. Кожне повідомлення про проблему стає інцидентом, отримання якого одержувач може підтвердити через посилання. Для форм на моніторингу Клієнт може визначити відповідальну особу й строк виконання.
Категорії суб’єктів даних	Працівники й постачальники послуг Клієнта, яких він зазначає як адресатів сповіщень або відповідальних осіб; особи, які підтверджують отримання інциденту. Учасники команди з власним обліковим записом також з’являються в Частині B.
Категорії персональних даних	Адресат сповіщень: канал, адреса одержувача (адреса електронної пошти, адреса вебхука чи чату, ID чату Telegram), вибрані події, режим доставки, секрет підпису для вебхуків, остання доставка й остання помилка (alerts). Журнал доставки: адресат, події, стан, помилка, час (alert_log). Черга зведень: рядки повідомлень і посилання до доставки (alert_queue). Інцидент: заголовок, рядки повідомлень, посилання, ідентифікатор підтвердження отримання, час та ім’я чи адреса електронної пошти особи, що підтверджує отримання, введені у формі, а інакше — адреса учасника, який увійшов (alert_incidents). Спроби доставки ескалацій за інцидентом та адресатом: кількість спроб (щонайбільше п’ять), час останньої, наступної спроби й успіху, посилання на лист у вихідній пошті, помилка (таблиця alert_escalation_deliveries). Призначення: обліковий запис відповідальної особи й строк виконання (у monitored_forms).
Вміст повідомлень	Домен, подія, коротке пояснення й посилання на сторінку домену. Без вмісту повідомлень відвідувачів.
Джерело	Вводиться Клієнтом; особа, що підтверджує отримання, вводить своє ім’я самостійно; ID чату Telegram створюється, коли одержувач натискає «Start» у боті (B.32).
Правова підстава (визначається контролером)	Визначається Клієнтом; як правило, організація власної діяльності Клієнта (ст. 6(1)(b) або (f) GDPR щодо працівників і постачальників послуг Клієнта).
Одержувачі	Оператори вибраних каналів; див. 4.1. Сповіщення електронною поштою — через постачальника поштових послуг (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Третя країна	Залежно від вибраного каналу; кілька постачальників розташовані у США, Telegram — поза ЄС без рішення про належний рівень захисту. Див. 4.1.
Зберігання	Журнал доставки — через 90 днів (щоночі, fe_alert_log_aufraeumen() із srv/cron_status.php). Повідомлення зведень — через 30 днів після доставки (cfg/kanal_lib.php, під час кожної доставки зведення). Інциденти — доки не вирішені; вирішені — через 180 днів після вирішення (cfg/vorfall_lib.php, запуск ескалацій) разом зі спробами доставки їхніх ескалацій. Адресати сповіщень і призначення — до видалення Клієнтом або разом із доменом.
Технічні та організаційні заходи	Розділ 8. Зокрема: вебхуки підписані окремим секретом для кожного адресата; підтвердження отримання лише після натискання (POST), щоб попередній перегляд посилань у чат-програмах нічого не запускав; сповіщення під час вікна обслуговування лише записуються до журналу, а не надсилаються.

A.4 Особи, випадково видимі на перевірених сторінках Клієнта й на знімках екрана

Поле	Запис
Мета	Перевірка доменів в обліковому записі Клієнта (сканування, моніторинг, активна перевірка) читає публічні сторінки Клієнта й робить знімки екрана форм. Те, що показує сама сторінка, може стосуватися людей, які не мають стосунку до перевірки. Ці дані виникають випадково; вони не є метою перевірки.
Категорії суб’єктів даних	Люди, чиє ім’я, фотографія чи контактні дані з’являються на перевіреній сторінці (контактна особа біля форми, фотографії команди на головній сторінці, відомості про постачальника).
Категорії персональних даних	Знімки екрана: видима область головної сторінки, кожна видима форма як фрагмент і зображення наступної сторінки після активного тестового надсилання; зберігаються як файли поза вебкаталогом, у базі даних лише посилання (scan_screenshots). Структура форми: адреса сторінки, селектор, назви полів, типи полів, підписи полів, прапорці обов’язковості й видимості, підписи кнопок надсилання (forms, поле «карта полів»); без значень полів. Сканер читає початки прихованих полів (до 24 символів) і атрибутів даних (до 60 символів) лише під час перевірки для розпізнавання позначок часу й токенів; зберігається лише результат. Результати перевірки з доказами (findings), зведення із заголовками сторінок (scans). Для перевірок у платних облікових записах, для яких це доступно, локальна модель генерує план дій за пріоритетами з вибраних результатів перевірки й метаданих сканування; його текст, мова, стан і позначка часу зберігаються у зведенні сканування. Якщо адреса електронної пошти з’являється у формі як одержувач, зберігається лише її домен, ніколи сама адреса.
Джерело	Публічні сторінки домену Клієнта, отримані сканером.
Правова підстава (визначається контролером)	Визначається Клієнтом для вмісту його власного сайту. Для нас обробка є частиною дорученої перевірки.
Одержувачі	Клієнт; для агентств — їхній клієнт через портал або звіт під власним брендом; кожен, хто отримує посилання на звіт (звіти за випадковими адресами, не в пошукових системах). Якщо тип форми неясний, локальна мовна модель на нашому власному сервері отримує для класифікації структуру форми із заголовком сторінки, адресою сторінки й видимим текстом форми (до 400 символів); зображень вона не отримує. Для відповідних платних перевірок локальна модель також отримує ім’я хоста, загальний результат і оцінку, CMS, відповідний тип форми й адресу сторінки, визначений плагін і вибрані невдалі чи неясні результати перевірки для створення плану дій. Запит тимчасово утримується у внутрішній черзі завдань і видаляється після отримання або плановим очищенням записів, старших за одну годину.
Третя країна	Немає.
Зберігання	Результати перевірок домену — щонайбільше 13 місяців; остання завершена перевірка кожного домену залишається (нічний запуск видалення, частина «старі результати перевірок»). Форми, окремі результати виявлення, посилання на зображення й файли зображень видаляються з результатом перевірки. Разом із доменом ці дані видаляються негайно (ланцюг видалення в B.15; винятки в розділі 6.4).
Межі маскування	Знімки екрана повної перевірки нічого не маскують: показують те, що сторінка показує кожному відвідувачу. Поля форм порожні під час отримання, оскільки сканер нічого не вводить; попередньо заповнені значення були б видимими. Після входу знімки екрана не робляться (A.5). Зображення браузерних перевірок маскують поля введення (A.6).
Технічні та організаційні заходи	Розділ 8. Зокрема: зображення можна отримати лише через звіт, а чужий ідентифікатор зображення повертає «не знайдено»; звіти з noindex; кожна перевірка працює у власному ізольованому контейнері.

Ті самі дані виникають у перевірках без облікового запису (безкоштовна перевірка, дослідження, перевірка потенційного клієнта). Там немає Клієнта, від імені якого ми діємо; тому ці випадки наведено в Частині B (B.5, B.7, B.8).

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

Поле	Запис
Мета	Читання форм, які з’являються лише після входу (клієнтська область, область учасників). Сканер входить із тестовим обліковим записом, який Клієнт створив на власному сайті, й читає визначені сторінки. Крім форми входу, він нічого не надсилає, не проводить там активних тестів, не робить знімків екрана й не відвідує адрес виходу, видалення чи скасування. Якщо форма входу містить CAPTCHA, він зупиняється; CAPTCHA не обходяться.
Передумова	Підтверджений домен, платний тариф, роль власника чи адміністратора, пряме підтвердження, що обліковий запис тестовий. Щонайбільше п’ять сторінок, усі на тому самому домені.
Категорії суб’єктів даних	Особа, на ім’я якої ведеться тестовий обліковий запис (в ідеалі ніхто; Клієнту слід використовувати функціональний обліковий запис); особи, чиї дані з’являються на сторінках після входу.
Категорії персональних даних	Ім’я користувача й пароль тестового облікового запису, лише зашифровані; підказка для імені користувача (перший символ і довжина); адреса входу, перелік сторінок, назви полів входу, індикатор успіху, особа, яка створила запис, час, останній результат як короткий код (domain_logins). Для поточного завдання — копія шифротексту (поле «пакет входу» в scan_jobs). Із сторінок після входу: структура форм як у A.4, без знімків екрана й без cookie.
Джерело	Вводиться Клієнтом в обліковому записі.
Правова підстава (визначається контролером)	Визначається Клієнтом. Клієнт гарантує, що має право використовувати тестовий обліковий запис.
Одержувачі	Немає. Ані Клієнт, ані підтримка, ані програмний інтерфейс не можуть прочитати облікові дані; інтерфейс показує лише підказку для імені користувача.
Третя країна	Немає.
Захист облікових даних	Ім’я користувача й пароль шифруються негайно під час збереження відкритим ключем сервера сканування (X25519, HKDF-SHA256, AES-256-GCM; домен прив’язано як асоційовані дані, тому шифротекст неможливо приєднати до іншого домену). Закритий ключ має лише сервер сканування. Вебсервер, база даних і резервні копії містять лише шифротекст; ми також не можемо розшифрувати його там. Сервер сканування розшифровує лише на час запуску, передає облікові дані до ізольованого контейнера перевірки лише через стандартне введення, негайно видаляє копію в завданні й не записує її до жодного результату, журналу чи тексту помилки. На шляху до сайту Клієнта вони захищені лише шифруванням цього сайту; обмеження цього передавання визначено в розділі 10.
Зберігання	Збережені облікові дані — до видалення Клієнтом. Під час видалення шифротекст перезаписується випадковими даними тієї самої довжини, а рядок видаляється; завдання в очікуванні очищаються (fe_login_loeschen()). Разом із доменом рядок видаляється через зовнішній ключ. Сервер сканування очищає копії в завданнях після запуску; усе, що залишилося (завдання перерване, сервер сканування недоступний), очищає запуск перевірки стану щонайпізніше через одну годину (fe_login_aufraeumen(), частина «login_jobs»). Резервні копії бази даних містять шифротекст до спливу строку зберігання копії через 14 днів.
Технічні та організаційні заходи	Розділ 8. Зокрема: асиметричне шифрування з окремими ключами; список блокування шляхів виходу й видалення; без знімків екрана після входу; функція лише для платних тарифів і підтверджених доменів; кожна зміна в журналі дій (без облікових даних).

Ми свідомо не створили жодного способу зберігати облікові дані для сервера Клієнта, адміністративної області CMS або облікових записів хостингу. Тестовий обліковий запис — це обліковий запис відвідувача на сайті Клієнта, а не доступ до його системи.

A.6 Налаштовані сценарії форм, браузерні перевірки й незалежна проба

Поле	Запис
Мета	Форма на моніторингу проходиться в реальному браузері (Chromium, WebKit або обох) до моменту безпосередньо перед надсиланням: завантажити сторінку, виконати попередні натискання (щонайбільше п’ять, ніколи не на полі введення чи кнопці надсилання), заповнити поля явно синтетичними значеннями (як-от адресою із зарезервованим закінченням .invalid), пройти багатокрокові форми. Браузерна перевірка нічого не надсилає; надсилання технічно заблоковане в браузері. Додатково — вимірювання часу й візуальні порівняння форми.
Категорії суб’єктів даних	Як у A.4 (особи, видимі на сторінці форми); працівники Клієнта, зазначені як відповідальні особи (A.3).
Категорії персональних даних	Конфігурація: адреса форми, селектори, початкова адреса, кроки натискань, вибір браузера, підпис, критичність, призначення, строк виконання (monitored_forms). Результати кожного запуску: стан, технічна причина відмови, очищені повідомлення про помилки, мережеві й часові вимірювання, зображення форми як JPEG щонайбільше 32 KB із замаскованими полями введення (form_browser_runs). Спостереження за перевіркою (form_observations), часові ряди (form_performance). Завдання з переліком цілей (поля «targets» і «result» у scan_jobs).
Тестовий доступ	Якщо Клієнт зберіг тестовий обліковий запис (A.5), повна перевірка також використовує його для налаштованих сценаріїв форм. Згідно з виміряним кодом окремі браузерні перевірки між двома повними перевірками працюють без тестового облікового запису.
Незалежна проба	Передбачено другу точку перевірки в іншій локації, яка виконувала б перехресну перевірку перед сповіщенням. Вона отримувала б домен, очищену конфігурацію та ідентифікатор завдання, без введення відвідувачів і без облікових даних. Наразі вона не налаштована (типово вимкнена). Без проби немає доказів із другої локації; тоді сповіщення ґрунтується на нашому власному вимірюванні.
Джерело	Налаштовується Клієнтом; результати — з отримання сторінки Клієнта.
Правова підстава (визначається контролером)	Визначається Клієнтом для вмісту його сайту й обов’язків його працівників.
Одержувачі	Клієнт; якщо пробу налаштовано — її оператор (наразі ніхто).
Третя країна	Немає.
Зберігання	Результати браузерних запусків, завершені браузерні завдання й часові ряди — через 13 місяців (нічний запуск видалення, частини «browser_runs», «browser_jobs», «form_performance»). Конфігурації — до видалення домену (окремо їх можна змінити або вимкнути, але не видалити); разом із доменом вони видаляються через зовнішні ключі разом із запусками, спостереженнями й часовими рядами.
Що доводить вимірювання	Часові показники й стани з нашого браузера перевірки. Вони не вимірюють досвіду реальних відвідувачів і не доводять ані частки завершень, ані втрачених звернень.
Технічні та організаційні заходи	Розділ 8. Зокрема: надсилання технічно унеможливлене; лише адреси на тому самому домені; замасковані зображення; ізольований контейнер перевірки.

A.7 «Fix it for me» — вставлений код форми

Поле	Запис
Мета	Клієнт вставляє код своєї форми; мовна модель на нашому власному обладнанні вбудовує модуль захисту. У відповідь повертаються змінений файл, патч, результат перевірки синтаксису й зазначення того, чи справді вбудовано виклик перевірки. Без вставленого коду сервіс надає готовий модуль із назвами полів з останнього сканування.
Категорії суб’єктів даних	Особи, чиї дані випадково містяться у вставленому коді (як-от адреса одержувача, імена в коментарях, облікові дані поштового сервера).
Категорії персональних даних	Вставлений код, щонайбільше 30 000 символів. У базі даних лише запис у журналі дій (дія «fix_ai» із робочим простором і часом), який ураховується в щоденному ліміті наразі десяти викликів на робочий простір.
Джерело	Вставляється Клієнтом.
Правова підстава	Виконання договору з Клієнтом (ст. 6(1)(b) GDPR) щодо самого коду; для даних третіх осіб, що випадково містяться в ньому, підставу визначає Клієнт.
Одержувачі	Немає. Мовна модель працює на нашому власному сервері сканування у внутрішній мережі; жодного зовнішнього сервісу ШІ, навіть як резервного варіанта.
Третя країна	Немає.
Зберігання	Код не зберігається. Для перевірки синтаксису створюється тимчасовий файл і негайно видаляється після неї. Запис у журналі дій видаляється через 365 днів.
Примітка Клієнту	Код, що містить паролі, ключі API або персональні дані, слід очистити перед вставленням. Ми не перевіряємо вмісту.
Технічні та організаційні заходи	Розділ 8. Зокрема: лише власники й адміністратори платних тарифів; вставлений код передається моделі з позначенням як дані й ніколи не виконується; без завантаження на сторонні сервери.

A.8 Брендове оформлення та контактні особи агентства

Поле	Запис
Мета	Звіти, короткі звіти, журнали доказів і клієнтський портал агентства (тариф Business) відображаються під його брендом, за бажанням — на власному піддомені агентства.
Категорії суб’єктів даних	Контактні особи агентства, чиє ім’я або контактні дані з’являються в контактному рядку.
Категорії персональних даних	Назва компанії, сайт, контактний рядок, примітка клієнту, акцентний колір, оформлення, файл логотипа, перемикач згадки про formexposed, власний домен з ідентифікатором і станом перевірки (workspace_branding).
Джерело	Вводиться агентством.
Правова підстава	Виконання договору з агентством (ст. 6(1)(b) GDPR). Якщо контактний рядок називає працівників агентства, підставу визначає агентство.
Одержувачі	Кожен, кому агентство надає посилання на звіт, короткий звіт або портал.
Третя країна	Немає.
Зберігання	До зміни агентством; бренд і файл логотипа видаляються разом із робочим простором (fe_arbeitsbereich_daten_loeschen()). Власний домен, перевірка DNS якого не вдається протягом семи днів, вимикається. Власний домен типово вимкнений.
Технічні та організаційні заходи	Розділ 8.

A.9 Лічильники, показники стану й помилки полів із плагіна та розширення

Поле	Запис
Мета	Раз на день плагін WordPress і розширення TYPO3 повідомляють показники форм на з’єднаному сайті: заблоковані надсилання за причинами, надсилання, надіслані й невдалі листи, показники стану налаштувань форм, збережені звернення за джерелом і строком зберігання. Необов’язково, типово вимкнено: події форм і категорії помилок полів за позицією поля. Ці показники створюють «Захист у цифрах», щомісячний звіт, сповіщення про тишу й повідомлення про ризиковані налаштування.
Класифікація	Показники спроєктовано так, щоб вони не описували жодної особи. Ми наводимо їх у Частині A, оскільки вони виникають із подій на сайті Клієнта, спричинених його відвідувачами; на нашу думку, вони є персональними даними щонайбільше в граничних випадках (сайт із дуже малою кількістю надсилань у певний день). Саме передавання (ключі, версії, хост) наведено в Частині B (B.20).
Категорії суб’єктів даних	Відвідувачі сайту Клієнта, які надсилають форму.
Категорії персональних даних	Щоденні показники за хостом: заблоковано загалом і за причинами, надсилання, надіслані й невдалі листи, категорія помилки надсилання пошти (лише одна з чотирьох категорій, ніколи текст помилки, оскільки він може містити адреси одержувачів), кількість відповідей reCAPTCHA, видалені й розблоковані звернення (plugin_stats). Стан: версії з фіксованого переліку плагінів форм, CAPTCHA й пошти, числові показники налаштувань, строки зберігання (plugin_health). Повідомлення про зміни: назва й версія оновленого плагіна (plugin_changes). Необов’язково: лічильники за формою й днем із категоріями помилок за позицією поля (form_metrics). Ніколи: введення, назви полів, паролі, файли, адреси електронної пошти, імена, IP-адреси або постійні ідентифікатори відвідувачів.
Джерело	Плагін на сайті Клієнта через програмний інтерфейс із секретом з’єднання сайту.
Правова підстава (визначається контролером)	Визначається Клієнтом; Клієнт вирішує, чи активувати необов’язкові лічильники та як інформувати відвідувачів.
Одержувачі	Клієнт. Домени посилань із заблокованих повідомлень потрапляють до колективного захисту (B.21).
Третя країна	Немає.
Зберігання	Щоденні показники, повідомлення про зміни й лічильники форм — через 13 місяців (нічний запуск видалення, частини «plugin_stats» і «form_metrics»). Показники стану перезаписуються з кожним повідомленням. Усі дані плагіна для хоста видаляються, щойно жоден домен у системі більше не посилається на цей хост (негайно під час видалення останнього домену; старі дані — щоночі, частина «orphan_hosts»).
Що доводять показники	Те, що підрахував плагін. Вони не доводять ані частки завершень, ані втрачених звернень.
Технічні та організаційні заходи	Розділ 8. Зокрема: приймання лише з прив’язаною до сайту парою ключів; приймаються лише відомі ключі й числа, усе інше відкидається; дні поза 14-денним вікном відхиляються.

A.10 Межа: що залишається лише на сайті Клієнта

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

Функція	Що обробляється локально	Зберігання на боці Клієнта
Карантин	Зупинені надсилання з причиною, які можна розблокувати для надсилання електронною поштою на адресу сайту	14 днів
Резервне збереження листів	Надсилання, листи форм для яких не вдалося надіслати, для повторного надсилання (типово ввімкнено)	30 днів
Арифметична задача замість reCAPTCHA	Арифметична задача в браузері відвідувача, без стороннього сервісу (типово вимкнено)	–
Налаштування зберігання	Видалення збережених звернень у плагінах форм після вибраного оператором строку (типово вимкнено)	відповідно до налаштувань
Обмеження частоти	короткочасний ідентифікатор, виведений з IP-адреси, не передається нам	короткочасно
Локальні щоденні лічильники	Значення лічильників перед передаванням	щонайбільше 14 днів
Записувач для адміністраторів	технічні селектори й кроки навігації в сеансовому сховищі браузера адміністратора, який увійшов; введення не читається. Передається лише вибрана конфігурація (тоді A.6)	щонайбільше 15 хвилин
Допомога відвідувачам	може активуватися окремо; не зберігає чернеток і не надсилає повторно автоматично	–
Спостереження за новими правилами спаму	додаткові спрацювання підраховуються локально, без автоматичної активації	сім днів

A.11 Захист форм (formconfirmed)

Поле	Запис
Мета	Оцінювання надсилань через форми на сайтах Клієнта для розпізнавання автоматизованих надсилань: видача й перевірка завдань (доказ виконання обчислювальної роботи), одноразові перевірочні токени, час заповнення, поле-пастка, численні запити; на бажання Клієнта — оцінювання тексту повідомлення мовною моделлю. Лише для Клієнтів, які вмикають захист форм.
Категорії суб’єктів даних	Відвідувачі сайтів Клієнта, які відкривають сторінку із захищеною формою або надсилають її.
Категорії персональних даних	IP-адреса (зберігається лише скороченою та гешованою з ключем, що змінюється щодня), адреса й домен сторінки, моменти часу та час заповнення, чи заповнено поле-пастку (так/ні), ідентифікатор браузера в журналі вебсервера; лише за ввімкненої перевірки вмісту — текст повідомлення (лише в оперативній пам’яті).
Джерело	Браузер відвідувача (завдання, перевірочний токен); сервер Клієнта (запит на перевірку, за потреби текст).
Одержувачі	Клієнт (бал, дія, причини). Інших немає; субобробників для цієї обробки немає.
Третя країна	Немає.
Зберігання	Гешований ідентифікатор — 1 година; використані перевірочні токени — щонайбільше 11 хвилин; результати перевірки без IP-адреси й без тексту — 30 днів; щоденні показники — 400 днів; журнал вебсервера — 14 днів; текст не зберігається.
Технічні та організаційні заходи	Розділ 8; додатково скорочення й гешування з денним ключем, підписані завдання, одноразове використання, мовна модель на власному обладнанні без запису тексту в журнал.

4. Частина A — одержувачі, субобробники й передавання до третіх країн

Наведена таблиця перелічує одержувачів, яких ми самі залучаємо і які можуть отримувати дані з Частини A. Визначальним постійно оновлюваним переліком є сторінка Субобробники; якщо вона відрізняється від цієї таблиці, це виявлена невідповідність, а не питання форматування.

Одержувач	Що отримує	Третя країна	Підстава	Стан
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Контрольна скринька перевірки доставки (A.1); надсилання листів-сповіщень (A.3), підтверджень і звітів підписникам порталу (A.2)	Місце обробки ще належить перевірити; див. сторінку «Субобробники»	Договір про обробку даних; підставу передавання ще належить перевірити	Відкрито. Відповідний договір, фактичні місця обробки й підставу передавання ще не задокументовано. Цей реєстр не підтверджує ані сертифікації, ані укладеного договору.
Namecheap, Inc. (реєстратор, DNS; пересилання пошти до налаштування скриньки)	До налаштування скриньки — загальна вхідна пошта, адресована на наш домен; не копії з перевірки доставки, які надходять лише за записів MX, спрямованих безпосередньо на скриньку (A.1)	США	підлягає перевірці: сертифікація за EU-US Data Privacy Framework або стандартні договірні положення	Використовується; підстава відкрита.
Наш власний сервер сканування з локальною мовною моделлю	Структура форми для класифікації й вибрані результати перевірки з метаданими сканування для планів дій у платних облікових записах (A.4), вставлений код (A.7), розшифровані тестові облікові дані лише під час запуску (A.5)	–	Експлуатується нами, не третя особа	Використовується.
Незалежна проба в другій локації	Домен, очищена конфігурація, ідентифікатор завдання (A.6)	залежно від локації	слід визначити перед введенням в експлуатацію	Не налаштовано.

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

4.1 Канали сповіщень, вибрані Клієнтом

Крім одержувачів, яких залучаємо ми, є канали, які Клієнт вибирає для своїх сповіщень (A.3). Наш сервер запускає передавання; Клієнт визначає адресата й постачальника. Вибір каналу не звільняє нас від власних обов’язків обробника. Роль, договір і заходи захисту, потрібні для третіх країн, необхідно визначити для кожного постачальника; для чат-сервісів це ще не завершено (відкрите питання юридичної перевірки).

Канал	Що надсилається	Місцезнаходження постачальника
Електронна пошта	Домен, подія, пояснення, посилання; на введену адресу	через Namecheap, Inc. (Private Email), Phoenix, Arizona, USA
Вебхук на довільно вибрану адресу	Подія як JSON (домен, події, рядки, посилання, позначка часу), підписана секретом адресата	визначається Клієнтом
Slack, Discord, Microsoft Teams, Google Chat	те саме сповіщення як повідомлення чату на введену адресу вебхука	переважно США
Telegram	адресат, вибраний Клієнтом; ми надсилаємо повідомлення через нашого бота на пов’язаний ID чату	поза ЄС, без рішення про належний рівень захисту; підстава передавання — відкрите питання юридичної перевірки

У жодному випадку вміст повідомлення відвідувача не надсилається. Сповіщення містять домен, подію й посилання.

5. Частина B — ст. 30(1): обробка під нашу власну відповідальність

Контролер щодо всього в цій частині: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland, contact@lukaswojcik.com. Представник не потрібен (місце здійснення діяльності в Союзі). Фахівця із захисту даних не призначено (розділ 9). Технічні та організаційні заходи: розділ 8 і сторінка Технічні та організаційні заходи. Як суб’єкти даних реалізують свої права, описано на сторінці Доступ, видалення та інші Ваші права; власники облікових записів можуть самостійно завантажити свої дані у файл (Налаштування).

Коли ми покладаємося на законні інтереси (ст. 6(1)(f) GDPR), ми називаємо інтерес і причину, з якої менш втручальний засіб недостатній. Зважування є нашою оцінкою; воно є частиною юридичної перевірки.

B.1 Відвідувачі нашого сайту — журнали вебсервера

Поле	Запис
Мета	Робота й безпека сайту та застосунку: надання вмісту, усунення несправностей, виявлення атак і перевантаження.
Категорії суб’єктів даних	Кожен, хто відкриває сторінку formexposed.com або form.exposed, включно з відвідувачами сторінок Клієнтів, браузер яких завантажує наше зображення значка (B.18), одержувачами, які відкривають звіт або посилання підтвердження отримання, та сайтами, плагін яких викликає наш інтерфейс.
Категорії персональних даних	Повна IP-адреса, час, запитана адреса, код стану, передані байти, сторінка переходу (referrer), ідентифікатор браузера (user agent).
Де зберігається	Журнали доступу проміжного проксі й вебсервера як файли на вебсервері, не в базі даних.
Джерело	Браузер або програма, що надсилає запит.
Правова підстава	Ст. 6(1)(f) GDPR. Інтерес: безпечна й безперервна робота. Зважування: без повної адреси неможливо пов’язати повторні запити одного відправника й відвертати атаки; скорочена адреса не підтримує такого розрізнення. Журнали не поєднуються з іншими даними й видаляються після короткого строку.
Одержувачі	Немає.
Третя країна	Немає.
Зберігання	14 днів: щоденна ротація з 14 поколіннями, потім перезаписуються (системна служба ротації журналів, а не нічний запуск видалення застосунку).
Технічні та організаційні заходи	Розділ 8.

B.2 Журнал переглядів сторінок застосунку

Поле	Запис
Мета	Безпека й виявлення зловживань (хто, що й як часто запитує), простежуваність доступу до облікового запису, проста статистика використання без аналітичного сервісу.
Категорії суб’єктів даних	Усі відвідувачі сайту й користувачі застосунку під час справжніх переглядів сторінок (без фонових запитів, без надсилань форм).
Категорії персональних даних	Повна IP-адреса, країна, визначена за нею під час запису (локальна геобаза, без запиту до третьої особи), ID облікового запису користувачів, які увійшли, запитана адреса й сторінка переходу (токени доступу в них, як-от у посиланнях на звіти чи портали, замасковані), ідентифікатор браузера та визначені за ним тип пристрою, операційна система й браузер, мова, час (access_logs). Під час «Перегляду як клієнт» (B.14) ID облікового запису не встановлюється, щоб перегляди сторінок підтримкою не з’являлися в журналі Клієнта.
Джерело	Запит браузера.
Правова підстава	Ст. 6(1)(f) GDPR. Інтерес: запобігання зловживанням і простежуваність. Зважування: як у B.1; строк зберігання довший, оскільки шаблони зловживань стають видимими протягом тижнів. Чи слід скоротити IP-адресу або строк зберігання — відкрите питання юридичної перевірки.
Одержувачі	Немає. Власники облікових записів отримують власні перегляди сторінок в експорті даних.
Третя країна	Немає.
Зберігання	60 днів (щоночі між 03:00 і 03:05, srv/cron_status.php, налаштування «журнал переглядів сторінок»).
Технічні та організаційні заходи	Розділ 8. IP-адреса береться з пересланого заголовка лише якщо запит надходить від нашого власного проміжного проксі, і тоді лише запис, доданий цим проксі; інакше будь-хто міг би довільно вказувати своє походження.

B.3 Cookie та зберігання в браузері

Поле	Запис
Мета	Технічно необхідне зберігання: сеанс, захист від підроблення міжсайтових запитів (CSRF), підрахунок лімітів перевірок без облікового запису, вхід, збереження входу за бажанням, світле чи темне оформлення.
Категорії суб’єктів даних	Відвідувачі й користувачі formexposed.com.
Категорії персональних даних	Сеансовий cookie bpid (ідентифікатор сеансу; завершується із закриттям браузера; HttpOnly, SameSite=Lax, Secure через HTTPS). Cookie bp_remember лише після вибору «Залишатися в системі» (селектор і перевірна частина; 30 днів). Локальне сховище bp_theme (світле, темне або системне). В адміністративній області — додатково локальні налаштування відображення операторів. Для лімітів з ідентифікатора сеансу формується хеш; сам ідентифікатор не зберігається.
Не встановлюється	Жодних аналітичних, рекламних або відстежувальних cookie. Партнерська програма (B.33) працює без cookie. Зображення значка на сторінках Клієнтів не встановлює cookie (B.18). reCAPTCHA може встановлювати cookie Google під час надсилання захищеної форми (B.23).
Правова підстава	Доступ до кінцевого пристрою: суворо необхідний для послуги, запитаної користувачем (§ 25(2) пункт 2 TDDDG, німецького Закону про захист даних у телекомунікаціях і цифрових послугах; ст. 399(3) PKE, польського Закону про електронні комунікації (Prawo komunikacji elektronicznej)). Обробка: ст. 6(1)(b) GDPR (обліковий запис) і (f) (безпека, ліміти).
Одержувачі	Немає.
Третя країна	Немає.
Зберігання	Сеанс; 30 днів для токена збереження входу. Нічний запуск видаляє прострочені токени збереження входу в базі даних (remember_tokens); під час виходу, зміни пароля й відкликання пристрою — негайно.
Технічні та організаційні заходи	Розділ 8.

B.4 Безкоштовна перевірка без облікового запису — приймання, ліміти й моніторинг зловживань

Поле	Запис
Мета	Будь-хто може замовити перевірку домену без облікового запису. Щоб поле введення не стало зброєю проти сторонніх сайтів, діють багаторівневі ліміти: одна анонімна перевірка домену за сім днів (після цього — той самий звіт), ліміти за IP-адресою й сеансом за 24 години, щоденний ліміт усієї системи, блокування дуже молодих доменів, список блокування й відмови від перевірок, лише публічні адреси. Підозрілі шаблони фіксуються й повідомляються оператору. Ліміти за IP-адресою, сеансом і всією системою, кожен із окремим підрахунком, також застосовуються до перевірки з плагіна без облікового запису (плагін із прив’язаною парою ключів підраховується за сайтом замість адреси) та відмови від перевірок (B.30); безкоштовний інструмент заголовків (B.9) має власні ліміти за IP-адресою й днем та всією системою.
Категорії суб’єктів даних	Особи, які запускають перевірку, запит інструмента заголовків або відмову від перевірок; сервери, на яких установлено плагін.
Категорії персональних даних	Журнал кожного запиту: джерело (перевірка, плагін, інструмент заголовків, відмова від перевірок), повна IP-адреса, хеш ідентифікатора сеансу, перевірений хост, країна з IP-адреси, прийнято чи відхилено з причиною, час (check_throttle). Аномалії: тип (IP-адреса, сеанс, країна, система), ключ (для типу «IP» — повна IP-адреса), шаблон, серйозність, короткий опис, час виявлення й усунення, особа, яка усунула (abuse_flags). Завдання: хост, режим, рівень довіри й скорочений хеш сеансу як ідентифікатор ініціатора (scan_jobs). Звіт: випадковий ідентифікатор, хост, мова, строк дії, перший перегляд, кількість переглядів (reports). Кешований вік домену із запиту до реєстру (domain_age_cache).
Джерело	Введення особи; її запит; запит до реєстру (RDAP) щодо віку домену.
Правова підстава	Виконання запитаної перевірки: ст. 6(1)(b) GDPR (використання безкоштовної перевірки за Умовами надання послуг); альтернативно — (f). Ліміти й моніторинг: ст. 6(1)(f). Інтерес: запобігти використанню сервісу як інструмента проти сторонніх сайтів або як гармати для спаму. Зважування: без прив’язування до адреси й сеансу неможливо було б забезпечити ліміти; семиденний строк такий самий короткий, як найдовший ліміт, що за ним підраховується.
Одержувачі	Google (reCAPTCHA під час надсилання, B.23). Для віку домену сканер запитує сервіс перенаправлення RDAP rdap.org, який пересилає до відповідального реєстру; передається лише доменне ім’я. Коли виникає аномалія, оператор отримує сигнал через Telegram без жодних змінних (без хоста, без адреси). Звіт може побачити той, хто має його випадкове посилання.
Третя країна	США через reCAPTCHA (B.23).
Зберігання	Журнал запитів — 7 днів (щоночі, srv/cron_status.php). Усунені аномалії — через 90 днів після усунення; неусунені залишаються, доки хтось їх не усуне (розділ 10). Строк дії анонімних звітів спливає через 30 днів; потім нічний запуск видаляє звіт, завдання, результат перевірки, форми, окремі результати виявлення й зображення (fe_reports_aufraeumen()). Адміністратор може вручну зняти обмеження для адреси; це видаляє її журнал за останні 24 години.
Технічні та організаційні заходи	Розділ 8. Аварійна зупинка всіх анонімних перевірок в адміністративній області; зворотний тиск, що не приймає нових безкоштовних перевірок за наявності затору в черзі.

B.5 Сканерна перевірка сторонніх сайтів

Поле	Запис
Мета	Перевірка безпеки публічних контактних форм: захист від спаму й зловживань, властивості захисту даних і доступності, вбудовані сторонні скрипти, поведінка після відмови в банері cookie, мобільне відображення. Застосовується до перевірок без облікового запису (B.4), доменів в обліковому записі, які ще не підтверджені, та як основа дослідження (B.7) і перевірки потенційного клієнта (B.8). Для підтверджених доменів в обліковому записі ми діємо від імені Клієнта (A.4).
Поведінка сканера	Власний ідентифікатор із посиланням на сторінку сканера; читає robots.txt перед перевіркою й зупиняється, якщо правило disallow охоплює головну сторінку (так само якщо robots.txt недоступний або є серверна помилка); правила disallow для окремих підшляхів не враховуються окремо. Пульс форми, отримання підтвердження, інструмент заголовків і пошук відкритих для доступу файлів не читають robots.txt. Щонайбільше вісім публічних сторінок за перевірку, додатково до трьох сторінок із натисканням «Відхилити» в банері cookie, до трьох сторінок у вигляді для телефона, активні проби для підтверджених доменів і до п’яти сторінок після входу (A.5); сторінки завантажуються послідовно, а не паралельно; лише публічні адреси, без внутрішніх мереж, перенаправлення перевіряються повторно; список блокування й відмови від перевірок перевіряються перед прийняттям і вдруге в сканері. Пасивно: без підтвердження контролю для Клієнтів нічого не надсилається (виняток: внутрішні перевірки наших власних тестових і демонстраційних доменів, B.6).
Категорії суб’єктів даних	Оператори перевірених сайтів (якщо вони є фізичними особами, як-от фізичні особи — підприємці); особи, які випадково видимі на перевірених сторінках.
Категорії персональних даних	Як у A.4: адреси й заголовки сторінок, структура форм (назви, типи й підписи полів, без значень полів), заходи захисту, сторонні скрипти (адреси; ID облікових записів пікселів та інструментів запису замінюються перед збереженням), поведінка банера cookie, знімки екрана (видима область головної сторінки, форми). Якщо адреса одержувача з’являється у формі — лише її домен (scans, forms, findings, scan_screenshots).
Джерело	Публічно доступні сторінки.
Правова підстава	Ст. 6(1)(f) GDPR. Інтерес: виконання запитаної перевірки безпеки; повідомлення операторам сайтів про слабкі місця, які можуть зашкодити їхнім відвідувачам. Зважування: читається лише те, що бачить кожен відвідувач, у невеликому обсязі й без надсилання; оператор може будь-коли назавжди виключити свій домен без підтвердження. Інформація за ст. 14 GDPR надається через сторінку сканера, відмову від перевірок і Політику конфіденційності; чи достатньо цього за ст. 14(5)(b) — відкрите питання юридичної перевірки.
Одержувачі	Той, хто запускає звіт, і кожен, кому він надає випадкове посилання; локальна мовна модель на нашому власному сервері, коли тип форми неясний (структура форми, заголовок і адреса сторінки, видимий текст форми). Попередження про вразливості з версій плагінів ніколи не з’являються в анонімних звітах.
Третя країна	Немає.
Зберігання	Анонімно: 30 днів (B.4). Перевірка потенційного клієнта: 90 днів (B.8). Дослідження: до публікації (B.7). Домен в обліковому записі: щонайбільше 13 місяців, остання перевірка залишається; негайно разом із доменом. Внутрішні перевірки оператора без домену й без звіту (як-от створені з командного рядка): строку зберігання немає (розділ 10). Тимчасові файли на сервері сканування видаляються після кожного запуску.
Технічні та організаційні заходи	Розділ 8. Зокрема: окремий контейнер перевірки зі зниженими привілеями, файловою системою лише для читання, лімітом пам’яті й власною мережею; подвійна перевірка цілі.

B.6 Активні тестові надсилання

Поле	Запис
Мета	Перевірка того, чи приймає контактна форма надсилання без захисту, чи діють на боці сервера CAPTCHA, пастка (honeypot), токен, валідація адреси електронної пошти й обмеження частоти та чи можна впровадити заголовки.
Передумова	Для Клієнтів — лише домени з наданим підтвердженням контролю (запис DNS, метатег, файл або з’єднаний плагін); додатково оператор використовує внутрішній інструмент командного рядка для створення перевірок із рівнем «verified» для наших власних тестових і демонстраційних доменів. Лише з увімкненим глобальним перемикачем, лише для форми, надійно класифікованої як загальна контактна форма. Ніколи не для замовлень, бронювань, реєстрацій, розсилок, платежів, завантажень файлів, обов’язкових полів із реальними персональними даними або доменів органів влади, медичних чи освітніх закладів.
Категорії суб’єктів даних	Працівники Клієнта, які отримують листи з форм.
Категорії персональних даних	Тестове надсилання не містить персональних даних: відправник «FormExposed Security Scanner», наша власна адреса відправника або адреса в .invalid, позначена тема й текст мовою сторінки з посиланням на сторінку сканера та відмову від перевірок і номером перевірки. Ми зберігаємо: відповідь сторінки, результати перевірки, зображення наступної сторінки (як у A.4).
Обсяг	Щонайбільше п’ять надсилань за перевірку (налаштування, типово 5); повторно з частотою перевірок тарифу, щодня в найвищому тарифі.
Джерело	Вказівка Клієнта.
Правова підстава	Виконання договору з Клієнтом (ст. 6(1)(b) GDPR); надсилання надходять до власної форми Клієнта. Для одержувачів на боці Клієнта: організація діяльності Клієнта.
Одержувачі	Клієнт (його лист із форми).
Третя країна	Не через нас.
Зберігання	Результати як у A.4.
Технічні та організаційні заходи	Розділ 8. Ін’єкція заголовків лише виявляється, ніколи не виконується зі справжнім одержувачем; валідація адреси електронної пошти використовує лише домен, який не може існувати.

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

Поле	Запис
Мета	Статистика захисту контактних форм у країні чи галузі. Публікуються лише сукупні показники, без назв сайтів; сегменти — лише від 20 сторінок із формою.
Категорії суб’єктів даних	Оператори сайтів у переліку; випадково видимі особи.
Категорії персональних даних	Як у B.5, лише пасивно. Додатково перелік: хост, сегмент, стан, завдання (study_domains); дослідження із заголовком, країною, сукупними результатами (studies).
Джерело	Перелік публічних сайтів, складений оператором; самі сторінки.
Правова підстава	Ст. 6(1)(f) GDPR. Інтерес: статистичні твердження про стан безпеки форм. Зважування: пасивно, з обмеженням частоти (мало завдань за запуск), список блокування й відмови від перевірок діють, публікація лише сукупних показників, сирі дані видаляються.
Одержувачі	Публіка, лише сукупні показники.
Третя країна	Немає.
Зберігання	Сирі дані (результати перевірок, форми, окремі результати виявлення, зображення, завдання) видаляються під час публікації (fe_studie_veroeffentlichen()). Перелік хостів із сегментом залишається після цього; для нього й досліджень, які ніколи не публікуються, строку зберігання немає (розділ 10). Оператор вирішує, які переліки перевіряти й чи публікувати дослідження.
Технічні та організаційні заходи	Розділ 8.

B.8 Перевірка потенційного клієнта (режим залучення клієнтів для агентств)

Поле	Запис
Мета	Агентство (тариф Business) пасивно перевіряє сайт потенційного клієнта й отримує короткий звіт під своїм брендом та пасивний звіт. Ми ні до кого не звертаємося; агентство самостійно передає посилання.
Категорії суб’єктів даних	Оператор перевіреного сайту; випадково видимі особи; працівники агентства, які запускають перевірку.
Категорії персональних даних	Як у B.5, лише пасивно. Додатково: робочий простір, особа, яка запускає перевірку, хост, випадковий ідентифікатор звіту, час (prospect_checks).
Джерело	Введення агентства; публічні сторінки.
Правова підстава	Ст. 6(1)(f) GDPR (наш інтерес у наданні сервісу й інтерес агентства в обґрунтованому зверненні). Ролі агентства й нас та обов’язки агентства під час передавання звіту — відкриті питання юридичної перевірки: якщо агентство без запиту надсилає звіт електронною поштою або телефонує, це прямий маркетинг, який потребує згоди за ст. 398 PKE і § 7(2) UWG (німецького Закону проти недобросовісної конкуренції), навіть між підприємствами. Це відповідальність агентства; Умови надання послуг відповідно зобов’язують його.
Одержувачі	Агентство та кожен, кому воно надає посилання.
Третя країна	Немає.
Зберігання	Строк дії звіту й результату перевірки спливає через 90 днів, після чого їх видаляє нічний запуск (fe_reports_aufraeumen()); запис перевірки видаляється через 90 днів у щоденному запуску колективного захисту з 04:00 (srv/cron_status.php). Разом із робочим простором — негайно.
Технічні та організаційні заходи	Розділ 8. Щомісячна квота (налаштування, типово 30); та сама сторінка протягом семи днів повертає той самий звіт; відмова від перевірок діє.

B.9 Інструмент заголовків без облікового запису

Поле	Запис
Мета	Безкоштовна оцінка (від A+ до F) захисних заголовків головної сторінки домену. Два запити, без браузера, без форми, без надсилання.
Категорії суб’єктів даних	Особи, які використовують інструмент; оператори перевіреного домену.
Категорії персональних даних	Журнал запитів як у B.4 (джерело «headers», IP-адреса, хеш сеансу, хост). Результат: хост, оцінка, бали, оцінені заголовки (header_checks).
Правова підстава	Ст. 6(1)(f) GDPR, як у B.4 і B.5.
Одержувачі	Google (reCAPTCHA, B.23).
Третя країна	США через reCAPTCHA.
Зберігання	Журнал запитів — 7 днів; результати — наразі через 90 днів (нічний запуск видалення, частина «header_checks», налаштування «headers_keep_days»). Для доменів в обліковому записі оцінка визначається заново щодня й зберігається з доменом.
Технічні та організаційні заходи	Розділ 8. Ліміти за IP-адресою й днем; відмова від перевірок діє.

B.10 Облікові записи клієнтів

Поле	Запис
Мета	Обслуговування облікових записів клієнтів, робочих просторів і тарифів.
Категорії суб’єктів даних	Клієнти (підприємства) і члени їхніх команд із власним обліковим записом.
Категорії персональних даних	Адреса електронної пошти та нормалізована форма, пароль лише як хеш, ім’я (обов’язково), прізвище й компанія (якщо надано); застосунок не зберігає адреси й номера платника ПДВ, їх надають лише в Stripe (B.26); стан, мова, режим відображення, валюта, тариф і стан оплати, ID клієнта й підписки Stripe, кінець розрахункового періоду, скасування наприкінці періоду, ідентифікатори підтвердження й скидання зі строком дії, нова адреса електронної пошти до підтвердження, час реєстрації, останній вхід і остання IP-адреса, час відкликання всіх сеансів, дані двофакторного входу (B.11), щомісячний звіт увімкнено/вимкнено, час листа-нагадування, відкриття тарифів кодами, реферальний код і рекомендація (users). Робочі простори з назвою, часом, станом (workspaces); участь із роллю й датою приєднання (workspace_users).
Джерело	Реєстрація й налаштування особою; стан оплати зі Stripe.
Правова підстава	Ст. 6(1)(b) GDPR (договір). Остання IP-адреса: (f) (безпека облікового запису).
Одержувачі	Stripe (B.26); постачальник поштових послуг для листів облікового запису (B.25). Учасники того самого робочого простору бачать ім’я, адресу електронної пошти й роль інших учасників.
Третя країна	Через Stripe і постачальника поштових послуг.
Зберігання	До видалення власником облікового запису. Під час видалення його власні робочі простори, якими більше ніхто не користується, видаляються з усіма доменами та їхніми даними; робочі простори з іншими учасниками переходять до іншого учасника — насамперед до адміністраторів, а серед них до того, хто належить до простору найдовше. Участь, токени збереження входу, пристрої, ключі API, відкриті коди Telegram, відгуки про звіти (B.35) і рядок облікового запису видаляються; чинна платна підписка спочатку негайно завершується в Stripe без повернення коштів (www/ajax.php, fe_konto_reste_loeschen()). Натомість скасування в розділі оплати набирає чинності наприкінці періоду; після цього обліковий запис продовжує працювати на безкоштовному тарифі. Що залишається, визначено в розділі 6.4. Облікові записи, які ніколи не підтверджувалися й до яких ніколи не входили, видаляються через 30 днів, якщо до їхнього робочого простору не приєднано іншого учасника (нічний запуск видалення, частина «pending_accounts»). Неактивні облікові записи не видаляються. Якщо договір щодо облікового запису завершується іншим способом, наприклад через наше припинення, ми видаляємо обліковий запис не пізніше ніж через 30 днів після завершення договору; наразі це робиться вручну (зобов’язання за Договором про обробку даних).
Технічні та організаційні заходи	Розділ 8.

B.11 Вхід, пристрої, другий фактор і журнал дій

Поле	Запис
Мета	Захист облікових записів: обмеження спроб входу й інших спроб пароля, показ і відкликання пристроїв з активним входом, двофакторний вхід, простежуваність змін.
Категорії суб’єктів даних	Власники облікових записів і учасники команд; особи, які намагаються ввійти, зареєструватися або ввести пароль клієнтського порталу.
Категорії персональних даних	Спроби входу: IP-адреса, введена адреса електронної пошти, успіх, час (login_attempts). Пристрої: хеш ідентифікатора сеансу (ніколи сам ідентифікатор), зв’язок із токеном збереження входу, IP-адреса, ідентифікатор браузера та визначені за ним браузер, операційна система й тип пристрою, час входу, останньої активності й відкликання, а для «Перегляду як клієнт» — ідентифікатор особи підтримки (login_sessions). Токени збереження входу для «Залишатися в системі»: селектор, перевірна частина, строк дії (remember_tokens). Двофакторний вхід: секрет зашифровано, час активації, останній використаний часовий крок, коди відновлення лише як хеші (у users). Журнал дій: обліковий запис, робочий простір, дія, ціль, подробиці, IP-адреса, країна, час (audit_logs). Лічильники спроб входу, другого фактора, підтвердження пароля, скидання пароля, реєстрації й паролів клієнтських порталів: ключ HMAC, виведений із мети й ID облікового запису (для невідомої адреси або скидання — адреси електронної пошти в нижньому регістрі), IP-адреси, облікового запису й IP-адреси разом або ID порталу (також разом з IP-адресою), кількість спроб, строк дії; адреси електронної пошти й IP-адреси не зберігаються там у відкритому вигляді (таблиця auth_attempt_buckets).
Правова підстава	Ст. 6(1)(b) GDPR у поєднанні зі ст. 32 (список пристроїв, другий фактор) і (f) (спроби входу, журнал дій). Інтерес: захист облікових записів від захоплення, документування змін (ст. 5(2)). Зважування: скорочена адреса не відповідає на запитання «чи це був я?»; журнал дій повинен пережити спір, який виникне лише через місяці.
Одержувачі	Немає. Власник облікового запису бачить свої пристрої й отримує спроби входу, пристрої та дії в експорті даних; під час сеансу «Перегляд як клієнт» там не відображається ані IP-адреса, ані браузер особи підтримки.
Третя країна	Немає.
Зберігання	Спроби входу — 7 днів; після успішного входу невдалі спроби з тієї самої адреси видаляються негайно. Лічильники спроб — до кінця свого часового вікна (наразі 15 хвилин, одна година для скидання пароля й реєстрації); прострочені видаляються під час наступного доступу й нічним запуском. Пристрої — через 90 днів після останнього використання або відкликання (нічний запуск видалення, частина «sessions»), негайно разом з обліковим записом. Токени збереження входу припиняють діяти через 30 днів. Журнал дій — 365 днів (щоночі); коли обліковий запис видаляється, його записи залишаються до кінця строку зберігання (розділ 6.4).
Технічні та організаційні заходи	Розділ 8.

B.12 Підтвердження укладення договору

Поле	Запис
Мета	Доведення того, яку версію Умов надання послуг, Договору про обробку даних і Політики конфіденційності Клієнт прийняв або з якою ознайомився під час реєстрації, а також того, що Клієнт використовує сервіс для своєї підприємницької діяльності.
Категорії суб’єктів даних	Клієнти.
Категорії персональних даних	Для кожного документа: обліковий запис, документ, версія (хеш відображеного тексту), привід, IP-адреса, ідентифікатор браузера, час (legal_consents). Сама відображена версія з повним текстом, мовою, заголовком і адресою, один раз для кожної версії (legal_versions; не містить персональних даних).
Правова підстава	Ст. 6(1)(b) і (f) GDPR (підтвердження укладення договору, захист від вимог).
Одержувачі	Немає. Власник облікового запису отримує свої записи в експорті даних.
Третя країна	Немає.
Зберігання	Доки існує обліковий запис; після видалення облікового запису — чотири роки від згоди, потім видаляються щоночі (srv/cron_status.php). Обґрунтування в коді: трирічний строк позовної давності від кінця року, округлений угору. Чи передбачає польське право інший строк — частина юридичної перевірки.
Технічні та організаційні заходи	Розділ 8. Якщо бракує будь-якого з трьох документів, реєстрацію закрито.

B.13 Запрошення до команди

Поле	Запис
Мета	Запрошення інших осіб до робочого простору.
Категорії суб’єктів даних	Запрошені особи.
Категорії персональних даних	Адреса електронної пошти, роль, ідентифікатор запрошення, особа, яка запрошує, строк дії, час прийняття (workspace_invites); лист-запрошення у вихідній пошті (B.25).
Джерело	Вводиться учасником, який запрошує.
Правова підстава	Ст. 6(1)(b) GDPR щодо Клієнта; щодо запрошеної особи — (f) (інтерес Клієнта в залученні своєї команди).
Одержувачі	Постачальник поштових послуг (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Третя країна	Через постачальника поштових послуг.
Зберігання	Запрошення чинне 14 днів і лише доки особа, яка запрошує, є власником чи адміністратором робочого простору. Неприйняті запрошення — після спливу строку дії, прийняті — через 30 днів після прийняття (щоночі, srv/cron_status.php і частина «invites» у cfg/fristen_lib.php). Разом із робочим простором — негайно.
Технічні та організаційні заходи	Розділ 8.

B.14 «Перегляд як клієнт» службою підтримки

Поле	Запис
Мета	Суперадміністратор бачить застосунок так, як його бачить Клієнт, щоб вирішити питання підтримки («у мене немає кнопки»).
Категорії суб’єктів даних	Відповідний Клієнт; суперадміністратор.
Категорії персональних даних	Усе, що Клієнт бачить у застосунку. Записується до журналу: окремий рядок пристрою з ідентифікатором суперадміністратора (login_sessions), початок і кінець у журналі дій (audit_logs).
Правова підстава	Ст. 6(1)(b) GDPR (підтримка як частина послуги), альтернативно — (f).
Обмеження	Щонайбільше одна година, потім повний вихід. Завершення перегляду також повністю завершує сеанс суперадміністратора, включно із сеансом, із якого він прийшов; повернутися до адміністративної області він може лише повторним входом із паролем і другим фактором. Негайно завершується, якщо роль суперадміністратора понижено або його заблоковано. Усе, що змінює обліковий запис Клієнта, блокується: пароль, адреса електронної пошти, другий фактор, пристрої, підписка, експорт, видалення, передавання. Адміністративна область під час сеансу закрита. Клієнт бачить доступ у списку своїх пристроїв і в експорті даних як доступ підтримки.
Одержувачі	Немає.
Третя країна	Немає.
Зберігання	Рядок пристрою — 90 днів, журнал дій — 365 днів.
Технічні та організаційні заходи	Розділ 8.

B.15 Домени, підтвердження контролю й моніторинг

Поле	Запис
Мета	Основна послуга для Клієнтів: зберігання доменів в обліковому записі, надання підтвердження контролю, регулярні перевірки й виявлення змін. Це охоплює пульс форми (легкий запит без браузера кожні 10–30 хвилин залежно від тарифу), щоденний нагляд за поштовими DNS і сертифікатом, дату закінчення строку домену, списки блокування, відкриті для доступу файли, видимі ззовні версії, перелік скриптів, візуальні зміни форми, відмови постачальників CAPTCHA й пошти та нагляд за вразливостями плагінів форм.
Категорії суб’єктів даних	Клієнти й члени їхніх команд; оператори доменів, якщо вони є фізичними особами.
Категорії персональних даних	Домен із хостом, публічним ідентифікатором, приміткою, позначкою клієнта, типом та ідентифікатором підтвердження, частотою перевірок, увімкненням/вимкненням моніторингу, вікнами обслуговування, цінністю звернення, ідентифікаторами значка, перевірки доставки й хука розгортання, ключем плагіна, станами й найновішими результатами нагляду (DNS, сертифікат, автентичність листа з форми, списки блокування, відкриті файли, заголовки, версії) (domains). Пульс за сторінкою форми (form_pulse). Вразливості з версій плагінів (vuln_hits). Перелік скриптів з адресою, хешем, розміром, схваленням з особою, яка схвалила, і причиною (script_inventory, script_changes). Перевірки як у A.4. Для відкритих файлів зберігаються шлях, серйозність і тип, ніколи не вміст.
Запити до третіх осіб	Запити DNS (SPF, DMARC, MX, запис підтвердження). Запит до реєстру через RDAP за каталогом IANA: лише доменне ім’я. DNS-списки блокування (SpamCop, PSBL, Mailspike, SURBL; Spamhaus лише зі збереженими обліковими даними доступу, наразі ні): IP-адреси вебсервера й поштового сервера та доменне ім’я, без даних відвідувачів. Google Web Risk лише якщо налаштовано (наразі ні): адреса головної сторінки. Служба позначок часу: лише хеш-значення (B.19). WPVulnerability: лише ідентифікатор плагіна чи теми або версія WordPress; порівняння зі встановленою версією плагіна ми виконуємо самостійно. Сторінки стану Cloudflare, hCaptcha, Google Cloud, SendGrid, Mailgun і Brevo: нічого не передається, крім самого запиту.
Джерело	Клієнт; запити до сторінки Клієнта; публічні каталоги.
Правова підстава	Ст. 6(1)(b) GDPR.
Одержувачі	Названі сервіси не отримують персональних даних наших Клієнтів тією мірою, якою доменні імена й адреси серверів підприємства не є персональними даними; для фізичних осіб — підприємців доменне ім’я може бути персональними даними. Учасники робочого простору бачать домен.
Третя країна	Запити можуть надходити до сервісів у третіх країнах (як-от запити до реєстрів, списки блокування). Передається лише зазначене в рядку «Запити до третіх осіб».
Зберігання	До видалення домену. Тоді fe_domain_loeschen() негайно видаляє результати перевірок, форми, окремі результати виявлення, зображення, звіти, завдання, адресатів сповіщень і журнал сповіщень, інциденти, коди Telegram, доставки, пульс, вразливості й підтвердження; через зовнішні ключі — форми на моніторингу, браузерні запуски, тестовий обліковий запис і лічильники форм; дані плагіна хоста, якщо інший домен не посилається на нього. Також видаляються перелік скриптів домену й зміни скриптів; власного строку зберігання вони не мають (розділ 6.4). Результати перевірок — щонайбільше 13 місяців, останній залишається.
Технічні та організаційні заходи	Розділ 8. Нагляд за відкритими файлами й версіями лише для підтверджених доменів, щонайбільше один запит на шлях, лише перші 8 KB; зондування сторонніх шляхів без запиту було б інструментом атаки.

B.16 Сповіщення, інциденти й ескалація для власника облікового запису

Поле	Запис
Мета	Інформування Клієнта про несправності й зміни, дотримання вікон обслуговування, підтвердження отримання й ескалація інцидентів. Якщо адресатами є треті особи, ми діємо від імені Клієнта (A.3); якщо це сам власник облікового запису, це визначено тут.
Категорії суб’єктів даних	Власники облікових записів і учасники команд як одержувачі.
Категорії персональних даних	Як у A.3. Повідомлення відображаються мовою власника облікового запису.
Правова підстава	Ст. 6(1)(b) GDPR.
Одержувачі	Постачальник поштових послуг; вибрані чат-сервіси (4.1).
Третя країна	Залежно від каналу (4.1).
Зберігання	Як у A.3: журнал доставки — 90 днів, повідомлення зведень — 30 днів після доставки, інциденти — до вирішення й потім 180 днів. Адресати сповіщень — разом із доменом.
Технічні та організаційні заходи	Розділ 8.

B.17 Щомісячний звіт для облікових записів

Поле	Запис
Мета	1-го числа кожного місяця з 08:00 (надолуження до 3-го) — один лист на обліковий запис про всі його домени: рівень, оцінка й зміна, сповіщення, заблоковані боти, надсилання пошти, порівняльний показник.
Категорії суб’єктів даних	Активні власники облікових записів з увімкненим щомісячним звітом.
Категорії персональних даних	Адреса електронної пошти, мова, ключові показники доменів.
Правова підстава	Ст. 6(1)(b) GDPR (частина послуги). Можна відписатися в налаштуваннях; можна вимкнути централізовано.
Одержувачі	Постачальник поштових послуг (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Третя країна	Через постачальника поштових послуг.
Зберігання	Без окремого зберігання; лист залишається у вихідній пошті 30 днів (B.25).
Технічні та організаційні заходи	Розділ 8.

B.18 Значок і публічна сторінка підтвердження

Поле	Запис
Мета	Клієнт може вбудувати на свій сайт зображення значка й пов’язати його з публічною сторінкою підтвердження. Значок показує «Захищено» лише якщо домен підтверджений, моніторинг працює, а остання завершена перевірка відбулася щонайбільше 45 днів тому й дала результат «Захищено» або «Частково захищено»; інакше він нейтрально показує «Перевірка контактної форми». Сторінка підтвердження зазначає рівень і дату, без окремих результатів перевірки.
Категорії суб’єктів даних	Відвідувачі сайту Клієнта, браузер яких завантажує зображення; відвідувачі сторінки підтвердження.
Категорії персональних даних	Під час завантаження зображення: IP-адреса, час, запитана адреса, сторінка переходу й ідентифікатор браузера в журналі вебсервера (B.1). Адреса зображення не починає сеансу, не встановлює cookie й не записує до журналу переглядів сторінок. Сторінка підтвердження є звичайною сторінкою (B.2, B.3).
Правова підстава	Ст. 6(1)(f) GDPR. Інтерес: доставка зображення й безпечна робота. Чи є Клієнт і ми спільними контролерами передавання IP-адреси відвідувача в розумінні судової практики щодо вбудованого стороннього вмісту й чи потрібна домовленість за ст. 26 — відкрите питання юридичної перевірки. Клієнт отримує запропонований текст для своєї політики конфіденційності.
Одержувачі	Немає.
Третя країна	Немає.
Зберігання	14 днів (журнал вебсервера). Зображення кешується на одну годину. Коли значок вимкнено, ідентифікатор перестає бути чинним.
Технічні та організаційні заходи	Розділ 8.

B.19 Журнал доказів і позначка часу

Поле	Запис
Мета	Один журнал на домен і місяць (платні тарифи): що перевіряли, з яким результатом, про що повідомляли й що змінилося, як доказ для підзвітності, страховиків чи аудитів постачальників. Кожна версія отримує контрольний номер; публічна сторінка підтверджує домен, період і ключові показники, без подробиць. Із 7 жовтня 2026 року час підтверджує служба позначок часу за RFC 3161.
Категорії суб’єктів даних	Клієнти; опосередковано — особи, які можуть бути названі в журналі як ті, хто схвалив або підтвердив отримання.
Категорії персональних даних	Домен, місяць, контрольний номер, хеш вмісту (SHA-512), зведення й дані журналу, відповідь служби позначок часу, служба позначок часу й час, невдалі спроби (proof_docs).
Правова підстава	Ст. 6(1)(b) GDPR.
Одержувачі	Служба позначок часу (типово Certum, резервно DigiCert) отримує лише хеш журналу, а не його вміст. Публічно: ключові показники через сторінку підтвердження. Клієнт і кожен, кому Клієнт надає журнал або контрольний номер.
Третя країна	Передавання персональних даних немає: хеш не дозволяє робити висновків про вміст. Резервна служба розташована у США.
Зберігання	До видалення домену (fe_domain_loeschen()). Позначка часу не є кваліфікованою позначкою часу за eIDAS.
Технічні та організаційні заходи	Розділ 8.

B.20 Плагін і розширення: перевірка, з’єднання й передавання

Поле	Запис
Мета	Плагін WordPress і розширення TYPO3 можуть запитувати перевірку (навіть без облікового запису), з’єднуватися з обліковим записом (установлення вважається підтвердженням контролю одним натисканням в обліковому записі), відкривати функції захисту, щодня повідомляти показники (A.9) та негайно повідомляти про помилки пошти й режим обслуговування.
Категорії суб’єктів даних	Клієнти; оператори сайтів, які використовують плагін без облікового запису.
Категорії персональних даних	Для кожного хоста: версії плагіна й CMS, кількість перевірок, ідентифікатор останнього звіту, хеш секрету з’єднання, перший і останній контакт (plugin_sites). Одноразові коди з’єднання як хеш зі строком дії (plugin_connect_tokens). Коди розгортання агентства як хеш із префіксом, позначкою, використаннями, особою, яка створила (workspace_connect_codes). Журнал запитів з IP-адресою сервера, що викликає (B.4). Ключ плагіна публічно видимий у head сайту; це хеш секрету, а сам секрет зберігається лише як хеш і ніколи не повертається.
Правова підстава	Ст. 6(1)(b) GDPR (обліковий запис); без облікового запису — (f) (запитана перевірка, запобігання зловживанням).
Одержувачі	Немає.
Третя країна	Немає.
Зберігання	Дані хоста видаляються, щойно жоден домен більше не посилається на нього; рядок плагіна без облікового запису — лише після 90 днів без контакту (нічний запуск видалення, частина «orphan_hosts»). Одноразові коди — через один день після спливу строку дії. Коди розгортання — разом із робочим простором.
Технічні та організаційні заходи	Розділ 8. Із 27 вересня 2026 року сервер приймає лише пари ключів, прив’язані до сайту; старіші неприв’язані секрети з’єднання було видалено.

B.21 Колективний захист

Поле	Запис
Мета	Спільний захист від спаму: з’єднані сайти повідомляють домени посилань у повідомленнях, які зупинив їхній рівень захисту. Домен, який з’являється щонайменше на трьох сайтах із щонайменше п’ятьма спрацюваннями протягом семи днів, потрапляє до списку, що повертається всім з’єднаним сайтам; їхній рівень захисту переносить повідомлення з такими посиланнями до карантину, ніколи не знищує безслідно.
Категорії суб’єктів даних	Власники повідомлених доменів посилань, якщо вони є фізичними особами (наприклад, оператор спам-сайту під власним ім’ям). Не відправники й одержувачі повідомлень: адреси, тексти й імена не повідомляються.
Категорії персональних даних	Сигнали: тип, домен, хост, що повідомив, день, спрацювання (swarm_signals). Список: тип, домен, кількість сайтів і спрацювань, час (swarm_list). Великі сервіси, домени наших Клієнтів і винятки, встановлені оператором, ніколи не потрапляють до списку.
IP-мережі	Поширення IP-мереж (/24, /48) підготовлено. Воно вимкнене, і плагін їх не повідомляє; його ввімкнуть лише після юридичної перевірки, оскільки IP-адреси є персональними даними.
Правова підстава	Ст. 6(1)(f) GDPR. Інтерес: захист форм усіх Клієнтів від хвиль спаму. Зважування: лише домени, мінімальні пороги проти навмисного спотворення списку, без втрати повідомлень, видалення можливе будь-коли.
Одержувачі	Усі з’єднані сайти (список доменів).
Третя країна	Залежно від місця з’єднаних сайтів; список може також надходити до сайтів поза ЄЕП. Він є персональними даними лише в граничних випадках (домени фізичних осіб). Підставу передавання за Главою V GDPR для цих випадків ще належить визначити (відкрите питання юридичної перевірки).
Зберігання	Сигнали — 30 днів (щоденний запуск колективного захисту з 04:00, cfg/swarm_lib.php). Список перераховується щодня; те, що більше не досягає порогу, випадає з нього.
Технічні та організаційні заходи	Розділ 8.

B.22 Ключі API, програмний інтерфейс і сервер MCP

Поле	Запис
Мета	Доступ власних інструментів Клієнта (REST API, Zapier, Make, сервер MCP для ШІ-асистентів) до його доменів, перевірок та інцидентів.
Категорії суб’єктів даних	Клієнти, які створюють ключі.
Категорії персональних даних	Ключ лише як хеш, префікс, позначка, час створення, останнього використання й відкликання (api_keys). Виклики за хвилину (api_usage).
Правова підстава	Ст. 6(1)(b) GDPR.
Одержувачі	Інструмент, якому Клієнт надає ключ; його визначає Клієнт.
Третя країна	Залежно від інструмента Клієнта.
Зберігання	Ключі — до відкликання, негайно разом з обліковим записом; ключі без облікового запису (старі дані) — щоночі. Лічильники викликів — через один день (періодично очищаються під час виклику).
Технічні та організаційні заходи	Розділ 8.

B.23 reCAPTCHA й наш власний захист форм

Поле	Запис
Мета	Захист від автоматизованого доступу до наших власних форм: безкоштовна перевірка, інструмент заголовків, відмова від перевірок, вхід, реєстрація, забутий пароль і його скидання, підтримка й контакт. Додатково наш власний захист без третіх осіб: пастка (приховане поле), підписана перевірка часу й токен CSRF. З 29 жовтня 2026 року додатково наш захист форм formconfirmed (доказ виконання обчислювальної роботи й одноразовий перевірочний токен) для безкоштовної перевірки, реєстрації, входу та «Забули пароль».
Категорії суб’єктів даних	Особи, які надсилають ці форми.
Категорії персональних даних	У Google: IP-адреса, дані браузера й пристрою, поведінкові дані, cookie Google. У нас: оцінка Google (бал і дія) лише в момент перевірки, без збереження, навіть коли надсилання відхиляється. У власному захисті форм: IP-адреса (зберігається лише скороченою та гешованою), сторінка, моменти часу, чи заповнено поле-пастку (так/ні); жодного вмісту.
Час	Скрипт Google завантажується лише під час надсилання захищеної форми, а не відкриття сторінки. Власний захист форм отримує своє завдання під час відкриття сторінки й виконує обчислення, щойно форму починають використовувати. У системі розроблення reCAPTCHA вимкнена.
Правова підстава	Ст. 6(1)(f) GDPR. Інтерес: захист від ботів, особливо для безкоштовної перевірки, яку інакше можна було б використовувати проти сторонніх сайтів. Чи потребує доступ до кінцевого пристрою згоди за § 25 TDDDG або ст. 399 PKE, хоча скрипт завантажується лише під час надсилання, — відкрите питання юридичної перевірки. Власний захист форм не встановлює cookie, нічого не зберігає в браузері й не створює цифрового відбитка; він має з часом повністю замінити reCAPTCHA.
Одержувачі	Google Ireland Limited; Google LLC. Для власного захисту форм — немає.
Третя країна	США (лише reCAPTCHA). Підстава: сертифікація за EU-US Data Privacy Framework або стандартні договірні положення; ще потрібно докладно задокументувати.
Зберігання	reCAPTCHA: у нас не зберігається; у Google — за його правилами. Власний захист форм: гешований ідентифікатор — 1 година, використані перевірочні токени — щонайбільше 11 хвилин, результати перевірки без IP-адреси — 30 днів.
Відмова	Якщо Google не відповідає протягом трьох секунд або надає непридатну відповідь, надсилання відхиляється; так само порожній токен і відповідь для дії, відмінної від дії форми. Перевірка пропускається лише якщо reCAPTCHA вимкнена. У власному захисті форм надсилання без дійсного перевірочного токена відхиляється; якщо сервіс був недоступний для отримання завдання, його допускають.
Технічні та організаційні заходи	Розділ 8.

B.24 Підтримка й контактна форма

Поле	Запис
Мета	Отримання звернень і відповіді на них через вікно підтримки та сторінку контактів. Обидва способи використовують той самий шлях і ту саму таблицю.
Категорії суб’єктів даних	Особи, які звертаються, із входом або без нього.
Категорії персональних даних	Обліковий запис (якщо виконано вхід; тоді діє адреса облікового запису, а не введена), адреса електронної пошти, причина з фіксованого переліку, текст до 4 000 символів, стан, повна IP-адреса, країна, ідентифікатор браузера, сторінка переходу (лише власні шляхи), мова, час отримання й відповіді (support_requests); запис у журналі дій (без тексту); підтвердження отримання заявнику у вихідній пошті (B.25), із текстом до 2 000 символів лише для відправників, які увійшли, без тексту для запитів без входу.
Правова підстава	Ст. 6(1)(b) GDPR, якщо звернення стосується договору; інакше — (f). Повна IP-адреса: (f) (ліміт трьох звернень за годину й адресу, запобігання зловживанням).
Одержувачі	Постачальник поштових послуг (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) для підтвердження й відповіді. Telegram отримує фіксований сигнал без жодних змінних («є нове звернення до підтримки»), а отже без персональних даних.
Третя країна	Через постачальника поштових послуг.
Зберігання	24 місяців (нічний запуск видалення, частина «support»); вручну — раніше. Коли обліковий запис видаляється, звернення залишаються до кінця строку зберігання (розділ 6.4).
Технічні та організаційні заходи	Розділ 8. reCAPTCHA, наш власний захист форм, обмеження частоти.

B.25 Надсилання електронної пошти (вихідна пошта)

Поле	Запис
Мета	Транзакційні листи: підтвердження реєстрації й нових адрес електронної пошти, скидання пароля, запрошення, сповіщення, щомісячні звіти, підтвердження й звіти порталу, підтвердження отримання звернень до підтримки й відповіді, нагадування про пробний період і налаштування, експлуатаційні повідомлення операторам. Без реклами, без листів особам, які самостійно не підписалися або не були зазначені Клієнтом як одержувачі.
Категорії суб’єктів даних	Одержувачі цих листів.
Категорії персональних даних	Адреса одержувача, тема, повний вміст, адреса для відповіді, мета, шлях надсилання, стан, помилка, спроби, час (mail_outbox). Вміст може включати посилання підтвердження й скидання з чинними ідентифікаторами.
Правова підстава	Ст. 6(1)(b) GDPR; для експлуатаційних повідомлень — (f).
Одержувачі	Namecheap, Inc. (Private Email), Phoenix, Arizona, USA (надсилання); власник облікового запису бачить свої надіслані листи в експорті даних (без вмісту).
Третя країна	Залежно від місця обробки постачальника поштових послуг; договір і підставу передавання ще потрібно задокументувати (розділ 4).
Зберігання	30 днів (щоночі, srv/cron_status.php). Цей строк навмисно найкоротший серед журналів: тривалий журнал надсилання був би зібранням чинних ключів. Запуск перевірки стану кожні п’ять хвилин перевіряє, чи настав час повторної спроби.
Стан	Надсилання пошти потрібно налаштувати перед запуском. Доки постачальника поштових послуг із його місцезнаходженням і підставою не визначено, правові тексти показують маркер.
Технічні та організаційні заходи	Розділ 8. Невдалі листи надсилаються повторно зі збільшенням інтервалів, а після максимальної кількості спроб подальші спроби припиняються.

B.26 Платежі й оплата

Поле	Запис
Мета	Укладення й керування підписками (щомісячно або щорічно наперед), 14-денний пробний період без картки з нагадуванням за три дні до завершення, оплата за рахунком для річних підписок (типово вимкнено), відкриття тарифів кодами хостинг-провайдерів і партнерів без оплати, виставлення рахунків, зберігання для податкових цілей.
Категорії суб’єктів даних	Клієнти.
Категорії персональних даних	У Stripe: адреса електронної пошти, ім’я, платіжна адреса, номер платника ПДВ, платіжні дані, рахунки; як метадані — наш ID облікового запису й тариф. У нас: ID клієнта й підписки Stripe, тариф, стан, кінець періоду, скасування наприкінці періоду (users); отримані події Stripe лише з ідентифікатором, типом, станом і часом, без вмісту (stripe_events); використання кодів хостинг-провайдерів з обліковим записом, кампанією й строком дії (bundle_redemptions). Дані карток ніколи не надходять до нас.
Джерело	Клієнт під час оформлення в Stripe; події зі Stripe.
Правова підстава	Ст. 6(1)(b) GDPR; для зберігання для податкових цілей — (c).
Одержувачі	Stripe Payments Europe Limited (Ireland); Stripe, Inc. (USA). Для частин обробки платежів Stripe діє під власну відповідальність; точний розподіл ролей є частиною юридичної перевірки.
Третя країна	США через Stripe, Inc.; підстава: Data Privacy Framework або стандартні договірні положення за умовами Stripe.
Зберігання	Платіжні поля — разом з обліковим записом; чинна підписка завершується перед видаленням облікового запису. Рахунки й платіжні документи за польським податковим правом — п’ять років від кінця року, у якому сплив строк сплати податку; вони зберігаються в Stripe й доступні в клієнтському порталі Stripe. Події Stripe й використання кодів не мають строку зберігання (розділ 6.4).
Технічні та організаційні заходи	Розділ 8. Події Stripe приймаються лише з чинним підписом; кожна подія обробляється один раз.

B.27 Резервні копії

Поле	Запис
Мета	Відновлення після помилки: помилкове видалення, пошкоджена міграція.
Категорії суб’єктів даних	Кожен, чиї дані є в базі даних.
Категорії персональних даних	Повний стиснений дамп бази даних застосунку. Знімки екрана й файли логотипів зберігаються поза базою даних і не є частиною цієї резервної копії. Облікові дані тестових облікових записів містяться в ній лише як шифротекст (A.5).
Процедура	Щоночі о 03:00, після запуску видалення, щоб резервна копія не забирала те, що щойно видалено за строками зберігання. Дамп зберігається лише після перевірки вмісту (код завершення, кількість таблиць, завершальний рядок). Щонеділі тест відновлення завантажує найновішу резервну копію до тимчасової бази даних і порівнює її таблиця за таблицею. Якщо щось не вдається, операторам надсилаються сигнал і лист.
Правова підстава	Ст. 6(1)(f) GDPR у поєднанні зі ст. 32(1)(c).
Одержувачі	Немає.
Третя країна	Немає.
Зберігання	14 днів; старіші дампи видаляються лише після успішного створення нової резервної копії (cfg/backup_lib.php). Видалення, які відбуваються протягом цього часу, доходять до резервної копії лише зі спливом строку її зберігання; якщо дані відновлено з резервної копії, після цього повторно застосовуються запити на видалення.
Місце	Резервні копії наразі зберігаються в тому самому місці, що й база даних, і окремо не шифруються; зашифрована копія в другій локації запланована (розділи 8.1 і 10).
Технічні та організаційні заходи	Розділ 8.

B.28 Журнал помилок і сповіщення про помилки

Поле	Запис
Мета	Виявлення й усунення помилок до того, як про них повідомить Клієнт. Нові типи помилок і хвилі помилок повідомляються операторам, додатково щоденний огляд із 08:00.
Категорії суб’єктів даних	Користувачі, чий запит спричиняє помилку; опосередковано — особи, чиї дані з’являються в повідомленні про помилку.
Категорії персональних даних	Рівень, джерело, повідомлення, контекст як JSON, ID облікового запису сеансу, час (error_logs). Типи помилок: відбиток, шаблон (із якого видалено адреси електронної пошти, адреси, числа й ідентифікатори), одне незмінене повідомлення-зразок до 2 000 символів, перше й останнє виникнення, кількість (error_kinds).
Правова підстава	Ст. 6(1)(f) GDPR (безпека експлуатації, ст. 32).
Одержувачі	Оператори електронною поштою через постачальника поштових послуг: для нового типу помилки — джерело й необроблений текст повідомлення до 400 символів (не очищений), а також щоденний оглядовий лист; для хвилі помилок надходить лише сигнал Telegram. Telegram отримує лише фіксовані речення без змінних («Виник новий тип помилки», «Багато помилок за короткий час»).
Третя країна	Через постачальника поштових послуг.
Зберігання	Журнал помилок — 90 днів (щоночі). Типи помилок без строку зберігання (розділ 10). Сповіщення про помилки ввімкнено в робочій системі й вимкнено в системі розроблення.
Технічні та організаційні заходи	Розділ 8.

B.29 Експлуатаційні сигнали й моніторинг стану

Поле	Запис
Мета	Виявлення відмов: кожні п’ять хвилин перевірка компонентів (головна сторінка, база даних, місце на диску, сигнал активності сканера, затор у черзі), сторінка стану, сигнал про несправність і відновлення, сигнал активності зовнішньому сервісу моніторингу, щоб помітити навіть повну відмову; затор перед сканером.
Категорії суб’єктів даних	Як правило, немає.
Категорії персональних даних	Немає. Щоденні рядки за компонентом із кількістю перевірок і останньою помилкою (system_status_logs), сигнал активності сканера (scanner_heartbeat), щоденні ключові показники без зв’язку з особою (daily_stats). Сигнали до Telegram — фіксовані речення без змінних; сигнал активності — запит без вмісту.
Правова підстава	Не застосовується, оскільки персональних даних немає; із запобіжних міркувань — ст. 6(1)(f).
Одержувачі	Telegram (фіксовані речення); зовнішній сервіс моніторингу (лише запит); оператори електронною поштою.
Третя країна	Telegram поза ЄС; персональні дані не передаються.
Зберігання	Рядки стану — 400 днів (щоночі).
Технічні та організаційні заходи	Розділ 8.

B.30 Відмова від перевірок — виключення домену

Поле	Запис
Мета	Будь-хто може назавжди виключити будь-який домен із перевірок без підтвердження; блокування негайно діє для всіх способів перевірки (безкоштовна перевірка, плагін без облікового запису, дослідження, перевірка потенційного клієнта, інструмент заголовків), а також для доменів платних Клієнтів із підтвердженням контролю; їхній поточний моніторинг завершується з наступною запланованою перевіркою. Воно застосовується до домену та його варіанта з www, а не до інших піддоменів. Скасувати його можемо лише ми, на запит і з підтвердженням. Щоб можна було виявити й скасувати зловживання (наприклад, блокування конкурентом чужих доменів), блокування записується до журналу.
Категорії суб’єктів даних	Особи, які виключають домен.
Категорії персональних даних	Домен, добровільна причина до 250 символів, джерело, IP-адреса, країна, ідентифікатор браузера, час; під час скасування — час, особа, яка скасувала блокування, і причина (blocklist). Журнал запитів як у B.4.
Правова підстава	Для виключення — ст. 6(1)(f) GDPR. Інтерес: постійне виконання бажання не перевіряти домен за всіма способами перевірки. Якщо особа, яка виключає домен, сама є суб’єктом даних, виключення водночас реалізує її заперечення за ст. 21 (ст. 6(1)(c)). Для адреси, країни й ідентифікатора браузера — (f) (виявлення зловживань).
Одержувачі	Google (reCAPTCHA, B.23).
Третя країна	США через reCAPTCHA.
Зберігання	IP-адреса, країна й ідентифікатор браузера — через 12 місяців (нічний запуск видалення, частина «optout_ip»). Саме виключення залишається постійно, щоб воно діяло.
Технічні та організаційні заходи	Розділ 8. Багато блокувань з однієї країни за короткий час створюють аномалію (B.4).

B.31 Нагадування після реєстрації

Поле	Запис
Мета	Один лист через два–14 днів після реєстрації підтвердженим обліковим записам без підтвердженого домену: «Додати сайт» або «Підтвердити домен». Без пропозиції, ціни чи переходу на вищий тариф; із приміткою, що повторно його не надсилатимуть. У будні з 09:00 до 18:00, щонайбільше 50 за запуск.
Категорії суб’єктів даних	Нові власники облікових записів.
Категорії персональних даних	Адреса електронної пошти, мова, час надсилання (поле «нагадування надіслано» в users), домен і стан підтвердження.
Правова підстава	Ст. 6(1)(b) GDPR (примітка щодо налаштування власного облікового запису). Чи є лист повідомленням щодо договірних відносин або комерційною інформацією, яка потребувала б згоди (ст. 10 UŚUDE, польського Закону про надання послуг електронними засобами (ustawa o świadczeniu usług drogą elektroniczną); ст. 398 PKE; § 7 UWG), — відкрите питання юридичної перевірки; оператор може централізовано вимкнути його.
Одержувачі	Постачальник поштових послуг (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Третя країна	Через постачальника поштових послуг.
Зберігання	Час зберігається, доки існує обліковий запис; лист — 30 днів у вихідній пошті.
Технічні та організаційні заходи	Розділ 8. Час установлюється до надсилання, щоб переривання не спричинило другого листа.

B.32 Бот Telegram для сповіщень Клієнта

Поле	Запис
Мета	Чат Telegram пов’язується як адресат сповіщень: Клієнт отримує посилання на нашого бота з одноразовим кодом; коли одержувач натискає «Start», наш сервер читає код із нових повідомлень боту й зберігає ID чату. Для цього не потрібна відкрита кінцева точка на нашому боці (вебхук).
Категорії суб’єктів даних	Клієнти й особи, чий чат Telegram пов’язується.
Категорії персональних даних	Одноразовий код, домен, обліковий запис, який створив, події, режим доставки, ID чату, час (telegram_links); ID чату як адресат (alerts). Telegram надає з повідомленням додаткові відомості профілю; оцінюються й зберігаються лише код та ID чату.
Правова підстава	Ст. 6(1)(b) GDPR; для третіх осіб як одержувачів — A.3.
Одержувачі	Telegram.
Третя країна	Поза ЄС, без рішення про належний рівень захисту; вибір робить Клієнт (4.1). Підстава й повідомлення — відкриті питання юридичної перевірки.
Зберігання	Код чинний 30 хвилин; рядки зв’язків видаляються через один день під час створення нового коду, відкриті коди — разом з обліковим записом і доменом. ID чату як адресат — до видалення адресата сповіщень або домену.
Технічні та організаційні заходи	Розділ 8.

B.33 Партнерська програма й коди відкриття тарифів

Поле	Запис
Мета	Обліковий запис може залучати нових Клієнтів за реферальним кодом і отримує комісію з їхніх оплачених рахунків протягом обмеженої кількості місяців. Код передається в адресі до реєстрації; cookie не встановлюється. Хостинг-провайдери й партнери можуть видавати коди, які відкривають тариф на певний період без оплати; за один тиждень до завершення Клієнт отримує нагадування.
Стан	Партнерська програма типово вимкнена, доки не будуть готові Умови партнерства.
Категорії суб’єктів даних	Партнери й залучені Клієнти.
Категорії персональних даних	Реферальний код, партнер, який рекомендував, і час рекомендації (у users); комісія з партнером, Клієнтом, ID рахунка Stripe, сумою, валютою, комісією, станом, часом (partner_commissions). Відкриття тарифу з тарифом, завершенням, джерелом, нагадуванням (у users); кампанії й використання кодів (bundle_campaigns, bundle_redemptions).
Правова підстава	Ст. 6(1)(b) GDPR (партнерська угода); для Клієнта — (f) (розрахунок комісії, без передавання партнеру даних Клієнта понад суму комісії); податкові документи — (c).
Одержувачі	Партнер бачить свої комісії.
Третя країна	Немає.
Зберігання	Рекомендація й відкриття тарифу — разом з обліковим записом. Комісії й використання кодів не мають строку зберігання в коді; як бухгалтерські документи комісії підлягають зберіганню для податкових цілей (розділ 6.4).
Технічні та організаційні заходи	Розділ 8.

B.34 Канал повідомлення про вразливості

Поле	Запис
Мета	Отримання повідомлень про вразливості в formexposed за правилами на сторінці Безпека й у /.well-known/security.txt.
Категорії суб’єктів даних	Особи, які повідомляють; особи, чиї дані повідомлення містить як докази.
Категорії персональних даних	Адреса електронної пошти, ім’я, вміст повідомлення й вкладення в тому вигляді, у якому їх надсилає заявник. Повідомлення надходить до нас електронною поштою на зазначену там адресу; застосунок його не зберігає.
Правова підстава	Ст. 6(1)(f) GDPR (безпека сервісу, ст. 32); якщо повідомлення містить персональні дані третіх осіб як докази — так само (f) з метою усунення вразливості.
Одержувачі	Постачальник поштових послуг і, до налаштування скриньки, пересилання пошти домену в Namecheap (розділ 4).
Третя країна	Через постачальника поштових послуг і, до переходу, пересилання.
Зберігання	Строку зберігання не встановлено й технічно не забезпечено (розділ 10). Оператор ще має встановити строк; очевидним підходом було б видаляти докази з даними третіх осіб після усунення вразливості й поводитися з листуванням як зі зверненнями до підтримки.
Технічні та організаційні заходи	Розділ 8.

B.35 Відгук щодо звіту

Поле	Запис
Мета	Отримання відгуків під звітом («Чи є помилка в цьому звіті?») для виявлення помилок розпізнавання форм. Суперадміністратор класифікує їх (новий, підтверджений, виправлений, відхилений) і може завантажити дані перевірки звіту як тестовий випадок (форми з полями, причинами й результатами перевірки, без знімків екрана й активно надісланих текстів).
Категорії суб’єктів даних	Особи, які переглядають звіт, із входом або без нього.
Категорії персональних даних	Категорія й перевірка з фіксованих переліків, адреса сторінки до 500 символів, текст до 1 000 символів, мова, час, ідентифікатор звіту, перевірка, хост; ідентифікатор облікового запису, якщо виконано вхід; HMAC-SHA256 IP-адреси із секретним ключем для ліміту; стан, відповідальний за обробку, час обробки (report_feedback). Журнал дій: зміни стану й завантаження тестового випадку. Без адреси електронної пошти, без IP-адреси у відкритому вигляді.
Правова підстава	Ст. 6(1)(f) GDPR (виявлення й усунення помилок розпізнавання; ліміт проти зловживань).
Одержувачі	Немає.
Третя країна	Немає.
Зберігання	24 місяців (нічний запуск видалення, частина «report_feedback»); контрольна сума IP-адреси очищається через 2 дні (частина «report_feedback_ip»); негайно під час видалення облікового запису. Завантажені тестові випадки не містять даних про особу, яка повідомила.
Технічні та організаційні заходи	Розділ 8. Власний захист форм (пастка, підписаний час, CSRF), щонайбільше 5 повідомлень за годину й 20 за день на контрольну суму, 10 на звіт; читати можуть лише суперадміністратори.

6. Зберігання — що охоплює нічний запуск видалення, а що ні

Автоматичне видалення існує й має своє місце. Запуск перевірки стану (srv/cron_status.php) починається кожні п’ять хвилин через crontab вебсервера як у робочій системі, так і в системі розроблення. Він перевіряє компоненти, отримує пошту перевірки доставки, планує перевірки й надсилає сповіщення. Раз на день у вікні з 03:00 до 03:04 він видаляє дані за строками зберігання, а потім створює резервну копію. Із 27 вересня 2026 року він додатково викликає запуск строків зберігання в cfg/fristen_lib.php (fe_fristen_lauf()), частини якого працюють незалежно одна від одної: якщо одна не вдається, інші продовжують, а помилка фіксується в журналі помилок.

Підтвердження, що запуск працює: стан резервного копіювання системи розроблення показує успішну копію о 03:00 11 жовтня 2026 року; резервна копія створюється в тому самому блоці одразу після видалення. Запуск записує журнал для кожної видаленої таблиці лише до стандартного виводу, який crontab відкидає; постійного запису про те, що й коли видалено, немає (розділ 10).

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

6.1 Охоплено щоденним запуском

Дані	Строк зберігання й умова запуску	Місце в коді
Журнал переглядів сторінок (access_logs)	60 днів	srv/cron_status.php
Журнал дій (audit_logs)	365 днів	srv/cron_status.php
Журнал помилок (error_logs)	90 днів	srv/cron_status.php
Вихідна пошта (mail_outbox)	30 днів	srv/cron_status.php
Токени збереження входу «Залишатися в системі» (remember_tokens)	після спливу строку дії (30 днів)	srv/cron_status.php
Неприйняті запрошення (workspace_invites)	після спливу строку дії (14 днів)	srv/cron_status.php
Спроби входу (login_attempts); лічильники спроб (auth_attempt_buckets)	7 днів; лічильники — зі спливом часового вікна (наразі 15 хвилин, одна година для скидання пароля й реєстрації), також під час наступного доступу	srv/cron_status.php
Журнал запитів перевірок без облікового запису (check_throttle)	7 днів	srv/cron_status.php
Одноразові коди з’єднання плагіна (plugin_connect_tokens)	1 день після спливу строку дії	srv/cron_status.php
Усунені аномалії (abuse_flags)	90 днів після усунення	srv/cron_status.php
Звіти зі спливлим строком дії разом із результатом перевірки, формами, окремими результатами виявлення, зображеннями й завданням (лише без домену в обліковому записі)	анонімні — 30 днів, потенційні клієнти — 90 днів	fe_reports_aufraeumen()
Журнал доставки сповіщень (alert_log)	90 днів	fe_alert_log_aufraeumen()
Рядки стану (system_status_logs)	400 днів	srv/cron_status.php
Записи згоди видалених облікових записів (legal_consents)	коли обліковий запис видалено й від згоди минуло 4 роки	srv/cron_status.php
Залишки видалених доменів: результати перевірок, завдання, дані сповіщень, інциденти, коди Telegram, доставки, пульс, вразливості, докази, перелік скриптів і зміни скриптів	негайно під час наступного запуску	fe_fristen_lauf(), частини «orphan_scans», «orphan_rows»
Дані плагінів хостів без домену; рядок плагіна без облікового запису	негайно; рядок — після 90 днів без контакту	частина «orphan_hosts»
Результати інструмента заголовків (header_checks)	наразі 90 днів	частина «header_checks»
Результати перевірок домену з формами, окремими результатами виявлення, зображеннями, звітами, завданнями	13 місяців; останній завершений для кожного домену залишається	частина «old_scans»
Браузерні запуски, завершені браузерні завдання, часові ряди (form_browser_runs, scan_jobs, form_performance)	13 місяців	частини «browser_runs», «browser_jobs», «form_performance»
Лічильники форм (form_metrics), щоденні показники плагінів і повідомлення про зміни (plugin_stats, plugin_changes)	13 місяців	частини «form_metrics», «plugin_stats»
Пристрої з активним входом (login_sessions)	90 днів після останнього використання чи відкликання	частина «sessions»
Прийняті запрошення	30 днів після прийняття	частина «invites»
Звернення до підтримки (support_requests)	24 місяців	частина «support»
Відгуки щодо звітів (report_feedback)	24 місяців; контрольна сума IP-адреси — 2 дні	частини «report_feedback» і «report_feedback_ip»
Версії звітів PDF у кеші (var/pdf)	7 днів	частина «pdf_cache»
IP-адреса, країна й ідентифікатор браузера у відмові від перевірок (blocklist)	12 місяців; виключення залишається	частина «optout_ip»
Підписники порталу (client_subscribers)	непідтверджені — 30 днів; ті, що відписалися, — 3 роки	частина «subscribers»
Ніколи не підтверджені облікові записи разом із робочим простором	30 днів без входу, якщо не приєднано іншого учасника	частина «pending_accounts»
Ключі API без облікового запису (старі дані)	негайно	частина «api_keys»

6.2 Поза вікном 03:00

Дані	Строк зберігання й умова запуску	Місце в коді
Копії в контрольній скриньці перевірки доставки	після обробки, кожні п’ять хвилин	fe_zustellung_abholen()
Відповідності перевірки доставки (delivery_log)	180 днів, під час кожного отримання	fe_zustellung_abholen()
Шифротекст тестових облікових записів у завданнях (scan_jobs)	після запуску, щонайпізніше через одну годину	сервер сканування; fe_login_aufraeumen()
Інциденти (alert_incidents) зі спробами доставки їхніх ескалацій	доки не вирішені; 180 днів після вирішення	fe_vorfaelle_aufraeumen() у cfg/vorfall_lib.php
Надіслані повідомлення зведень (alert_queue)	30 днів після доставки	cfg/kanal_lib.php
Сигнали колективного захисту (swarm_signals)	30 днів, щодня з 04:00	cfg/swarm_lib.php
Перевірки потенційних клієнтів (prospect_checks)	90 днів, щодня з 04:00	srv/cron_status.php
Коди зв’язування Telegram (telegram_links)	1 день, під час створення нового коду	cfg/kanal_lib.php
Лічильники викликів API (api_usage)	1 день, періодично під час виклику	cfg/agentur_lib.php
Усунені відмови постачальників (provider_incidents), кеш вразливостей (vuln_cache)	90 і 30 днів відповідно; без персональних даних	cfg/anbieter_lib.php, cfg/luecken_lib.php
Сирі дані досліджень	під час публікації	fe_studie_veroeffentlichen()
Резервні копії	14 днів, після успішного створення нової резервної копії	cfg/backup_lib.php
Журнали вебсервера	14 днів	системна ротація журналів

6.3 Під час видалення Клієнтом

• Видалення домену (fe_domain_loeschen()): результати перевірок із формами, окремими результатами виявлення й файлами зображень, звіти, завдання, адресати сповіщень, журнал доставки, черга зведень, інциденти, коди Telegram, доставки, пульс, вразливості, журнали доказів, домен із клієнтських порталів із фіксованим вибором; через зовнішні ключі — форми на моніторингу з браузерними запусками, спостереженнями й часовими рядами, тестовий обліковий запис, лічильники форм; дані плагіна хоста, якщо інший домен не посилається на нього. Перелік скриптів домену й зміни скриптів також видаляються разом із ним; власного строку зберігання вони не мають (розділи 6.4 і 10). Дані, що залишилися без пов’язаного домену з періоду до 27 вересня 2026 року, очищає нічний запуск (частини «orphan_scans», «orphan_rows»).
• Видалення робочого простору (fe_arbeitsbereich_daten_loeschen()): додатково бренд разом із логотипом, клієнтські портали разом із підписниками, коди розгортання, перевірки потенційних клієнтів, а також запрошення й участь.
• Видалення облікового запису: негайно завершити чинну платну підписку в Stripe без повернення коштів; передати або видалити власні робочі простори власника; видалити участь, токени збереження входу, пристрої, ключі API з лічильниками, відкриті коди Telegram і рядок облікового запису.
• Видалення тестового облікового запису (fe_login_loeschen()): перезаписати шифротекст, видалити рядок, очистити завдання в очікуванні.

6.4 Чого запуск не охоплює

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

Дані	Що застосовується	Оцінка
Дані облікового запису включно з останньою IP-адресою (users)	до видалення власником облікового запису; неактивні облікові записи не видаляються	договірні дані; бракує правила для постійно неактивних облікових записів без підписки
Журнал дій, перегляди сторінок, журнал помилок видаленого облікового запису	залишаються з ID облікового запису й IP-адресою до кінця свого строку зберігання	навмисно (доказ дій навіть після припинення); ID більше не вказує на обліковий запис
Звернення до підтримки видаленого облікового запису	залишаються до 24 місяців зі старим ID облікового запису	навмисно; ID не очищається
Записи згоди видаленого облікового запису	доки від згоди не мине 4 роки (відлік від згоди, а не від видалення облікового запису)	навмисно (розділ B.12)
Неусунені аномалії з IP-адресою (abuse_flags)	доки хтось їх не усуне	відкрите питання (розділ 10)
Типи помилок із незміненим повідомленням-зразком (error_kinds)	немає строку зберігання	відкрите питання (розділ 10)
Перелік скриптів і зміни скриптів (script_inventory, script_changes)	власного строку зберігання немає; зберігаються, доки існує домен, і видаляються разом із ним	відкрите питання (розділ 10)
Підписники відкликаних клієнтських порталів	до видалення робочого простору	відкрите питання (розділ 10)
Відкликані ключі API й коди розгортання	до видалення облікового запису чи робочого простору	лише хеші, префікс і позначка; незначно
Перелік хостів досліджень (study_domains), ніколи не опубліковані дослідження	немає строку зберігання	відкрите питання (розділ 10)
Внутрішні перевірки без домену й без звіту (результати перевірок, форми, окремі результати виявлення, знімки екрана)	немає строку зберігання; жоден шлях видалення їх не охоплює	відкрите питання (розділ 10)
Комісії, використання кодів, події Stripe	немає строку зберігання	бухгалтерське значення; строк слід установити за податковим правом
Кешований вік домену (domain_age_cache)	немає строку зберігання	лише доменне ім’я й дата реєстрації
Результат автентифікації листа з форми з доменом відправника	разом із доменом; перезаписується під час кожного отримання	див. A.1
Виключення у відмові від перевірок	постійно	навмисно; без постійності виключення не діє
Листи у скриньці каналу повідомлень і загальній скриньці	немає технічного строку зберігання	відкрите питання (розділ 10)

6.5 Поза базою даних

• Знімки екрана зберігаються як файли поза вебкаталогом і видаляються разом зі своїм результатом перевірки (усі зазначені вище шляхи видалення також видаляють файли).
• Файли логотипів брендів видаляються під час заміни й разом із робочим простором.
• На сервері сканування для кожного завдання створюється тимчасовий каталог із результатом і зображеннями; він видаляється після кожного запуску, навіть після помилки.
• Резервні копії зберігаються на вебсервері (B.27).
• Журнали вебсервера з повною IP-адресою зберігаються 14 днів (B.1).

7. Автоматизовані рішення, профілювання й оцінювання

formexposed оцінює сайти, а не людей. За нашою оцінкою, сервіс не приймає рішень, які мають правові наслідки для особи або подібним чином істотно впливають на неї (ст. 22(1) GDPR). Однак існують автоматизовані оцінки й автоматичні блокування. Ми перелічуємо їх, щоб класифікацію можна було перевірити.

Механізм	Що робить	Кого зачіпає
Оцінка й висновок перевірки	Зважена сума відсутніх рівнів захисту (CAPTCHA, пастка, токен, перевірка часу, неефективна CAPTCHA, відома відкрита конфігурація), від 0 до 100; із цього — «Незахищено», «Частково захищено» або «Захищено». Висновок сайту відповідає найгіршій контактній формі, розпізнаній як така правилами (не мовною моделлю); без контактної форми висновку немає. Вагові коефіцієнти можна налаштувати в адміністративній області.	Оператори сайтів; для фізичних осіб — підприємців опосередковано особа. Висновок не має правового наслідку; це результат перевірки з доказами й інструкціями.
Класифікація типу форми	Спочатку правила, локальна мовна модель — лише якщо правила повертають «невідомо». Визначає, чи дозволене активне тестове надсилання (лише для контактної форми, надійно розпізнаної правилами). Форми, класифіковані мовною моделлю, ніколи не надсилаються й не враховуються в оцінці та висновку.	Клієнт і одержувачі його листів із форм; захисний ефект: за сумніву нічого не надсилається.
План дій за пріоритетами в платних звітах	Локальна мовна модель підсумовує вибрані невдалі чи неясні результати перевірки й метадані сканування як короткі нумеровані кроки. Її текст позначається як зведення ШІ; визначальними залишаються окремі результати перевірки. Він не змінює оцінки сканування, висновку чи конфігурації сайту.	Клієнт або інший уповноважений читач звіту, який вирішує, які кроки робити.
Значок	Показує «Захищено» лише за фіксованих умов (B.18), інакше — нейтральний стан.	Клієнт; без впливу на відвідувачів.
Ліміти й блокування для безкоштовної перевірки, інструмента заголовків і відмови від перевірок	Відхиляють запити, якщо досягнуто лімітів за адресою, сеансом, доменом чи системою, якщо домен надто молодий чи невідомого віку або перебуває у списку блокування.	Ініціатори запитів; наслідок: у безкоштовній послузі відмовляють на години чи дні. Адміністратор може зняти обмеження для адреси; звернення через сторінку контактів потрапляють до людини.
Аномалії	Шаблони (багато доменів з однієї адреси, сплески запитів, багато відхилень, багато відмов від перевірок з однієї країни, досягнуто щоденного ліміту) фіксуються й повідомляються. Самі вони не блокують; блокування виникає через ліміти.	Ініціатори запитів.
Блокування входу	Після наразі восьми невдалих входів з однієї адреси за 15 хвилин входи з цієї адреси тимчасово відхиляються. Додатково всі спроби входу, включно з успішними, підраховуються за обліковим записом та IP-адресою (наразі вісім), за обліковим записом за всіма адресами (значно більше, проти розподіленого вгадування) і за IP-адресою (наразі 80) протягом 15 хвилин, так само як коди другого фактора (десять на обліковий запис за 15 хвилин); понад це спроби відхиляються. Тому невдалі спроби з іншої адреси більше не блокують власнику доступ до облікового запису. Підтвердження пароля (п’ять на обліковий запис за 15 хвилин), листи скидання (три на адресу за годину, із незмінною відповіддю), реєстрації (десять на IP-адресу за годину) і спроби пароля клієнтського порталу (десять на портал та IP-адресу, 50 на портал за 15 хвилин) обмежуються так само.	Особи, які входять, реєструються чи відкривають клієнтський портал; наслідок обмежений у часі, скидання пароля залишається можливим.
Поріг reCAPTCHA	Відхиляє надсилання нижче оцінки Google; поріг за місцем використання (наразі 0.7 для перевірки й відмови від перевірок). Відповіді для іншої дії та надсилання, для яких Google не відповідає протягом трьох секунд, також відхиляються.	Особи, які надсилають наші форми; наслідок: нова спроба або шлях через сторінку контактів.
Колективний захист	Автоматично додає домен посилання до списку після досягнення мінімальних порогів; рівні захисту з’єднаних сайтів переносять повідомлення з такими посиланнями до карантину.	Відправники повідомлень на сторінки Клієнтів. Наслідок: повідомлення затримується, а не видаляється, і оператор сайту може його розблокувати. Рішення щодо повідомлення приймає плагін оператора на його сайті, а не ми.
Порівняльні показники	«Захищено краще за X % перевірених сайтів», лише із сукупності щонайменше 20 хостів.	Оператори сайтів; без впливу.

Найближчим до ст. 22 є рівень захисту плагіна на сторінках Клієнтів, який автоматично затримує надсилання. Це обробка оператором сайту на його сервері (A.10). Він нічого не видаляє, а переносить повідомлення до карантину, і оператор може розблокувати будь-яке повідомлення. Профілювання відвідувачів не відбувається ані там, ані в нас; немає ідентифікатора відвідувача, що пов’язував би одне повідомлення з іншим.

8. Технічні та організаційні заходи (ст. 32) — загальний опис

Цей розділ є загальним описом за ст. 30(1)(g) і (2)(d) GDPR. Докладна версія — на сторінці Технічні та організаційні заходи. Кожний захід нижче підтверджено кодом або конфігурацією. Ще не реалізовані заходи наведено в тому самому розділі (8.1), щоб опис був повним.

Сфера	Чинний захід
Шифрування передавання	HTTPS для сайту, застосунку й інтерфейсів; HSTS; cookie сеансу й токена збереження входу лише через HTTPS, HttpOnly, SameSite=Lax.
Контроль доступу (автентифікація)	Паролі лише як хеші, нові — щонайменше десять символів і щонайбільше 72 байти; блокування входу після повторних невдалих спроб і ліміти спроб за обліковим записом та IP-адресою разом, за обліковим записом і за IP-адресою, щоб невдалі спроби з іншої адреси не блокували власнику доступ; ліміти спроб також для підтвердження пароля, скидання пароля (з однаковою відповіддю й часом відповіді), реєстрацій і паролів порталів; двофакторний вхід (TOTP) із зашифрованим секретом, захистом від повторного використання коду й хешованими кодами відновлення; новий ідентифікатор сеансу під час кожного входу, ідентифікатори, не видані сервером, не приймаються; «Залишатися в системі» не для суперадміністраторів, кожний токен чинний лише один раз; зміна адреси електронної пошти робить відкрите посилання скидання нечинним; пристрої можна відкликати окремо або всі разом; список пристроїв зберігає лише хеш ідентифікатора сеансу.
Контроль доступу (повноваження)	Ролі за робочим простором (власник, адміністратор, переглядач); дозволи перевіряються щодо об’єкта, ніколи щодо ідентифікатора з форми; тестовий обліковий запис, «Fix it for me» й активні перевірки лише для власників та адміністраторів; «Перегляд як клієнт» обмежений у часі й заблокований для дій, що змінюють обліковий запис, його завершення повністю завершує вхід, повернення до адміністративної області лише з паролем і другим фактором; запрошення чинні лише доки особа, яка запрошує, є власником чи адміністратором; адреси вебхуків і чат-каналів показуються переглядачам лише скороченими до хоста; ім’я хоста підтвердженого домену неможливо змінити.
Безпека застосунку	Токени CSRF; підготовлені запити до бази даних; наш власний захист форм (пастка, підписана перевірка часу); reCAPTCHA у публічних формах; обмеження частоти для підтримки, перевірок та інтерфейсів; лише один виклик «Fix it for me» на робочий простір одночасно, щоб квота діяла й за одночасних запитів; Content Security Policy із захистом від вбудовування у фрейми, що дозволяє працювати лише скриптам із дозволом (одноразовим значенням) відповідної відповіді; IP-адреса з пересланих заголовків лише від власного проксі й лише з доданого ним запису; токени доступу замасковані в журналі переглядів сторінок.
Секрети	Ключі API, коди розгортання, секрети з’єднання плагінів, одноразові коди й паролі порталів лише як хеші; облікові дані тестових облікових записів асиметрично зашифровані, закритий ключ лише на сервері сканування; вебхуки підписані; події Stripe лише з чинним підписом.
Мінімізація даних	Перевірка доставки не зберігає вмісту й повних адрес відправників; адреси одержувачів у формах — лише як домен; ID облікових записів в адресах скриптів замінюються; показники плагінів лише з фіксованих переліків; тексти помилок надсилання пошти лише як категорія; сигнали Telegram без змінних; зображення браузерних перевірок із замаскованим введенням; без знімків екрана після входу.
Ізоляція сканера	Кожна перевірка у власному контейнері: усі можливості Linux скинуто, без підвищення привілеїв, файлова система лише для читання, ліміт пам’яті й процесів, власна мережа; перевірка цілі щодо приватних і локальних мереж перед прийняттям і в сканері, також після перенаправлень; service worker заблоковані, з’єднання WebSocket закриті. Запити вебсервера (підтвердження контролю, інструмент заголовків, пошук файлів, пульс, RDAP, сертифікати, вебхуки й сповіщення в чаті) лише через звичайні вебпорти й лише до точно перевіреної адреси, вебхуки й сповіщення в чаті лише через HTTPS.
Зберігання	Знімки екрана поза вебкаталогом, отримання лише через звіт; звіти за випадковими адресами з noindex; каталог резервних копій доступний для читання лише сервісу.
Доступність і відновлення	Нічна резервна копія з перевіркою вмісту, щотижневий тест відновлення, сповіщення в разі невдачі; перевірка компонентів кожні п’ять хвилин із сигналом і листом; зовнішній сигнал активності; аварійна зупинка анонімних перевірок; зворотний тиск за затору в черзі.
Простежуваність	Журнал дій для входів, змін, видалень, доступу підтримки й схвалень; журнал помилок зі сповіщенням.
Видалення	Строки зберігання в одному місці в коді, з тих самих налаштувань, що й тексти (розділ 6); ланцюги видалення домену, робочого простору й облікового запису з винятками в розділі 6.4.
Права суб’єктів даних	Експорт усіх даних облікового запису у файл одним натисканням на основі дозволеного переліку полів, без секретів.
Організація	Адміністративна область лише для облікових записів із правами суперадміністратора, заблокована під час «Перегляду як клієнт»; системи розроблення й робочої експлуатації розділені, система розроблення за додатковим бар’єром доступу; передавання правових текстів після схвалення через інструмент, який відхиляє чернетки й заповнювачі.

8.1 Ще не реалізовані заходи

• Немає шифрування бази даних у стані зберігання (виміряно 11 жовтня 2026 року). Винятки — облікові дані тестових облікових записів і секрет двофакторного входу, які шифруються на рівні полів.
• Внутрішні з’єднання не є наскрізно зашифрованими. З’єднання в нашій внутрішній мережі не шифруються на всьому шляху. Облікові дані тестових облікових записів передаються там лише як шифротекст.
• Немає резервної копії в другій локації. Резервні копії наразі зберігаються в тому самому місці, що й база даних, і окремо не шифруються; зашифрована копія в другій локації запланована. До того часу вони захищають від помилкової команди видалення, а не від втрати локації.
• Посилення захисту адміністрування серверів не завершене. Безпека адміністративного доступу до наших серверів ще не відповідає стандарту, який ми плануємо для експлуатації; посилення захисту триває. Ми не публікуємо подробиць, оскільки вони допомогли б нападнику; надаємо їх наглядовому органу на запит.
• Немає функціонального журналу читання в адміністративній області. Дії запису фіксуються в журналі дій; хто лише переглядав яке звернення до підтримки чи який звіт, можна визначити лише з журналу переглядів сторінок (60 днів).
• Немає постійного журналу видалення. Те, що видалив нічний запуск, не фіксується (розділ 6).
• Немає незалежної другої точки перевірки. Пробу в другій локації не налаштовано (A.6).

9. Фахівець із захисту даних — оцінка за ст. 37 GDPR

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

Ст. 37(1) вимагає призначення в трьох випадках.

• Підпункт (a) (орган або установа публічної влади) не застосовується.
• Підпункт (b) (основна діяльність, яка потребує регулярного й систематичного масштабного моніторингу суб’єктів даних): наша основна діяльність — регулярна, систематична перевірка сайтів і форм, а не спостереження за людьми. Ми не створюємо профілів відвідувачів, не використовуємо відстеження й не пов’язуємо одне повідомлення з іншим. Перевірка доставки (A.1) пропускає реальні повідомлення відвідувачів через нашу скриньку, але оцінює лише заголовки й перші 8 KB для віднесення до домену та не зберігає вмісту; вона спостерігає за шляхами доставки, а не людьми. Облікові записи клієнтів і журнали є допоміжними до підприємницької діяльності.
• Підпункт (c) (масштабна обробка особливих категорій за ст. 9 або даних про кримінальні правопорушення за ст. 10 як основна діяльність): не виконується. Особливі категорії можуть випадково з’являтися в копіях листів із форм (A.1), на сторінках після входу (A.5) або у вставленому коді (A.7); випадкове отримання не є основною діяльністю.

Ст. 37(4) дозволяє національному праву додавати інші випадки. Ми отримуємо юридичне підтвердження того, чи вимагає польське право призначення такого фахівця.

Підстави для нової оцінки: активація колективного захисту з IP-мережами; функція, яка розпізнає відвідувачів між кількома повідомленнями чи сайтами; зберігання вмісту з перевірки доставки; Клієнт, чиї форми переважно стосуються особливих категорій (здоров’я, заяви на роботу) з увімкненою масштабною перевіркою доставки; перший працівник із доступом до даних клієнтів. Добровільне призначення залишається можливим; тоді ст. 37–39 застосовуються в повному обсязі.

Окремо: чи потрібна оцінка впливу на захист даних за ст. 35 для окремих видів обробки, відповідає сторінка Оцінка впливу на захист даних. Її порогова оцінка доходить висновку, що оцінка впливу потрібна для колективного захисту (B.21) і досліджень у запланованому масштабі (B.7) та виконується нами, а для перевірки доставки (A.1) потрібна в типовій конфігурації як обов’язок Клієнта, якому ми в цьому допомагаємо.

10. Відкриті питання й заплановані заходи

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

Відкрите питання	Що підтверджено	Значення
Постачальник поштових послуг без задокументованого договору	Для Namecheap, Inc. (Private Email), Phoenix, Arizona, USA договір, місця обробки й підставу передавання не задокументовано. Через цього постачальника проходять листи облікових записів, сповіщення й контрольна скринька з реальними повідомленнями відвідувачів.	Відповідними положеннями є ст. 28(2) і (4) та Глава V GDPR. Укладення й документування заплановані до запуску.
Підстави для чат-сервісів і reCAPTCHA відкриті	Сповіщення до Telegram (без рішення про належний рівень захисту), Slack, Discord, Microsoft Teams і Google Chat; reCAPTCHA без запиту згоди.	Відкриті питання юридичної перевірки; до того часу повідомлення й підстава не остаточні.
Контрольна скринька може утримувати повідомлення під час збоїв	Видалення відбувається після успішної обробки; якщо отримання не вдається, копії залишаються до наступного успішного запуску. Попередження про тривале накопичення листів у скриньці немає.	Копії містять реальні звернення відвідувачів.
Немає резервної копії в другій локації та шифрування бази даних у стані зберігання	Розділ 8.1. Зашифрована резервна копія в другій локації запланована.	Одна подія в локації зачепила б дані й резервну копію одночасно; викрадений носій був би доступним для читання.
Неусунені аномалії без строку зберігання	Аномалії з повною IP-адресою як ключем видаляються лише через 90 днів після усунення; те, що ніколи не усунено, залишається.	Стосується принципу обмеження зберігання (ст. 5(1)(e)); видалення залежить від ручного усунення. Фіксований строк зберігання заплановано (заходи Оцінки впливу на захист даних).
Типи помилок із повідомленням-зразком без строку зберігання	Повідомлення-зразок зберігається незміненим до 2 000 символів; очищений шаблон видаляє адреси й числа, зразок — ні.	Повідомлення про помилки можуть містити адреси електронної пошти, імена хостів або IP-адреси.
Перелік скриптів без власного строку зберігання	Перелік скриптів і зміни скриптів видаляються разом із доменом (FE_DOMAIN_TABELLEN), зокрема під час видалення робочого простору чи облікового запису й у нічному запуску для залишків; власного строку зберігання вони не мають. Вони містять адреси скриптів, адреси сторінок, а для схвалень — особу, яка схвалила, і причину довільним текстом.	Стосується принципу обмеження зберігання (ст. 5(1)(e)); журнал змін зі схваленнями продовжує зростати, доки існує домен.
Підписники відкликаних порталів	Відкликаний портал блокується, а не видаляється; його підписники залишаються до видалення робочого простору.	Мета (надсилання звіту) припинилася з відкликанням.
Переліки досліджень без строку зберігання	Після публікації хости й сегменти залишаються; ніколи не опубліковані дослідження також зберігають свої сирі дані.	Обіцянка «сирі дані видаляються» застосовується лише до опублікованих досліджень.
Внутрішні перевірки без шляху видалення	Перевірки з рівнем довіри «internal», які не мають ані домену, ані звіту (дослідження й перевірки, створені оператором із командного рядка), не охоплюються жодним шляхом видалення; разом із ними залишаються форми, окремі результати виявлення й знімки екрана сторонніх сайтів.	Стосується принципу обмеження зберігання (ст. 5(1)(e)); зачіпає осіб, які нічого не знають про перевірку. Оцінено як високий ризик в Оцінці впливу на захист даних.
Підтвердження контролю не поновлюється	Підтвердження контролю перевіряється один раз; у коді немає шляху, за яким домен знову втрачає його.	Активні тестові надсилання, пошук файлів і сканування захищеної входом частини сайту продовжуються після зміни власника чи доручення.
Сканування захищеної входом частини сайту: передавання до сторінки Клієнта	Для адреси входу дозволено http поряд із https, а помилки сертифіката на сторінці Клієнта не зупиняють входу.	Облікові дані тестового облікового запису можуть бути перехоплені на шляху до сторінки Клієнта.
Видалення залежить від часового вікна	Щоденний блок виконується лише якщо запуск перевірки стану починається між 03:00 і 03:04. Якщо цей єдиний запуск не вдається (база даних недоступна, сервер перезапущено), видалення й резервне копіювання цього дня не відбуваються; надолуження немає. Те, що видалено, постійно не журналюється.	Тоді строки зберігання непомітно продовжуються на день. Пропущене вікно не спричиняє сповіщення; повідомляється лише резервне копіювання, яке запускається й не вдається. Список налаштування в адміністративній області показує дату останнього успішного резервного копіювання.
Деякі видалення залежать від моніторингу	Спорожнення контрольної скриньки перевірки доставки, видалення інцидентів, надісланих повідомлень зведень, сигналів колективного захисту й перевірок потенційних клієнтів, а також очищення залишків копій тестових облікових записів у завданнях виконуються в частині планувальника запуску перевірки стану, яка працює лише доки моніторинг увімкнено в адміністративній області; відповідності перевірки доставки видаляються лише доки налаштована контрольна скринька.	Якщо моніторинг централізовано вимкнено або скриньку видалено, ці строки зберігання зупиняються непомітно.
Канал повідомлень і скриньки без строку зберігання	Повідомлення про вразливості й інші вхідні листи зберігаються поза застосунком; строку зберігання не встановлено.	Повідомлення можуть містити докази з даними третіх осіб.
Значення прихованих полів читаються під час перевірки	Сканер читає значення прихованих полів форми до 24 символів і атрибутів даних до 60 символів для розпізнавання позначок часу й токенів. До карти полів і результатів перевірки потрапляють лише назва поля, тип, підпис і результат розпізнавання, а не значення.	Немає прогалини зберігання; значення перебуває лише в оперативній пам’яті контейнера сканування під час перевірки. Попередньо заповнене значення (як-от номер клієнта) при цьому читається, але не зберігається.
Виведений домен відправника в результаті автентифікації	A.1.	Для особистих доменів відвідувачів — персональні дані, що походять із реального повідомлення.
Посилення захисту адміністрування серверів не завершене; внутрішні з’єднання не є наскрізно зашифрованими	Розділ 8.1. Посилення захисту триває; подробиць публічно не зазначаємо.	Інцидент безпеки на рівні сервера зачепив би застосунок, базу даних і резервні копії одночасно.
Вимірювання в системі розроблення	Схему, код і налаштування виміряно в системі розроблення.	Код і схема відповідають робочій системі; налаштування можуть відрізнятися, і їх потрібно перевірити там повторно перед запуском.

11. Підтримання цього реєстру

Ст. 30 вимагає вести реєстр письмово й надавати наглядовому органу на запит. Для цього потрібні відповідальна особа й періодичність звіряння із системою, а не з попередньою версією.

• Відповідальність: Lukas Wójcik, власник. Перегляд проводиться щороку й за кожної зміни діяльності з обробки.
• Події, що потребують оновлення: новий чи змінений субобробник, зокрема вибір постачальника поштових послуг; нова таблиця або нове поле з персональними даними; зміна строків зберігання чи ланцюгів видалення в cfg/fristen_lib.php або srv/cron_status.php; новий канал сповіщень або новий запит до третьої особи; увімкнення функції, що типово вимкнена (колективний захист з IP-мережами, проба, власні домени, партнерська програма, оплата за рахунком, Spamhaus або Google Web Risk); перехід на інші сервери.
• Процедура: кожне твердження тут походить із коду, схеми чи вимірювання. Перегляд, який лише читає текст, нічого не перевірив: схема й ланцюги видалення вимірюються знову, заповнювачі залишаються заповнювачами, відкриті питання закриваються або переносяться далі з причинами.
• Зв’язок з іншими документами: цей реєстр не замінює Політику конфіденційності, Договір про обробку даних, Технічні та організаційні заходи або перелік Субобробників. Якщо вони й цей реєстр відрізняються, ця відмінність є виявленою невідповідністю.
• Зміни цього документа перелічено на сторінці Зміни договірних документів.