Класификация на данни за ISO 27001, GDPR, NIS2 и DORA

Моментът на одита през 2026 г.: „Покажете ми доказателствата“

Февруари 2026 г. е и тримесечното заседание на управителния съвет в бързо развиваща се финтех компания, предоставяща SaaS, не протича толкова гладко, колкото директорът по информационна сигурност (CISO) е очаквал.

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

„Водещият ни инвеститор пита как можем да докажем, че финансовите данни на клиентите се защитават последователно в AWS, Azure, нашата SaaS платформа за поддръжка и аналитичното хранилище. Ако одитор изтегли един файл от обектно хранилище и друг от папка за съвместна работа, как знаем, че и двата се управляват по едни и същи правила?“

CISO отваря регистъра на активите. В него са изброени бази данни, облачни акаунти, приложения, SaaS платформи и места за съхранение. Но полето за класификация е непълно. Няколко папки са именувани по отдели, а не по чувствителност. Клиентски експорти стоят до вътрешни файлове за отчетност. Някои таблици на поддръжката съдържат клиентски идентификатори, платежни референции и бележки по случаи, но са етикетирани като „Вътрешна употреба“. Има DLP правила, но те се задействат само при очевидни шаблони. Политиката за облачни услуги казва, че личните данни от ЕС трябва да остават в одобрени региони, но екипът не може да докаже, че правилата за местонахождение на данните се управляват от метаданни за класификация.

След това мениджърът по съответствие добавя регулаторния аспект: „Това ще удовлетвори ли GDPR Article 32, NIS2 Article 21 и доказателствата за ИКТ риска по DORA?“

Честният отговор е: все още не.

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

В терминологията на ISO/IEC 27001:2022 класификацията и етикетирането не са козметични практики за управление на документи. Те са практическата връзка между оценката на риска, контрола на достъпа, шифроването, сроковете за съхранение, DLP, местонахождението на данните в облак, надлежната проверка на доставчици, мониторинга и докладването на инциденти. В модела за внедряване на Clarysec те стоят в центъра на доказателствената верига на ISMS: инвентаризирайте актива, определете собственик, класифицирайте го, етикетирайте го, приложете правила за работа с информацията, наблюдавайте изключенията и покажете проследимостта пред одиторите.

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

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

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

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

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

ISO/IEC 27001:2022 е добре пригоден като операционна система за тези доказателства. Clauses 4.1 to 4.4 изискват организацията да разбира вътрешните и външните обстоятелства, изискванията на заинтересованите страни, регулаторните и договорните задължения и интерфейсите с други организации. Clauses 6.1.1 to 6.1.3 изискват оценка на риска, третиране на риска, избор на контроли, Декларация за приложимост и съхранени доказателства. ISO/IEC 27001:2022

Ако GDPR, NIS2 и DORA попитат: „Защо приложихте тези мерки?“, ISO/IEC 27001:2022 помага да отговорите: „Защото тези активи, типове данни, рискове, задължения и решения за третиране ни доведоха дотук.“

Класификацията е решението за риска. Етикетирането е оперативният сигнал.

Clarysec разделя класификацията и етикетирането, защото одиторите ги разграничават.

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

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

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

Същата Политика за класификация и етикетиране на данни - SME изисква от организациите да:

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

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

Организацията трябва да поддържа стандартизирана схема за класификация с ясно дефинирани нива. Като минимум трябва да се използват следните нива на класификация: 5.1.1 Публична: Информация, предназначена за открито публикуване и неограничено разпространение 5.1.2 Вътрешна употреба: Непублична служебна информация, която не е предназначена за външно оповестяване 5.1.3 Поверителна: Чувствителни бизнес, договорни или клиентски данни, изискващи строг контрол на достъпа 5.1.4 Ограничена (или Строго поверителна): Критична или регулирана информация, при която неоторизирано разкриване може да доведе до значителна вреда или правна отговорност

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

Корпоративната политика е изрична относно оперативното етикетиране:

Всички информационни активи трябва да бъдат етикетирани по начин, който е: 6.2.1.1 Устойчив: Не може лесно да бъде премахнат или заменен 6.2.1.2 Видим: Ясен за потребителите в момента на използване 6.2.1.3 Машинно четим: Където е възможно, трябва да се поддържа маркиране с метаданни

Машинно четимите етикети са моментът, в който програмата преминава от осведоменост към прилагане. Ако етикетите са базирани на метаданни, облачни платформи, DLP системи, шлюзове за електронна поща, инструменти за идентичност, SIEM правила, CASB платформи и механизми за съхранение могат да действат въз основа на тях. Ако етикетите са само долен колонтитул в документ, те могат да помагат на потребителите, но не могат надеждно да прилагат правила в мащаб.

