Съответствие на уебсайтове с ОРЗД: какво всъщност е нужно, за да го изградите

Повечето съвети за ОРЗД в интернет са писани за юристи или за хора, които купуват генератор на политики. Много малко от тях са писани за човека, който трябва да отвори редактора и да промени нещо.

Това ръководство е от втория вид. То минава през онова, което Общият регламент относно защитата на данните изисква от един уебсайт и от системите зад него, описано като неща, които изграждате, конфигурирате или изтривате. Вършим тази работа за компании, работещи в ЕС, откакто регламентът започна да се прилага през 2018 г., и наборът от типични грешки почти не се е променил оттогава.

Едно нещо да кажем още в началото: ОРЗД не стана по-лесен, защото дойдоха по-нови регламенти. Стана по-важен, защото почти всичко в сегашната вълна от цифрови правила на ЕС предполага, че личните ви данни вече са в ред.

Започнете с честна инвентаризация на данните

Почти всеки провален проект по ОРЗД, който сме наследявали, се е провалил на едно и също място. Екипът е написал политиката първо и е открил данните по-късно.

Преди всичко друго картографирайте какви лични данни реално събира сайтът ви. Не какво пише в продуктовата спецификация, че събира. А какво има в базата данни, в логовете, в платформата за анализ, в CRM, в инструмента за поддръжка, в стека за маркетингова автоматизация, в системата за проследяване на грешки, в логовете на CDN и в скриптовете на трети страни на страницата.

На практика това означава:

• Прегледайте схемата. Всяка колона, която може да идентифицира човек, пряко или в комбинация с друга колона.
• Прочетете раздела Network при реално зареждане на страница. Всяка изходяща заявка към домейн, който не контролирате, е потенциално предаване на лични данни, защото IP адресът плюс user agent са лични данни.
• Проверете какво улавя системата ви за проследяване на грешки. Стековете на извикванията редовно съдържат имейл адреси, токени и тела на заявки.
• Проверете колко дълго се пазят логовете. Логове за достъп с IP адреси, пазени завинаги, са една от най-честите констатации и една от най-лесните за поправяне.

Запишете го като регистър на дейностите по обработване. Член 30 така или иначе го изисква за повечето организации, а версията, полезна за инженерите, е таблица със системата, данните, целта, правното основание, срока на съхранение и получателите.

Изберете правно основание за всяка цел, а не за всяка система

Член 6 ви дава шест правни основания. Грешката, която виждаме най-често, е да се избере едно за целия продукт.

Почти сигурно имате няколко цели едновременно. Изпълнението на поръчка е договор. Проверките за измами обикновено са законни интереси или законово задължение. Пазенето на фактури за законовия срок е законово задължение. Маркетинговите имейли в повечето държави членки изискват съгласие. Незадължителният анализ изисква съгласие заради правилата на ePrivacy за достъп до крайното оборудване, а не заради самия ОРЗД.

Практическото последствие е, че моделът ви на данни трябва да знае на коя цел служи всеки запис. Ако не можете да отделите маркетинговия профил от записа за поръчката, не можете да уважите възражение срещу маркетинга, без да счупите историята на поръчките. Това разделяне е решение в схемата и е мъчително да се добави впоследствие.

Съгласието трябва да е истинско и трябва да е записано

Ако разчитате на съгласие, то трябва да е свободно дадено, конкретно, информирано и недвусмислено и трябва да можете да го докажете по-късно.

Конкретно:

• Нищо незадължително не се задейства, преди потребителят да направи избор. Това включва кода за анализ, рекламния пиксел, уиджета за чат, шрифта, зареден от CDN на трета страна, и скрипта за A/B тестове.
• Отказът трябва да е толкова лесен, колкото приемането. Същото ниво, същата видимост, същият брой кликвания. Регулаторите третират всичко друго като манипулативен дизайн (dark pattern) и са последователни в това.
• Съгласието е за всяка цел поотделно. Един превключвател за „анализ, маркетинг и персонализация“ не е конкретен.
• Оттеглянето е толкова лесно, колкото даването. Постоянна връзка или плаващ бутон, а не имейл до поддръжката.
• Пазете доказателството: времеви печат, низа за съгласие или състоянието на всяка категория, версията на банера и текста, който потребителят е видял. Без версията не можете да защитите запис за съгласие отпреди две години.

