Оценка на риска за поверителността по ISO 27701 и GDPR

Срещата в понеделник сутрин беше позната за Мария, CISO на бързо развиваща се компания за здравни технологии.

Главният изпълнителен директор искаше опростено табло, което да показва експозицията към риск по GDPR, преди компанията да пусне своята платформа за анализ на пациентски данни, базирана на изкуствен интелект. Новият ръководител по поверителността, Давид, разполагаше с регистър на дейностите по обработване (RoPA) с 50 раздела. Инженерният екип беше защитил облачната среда. Продуктът беше готов за пускане. Доставчикът описваше своята верига от подизпълнители по обработването като „на корпоративно ниво“.

Но един въпрос спря разговора.

„Какъв е действителният ни риск и можем ли да докажем пред корпоративните клиенти, че го държим под контрол?“

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

Това е пропускът, пред който са изправени много организации при преминаване към ISO/IEC 27701:2025 и отчетност по GDPR. Те имат уведомления за поверителност, въпросници към доставчици, записи в RoPA, карти на данните, шаблони за DPIA и контроли по ISO/IEC 27001:2022. Това, което често липсва, е оперативният слой, който ги свързва.

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

Тук пакетите с политики на Clarysec, Zenith Blueprint и Zenith Controls помагат на екипите да преминат от несвързани електронни таблици към защитима система за управление на риска за поверителността.

Оценката на риска за поверителността е липсващият оперативен слой

Отчетността по GDPR често се свежда до „наличие на документация“. Документацията е важна, но Article 5(2) отива по-далеч. Администраторът носи отговорност и трябва да може да докаже съответствие с принципите в Article 5(1), включително законосъобразност, добросъвестност, прозрачност, ограничение на целите, свеждане на данните до минимум, точност, ограничение на съхранението, цялостност и поверителност.

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

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

1. Инвентара на обработването на лични данни (PII) или RoPA.
2. Документацията за правното основание и целта.
3. Първоначалната проверка на риска за поверителността и решението за DPIA.
4. Третирането на риска и избора на контроли.
5. Управлението на доставчици, обработващи лични данни, и подизпълнители по обработването.
6. Доказателствата, съхранявани в ISMS и PIMS.

Clarysec прави тази връзка изрична. В корпоративната Политика за оценка на риска за поверителността и DPIA тригерът се активира преди началото на обработването:

[И за двете роли] Собственикът на процеса / собственикът на бизнес процеса ТРЯБВА да инициира първоначална проверка на риска за поверителността в REG04, преди да започне ново или съществено променено обработване на лични данни (PII), записано в REG02.

Същата дисциплина в началото на процеса присъства и в корпоративната Политика за инвентар на обработването на лични данни (PII) и правно основание:

[И за двете роли] Собственикът на процеса / собственикът на бизнес процеса ТРЯБВА да инициира първоначална проверка на риска за поверителността и DPIA в REG04, преди ново или съществено променено обработване на лични данни (PII) да продължи.

Това предотвратява често срещания модел на отказ: продуктът се пуска, RoPA се актуализира по-късно, въпросът за DPIA идва твърде късно и регистърът на риска никога не получава сценария за поверителността.

За администраторите това подпомага дисциплината по правното основание съгласно GDPR Article 6, защитата на данните още при проектирането и по подразбиране съгласно Article 25, сигурността на обработването съгласно Article 32 и отчетността съгласно Article 5. За обработващите лични данни това подпомага документираните нареждания, увереността пред клиентите, договорните граници и прозрачността относно подизпълнителите по обработването.

Започнете от реалното обработване, а не от празен шаблон

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

За SaaS, fintech или организация в здравните технологии промяната може да включва:

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

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

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

За по-малки екипи SME Политика за защита на данните и поверителност предоставя отправна точка в клауза 5.2.1:

Координаторът по поверителност трябва да поддържа регистър на всички дейности по обработване на лични данни, включително категории данни, цел, правно основание и срокове за съхранение

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

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

Координаторът по поверителност трябва да оценява рисковете за поверителността ежегодно и при съществени промени в системите

