Управление на ОВЗД за ISO 27001, NIS2 и DORA
Четвъртък е, 17:40 ч., и от Мария, директор по информационна сигурност (CISO) в бързо растяща финтех компания, се иска да одобри релийз преди края на тримесечието.
Продуктовият екип го представя като пробив: функция за удостоверяване на плащания, базирана на биометрия и поведенчески анализ, която ще направи клиентския достъп безпроблемен и ще намали измамите. Инженерният екип твърди, че не се създава нова основна база данни. Продажбите казват, че регулиран финансов клиент чака. Мениджърът по релийза вече е маркирал заявката като стандартна промяна.
Тогава длъжностното лице по защита на данните (DPO) задава три въпроса.
Ще комбинира ли функцията биометрични или поведенчески данни с атрибути на акаунта? Ще получава ли облачен подизпълнител телеметрия или сигнали за автентикация? Оценил ли е някой дали промяната създава висок риск за физическите лица?
В стаята настъпва тишина.
Мария има регистър на риска по ISO/IEC 27001:2022. Правният екип има регистър на дейностите по обработване по GDPR. Екипът по доставки има въпросник за доставчик. Облачният екип има преглед на сигурността на доставчика. Мениджърът по промените има заявка. Управителният съвет току-що е бил информиран за отчетността по NIS2 и очакванията на DORA за оперативна устойчивост.
Нито един от тези записи сам по себе си не разказва цялата история.
Това е проблемът с управлението на оценките на въздействието върху защитата на данните (ОВЗД) през 2026 г. ОВЗД не могат да стоят в папка „защита на личните данни“ в очакване на регулатор. Те трябва да се превърнат в записи на решения, които свързват GDPR Articles 25, 30, 32, 35 и 36 с доказателствата за риска по ISO/IEC 27001:2022, мерките за управление на риска за киберсигурността по NIS2, управлението на ИКТ промени по DORA, уверението от доставчици и отчетността на ниво управителен орган.
Организациите, които срещат затруднения, обикновено не пренебрегват съответствието. Те извършват отделно преглед на защитата на личните данни, преглед на сигурността, преглед на облачните услуги и преглед на промените. Организациите, които успяват, създават един проследим управленски работен поток, в който тригерите за ОВЗД, оценката на риска, надлежната проверка на доставчици, съпоставянето с контроли, тестването и одобрението на остатъчния риск формират единна доказателствена верига.
Защо изолираните ОВЗД се провалят през 2026 г.
GDPR въведе ОВЗД като формален механизъм за оценяване на обработване, което вероятно ще доведе до висок риск за физическите лица. В много компании тя се превърна в правна задача или задача по защита на личните данни — формуляр, който се попълва, когато проектът изглежда чувствителен.
Този модел вече не може да бъде защитен.
Промяна в обработването на лични данни рядко е само събитие, свързано със защитата на личните данни. Тя също е:
- Събитие, свързано с риска за информационната сигурност по ISO/IEC 27001:2022.
- Събитие по управление на киберсигурността по NIS2, ако са засегнати мрежови и информационни системи, доставчици или контроли за сигурност.
- Събитие, свързано с ИКТ промяна и устойчивост по DORA, за финансови субекти и релевантни доставчици на ИКТ услуги.
- Събитие, свързано с риска при доставчици и облачни услуги, когато са ангажирани обработващи лични данни, подизпълнители по обработване, приложно-програмни интерфейси (API), SDK или хоствани услуги.
Когато тези оценки се извършват отделно, пропуските стават опасни. Екипът по защита на личните данни може да одобри ОВЗД, без да разбира уязвимостите в биометричен SDK. ИТ екипът може да пусне промяна, без да осъзнае, че тя включва данни от специални категории или поведенческо наблюдение. Екипът по сигурност може да прегледа облачна услуга, без да я свърже с конкретните рискове за правата и свободите, идентифицирани в ОВЗД.
Отговорът не е повече документация. Отговорът е интегрирано управление.
ОВЗД трябва да се третира като тригер, който стартира координиран работен поток за риска между защитата на личните данни, сигурността, облачните услуги, доставчиците, инженерните екипи, правния отдел и ръководството.
Основата в GDPR: управлението на ОВЗД започва с осведоменост за обработването
ОВЗД не може да бъде достоверна, ако организацията не може да обясни какво обработва, защо го обработва, кой го получава и колко дълго се съхранява.
Отчетността по GDPR изисква повече от декларация за намерение. Article 5 установява основни принципи като законосъобразност, добросъвестност, прозрачност, ограничение на целите, свеждане на данните до минимум, точност, ограничение на съхранението, цялостност и поверителност. Той също изисква администраторът да доказва съответствие. Article 25 изисква защита на личните данни на етапа на проектиране и по подразбиране. Article 30 изисква регистри на дейностите по обработване. Article 32 изисква сигурност на обработването. Article 35 изисква ОВЗД, когато обработването вероятно ще доведе до висок риск. Article 36 изисква предварителна консултация, когато високият риск остава без достатъчно смекчаване.
За SaaS, финтех, облачни организации и доставчици на управлявани услуги това означава, че всяка съществена промяна трябва да се проверява за въздействие върху защитата на личните данни. Тригерът не е дали проектът е етикетиран като „защита на личните данни“. Тригерът е дали промяната засяга лични данни, цел на обработването, правно основание, получатели, срок за съхранение, права за достъп, доставчици, облачни локации или остатъчен риск.
Политиката за защита на данните и поверителност - МСП на Clarysec превръща това в оперативно изискване:
„Координаторът по защита на личните данни трябва да поддържа регистър на всички дейности по обработване на лични данни, включително категории данни, цел, правно основание и срокове за съхранение.“
От раздел „Изисквания за управление“, клауза на политиката 5.2.1.
Същата политика за МСП вгражда защитата на личните данни в предоставянето на услуги:
„Защита на личните данни на етапа на проектиране и по подразбиране трябва да се прилага във всички нови системи и услуги.“
От раздел „Изисквания за управление“, клауза на политиката 5.3.1.
За корпоративни среди Политиката за защита на данните и поверителност на Clarysec прави контролния праг за ОВЗД изричен:
„Всички съществени промени в системи или процеси, включващи лично идентифицираща информация (PII), изискват документирана оценка на въздействието върху защитата на данните (DPIA), прегледана от длъжностното лице по защита на данните (DPO).“
От раздел „Изисквания за управление“, клауза на политиката 5.6.
Тази клауза е мостът между отчетността по GDPR и оперативния контрол. Тя премества ОВЗД от последваща правна формалност към управление на проекти и одобрение на промени.
Свързване на ОВЗД с доказателствата за риска по ISO/IEC 27001:2022
ISO/IEC 27001:2022 предоставя структурата на системата за управление, от която се нуждае управлението на ОВЗД.
Клаузи 4.1 до 4.4 изискват организацията да разбира своя контекст, заинтересованите страни, изискванията, обхвата на системата за управление на информационната сигурност (СУИС) и взаимодействащите процеси. Законодателството за защита на личните данни, клиентските договори, задълженията по NIS2, изискванията на DORA, задълженията на обработващите лични данни и зависимостите от доставчици принадлежат към този контекст.
Клаузи 5.1 до 5.3 изискват лидерство, съгласуване на политиките, ресурси, роли и отговорности. Именно тук много ОВЗД се провалят. DPO може да идентифицира висок риск, но без собственици на риска, правила за ескалация и подкрепени от ръководството критерии за приемане ОВЗД се превръща в документ вместо в решение.
Клаузи 6.1.1 до 6.1.3 изискват планиране, основано на риска, документиран процес за оценка на риска за информационната сигурност, критерии за приемане на риска, собственици на риска, планиране на третирането, избор на контроли, Декларация за приложимост и одобрение на остатъчния риск. Това е структурата, която ОВЗД трябва да използва.
ОВЗД може да идентифицира вреди като риск от профилиране, неоторизирано разкриване, незаконосъобразна вторична употреба, измама с идентичност, дискриминация или прекомерно съхранение. СУИС превежда тези вреди в рискови сценарии, анализ на вероятност и въздействие, действия за третиране, контроли от Annex A и одобрения на остатъчния риск.
Политиката за управление на риска - МСП на Clarysec дефинира минималната дисциплина:
„Всеки запис за риск трябва да включва: описание, вероятност, въздействие, оценка, собственик и план за третиране.“
От раздел „Изисквания за управление“, клауза на политиката 5.1.2.
За корпоративни среди Политиката за управление на риска на Clarysec свързва планирането на третирането с доказателствата по ISO/IEC 27001:2022:
„Длъжностното лице по управление на риска трябва да гарантира, че мерките за третиране са реалистични, ограничени във времето и съпоставени с контролите от ISO/IEC 27001 Annex A.“
От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.4.2.
Zenith Blueprint: 30-стъпкова пътна карта за одитори, фаза „Управление на риска“, стъпка 13, „Планиране на третирането на риска и Декларация за приложимост“, обяснява ясно ролята на SoA:
„SoA на практика е свързващ документ: той свързва вашата оценка/третиране на риска с реалните контроли, които имате.“
Това е моделът на готова за одит ОВЗД. Констатация от ОВЗД не трябва да приключва с „рискът е приет“. Тя трябва да се съпостави с регистъра на риска, плана за третиране, Декларацията за приложимост, прегледа на доставчика, надлежната проверка на облачните услуги, заявката за промяна, доказателствата от тестване и управленското решение.
Един запис на решение, множество резултати за съответствие
Зрелият работен поток за управление на ОВЗД не дублира всяка регулация. Той събира доказателства веднъж и ги използва интелигентно повторно.
| Въпрос за управлението на ОВЗД | Създадени доказателства | Доказателства по ISO/IEC 27001:2022 | Стойност за отчетността по GDPR | Стойност за NIS2 или DORA |
|---|---|---|---|---|
| Какво обработване се променя? | Актуализация на регистъра на дейностите по обработване и входящ запис за ОВЗД | Доказателства за обхват, контекст, активи и процеси | Подкрепя регистрите на дейностите по обработване и защитата на личните данни на етапа на проектиране | Показва осведоменост за оперативния риск |
| Какво може да навреди на физическите лица? | Сценарий за риск за защитата на личните данни и оценка на въздействието | Резултат от оценката на риска и собственик на риска | Подкрепя обосновката на ОВЗД и отчетността | Съгласува се с риск-базираното управление на киберсигурността |
| Кои контроли намаляват риска? | Предпазни мерки, технически и организационни мерки (TOMs) и план за третиране | Декларация за приложимост, план за третиране и статус на внедряване на Annex A | Подкрепя сигурността на обработването и защитата на личните данни по подразбиране | Подкрепя мерките за киберсигурност и ИКТ риск |
| Кой друг обработва или има достъп до данните? | Преглед на доставчик, обработващ лични данни и облачна услуга | Доказателства за контроли при доставчици и облачни услуги | Подкрепя надзора върху обработващия и управлението на трансферите | Подкрепя риска във веригата на доставки и ИКТ риска от трети страни |
| Какво се промени в продукционна среда? | Запис за промяна, доказателства от тестване и одобрение | Доказателства за управление на промените и оперативен контрол | Показва, че контролите са разгледани преди релийза | Подкрепя очакванията за риск при промени и устойчивост |
| Кой прие остатъчния риск? | Одобрение от DPO, собственик на риска и ръководството | Приемане на остатъчния риск и входни данни за преглед от ръководството | Показва отчетно вземане на решения | Подкрепя надзора от съвета или управителния орган |
Тази доказателствена верига се съгласува пряко с ISO/IEC 27001:2022 клауза 8.1, която изисква планирани и контролирани оперативни процеси, документирани доказателства, контрол на планираните промени и преглед на непредвидените промени. Клауза 8.2 изисква оценки на риска на планирани интервали или когато се предлагат или настъпват съществени промени. Клауза 8.3 изисква внедряване на плана за третиране на риска. След това клауза 9 превръща доказателствата в уверение чрез мониторинг, измерване, вътрешен одит и преглед от ръководството.
Политиката за защита на данните и поверителност - МСП прави сроковете изрични:
„Координаторът по защита на личните данни трябва да оценява рисковете за защитата на личните данни ежегодно и при съществени промени в системите.“
От раздел „Третиране на риска и изключения“, клауза на политиката 7.1.1.
Ако съществена промяна, свързана с лични данни, не задейства проверка за ОВЗД и повторна оценка в СУИС, процесът на управление е непълен.
NIS2: управлението на ОВЗД се превръща в управленска отчетност
NIS2 увеличава управленския натиск върху организациите в съществени и важни сектори. Тя се прилага за много публични и частни субекти в изброени сектори, които отговарят на релевантните прагове за размер, и може да се прилага независимо от размера в специфични случаи, като доставчици на удостоверителни услуги, DNS, регистри на TLD, публични електронни съобщителни услуги, единствени доставчици на съществени услуги или субекти със системна рискова роля.
За управлението на ОВЗД ключовият въпрос не е само обхватът. Ключовият въпрос е отговорността на ръководството.
NIS2 Article 20 изисква управителните органи на съществени и важни субекти да одобряват мерките за управление на риска за киберсигурността, да контролират тяхното внедряване и да преминават обучение. Article 21 изисква подходящи и пропорционални технически, оперативни и организационни мерки, основани на рисковата експозиция, размера, вероятността, степента на сериозност, общественото и икономическото въздействие, актуалното състояние на техниката и релевантните стандарти.
Article 21(2) включва области, които често се припокриват с резултатите от ОВЗД, включително:
- Анализ на риска и политики за сигурност на информационните системи.
- Обработване на инциденти.
- Непрекъсваемост на дейността и управление на кризи.
- Сигурност на веригата на доставки.
- Сигурност при придобиване, разработка и поддръжка на мрежови и информационни системи.
- Обработване и оповестяване на уязвимости.
- Политики за оценка на ефективността на мерките за управление на риска за киберсигурността.
- Киберхигиена и обучение.
- Криптография и шифроване.
- Сигурност на човешките ресурси, контрол на достъпа и управление на активите.
- MFA, непрекъсната автентикация, защитени комуникации и защитени аварийни комуникации.
Следователно ОВЗД за нова биометрична, поведенческо-аналитична или облачно базирана дейност по обработване трябва да задава въпроси, релевантни за NIS2. Зависи ли обработването от нов доставчик? Въвежда ли нов API, SDK, поток за идентичност или модел на достъп? Променя ли въздействието при инцидент? Изисква ли шифроване, по-силно журнализиране, проверки за сигурна разработка или одобрение от ръководството?
Практическият управленски въпрос става прост: може ли организацията да докаже, че промяна с въздействие върху защитата на личните данни е разгледана като част от управлението на риска за киберсигурността преди внедряване?
Това доказателство трябва да е видимо във входящия запис за ОВЗД, актуализирания регистър на дейностите по обработване, регистъра на риска, плана за третиране, Декларацията за приложимост, надлежната проверка на доставчици, доказателствата от тестване на сигурността, одобрението на промяната и приемането на остатъчния риск.
DORA: доказателствата за ИКТ промени и трети страни са неизбежни
DORA се прилага от 17 януари 2025 г. и създава единна рамка на ЕС за управление на ИКТ риска, докладване на съществени ИКТ-свързани инциденти, тестване на цифровата оперативна устойчивост, споделяне на информация за киберзаплахи и уязвимости, управление на ИКТ риска от трети страни и надзор върху критични доставчици на ИКТ услуги от трети страни.
За финансовите субекти DORA обикновено действа като секторно-специфичен правен акт на Съюза за управление на ИКТ риска и задълженията за докладване на инциденти, докато NIS2 остава релевантна за по-широка координация на екосистемата и за субекти извън DORA.
Управлението на ОВЗД е важно по DORA, защото обработването на лични данни обикновено съществува в ИКТ системи, услуги от трети страни, облачни среди и оперативни работни потоци.
DORA Article 5 изисква вътрешни рамки за управление и контрол за управление на ИКТ риска, с отговорност на управителния орган. Article 6 изисква документирана рамка за управление на ИКТ риска, интегрирана в общото управление на риска. Articles 8 до 14 обхващат идентифициране на активи и зависимости, защита и превенция, откриване, непрекъсваемост, резервни копия, възстановяване, извлечени поуки и кризисни комуникации.
DORA Article 28 изисква финансовите субекти да управляват ИКТ риска от трети страни като неразделна част от управлението на ИКТ риска и да запазват отговорността си при използване на ИКТ услуги. Той изисква регистри на договорите за ИКТ услуги, оценки преди сключване на договор, надлежна проверка, оценка на риска от концентрация, планиране на одит и инспекции, права за прекратяване и стратегии за изход. Article 30 изисква писмени договори с ясни описания на услугите, местонахождение на данните, защити за поверителност, цялостност и наличност, възстановяване и връщане на данни, съдействие при инциденти, сътрудничество с органите, права за прекратяване и допълнителни предпазни мерки за критични или важни функции.
За ОВЗД това променя въпроса към доставчика. „Имаме ли DPA?“ не е достатъчно. По-добрият въпрос е: можем ли да докажем, че ИКТ зависимостта, местонахождението на данните, подизпълнението, стандартите за сигурност, устойчивостта, правата на одит, поддръжката при инциденти и стратегията за изход са оценени преди одобряване на обработването?
Политиката за използване на облачни услуги на Clarysec прави този контрол преди активиране изричен:
„Всяко използване на облачни услуги трябва да премине риск-базирана надлежна проверка преди активиране, включително оценка на доставчика, валидиране на правното съответствие и прегледи за валидиране на контролите.“
От раздел „Изисквания за управление“, клауза на политиката 5.2.
ОВЗД не трябва да одобрява нов обработващ за анализи, доставчик на идентичност, биометричен SDK или облачна платформа за телеметрия, освен ако надлежната проверка на облачните услуги, правната валидация и валидирането на контролите не са завършени или изрично проследени като действия за третиране.
Опорните точки в ISO/IEC 27002:2022: защита на личните данни, проекти и промени
Zenith Controls: Ръководството за cross-compliance на Clarysec третира контролите по ISO/IEC 27002:2022 като опорни точки за cross-compliance. За управлението на ОВЗД три контрола са особено важни.
| Контрол по ISO/IEC 27002:2022 | Защо е важен за управлението на ОВЗД | Стойност за cross-compliance |
|---|---|---|
| 5.34 Поверителност и защита на PII | Изисква осведоменост и защита на личните данни през целия им жизнен цикъл | Подкрепя отчетността по GDPR, ISO/IEC 27001:2022 Annex A, мерките за риска по NIS2 и очакванията на DORA за защита на данните |
| 5.8 Информационна сигурност в управлението на проекти | Вгражда мисленето за въздействието върху сигурността и защитата на личните данни в дизайна на проекта | Подкрепя защитата на личните данни на етапа на проектиране, сигурната разработка и мерките по NIS2 за придобиване и разработка |
| 8.32 Управление на промените | Гарантира, че промените се оценяват, оторизират, тестват, внедряват и преглеждат | Подкрепя оперативния контрол по ISO, управлението на ИКТ промени по DORA и проследимостта за одит |
Записът в Zenith Controls за 5.34, „Поверителност и защита на PII“, го класифицира като превантивен, свързан с поверителност, цялостност и наличност, съгласуван с концепциите за киберсигурност Identify и Protect и обвързан със защитата на информацията плюс правни способности и способности за съответствие.
Zenith Blueprint, фаза „Контроли в действие“, стъпка 23, формулира практическата точка:
„Основата на този контрол е осведомеността за данните. Организацията трябва да знае каква PII събира, къде се намира тя, защо се обработва и кой има достъп до нея.“
Записът в Zenith Controls за 5.8, „Информационна сигурност в управлението на проекти“, го класифицира като превантивен, свързан с поверителност, цялостност и наличност, съгласуван с Identify и Protect и позициониран в областите на управление, екосистема и защита.
Zenith Blueprint, фаза „Контроли в действие“, стъпка 22, посочва:
„Целта на този контрол не е да затрупа проектите с бюрокрация. Целта е да гарантира, че сигурността се третира като входно изискване при дизайна, а не като етап на тестване.“
Защитата на личните данни трябва да се третира по същия начин. ОВЗД след въвеждане в експлоатация често е доклад за щети. ОВЗД по време на дизайна е превенция на риска.
Записът в Zenith Controls за 8.32, „Управление на промените“, го класифицира като превантивен, свързан с поверителност, цялостност и наличност, съгласуван с Protect и обвързан със сигурността на приложенията плюс способности за сигурност на системите и мрежите.
Zenith Blueprint, фаза „Контроли в действие“, стъпка 21, е директен:
„Промяната е неизбежна, но в киберсигурността неконтролираната промяна е опасна.“
Политиката за управление на промените - МСП на Clarysec улавя тригера:
„Ако промяна включва чувствителни данни, права за достъп до системи или външни интеграции, се изисква преглед на въздействието върху сигурността. Определеният контакт по сигурност или съответствие трябва да оцени дали промяната въвежда допълнителни рискове и да препоръча допълнителни предпазни мерки.“
От раздел „Третиране на риска и изключения“, клауза на политиката 7.5.1.
За корпоративни среди Политиката за управление на промените на Clarysec задава очакването към Консултативния съвет по промените:
„Оценявайте промените за рискове за сигурността и съответствието преди одобрение от Консултативния съвет по промените.“
От раздел „Роли и отговорности“, клауза на политиката 4.6.1.
Практически пример: одобряване на функция за биометричен анализ
Мария не се нуждае от три отделни управленски проекта. Тя се нуждае от един интегриран вход за проект и работен поток за риска.
Продуктовият екип предлага биометрично удостоверяване на плащания с поведенчески анализ. Функцията събира биометрични шаблони, метаданни за устройства, атрибути на акаунта, IP адреси, събития за автентикация и сигнали за измами. Тя използва доставчик на облачни анализи и биометричен SDK от трета страна. Екипите за клиентски успех ще получат агрегиран достъп до информационно табло.
Заявката за промяна трябва да задейства проверка за ОВЗД и оценка на риска преди разпределяне на ресурси или одобрение от Консултативния съвет по промените.
| Поле във входящия запис | Примерен отговор |
|---|---|
| Включени лични данни | Биометричен шаблон, потребителски идентификатор, IP адрес, метаданни за устройство, роля на акаунта, събития за автентикация |
| Цел на обработването | Удостоверяване на плащания, откриване на измами и анализи за клиентски успех |
| Правно основание за потвърждение | Необходимост за изпълнение на договор, легитимни интереси или изрично съгласие, подлежащо на преглед от DPO |
| Нов доставчик или облачна услуга | Доставчик на биометричен SDK и обработващ за облачни анализи в регион на ЕС |
| Чувствителни данни или данни от специални категории | Биометричните данни изискват преглед за висок риск, когато се използват за уникална идентификация |
| Промяна в модела на достъп | Екипът за клиентски успех получава агрегиран достъп до информационно табло |
| Промяна в съхранението | Журналите за събития се съхраняват 180 дни, биометричните шаблони се съхраняват съгласно условията за ползване на услугата |
| Изисква се ОВЗД | Да, биометричното обработване, наблюдението и новата зависимост от доставчик изискват преглед |
След това интегрираната оценка трябва да създаде едно рисково досие.
| Раздел на оценката | Основна рамка | Въпроси за отговор | Доказателства или резултат |
|---|---|---|---|
| Описание на обработването | GDPR Article 35 | Какви данни се обработват, защо, от кого и за колко дълго? | Поток на данните, актуализация на RoPA, входящ запис за ОВЗД |
| Необходимост и пропорционалност | GDPR Article 35 | Необходимо ли е обработването и представлява ли най-малко инвазивния приложим подход? | Преглед от DPO и обосновка |
| Риск за физическите лица | GDPR Article 35 | Могат ли физическите лица да бъдат изложени на кражба на идентичност, дискриминация, профилиране, изключване или финансови вреди? | Анализ на риска в ОВЗД и запис в регистъра на риска по ISO |
| Оценка на риска за сигурността | ISO/IEC 27001:2022 клауза 6.1.2 | Какви заплахи за поверителността, цялостността и наличността съществуват? | Записи в регистъра на риска с вероятност, въздействие, собственик и третиране |
| Анализ на въздействието по NIS2 | NIS2 Article 21 | Засяга ли промяната доставчици, сигурна разработка, контрол на достъпа, обработване на инциденти или непрекъсваемост? | Оценка на доставчик, контролен списък за сигурна разработка, доказателства от ръководството |
| Анализ на устойчивостта по DORA | DORA Articles 8, 9, 24 и 30 | Това ИКТ промяна ли е, която засяга устойчивост, тестване или договорни задължения? | Запис за промяна, план за тестване, преглед на договор и доказателства за изход |
| Третиране на риска и контроли | ISO/IEC 27001:2022 клауза 6.1.3 | Кои TOMs и контроли от Annex A намаляват риска? | План за третиране и актуализирана Декларация за приложимост |
Примерните записи за риск може да изглеждат така:
| Рисков сценарий | Вероятност | Въздействие | Примери за третиране | Съпоставяне с контроли |
|---|---|---|---|---|
| Прекомерно събиране извън заявената цел | Средна | Високо | Преглед на свеждането на данните до минимум, одобрение на схема на събитията, ограничение на съхранението | 5.34, 5.31, 8.10 |
| Неоторизиран достъп до биометрично или поведенческо информационно табло | Средна | Високо | Достъп, базиран на роли, MFA, журнализиране, тримесечен преглед на достъпа | 5.15, 5.18, 8.15, 8.16 |
| Неправилна конфигурация на облачен обработващ разкрива телеметрия | Ниска | Високо | Надлежна проверка на облачни услуги, шифроване, базова конфигурация, мониторинг | 5.23, 8.9, 8.24, 8.16 |
| Уязвимост в биометричен SDK компрометира данни за автентикация | Средна | Високо | Надлежна проверка на доставчик, преглед на сигурна разработка, тестване на сигурността | 5.21, 8.25, 8.28, 8.29 |
| Профилирането създава несправедливо въздействие върху клиента | Средна | Високо | Преглед от DPO, текст за прозрачност, обработване на възражения, когато е приложимо | 5.34, 5.8 |
Преди релийз записът за промяна трябва да съдържа завършена ОВЗД или одобрен от DPO план за третиране, актуализиран регистър на дейностите по обработване, надлежна проверка на доставчици и облачни услуги, преглед на въздействието върху сигурността, резултати от тестове, план за връщане към предходно състояние, план за мониторинг и одобрение на остатъчния риск.
След релийза собственикът трябва да провери журналите, предупрежденията, ролите за достъп, информационните табла, правилата за съхранение и работните потоци за изтриване. Това затваря цикъла на планираната промяна съгласно ISO/IEC 27001:2022 клауза 8.1 и подкрепя дисциплина за оперативна устойчивост в стила на DORA.
Какво ще попитат одиторите
Единната ОВЗД предоставя на различни одитори една последователна доказателствена следа.
| Одиторска перспектива | Вероятен фокус на одита | Доказателства, които трябва да съществуват |
|---|---|---|
| Одитор по ISO/IEC 27001:2022 | Дали съществени промени са задействали оценка на риска, третиране, актуализации на Декларацията за приложимост и оперативен контрол | Входящ запис за ОВЗД, регистър на риска, план за третиране, бележки по Декларацията за приложимост, запис за промяна, вътрешна одитна следа |
| Проверяващ по защита на личните данни съгласно GDPR | Дали обработването с висок риск е оценено преди внедряване и предпазните мерки са документирани | ОВЗД, регистър на дейностите по обработване, анализ на правното основание, преглед от DPO, доказателства за прозрачност и съхранение |
| Одитор, ориентиран към NIS2 | Дали одобрените от ръководството рискови мерки покриват политики за сигурност, верига на доставки, обработване на инциденти, непрекъсваемост, достъп, шифроване и обработване на уязвимости | Записи от преглед на съвета или ръководството, съпоставяне с контроли, преглед на доставчик, връзка с инциденти и непрекъсваемост |
| Одитор, ориентиран към DORA | Дали ИКТ промяната, зависимостта от трета страна, устойчивостта, тестването и договорните доказателства са интегрирани в управлението на ИКТ риска | Оценка на ИКТ риска, регистър на доставчиците, договорни клаузи, доказателства от тестване, план за изход, доказателства за поддръжка при инциденти |
| Оценител по NIST CSF | Дали резултатите за управление, риск, активи, доставчици, защита, откриване, реагиране и възстановяване са свързани | Текущ и целеви профил, план за пропуски, инвентар на активите, записи за риск, свързан с доставчици, доказателства за мониторинг и реагиране |
| Одитор по COBIT 2019 или ISACA | Дали подпомагането на промените, управлението на риска, услугите за сигурност и практиките за уверение са контролирани | Записи на Консултативния съвет по промените, анализ на въздействието, одобрения, тестване, разделение на задълженията, преглед след промяна |
NIST CSF 2.0 е полезен като комуникационен слой, защото функцията GOVERN поставя стратегията, очакванията, политиките, ролите, надзора и управлението на риска във веригата на доставки в центъра. COBIT 2019 добавя уверение за процесите, особено около структурираното подпомагане на промените, анализа на въздействието, одобренията, тестването и оценката след промяна.
Регулатор по GDPR може да започне с правата и свободите на физическите лица. Одитор по ISO може да започне с документирана оценка на риска и внедряване на контроли. Проверяващ по DORA може да започне с ИКТ зависимостта и устойчивостта. Проверяващ по NIS2 може да започне с управленски надзор и пропорционални мерки за киберсигурност.
Една и съща доказателствена верига на ОВЗД трябва да удовлетворява всички тях.
Решенията по ОВЗД трябва да издържат при инциденти
ОВЗД не е само артефакт за одобрение преди релийз. Тя трябва да подобрява готовността при нарушения и инциденти.
GDPR определя нарушение на сигурността на личните данни като нарушение на сигурността, водещо до случайно или незаконно унищожаване, загуба, изменение, неоторизирано разкриване на или достъп до лични данни. NIS2 изисква уведомяване за значителни инциденти без неоправдано забавяне, включително ранно предупреждение в рамките на 24 часа, уведомяване в рамките на 72 часа и окончателен доклад не по-късно от един месец след уведомяването за инцидента. DORA изисква финансовите субекти да откриват, управляват, журнализират, класифицират, ескалират и уведомяват за съществени ИКТ-свързани инциденти чрез първоначално, междинно и окончателно докладване, с уведомяване на клиенти, когато са засегнати финансовите им интереси.
Ако ОВЗД е записала потоци на данните, обработващи лични данни, контроли за достъп, съхранение, журнализиране, шифроване, псевдонимизация и отговорности при инциденти, екипът за инциденти може да отговори по-бързо на критични въпроси. Какви лични данни са засегнати? Кои системи и доставчици са засегнати? Кои физически лица или клиенти може да са засегнати? Имало ли е шифроване? Кои журнали са налични? Кои срокове за докладване се прилагат? Какви комуникации с клиенти или регулатори са необходими?
Ето защо управлението на ОВЗД трябва да се свързва с контролите за инциденти по ISO/IEC 27001:2022, контролите за непрекъсваемост на дейността и контролите за готовност на ИКТ, както и с очакванията на NIS2 и DORA за жизнения цикъл на инцидентите.
Често срещани провали в управлението на ОВЗД
Провалите обикновено се причиняват от несвързани работни потоци, а не от липса на усилие.
| Провал | Защо създава риск | По-добра практика |
|---|---|---|
| Регистърът на дейностите по обработване се актуализира след въвеждане в експлоатация | Регистърът се превръща в исторически инвентар вместо в контрол при проектирането | Актуализирайте RoPA преди одобрение |
| Липсва проверка за ОВЗД при входяща регистрация на промени | Рискът за защитата на личните данни се открива твърде късно | Добавете задължителни въпроси за лични данни, доставчици, достъп и съхранение |
| Рисковете от ОВЗД остават в папка „защита на личните данни“ | Третирането за сигурност и одобрението на остатъчния риск не са проследими | Преобразувайте констатациите от ОВЗД в записи в регистъра на риска на СУИС |
| Прегледите на доставчици се фокусират само върху въпросници | Целта на обработване, местонахождението на данните, подизпълнителите, правата на одит и изходът може да бъдат пропуснати | Комбинирайте надлежна проверка за сигурност, защита на личните данни, правни въпроси и устойчивост |
| В Декларацията за приложимост липсва обосновка за защита на личните данни и облачни услуги | Одиторите виждат контролите, но не и логиката на риска | Съпоставете контролите с констатациите от ОВЗД и задълженията по GDPR, NIS2 и DORA |
| Остатъчният риск се приема неформално | Управленската отчетност не може да бъде доказана | Запишете одобрението от DPO, собственика на риска и ръководството, заедно с условията |
Контролен списък за управление на ОВЗД
Използвайте този контролен списък, за да интегрирате ОВЗД в СУИС, готовността за NIS2 и управлението на ИКТ промени по DORA.
| Дейност по управление | Собственик | Минимални доказателства |
|---|---|---|
| Проверка за ОВЗД, вградена във входящата регистрация на проекти и промени | Мениджър по промените и DPO | Формуляр за входяща регистрация, решение за тригер и обосновка |
| Регистърът на дейностите по обработване е актуализиран преди одобрение | Координатор по защита на личните данни или DPO | Цел, правно основание, категории данни, съхранение и получатели |
| Рисковете за защитата на личните данни са преведени в рискове на СУИС | Длъжностно лице по управление на риска и собственик на система | Записи за риск с вероятност, въздействие, собственик и план за третиране |
| Контролите са съпоставени с Декларацията за приложимост | Мениджър на СУИС | Приложими контроли от Annex A, обосновка и статус на внедряване |
| Завършена е надлежна проверка на доставчици и облачни услуги | Доставки, сигурност и правен отдел | Оценка на доставчика, договорни клаузи, местонахождение на данните и доказателства за изход |
| Завършено е тестване на сигурността и защитата на личните данни | Инженеринг и сигурност | Резултати от тестове, преглед на достъпа, валидиране на журнализирането и доказателства за уязвимости |
| Остатъчният риск е приет | Собственик на риска, DPO и ръководство, когато се изисква | Запис за одобрение, условия и дата за преглед |
| Извършен е преглед след промяна | Собственик на промяната и собственик на услугата | Бележки от прегледа, инциденти, показатели и коригиращи действия |
Това не е бюрокрация. Това е оперативна отчетност. То помага на CISO да докаже, че сигурността е разгледана, на DPO да докаже, че рискът за защитата на личните данни е оценен, на мениджъра по съответствието да докаже, че контролите се съпоставят между рамките, и на собственика на бизнеса да докаже, че иновацията е управлявана отговорно.
Как помага Clarysec
Подходът на Clarysec е проектиран за организации, които се сблъскват с припокриващи се задължения през 2026 г. и фрагментирани доказателства.
Инструментариумът от политики ви дава езика за управление. Политиката за защита на данните и поверителност определя кога се изискват ОВЗД и кой ги преглежда. Политиката за управление на риска определя как трябва да бъдат структурирани и съпоставяни записите за риск. Политиката за управление на промените гарантира, че въздействията върху защитата на личните данни и сигурността се оценяват преди одобрение. Политиката за използване на облачни услуги изисква надлежна проверка преди активиране на облачни услуги.
Zenith Blueprint предоставя пътната карта за внедряване. Стъпка 13 превръща третирането на риска и Декларацията за приложимост в мост за cross-compliance. Стъпка 22 вгражда сигурността в управлението на проекти. Стъпка 21 прави промяната целенасочена, обоснована и годна за одит. Стъпка 23 превръща защитата на PII в контрол по жизнен цикъл, основан на осведоменост за данните, законосъобразна употреба, ограничаване на достъпа, надзор върху доставчици и оперативни процеси за защита на личните данни.
Ръководството Zenith Controls предоставя компаса за cross-compliance. За управлението на ОВЗД контролите по ISO/IEC 27002:2022 5.34, 5.8 и 8.32 свързват защитата на личните данни, управлението на проекти и контрола на промените с отчетността по GDPR, мерките за киберсигурност по NIS2, управлението на ИКТ риска по DORA, резултатите по NIST CSF и уверението по COBIT 2019.
Ако организацията ви се подготвя за прегледи на отчетността по GDPR, сертификация по ISO/IEC 27001:2022, готовност за NIS2 или оперативна устойчивост по DORA, започнете с интегриране на тригерите за ОВЗД във входящата регистрация на проекти и промени. Свържете констатациите от ОВЗД с регистъра на риска. Съпоставете мерките за третиране в Декларацията за приложимост. Валидирайте доставчиците и облачните услуги преди активиране. Съхранявайте един запис на решение, който ръководството, одиторите и регулаторите могат да проследят.
Най-добрата ОВЗД не е тази, написана след като регулаторът я поиска. Най-добрата ОВЗД е тази, която е оформила системата, преди клиентите, одиторите или инцидентите да я изпитат.
Прегледайте текущия си процес за ОВЗД спрямо инструментариума от политики на Clarysec, използвайте Zenith Blueprint, за да изградите проследимост, готова за одит, и използвайте Zenith Controls, за да съпоставите една рамка за контроли между GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF и COBIT 2019. След това превърнете следващата си промяна с въздействие върху защитата на личните данни в управлявано, подкрепено с доказателства решение за релийз, вместо в паническо действие за съответствие в последния момент.
Frequently Asked Questions
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
