Управление на жалби относно защитата на личните данни за GDPR и ISO 27701

Петък е, 16:45 ч., когато CISO на бързо растяща FinTech SaaS платформа вижда входящия имейл. Темата е кратка, формална и веднага създава напрежение: „Официално запитване относно жалба, реф.: [Case Number]“.

Изпращачът е национален орган за защита на данните.

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

Срокът за отговор е 10 работни дни.

В този момент управлението на защитата на личните данни престава да бъде теоретично. Уведомлението за поверителност може да съществува. Политиката за защита на данните може да е била одобрена миналата година. Работният поток за DSAR може да е записан някъде в споделен диск. Но регулаторът не пита дали организацията има добри намерения. Регулаторът изисква доказателства.

Кой е собственик на отговора? Може ли DPO или отговорникът по защита на личните данни да комуникира директно с органа? Може ли екипът за поддръжка да изпрати кратък обяснителен имейл? Това само жалба по GDPR ли е, или е и нарушение на сигурността на личните данни, съществен инцидент, свързан с ИКТ по DORA, или значителен инцидент по NIS2? Кои записи могат да бъдат разкрити външно и кой ги одобрява?

Именно тук управлението на системата за управление на информацията за защита на личните данни по ISO/IEC 27701:2025 трябва да стане оперативно. PIMS не е папка с документи за поверителност. Това е система за управление, която превръща жалбите, ескалациите на искания от субекти на данни, кореспонденцията с надзорни органи, индикаторите за нарушение, разкриването на доказателства, коригиращите действия и прегледите от ръководството в защитима следа за отчетност.

Подходът на Clarysec е прост: жалбите относно защитата на личните данни и исканията от надзорни органи трябва да се третират като управлявани работни потоци, а не като ad hoc правни събития. Това означава предварително определени канали за приемане, ролево базирана ескалация, регистри на доказателствата, правила за комуникация с регулатори, коригиращи действия и съпоставяне на изискванията за съответствие между рамки към очакванията за уверение по GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIST CSF 2.0, NIS2, DORA и COBIT 19.

Защо управлението на жалби относно защитата на личните данни се проваля под натиск

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

Жалбите са различни.

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

GDPR прави този проблем с доказателствата неизбежен. Article 5 изисква администраторите да обработват лични данни законосъобразно, добросъвестно, прозрачно, за конкретни цели, при минимизиране на данните, точност, ограничение на съхранението и подходяща сигурност. Article 5(2) добавя задължението за отчетност: администраторът трябва да може да докаже съответствие. Article 6 изисква правно основание, Article 9 добавя по-строги условия за специални категории лични данни, а Article 4 дефинира ролите, дейностите по обработване и понятието за нарушение на сигурността на личните данни, които често стават централни при разследвания на жалби.

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

Регулаторът може да поиска:

• Първоначалното искане, свързано със защитата на личните данни, и потвърждението за получаване.
• Записи за валидиране на самоличността.
• Вътрешно маршрутизиране и журнали на решенията.
• Копия от комуникацията с жалбоподателя.
• Приложимата версия на уведомлението за поверителност.
• Записи за обработването и правното основание.
• Участие на обработващ лични данни и подизпълнител по обработване.
• Доказателства от DPIA, когато е приложимо.
• Контроли за сигурност, защитаващи личните данни.
• Оценка на нарушението и обосновка за уведомяване.
• Коригиращи действия и резултати от прегледа от ръководството.

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

Оперативният модел на Clarysec: жалбите са събития, контролирани от PIMS

В набора от политики на Clarysec за PIMS по ISO/IEC 27701:2025 обработването на жалби не се третира като страничен процес. То свързва приемането, уведомленията за поверителност, управлението на права, взаимодействието с регулатори, разкриването на доказателства, триажа на инциденти по сигурността и непрекъснатото подобрение.

Версията за МСП на Политиката за защита на данните и поверителност на Clarysec Политика за защита на данните и поверителност за МСП ясно възлага отговорност:

„Отговаря на индивидуални искания, свързани с поверителността, и регулаторни запитвания“

От раздел „Роли и отговорности“, клауза 4.2.2 от политиката.

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

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

„Всички опасения, инциденти или рискове, свързани с поверителността, трябва незабавно да бъдат ескалирани към управителя (GM) или координатора по поверителност“

