Технічні та організаційні заходи

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

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

Заходи за ст. 32 GDPR, за допомогою яких LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland, захищає сервіс formexposed. Ця сторінка є частиною Договору про обробку даних як Додаток 2.

1. Сфера дії та принцип

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

Структура за ст. 32(1) GDPR. Псевдонімізацію й шифрування (підпункт (a)) охоплює розділ 4; постійну конфіденційність, цілісність, доступність і стійкість систем (підпункт (b)) — розділи 3, 5, 6 і 7; здатність своєчасно відновлювати доступність після інциденту (підпункт (c)) — розділ 7.1; процес регулярного тестування, оцінювання й аналізу ефективності (підпункт (d)) — розділ 9. Ми вибрали заходи на основі ризиків, описаних у нашій Оцінці впливу на захист даних, з урахуванням сучасного стану техніки й витрат на реалізацію.

Принцип: виміряне, а не заплановане. Тут зазначено лише те, що фактично реалізовано в коді чи експлуатації. Заплановане, але ще не реалізоване прямо перелічено як «заплановано» в розділі 10. Відсутність заходу тут не означає, що він неявно діє.

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

2. Структура сервісу

Сервіс працює на двох власних серверах постачальника в Польщі, розташованих в одній внутрішній мережі:

Вебсервер із базою даних. Він надає застосунок, містить базу даних, надсилає повідомлення й створює резервні копії даних. Лише його налаштовано для приймання запитів з інтернету.
Сервер сканування. Він виконує перевірки сторонніх і власних сайтів у браузері та запускає мовну модель, яка класифікує окремі форми, підсумовує результати сканування як плани дій за пріоритетами для платних облікових записів і додає код у «Fix it for me». Його не налаштовано для приймання запитів з інтернету; натомість він сам отримує завдання з вебсервера й повертає туди результати.

До експлуатації не залучено хостинг-провайдера, дата-центру чи хмарного постачальника, і нічого не надходить до зовнішнього сервісу ШІ. Які треті особи отримують дані, визначено на сторінці Субобробники.

3. Конфіденційність

3.1 Контроль фізичного доступу

Сервери розташовані в приміщеннях постачальника в Польщі, які не відкриті для публіки. Доступ має лише власник (за заявою оператора). Точна адреса місця розташування навмисно тут не зазначається.

3.2 Контроль доступу: вхід до сервісу

