Картографиране на потоците от данни в RoPA за GDPR, NIS2 и DORA

Вторник е, 09:10 ч., а CISO, DPO, ръководителят на закупуването и директорът по операциите са в един и същ видеоконферентен разговор, но не работят с едни и същи доказателства.

DPO разполага с Регистър на дейностите по обработване, или RoPA, в който са изброени въвеждането на клиенти, изчисляването на възнагражденията на служители, тикетите за поддръжка и маркетинговата аналитика. CISO има инвентар на облачните активи. Екипът по закупуване разполага с договорите с доставчици. Операциите поддържат електронна таблица за непрекъснатост на дейността. Финансовият екип поддържа регистъра на информацията по DORA. Никой не може да отговори на най-базовия свързан въпрос на регулатора:

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

Този въпрос е реалният тест за съответствие през 2026 г.

GDPR все още изисква отчетни записи по Article 30. NIS2 превърна киберсигурността във въпрос на отчетност на управителните органи за съществените и важните субекти. DORA изисква финансовите субекти да доказват ИКТ зависимости, критични или важни функции, договорености с трети страни за ИКТ услуги, класификация на инциденти и тестване на устойчивостта. ISO/IEC 27001:2022 предоставя структурата на системата за управление, която може да обедини всичко това, но само ако RoPA и картографирането на потоците от данни се третират като живи управленски доказателства, а не като електронни таблици на екипа по защита на личните данни.

В Clarysec виждаме един и същ модел при бързо растящи SaaS, fintech, облачни, MSP и B2B технологични компании. Те имат достатъчно документация, за да отговорят на въпросник, но нямат достатъчно свързани доказателства, за да издържат надзорен преглед, киберинцидент, отказ на доставчик или вътрешен одит. Проблемът рядко е липса на информация. Проблемът е липса на връзка.

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

Защо RoPA и картографирането на потоците от данни се превърнаха в управленски въпрос през 2026 г.

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

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

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

NIS2 добавя перспективата на устойчивостта на услугите. Тя включва в обхвата много средни и по-големи организации в сектори с висока степен на критичност и други критични сектори, включително цифрова инфраструктура, доставчици на облачни изчислителни услуги, доставчици на услуги за центрове за данни, мрежи за доставка на съдържание, доставчици на удостоверителни услуги, доставчици на обществени електронни съобщителни услуги, доставчици на управлявани услуги и доставчици на управлявани услуги по сигурност. Annex I включва също банковия сектор и инфраструктурите на финансовите пазари. Някои субекти могат да попаднат в обхвата независимо от размера, включително определени доставчици на DNS услуги, регистри на TLD, удостоверителни услуги и обществени комуникации, както и субекти, чието прекъсване може да засегне значително обществената безопасност, общественото здраве, системния риск или критични обществени и икономически дейности.

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

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

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

За финансовите субекти, които са идентифицирани и по националното транспониране на NIS2, DORA се третира като секторно специфичен правен акт на Съюза за еквивалентните изисквания относно ИКТ риск, докладване на инциденти, тестване, споделяне на информация и риск от трети страни. На практика fintech компания не може да изгради един набор от доказателства за защита на личните данни, друг за DORA и трети за NIS2. Необходим ѝ е единен слой за управление на данните, който отчита зависимостите.

Този слой е RoPA плюс картографиране на потоците от данни.

ISO/IEC 27001:2022 е гръбнакът

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

Началната точка не е инструментът за диаграми. Началната точка е обхватът.

Клаузи 4.1 до 4.4 на ISO/IEC 27001:2022 изискват организацията да определи контекста, заинтересованите страни, обхвата на СУИС и взаимодействащите процеси. Обхватът трябва да отчита правните, регулаторните и договорните задължения, както и интерфейсите и зависимостите между вътрешни дейности и дейности, извършвани от други организации. За RoPA и картографирането на потоците от данни това означава, че обхватът на СУИС трябва изрично да включва външно възложени облачни платформи, обработващи плащания, доставчици на идентичност, инструменти за поддръжка, доставчици на управлявани услуги по сигурност и критични за бизнеса SaaS интеграции.

Клаузи 5.1 до 5.3 възлагат на ръководството отговорност за политиката, ресурсите, определянето на роли и докладването. Това отразява посоката на NIS2 Article 20, който изисква управителните органи да одобряват мерките за управление на риска в киберсигурността, да наблюдават внедряването им и да преминават обучение. Това също е съгласувано с DORA Article 5, който възлага на управителния орган крайната отговорност за ИКТ риска и надзора върху политиките, стратегията за устойчивост, плановете за непрекъснатост, плановете за одит, ИКТ услугите от трети страни и каналите за докладване на съществени инциденти.