Прилагането тук не е теоретично. През септември 2025 г. френският орган за защита на данните глоби в един и същи ден Google с 325 милиона евро и Shein със 150 милиона евро заради практиките им с бисквитки. И двата случая се въртяха около механиката, а не около текста на политиката: бисквитки, поставени преди каквото и да е действие, и бутони за отказ, които всъщност не отказваха.

Правилата около това също се променят. Предложението на Комисията Digital Omnibus би преместило съгласието за крайното оборудване в самия ОРЗД и би направило сигналите на ниво браузър задължителни. Съветът върви в обратната посока: проектът му на преговорна позиция от 2 октомври 2026 г., според публикациите, запазва съгласието за бисквитки в член 5, параграф 3 от Директивата за правото на неприкосновеност на личния живот и електронни комуникации и премахва и двата нови члена в ОРЗД. Към 10 октомври 2026 г. Съветът още не беше приел тази позиция, а преговорите с Парламента не бяха започнали. Какво би променило предложението на Комисията, описахме в съгласието за бисквитки след Digital Omnibus.

Изградете механизма за правата на субектите на данни отрано

Членове 15 до 22 дават на хората право на достъп, коригиране, изтриване, ограничаване, преносимост и възражение. Имате един месец да отговорите, с възможност за удължаване до три при сложни случаи.

Екипите обикновено обработват първите няколко искания ръчно, което работи точно докато спре да работи. Какво ви трябва, доста преди да дойде обемът:

Механизъм, който намира човек във всички системи. По даден имейл адрес връща всичко: профила, поръчките, заявките към поддръжката, маркетинговия профил, идентификатора в анализа, логовете. Ако човек трябва да помни, че има платформа за отзиви на трета страна, която пази данни, някой рано или късно ще забрави.

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

Преносим експорт. Структуриран, широко използван, машинно четим. JSON е напълно приемлив. PDF на генерирана HTML страница не е.

Флаг за възражение, който цялата система чете. Възражението срещу профилиране трябва наистина да спре профилирането, включително в пакетната задача, която тръгва в 3 часа сутринта и не проверява флага.

Съхранението е задача, а не ред в политиката

Ограничението на съхранението е принципът, който най-често се нарушава от иначе добре изградени системи, защото изтриването на данни изисква някой да напише и насрочи задача, която никой не е поискал.

Дайте на всяка категория данни определен срок и после го реализирайте. Логовете за достъп, записите за сесии, изоставените колички, непотвърдените регистрации, затворените заявки към поддръжката, старите резервни копия и суровите данни от анализа се нуждаят от срок на изтичане. Резервните копия заслужават специално внимание: ако процесът ви за възстановяване връща изтрити лични данни, изтриването ви е непълно, а обичайният отговор е документирана ротация на резервните копия с максимална възраст плюс повторно прилагане на изтриванията след всяко възстановяване.

Предавания, подизпълнители и къде всъщност работи стекът ви

Предаванията извън ЕИП изискват правен механизъм, обикновено Рамката за защита на личните данни между ЕС и САЩ за сертифицирани получатели в САЩ или Стандартни договорни клаузи плюс оценка на въздействието на предаването в останалите случаи.

Инженерният ъгъл е по-прост от правния: знайте къде физически се намират данните ви. Това означава облачния регион на всяка услуга, местоположението на резервните копия, региона на управляваната ви база данни, конфигурацията на крайните точки на CDN и, което е важно, модела на поддръжка на всеки SaaS инструмент, който ползвате. Доставчик, хостван във Франкфурт, чийто екип по поддръжката влиза в продукционната среда извън ЕИП, пак е предаване.

По принцип препоръчваме личните данни да се пазят в региони в ЕС, когато няма сериозна причина за обратното. Това премахва цяла категория спорове, а разликата в цената обикновено е пренебрежима.

Поддържайте списък на подизпълнителите и го актуализирайте. Член 28 изисква писмено споразумение за обработване с всеки от тях, а списъкът е и това, което клиентите ви ще поискат при надлежната проверка.

Сигурност по подразбиране, изразена като конфигурация

Член 32 изисква подходящи технически и организационни мерки. Това е умишлено неясно, но минимумът за уебсайт през 2026 г. не е:

