Технически и организационни мерки

Този документ е публикуван на няколко езика. В случай на несъответствие между езиковите версии меродавна е полската версия.

Версия 1.1 · Последна актуализация: 22 октомври 2026 г.

Мерки по чл. 32 ОРЗД, с които LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Полша, защитава услугата formexposed. Тази страница е неразделна част от Договора за обработване на лични данни като Приложение 2.

1. Обхват и принцип

Мерките се прилагат за всички данни, обработвани от услугата: за данните, които обработваме от името на нашите Клиенти (описани в Договора за обработване на лични данни), и за данните, за които ние самите сме администратор, като клиентските акаунти и логовете. Няма отделни нива на защита за двете; това, което защитава акаунта, защитава и данните, обработвани от наше име като обработващ.

Структура съгласно чл. 32(1) ОРЗД. Псевдонимизацията и криптирането (буква (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 минути, включително при настройката.
Административна област само с втори фактор. Административната област на оператора се отваря само за акаунти с включен втори фактор. Контролният списък за настройка отчита всеки администраторски акаунт без втори фактор.
Сесии. Бисквитката на сесията не може да бъде прочетена от скриптове (HttpOnly), изпраща се само през HTTPS (Secure) и не се изпраща със заявки от сайтове на трети лица, които биха могли да променят нещо (SameSite=Lax). При вход се създава нов идентификатор на сесията, така че предварително подхвърлен идентификатор вече не е валиден; сървърът не приема идентификатор на сесия, който не е издал сам. Всеки акаунт вижда устройствата, на които е влязъл, и може да излиза от тях поотделно.
„Запомни ме“ не е задължително и е валидно 30 дни, но не и за акаунти с административни права; те винаги влизат с парола и втори фактор. Токенът се състои от две части; проверяващата част се съхранява в базата данни само като хеш. Всяко използване го заменя с нов и дори при едновременни заявки всеки токен е валиден само веднъж, така че откраднат токен се забелязва най-късно при следващото истинско посещение.
Връзки в имейли. Връзките за потвърждаване на адреса и за нулиране на паролата се съхраняват в базата данни само като хеш. Връзката за нулиране е валидна един час, връзката за потвърждаване на регистрация – 72 часа, връзката за потвърждаване на променен адрес – 24 часа. Ако имейл адресът бъде променен, открита връзка за нулиране става невалидна.
Интерфейси. API ключовете, кодовете за свързване на разширенията и кодовете за внедряване се съхраняват само като хеш. API ключовете могат да се използват само ограничен брой пъти в минута; кодовете за свързване на разширенията са валидни 15 минути и само веднъж.
Защита от ботове на публичните форми (регистрация, вход, парола, проверка, инструмент за хедъри, opt-out, поддръжка и контакт): 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 ключовете, кодовете за свързване и внедряване, токените за „Запомни ме“, идентификаторите на сесии в списъка с устройства и връзките за потвърждаване и нулиране се съхраняват само като хеш.
Тайните за втория фактор се съхраняват шифровани (раздел 3.2).
Не твърдим, че цялата база данни е шифрована в покой. Чувствителните стойности са защитени поотделно, както е описано по-горе.

4.3 Свеждане на данните до минимум чрез проектирането

Проверка на доставката: четат се само хедърите и най-много първите 8 KB от текста. В базата данни попадат само часът, връзката с домейна, където е приложимо идентификаторът на тестовото изпращане и резултатът от проверката на автентичността (SPF, DKIM, DMARC), никога съдържанието или пълен адрес на подателя. Резултатът от проверката на автентичността на последния имейл се пази с домейна и се презаписва от следващия; той съдържа IP адреса на доставящия пощенски сървър и имейл домейна на подателя. Имейлът се изтрива от пощенската кутия след успешна обработка; ако извличането или изтриването е неуспешно, това става при следващото успешно изпълнение.
Проверки: структурата на формите се съхранява с имена на полета, типове и етикети, атрибути за задължителност и видимост, без стойности; скенерът чете началото на предварително попълнени скрити полета (до 24 знака) и на data атрибути (до 60 знака) само по време на проверката и не ги съхранява. Екранните снимки от пълната проверка не се редактират; само проверките в браузър покриват полетата за въвеждане. Адресите на получатели от формите се съхраняват само като домейн. Активните тестови изпращания съдържат само обозначени тестови текстове без лични данни.
Разширенията за WordPress и TYPO3 предават само дневни данни и характеристики като инвентара на плъгините, а при свързан плъгин за WordPress и домейните на връзки от блокирани съобщения за защита чрез колективно разпознаване (включено по подразбиране); никакво друго съдържание, никакви имена, адреси или IP адреси на посетители. Незадължителните броячи на грешки във формите и полетата са изключени по подразбиране.
„Fix it for me“: поставеният код се обработва само за времето на заявката и не се съхранява.
Значка: изображението на значката на уебсайтовете на клиентите не задава бисквитки и не стартира сесия.
Оперативните известия до телефона на оператора са фиксирани текстове без променливи, т.е. без имена, адреси или съдържание. Известията за грешки по имейл до оператора съдържат суровия текст на съобщението за грешка, неизчистен и съкратен до 400 знака; в отделни случаи той може да съдържа адреси или връзки.
Колективна защита: между разширенията на Клиентите се споделят само домейни от връзки в блокиран спам; обменът на IP мрежи е изключен.
Местоположение: държавата на IP адрес се определя от локален файл с база данни; никакъв адрес не се изпраща към услуга за геолокация.

5. Защита срещу злоупотреба със скенера

Скенерът зарежда страници на трети лица с истински браузър. Без защита той би бил инструмент, с който някой отвън би могъл да достигне до нашата вътрешна мрежа или до други непублични цели (подправяне на заявки от страна на сървъра, SSRF). Затова има два независими слоя и изолация на всяко отделно изпълнение.

5.1 Изолирано изпълнение

Всяка проверка се изпълнява в собствен контейнер, който след това се премахва. Той работи без администраторски права, без допълнителни възможности на операционната система и без възможност за повишаване на привилегиите. Файловата му система е само за четене, с изключение на малки временни области.
Паметта, броят на процесите и времето за изпълнение са ограничени; изпълнение, което надвиши времето, се прекратява.

5.2 Мрежа: два слоя

Първи слой, в скенера: преди сканирането и след това при всяка отделна заявка на браузъра, включително пренасочвания и вградено съдържание, се проверява към какво се разрешава адресът. Частни, локални, резервирани мрежи и мрежи за документация (IPv4 и IPv6) се отхвърлят, както и портове, различни от обичайните за уеб. Браузърът не допуска service workers, а WebSocket връзките се затварят, тъй като и двете биха могли да заобиколят тази проверка.
Втори слой, в мрежата: контейнерите работят в собствена мрежа. Правилата на защитната стена разрешават връзки оттам към интернет само през уеб портове; връзките към частни мрежи, включително нашата вътрешна мрежа с уеб сървъра и базата данни, са блокирани. Изключенията, които самото изпълнение на проверката изисква, са ограничени до необходимото и са описани в нашата вътрешна документация. Този слой действа и ако дадено име се разреши различно едва след първата проверка.

5.3 Заявки, отправяни от уеб сървъра

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

5.4 Какво скенерът не прави на сайтове на трети лица

Активни тестови изпращания (най-много пет на проверка) съществуват за Клиентите само за домейни, за които е предоставено доказателство за контрол (DNS, мета таг, файл или разширение); единственото изключение са вътрешните проверки на нашите собствени тестови и демонстрационни домейни. Името на хоста на домейн с доказан контрол не може да бъде променено, така че доказателството да не премине към друг хост. Всичко останало е пасивно: четене на страници като посетител.
Проверките в браузър стигат до момента преди изпращането и не задействат поръчка, плащане или изпращане.
Домейните в списъка за opt-out не се проверяват; текущото наблюдение приключва със следващата планирана проверка.

6. Цялостност: предаване и въвеждане

6.1 Пренос

Приложението е достъпно от интернет само през HTTPS; браузърът получава указание да използва само HTTPS в продължение на една година (HSTS). Сертификатите се подновяват автоматично.
Допълнителни хедъри ограничават вграждането на приложението в страници на трети лица, отгатването на типовете файлове и изпращането на форми към цели на трети лица. Политика за сигурност на съдържанието (CSP) позволява в приложението да се изпълняват само онези скриптове, които сървърът разрешава със съответния отговор; съвременните браузъри не изпълняват инжектирани скриптове или обработчици на събития в HTML.
Пощенската кутия за проверката на доставката се чете чрез криптирана връзка с проверка на сертификата.
Уебхуковете могат да бъдат подписвани с тайна на Клиента (HMAC-SHA256 с времеви печат), така че получателят да може да провери произхода и цялостността. Заявките към незадължителната втора контролна точка се подписват, а при проверките в браузър – и отговорите им.
Казано открито: връзките в нашата вътрешна мрежа не са криптирани навсякъде. Данните за вход за сканирането зад вход остават шифровани през цялото време (раздел 4.1).

6.2 Контрол на въвеждането и логове

Важните действия в акаунтите и работните пространства (като вход, промени в домейни, канали за предупреждения и права, изтривания, достъп от поддръжката) се записват в лога на дейностите с акаунт, час, IP адрес и държава и се изтриват след 365 дни.
Записите за достъп до страници, водени за сигурност и предотвратяване на злоупотреби, се изтриват след 60 дни, логовете на грешки – след 90 дни, съдържанието на изпратените имейли – след 30 дни. Токените за достъп в заявените адреси и референтите, като тези на връзките към доклади или портали, се появяват в записите за достъп до страници само в маскиран вид.
Приемането на договорните документи се съхранява с показаната версия, нейната контролна сума, час, IP адрес и идентификатор на браузъра.
Доказателствените логове могат да бъдат снабдени с времеви печат от външен доставчик на удостоверителни услуги за времеви печат; към него се изпраща само контролна сума на съдържанието, не самото съдържание.

7. Наличност и устойчивост

7.1 Резервни копия

Базата данни се архивира всяка нощ. Резервното копие получава окончателното си име едва след проверка на съдържанието му: успешно завършване на програмата за архивиране, поне един запис, толкова таблици, колкото има базата данни, и заключителният ред на пълно изпълнение. По-старите резервни копия се премахват само след успешно ново копие.
Всяко резервно копие се изтрива след 14 дни. Мястото на съхранение е извън всяка обслужвана директория; място в рамките на проекта се отхвърля.
Тест за възстановяване: веднъж седмично последното резервно копие се зарежда във временна база данни, сравнява се таблица по таблица с работната и се изтрива отново. Резултатът се съхранява.
Ако архивиране или тест е неуспешен, се изпраща известие по имейл и до телефона на оператора.
Възстановяване след инцидент: ако базата данни откаже или данните бъдат повредени, възстановяваме последното тествано резервно копие. При това промените, направени след това копие, като правило най-много тези от един ден, могат да бъдат загубени; ако архивиране е било неуспешно – съответно повече. След това изпълняваме повторно известните по-късни искания за изтриване (раздел 8). Не се задължаваме с определено време за възстановяване.
Ограничение, казано открито: понастоящем резервните копия се съхраняват на същото място като базата данни и не са отделно шифровани. Те защитават от грешки при експлоатацията, погрешни промени и повредени данни, но не и от загуба на самия сървър. Планирано е шифровано копие на второ местоположение (раздел 10).
Данните за вход за сканирането зад вход се съдържат в резервните копия само като шифриран текст; тайната за втория фактор – само в шифрован вид, с ключ извън базата данни.

7.2 Наблюдение

Процес за проверка на състоянието проверява компонентите на услугата на всеки пет минути, включително базата данни, опашката и сигнала за активност (heartbeat) на скенера, който скенерът записва редовно дори когато не работи. Ако компонент откаже, се изпраща известие; ако се възстанови – съобщение за отмяна на тревогата.
Взаимно наблюдение: процесът за проверка на състоянието не може да съобщи за отказ на машината, на която работи. Затова сървърът за сканиране проверява всяка минута дали приложението отговаря и след няколко последователни неуспеха съобщава с фиксиран текст на телефона на оператора. Обратно, уеб сървърът наблюдава сигнала за активност на скенера; контролният списък за настройка показва дали взаимното наблюдение работи.
Сигнал за грешка: вид грешка, която никога досега не е възниквала, се съобщава веднъж незабавно; натрупване на грешки задейства само един сигнал до телефона на оператора; веднъж дневно се изпраща обобщение. Така не научаваме за грешка първо от Клиент.
Ограничение, казано открито: и двата сървъра са на едно и също място. Отказ на цялото местоположение, например на електрозахранването или на интернет връзката, не се съобщава от никой механизъм за предупреждение, а се забелязва от човек.

7.3 Промени и внедряване

Новите версии първо се изграждат и тестват в отделната среда за разработка. Внедряването проверява всички предпоставки преди записването на първия файл, извършва промените в схемата на базата данни и оставя текущите проверки да завършат по подреден начин, преди скенерът да се рестартира.
За пътя на нов Клиент има бърз тест (smoke test) чрез реален HTTP, който се изпълнява след превключвания. Не твърдим, че преди всяко отделно внедряване се изпълнява автоматизиран набор от тестове.

8. Изтриване и срокове на съхранение

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

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

Хора: понастоящем услугата се управлява от самия собственик. Други лица получават достъп само след поемане на задължение за поверителност и само в необходимия обхват и обработват данни само по наши указания (чл. 29 и чл. 32(4) ОРЗД).
Подизпълнители обработващи лични данни: ангажираме ги само след преглед на техните гаранции и въз основа на договор по чл. 28(4) ОРЗД и ги посочваме на страницата Подизпълнители обработващи лични данни; подробностите се уреждат от Договора за обработване на лични данни.
Нарушения на сигурността на личните данни: ако нарушение на сигурността на личните данни засяга данни, обработвани от наше име като обработващ, уведомяваме Клиента без ненужно забавяне, по възможност в рамките на 48 часа; подробностите се уреждат от Договора за обработване на лични данни.
Докладване на уязвимости: приемаме сигнали на Сигурност и чрез файла /.well-known/security.txt.
Контролен списък за настройка и старт: в административната област контролен списък измерва състоянието на свързаните със сигурността настройки, като архивиране, администратори без втори фактор, настройка на пощата и сигнал за активност, и показва отклоненията.
Преглед на тези мерки (чл. 32(1)(d) ОРЗД): при всяка съществена промяна на услугата, след всеки инцидент със сигурността и иначе поне веднъж годишно. При това преценяваме дали мерките са ефективни и все още отговарят на рисковете и отразяваме резултата в нова версия на тази страница или, ако нищо не се променя, с датата на прегледа в раздел 11. Текущо контролният списък за настройка и старт измерва състоянието на настройките, които обхваща.
Външни одити: понастоящем не са възложени външни тестове за проникване и няма сертификати за сигурност. Посочваме това тук, за да не предполага никой, че съществуват.

10. Планирано, все още невъведено

Тези точки не са мерки, за които се задължаваме, докато не бъдат посочени тук като въведени в нова версия:

Резервно копие на второ местоположение: шифровано копие на нощното резервно копие извън сървъра, така че дори пълна загуба на сървъра да не доведе до загуба на данни.
Втора контролна точка: независимото потвърждение на проверките в браузър от второ местоположение е подготвено в услугата, но не е настроено. Без него няма потвърждение от второ местоположение.
Укрепване на администрирането на сървърите: то продължава. По причините, посочени в раздел 1, не публикуваме подробности.

11. Състояние и версия

Версия 1.1 · Последна актуализация: 22 октомври 2026 г. · при несъответствия между езиковите версии предимство има полската версия вместо немската; няма други промени.
Версия 1.0 · Последна актуализация: 11 октомври 2026 г. · първа версия като отделна страница; преди това Приложение 2 към Договора за обработване на лични данни. Коригирано спрямо предишното приложение: тестът за възстановяване се изпълнява седмично, резервните копия са на същия сървър, преди всяко внедряване не се изпълнява автоматизиран набор от тестове, връзките във вътрешната мрежа не са криптирани навсякъде. Новоописани: шифроването на данните за вход за сканирането зад вход, изолацията на скенера, взаимното наблюдение и сигналът за грешка.
Промените се публикуват с нов номер на версия тук и в прегледа Промени в договорните документи; при всяко отслабване на мерките се прилага срокът за уведомление от Договора за обработване на лични данни.
При несъответствия между езиковите версии предимство има полската версия.

С какво можем да помогнем?