Паролі зберігаються лише як хеш за стандартним методом PHP (bcrypt). Якщо стандартний метод змінюється, хеш оновлюється під час наступного входу. Під час спроби входу з невідомою адресою сервер усе одно обчислює хеш, щоб час відповіді не розкривав існування облікового запису. Так само відповідь на запит скидання пароля ані формулюванням, ані тривалістю не розкриває існування облікового запису; листи скидання на ту саму адресу надсилаються щонайбільше тричі на годину. Нові паролі повинні містити щонайменше десять символів і не перевищувати 72 байти (UTF-8), оскільки bcrypt не враховує більше байтів. Зміна пароля завершує сеанси всіх інших пристроїв; скидання через посилання завершує сеанси всіх пристроїв, а посилання чинне лише один раз.
Блокування після невдалих спроб. Невдалі входи підраховуються за IP-адресою; після надто великої кількості за короткий час (наразі вісім за 15 хвилин) вхід із цієї адреси тимчасово блокується. Успішний вхід скидає цей лічильник. Спроби видаляються через сім днів. Крім того, перед кожною перевіркою пароля підраховується одна спроба за обліковим записом (для невідомої адреси — за введеною адресою) та IP-адресою, включно з успішними спробами: наразі щонайбільше вісім на обліковий запис із тієї самої IP-адреси й 80 на IP-адресу за 15 хвилин; для облікового запису за всіма адресами сукупно діє значно вищий ліміт проти розподіленого вгадування. Тому невдалі спроби з іншої адреси більше не блокують власнику доступ до облікового запису. Ці лічильники містять лише ключ HMAC, без адреси електронної пошти чи IP-адреси у відкритому вигляді, і припиняють існувати зі спливом свого часового вікна. Якщо сховище лічильників недоступне, у вході відмовляють, а не пропускають його. Такий самий тип обмеження застосовується до підтвердження пароля перед зміною пароля чи адреси, увімкненням чи вимкненням другого фактора, передаванням робочого простору, експортом даних і видаленням облікового запису (п’ять спроб на обліковий запис за 15 хвилин), до реєстрацій (десять на IP-адресу за годину) та паролів клієнтських порталів (десять спроб на портал та IP-адресу, 50 на портал за 15 хвилин).
Другий фактор. Кожен обліковий запис може ввімкнути вхід з одноразовим кодом за RFC 6238 (TOTP). Секрет для цього зберігається зашифрованим у базі даних; ключ не зберігається в базі даних, тому самого її витягу недостатньо. Прийнятий код не є чинним удруге. Десять кодів відновлення зберігаються лише як хеші. Одноразові коди й коди відновлення обмежені десятьма спробами на обліковий запис за 15 хвилин, зокрема під час налаштування.
Адміністративна область лише з другим фактором. Адміністративна область оператора відкривається лише обліковим записам з увімкненим другим фактором. Контрольний список налаштування повідомляє про кожний обліковий запис адміністратора без другого фактора.
Сеанси. Скрипти не можуть прочитати сеансовий cookie (HttpOnly), він надсилається лише через HTTPS (Secure) і не надсилається із запитами зі сторонніх сайтів, здатними щось змінити (SameSite=Lax). Під час входу створюється новий ID сеансу, тому підкладений заздалегідь ID більше не чинний; сервер не приймає ID сеансу, якого сам не видав. Кожен обліковий запис бачить свої пристрої з активним входом і може окремо завершувати їхні сеанси.
«Залишатися в системі» є необов’язковим і діє 30 днів, але не для облікових записів з адміністративними правами; вони завжди входять із паролем і другим фактором. Токен складається з двох частин; частина для перевірки зберігається в базі даних лише як хеш. Кожне використання замінює його новим, і навіть за одночасних запитів кожний токен чинний лише один раз, щоб викрадений токен було виявлено щонайпізніше під час наступного справжнього відвідування.
Посилання в листах. Посилання для підтвердження адреси й скидання пароля зберігаються в базі даних лише як хеші. Посилання скидання чинне одну годину, посилання підтвердження реєстрації — 72 години, посилання підтвердження зміненої адреси — 24 години. У разі зміни адреси електронної пошти відкрите посилання скидання стає нечинним.
Інтерфейси. Ключі API, коди з’єднання розширень і коди розгортання зберігаються лише як хеші. Ключі API можна використовувати лише обмежену кількість разів за хвилину; коди з’єднання розширень чинні 15 хвилин і лише один раз.
Захист від ботів у публічних формах (реєстрація, вхід, пароль, перевірка, інструмент заголовків, відмова від перевірок, підтримка й контакт): Google reCAPTCHA, яка завантажується лише під час надсилання. Приймається лише чинна відповідь Google із достатньою оцінкою для саме тієї дії форми; якщо Google не відповідає протягом трьох секунд, надсилання відхиляється. Подробиці — у Політиці конфіденційності.

3.3 Контроль доступу: адміністрування серверів

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

3.4 Контроль повноважень: права в сервісі