• TLS навсякъде, включен HSTS, без смесено съдържание.
• Пароли, хеширани със съвременна функция, интензивна по памет, и многофакторно удостоверяване, достъпно за профилите, които съдържат лични данни.
• Криптиране в покой на базите данни и резервните копия.
• Достъп до личните данни в продукционната среда, ограничен по роли и записван в лог, с прегледи, които наистина се правят.
• Псевдонимизация, където е възможно: хеширайте идентификатора в анализа, а таблицата за съответствие пазете отделно и с контрол на достъпа.
• Изпробвано възстановяване, а не само резервно копие.

Защитата на данните на етапа на проектирането и по подразбиране по член 25 означава, че вариантът, който пази поверителността, е този, който получавате, без да правите нищо. Полето за бюлетина е без отметка. Видимостта на профила е частна. Незадължителните полета са незадължителни.

Уведомяването за нарушения изисква наръчник

Седемдесет и два часа от узнаването до уведомяването на надзорния орган не са много, особено ако нарушението бъде открито в петък вечер. Имайте предвид, че предложението Digital Omnibus би удължило срока на деветдесет и шест часа, макар че още не е закон.

Подгответе се предварително: кой обявява инцидент, кой преценява дали са засегнати лични данни, кой се свързва с регулатора, какво съдържа уведомлението и как информирате засегнатите хора, ако рискът е висок. Напишете го като наръчник с посочени роли и го отрепетирайте веднъж. Първият път, когато го използвате, не бива да е първият път, когато го четете.

Самата повърхност на уебсайта

Част от ОРЗД се вижда на страницата и си струва подробностите да са точни, защото това са нещата, за които хората подават сигнали.

Уведомлението ви за поверителност трябва да посочва самоличността и данните за контакт на администратора, целите и правните основания, получателите и категориите получатели, механизмите за предаване, сроковете на съхранение, пълния списък с права, включително правото на жалба до надзорен орган, и дали има автоматизирано вземане на решения. Пишете го на език, който обикновеният човек може да следва. Многослойните уведомления, с кратка версия, водеща към подробностите, работят по-добре от стена от текст.

Формулярите трябва да събират само онова, което ви трябва. Всяко поле е обосновка, която може да се наложи да дадете. Ако полето за маркетингово съгласие е в същото изпращане като поръчката, то трябва да е отделно, без отметка и с отделен текст.

Вградените елементи от трети страни са тихият провал. YouTube в режим на подобрена поверителност, карти зад заместител, който се зарежда с кликване, шрифтове, хоствани при вас, вместо да се теглят от CDN на трета страна. Всяко от тези е малка промяна и всяко премахва по една констатация.

Какво най-често виждаме да се обърква

След достатъчно одити един и същ кратък списък продължава да се появява:

1. Анализът се зарежда преди съгласието, обикновено защото мениджърът на тагове е настроен от маркетинга и никога не е преглеждан от инженерите.
2. Бутоните за отказ въпреки това задействат съгласие заради поведението по подразбиране на скрипт на трета страна.
3. Изобщо няма задачи за изтриване по срок, на нито една таблица.
4. Изтриването пропуска резервните копия, логовете и CRM.
5. Уведомлението за поверителност описва поток от данни, който се е променил преди осемнадесет месеца.
6. Списъците с подизпълнители спират при трите очевидни доставчици.
7. Записите за съгласие нямат версия на текста, който е бил показан.

Нито едно от тези не е труден проблем. Просто е работа, която никой не е получил като задача.

Как да получите помощ

Ако искате втори поглед върху съществуващ сайт, правим технически одити по ОРЗД, които дават приоритизиран списък със задачи, а не доклад: какво да поправите, в какъв ред и с оценка за всяка точка. Ако изграждате нещо ново, значително по-евтино е моделът на данните и архитектурата на съгласието да са правилни от самото начало.

Покриваме и по-широкия набор от изисквания на ЕС, включително достъпността и навлизането на европейския пазар. Пишете ни на office@c9group.dev.

Ние изграждаме софтуер. Не даваме правни съвети и тълкуването на всяко конкретно изискване е работа на вашите юристи. Това, което можем да направим, е да гарантираме, че системата прави онова, което вашите юристи казват, че трябва.