72-часов наръчник по GDPR за нарушения на сигурността на личните данни за директори по информационна сигурност
Във вторник в 2:13 ч. през нощта се задейства алармата.
Мария, директор по информационна сигурност (CISO) на бързо растяща финтех SaaS платформа, се събужда от ескалация от SOC: аномални заявки към базата данни идват от акаунт на разработчик. Акаунтът е достъпил таблици, съдържащи имена на клиенти, имейли, истории на трансакции и национални идентификационни номера. В рамките на минути екипът потвърждава, че удостоверителните данни на разработчика са били откраднати при фишинг атака. Прозорецът на експозиция е неясен. Намерението на нападателя е неизвестно. Обхватът на въздействието все още се изчислява.
Срокът започва да тече сега.
За GDPR Мария може да разполага със 72 часа, за да уведоми надзорен орган, ако има вероятност инцидентът да породи риск за физическите лица. За NIS2, ако дружеството е съществен или важен субект и инцидентът е значителен, може да е необходимо ранно предупреждение в рамките на 24 часа и официално уведомяване в рамките на 72 часа. За DORA може да са приложими и задължения за докладване на ИКТ инциденти във финансовия сектор и задължения за оперативна устойчивост. Клиенти, застрахователи, правен консултант, висше ръководство и одитори ще очакват отговори.
Това е моментът, в който общият план за реагиране при инциденти често се проваля. Наръчник за реагиране при зловреден софтуер може да обясни как се изолира хост. Процедура на SOC може да описва запазването на журнали. Но процесът за управление на нарушения на сигурността на личните данни по ISO/IEC 27701:2025 трябва да отговори под натиск на по-трудни въпроси:
- Били ли са лични данни изложени, променени, загубени, унищожени или достъпени без разрешение?
- Действа ли организацията като администратор, обработващ лични данни, съвместен администратор или подизпълнител по обработване?
- Кога е настъпило узнаването и кои доказателства го потвърждават?
- Изисква ли се регулаторно уведомяване съгласно GDPR Article 33?
- Изложени ли са засегнатите физически лица на висок риск съгласно GDPR Article 34?
- Ако организацията действа като обработващ лични данни, колко бързо трябва да бъде уведомен администраторът?
- Кои доказателства ще подкрепят решението шест месеца по-късно по време на одит?
Разликата между хаос и контрол не е броят на инструментите за сигурност в технологичния стек. Разликата е дали организацията е изградила дисциплинирана система за управление на информацията за поверителността, или PIMS, която свързва реагирането при инциденти, управлението на поверителността, обработването на доказателства, ескалацията към доставчици и регулаторното докладване в един защитим жизнен цикъл.
Управлението на нарушения започва преди някой да каже „нарушение“
Първата оперативна грешка е допускането, че управлението на нарушения на сигурността на личните данни започва едва след като правният екип потвърди нарушение на сигурността на личните данни. В действителност процесът започва, когато лице, система, доставчик или клиент забележи нещо, което може да включва лични данни.
Zenith Blueprint: 30-стъпкова пътна карта за одитора на Clarysec Zenith Blueprint поставя този човешки тригер във фазата „Контроли в действие“, Стъпка 16: Контроли за персонала II. Ръководството посочва:
„Ефективната система за реагиране при инциденти започва не с инструменти, а с хора. Control 6.8 подчертава значението на това всеки служител, външен изпълнител или заинтересована страна да знае как да разпознава и докладва потенциален инцидент по сигурността и да се чувства в безопасност и овластен да го направи.“
Това е важно, защото много инциденти, свързани с поверителността, не се откриват първо от SIEM. Те започват със служител по поддръжката, който вижда прикачен файл на друг клиент; служител по работни заплати, който забелязва погрешно изпратена електронна таблица; клиент, който докладва фактура на друг потребител; или доставчик, който докладва изгубен лаптоп.
Политика за защита на данните и поверителност за МСП Data Protection and Privacy Policy-sme, раздел „Прилагане и съответствие“, клауза 8.3.1, превръща това в незабавно задължение:
„Всички нарушения на сигурността на личните данни или подозирани инциденти трябва да бъдат докладвани незабавно на Координатора по поверителност“
За корпоративни програми Политика за защита на данните и поверителност Data Protection and Privacy Policy, раздел „Прилагане и съответствие“, клауза 8.3.2, възлага ръководството:
„Длъжностното лице по защита на данните (DPO) ръководи ограничаването, анализа и ескалацията на нарушенията в съответствие с ISO/IEC 27035 и GDPR Articles 33 and 34.“
Това е преходът от „ИТ проверява случая“ към „активиран е жизненият цикъл на PIMS за нарушения“.
Първата точка на натиск: събитие, инцидент по сигурността, инцидент с поверителността или нарушение на сигурността на личните данни
В 2:13 ч. екипът на Мария има аларма. Все още няма потвърдено нарушение, подлежащо на уведомяване. Първото критично решение е класификацията.
Zenith Blueprint, фаза „Контроли в действие“, Стъпка 23: Организационни контроли, обяснява ISO/IEC 27002:2022 control 5.25, оценка и решение относно събития по информационна сигурност:
„Не всяка аномалия е бедствие. Не всяка аларма означава компрометиране. В реалната среда екипите по сигурност и бизнес звената са залети от шум: опити за вписване, аномалии в журналите, незначителни нарушения на политиките, дейности по неуправлявани ИТ извън одобрените процеси. Истинското предизвикателство не е само в откриването, а в разграничаването на безвредното от вредното и в знанието кое изисква ескалация.“
Жизненият цикъл при нарушение на поверителността трябва да прави това разграничение повторяемо. Той не трябва да зависи от това кой е дежурен, кой юрист се включва първи или дали CISO се чувства комфортно при несигурност.
Практическият класификационен модел на Clarysec разделя четири етапа:
| Етап на класификация | Въпрос | Типичен собственик | Необходими доказателства |
|---|---|---|---|
| Събитие | Случило ли се е нещо необичайно? | Сервизно бюро, SOC, бизнес собственик | Билет, доклад, аларма, имейл, извлечение от журнал |
| Инцидент по сигурността | Застрашило или компрометирало ли е събитието информационната сигурност? | Координатор по реагиране при инциденти | Билет за инцидент, бележки от триаж, засегнати системи |
| Инцидент с поверителността | Може ли събитието да включва лични данни или задължения, свързани с поверителността? | Ръководител по поверителността или DPO | Категории лични данни, субекти на данни, роля при обработването |
| Потвърдено или подозирано нарушение на сигурността на личните данни | Били ли са лични данни изложени, загубени, променени, унищожени или достъпени неправомерно или случайно? | DPO, ръководител по поверителността, правен отдел, бизнес собственик | Оценка на риска, решение за уведомяване, регистър на доказателствата |
Думата „подозирано“ е съществена. Clarysec не препоръчва да се изчаква пълна сигурност, преди да се отвори работният поток за нарушение на поверителността. Регистърът на нарушенията трябва да се отвори, когато нарушение на сигурността на личните данни е разумно подозирано, след което да се актуализира с развитието на фактите.
Политика за управление на инциденти и нарушения на сигурността на личните данни PII Incident and Breach Management Policy, раздел „Класификация и оценка на нарушението“, клауза 4.2.3, изисква администраторите да документират решението преди външно действие:
„[Администратор] Длъжностното лице по защита на данните / Съветникът по поверителност ТРЯБВА да оцени риска за засегнатите субекти на данни за всяко потвърдено или разумно подозирано нарушение на сигурността на личните данни и да запише препоръката за уведомяване, обосновката на риска и становището в REG10 преди вземане на решението за външно уведомяване.“
Тази клауза е оперативното ядро на готовото за одит реагиране при нарушения по GDPR: оценете риска, запишете обосновката, документирайте становището, вземете решение и запазете доказателствата в REG10.
72-часовият срок е доказателствен проблем, не календарно напомняне
Много екипи третират 72-часовото изискване за уведомяване по GDPR като срок в проектен план. При реален инцидент трудната част е да се докаже кога е настъпило узнаването, какво е било известно към този момент, колко бързо е действала организацията и защо решението за уведомяване е било разумно.
Политика за реагиране при инциденти за МСП Incident Response Policy-sme, раздел „Цел“, клауза 1.2, формулира целта:
„Тази политика позволява на организацията да минимизира вредите, да защити клиентските данни и да изпълни регулаторни задължения, като 72-часовото изискване по GDPR за уведомяване при нарушение на сигурността на личните данни.“
Политика за защита на данните и поверителност за МСП, раздел „Прилагане и съответствие“, клауза 8.3.3, посочва:
„Когато се изисква, уведомяването на органите и засегнатите физически лица трябва да се извърши в рамките на 72 часа“
За корпоративни програми Политика за защита на данните и поверителност, раздел „Прилагане и съответствие“, клауза 8.3.3, посочва:
„Нарушенията, които достигат законовия праг за уведомяване, се докладват на надзорните органи в рамките на 72 часа.“
Целта не е да се уведомява за всяка аномалия. Целта е достатъчно бързо да се вземе защитимо решение, така че необходимото уведомяване да може да се извърши навреме. Зрялата PIMS следователно използва вътрешни срокове, които са по-кратки от външните законови срокове.
| Време от узнаването | Действие в PIMS | Доказателства за записване в REG10 |
|---|---|---|
| 0 до 4 часа | Отваряне на запис за инцидент с лични данни, определяне на собственик, запазване на първоначални доказателства, идентифициране на ролята при обработването | Входящ доклад, времеви маркер на узнаването, възложени роли, първоначално засегнати системи и данни |
| 4 до 12 часа | Ограничаване на експозицията, идентифициране на категории лични данни, определяне на задълженията като администратор или обработващ лични данни | Действия по ограничаване, засегнати типове данни, оценка на ролята, зависимости от доставчици или клиенти |
| 12 до 24 часа | Извършване на предварителна оценка на риска и решение дали е вероятно уведомяване на надзорен орган | Обосновка на риска, вероятно въздействие, несигурност, становище на DPO, правен принос |
| 24 до 48 часа | Подготовка на уведомление или обосновка за неуведомяване, координиране на комуникации с клиенти или администратори | Проект на уведомление, журнал на решенията, одобрения, уведомления до клиенти, препратки към доказателства |
| 48 до 72 часа | Подаване на изискваното уведомление, документиране на обосновка за забавяне при необходимост, подготовка на комуникация до физическите лица при висок риск | Доказателства за подаване, референтен номер от регулатора, окончателно решение, комуникационен план |
| След 72 часа | Продължаване на разследването, актуализиране на регулатора при необходимост, уведомяване на физическите лица, когато се изисква, завършване на извлечените поуки | Последващи доклади, коригиращи действия, одобрение за приключване, списък с подобрения |
Политика за управление на инциденти и нарушения на сигурността на личните данни, раздел „Уведомяване и комуникации“, клауза 4.4.1, прави изискването за документация изрично:
„[Администратор] Ръководителят по поверителността / Мениджърът на PIMS ТРЯБВА да изготви документирано решение за регулаторно уведомяване за всяко потвърдено нарушение на сигурността на личните данни без ненужно забавяне и в рамките на вътрешен срок, който поддържа приложимите външни срокове за уведомяване, и ТРЯБВА да съхрани уведомлението, обосновката за неуведомяване или обосновката за забавяне в REG10.“
Регулатор може да оспори решение. Одитор може да провери дали процесът е бил следван. Но ако организацията може да покаже навременни доказателства, структурирани критерии, становище на DPO и документирана обосновка, тя е в много по-силна позиция от екип, който казва: „Обсъдихме го в разговор.“
Администраторите и обработващите лични данни се нуждаят от различни пътища при нарушение
Съвременните SaaS компании често работят в повече от една роля във връзка с поверителността. Финтех платформата на Мария може да бъде администратор за своите преки абонати и обработващ лични данни за корпоративни клиенти. В друг сценарий B2B портал за поддръжка може да бъде обработващ лични данни за клиентски прикачени файлове към билети, но администратор за собствените си вътрешни метаданни за поддръжка.
Това разграничение променя пътя за уведомяване.
| Задължение | Роля на администратор на лични данни | Роля на обработващ лични данни |
|---|---|---|
| Основно задължение | Към надзорния орган и засегнатите физически лица, когато праговете са достигнати | Към засегнатия администратор или клиент |
| Адресат на уведомяването | Съответният надзорен орган и, при висок риск, засегнатите физически лица | Клиентът или администраторът, посочен в договора |
| Тригер за уведомяване | Риск за правата и свободите на физическите лица | Узнаване за нарушение, засягащо клиентски лични данни |
| Срок | Без ненужно забавяне и, когато е възможно, в рамките на 72 часа след узнаването | Без ненужно забавяне и в рамките на договорните срокове, често 24 или 48 часа |
| Оценка на риска | Трябва да оцени риска за физическите лица и да вземе решение за уведомяване по Article 33 и 34 | Предоставя факти, за да може администраторът да оцени риска |
За обработващите лични данни Политика за управление на инциденти и нарушения на сигурността на личните данни, раздел „Уведомяване и комуникации“, клауза 4.4.4, посочва:
„[Обработващ лични данни] Ръководителят по поверителността / Мениджърът на PIMS ТРЯБВА да уведоми засегнатия администратор или клиент без ненужно забавяне и в рамките на всеки приложим договорен срок след узнаване за нарушение на сигурността на личните данни, засягащо клиентски лични данни, и ТРЯБВА да записва първоначалните и последващите уведомления в REG08 и REG10.“
Обработващият лични данни не трябва да изчаква завършването на анализа на риска по GDPR от администратора. Той трябва да уведоми администратора с наличните факти и да предоставя актуализации с напредването на разследването. След това администраторът взема решение за уведомяване на надзорния орган и за комуникация със засегнатите физически лица за своето обработване.
При въздействия с висок риск за физическите лица администраторът трябва да оцени и директната комуникация. Политика за управление на инциденти и нарушения на сигурността на личните данни, клауза 4.4.3, посочва:
„[Администратор] Ръководителят по поверителността / Мениджърът на PIMS ТРЯБВА да координира комуникацията със засегнатите субекти на данни, когато оценката на нарушението установи висок риск или еквивалентен тригер за комуникация, и ТРЯБВА да запише съдържанието на комуникацията, аудиторията, времето, метода на доставяне и доказателствата за одобрение в REG10.“
Корпоративната Политика за защита на данните и поверителност, раздел „Прилагане и съответствие“, клауза 8.3.4, засилва това изискване:
„Ако бъде установен висок риск за физическите лица, засегнатите субекти на данни се уведомяват без ненужно забавяне, освен ако е приложимо изключение (напр. въведено е силно шифроване).“
Това изключение трябва да бъде основано на доказателства. Твърдението „данните бяха шифровани“ не е достатъчно. Организацията трябва да докаже, че изложените данни са били нечетими за неоторизирани страни и че съответните ключове не са били компрометирани.
Доставчиците могат да предопределят първите 24 часа
Трети страни често държат фактите, необходими за класификация и уведомяване. Доставчик на облачни услуги може да държи журнали за достъп. Обработващ лични данни за работни заплати може да знае кои служители са засегнати. Доставчик на управлявани услуги може да е извършил промяната в конфигурацията. Подизпълнител по обработване може да държи форензична телеметрия.
Затова условията за нарушения в договорите с доставчици трябва да бъдат проектирани преди инцидента.
Политика за сигурност на трети страни и доставчици Third party and supplier security policy, раздел „Изисквания за управление“, клауза 5.3.3, включва договорно управление върху:
„Срокове за уведомяване при нарушение (напр. в рамките на 24 или 72 часа, в зависимост от критичността и регулаторните изисквания)“
За по-малки организации Политика за сигурност на трети страни и доставчици за МСП Third-Party and Supplier Security Policy-sme по сходен начин поддържа срокове за уведомяване при нарушения в управлението на доставчици.
Clarysec препоръчва договорите с доставчици и споразуменията за обработване на лични данни да дефинират:
- Какво представлява подозирано нарушение на сигурността на личните данни
- Кой трябва да бъде уведомен и по кой канал
- Първоначален срок за уведомяване, често по-кратък от регулаторния срок на администратора
- Минимални факти, необходими в първото уведомление
- Честота на актуализациите по време на разследването
- Задължения за запазване на доказателства
- Прехвърляне на задълженията за уведомяване към подизпълнители по обработване
- Подкрепа за комуникации с регулатор и субекти на данни
- Задължения за коригиращи действия след инцидент
Ако споразуменията с доставчици използват неясни изрази като „възможно най-скоро“, срокът по GDPR за администратора може да зависи от вътрешния дебат на друга организация. Това не е защитим оперативен модел.
Доказателствата превръщат реагирането в защитимо съответствие
По време на инцидента на Мария екипът се нуждае от журнали за автентикация, записи на заявки към базата данни, доказателства за фишинг, промени в контрола на достъпа, списъци на засегнатите клиенти, действия по ограничаване, становище на DPO и проекти на комуникации. В сценарий с B2B SaaS портал екипът може да се нуждае от екранни снимки, разрешения за обектно хранилище, идентификатори на билети за поддръжка, IAM промени и журнали за достъп между тенанти.
Доказателствата трябва да бъдат запазени правилно. Разхвърляни екранни снимки, експорти от чатове и лични папки не са достатъчни.
Zenith Blueprint, фаза „Контроли в действие“, Стъпка 23, разглежда ISO/IEC 27002:2022 control 5.28, събиране на доказателства:
„Когато възникне инцидент по информационна сигурност, един от най-критичните, но често пренебрегвани елементи на реагирането са доказателствата. Не журнали, не екранни снимки, не свободни разкази, а правилно запазени доказателства, които спазват веригата на съхранение и са устойчиви на подправяне.“
Политика за събиране на доказателства и форензика Evidence Collection and Forensics Policy, раздел „Изисквания за управление“, клауза 5.5, посочва:
„Всички събрани доказателства се идентифицират уникално, етикетират се и се съхраняват в защитено хранилище със:“
Политика за управление на инциденти и нарушения на сигурността на личните данни, раздел „Доказателства, водене на записи и поверителност“, клауза 4.5.1, свързва тези доказателства със записа в PIMS:
„[И двете роли] Координаторът по реагиране при инциденти ТРЯБВА да поддържа пълен запис в REG10 за всеки подозирано или потвърдено инцидент с лични данни от приемането до приключването, включително факти, времева информация, класификация, оценка, действия, решения, уведомления, препратки към доказателства и статус на приключване.“
REG10 става единственият източник на истина за инцидента. REG08 обхваща уведомленията до клиенти или администратори, когато са приложими. Заедно те позволяват на екипите по сигурност, поверителност, правни въпроси и одит да работят от една доказателствена ос.
| Поле в REG10 | Примерен запис |
|---|---|
| Идентификатор на инцидента | PII-2026-034 |
| Времеви маркер на узнаването | 2026-06-23 02:13 UTC, потвърдена SOC аларма |
| Роля при обработването | Администратор за преки абонати, обработващ лични данни за набори от данни на корпоративни клиенти |
| Засегнати лични данни | Имена, служебни имейли, истории на трансакции, национални идентификационни номера |
| Първоначална класификация | Потвърден инцидент по сигурността с подозирано нарушение на сигурността на личните данни |
| Ограничаване | Удостоверителните данни на разработчика са отнети, сесиите са прекратени, достъпът до засегнатата база данни е ограничен |
| Оценка на риска | Достъпени са непублични идентификатори; рискът от измама със самоличност не може да бъде изключен |
| Решение за уведомяване | Одобрено е уведомяване на надзорния орган за данните, за които организацията е администратор; корпоративните клиенти са уведомени като администратори |
| Препратки към доказателства | Журнал за автентикация E-034-01, експорт на заявки E-034-02, фишинг артефакт E-034-03 |
| Приключване | Първопричината е отстранена, MFA контролите са укрепени, обучението за фишинг е актуализирано, последващите действия с клиенти са завършени |
Целта не е бюрокрация. Целта е да не се налага организацията да възстановява спомени от разпръснати Slack съобщения, след като регулаторът се свърже с нея.
Картографиране на реагирането на PIMS по ISO 27701 към ISO 27001 и ISO 27002
Зрелият процес за нарушения на сигурността на личните данни се намира на пресечната точка между управлението на поверителността и управлението на информационната сигурност.
Клаузи 4.1 до 4.4 на ISO/IEC 27001:2022 изискват организациите да разбират контекста, заинтересованите страни, обхвата на ISMS и процесите на системата за управление. За управление на нарушения на сигурността на личните данни това означава процесът да отразява регулаторните задължения, клиентските договори, ролите при обработването, зависимостите от доставчици и секторните задължения преди настъпване на инцидент.
Zenith Controls: Ръководство за кръстосано съответствие Zenith Controls помага за картографиране на контролите за инциденти в по-широк модел за увереност. Най-релевантните контроли по ISO/IEC 27002:2022 са:
| Контрол по ISO/IEC 27002:2022 | Третиране в Zenith Controls | Защо е важен за управлението на нарушения на сигурността на личните данни |
|---|---|---|
| 5.24 Планиране и подготовка за управление на инциденти по информационна сигурност | Коригиращ контрол, реагиране и възстановяване, управление на събития по информационна сигурност | Дефинира планове, роли, пътища за ескалация, комуникационни шаблони и готовност за нарушения на поверителността |
| 5.25 Оценка и решение относно събития по информационна сигурност | Откриващ контрол, откриване и реагиране, управление на събития по информационна сигурност | Създава структурирана точка за вземане на решение при класифициране на инциденти с поверителността и подозирани нарушения на сигурността на личните данни |
| 5.26 Реагиране при инциденти по информационна сигурност | Коригиращ контрол, реагиране и възстановяване, управление на събития по информационна сигурност | Активира ограничаване, координация, подкрепа за уведомяване, възстановяване и комуникация със заинтересовани страни |
| 5.28 Събиране на доказателства | Запазване на доказателства и надеждност на разследването през жизнения цикъл на инцидента | Подкрепя отчетността по GDPR, форензичното качество, въпросите на регулатора и защитимостта при одит |
| 6.8 Докладване на събития по информационна сигурност | Канал за докладване, управляван от хората, и обучение за осведоменост | Осигурява бързо докладване на подозирани инциденти с лични данни от служители, външни изпълнители и заинтересовани страни |
ISO/IEC 27035 поддържа структурирано управление на инциденти. ISO/IEC 27037 поддържа обработването на цифрови доказателства. ISO/IEC 29134 може да подпомогне логиката на оценките на въздействието върху защитата на данните, когато отстраняването след нарушение разкрие необходимост от по-задълбочен преглед за DPIA. След това ISO/IEC 27701:2025 въвежда в системата за управление контекста на ролята по поверителност, въздействието върху субектите на данни, задълженията на администраторите и обработващите лични данни и доказателствените изисквания на PIMS.
Един инцидент, много регулаторни перспективи
Инцидентът на Мария не е само въпрос по GDPR. Тъй като дружеството предоставя облачни услуги на клиенти от финансовия сектор, NIS2 и DORA също може да се прилагат. Клиентските договори може да налагат 24-часово уведомяване. Киберзастраховката може да изисква бързо уведомяване. Вътрешното управление може да изисква докладване до съвета.
Създаването на отделни разкази за всяка рамка поражда риск от противоречия. Методът на Clarysec е да се поддържа една доказателствена ос, след което от нея да се създават специфични за рамките изходи.
| Рамка или регулация | Перспектива към инцидента | Изход от доказателствената ос на Clarysec |
|---|---|---|
| GDPR | Нарушение на сигурността на личните данни, риск за физическите лица, уведомяване на надзорен орган, комуникация със засегнати физически лица | Запис на решението в REG10, становище на DPO, обосновка по Article 33 и 34, доказателства за комуникация |
| ISO/IEC 27701:2025 | Управление на PIMS, задължения на администратор и обработващ лични данни, риск за субекта на данни, доказателства за поверителност | Класификация на инцидент с лични данни, оценка на ролята, REG08 и REG10, коригиращи действия |
| ISO/IEC 27001:2022 | Контекст на ISMS, заинтересовани страни, процес за реагиране при инциденти, непрекъснато подобрение | Запис за инцидента, актуализации на третирането на риска, вход за преглед от ръководството, доказателства за ефективност на контролите |
| NIS2 | Обработване на значителни инциденти, поетапно докладване, мерки за сигурност срещу всички видове опасности | Доказателства за 24-часово ранно предупреждение, 72-часов пакет за уведомяване за инцидент, подкрепа за окончателен доклад в едномесечен срок |
| DORA | Управление на ИКТ инциденти за финансови субекти и цифрова оперативна устойчивост | Факти за ИКТ въздействието, зависимости от трети страни, обратна връзка от тестване на устойчивостта, подкрепа за докладване на инциденти |
| NIST CSF 2.0 | Текущ и целеви профил, приоритизиран план за действие, комуникация на риска | Актуализации на пропуски, целеви подобрения, наратив за риска на ниво съвет |
| COBIT 2019 | Управление, управленски цели, отчетност, резултатност на контрола | RACI, журнали на решенията, показатели за процесите, проследяване на коригиращи действия |
NIS2 Article 21 установява мерки за управление на риска за киберсигурността, включително обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, оценка на ефективността, киберхигиена, криптография, контрол на достъпа, управление на активите, MFA и сигурни комуникации. NIS2 Article 23 създава поетапно докладване за значителни инциденти, включително ранно предупреждение в рамките на 24 часа, уведомяване за инцидент в рамките на 72 часа, актуализации при поискване и окончателен доклад не по-късно от един месец след уведомяването за инцидента.
DORA се прилага от 17 януари 2025 г. и установява единни изисквания за управление на ИКТ риска, докладване на ИКТ инциденти, тестване на цифровата оперативна устойчивост, споделяне на информация и управление на риска от ИКТ трети страни за финансови субекти. За финтех доставчик един инцидент може следователно да бъде нарушение по GDPR, значителен инцидент по NIS2, релевантно за DORA ИКТ събитие за клиенти и договорно събитие за уведомяване.
Как одиторите ще тестват жизнения цикъл
Одиторите рядко спират до „покажете ми вашата политика за реагиране при инциденти“. Те проверяват дали жизненият цикъл работи под доказателствен натиск.
Одитор по ISO/IEC 27701:2025 или ISO/IEC 27001:2022 ще попита как инцидентите с поверителността влизат в ISMS и PIMS, кой класифицира събитията, как се различават задълженията на администратор и обработващ лични данни и как инцидентите водят до коригиращи действия.
Одитор по GDPR или надзорен орган ще се фокусира върху момента на узнаване, риска за физическите лица, участието на DPO, обосновката за уведомяване, комуникацията със засегнатите физически лица и отчетността. Възможно е да извадят извадка от инциденти, за които не е било извършено уведомяване, за да проверят дали обосновката за неуведомяване е документирана.
Преглед по NIS2 или DORA ще разгледа праговете за значителен инцидент, поетапното докладване, ИКТ въздействието, зависимостите от трети страни, последствията за устойчивостта и дали докладването е било съгласувано със съответния компетентен орган или изискванията на клиента.
Оценител по NIST CSF 2.0 ще попита дали инцидентът е променил текущия профил и целевия профил на организацията. Преглеждащ по COBIT 2019 ще се фокусира върху управлението, отчетността, собствеността върху процесите, показателите и проследяването на коригиращите действия.
Силен пакет за одит трябва да включва:
| Доказателствен елемент | Защо одиторите го изискват |
|---|---|
| Запис за инцидента в REG10 | Доказва приемане, времева информация, класификация, оценка, решения, уведомления и приключване |
| Запис в REG08 за уведомяване на клиент или администратор | Доказва комуникациите от обработващия лични данни и историята на актуализациите към клиента |
| Първоначален доклад или аларма | Установява как е открит инцидентът и кога е започнало узнаването |
| Хронология на ключовите действия | Показва ограничаване, оценка, одобрения и решения за уведомяване |
| Оценка на ролята при обработването | Демонстрира разделянето на задълженията на администратор и обработващ лични данни |
| Категории лични данни и засегнати субекти | Подкрепя оценката на риска и обхвата на уведомяването |
| Препоръка на DPO или съветник по поверителност | Доказва отчетно становище по поверителността преди външно решение |
| Обосновка за уведомяване или неуведомяване | Подкрепя отчетността по GDPR Article 33 и 34 |
| Индекс на хранилището за доказателства | Демонстрира целостта на доказателствата и дисциплина по веригата на съхранение |
| Първопричина и план за коригиращи действия | Показва непрекъснато подобрение и преглед на ефективността на контролите |
Тук Zenith Controls е търговски и оперативно ценен. Той помага едни и същи доказателства да се картографират към контролите за инциденти по ISO/IEC 27002:2022, отчетността по GDPR, обработването на инциденти по NIS2, очакванията за устойчивост по DORA, комуникацията по NIST CSF и управлението по COBIT, без всеки път да се изгражда наново одитният разказ.
Оперативен ритъм за първите 24 часа
Реалистичният наръчник за нарушения на сигурността на личните данни трябва да бъде практически, а не теоретичен. Разгледайте експозиция между тенанти в SaaS, докладвана от клиент в 08:12.
В 08:12 екипът за клиентски успех получава доклада и следва поведението за докладване от Zenith Blueprint Стъпка 16. Билетът се маркира като подозирано инцидент с лични данни.
В 08:25 Координаторът по реагиране при инциденти отваря REG10. Записът включва времевия маркер на узнаването, докладващото лице, системата, предполагаемите типове данни и собственика.
В 09:02 инженерният екип връща промяната в разрешенията. Журналите се експортират преди ротация. Отговорникът за доказателствата етикетира доклада на клиента, IAM промяната, експорта на журналите за достъп и потвърждението за ограничаване в защитеното хранилище.
В 10:30 Ръководителят по поверителността определя, че организацията действа като обработващ лични данни за клиентските прикачени файлове към поддръжка. Съгласно Политика за управление на инциденти и нарушения на сигурността на личните данни, клауза 4.4.4, засегнатите клиенти администратори трябва да бъдат уведомени без ненужно забавяне и в рамките на договорните срокове. Отваря се REG08.
В 12:00 DPO оценява риска за субектите на данни. Данните изглеждат ограничени, но някои прикачени файлове може да включват имена на служители и вътрешни идентификатори. DPO записва обосновката на риска и препоръката в REG10.
В 15:00 засегнатите клиенти администратори получават първоначалното уведомление: какво се е случило, кога е било открито, какво е ограничено, какви лични данни може да са засегнати, какво все още се анализира и кога ще бъде предоставена следващата актуализация.
В 18:00 ръководството получава кратък инструктаж: уведомленията до клиенти са изпратени, решенията за уведомяване на регулатор принадлежат на администраторите за клиентските лични данни, вътрешното обработване като администратор все още се оценява, доказателствата са запазени и анализът на първопричините е в ход.
Този ритъм предотвратява най-честите провали при нарушения: пропуснати срокове, объркани роли, недокументирано становище и неконтролирани комуникации.
Често срещани модели на провал, които трябва да бъдат премахнати преди следващата аларма
Най-вредните провали при нарушения на поверителността рядко са причинени от един липсващ документ. Те са причинени от прекъсвания между сигурността, поверителността, правния отдел, доставчиците и бизнес собствениците.
Clarysec често наблюдава следните модели:
- Планове за реагиране при инциденти съществуват, но липсва класификация на нарушенията на сигурността на личните данни.
- 72-часовото уведомяване по GDPR е споменато, но вътрешните срокове не са по-кратки от законовия срок.
- Ескалацията от обработващия лични данни се забавя, защото екипите изчакват пълен анализ на първопричините.
- Договорите с доставчици не изискват бързо уведомяване при нарушение или подкрепа за доказателства.
- Становището на DPO е устно и никога не се въвежда в регистъра на нарушенията.
- Комуникацията с физическите лица при висок риск се разглежда твърде късно.
- Доказателствата се съхраняват в лични папки, чат теми или коментари към билети.
- Решенията за неуведомяване не се документират.
- Извлечените поуки не актуализират контролите, обучението, клаузите за доставчици или плановете за третиране на риска.
Zenith Blueprint, Стъпка 23, улавя защо структурата е важна:
„Реагиране при инциденти без структура се превръща в хаотично действие. Имейли се изпращат, срещи се свикват, а решенията се вземат емоционално или непоследователно. Зрялата ISMS обаче превръща реагирането в дисциплина.“
Тази дисциплина е целта на управлението на нарушения на сигурността на личните данни по ISO/IEC 27701:2025.
Изградете жизнения цикъл на Clarysec за нарушения на сигурността на личните данни
Подходът на Clarysec комбинира три слоя.
Първо, Zenith Blueprint предоставя пътната карта за внедряване. Стъпка 16 гарантира, че хората разпознават и докладват подозирани инциденти. Стъпка 23 операционализира оценката, решението, реагирането и събирането на доказателства чрез контролите 5.25, 5.26 и 5.28 на ISO/IEC 27002:2022.
Второ, наборът от политики дефинира правомощията и задълженията. Политиките за МСП правят докладването, 72-часовото узнаване и регистрите на инциденти практически приложими за по-малки организации. Корпоративните политики възлагат ръководство на DPO, прагове за нарушения, комуникация със засегнати физически лица, условия за уведомяване от доставчици, обработване на доказателства и форензично управление. Специфичната за PIMS Политика за управление на инциденти и нарушения на сигурността на личните данни добавя ролеви задължения на администратор и обработващ лични данни, REG08, REG10, обосновка за уведомяване и доказателства за приключване.
Трето, Zenith Controls служи като компас за кръстосано съответствие. Той картографира планирането, оценката, реагирането и доказателствата при инциденти в интегриран поглед през ISO/IEC 27002:2022, GDPR, NIS2, DORA, NIST CSF 2.0 и очаквания за увереност в стил COBIT.
За CISO това намалява оперативното объркване. За DPO създава защитима проследимост на решенията по поверителността. За мениджърите по съответствие свързва един запис за инцидент с множество регулаторни изходи. За одиторите създава проследими доказателства. За висшето ръководство намалява вероятността управляем инцидент с поверителността да се превърне в регулаторна и репутационна криза.
Следваща стъпка
Не чакайте алармата в 2 ч. през нощта, за да разберете дали процесът ви за нарушения на сигурността на личните данни работи.
Започнете тази седмица с три действия:
- Прегледайте дали приемането на инциденти изрично улавя подозирани инциденти с лични данни.
- Потвърдете, че задълженията при нарушение за администратор и обработващ лични данни са разделени в политиките, договорите и регистрите на доказателствата.
- Проведете настолно упражнение с реалистичен сценарий, като компрометирани удостоверителни данни, експозиция между тенанти, погрешно изпратен файл с работни заплати, изгубен шифрован лаптоп или компрометиране на доставчик.
Clarysec може да ви помогне да операционализирате това чрез Zenith Blueprint: 30-стъпкова пътна карта за одитора Zenith Blueprint, Zenith Controls: Ръководство за кръстосано съответствие Zenith Controls и набора от политики за ISO/IEC 27701:2025 PIMS, включително Политика за управление на инциденти и нарушения на сигурността на личните данни PII Incident and Breach Management Policy, Политика за защита на данните и поверителност Data Protection and Privacy Policy, Политика за реагиране при инциденти за МСП Incident Response Policy-sme, Политика за сигурност на трети страни и доставчици Third party and supplier security policy и Политика за събиране на доказателства и форензика Evidence Collection and Forensics Policy.
Изтеглете инструментариума на Clarysec за PIMS, заявете оценка на готовността при нарушение или насрочете демонстрация, за да превърнете 72-часовото си реагиране по GDPR от хаотично действие в дисциплиниран процес с готовност за одит.
Сертифицирайте се по PECB ISO/IEC 27701 и изградете своята PIMS
- ✓ Официални учебни материали на PECB и два опита за изпит
- ✓ Таксата за сертифициране и първата годишна такса за поддръжка (AMF) са включени, където е приложимо
- ✓ Самостоятелно обучение или онлайн на живо · курсът се възлага до 1 работен ден
Frequently Asked Questions
За автора
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