Ролі. Кожен робочий простір має ролі власника, адміністратора й переглядача. Зміна, видалення, запрошення й збереження облікових даних дозволені лише власникам та адміністраторам; лише власник може змінювати ролі й видаляти учасників. Запрошення чинне лише доки особа, яка його надіслала, залишається власником або адміністратором. Переглядачі бачать адреси вебхуків і чат-каналів лише скороченими до хоста, оскільки самої адреси достатньо для дописування до каналу. Перевірка здійснюється на сервері, а не лише в інтерфейсі.
Прив’язка до робочого простору. Домени й налаштування доступні лише учасникам робочого простору. Для кожної перевірки Сервіс створює звіт за випадковим посиланням, яке неможливо вгадати; через це посилання результати й знімки екрана перевірки доступні без входу, знімки екрана — лише разом із посиланням їхнього звіту. Посилання відображається в обліковому записі й сповіщеннях; той, хто передає його, передає звіт.
Запити, що змінюють стан, потребують окремого для сеансу токена безпеки (захист від CSRF), який порівнюється за сталий час.
«Перегляд як клієнт». Для підтримки оператор може бачити застосунок так, як його бачить Клієнт. Перегляд завершується через одну годину, блокує зміни пароля, адреси, другого фактора, пристроїв, підписки, експорту й видалення, на цей час закриває адміністративну область і записується до журналу. Завершення повністю завершує сеанс оператора; повернутися до адміністративної області він може лише повторним входом із паролем і другим фактором. Клієнт може побачити це у своєму експорті даних.
Адміністрування. Лише кілька прямо уповноважених облікових записів мають адміністративні права; кожне скидання другого фактора адміністрацією записується до журналу.

3.5 Контроль розділення

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

4. Шифрування, псевдонімізація й мінімізація даних

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

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

Під час збереження вебсервер шифрує їх відкритим ключем сервера сканування (ECIES: X25519 з одноразовим ключем для кожного запису, HKDF-SHA256, AES-256-GCM). Закритий ключ існує лише на сервері сканування. Вебсервер, база даних і резервні копії містять лише шифротекст; ми також не можемо прочитати його там.
Кожний запис криптографічно прив’язаний до свого домену. У разі перенесення до іншого домену розшифрування не вдається.
Для сканування шифротекст додається до завдання. Сервер сканування розшифровує його й передає облікові дані контейнеру перевірки лише через стандартне введення, ніколи як аргумент командного рядка, видимий у списках процесів. Щойно сервер сканування прочитав його, шифротекст видаляється із завдання; окремий запуск очищає будь-які залишки щонайпізніше через одну годину.
Облікові дані ніколи не відображаються, не записуються до журналів, не видаються через API й не експортуються. Інтерфейс показує лише перший символ і довжину імені користувача. Їх видалення перезаписує шифротекст.
Після входу сканер лише читає: без надсилання, активних тестів, знімків екрана, сторінок виходу, видалення чи скасування.

4.2 Інше шифрування й хеші

Паролі, коди відновлення, паролі клієнтських порталів, ключі API, коди з’єднання й розгортання, токени «Залишатися в системі», ID сеансів у списку пристроїв і посилання підтвердження та скидання зберігаються лише як хеші.
Секрети другого фактора зберігаються зашифрованими (розділ 3.2).
Ми не заявляємо шифрування всієї бази даних у стані зберігання. Чутливі значення захищені окремо, як описано вище.

4.3 Мінімізація даних на етапі проєктування