Къде е мястото на класификацията в пътната карта на Clarysec

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

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

Насоките на Zenith Blueprint относно ISO/IEC 27002:2022 контрол 5.12, Класификация на информацията, обясняват принципа:

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

За ISO/IEC 27002:2022 контрол 5.13, Етикетиране на информацията, същата пътна карта превръща класификацията в ежедневно поведение:

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

Последната връзка в пътната карта се появява в стъпка 13, „Планиране на третиране на риска и Декларация за приложимост“. Zenith Blueprint описва SoA като мост между рисковете, мерките за третиране и контролите. Тук класификацията се превръща в одитна проследимост. Рисков сценарий като „неоторизирано разкриване на клиентски финансови данни от споделено облачно хранилище“ може да бъде съпоставен с класификация, етикетиране, контрол на достъпа, шифроване, регистриране, DLP, използване на облачни услуги, изисквания към доставчиците и реагиране при инциденти.

Връзките между контролите, които одиторите очакват да видят

В Zenith Controls: Ръководство за кръстосано съответствие на Clarysec ISO/IEC 27002:2022 контрол 5.12, Класификация на информацията, е картографиран като превантивен контрол, който поддържа поверителност, цялостност и наличност. Той е свързан с концепцията за киберсигурност „Идентифициране“, оперативната способност „Защита на информацията“ и домейните за сигурност „Защита“ и „Отбрана“.

За ISO/IEC 27002:2022 контрол 5.13, Етикетиране на информацията, Zenith Controls картографира контрола като превантивен, фокусиран върху защитата, със същите свойства на информационната сигурност и оперативна способност „Защита на информацията“.

Ключовият извод е, че класификацията и етикетирането не са изолирани. Те правят околните контроли защитими.

Zenith Controls картографира контрол 5.12 към GDPR Article 32 и Recital 83, NIS2 Article 21(2)(a) и 21(2)(f), ISO/IEC 27701 Annex B, NIST SP 800-53 MP-3 и PM-11, FIPS 199 и NIST SP 800-60, както и COBIT 2019 DSS06.06 и APO13.01. Той картографира контрол 5.13 към GDPR Article 32, NIS2 Article 21(2)(a) и 21(2)(f), DORA Article 9(1) и 9(2), NIST SP 800-53 MP-3 и COBIT 2019 DSS06.06.

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

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

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

P12 Политика за управление на активите на Clarysec изисква инвентарът на активите да включва ниво на класификация като минимално поле:

Инвентарът на активите трябва да съдържа най-малко: 5.3.1 Идентификатор на актив, категория и тип 5.3.2 Сериен номер или уникален етикет (за физически активи) 5.3.3 Версия на софтуера или лицензионен ключ (за софтуерни активи) 5.3.4 Собственик на актив 5.3.5 Ниво на класификация (Публична, Вътрешна употреба, Поверителна, Ограничена) 5.3.6 Местоположение (физическо, виртуално, облачно) 5.3.7 Статус на жизнения цикъл (активен, в поддръжка, изведен от употреба)

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

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

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

Етикетите трябва да управляват правилата за работа с данни в облак и SaaS

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

P27 Политика за използване на облачни услуги на Clarysec свързва използването на облачни услуги пряко с класификацията и местонахождението на данните:

Класификация на данни и местонахождение на данните 6.6.1 Данни не могат да бъдат премествани към облачна платформа без класификация в съответствие с Политиката за класификация и етикетиране на данни (P13). 6.6.2 Изискванията за местонахождение на данните трябва да бъдат наложени договорно (напр. съхранение само в ЕС за данни, регулирани от GDPR). 6.6.3 Трансграничните прехвърляния на данни трябва да съответстват на GDPR Chapter V и, когато е приложимо, DORA Article 28.

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

Политиката за класификация и етикетиране на данни - SME дава на по-малките организации прост модел за внедряване:

Споделените папки или облачните дискове трябва да използват имена на папки или тагове, за да посочват класификацията (напр. „/Clients_Confidential“).

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

Етикет „Ограничена“ може да задейства блокиране на външно споделяне, шифроване на данни в покой и при пренос, MFA, ограничения за изтегляне на неуправлявани устройства, съхранение на одитни журнали, SIEM предупреждения, правила за съхранение, ограничения за местоположение на доставчиците и ескалация на сериозността на инцидента.

P13 Политика за класификация и етикетиране на данни задава базовото изискване:

Цялата работа с информация, включително предаване, достъп, съхранение и унищожаване, трябва да съответства на нейното ниво на класификация. Като минимум: 6.3.1.1 Публична: Може да се разкрива свободно; не се изисква специална работа 6.3.1.2 Вътрешна употреба: Споделя се в рамките на организацията; съхранява се в защитени вътрешни системи 6.3.1.3 Поверителна: 6.3.1.3.1 Достъпът е ограничен само до оторизиран персонал 6.3.1.3.2 Трябва да бъде шифрована при пренос и в покой 6.3.1.3.3 Може да се споделя външно само при NDA или еквивалентни договорни защитни мерки 6.3.1.4 Ограничена: 6.3.1.4.1 Прилагат се най-високите изисквания за сигурност 6.3.1.4.2 Изискват се силни контроли на достъпа, многофакторна автентикация (MFA) и журналиране за одит 6.3.1.4.3 Физическа и логическа сегрегация, когато е осъществимо 6.3.1.4.4 Външното споделяне е забранено без одобрение от CISO

Всеки етикет има поведение. Всяко поведение има контрол. Всеки контрол има доказателства.

Практически пример за прилагане

Да разгледаме финтех анализатор, който създава Q3_2026_Customer_Churn_Analysis.xlsx. Таблицата включва клиентски идентификатори, обеми на транзакции и прогнозна оценка за отпадане на клиенти.

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

Файлът е шифрован в покой на устройството и в облачното хранилище. Видима заглавка го маркира като Поверителна. Когато анализаторът се опита да го синхронизира към личен облачен диск, DLP правило блокира действието и регистрира опита. Когато анализаторът се опита да го изпрати по имейл до външен домейн, който не е партньорски, имейл шлюзът поставя съобщението под карантина и предупреждава екипа по операции по сигурността. Ако по-късно файлът бъде прекласифициран като Ограничена, защото съдържа регулирани финансови транзакционни данни, външното споделяне се деактивира, освен ако CISO или собственикът на данните не одобри изключението.

Това е доказателството, което главният изпълнителен директор търсеше. То е проследимо, автоматизирано и свързано с политика, одобрена от управителния съвет. То също така е в съответствие с P27 Политика за използване на облачни услуги, защото не се допуска преместване към облак без класификация, а трансграничните прехвърляния трябва да отговарят на GDPR Chapter V и, когато е приложимо, DORA Article 28.

Изградете матрица от класификация към контроли за една седмица

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

Ден 1: Потвърдете схемата за класификация

Започнете с четири нива: Публична, Вътрешна употреба, Поверителна и Ограничена. Използвайте P13 Политика за класификация и етикетиране на данни като базово изискване. Дефинирайте критерии чрез въздействие върху бизнеса, правно въздействие, договорна чувствителност, риск за личните данни, критичност на услугата и финансова вреда.

Ден 2: Изберете десет критични информационни актива

Използвайте Zenith Blueprint стъпка 9. Включете клиентска база данни, система за билети на поддръжката, платформа за човешки ресурси, доставчик на идентичност, платежен експорт, хранилище за данни, кофа за обектно съхранение, папка за отчетност към управителния съвет, хранилище за код и хранилище за доказателства за инциденти. Запишете собственик, местоположение, класификация и релевантност по GDPR.

Ден 3: Картографирайте правилата за работа с информацията

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

Ден 4: Конфигурирайте един технически път за прилагане

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

Ден 5: Актуализирайте регистъра на риска и SoA

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

Ден 6: Тествайте контрола

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

Ден 7: Обучете потребителите от първа линия

Обучението трябва да бъде специфично за ролята. Разработчиците трябва да знаят кога продукционни данни не могат да се използват в тестови среди. Човешките ресурси трябва да разбират защо досиетата на служителите са Поверителни или Ограничена. Продажбите трябва да знаят защо клиентски експорти не могат да се качват в неодобрени SaaS инструменти. Висшите ръководители трябва да разбират защо материалите за управителния съвет, файловете за придобивания и данните на инвеститорите изискват по-строга работа с тях.

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

Как одиторите ще тестват класификацията и етикетирането

Одиторите рядко тестват класификацията изолирано. Те следват данните.

Одитор по ISO/IEC 27001:2022 ще свърже класификацията с обхвата на ISMS, изискванията на заинтересованите страни, правните и договорните задължения, оценката на риска и Декларацията за приложимост. Той ще очаква доказателства за ISO/IEC 27002:2022 контроли 5.9, 5.12, 5.13, 5.14, 5.15, 5.34 и релевантните технически контроли. Типичните доказателства включват одобрени политики, записи от инвентара на активите, записи в регистъра на риска, етикетирани образци, правила за работа с информацията, прегледи на правата за достъп, одитни констатации от вътрешен одит и коригиращи действия.

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

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

