GDPR за сайт и онлайн магазин: лични данни, бисквитки и технически изисквания

GDPR за сайт не започва с изтегляне на готова политика или инсталиране на банер за бисквитки. Започва с по-практичен въпрос: какви данни действително преминават през сайта, защо са нужни, кой ги получава и кога започва обработването им.

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

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

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

Как сайтът или онлайн магазинът обработва лични данни

Лични данни са не само име, телефон и имейл. В зависимост от контекста към тях могат да се отнасят IP адрес, идентификатор на устройство, клиентски номер, история на поръчки, адрес за доставка и информация, която позволява човек да бъде разпознат пряко или косвено.

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

За собственика на сайта най-полезно е да проследи целия път:

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

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

Започнете с карта на данните, не с готов шаблон

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

Картата на данните превръща общата тема в проверими въпроси. За всяка функция или инструмент запишете какво се събира, целта, получателите, момента на активиране, срока и отговорните лица.

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

Кога е нужно съгласие и кога има друго правно основание

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

Например данните, необходими за изпълнение на поръчка, обичайно не се обработват само защото клиентът е отбелязал поле "Съгласен съм". Магазинът има нужда от име, адрес и контакт, за да изпълни поисканата покупка. Част от информацията може да се пази и заради счетоводни или други законови задължения. Точната преценка обаче зависи от процеса и трябва да бъде направена от администратора с подходящ правен съвет.

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

Практичното правило е първо да разделите целите, а след това да определите основанието за всяка от тях:

• отговор на запитване;
• изпълнение на поръчка;
• създаване на клиентски профил;
• издаване и съхранение на счетоводни документи;
• изпращане на бюлетин;
• измерване на поведението;
• персонализирана реклама;
• защита от злоупотреби и техническа сигурност.

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

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

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

За всеки основен процес посетителят трябва да може да разбере:

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

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

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

Какво са бисквитките и кои не изискват съгласие

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

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

Изключението трябва да се прилага според реалната цел. Бисквитка не става строго необходима само защото е поставена в категория "Необходими". Ако се използва за измерване, профилиране или реклама, името и настройката в банера не променят поведението ѝ.

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

Кога аналитичните и рекламните технологии изискват предварителен избор

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

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

Проверете поне следните състояния:

1. Ново посещение без направен избор.
2. Приемане само на избрани категории.
3. Отказ на всички незадължителни категории.
4. Промяна на вече запазено решение.
5. Изтичане или обновяване на решението след промяна на доставчиците.

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

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

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

Добре работещият банер не е просто съобщение "Този сайт използва бисквитки". Той трябва да дава реален избор и технически да управлява незадължителните технологии.

Практичната конфигурация включва:

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

Отказът не трябва да се скрива зад дълга последователност от екрани. Докладът на EDPB Cookie Banner Taskforce разглежда проблеми като липса на реален отказ, предварително маркирани полета, подвеждащи визуални решения, неправилно класифицирани "необходими" бисквитки и затруднено оттегляне.

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

Контактни форми, бюлетини, резервации и регистрации

Формите са лесно видими, но често остават извън техническата проверка. Полетата, получателите, копията по имейл, записите в WordPress и връзките с външни системи трябва да бъдат описани поотделно.

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

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

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

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

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

Външно съдържание, карти, видео и социални мрежи

Вграденото съдържание изглежда като част от сайта, но често се зарежда от чужд домейн. Още преди човекът да пусне видео или да отвори карта, браузърът може да изпрати IP адрес, данни за устройството и адреса на посетената страница към доставчика.

Проверете отделно:

• видео платформи;
• интерактивни карти;
• публикации и бутони от социални мрежи;
• външни шрифтове;
• чат системи;
• антиспам и защита на формуляри;
• платежни полета, зареждани от външен домейн;
• инструменти за запис на сесии или топлинни карти.

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

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

Какво е различно при онлайн магазин

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

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

• поръчка като гост и поръчка с профил;
• автоматично създаване на клиентски акаунт;
• различен адрес за плащане и доставка;
• издаване на фактура;
• изоставена количка;
• напомняния и маркетингови съобщения;
• продуктови препоръки и профилиране;
• връщания, рекламации и обслужване;
• синхронизация със склад, ERP, CRM или счетоводство.

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

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

Поръчки, плащания, куриери и клиентски профили

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

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

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

Клиентският профил създава постоянен достъп до история, адреси и настройки. Затова са нужни:

• сигурно управление на паролата;
• ограничение на опитите за вход и защита според риска;
• подходящи роли и достъпи в администрацията;
• възможност за корекция на данните;
• работещ процес при искане за изтриване или ограничаване;
• ясно разграничение между данни, които могат да бъдат изтрити, и данни, които трябва да се пазят заради задължение или правен иск.

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

Външни доставчици, достъпи и предаване на данни

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

За всеки доставчик проверете:

• юридическото лице и услугата по договора;
• какви данни получава;
• за какви цели ги използва;
• ролята му спрямо конкретното обработване;
• има ли договорни клаузи за обработване;
• къде се намират данните и подизпълнителите;
• има ли предаване извън Европейското икономическо пространство;
• как се изтриват или връщат данните при прекратяване;
• как се съобщават инциденти и промени;
• какви административни и технически достъпи има.

Не приемайте, че доставчикът е "в Европа" само защото има европейски сайт или фактура. Проверете конкретната услуга, регионите за съхранение, подизпълнителите и механизмите за международно предаване.

Ограничете достъпа според ролята. Маркетинговият екип не трябва автоматично да има достъп до всички поръчки, а външен разработчик не трябва да използва постоянен администраторски профил след приключване на задачата. Временните достъпи трябва да бъдат отнети, а действията по критични системи да могат да се проследят.

Срокове за съхранение, права и сигурност

Срокът не трябва да бъде "безсрочно" по подразбиране. За всеки процес определете конкретен период или критерий: до приключване на запитването, докато профилът е активен, до отписване, за срока на договорно или счетоводно задължение или докато е необходимо за защита на правен иск.

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

Сайтът трябва да има работещ процес за искания относно:

• достъп до данните;
• корекция;
• изтриване;
• ограничаване на обработването;
• възражение;
• преносимост, когато е приложима;
• оттегляне на съгласие.

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

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

Кой носи правната и кой техническата отговорност

Собственикът на бизнеса обичайно определя защо и как се обработват данните и носи отговорността да може да докаже решенията си. Юристът помага да бъдат оценени основанията, текстовете, сроковете, договорите и специфичните рискове. Разработчикът реализира техническите изисквания и проверява дали системата се държи според заданието.

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

Най-надеждният модел е всяко изискване да има собственик, одобрен текст, техническа задача и тест за приемане. Така фразата "направете сайта по GDPR" се заменя с проверими резултати.

Защо банерът или разширението не гарантира съответствие

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

Най-честите несъответствия след инсталиране на банер са:

• скриптове се зареждат преди избора;
• част от кода е добавен извън системата за управление;
• технология е поставена в грешна категория;
• бутонът за отказ липсва или е трудно откриваем;
• оттеглянето не спира бъдещото обработване;
• политиката изброява различни инструменти от реалните;
• ново разширение е добавено без повторна проверка;
• банерът е преведен, но линковете или категориите не са актуализирани;
• записът на избора не съответства на показаната версия.

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

Съответствието е поддържан процес: описване, правна оценка, техническа реализация, тест, наблюдение и актуализация при промяна.

Практичен контролен списък преди пускане или промяна на сайта

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

Данни и цели

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

Правна оценка и информация

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

Техническа реализация

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

Тест и поддръжка

• Направен е тест при ново посещение без избор.
• Направен е тест при приемане само на отделна категория.
• Направен е тест при пълен отказ.
• Направен е тест при промяна и оттегляне на избора.
• Проверени са реалните мрежови заявки, не само видимите бисквитки.
• Определен е човек, който следи нови разширения, код и доставчици.
• Има дата за периодична повторна проверка.

Когато липсва информация за цел, основание, срок или доставчик, техническата работа трябва да спре на тази точка. Разработчикът не трябва да попълва правните решения по предположение, а собственикът не трябва да приема, че инсталирано разширение е завършена GDPR проверка.

SeoWebDesign може да реализира и тества технически одобрени изисквания при изработка на сайт или онлайн магазин. Правните текстове и преценката за конкретния бизнес трябва да бъдат предоставени или проверени от подходящ правен специалист.

Официални източници

• EUR-Lex - Общ регламент относно защитата на данните
• Your Europe - защита на данните съгласно GDPR
• Your Europe - бисквитки и онлайн поверителност
• EUR-Lex - Директива 2002/58/ЕО за неприкосновеността в електронните комуникации
• EDPB - Насоки 05/2020 относно съгласието
• EDPB - доклад на работната група за банерите за бисквитки
• EDPB - защита на данните на етапа на проектиране и по подразбиране
• КЗЛД - бързо ръководство за спазване на GDPR
• КЗЛД - специфични насоки за различни сектори