Перевірка доставки: читаються лише заголовки й щонайбільше перші 8 KB тексту. До бази даних потрапляють лише час, відповідність домену, за потреби ID тестового надсилання та результат перевірки автентичності (SPF, DKIM, DMARC), ніколи не вміст чи повна адреса відправника. Результат автентичності найновішого листа зберігається з доменом і перезаписується наступним; він містить IP-адресу поштового сервера доставки й поштовий домен відправника. Лист видаляється зі скриньки після успішної обробки; якщо отримання чи видалення не вдається, це відбувається під час наступного успішного запуску.
Перевірки: структура форм зберігається з назвами, типами й підписами полів, атрибутами обов’язковості й видимості, без значень; початки попередньо заповнених прихованих полів (до 24 символів) і атрибутів даних (до 60 символів) сканер читає лише під час перевірки й не зберігає. На знімках екрана повної перевірки дані не приховуються; лише браузерні перевірки закривають поля введення. Адреси одержувачів форм зберігаються лише як домен. Активні тестові надсилання містять лише позначені тестові тексти без персональних даних.
Розширення для WordPress і TYPO3 передають лише щоденні показники й характеристики, як-от перелік плагінів, а для з’єднаного плагіна WordPress — також домени посилань із заблокованих повідомлень для колективного захисту (типово ввімкненого); жодного іншого вмісту, імен, адрес чи IP-адрес відвідувачів. Необов’язкові лічильники помилок форм і полів типово вимкнені.
«Fix it for me»: вставлений код обробляється лише протягом запиту й не зберігається.
Значок: зображення значка на сайтах клієнтів не встановлює cookie й не починає сеансу.
Експлуатаційні повідомлення на телефон оператора є фіксованими текстами без змінних, тобто без імен, адрес чи вмісту. Повідомлення про помилки електронною поштою оператору містять необроблений текст повідомлення про помилку, не очищений і обрізаний до 400 символів; в окремих випадках він може містити адреси чи посилання.
Колективний захист: між розширеннями Клієнтів поширюються лише домени з посилань у заблокованому спамі; обмін IP-мережами вимкнено.
Місцезнаходження: країна IP-адреси визначається з локального файлу бази даних; жодна адреса не надходить до сервісу геолокації.

5. Захист від неналежного використання сканера

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

5.1 Ізольований запуск

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

5.2 Мережа: два рівні

Перший рівень у сканері: перед скануванням, а потім для кожного окремого запиту браузера, включно з перенаправленнями й вбудованим вмістом, перевіряється, на яку адресу перетворюється ім’я. Приватні, локальні, зарезервовані мережі та мережі для документації (IPv4 і IPv6) відхиляються, як і порти, відмінні від звичайних для вебу. Браузер не дозволяє service worker, а з’єднання WebSocket закриваються, оскільки обидва механізми могли б обійти цю перевірку.
Другий рівень у мережі: контейнери працюють у власній мережі. Правила брандмауера дозволяють з’єднання звідти до інтернету лише через вебпорти; з’єднання до приватних мереж, зокрема нашої внутрішньої мережі з вебсервером і базою даних, блокуються. Винятки, потрібні самому запуску перевірки, обмежені необхідним і описані в нашій внутрішній документації. Цей рівень діє також якщо ім’я перетворюється на іншу адресу лише після першої перевірки.

5.3 Запити вебсервера

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

5.4 Чого сканер не робить на сторонніх сайтах

Активні тестові надсилання (щонайбільше п’ять за перевірку) для Клієнтів існують лише для доменів із наданим підтвердженням контролю (DNS, метатег, файл або розширення); єдиний виняток — внутрішні перевірки наших власних тестових і демонстраційних доменів. Ім’я хоста домену з підтвердженням контролю неможливо змінити, щоб підтвердження не перейшло до іншого хоста. Усе інше пасивне: читання сторінок як відвідувачем.
Браузерні перевірки доходять до моменту перед надсиланням і не запускають жодного замовлення, оплати чи надсилання.
Домени у списку відмов від перевірок не перевіряються; поточний моніторинг завершується з наступною запланованою перевіркою.

6. Цілісність: передавання й введення

6.1 Передавання

Застосунок доступний з інтернету лише через HTTPS; браузеру вказується використовувати лише HTTPS протягом одного року (HSTS). Сертифікати поновлюються автоматично.
Додаткові заголовки обмежують вбудовування застосунку в сторонні сторінки, вгадування типів файлів і надсилання форм стороннім адресатам. Політика безпеки вмісту дозволяє працювати в застосунку лише тим скриптам, які сервер дозволяє у відповідній відповіді; сучасні браузери не виконують вставлених зловмисником скриптів чи обробників подій у HTML.
Пошта зі скриньки перевірки доставки отримується зашифрованим з’єднанням із перевіркою сертифіката.
Вебхуки можна підписувати секретом Клієнта (HMAC-SHA256 із позначкою часу), щоб одержувач міг перевірити походження й цілісність. Запити до необов’язкової другої точки перевірки підписуються, а для браузерних перевірок — і відповіді.
Зазначено відкрито: з’єднання в нашій внутрішній мережі зашифровані не на всіх ділянках. Облікові дані для сканування захищеної входом частини сайту залишаються зашифрованими на всьому шляху (розділ 4.1).