За предприятията управленската периодичност е по-строга. Корпоративната Политика за защита на данните и поверителност посочва:

Регистрите на риска за поверителността трябва да се поддържат в рамките на ISMS и да се преглеждат най-малко на тримесечна база от длъжностното лице по защита на данните (DPO) и CISO.

Тук интеграцията между ISO/IEC 27701:2025 и ISO/IEC 27001:2022 става практическа. Рисковете за поверителността не се скриват в правни папки. Те се преглеждат заедно с рисковете за сигурността, рисковете, свързани с доставчици, инцидентите, одитните констатации, плановете за третиране на риска и докладването към ръководството.

Процесът на Clarysec от REG02 до REG04

Най-ефективният процес за оценка на риска за поверителността е достатъчно прост за собствениците на бизнес процеси и достатъчно строг за одиторите. Моделът на Clarysec използва REG02 като инвентар на обработването на лични данни (PII), а REG04 — като запис за оценка на риска за поверителността и DPIA.

Политиката за оценка на риска за поверителността и DPIA определя минималните доказателства, необходими преди REG04 да може да бъде затворен:

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

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

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

Всеки запис за риск трябва да включва: описание, вероятност, въздействие, оценка, собственик и план за третиране.

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

Използвайте механизма за риск на ISO/IEC 27001:2022 за поверителността

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

Клаузи 4.1 до 4.4 изискват организацията да разбира вътрешните и външните фактори, изискванията на заинтересованите страни, обхвата на ISMS и процесите на ISMS. За поверителността заинтересованите страни включват клиенти, субекти на данни, служители, регулатори, обработващи лични данни, подизпълнители по обработването, надзорни органи, надзорни органи във финансовия сектор, когато е приложимо, и договорни клиенти.

Клауза 6.1.2 изисква процес за оценка на риска за информационната сигурност. Клауза 6.1.3 изисква третиране на риска за информационната сигурност, включително избор на контроли, изготвяне на Декларация за приложимост, формулиране на план за третиране на риска и получаване на одобрение от собственика на риска за плана и остатъчните рискове. Клаузи 8.2 и 8.3 изискват извършване на оценки и третиране на риска за информационната сигурност на планирани интервали или при настъпване на значителни промени, като се съхраняват документираните резултати.

Корпоративната Политика за управление на риска на Clarysec е съгласувана с тази структура в клауза 5.1:

Формален процес за управление на риска трябва да се поддържа в съответствие с ISO/IEC 27005 и ISO 31000, като обхваща идентифициране, анализ, оценка, третиране, наблюдение и комуникация на риска.

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

Zenith Blueprint: 30-стъпкова пътна карта за одитори на Clarysec обяснява това във фазата „Управление на риска“, стъпка 10:

При дефиниране на въздействието е разумно нивата да се свържат с конкретния мащаб на вашия бизнес. Например „Съществено финансово въздействие = загуба > $100k“ (адаптирайте към вашия контекст). Също така вземете предвид регулаторното въздействие: например нарушение на сигурността на личните данни може автоматично да бъде „Съществено“ или „Тежко“ поради глоби по GDPR и изисквания за уведомяване, дори когато пряката финансова загуба е неясна.

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

Практически пример: AI анализ на пациентски данни

Да се върнем към Мария и Давид. Тяхната платформа за здравни технологии ще обработва специални категории здравни данни по GDPR Article 9. Тя ще използва пациентска история, данни от прегледи, бележки на клиницисти и резултати от модели, за да генерира рискови анализи.

Използвайки Zenith Blueprint, те започват със стъпка 9 — идентифициране на активи, заплахи и уязвимости:

За всеки актив запишете ключови данни: име/описание, собственик, местоположение и класификация (чувствителност). Например актив може да бъде „Клиентска база данни — собственост на ИТ отдела — хоствана в AWS — съдържа лични и финансови данни (висока чувствителност).“

Същата стъпка добавя и гледната точка на поверителността:

Уверете се, че активите с лични данни са маркирани (за относимост към GDPR), а активите за критични услуги са посочени (за потенциална приложимост на NIS2, ако сте в регулиран сектор).

