GDPR усогласеност за сајтови: што навистина треба да се изгради

Повеќето совети за GDPR на интернет се напишани за правници или за оние што купуваат генератор на политики. Многу малку е напишано за лицето што мора да отвори уредувач и да смени нешто.

Овој водич е од вториот вид. Поминува низ тоа што Општата уредба за заштита на податоците бара од еден сајт и системите зад него, изразено како работи што ги градите, конфигурирате или бришете. Ја вршиме оваа работа за компании во ЕУ откако уредбата почна да се применува во 2018, а образецот на тоа што тргнува наопаку речиси не се променил.

Една забелешка на почетокот: GDPR не стана полесен затоа што дојдоа понови прописи. Стана поважен, бидејќи речиси сè во сегашниот бран дигитални правила на ЕУ претпоставува дека вашите лични податоци се веќе средени.

Почнете со чесен попис на податоци

Речиси секој неуспешен GDPR проект што сме го наследиле пропаднал на истото место. Тимот прво ја напишал политиката, а податоците ги открил подоцна.

Пред сè друго, мапирајте кои лични податоци вашиот сајт навистина собира. Не она што го вели спецификацијата на производот. Она што е во базата, логовите, аналитичката платформа, CRM, алатката за поддршка, маркетиншкиот стек, следачот на грешки, CDN логовите и скриптите од трети страни на страницата.

Во практика тоа значи:

• Да ја прочешлате шемата. Секоја колона што би можела да идентификува лице, самостојно или во комбинација со друга.
• Да го прочитате мрежниот таб при вистинско вчитување на страницата. Секое појдовно барање кон домен што не го контролирате е потенцијален пренос на лични податоци, бидејќи IP адреса плус user agent се лични податоци.
• Да проверите што фаќа следачот на грешки. Трагите на стекот рутински содржат имејл адреси, токени и тела на барања.
• Да го проверите чувањето на логовите. Логовите за пристап со IP адреси чувани засекогаш се едно од најчестите наоди и едно од најлесно поправливите.

Запишете го тоа како евиденција на активности на обработка. Член 30 така или така го бара тоа од повеќето организации, а верзијата корисна за програмери е табела со систем, податоци, цел, правен основ, рок на чување и приматели.

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

Член 6 дава шест правни основи. Најчестата грешка е да се избере еден за целиот производ.

Речиси сигурно имате повеќе цели што течат истовремено. Извршувањето на нарачка е договор. Проверките за измама обично се легитимен интерес или законска обврска. Чувањето фактури законски рок е законска обврска. Маркетинг имејлот е согласност во повеќето земји членки. Неесенцијалната аналитика е согласност, поради ePrivacy правилата за пристап до терминална опрема, а не поради самиот GDPR.

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

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

Ако се потпирате на согласност, таа мора да биде доброволна, конкретна, информирана и недвосмислена, а вие мора подоцна да умеете да ја докажете.

Конкретно:

• Ништо неесенцијално не се активира пред корисникот да преземе дејство. Тоа вклучува аналитички исечок, рекламен пиксел, чет виџет, фонт од CDN на трета страна и скрипта за A/B тестирање.
• Одбивањето мора да биде исто толку лесно како прифаќањето. Ист слој, иста истакнатост, ист број кликови. Регулаторите сè друго го третираат како мрачен образец и во тоа се доследни.
• Согласноста е по цел. Едно прекинувалче што опфаќа „аналитика и маркетинг и персонализација" не е конкретно.
• Повлекувањето е исто толку лесно како давањето. Траен линк или лебдечко копче, не имејл до поддршката.
• Зачувајте го доказот: временска ознака, стрингот на согласност или состојбата на секоја категорија, верзијата на банерот и текстот прикажан на корисникот. Без верзијата не можете да одбраните двегодишен запис за согласност.

Спроведувањето овде не е теоретско. Во септември 2025 францускиот орган истиот ден го казни Google со 325 милиони евра и Shein со 150 милиони за практики со колачиња. И двата случаи се однесуваа на механиката, а не на текстот на политиката: колачиња поставени пред каква било интеракција и копчиња за одбивање што всушност не одбивале.

И правилата се во движење. Предлогот Digital Omnibus би ја пренел согласноста за терминална опрема во самиот GDPR и би ги направил сигналите на прелистувачот обврзувачки. Што би се променило опишавме во согласност за колачиња по Digital Omnibus.

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

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

Тимовите првите барања обично ги решаваат рачно, што работи точно до моментот кога престанува. Што треба да имате многу пред да пристигне обемот:

Разрешувач што наоѓа лице низ сите системи. За дадена имејл адреса да врати сè: сметката, нарачките, тикетите за поддршка, маркетиншкиот профил, аналитичкиот идентификатор, логовите. Ако човек мора да помни дека постои и платформа за оценки од трета страна со податоци, некој еднаш ќе заборави.

Патека за бришење што ги почитува обврските за чување. Бришењето не е апсолутно. Фактурите обично мораат да преживеат од даночни причини. Ви треба меко бришење со тврдо бришење врзано за целта, за да го отстраните маркетиншкиот профил задржувајќи го сметководствениот запис и за тој запис сам да истече навреме.

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

Знаменце за приговор што го чита целиот систем. Приговорот на профилирање мора навистина да го запре профилирањето, вклучувајќи го и пакетниот процес што работи во три наутро и не го проверува знаменцето.

Чувањето е работа, а не ред во политика