6.2 Контроль введення й журнали

Важливі дії в облікових записах і робочих просторах (як-от вхід, зміни доменів, адресатів сповіщень і прав, видалення, доступ підтримки) записуються в журналі дій з обліковим записом, часом, IP-адресою й країною та видаляються через 365 днів.
Записи доступу до сторінок, що зберігаються для безпеки й запобігання зловживанням, видаляються через 60 днів, журнали помилок — через 90 днів, вміст надісланих листів — через 30 днів. Токени доступу в запитаних адресах і джерелах переходу, як-от у посиланнях на звіти чи портали, з’являються в записах доступу до сторінок лише в замаскованому вигляді.
Прийняття договірних документів зберігається з відображеною версією, її контрольною сумою, часом, IP-адресою й ідентифікатором браузера.
Журнали доказів можуть отримувати позначку часу від зовнішньої служби позначок часу; до неї надходить лише контрольна сума вмісту, а не сам вміст.

7. Доступність і стійкість

7.1 Резервне копіювання

Резервна копія бази даних створюється щоночі. Остаточну назву вона отримує лише після перевірки вмісту: успішного завершення програми резервного копіювання, наявності щонайменше одного запису, тієї самої кількості таблиць, що й у базі даних, і завершального рядка повного запуску. Старіші резервні копії видаляються лише після успішного створення нової.
Кожна резервна копія видаляється через 14 днів. Місце зберігання перебуває поза будь-яким каталогом, з якого надається вміст; місце всередині проєкту відхиляється.
Тест відновлення: раз на тиждень найновіша резервна копія завантажується до тимчасової бази даних, порівнюється таблиця за таблицею з робочою базою й знову видаляється. Результат зберігається.
Якщо резервне копіювання чи тест не вдається, повідомлення надсилається електронною поштою й на телефон оператора.
Відновлення після інциденту: якщо база даних відмовляє або дані пошкоджені, ми відновлюємо найновішу перевірену резервну копію. Зміни після цієї копії, як правило щонайбільше за один день, можуть при цьому втратитися; якщо резервне копіювання не вдалося — відповідно більше. Потім ми повторно виконуємо відомі пізніші запити на видалення (розділ 8). Ми не зобов’язуємося забезпечити певний час відновлення.
Обмеження, зазначене відкрито: резервні копії наразі зберігаються в тому самому місці, що й база даних, і окремо не шифруються. Вони захищають від помилок експлуатації, хибних змін і пошкоджених даних, а не від втрати самого сервера. Зашифрована копія в другій локації запланована (розділ 10).
Облікові дані для сканування захищеної входом частини сайту містяться в резервних копіях лише як шифротекст; секрет другого фактора — лише в зашифрованому вигляді з ключем поза базою даних.

7.2 Моніторинг

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

7.3 Зміни й розгортання

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

8. Видалення й строки зберігання