Одитор по COBIT 2019 или в стил ISACA ще постави акцент върху целите на управлението, собствеността върху процесите, дизайна на контролите и оперативната ефективност. Zenith Controls картографира контрола за инвентар 5.9 към COBIT 2019 BAI09.01, BAI09.02 и DSS05.04 и препраща към ISACA ITAF 2204 и 2301. За класификацията Zenith Controls картографира контрол 5.12 към COBIT 2019 DSS06.06 и APO13.01, докато етикетирането се картографира към DSS06.06. Одиторът ще попита кой е собственик на процеса, как се одобряват изключенията, дали резултатността се наблюдава и дали ръководството получава отчетност.

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

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

Често срещани модели на отказ

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

Първо, те класифицират документи, но не и бази данни, приложно-програмни интерфейси (API), журнали, резервни копия, експорти или SaaS записи. Чувствителни данни в журнал за отстраняване на грешки могат да бъдат толкова вредни, колкото чувствителни данни в електронна таблица.

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

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

Четвърто, плановете за реагиране при инциденти пренебрегват класификацията. Ако критериите за степен на сериозност не включват чувствителността на данните, екипите за инциденти губят време да установяват какво е засегнато по време на криза. Анализът на нарушения по GDPR, обработването на инциденти по NIS2 и класификацията на инциденти по DORA печелят от бърз контекст за данните.

Пето, SoA не обяснява защо контролите за класификация и етикетиране са приложими. Организацията може да е внедрила етикети, но SoA не ги свързва с GDPR Article 32, NIS2 Article 21, ИКТ риска по DORA, клиентски договори или конкретни рискови сценарии.

Отчетност към ръководството: направете класификацията видима

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

Полезни показатели включват:

• Процент на критичните информационни активи с определени собственици.
• Процент на активите с одобрена класификация.
• Брой активи с класификация Ограничена без засилено регистриране.
• Брой Поверителни или Ограничена хранилища с активирано външно споделяне.
• Процент на доставчиците, обработващи Поверителни или Ограничена данни, с актуализирани договорни клаузи.
• Брой изключения от класификацията и просрочени действия за отстраняване.
• DLP инциденти по етикет.
• Завършване на прегледи на достъпа за активи с класификация Ограничена.
• Облачни места за съхранение на данни, регулирани от GDPR.
• Упражнения за реагиране при инциденти, които са използвали критерии за сериозност, базирани на класификация.

Тези показатели подпомагат прегледа от ръководството по ISO/IEC 27001:2022, управленския надзор по NIS2, отчетността по управлението по DORA и исканията от клиенти за потвърждение на контролите. Те също правят класификацията разбираема за висшите ръководители. Ръководството може да действа по-бързо, когато види, че няколко хранилища с класификация Ограничена нямат тествано възстановяване или че критични доставчици обработват клиентски данни без потвърдено съхранение в ЕС.

От политика към доказателство

Моделът за внедряване на Clarysec е воден от доказателства:

1. Дефинирайте схемата за класификация в P13 Политика за класификация и етикетиране на данни или започнете с Политиката за класификация и етикетиране на данни - SME.
2. Добавете класификация към инвентара на активите чрез P12 Политика за управление на активите.
3. Прилагайте ограничения за облак и изисквания за местонахождение на данните чрез P27 Политика за използване на облачни услуги.
4. Използвайте Zenith Blueprint стъпка 9, за да идентифицирате информационни активи, собственици, местоположения и чувствителност.
5. Използвайте Zenith Blueprint стъпка 13, за да картографирате рисковете към контролите в SoA.
6. Използвайте Zenith Blueprint стъпка 22, за да внедрите ISO/IEC 27002:2022 контроли 5.12 и 5.13 в ежедневните операции.
7. Използвайте Zenith Controls, за да картографирате същите доказателства към GDPR, NIS2, DORA, NIST CSF, COBIT 2019 и поддържащи стандарти.
8. Тествайте прилагането на етикети, ограниченията на достъпа, регистрирането, DLP и триажа на инциденти.
9. Докладвайте резултатността на класификацията на ръководството.
10. Преглеждайте класификацията след съществени промени в системи, процеси, доставчици или регулации.

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

Ако вашата организация се подготвя за сертификация по ISO/IEC 27001:2022, увереност по GDPR, готовност по NIS2, клиентска надлежна проверка по DORA или комбиниран одит на съответствието, започнете с един въпрос:

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

Ако отговорът все още е „не“, Clarysec може да ви помогне бързо и защитимо да изградите доказателствената верига.

Използвайте Политиката за класификация и етикетиране на данни - SME, P13 Политика за класификация и етикетиране на данни, P12 Политика за управление на активите, P27 Политика за използване на облачни услуги, Zenith Blueprint: 30-стъпкова пътна карта за одитори и Zenith Controls: Ръководство за кръстосано съответствие, за да превърнете класификацията от статична политика в оперативен контролен слой за GDPR Article 32, управление на киберриска по NIS2 и доказателства за ИКТ риска по DORA.

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