От раздел „Изисквания за управление“, клауза 5.4.1 от политиката.

Тя също затваря цикъла на доказателствата:

„Журналите за ескалация трябва да се поддържат, включително крайните резултати и коригиращите действия“

От раздел „Изисквания за управление“, клауза 5.4.2 от политиката.

За корпоративни среди Политиката за защита на данните и поверителност на Clarysec Политика за защита на данните и поверителност възлага на DPO по-широка роля по регулаторни въпроси и нарушения:

„Ръководи взаимодействието с регулатори, провежда оценки на въздействието върху защитата на данните (DPIA) и управлява процесите за уведомяване при нарушения.“

От раздел „Роли и отговорности“, клауза 4.2.3 от политиката.

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

„Длъжностното лице по защита на данните (DPO) трябва да поддържа документирани процеси за приемане, валидиране, проследяване и отговор на искания от субекти на данни (DSR).“

От раздел „Изисквания за прилагане на политиката“, клауза 6.4.1 от политиката.

„Исканията трябва да бъдат потвърждавани в рамките на 72 часа и разрешавани в законоустановените срокове.“

От раздел „Изисквания за прилагане на политиката“, клауза 6.4.2 от политиката.

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

От входящата поща за поверителност до отговор към органа: управляваният работен поток

Добър работен поток за управление на жалби относно защитата на личните данни и искания от надзорни органи отговаря на пет въпроса в рамките на първия час:

1. Какъв тип събитие е това?
2. Кой е неговият собственик?
3. Какъв краен срок се прилага?
4. Какви доказателства са необходими?
5. Каква външна комуникация е разрешена?

Clarysec картографира тези въпроси в структуриран работен поток на PIMS.

Корпоративната Политика за правно и регулаторно съответствие Политика за правно и регулаторно съответствие е категорична относно риска при комуникация с регулатори:

„Всички устни или писмени изявления към регулатори трябва да бъдат предварително одобрени“

От раздел „Третиране на риска и изключения“, клауза 7.3.1.2 от политиката.

Тя също изисква контрол на сроковете и доказателствата:

„Крайните срокове за отговор трябва да се проследяват и да се поддържат журнали за доказателства“

От раздел „Третиране на риска и изключения“, клауза 7.3.1.3 от политиката.

За малки и средни предприятия Политиката за правно и регулаторно съответствие за МСП Политика за правно и регулаторно съответствие за МСП дава практически модел за отговор:

„Ако регулатори поискат доказателства за съответствие:“

От раздел „Прилагане и съответствие“, клауза 8.4.1 от политиката.

„Управителят (GM) трябва да предостави Регистъра на съответствието, записите и политиките.“

От раздел „Прилагане и съответствие“, клауза 8.4.1.1 от политиката.

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

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

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

Съгласно очакванията за прозрачност по GDPR лицата трябва да знаят къде да изпращат искания и опасения. Съгласно управлението на PIMS по ISO/IEC 27701:2025 този канал трябва да захранва контролиран регистър.

Политиката за уведомления за поверителност и прозрачност на Clarysec Политика за уведомления за поверителност и прозрачност адресира това в момента на одобряване на уведомлението:

„[Администратор] Собственикът на процеса / собственикът на бизнеса ТРЯБВА да включи текущия канал за приемане на искания за упражняване на права REG06 и канала за контакт по жалби или въпроси, свързани с поверителността, в REG07 преди подаване на уведомление за поверителност за одобрение.“

От раздел „Съдържание на уведомлението и информация за прозрачност“, клауза 4.2.4 от политиката.

Тази клауза е оперативно важна. Тя предотвратява публикуването от бизнес екипи на уведомления за поверителност с остарели пощенски кутии на DPO, неработещи уебформуляри или общи връзки „свържете се с нас“, които клиентската поддръжка не разпознава като канали за поверителност.

Резултатът е затворен цикъл:

• Уведомленията за поверителност посочват правилния канал за приемане на жалби и искания за права.
• Исканията и жалбите влизат в REG06.
• Отговорникът по защита на личните данни или мениджърът на PIMS ги класифицира и маршрутизира.
• Резултатите и комуникациите се записват.
• Тенденциите и коригиращите действия се преглеждат в REG12.

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

„[Всички] Отговорникът по защита на личните данни / мениджърът на PIMS ТРЯБВА да запише всяко искане за упражняване на права от субект на данни в REG06 в рамките на два работни дни от получаването.“

