Накратко: Който трябва или иска да уведоми клиентите след изтичане на данни, първо решава с длъжностното лице по защита на данните и с адвокат дали съществува задължение по чл. 34 ОРЗД, и изяснява дали бизнес клиентите са самите администратори. След това следват групите клиенти, сигурните канали, подготвено обслужване на клиенти и заключително съобщение. Съобщенията не съдържат връзки за вход, за да не се превърнат в образец за фишинг. Тази страница е обща информация и не е правен съвет.
Имейлът, от който всички се страхуват
Сървърът е почистен, уязвимостта е затворена, форензиката има първи резултати. Сега на масата стои въпрос, който много управители биха предпочели да избегнат: трябва ли да кажем на клиентите си? И ако да, как, без да причиним повече щети от самия инцидент?
Положението около PHP2Shell постави този въпрос наново пред много фирми, дори без проникване. Уебсайтове бяха предпазно офлайн, клиенти питаха, а измамниците според опита използват такива ситуации за фалшиви съобщения. Как по принцип е изградена кризисната комуникация, в какъв ред и с какво съдържание, описва Кризисна комуникация след атака. Този материал стига една стъпка по-дълбоко: решението, групите клиенти и практическото изпълнение.
Уведомяване на клиентите след изтичане на данни: задължение или решение?
Чл. 34 ОРЗД изисква засегнатите лица да бъдат уведомени без излишно забавяне, когато нарушение на сигурността на личните данни вероятно води до висок риск за техните права и свободи. Уведомяването описва естеството на нарушението на ясен и прост език и съдържа най-малко лице за контакт, вероятните последици и предприетите или планирани мерки.
Чл. 34, пар. 3 посочва изключения: когато данните са недостъпни за неоправомощени лица, например поради криптиране, когато последващи мерки вероятно премахват високия риск или когато уведомяването би изисквало несъразмерно усилие; тогава на негово място излиза публично съобщение. Дали някое от тези изключения е приложимо, е правна оценка за конкретния случай. Тя принадлежи на длъжностното лице по защита на данните и на адвоката, както и уведомяването на надзорния орган, вижте Задължение за уведомяване по ОРЗД: 72 часа след инцидента.
И без задължение информацията може да има смисъл. Клиентите, които научават за инцидента от друг източник, губят доверие по-бързо от тези, които го чуват от Вас.
Остава въпросът за момента. Който информира твърде рано, може да се наложи да поправя твърдения. Който чака твърде дълго, рискува междувременно клиентите да понесат щети, например от фишинг с изтекли адреси. Доказан среден път: да се съобщи рано какво е установено и какво клиентите могат да направят сами, и изрично да се обяви, че ще последва още информация. „Без излишно забавяне“ по смисъла на чл. 34 не означава да се чака краят на проучването.
Кои клиенти как да достигнете
Не всички клиенти се нуждаят от едно и също съобщение. Разграничавайте поне три групи:
| Група клиенти | Вашата роля | Какво означава за информирането |
|---|---|---|
| Частни клиенти с акаунт или поръчка | обикновено администратор | да се прецени уведомяване по чл. 34, разбираем език, конкретни препоръки |
| Бизнес клиенти, чиито данни използвате за собствени цели | обикновено администратор | обективна информация до посочени лица за контакт, класифициране за техните собствени задължения |
| Бизнес клиенти, за които обработвате данни по поръчка | обработващ лични данни | уведомяване без излишно забавяне по чл. 33, пар. 2, подкрепа за техните уведомявания |
Третата група често се пропуска. Ако например поддържате магазини или портали за клиенти, те по правило са самите администратори и трябва да изпълнят собствените си задължения за уведомяване. За това им е нужна Вашата информация бързо и пълно.
Избор на канали, без да насърчавате фишинга
Най-сигурният канал е този, който клиентите вече познават. Доказали са се:
- Имейл от обичайния адрес на подателя, без връзки за вход и без прикачени файлове, с указание да отворят уебсайта сами.
- Съобщение след влизане в клиентския акаунт, щом системата отново работи сигурно.
- Съобщение на уебсайта, като публично допълнение или, където чл. 34, пар. 3 го предвижда, като публично съобщение.
- Писмо за клиенти без актуален имейл адрес или при особено чувствителни данни.
- Телефон и обслужване на клиенти като звено за допълнителни въпроси, с номер, който клиентите вече познават от Вашия уебсайт или фактура.
Посочвайте във всяко съобщение изрично, че никога не питате по имейл или телефон за пароли, кодове или платежни данни. След известни инциденти измамниците с удоволствие изпращат съобщения, които изглеждат като Вашите.
От решението до заключителното съобщение
Така може да изглежда редът на практика:
- Запишете фактите: какво е доказано, какво вероятно, какво неизвестно. Навън излиза само доказаното.
- Получете правна оценка: задължение по чл. 34, роля спрямо бизнес клиентите, съгласуване с уведомяването на органа.
- Определете групите клиенти и каналите, вземете списъка с получатели от собствената система, а не от евентуално манипулирано копие.
- Подгответе обслужването на клиенти: вътрешни въпроси и отговори, ясна езикова рамка, препращане на трудните случаи към определено звено.
- Формулирайте препоръки за клиентите: например смяна на паролата, ако е възможно да са засегнати данни за достъп, и внимание към подозрителни съобщения.
- Изпратете и документирайте: кой кога по кой канал е бил информиран.
- Допълвайте: съобщавайте новите открития и изпратете заключително съобщение, когато проучването приключи.
Който е определил предварително вътрешно пътищата за контакт, спестява много време при това, вижте Контакти за извънредни ситуации: кого и кога трябва да уведомим?. Техническите стъпки, които трябва да предшестват информирането, обобщава Контролният списък след хакване.
Как помага PHP SOS конкретно?
- Предоставяме техническите факти за инцидента така подготвени, че длъжностното лице по защита на данните и адвокатът да могат да оценят задълженията.
- Проверяваме Вашите съобщения до клиентите за техническа точност и за това да не дават на нападателите насоки.
- Гарантираме, че списъците с получатели и клиентските акаунти идват от почистена система, преди да изпратите.
- Чрез Incident Response предоставяме данните за последващи и заключителни съобщения в договорения ритъм.
Извод: Доброто информиране на клиентите е правно проверено, разделено по групи, изпратено по сигурни канали и доведено докрай. Тази страница е обща информация и не е правен съвет; решението за конкретния случай вземате с длъжностното лице по защита на данните и с адвокат.
Често задавани въпроси
Кога трябва да уведомя клиентите след изтичане на данни?
По чл. 34 ОРЗД, когато нарушението вероятно води до висок риск за правата и свободите на засегнатите лица. Има изключения, например при ефективно криптиране на данните. Оценката правите с длъжностното лице по защита на данните и с адвокат; тази страница не е правен съвет.
Какво важи, ако обработвам данни по поръчка на бизнес клиентите си?
Тогава Вашите клиенти обикновено са самите администратори на лични данни. Според чл. 33, пар. 2 ОРЗД обработващият лични данни уведомява администратора без излишно забавяне, след като е узнал за нарушението. Уведомяването на органа и на засегнатите остава работа на Вашия клиент.
Мога ли да уведомя клиентите, макар да няма задължение?
Да. Доброволната информация може да има смисъл, например когато уебсайтът е бил предпазно офлайн заради PHP2Shell или клиентите задават въпроси. Важно е да се посочват само установени факти и да не се дава прибързан отбой.
Как да попреча на измамниците да имитират моето съобщение?
Откажете се в съобщението от връзки за вход и от прикачени файлове, насочете към Вашия известен уебсайт и посочете изрично по кои пътища никога не питате за пароли или платежни данни.