Клаузи 6.1.1 до 6.1.3 предоставят механизма за планиране: идентифициране на рисковете за поверителността, целостта и наличността, определяне на собственици на риска, анализ на последиците и вероятността, избор на варианти за третиране, сравняване на контролите с Приложение A, изготвяне на Декларация за приложимост и получаване на одобрение от собственика на риска.

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

Zenith Blueprint: 30-стъпкова пътна карта за одитори на Clarysec прави това практично във фазата „Управление на риска“, стъпка 9, „Идентифициране на активи, заплахи и уязвимости“:

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

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

Какво трябва да съдържа готов за одит RoPA

Силният RoPA не трябва да бъде сложен, но трябва да бъде свързан.

GDPR Article 5 изисква личните данни да се обработват законосъобразно, добросъвестно и прозрачно, да се събират за конкретни и легитимни цели, да се ограничават до необходимото, да се поддържат точни, да се съхраняват само толкова дълго, колкото е необходимо, и да се защитават чрез подходящи технически и организационни мерки. Article 5(2) изисква администраторът да носи отговорност за съответствието и да може да го докаже.

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

Наборът от политики за МСП на Clarysec превръща това в оперативно изискване. Политика за защита на данните и поверителност - МСП посочва:

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

Това е от раздел „Изисквания за управление“, клауза 5.2.1. За по-големи организации Политика за защита на данните и поверителност на Clarysec възлага отговорността пряко:

Поддържа Регистър на дейностите по обработване (RoPA) в съответствие с GDPR Article 30.

Този текст идва от „Роли и отговорности“, клауза 4.2.2. Практическото послание е просто: собствеността върху RoPA трябва да бъде възложена. Той не може да бъде осиротяла електронна таблица за съответствие.

RoPA, готов за 2026 г., трябва да включва следните полета.

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

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

Ако RoPA отговаря на въпроса „какво обработване съществува и защо“, картата на потоците от данни отговаря на въпросите „къде се движат данните, кой има достъп до тях, какво ги защитава и какво се нарушава, ако потокът спре“.

Политика за маскиране на данни и псевдонимизация - МСП на Clarysec формулира изискването недвусмислено:

Трябва да бъде създадена карта на потоците от данни.

Това идва от „Изисквания за управление“, клауза 5.1.1.1. Корпоративната версия, Политика за маскиране на данни и псевдонимизация, разширява очакването в клауза 5.2.1:

Поддържайте актуален инвентар на системите и потоците от данни, включващи чувствителни данни.

Клауза 5.2.2 добавя:

Картографирайте къде и как данните се трансформират, споделят или достъпват в различни среди.

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

В Zenith Blueprint, фазата „Контроли в действие“, стъпка 22, „Организационни контроли 5.1 до 5.18“, указанията за предаване на информация обясняват, че организациите трябва да определят разрешените методи за предаване, да ги съгласуват с класификацията и да гарантират, че страните разбират своите роли и задължения. Дадени са примери като криптирана електронна поща, защитени портали, SFTP, приложно-програмни интерфейси (API) и физическа доставка с криптиране. Също така се отбелязва, че личните данни, прехвърляни през граници, трябва да отговарят на изискванията за поверителност и правните задължения, а не само на вътрешни предпочитания.

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

1. Идентифицирайте системата източник, например CRM, платежна платформа, HRIS или бюро за поддръжка.
2. Идентифицирайте категорията данни, включително лични данни, финансови данни, данни на служители, специални категории данни или удостоверителни данни.
3. Идентифицирайте метода за предаване, например API, SFTP, електронна поща, защитен портал, ръчен експорт или репликация на резервни копия.
4. Идентифицирайте получателя, включително вътрешна система, облачна услуга, доставчик, подизпълнител по обработването, хранилище за данни или архив.
5. Идентифицирайте защитата, например криптиране, псевдонимизация, контрол на достъпа, журналиране, DLP или договорно ограничение.
6. Идентифицирайте зависимостта, включително дали потокът поддържа критична бизнес функция, критична или важна функция, съществена услуга или задължение за докладване на инциденти.

Три контрола от Приложение A на ISO/IEC 27001:2022 са особено важни тук. ISO/IEC 27002:2022 предоставя насоките за внедряване на тези контроли:

Zenith Controls: Ръководство за кръстосано съответствие на Clarysec определя 5.9, 5.14 и 5.34 като тематично свързани контроли за този управленски слой. Третирайте ги като опорни контроли, след което ги свържете с контролите за доставчици, облак, инциденти, непрекъснатост, журналиране, достъп и криптография чрез вашата Декларация за приложимост.