От раздел „Приемане, регистриране и класификация“, клауза 4.1.1 от политиката.

За сценарии с администратор тя също изисква комуникацията при приключване да бъде записана:

„[Администратор] Отговорникът по защита на личните данни / мениджърът на PIMS ТРЯБВА да съобщи резултата, статуса на изпълнение, обосновката за отказ, статуса на удължаване или наличния път за ескалация на заявителя и да запише комуникацията в REG06.“

От раздел „Отказ, удължаване, ограничение и приключване“, клауза 4.4.4 от политиката.

И за непрекъснато подобрение:

„[Всички] Отговорникът по защита на личните данни / мениджърът на PIMS ТРЯБВА да преглежда повтарящите се теми при искания за права, жалби, спорове и коригиращи действия в REG12 най-малко на тримесечна база.“

От раздел „Показатели и измерване“, клауза 8.1.6 от политиката.

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

Предоставянето на доказателства на надзорен орган е контролирана дейност

Когато орган поиска записи, организацията се сблъсква с втори риск за поверителността: прекомерно разкриване.

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

Затова Политиката за документирана информация и управление на доказателствата в PIMS на Clarysec Политика за документирана информация и управление на доказателствата в PIMS изисква одобрение и определяне на обхвата на разкриването:

„[Всички] Отговорникът по защита на личните данни / мениджърът на PIMS ТРЯБВА да запише одобрението и обхвата на разкриването в REG12 преди предоставяне на PIMS доказателства на външен одитор, клиент, обработващ лични данни, администратор, надзорен орган или друга външна страна.“

От раздел „Достъп, защита, извличане и разкриване“, клауза 4.4.5 от политиката.

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

За искания от надзорни органи Clarysec препоръчва пакет за отговор към органа, съдържащ:

• Референция на искането от органа, дата на получаване и краен срок.
• Определения собственик и одобряващ на отговора.
• Правното основание за разкриване, ако е необходимо.
• Обхвата на доказателствата и изключенията.
• Използваните източници на записи.
• Журнал на всички комуникации.
• Копие на окончателния отговор.
• Коригиращи действия, установени в резултат.

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

Къде ISO/IEC 27002:2022 прави управлението на защитата на личните данни одитируемо

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

Zenith Controls: The Cross-Compliance Guide на Clarysec Zenith Controls поставя контрол 5.5 от ISO/IEC 27002:2022, контакт с органи, в центъра на управлението на взаимодействието с регулатори. Той описва контрол 5.5 като превантивен и коригиращ, поддържащ поверителност, цялостност и наличност и свързан с концепциите Identify, Protect, Respond и Recover.

Zenith Controls обяснява оперативната връзка между контакта с органи и управлението на инциденти:

„Контрол 5.5 подпомага ефективността на управлението на инциденти, като гарантира, че организациите имат предварително установени контакти със съответните органи, като правоохранителни органи, регулатори, национални CERT или органи за защита на данните.“

От Zenith Controls, контрол 5.5, Контакт с органи.

Ръководството картографира контрол 5.5 към поддържащи контроли от ISO/IEC 27002:2022, които са пряко важни, когато жалбата се превърне в случай с регулаторно измерение.

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

Контрол 5.34, поверителност и защита на PII, е също толкова централен. Zenith Controls го свързва с инвентари на активите, управление на облачни услуги, класификация на информацията, предаване на информация, контрол на достъпа, управление на идентичности и преглед на сигурността на проекти и промени. В контекста на жалби тези връзки отговарят на ключови въпроси на регулатора: Какви PII съществуват? Къде се съхраняват? Кой има достъп до тях? Кои обработващи лични данни участват? Било ли е контролирано предаването? Проектът бил ли е прегледан за въздействие върху поверителността?

Не се срещайте с регулатора за първи път по време на криза

Zenith Blueprint: An Auditor’s 30-Step Roadmap на Clarysec Zenith Blueprint третира контакта с органи като планирана способност, а не като паническа реакция. Във фазата „Controls in Action“, Step 22, Организационни контроли, контрол 5.5 е описан с пряко предизвикателство:

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

От Zenith Blueprint, фаза „Controls in Action“, Step 22, Организационни контроли, контрол 5.5, Контакт с органи.