Нічний запуск видалення забезпечує дотримання строків, зазначених у Політиці конфіденційності й Договорі про обробку даних. Він читає ті самі налаштування, з яких беруться числа в текстах; тому щодо цих строків текст і поведінка не розходяться.
Результати перевірок включно зі знімками екрана видаляються через 13 місяців (найновіший для кожного домену залишається), показники розширень — через 13 місяців, журнали доставки сповіщень — через 90 днів, звернення до підтримки — через 24 місяців.
Видалення домену видаляє його дані, включно з перевірками, формами, окремими результатами виявлення, знімками екрана, звітами, завданнями, адресатами й журналами сповіщень, інцидентами, даними доставки, обліковими даними для сканування захищеної входом частини сайту та доказами.
Видалення облікового запису відбувається негайно; робочі простори без інших учасників видаляються з даними, робочі простори з іншими учасниками переходять до іншого учасника — насамперед до адміністраторів, а серед них до того, хто належить до простору найдовше. До спливу власних строків зберігаються: журнали, записи яких зберігають старий номер облікового запису, що більше не посилається на наявний обліковий запис, включно із записом видалення, а також надіслані листи, підтвердження укладення договору, звернення до підтримки, звіти перевірок потенційних клієнтів (до 90 днів) і платіжні дані в Stripe; подробиці — у Політиці конфіденційності.
Видалені дані залишаються в резервних копіях до спливу строку їх зберігання через 14 днів. Цільового видалення всередині резервної копії не відбувається; якщо резервну копію відновлено, відомі пізніші запити на видалення виконуються повторно вручну.

9. Організація й перегляд

Люди: наразі сервіс експлуатує сам власник. Інші особи отримують доступ лише після зобов’язання конфіденційності й лише в необхідному обсязі та обробляють дані лише за нашими вказівками (ст. 29 і ст. 32(4) GDPR).
Субобробники: ми залучаємо їх лише після перевірки їхніх гарантій і за договором відповідно до ст. 28(4) GDPR та перелічуємо на сторінці Субобробники; подробиці регулює Договір про обробку даних.
Порушення захисту персональних даних: якщо порушення захисту персональних даних зачіпає дані, які ми обробляємо як обробник, ми повідомляємо Клієнта без невиправданої затримки, за можливості протягом 48 годин; подробиці регулює Договір про обробку даних.
Повідомлення про вразливості: ми приймаємо повідомлення на сторінці Безпека й через файл /.well-known/security.txt.
Контрольний список налаштування й запуску: в адміністративній області контрольний список вимірює стан налаштувань, важливих для безпеки, як-от резервне копіювання, адміністратори без другого фактора, налаштування пошти й сигнал активності, та показує відхилення.
Перегляд цих заходів (ст. 32(1)(d) GDPR): після кожної істотної зміни сервісу, після кожного інциденту безпеки й в інших випадках щонайменше раз на рік. При цьому ми оцінюємо, чи ефективні заходи й чи досі відповідають ризикам, та фіксуємо результат у новій версії цієї сторінки або, якщо нічого не змінюється, датою перегляду в розділі 11. Постійно контрольний список налаштування й запуску вимірює стан охоплених ним налаштувань.
Зовнішні аудити: наразі зовнішні тести на проникнення не замовляються, і сертифікацій безпеки немає. Це зазначено тут, щоб ніхто не припускав їх наявності.

10. Заплановано, ще не реалізовано

Ці пункти не є заходами, які ми зобов’язуємося забезпечити, доки нова версія не позначить їх тут як реалізовані:

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

11. Стан і версія

Версія 1.1 · Останнє оновлення: 22 жовтня 2026 року · у разі розбіжностей між мовними версіями перевагу має польська версія замість німецької; інших змін немає.
Версія 1.0 · Останнє оновлення: 11 жовтня 2026 року · перша версія як окрема сторінка; раніше Додаток 2 до Договору про обробку даних. Виправлено порівняно з попереднім додатком: тест відновлення виконується щотижня, резервні копії перебувають на тому самому сервері, автоматизований набір тестів не запускається перед кожним розгортанням, з’єднання у внутрішній мережі зашифровані не на всіх ділянках. Описано нове: шифрування облікових даних для сканування захищеної входом частини сайту, ізоляція сканера, взаємний нагляд і сповіщення про помилки.
Зміни публікуються з новим номером версії тут і в огляді Зміни договірних документів; для будь-якого послаблення заходів застосовується строк повідомлення за Договором про обробку даних.
У разі розбіжностей між мовними версіями перевагу має польська версія.

Чим можемо допомогти?