Защо NIS2 и DORA изискват повече от регистър за защита на личните данни

Честа грешка е изграждането на RoPA, който е технически коректен по GDPR, но безполезен за NIS2 или DORA. Разликата е критичността на услугата.

NIS2 Article 23 изисква съществените и важните субекти да уведомяват за значими инциденти без неоправдано забавяне. Моделът за докладване включва ранно предупреждение в рамките на 24 часа, уведомление за инцидент в рамките на 72 часа и окончателен доклад в рамките на един месец. Значимите инциденти се оценяват според сериозно оперативно прекъсване, финансови загуби или материални или нематериални вреди за други физически или юридически лица. Тази оценка зависи от познаването на засегнатите услуги, получатели, държави, системи и доставчици.

DORA Article 17 изисква финансовите субекти да определят и внедрят процес за управление на инциденти, свързани с ИКТ, който открива, управлява и уведомява за инциденти, записва инциденти и значими киберзаплахи, идентифицира първопричини, задава индикатори за ранно предупреждение, класифицира инцидентите по тежест и критичност на засегнатите услуги, възлага роли и създава процедури за комуникация и ескалация. Article 18 изисква класификация въз основа на засегнати клиенти или контрагенти и трансакции, продължителност и период на недостъпност, географски обхват, загуба на данни, засягаща наличността, автентичността, целостта или поверителността, критичността на засегнатите услуги и икономическото въздействие.

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

Политика за непрекъснатост на дейността и аварийно възстановяване - МСП на Clarysec посочва полето за доказателства, от което организациите се нуждаят:

приоритизирани услуги и системи (критични бизнес функции)

Това идва от „Изисквания за управление“, клауза 5.2.1.2. Корпоративната Политика за непрекъснатост на дейността и аварийно възстановяване добавя измерението на зависимостите в клауза 5.2.4:

Критични зависимости (системи, доставчици, персонал)

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

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

RoPA, който не идентифицира доставчици, местоположения, методи за предаване, критичност и изходни зависимости, няма да подпомогне доказателствата по DORA.

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

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

Политиката за доставчици за МСП на Clarysec създава минималните оперативни доказателства. Политика за сигурност на трети страни и доставчици - МСП посочва:

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

Това идва от „Изисквания за управление“, клауза 5.4. Политиката за облак добавя отделно изискване за инвентар. Политика за използване на облачни услуги - МСП посочва:

Регистърът на облачните услуги трябва да се поддържа от доставчика на ИТ услуги или управителя. Той трябва да записва:

Това идва от „Изисквания за управление“, клауза 5.3. За корпоративен риск от зависимости Политика за управление на риска от зависимост към доставчици на Clarysec е по-конкретна:

Регистър на зависимостите от доставчици: звеното за управление на доставчиците (VMO) трябва да поддържа актуален регистър на всички критични доставчици, включително данни като предоставяни услуги/продукти; дали доставчикът е единствен източник; налични алтернативни доставчици или възможност за замяна; текущи договорни условия; и оценка на въздействието, ако доставчикът откаже или бъде компрометиран. Регистърът трябва ясно да идентифицира доставчиците с висока степен на зависимост (например тези, за които не съществува бърза алтернатива).

Това изискване, от „Изисквания за внедряване“, клауза 6.1, е точната връзка между RoPA, сигурността на веригата на доставки по NIS2 и риска от трети страни за ИКТ по DORA.

Zenith Blueprint, фазата „Контроли в действие“, стъпка 23, „Организационни контроли 5.19 до 5.37“, препоръчва съставяне на пълен списък на доставчиците, класифициране на доставчиците според достъпа им до системи, данни или оперативен контрол, включване на изисквания за сигурност в договорите, преглед на подизпълнителите, установяване на тригери при промени на доставчици и изграждане на процес за оценка на облачни услуги, обхващащ местоположение на данните, модел на достъп, журналиране и криптиране.

Именно това позволява на CISO да отговори по време на инцидент: „Коя критична услуга използва този доставчик, кои данни бяха изложени, кои клиенти трябва да бъдат уведомени, кой регулатор може да трябва да получи доклад и какъв алтернативен доставчик или изходен път съществува?“

Практически пример: въвеждане на клиенти във fintech

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

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

Полезната карта започва с един свързан запис.

Сега добавете проследимост на третирането на риска по ISO/IEC 27001:2022.