За управлението на жалби относно защитата на личните данни наръчникът трябва да идентифицира:

• Надзорните органи за защита на данните по юрисдикция.
• Органите по киберсигурност, CSIRT и секторните регулатори, когато е приложимо.
• Вътрешните собственици на контакта с органи, като DPO, CISO, правен отдел, управител (GM) или отговорник по защита на личните данни.
• Одобрените комуникационни канали.
• Правилата за правен преглед и одобрение от изпълнителното ръководство.
• Изискванията за съхранение на доказателства и контрол на разкриването.
• Тригерите за ескалация при нарушение, NIS2, DORA, клиент или обработващ лични данни.

Zenith Blueprint също разглежда външната комуникация във фазата „ISMS Foundation and Leadership“, Step 5, Комуникация, осведоменост и компетентност:

„Определете кой комуникира: вероятно вашият CISO/ISMS Manager управлява оперативните комуникации по сигурността с партньори/клиенти (например отговаря на въпросници по одити по сигурността), докато висшето ръководство или PR представител управлява публичните изявления относно инциденти. Правният консултант може да участва при формулирането на комуникации към регулатори.“

От Zenith Blueprint, фаза „ISMS Foundation and Leadership“, Step 5, Clause 7.4, Външна комуникация.

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

Съответствие между рамки: когато жалбата относно защитата на личните данни става повече от GDPR

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

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

NIS2 може да се прилага, когато организацията е съществен или важен субект, включително определена цифрова инфраструктура, доставчици на облачни изчислителни услуги, центрове за данни, MSP, MSSP, инфраструктури на финансовите пазари, цифрови доставчици и други сектори. NIS2 Article 21 изисква технически, оперативни и организационни мерки за управление на риска, обхващащи обработване на инциденти, непрекъснатост на дейността, сигурност на веригата на доставки, сигурна разработка, обработване на уязвимости, оценка на ефективността, обучение, криптография, контрол на достъпа, управление на активите и автентикация. Article 23 въвежда поетапно докладване на значителни инциденти, включително ранно предупреждение, уведомяване за инцидент и последващо докладване. Ако жалба относно защитата на личните данни разкрие инцидент, засягащ предоставянето на услуги, може да е необходим анализ по NIS2.

DORA се прилага за много финансови субекти и създава специфична рамка за цифрова оперативна устойчивост от 17 януари 2025 г. Тя обхваща управление на ИКТ риска, докладване на инциденти, тестване на устойчивостта, споделяне на информация за заплахи, риск от ИКТ услуги от трети страни и надзор. Articles 17 to 20 изискват процес за управление на инциденти, свързани с ИКТ, класификация, ескалация към ръководството, комуникация с клиенти и регулаторно докладване. Ако FinTech жалба относно защитата на личните данни съдържа твърдения за загуба на данни, компрометиране на достъп или отказ на външен доставчик на ИКТ услуги, процесът за инциденти по DORA може да се изпълнява паралелно с оценката по GDPR.

NIST CSF 2.0 предоставя практическо управленско покритие. Неговата функция GOVERN очаква правните, регулаторните, договорните, свързаните с поверителността и гражданските свободи задължения да бъдат разбрани и управлявани. Функциите RESPOND и RECOVER подпомагат триаж, ескалация, комуникация със заинтересованите страни, запазване на доказателства, ограничаване, отстраняване, възстановяване и документация.

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

Практически пример: SaaS искане от орган

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

Отговор, съгласуван с Clarysec, би протекъл по следния начин.

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

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

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

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

Пето, CISO или собственикът по сигурността проверява дали жалбата показва неразрешено разкриване, случайна загуба или достъп до лични данни. Ако да, процесът за инциденти се задейства. Това свързва случая с контролите от ISO/IEC 27002:2022 за докладване на събития, планиране на инциденти, реагиране, обработване на доказателства, регистриране, мониторинг и правни изисквания.

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

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

Това превръща стресиращото искане от орган в одитируем, повторяем работен поток на PIMS.

Погледът на одитора: как се тества същата жалба

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

Одитор по PIMS съгласно ISO/IEC 27701:2025 ще проследи жизнения цикъл на PII. Той ще попита как е получено искането, дали организацията правилно е идентифицирала своята роля в PIMS, дали е следван процесът за права, дали са били налични маршрути за жалби и ескалация, дали комуникациите са записани и дали повтарящите се теми са включени в непрекъснатото подобрение.