Ограничувањето на чувањето е начелото што најчесто го кршат инаку добро изградени системи, бидејќи бришењето бара некој да напише и закаже задача што никој не ја бара.

Дајте му на секоја категорија податоци дефиниран век, па спроведете го тоа. Логовите за пристап, сесиите, напуштените кошнички, непотврдените регистрации, затворените тикети, старите резервни копии и суровите аналитички податоци сите треба да имаат рок на истек. Резервните копии заслужуваат посебно внимание: ако вашиот процес на враќање ги оживува избришаните лични податоци, вашето бришење е нецелосно, а вообичаениот одговор е документирана ротација на резервни копии со максимална старост плус повторна примена на бришењата по секое враќање.

Преноси, подобработувачи и каде навистина работи вашиот стек

Преносите надвор од ЕЕП бараат правен механизам, обично рамката ЕУ и САД за заштита на податоците за сертифицирани американски приматели или стандардни договорни клаузули плус проценка на влијанието на преносот во останатите случаи.

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

Општо препорачуваме личните податоци да се држат во ЕУ региони кога нема силна причина за спротивното. Тоа отстранува цела категорија расправа, а разликата во цената обично е шум.

Водете список на подобработувачи и одржувајте го ажурен. Член 28 бара писмен договор со секој, а тој список е и она што вашите клиенти ќе го побараат при длабинска анализа.

Безбедност стандардно, изразена како конфигурација

Член 32 бара соодветни технички и организациски мерки. Тоа е намерно нејасно, но основата за сајт во 2026 не е предмет на преговори:

• TLS насекаде, HSTS вклучен, без мешана содржина.
• Лозинки хеширани со современа мемориски барана функција и повеќефакторска автентикација достапна за сметки со лични податоци.
• Енкрипција во мирување за бази и резервни копии.
• Пристапот до продукциски лични податоци ограничен по улога и логиран, со прегледи што навистина се случуваат.
• Псевдонимизација каде што е можна: хеширање на идентификаторот во аналитиката, табелата за мапирање одвоено и со ограничен пристап.
• Тестирано враќање, а не само резервна копија.

Заштитата на податоците по дизајн и стандардно од член 25 значи дека опцијата што ја штити приватноста е онаа што ја добивате без да направите ништо. Полето за билтен неозначено. Видливоста на профилот приватна. Опционите полиња опциони.

Пријавата на повреди бара прирачник

Седумдесет и два часа од дознавањето до пријавата до надзорниот орган не е многу, особено ако повредата се открие во петок навечер. Предлогот Digital Omnibus би го поместил тоа на деведесет и шест часа, но тоа сè уште не е право.

Подгответе однапред: кој прогласува инцидент, кој проценува дали се засегнати лични податоци, кој контактира со регулаторот, што содржи пријавата и како ги известувате засегнатите ако ризикот е висок. Напишете го тоа како прирачник со именувани улоги и вежбајте еднаш. Првото користење не треба да биде првото читање.

Површината на самиот сајт

Дел од GDPR е видлив на страницата и вреди тие детали да се средат, бидејќи токму нив ги пријавуваат луѓето.

Вашето известување за приватност мора да го наведе идентитетот и контактот на контролорот, целите и правните основи, примателите и категориите приматели, механизмите за пренос, роковите на чување, целосниот список права вклучувајќи го правото на жалба до надзорен орган и дали постои автоматизирано одлучување. Пишувајте на јазик што обичен човек може да го следи. Слоевитите известувања, со кратка верзија што води до детали, работат подобро од ѕид текст.

Формуларите треба да собираат само она што ви треба. Секое поле е оправдување што можеби ќе морате да го дадете. Ако полето за маркетиншка согласност е во истото испраќање како нарачката, мора да биде одделно неозначено и одделно формулирано.

Вградените содржини од трети страни се тивката грешка. YouTube во режим на подобрена приватност, мапи зад чувар што се вчитува на клик, фонтови хостирани кај вас наместо од CDN на трета страна. Секоја од овие измени е мала и отстранува еден наод.

Што најчесто гледаме дека не чини

По доволно проверки, се појавува истиот краток список:

1. Аналитика што се вчитува пред согласност, обично затоа што tag manager го поставил маркетингот, а инженерството никогаш не го прегледало.
2. Копчиња за одбивање што сепак активираат согласност поради стандардното однесување на скрипта од трета страна.
3. Никакви задачи за чување, на ниту една табела.
4. Бришење што ги пропушта резервните копии, логовите и CRM.
5. Известување за приватност што опишува тек на податоци сменет пред осумнаесет месеци.
6. Списоци на подобработувачи што застануваат кај трите очигледни добавувачи.
7. Записи за согласност без верзијата на прикажаниот текст.

Ништо од ова не е тежок проблем. Тоа е едноставно работа што никој не ја доделил.

Како до помош

Ако сакате втор пар очи на постоечки сајт, правиме технички GDPR проверки што даваат приоритетен список задачи наместо извештај: што да се поправи, по кој редослед, со проценка кај секоја ставка. Ако градите нешто ново, значително е поевтино моделот на податоци и архитектурата на согласности веднаш да се постават добро.

Ја покриваме и пошироката површина на усогласеност со ЕУ, вклучувајќи ја пристапноста и влезот на европскиот пазар. Нè наоѓате на office@c9group.dev.

Градиме софтвер. Не даваме правни совети, а толкувањето на конкретно барање им припаѓа на вашите правници. Она што можеме е да обезбедиме системот да го прави тоа што го велат вашите правници.