В Zenith Blueprint, фазата „Управление на риска“, стъпка 13, „Планиране на третирането на риска и Декларация за приложимост“, Clarysec описва SoA като свързващ документ, който обвързва оценката и третирането на риска с реалните контроли. Препоръчва се контролите да се картографират към рискове и, когато е релевантно, в Регистъра на риска или бележките към SoA да се правят кръстосани препратки към регулации като GDPR, NIS2 или DORA.

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

Бележката в SoA може да посочва, че наборът от контроли подпомага отчетността по GDPR, сигурността на веригата на доставки и готовността за инциденти по NIS2 Article 21, както и риска от трети страни за ИКТ и устойчивостта на критични функции по DORA.

Това е, което одиторите търсят: проследимост.

Картографиране за кръстосано съответствие: един слой от доказателства, множество въпроси

RoPA и картографирането на потоците от данни не са отделни силози за съответствие. Те подпомагат общ набор от въпроси в GDPR, NIS2, DORA, ISO/IEC 27001:2022, NIST CSF 2.0 и COBIT 2019.

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

Това се вписва естествено в оперативния модел на RoPA на Clarysec. RoPA дава контекста на защитата на личните данни. Инвентарът на активите дава техническия контекст. Регистрите на доставчиците и облачните услуги дават контекста на трети страни. BIA дава контекста на критичността. SoA дава контекста на контролите.

Един контрол от Приложение A на ISO/IEC 27001:2022 може също да подпомага няколко рамки. Контрол 5.14, Предаване на информация, е добър пример.

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

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

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

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

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

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

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

Оценител по NIST CSF 2.0 често ще използва профили. Той ще сравни текущите и целевите резултати в GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND и RECOVER. RoPA и картите на потоците от данни стават входни данни за управление на правни задължения, инвентари на активи, риск от доставчици, защита на данните, мониторинг, комуникации при инциденти и планиране на възстановяването.

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

Чести модели на неуспех

Най-честите неуспехи при RoPA и картографирането на потоците от данни са предвидими.

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

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

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

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

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

Накрая, собствеността е фрагментирана. DPO притежава RoPA, ИТ притежава активите, закупуването притежава доставчиците, операциите притежават BIA, финансите притежават регистрите по DORA и никой не притежава интегрираната карта на зависимостите.

Подходът на Clarysec решава това, като възлага доказателствените обекти на собственици на политики, а след това използва стъпките от Zenith Blueprint, за да свърже активи, рискове, контроли и проследимост чрез SoA.

30-дневен план за внедряване

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

Седмица 1: Изберете три критични или високорискови дейности по обработване. Добри кандидати са въвеждане на клиенти, обработване на плащания, HR администрация на служители, тикети за поддръжка или мониторинг на сигурността. За всяка валидирайте записа в RoPA спрямо действителните системи, категории данни, цели, правни основания и правила за съхранение.

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

Седмица 3: Свържете всеки поток с активи, доставчици, облачни услуги и критични бизнес функции. Използвайте Zenith Blueprint стъпка 9 за собственост и класификация на активите. Използвайте изискванията за регистър на доставчиците и облачните услуги, за да съберете доказателства за трети страни. Използвайте политиката за непрекъснатост на дейността, за да идентифицирате приоритизирани услуги и критични зависимости.

Седмица 4: Добавете проследимост на риска и контролите. За всеки поток създайте или актуализирайте рискови сценарии. Картографирайте контролите в SoA чрез Zenith Blueprint стъпка 13. Добавете бележки за отчетността по GDPR Article 30, мерките за риск по NIS2 Article 21 и доказателствата за ИКТ зависимости по DORA, когато е приложимо.

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

До края на 30 дни ще имате повторяем модел за останалата част от организацията.

Подходът на Clarysec: превърнете RoPA в живи доказателства за устойчивост

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

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

Clarysec помага на екипите да изградят тази проследимост без ненужна бюрокрация. Нашият набор от политики възлага собственост и изисквания за доказателства. Zenith Blueprint предоставя пътната карта за внедряване, включително идентифициране на активи, внедряване на контроли за доставчици и облак и проследимост чрез SoA. Zenith Controls предоставя компаса за кръстосано съответствие при картографиране на контролите от Приложение A на ISO/IEC 27001:2022 към очакванията за защита на личните данни, устойчивост, доставчици, облак и одит.

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

Clarysec може да ви помогне да го подготвите. Разгледайте Zenith Blueprint, укрепете управлението си с Политика за защита на данните и поверителност и Политика за управление на риска от зависимост към доставчици и използвайте Zenith Controls, за да превърнете фрагментираните доказателства за съответствие в един готов за одит оперативен модел.