Одитор по ISO/IEC 27001:2022 ще разгледа дисциплината на системата за управление. Той ще тества дали организацията е идентифицирала правни и договорни изисквания, възложила е роли, контролирала е документираната информация, оценила е рискове, избрала е контроли, управлявала е процеси за инциденти и доказателства и е преглеждала резултатността. Одиторът може да проследи жалбата до регистъра на риска, Декларацията за приложимост, записите за инциденти и плана за коригиращи действия.

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

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

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

Zenith Blueprint разглежда коригиращите действия във фазата „Audit, Review and Improvement“, Step 29, Непрекъснато подобрение:

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

От Zenith Blueprint, фаза „Audit, Review and Improvement“, Step 29, Непрекъснато подобрение, Коригиращи действия и научени уроци.

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

Практически контролен списък за CISO, DPO, мениджъри по съответствие и собственици на бизнеса

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

• Потвърдете, че уведомленията за поверителност включват актуални канали за искания за права и контакти за жалби.
• Уверете се, че REG06 или еквивалентен регистър записва всички искания за права, жалби, ескалации, резултати и комуникации.
• Дефинирайте кога жалбите се превръщат в инциденти, оценки на нарушение, правни въпроси или случаи пред надзорен орган.
• Възложете роли за контакт с органи за DPO, отговорник по защита на личните данни, правен отдел, CISO, управител (GM) и одобряващ от изпълнителното ръководство.
• Поддържайте матрица за контакт с надзорни органи по юрисдикция и сектор.
• Изисквайте одобрение преди устни или писмени изявления към регулатори.
• Проследявайте крайните срокове за отговор в контролиран регистър на доказателствата.
• Дефинирайте обхвата на разкриване на доказателства преди външно предоставяне на записи.
• Свържете досиетата по жалби с DPIA, записи в RoPA, споразумения с обработващи лични данни, правила за съхранение и журнали за сигурност.
• Преглеждайте повтарящите се теми в жалбите на тримесечна база и записвайте коригиращи действия.
• Тествайте процеса чрез настолно упражнение с участие на екипите по поверителност, правни въпроси, сигурност, поддръжка и ръководство.
• Включете пътища за ескалация към доставчици и обработващи лични данни, особено за облачни услуги, аналитични услуги, поддръжка и доставчици на управлявани услуги.
• Картографирайте управлението на жалби към отчетността по GDPR, контролите на PIMS по ISO/IEC 27701:2025, изискванията към ISMS по ISO/IEC 27001:2022 и контролите за органи и поверителност по ISO/IEC 27002:2022.
• За секторите в обхват добавете точки за вземане на решения относно докладване на инциденти по NIS2 или DORA.

Бизнес аргументът: доверието на регулатора се изгражда рано

Надзорните органи не очакват съвършенство. Те очакват контрол, отчетност и доказателства.

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

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

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

Следващи стъпки с Clarysec

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

Clarysec може да ви помогне да изградите готов за регулатор работен поток за жалби относно защитата на личните данни и искания от надзорни органи чрез:

• Политики за PIMS по ISO/IEC 27701:2025 и ролево базирани оперативни процедури.
• Модели на доказателства REG06 и REG12 за искания за права, жалби, разкриване и коригиращи действия.
• Матрици на отговорностите за DPO, отговорник по защита на личните данни, управител (GM), правен отдел и CISO.
• Наръчници за контакт с органи, базирани на Zenith Blueprint Zenith Blueprint.
• Съпоставяне на изискванията за съответствие между рамки чрез Zenith Controls Zenith Controls.
• Корпоративни и SME пакети с политики, включително Политика за защита на данните и поверителност Политика за защита на данните и поверителност, Политика за защита на данните и поверителност за МСП Политика за защита на данните и поверителност за МСП, Политика за правно и регулаторно съответствие Политика за правно и регулаторно съответствие, Политика за правно и регулаторно съответствие за МСП Политика за правно и регулаторно съответствие за МСП, Политика за управление на правата на субектите на данни Политика за управление на правата на субектите на данни, Политика за уведомления за поверителност и прозрачност Политика за уведомления за поверителност и прозрачност и Политика за документирана информация и управление на доказателствата в PIMS Политика за документирана информация и управление на доказателствата в PIMS.

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