Екипът на Мария идентифицира платформата за AI анализ на пациентски данни, пациентската база данни, хранилището за данни, конвейера за обучение на модели, таблото за клиницисти, облачното хранилище, доставчика на идентичност, одитните журнали, платформата за билети за поддръжка и инструмента за анализи от трета страна. Всеки актив получава собственик, местоположение, класификация и връзка с лични данни (PII).

След това те дефинират рискови сценарии. Единият е неразрешен достъп до здравни досиета. Друг е случайно разкриване чрез експорт на аналитични данни. Трети е пристрастност на AI модел, причинена от изкривени обучителни данни, което води до несправедливо или дискриминационно оценяване на риска за пациенти.

Стъпка 11 от Zenith Blueprint обяснява ролята на регистъра на риска:

Регистърът на риска обикновено е електронна таблица (нашият шаблон „Risk Register and SoA Builder.xlsx“ има отделен лист за това). Той служи като основен журнал на рисковете.

Запис за риск за поверителността за сценария с пристрастност на AI модела може да изглежда така:

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

Тъй като обработването е високорисково и включва специални категории данни, DPIA не е отделна последваща мисъл. Тя става по-задълбоченият етап на оценка за риск, който вече е записан в системата. Корпоративната Политика за защита на данните и поверителност посочва:

Всички съществени промени в системи или процеси, включващи лична информация (PII), трябва да изискват документирана оценка на въздействието върху защитата на данните (DPIA), прегледана от длъжностното лице по защита на данните (DPO).

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

[Администратор] Висшето ръководство ТРЯБВА да одобри приемането на висок остатъчен риск за поверителността в REG04, преди високорисково обработване от администратор да започне или да продължи.

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

От рискове към контроли със Zenith Controls

Оценката на риска за поверителността има значение само ако води до решения за контроли. Zenith Controls: ръководство за съответствие между рамки на Clarysec е ръководство за съответствие между рамки, което картографира контролите по ISO/IEC 27001:2022 и ISO/IEC 27002:2022 към свързани изисквания в различни рамки. Това не е отделен набор от контроли. То помага на екипите да разберат как доказателствата за контрол подкрепят множество задължения.

За оценката на риска за поверителността Zenith Controls подчертава три централни контрола от ISO/IEC 27002:2022:

Контрол 5.34 подкрепя също GDPR Article 25 и Article 32, NIS2 Article 21 мерки за управление на риска за киберсигурността, очакванията на DORA за управление на ИКТ риска и резултати от NIST CSF 2.0 като GV.OC-03 за правни, регулаторни, договорни, поверителност и граждански свободи задължения, плюс PR.DS-01 за защита на данни в покой.

Стъпка 13 от Zenith Blueprint свързва тези решения с Декларацията за приложимост:

Кръстосани препратки към регулации: Ако определени контроли са внедрени специално за спазване на GDPR, NIS2 или DORA, можете да отбележите това или в Регистъра на риска (като част от обосновката на въздействието на риска), или в бележките към SoA.

Така констатацията, свързана с поверителността, се превръща в решение за контрол в ISMS и PIMS, а не само в правен коментар.

Рискът при доставчици и обработващи лични данни трябва да се оценява преди одобрение

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

Корпоративната Политика за управление на поверителността при обработващи лични данни, подизпълнители по обработване и трети страни на Clarysec предотвратява това, като свързва прегледа на доставчици, REG04 и регистъра на трети страни:

[И за двете роли] Ръководителят по поверителността / мениджърът на PIMS ТРЯБВА да задейства първоначална проверка на риска за поверителността и DPIA в REG04 за високорискови взаимоотношения с обработващи лични данни и съществени промени във взаимоотношение с трета страна във връзка с поверителността преди одобрение, като референцията към REG04 се записва в REG08.

За SME Политиката за сигурност на трети страни и доставчици установява изискването за преглед преди ангажиране:

Преди ангажиране всеки доставчик трябва да бъде прегледан за потенциални рискове. Този преглед трябва да включва:

Оперативното послание е ясно. Рискът, свързан с доставчик, се оценява преди одобрение, а не след подписване.

Това подкрепя също NIS2 и DORA. NIS2 Article 21 изисква сигурност на веригата на доставки като част от мерките за управление на риска за киберсигурността. DORA Articles 28 to 30 изискват финансовите субекти да управляват ИКТ риска, свързан с трети страни, да извършват оценки преди сключване на договор, да поддържат договорни предпазни мерки, да разбират риска от подизпълнение, да наблюдават зависимостите и да планират изходи за критични или важни функции.

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

Един процес, много резултати за съответствие

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

NIST CSF 2.0 е особено полезен за комуникация с изпълнителното ръководство. Неговата функция GOVERN обхваща организационен контекст, стратегия за управление на риска, политика, роли, надзор и риск във веригата на доставки. Неговите организационни профили помагат текущите и целевите резултати да се превърнат в приоритизиран план за действие, например регистър на риска или план за действия и ключови етапи.

За организации, попадащи в обхвата на NIS2, DORA или секторно-специфични правила, доказателствата за риска за поверителността подкрепят също управлението на киберсигурността, надзора над доставчиците, готовността за инциденти и докладването за устойчивост.

Третирането на риска за поверителността е по-широко от шифроване

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

SME Политика за защита на данните и поверителност посочва:

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

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

Корпоративната Политика за управление на риска засилва планирането на третирането за рискове над толеранса:

Всички рискове, класифицирани над нивото на толеранс, трябва да имат свързан План за третиране на риска, който определя:

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

Тригерите за преглед поддържат оценката актуална

Оценка на риска за поверителността, която никога не се преразглежда, се превръща в остарели доказателства. Клаузи 8.2 и 8.3 на ISO/IEC 27001:2022 изискват оценка и третиране на риска на планирани интервали или при настъпване на значителни промени. Отчетността по GDPR изисква актуални решения. ISO/IEC 27701:2025 зависи от мониторинга и непрекъснатото подобрение.

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

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

Какво ще очакват да видят одиторите

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

Корпоративната Политика за защита на данните и поверителност изисква също дейност по вътрешен одит:

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

Това създава обратна връзка към ръководството. Пълни ли са записите в REG02? Навременни ли са първоначалните проверки в REG04? Извършват ли се DPIA, когато са задължителни? Одобряват ли се високите остатъчни рискове? Отразяват ли се промените при доставчици? Затварят ли се плановете за третиране? Съответстват ли уведомленията на действителното обработване?

Контролен списък за следващата среща относно промяна в поверителността

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

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

Превърнете отчетността за поверителността в работеща система

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

Започнете с фазата „Управление на риска“ в Zenith Blueprint, особено стъпки 9 до 13. Използвайте Risk Register and SoA Builder, за да свържете активи, заплахи, уязвимости, рискове за поверителността, решения за третиране и препратки към контроли. След това използвайте Zenith Controls, за да картографирате защитата на лични данни (PII), инвентара на активите и сигурността на доставчиците към очакванията за уверение по GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 и COBIT 19.

Съгласувайте оперативните политики, които правят процеса приложим: Политика за оценка на риска за поверителността и DPIA, Политика за инвентар на обработването на лични данни (PII) и правно основание, Политика за управление на поверителността при обработващи лични данни, подизпълнители по обработване и трети страни, Политика за управление на риска и Политика за защита на данните и поверителност. По-малките екипи могат да използват и SME политиките на Clarysec, а по-големите организации могат да структурират управлението чрез корпоративни политики.

Ако вашият екип пуска ново обработване, сменя доставчици, подготвя се за ISO/IEC 27701:2025 или се опитва да направи доказателствата за отчетност по GDPR повторяеми, започнете с една реална дейност по обработване. Отворете REG02, изпълнете първоначална проверка в REG04, картографирайте рисковете към контроли, определете собственици на третирането и прегледайте остатъчния риск с правилния отговорник за решението.

Именно в този един процес управлението на поверителността става оперативно.