Независимост на длъжностното лице по защита на данните за ISO 27701 и GDPR
Сара, CISO на бързо растящо финтех дружество, усети проблема още преди началото на заседанието на комитета по риска. Неправилно конфигурирано облачно хранилище беше изложило за кратко база данни в тестова среда, съдържаща клиентски тестови данни. Инженерният екип бързо беше коригирал конфигурацията. Нито една продукционна система не беше засегната. Докладът за инцидента описваше събитието като незначително.
Но човекът, който представяше този доклад, беше Марк, ръководителят на ИТ.
Марк беше и определеното длъжностно лице по защита на данните (DPO) на дружеството.
Като ръководител на ИТ Марк акцентираше върху скоростта на отстраняване, ограничения оперативен ефект и причините, поради които не е необходимо уведомяване на надзорния орган. Като DPO той трябваше да задава по-трудните въпроси: защо данните в тестовата среда са съществували в тази форма, дали наборът от данни съдържа идентифицируеми лица, дали сегрегацията на средите е отказала, дали инцидентът разкрива системна слабост в поверителността и дали субектите на данни могат да бъдат изложени на риск дори ако данните не са „продукционни PII“.
Това е проблемът с независимостта на DPO в най-практическата му форма. Въпросът не е дали Марк е действал недобросъвестно. Въпросът е структурен. Един човек не може обективно да наблюдава, оспорва и консултира решения, които същевременно притежава, одобрява или защитава.
Същият проблем се появява при SaaS дружества, които се подготвят за прегледи на готовността за ISO/IEC 27701:2025 PIMS, доставчици в здравеопазването, които отговарят на клиентски одити, финансови субекти под проверка по DORA, и МСП, които се опитват да поддържат управлението на поверителността леко. Организацията има DPO или съветник по поверителност на хартия. Уведомлението за поверителност е актуализирано. Шаблонът за DPIA съществува. Регистърът на нарушенията е готов. След това одиторът задава прост въпрос:
„Кой е вашият DPO или съветник по поверителност и какви други функции изпълнява?“
Ако отговорът е „ръководител на ИТ“, „CISO“, „главен юрисконсулт“, „оперативен директор (COO)“, „ръководител на ЧР“, „ръководител на маркетинга“ или „лицето, което одобрява достъп, ръководи реагирането при инциденти, подписва DPIA и преглежда същите контроли“, организацията няма просто кадрови проблем. Тя има проблем в управлението.
За ISO/IEC 27701:2025 и отчетността по GDPR независимостта на DPO не е формалност. Тя е контрол. Тя свързва дизайна на ролите, разделението на задълженията, прегледа от ръководството, третирането на риска, регистрите с доказателства, вътрешния одит и пътищата за ескалация.
Тук Clarysec помага на организациите да превърнат независимостта от неясна правна фраза в повторяем и одитируем оперативен модел чрез [P02] Политика за роли и отговорности в управлението, [P02S] Политика за роли и отговорности в управлението за МСП, [PIMS] Политика за роли, отговорности и отчетност по поверителността, [DP] Политика за защита на данните и поверителност, Zenith Blueprint: 30-стъпкова пътна карта за одитори и Zenith Controls: ръководство за съответствие между рамки.
Реалният риск при DPO с две функции
GDPR допуска DPO да изпълнява други задачи, но не и ако тези задачи създават конфликт на интереси. Article 38 изисква DPO да не получава инструкции относно изпълнението на задачите си, да не бъде санкциониран за изпълнението на тези задачи и да не заема допълнителни функции, които компрометират независимостта му.
Конфликтът обикновено възниква, когато DPO заема позиция, която определя целите или средствата за обработване на лични данни. Често срещани високорискови комбинации включват:
- DPO и ръководител на ИТ или CIO
- DPO и CISO или ръководител по информационна сигурност
- DPO и ръководител на маркетинга
- DPO и ръководител на ЧР
- DPO и оперативен директор (COO)
- DPO и ръководител на вътрешния одит
- DPO и собственик на продукт за високорисково обработване на данни
Някои комбинации не са автоматично забранени, но всички трябва да бъдат проверени. Правните консултанти, мениджърите по съответствие, ръководителите по сигурността и мениджърите на програми за поверителност може да разбират задълбочено защитата на данните, но въпросът е дали могат независимо да наблюдават, да оспорват решения и да ескалират опасения, без да преглеждат собствената си работа.
| Сценарий | Защо независимостта е важна | Сигнал за конфликт |
|---|---|---|
| Одобрение на DPIA за нова аналитична функция с изкуствен интелект | DPO трябва да оспори необходимостта, пропорционалността, правното основание, прозрачността и предпазните мерки | DPO носи отговорност и за сроковете за пускане на продукта или целите за приходи |
| Оценка на нарушение след неоторизиран достъп до журнали | DPO трябва да консултира класификацията и уведомяването при нарушение на сигурността на личните данни | DPO управлява екипа, чийто отказ на контрол е причинил инцидента |
| Въвеждане на обработващ лични данни за облачна аналитика | DPO трябва да оспори рисковете при предаване, съхранение, подизпълнители по обработване и достъп | DPO е договарял договора и иска одобрението да приключи |
| Одобрение на достъп до чувствителни клиентски данни | DPO трябва да наблюдава минимално необходимия достъп и отчетността | Същото лице одобрява, предоставя и преглежда достъпа |
| Вътрешен одит на контролите за поверителност | Одиторът трябва обективно да тества управлението на поверителността | DPO е написал процеса, изпълнил е контрола и преглежда доказателствата |
Рискът не е теоретичен. DPO в конфликт може да омаловажи рисковете за поверителността, за да защити бюджети, да избягва препоръки, които създават оперативно триене, да се колебае да докладва нарушение, което се отразява неблагоприятно на неговия отдел, или да няма независимостта да оспори висшето ръководство.
Отчетността по GDPR прави това критично от гледна точка на доказателствата. Article 5(2) изисква администраторът да носи отговорност за и да може да докаже съответствие с принципите на законосъобразно, добросъвестно, прозрачно, ограничено по цел, минимизирано, точно, ограничено по срок на съхранение, сигурно и отчетно обработване. Конфликт при DPO, който не е оценен, одобрен, смекчен и подкрепен с доказателства, отслабва тази демонстрация.
Какво означава независимост в рамките на PIMS
В система за управление на информацията за поверителност независимостта не винаги означава, че DPO трябва да бъде външен. Тя означава, че DPO или съветникът по поверителност може да изпълнява задължения по мониторинг и консултиране, без да бъде структурно блокиран, оперативно поставен в конфликт или притискан да одобрява решения, които трябва да оспорва.
Clarysec разделя три понятия, които организациите често смесват:
- Независимост — способността за консултиране, мониторинг и ескалация без намеса.
- Разделение на задълженията — разделяне на несъвместими отговорности, като одобряване и изпълнение на високорискови действия.
- Управление на конфликти на интереси — документиран работен поток за идентифициране, оценяване, одобряване, смекчаване и преглед на неизбежни съвместявания на роли.
Това започва с ръководството и възлагането на роли. ISO/IEC 27001:2022 clause 5.3 изисква висшето ръководство да гарантира, че отговорностите и правомощията за ролите, свързани с информационната сигурност, са възложени и комуникирани. В PIMS, изграден върху ISMS, тази управленска дисциплина естествено се разширява към ролите по поверителност.
[P02] Политика за роли и отговорности в управлението посочва своята цел:
„Да се поддържа модел на управление, който прилага разделение на задълженията, елиминира конфликти на интереси и позволява ескалация на нерешени въпроси по сигурността.“
Този цитат е от Enterprise Governance Roles and Responsibilities Policy, раздел „Цели“, клауза на политиката 3.2.
Същата политика изрично посочва очакването за доказателства:
„Разделението на задълженията се прилага и документира“
Този цитат е от Enterprise Governance Roles and Responsibilities Policy, раздел „Изисквания към управлението“, клауза на политиката 5.4.3.
За МСП Clarysec признава, че перфектното разделяне не винаги е възможно. [P02S] Политика за роли и отговорности в управлението за МСП посочва:
„Третирането на риска трябва да включва идентифициране на всички случаи, при които отделни лица може да имат конфликтни задължения (напр. одобрение и мониторинг на достъп). Мерките за смекчаване може да включват възлагане на правомощия за преглед на друго лице или прилагане на компенсиращи контроли (напр. журнали или проверки по извадка).“
Този цитат е от SME Governance Roles and Responsibilities Policy-sme, раздел „Третиране на риска и изключения“, клауза на политиката 7.2.1.
Това е практическият стандарт за по-малки организации. Не се преструвайте, че конфликт няма. Идентифицирайте го, одобрете го, смекчете го, запишете го и го преглеждайте.
REG01 и REG12: работният поток на Clarysec за доказателства
В много организации конфликтите на роли се обработват неформално. Някой казва: „Твърде малки сме за отделен DPO“, и решението никога не достига до регистър. Месеци по-късно одиторът иска доказателства, а организацията има само организационна структура.
[PIMS] Политика за роли, отговорности и отчетност по поверителността превръща това в контролиран работен поток. Тя изисква одобрение от висшето ръководство преди възлагане на чувствителни съвместявания на роли:
„[Всички] Висшето ръководство ТРЯБВА да одобри в REG01 съвместявания на роли, включващи ръководител по поверителност / мениджър на PIMS, длъжностно лице по защита на данните / съветник по поверителност, ръководител по информационна сигурност, координатор по реагиране при инциденти или вътрешен одит / преглеждащ по съответствие, преди възлагането им.“
Този цитат е от Privacy Roles, Responsibilities and Accountability Policy, раздел „Съвместяване на роли, разделение и независимост“, клауза на политиката 4.2.2.
Тя също изисква компенсиращи контроли за неизбежни конфликти:
„[Всички] Ръководителят по поверителност / мениджърът на PIMS ТРЯБВА да запише в REG12 компенсиращите контроли за неизбежни конфликти при разделението на задълженията, преди да одобри съвместяване на роли.“
Този цитат е от Privacy Roles, Responsibilities and Accountability Policy, раздел „Съвместяване на роли, разделение и независимост“, клауза на политиката 4.2.4.
И изисква бързо регистриране на опасения за независимостта:
„[Всички] Длъжностното лице по защита на данните / съветникът по поверителност ТРЯБВА да запише в REG12 опасения относно независимостта на ролята или опасения за конфликт на интереси в рамките на пет работни дни от идентифицирането им.“
Този цитат е от Privacy Roles, Responsibilities and Accountability Policy, раздел „Съвместяване на роли, разделение и независимост“, клауза на политиката 4.2.5.
Това е разликата между документация за поверителност и управление на поверителността. Политиката не казва просто „DPO трябва да бъде независим“. Тя дефинира кой одобрява съвместявания на роли, къде се регистрират конфликтите, колко бързо трябва да се записват опасенията за независимостта и как се прилагат компенсиращи контроли.
[DP] Политика за защита на данните и поверителност допълнително утвърждава изискването за независимост:
„Действа независимо, за да осъществява надзор върху съответствието с регулациите за защита на данните.“
Този цитат е от Enterprise Data Protection and Privacy Policy, раздел „Роли и отговорности“, клауза на политиката 4.2.1.
Практическа матрица за конфликт на интереси при DPO
Опростена матрица на конфликтите помага на ръководството да реши кои съвместявания на роли са приемливи, кои изискват смекчаване и кои трябва да бъдат забранени.
| Роля 1 | Роля 2 | Ниво на конфликт | Препоръчано действие или компенсиращи контроли |
|---|---|---|---|
| Ръководител на ИТ или CIO | Длъжностно лице по защита на данните | Високо | Избягвайте, когато е възможно. DPO не трябва да осъществява надзор върху същата инфраструктурна функция, която управлява |
| CISO или ръководител по информационна сигурност | Длъжностно лице по защита на данните | Високо | Документирайте в REG01 само ако е неизбежно; използвайте външен преглед по поверителност за нарушения и DPIA |
| Ръководител на маркетинга | Длъжностно лице по защита на данните | Високо | Избягвайте. Маркетингът често определя целите и средствата за използване на клиентски данни |
| Ръководител на ЧР | Длъжностно лице по защита на данните | Високо | Избягвайте. ЧР управлява чувствителни данни на служители и свързани политики |
| Служител от вътрешния одит | Длъжностно лице по защита на данните | Високо | Избягвайте. Вътрешният одит трябва да може независимо да преглежда функцията на DPO |
| Правен консултант | Длъжностно лице по защита на данните | Средно | Оценете внимателно, документирайте в REG01 и отделете съветите на DPO от адвокатската тайна, когато е необходимо |
| Ръководител по съответствие | Длъжностно лице по защита на данните | Средно | Оценете внимателно, дефинирайте мандат, линия на докладване и контроли за независим преглед |
| Външен консултант | Длъжностно лице по защита на данните | Ниско | Често е ефективно, ако договорът гарантира независимост, достъп, ресурси и права за ескалация |
Матрицата не замества управлението. Тя е инструмент за първоначална оценка, който захранва одобренията в REG01, опасенията в REG12, прегледа от ръководството и планирането на вътрешния одит.
Пет стъпки за управление на конфликти при DPO преди одиторите да ги открият
Когато клиент попита: „Нашият DPO е и ръководител по сигурността. Приемливо ли е това?“, отговорът зависи от доказателствата.
Стъпка 1: Запишете съвместяването на роли в REG01
Започнете с регистъра за възлагане на роли. Запишете лицето, формалната роля, линията на докладване, делегираните правомощия, оперативните отговорности, свързани с поверителността, статуса на одобрение и датата за преглед.
| Поле в REG01 | Примерно съдържание |
|---|---|
| Лице | Jane Smith |
| Роля 1 | Длъжностно лице по защита на данните / съветник по поверителност |
| Роля 2 | Ръководител по информационна сигурност |
| Роля 3 | Координатор по реагиране при инциденти |
| Изисква се одобрение | Изисква се одобрение от висшето ръководство преди възлагане |
| Първоначална оценка на конфликта | Висока за оценка на нарушение и мониторинг на достъпа, средна за преглед на DPIA |
| Решение за одобрение | Одобрено с компенсиращи контроли за 12 месеца |
| Дата за преглед | На тримесечна база и след всяко нарушение на сигурността на личните данни |
Това прилага изискването на [PIMS] Политика за роли, отговорности и отчетност по поверителността за одобрение от висшето ръководство преди възлагане.
Стъпка 2: Извършете оценка на конфликта
Попитайте къде DPO може да преглежда собствената си работа.
| Въпрос | Ако отговорът е „да“, има конфликт |
|---|---|
| Одобрява ли DPO дейността по обработване, която по-късно наблюдава? | Да |
| Управлява ли DPO екипа, чийто отказ може да трябва да оспори? | Да |
| Решава ли DPO тежестта на нарушението и същевременно притежава ли показатели за отстраняване? | Да |
| Има ли DPO търговски или оперативни KPI, свързани с одобрението? | Да |
| Може ли DPO да ескалира директно до висшето ръководство без филтриране? | Ако не, има опасение за независимостта |
Целта не е да се създаде перфектна организационна структура. Целта е да се предотвратят самоодобрение, скрито влияние и слаба ескалация.
Стъпка 3: Запишете компенсиращите контроли в REG12
Ако организацията не може незабавно да раздели ролите, запишете контролите в REG12.
| Конфликт | Компенсиращ контрол |
|---|---|
| DPO е и координатор по реагиране при инциденти | Правен консултант или външен съветник по поверителност преглежда решенията за уведомяване при нарушение на сигурността на личните данни |
| DPO е и ръководител по информационна сигурност | Вътрешният одит независимо тества доказателствата от мониторинга на поверителността всяко тримесечие |
| DPO одобрява достъп до журнали за поверителност | Друг мениджър извършва преглед на достъпа чрез неизменяеми журнали |
| DPO подпомага DPIA | Одобрението на DPIA изисква потвърждение от собственик на продукт, правен отдел, функция по поверителност и висше ръководство |
| DPO участва в избора на доставчик | Снабдяването или комитетът по риска извършва независима надлежна проверка на доставчиците относно поверителността |
Това е съгласувано с [SME-ISP] Политика за информационна сигурност за МСП:
„Никоя задача не може да бъде делегирана по начин, който премахва надзора или нарушава разделението на задълженията (напр. едно лице не трябва само да одобрява и изпълнява едно и също високорисково действие).“
Този цитат е от SME Information Security Policy-sme, раздел „Роли и отговорности“, клауза на политиката 4.5.3.
То също е съгласувано с [P02S] Политика за роли и отговорности в управлението за МСП:
„Делегирането не трябва да премахва надзора или да допуска неоторизирано самоодобрение.“
Този цитат е от SME Governance Roles and Responsibilities Policy-sme, раздел „Роли и отговорности“, клауза на политиката 4.5.2.
Стъпка 4: Документирайте съветите на DPO и опасенията за независимостта
Честа одитна слабост е, че съветите на DPO се дават на срещи, в чатове или неформални разговори, но нищо не се записва. [PIMS] Политика за роли, отговорности и отчетност по поверителността изисква:
„[Всички] Длъжностното лице по защита на данните / съветникът по поверителност ТРЯБВА да записва в REG12 съвети по поверителност, наблюдения от мониторинг или опасения за независимостта, когато това е поискано за съществени решения по поверителност или опасения за съответствие.“
Този цитат е от Privacy Roles, Responsibilities and Accountability Policy, раздел „Роли и отговорности“, клауза на политиката 5.1.3.
Тя изисква и своевременен преглед на ескалирани конфликти:
„[Всички] Длъжностното лице по защита на данните / съветникът по поверителност ТРЯБВА да прегледа ескалираните съществени конфликти на роли и да запише съвет в REG12 в рамките на 10 работни дни от ескалацията.“
Този цитат е от Privacy Roles, Responsibilities and Accountability Policy, раздел „Управление и надзор“, клауза на политиката 6.1.3.
| Поле в REG12 | Примерно съдържание |
|---|---|
| Решение | Пускане на функция за анализ на поведението на клиентите |
| Съвет на DPO | Да се продължи само след приключване на DPIA, актуализирано уведомление за поверителност, ограничение на срока за съхранение, механизъм за отказ и ограничение на достъпа |
| Опасение за независимостта | Собственикът на продукта поиска одобрение за пускане преди приключване на DPIA |
| Ескалация | Ескалирано до мениджъра на PIMS и главния изпълнителен директор |
| Резултат | Пускането е отложено до прилагане на предпазните мерки |
| Връзки към доказателства | DPIA, актуализация на уведомлението за поверителност, преглед на достъпа, одобрение от ръководството |
Този запис защитава организацията, но защитава и DPO. Той доказва, че е даден независим съвет, дори когато бизнесът е предпочитал по-бърз подход.
Стъпка 5: Включете конфликтите в прегледа от ръководството и вътрешния одит
Независимостта на DPO не е еднократна проверка при назначаване. Тя трябва да се преглежда чрез преглед от ръководството, вътрешен одит и проследяване на коригиращи действия.
[P02] Политика за роли и отговорности в управлението включва в прегледа на съответствието:
„Преглед на всички конфликти на интереси или неоторизирани делегации“
Този цитат е от Enterprise Governance Roles and Responsibilities Policy, раздел „Прилагане и съответствие“, клауза на политиката 8.2.1.3.
[DP] Политика за защита на данните и поверителност също поддържа участието на висшето ръководство при изключения:
„Изключенията трябва да бъдат одобрени от длъжностното лице по защита на данните (DPO) и висшето ръководство преди внедряване.“
Този цитат е от Enterprise Data Protection and Privacy Policy, раздел „Третиране на риска и изключения“, клауза на политиката 7.3.1.
Това двойно одобрение е важно. DPO консултира и наблюдава. Висшето ръководство притежава решението и остатъчния риск.
Как Zenith Blueprint и Zenith Controls картографират проблема
Zenith Blueprint поставя възлагането на роли в ранния етап на фазата „Основи и лидерство на ISMS“, стъпка 4: „Роли и отговорности в ISMS“. В него се отбелязва:
„Ако е приложимо (особено ако обработвате лични данни, може по закон да имате длъжностно лице по защита на данните). То гарантира, че ISMS е съгласувана със законодателството за поверителност, и може да координира одити.“
Стъпка 4 също подчертава, че мениджърът на ISMS или служителят по сигурността често координира внедряването, оценките на риска, одитите и програмите за осведоменост, и „трябва да има директен достъп до висшето ръководство за ескалация на въпроси“. Същият принцип се прилага за DPO. Съветник по поверителност, който не може да достигне до висшето ръководство, когато продуктов екип отхвърли препоръки от DPIA, не е реално независим.
Във фазата „Контроли в действие“, стъпка 22: „Организационни контроли“, Zenith Blueprint обяснява разделението на задълженията:
„Разделението на задълженията (SoD) е основен принцип на контрол, предназначен да намали риска от измами, грешки или злоупотреби, като гарантира, че никое лице няма прекомерни правомощия или достъп, които могат да бъдат използвани без откриване.“
Той също посочва реалността при МСП:
„Когато броят на служителите ограничава функционалното разделяне, организациите могат да приложат компенсиращи контроли. Те може да включват многостъпкови одобрения, автоматизирани прегледи на работни потоци или журналиране за одит с редовен преглед. Целта не е съвършенство, а осъзнатост.“
Стъпка 23 свързва служителите по поверителност, правните съветници и DPO с операциите по поверителност:
„Служителите по поверителност, правните съветници или длъжностните лица по защита на данните (DPO) трябва да участват в определянето на начина, по който се обработват личните данни, особено при международни предавания, трансгранично обработване или права на субекти на данни като достъп, коригиране и изтриване.“
Той продължава с доказателствата, които одиторите очакват:
„От гледна точка на одита този контрол все по-често е във фокус. Одитори, регулатори и клиенти искат да видят:
✓ Къде се намира PII,
✓ Кое правно основание урежда обработването му,
✓ Как е ограничен достъпът,
✓ Как се докладват инцидентите,
✓ И как организацията зачита правата и поддържа прозрачност.“
Zenith Blueprint също обяснява независимия преглед като контрол за обективност:
„Той изисква подходът на организацията към управление на информационната сигурност да бъде предмет на независим преглед на планирани интервали, така че слепите петна да могат да бъдат разкрити, допусканията да бъдат оспорени, а доверието да бъде валидирано през свеж поглед.“
И пояснява:
„„Независим“ в този контекст не винаги означава външен. Означава функционално отделен от оперативната собственост върху ISMS.“
За независимостта на DPO това означава, че вътрешният одит на управлението на поверителността не трябва да се извършва от лицето, чиято роля на DPO е предмет на преглед. Ако организацията е твърде малка, използвайте външен проверяващ или равнопоставен преглед, одобрен от висшето ръководство.
Zenith Controls идентифицира свързаните с темата контроли по ISO/IEC 27002:2022 като „Роли и отговорности по информационна сигурност“ 5.2, „Разделение на задълженията“ 5.3 и „Независим преглед на информационната сигурност“ 5.35. Това картографиране е важно, защото независимостта по поверителност не е изолирана от управлението на ISMS. Тя е част от същата одитна логика: дефинирайте отговорностите, разделете несъвместимите задължения и преглеждайте независимо системата за управление.
Съпоставяне между рамки за ISO 27701, GDPR, NIS2, DORA, NIST CSF и COBIT 19
Независимостта на DPO обикновено се обсъжда като въпрос по GDPR, но одиторите и регулаторите виждат същата слабост през множество рамки.
| Перспектива на рамката | Какво пита на практика | Доказателства за управление на конфликт при DPO |
|---|---|---|
| ISO/IEC 27701:2025 PIMS | Дефинирани ли са и функционират ли ролите, отговорностите, мониторингът и отчетността по поверителността? | Назначаване на DPO, възлагане на роли в REG01, опасения за независимостта в REG12, протоколи от прегледи от ръководството на PIMS |
| GDPR | Може ли администраторът да демонстрира отчетност, управление на поверителността и подходящи предпазни мерки? | Записи за съвети на DPO, оценка на конфликта, доказателства за оспорване при DPIA, журнали за съвети при нарушения |
| ISO/IEC 27001:2022 и ISO/IEC 27002:2022 | Възложени ли са отговорности, разделени ли са задълженията и извършват ли се независими прегледи? | RACI матрица, оценка на SoD, независимост на вътрешния одит, списък на собственици на контроли |
| NIS2 | Одобрява ли и надзирава ли ръководството мерки за риск, обучение, обработване на инциденти, непрекъсваемост и контроли във веригата на доставки? | Решения на ръководния орган, записи за ескалация, протоколи за управление на киберсигурността и поверителността |
| DORA | Надзирава ли ръководният орган ИКТ риск, риск от трети страни, вътрешен одит, устойчивост и докладване на инциденти? | Карта на ИКТ ролите, преглед на конфликти с трети страни, план за вътрешен одит, проследяване на коригиращи действия |
| NIST CSF 2.0 | Интегрирани ли са управлението, правните задължения, апетитът за риск, ролите и надзорът в ERM? | Текущ и целеви профил, регистър на пропуските в управлението, POA&M, доказателства за преглед на политиките |
| COBIT 19 и одитна перспектива на ISACA | Разделени ли са правата за вземане на решения, независимостта на уверението, собствеността върху риска и отговорностите за мониторинг? | Матрица на правата за вземане на решения, план за уверение, регистри на конфликти, проследяване на отстраняването |
NIS2 Article 20 възлага на ръководните органи отговорността да одобряват и надзирават мерките за управление на риска за киберсигурността и обучението. Article 21 изисква подходящи технически, оперативни и организационни мерки, включително анализ на риска, обработване на инциденти, непрекъсваемост, сигурност на веригата на доставки, оценка на ефективността, обучение, криптография, сигурност на ЧР, контрол на достъпа, управление на активите, MFA когато е приложимо, и сигурни комуникации. Ако DPO е и оперативен собственик по сигурността, надзорът върху поверителността трябва въпреки това да бъде запазен.
DORA Article 5 изисква финансовите субекти да поддържат вътрешна рамка за управление и контрол за управление на ИКТ риска, като ръководният орган носи крайната отговорност. Article 28 изисква управление на ИКТ риска от трети страни, надлежна проверка, договорни предпазни мерки, оценка на риска от концентрация и отчитане на конфликтите на интереси. DPO, който също притежава ИКТ риска или одобрението на трети страни, създава управленски проблем, който трябва да бъде контролиран.
NIST CSF 2.0 поставя тези въпроси във функцията GOVERN: правните, регулаторните, договорните, свързаните с поверителността и гражданските свободи задължения трябва да бъдат разбрани и управлявани, ролите трябва да са ясни, трябва да има надзор и рискът за киберсигурността трябва да бъде съгласуван с управлението на корпоративния риск. Конфликт при DPO може да се третира като пропуск в управлението, да му се възложи собственик, да се документира в план за действия и да се наблюдава.
Как одиторите тестват независимостта на DPO
Различните одитори използват различен език, но въпросите им се сближават.
| Профил на одитора | Вероятен одитен въпрос | Доказателства, които Clarysec подготвя |
|---|---|---|
| Одитор по ISO/IEC 27701:2025 PIMS | Възложени ли са отговорностите по поверителност, идентифицирани ли са конфликтите и независим ли е мониторингът? | Карта на ролите в PIMS, одобрения в REG01, регистри на конфликти в REG12, записи за съвети по поверителност |
| Одитор по ISO/IEC 27001:2022 | Дефинирани ли са ролите по информационна сигурност, разделени ли са несъвместимите задължения и извършен ли е независим преглед? | RACI, SoD матрица, план за вътрешен одит, действия от прегледа от ръководството |
| Одитор или регулатор с фокус върху GDPR | Може ли организацията да демонстрира отчетност и независими съвети от DPO? | Назначаване на DPO, записи за ескалация, съвети по DPIA, съвети при нарушения, надзор върху обучението |
| Оценител по NIST CSF | Интегрирани ли са управленските роли, правните задължения, толерансът към риск и надзорът в ERM? | Текущ и целеви профил по CSF, план за пропуски в управлението, регистър на риска |
| Проверяващ по DORA | Надзирава ли ръководството ИКТ риска и конфликтите в управлението на трети страни и инциденти? | Рамка за управление на ИКТ, план за вътрешен одит, роли за докладване на инциденти, преглед на конфликти при доставчици |
| Проверяващ по NIS2 | Одобрява ли и надзирава ли ръководният орган мерки за риск, обучение и обработване на инциденти? | Протоколи от заседания на съвета, записи за обучение, мерки за риск, доказателства за ескалация |
| Одитор по COBIT 19 или ISACA | Разделени ли са правилно правата за вземане на решения, независимостта на уверението и отговорностите за мониторинг? | Харта за управление, карта за уверение, регистър на конфликтите, проследяване на отстраняването |
Одиторът няма да приеме „нашият DPO е независим“ като достатъчен отговор. Отговорът трябва да бъде основан на доказателства: ето назначаването, ето картата на ролите, ето оценката на конфликта, ето одобрението, ето компенсиращите контроли, ето регистъра със съвети, ето проследимостта на ескалацията и ето записа от прегледа от ръководството.
Обучение: независимостта се проваля, когато хората заобикалят DPO
DPO не може да остане независим, ако организацията не знае кога да го включи. Продуктови мениджъри, инженери по сигурността, ЧР, търговски операции, снабдяване, поддръжка и лица, реагиращи при инциденти, се нуждаят от практически критерии за задействане.
[DPS] Политика за защита на данните и поверителност за МСП описва DPO или функцията по поверителност като подпомагаща:
„Подпомага оценките на риска, обучението и прилагането на политиките“
Този цитат е от SME Data Protection and Privacy Policy-sme, раздел „Роли и отговорности“, клауза на политиката 4.2.3.
[AT-SME] Политика за осведоменост и обучение по информационна сигурност за МСП свързва това с очакванията за обучение по GDPR:
„Article 39 – Изисква от длъжностните лица по защита на данните да надзирават осведомеността и обучението, когато е приложимо“
Този цитат е от SME Information Security Awareness and Training Policy-sme, раздел „Референтни стандарти и рамки“, клауза на политиката 11.4.2.
Обучението трябва да научи персонала да включва DPO преди:
- Стартиране на нова цел на обработването
- Използване на специални категории данни, биометрични данни, здравни данни, данни за измами или данни, свързани с нарушения
- Въвеждане на обработващ лични данни за клиентски данни
- Извършване на DPIA, оценки на предаването, промени в сроковете за съхранение или актуализации на уведомления за поверителност
- Закриване на инцидент, при който може да е настъпил неоторизиран достъп до лични данни
- Вземане на бизнес решение, което отхвърля или изменя съвет по поверителност
Последната точка е важна. Отчетността не изисква бизнесът да се съгласява с всяка препоръка на DPO. Тя изисква организацията да записва съвети, да документира решения и да показва кой е приел остатъчния риск.
Изградете пакет с доказателства за независимостта на DPO
За готовност по ISO/IEC 27701:2025 и GDPR Clarysec препоръчва пакет с доказателства за независимостта на DPO. Той трябва да бъде достатъчно лек за МСП, но достатъчно надежден за корпоративни одити.
| Доказателствен елемент | Цел |
|---|---|
| Запис за назначаване на DPO или съветник по поверителност | Показва формалното възлагане на ролята, обхвата, правомощията и линията на докладване |
| Одобрение в REG01 за съвместяване на роли | Показва, че висшето ръководство е одобрило чувствителни съвместявания на роли преди възлагането |
| Оценка на конфликт на роли | Показва, че несъвместимите задължения са идентифицирани и оценени |
| Регистър в REG12 за конфликти и опасения за независимостта | Показва опасения, съвети, компенсиращи контроли и разрешаване |
| Регистър на съветите на DPO | Показва принос по поверителност при DPIA, инциденти, предавания, права, срокове за съхранение и обработващи лични данни |
| Път за ескалация | Показва, че DPO може да достигне до висшето ръководство без намеса |
| Проверка на независимостта при вътрешен одит | Показва, че управлението на поверителността не се преглежда единствено от оперативните собственици |
| Протоколи от прегледи от ръководството | Показва, че ръководството е прегледало конфликти, изключения, инциденти и действия за подобрение |
| Записи за обучение | Показва, че персоналът знае кога да включи DPO |
| Инструмент за проследяване на коригиращи действия | Показва, че нерешените конфликти се третират и проследяват |
Този пакет с доказателства се съпоставя директно с 30-стъпковия подход на Zenith Blueprint. Стъпка 4 установява ролите и отговорностите. Стъпки 8 до 16 изграждат механизма за риск и възлагат собственици на риска. Стъпка 22 операционализира разделението на задълженията. Стъпка 23 разглежда правните интерфейси и интерфейсите по поверителност, включително участието на DPO и независимия преглед.
Превърнете независимостта на DPO в доказателства, а не в намерение
Ако вашият DPO, съветник по поверителност, ръководител по сигурността, правен консултант, мениджър по съответствие или вътрешен одитор носи повече от една „шапка“, не чакайте одит или инцидент да разкрие конфликта.
Започнете с три действия тази седмица:
- Картографирайте всяка роля по управление на поверителността и всяка оперативна роля в REG01.
- Идентифицирайте къде DPO или съветникът по поверителност може да одобрява, изпълнява, наблюдава или одитира една и съща дейност.
- Запишете неизбежните конфликти и компенсиращите контроли в REG12, след което ги включете в прегледа от ръководството.
Clarysec може да ви помогне да операционализирате това чрез Политика за роли, отговорности и отчетност по поверителността, Политика за роли и отговорности в управлението, Политика за роли и отговорности в управлението за МСП, Политика за защита на данните и поверителност, Zenith Blueprint: 30-стъпкова пътна карта за одитори и Zenith Controls: ръководство за съответствие между рамки.
Независимостта на DPO не е бюрокрация. Тя гарантира, че съветите по поверителност могат да бъдат чути, конфликтите могат да бъдат оспорени и отчетността може да бъде доказана, когато това е най-важно.
Изтеглете набора от политики на Clarysec, използвайте Zenith Blueprint, за да изградите своя работен поток за доказателства, или поискайте оценка на готовността, за да проверите дали вашият модел за независимост на DPO би издържал на проверка по ISO/IEC 27701:2025, GDPR, NIS2, DORA, NIST CSF 2.0 и COBIT 19.
About the Author
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