Ръководство за регистър на задълженията за съответствие в киберсигурността през 2026 г.

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

„Мария, трябва ми един слайд, който показва, че държим под контрол правните си задължения в областта на киберсигурността за 2026 г. Не само ISO 27001. Имам предвид всичко. NIS2, DORA, GDPR, клиентските ни договори. В съответствие ли сме? Къде са доказателствата? Кой отговаря?“

В 08:15 пристигнаха още три искания. Правният отдел искаше да знае дали дружеството е важен субект съгласно правилата за транспониране на NIS2 в държава членка. Длъжностното лице по защита на данните (DPO) искаше да знае дали подозрителен експорт от база данни трябва да се третира като нарушение на сигурността на личните данни по GDPR, като съществен инцидент, свързан с ИКТ, по DORA, като и двете или като нито едно от тях. Отделът по закупуване искаше одобрение за доставчик на аналитични услуги за предотвратяване на измами, който ще обработва лични данни от ЕС, ще поддържа критична услуга и ще използва облачен подобработващ извън ЕС.

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

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

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

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

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

Clarysec третира регистъра като жив артефакт на СУИС, а не като юридическо приложение. В Политика за правно и регулаторно съответствие функцията по съответствие:

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

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

Какво трябва да прави регистърът на задълженията за съответствие в киберсигурността през 2026 г.

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

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

Второ, той класифицира приложимостта. NIS2 може да се прилага, защото организацията попада в сектор по Приложение I или Приложение II, предоставя цифрова инфраструктура, действа като доставчик на управлявани услуги, предоставя услуги за облачни изчисления или попада в категория, независима от размера, като DNS, TLD или доверителни услуги. DORA може да се прилага, защото организацията е финансов субект или доставчик на ИКТ услуги от трета страна, който поддържа финансови субекти. GDPR може да се прилага, защото организацията обработва лични данни от ЕС, предлага услуги на физически лица в ЕС или наблюдава поведение в ЕС.

Трето, той съпоставя задълженията с вътрешни контроли, политики, процеси и системи. Тук регистърът става оперативен. Мерките за управление на риска по NIS2 Article 21 се съпоставят с оценка на риска, обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата за доставки, сигурна разработка, прегледи на ефективността на контролите, обучение, криптография, контрол на достъпа, управление на активите и многофакторна автентикация (MFA), когато е приложимо. DORA се съпоставя с отчетност на управителния орган, управление на ИКТ риска, класификация на инцидентите, тестване на устойчивостта, регистри на трети страни и стратегии за изход. GDPR се съпоставя с регистър на дейностите по обработване, правно основание, минимизиране на данните, срок за съхранение, сигурност на обработването, оценка на нарушението и доказателства за отчетност.

Четвърто, той определя собственици и периодичност на прегледа. Без собственост съответствието се превръща в тема за среща. Със собственост то се превръща в управляван процес.

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

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

„Всички правни и регулаторни задължения трябва да бъдат съпоставени с конкретни политики, контроли и собственици в рамките на Системата за управление на информационната сигурност (СУИС).“
От Политика за правно и регулаторно съответствие, Изисквания за прилагане на политиката, клауза 6.2.1.

Тя също дефинира доказателствата като част от същия механизъм:

„Необходими артефакти или записи за доказване на съответствие (напр. журнали за одит, настройки за криптиране, документация за съгласие)“
От Политика за правно и регулаторно съответствие, Изисквания за прилагане на политиката, клауза 6.2.2.3.

Това е разликата между осведоменост за съответствието и увереност в съответствието.

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

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

Клаузи 4.1 до 4.4 изискват организацията да разбира вътрешните и външните фактори, да идентифицира заинтересованите страни и да определя правните, регулаторните и договорните изисквания, релевантни за СУИС. Клаузи 5.1 до 5.3 изискват ангажимент на ръководството, съгласуване на политиките, ресурси и възложени отговорности. Клаузи 6.1 до 6.2 изискват оценка на риска, третиране на риска, Декларация за приложимост и измерими цели, основани на приложимите изисквания. Клаузи 8, 9 и 10 създават оперативния цикъл: внедряване на контроли, повторна оценка на рисковете, мониторинг на резултатността, провеждане на вътрешни одити, преглед от ръководството и коригиране на несъответствия.

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

„Клауза 4.2 не изисква конкретен документ, но на практика е полезно да се създаде таблица за анализ на заинтересованите страни. Това може да бъде проста таблица с колони: заинтересована страна, потребности/очаквания, как ги адресираме.“
От Zenith Blueprint, фаза „Основи и лидерство на СУИС“, Стъпка 2.

Този анализ на заинтересованите страни се превръща във вход на по-високо ниво за регистъра на задълженията. След това регистърът става мост към третирането на риска.

Във фазата „Управление на риска“, Стъпка 13, Zenith Blueprint указва на екипите да съпоставят контролите с рискове, клаузи и външни регулации:

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

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

Трите опорни контроли от ISO/IEC 27002:2022

Централният контрол от ISO/IEC 27002:2022 за управление на задълженията е 5.31, Правни, законови, регулаторни и договорни изисквания. Zenith Controls: The Cross-Compliance Guide на Clarysec класифицира 5.31 като превантивен контрол, свързан с поверителност, цялостност и наличност, съгласуван с концепцията Identify в киберсигурността и действащ в способността „Правни въпроси и съответствие“ в областите управление, екосистема и защита.

Формулировката в Zenith Controls е директна:

„Сигурността не съществува във вакуум. Тя действа в мрежа от задължения — някои определени от закона, други от договор, а трети от секторно специфична регулация.“
От Zenith Controls, третиране на контрол 5.31 от ISO/IEC 27002:2022.

Контрол 5.31 не работи самостоятелно. Два поддържащи контрола са съществени.

Контрол 5.2, Роли и отговорности по информационна сигурност, гарантира, че задълженията не се възлагат абстрактно на „бизнеса“ или „ИТ“. Съпоставянето в Zenith Controls свързва 5.2 със собственост върху политиките, мониторинг на съответствието, управление на инциденти, осведоменост, независим преглед, обработване на доказателства и управление на привилегирован достъп.

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

Заедно тези контроли отговарят на основните въпроси на одитора.

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

„Управителят трябва да поддържа прост, структуриран Регистър на съответствието, който изброява:“
От Политика за правно и регулаторно съответствие - МСП, Изисквания за управление, клауза 5.1.1.

Тя също изисква рутинен преглед:

„Регистърът на съответствието трябва да се преглежда на тримесечна база и да се актуализира, когато:“
От Политика за правно и регулаторно съответствие - МСП, Изисквания за управление, клауза 5.1.2.

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

Изграждайте регистъра около задълженията, а не около рамките

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

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

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

Целта не е да се скрият правните различия. Целта е да не се внедрява една и съща способност три пъти.

Практичен модел на регистър, който можете да внедрите тази седмица

Регистърът на задълженията в стил Clarysec трябва да бъде достатъчно прост за поддръжка и достатъчно подробен, за да издържи на извадково одитно тестване. Минималните полета са:

1. Идентификатор на задължението.
2. Източник, например NIS2, DORA, GDPR, ISO/IEC 27001:2022, клиентски договор или вътрешна политика.
3. Конкретен член, клауза или договорна препратка.
4. Обобщение на изискването.
5. Обосновка на приложимостта.
6. Засегнат бизнес процес или услуга.
7. Рисков сценарий при неизпълнение.
8. Съпоставяне с контроли, включително контроли от ISO/IEC 27002:2022 и препратки към вътрешни политики.
9. Собственик на контрола.
10. Собственик на доказателствата.
11. Периодичност на прегледа.
12. Местоположение на доказателствата.
13. Изключения или открити пропуски.
14. Индикатор за ескалация към преглед от ръководството.
15. Дата на последния преглед и дата на следващия преглед.
16. Статус.

Ето практически пример за SaaS финтех доставчик, работещ в ЕС.

| Идентификатор на задължението | Източник и изискване | Вътрешно съпоставяне | Собственик | Периодичност на прегледа | Доказателства | |—|—|—|—|—| | OBL-001 | Приложимост на NIS2 и класификация на субекта за цифрова инфраструктура или дейности като доставчик на управлявани услуги | Политика за правно и регулаторно съответствие, контрол 5.31, обхват на СУИС | Мениджър по съответствието | Тримесечно и при промяна на услуга | Меморандум за приложимост, данни за регистрация на субекта, брифинг за управителния орган | | OBL-002 | Управление на ИКТ риска от трети страни по DORA за критични или важни ИКТ услуги | Процедура за сигурност на доставчиците, контроли 5.19 до 5.23, регистър на доставчиците по DORA | Собственик на риска от доставчици | Тримесечно и преди нов критичен доставчик | Регистър на доставчиците, надлежна проверка, договорни клаузи, тест за изход | | OBL-003 | Оценка на нарушение на сигурността на личните данни и отчетност по GDPR | План за реагиране при инциденти, процедура за поверителност, контроли 5.24 до 5.28 и 5.34 | DPO и мениджър по инциденти | При всеки инцидент, тримесечен преглед на тенденциите | Оценка на нарушението, билет за инцидент, решение за уведомяване, научени уроци | | OBL-004 | Мониторинг, вътрешен одит и преглед от ръководството по ISO/IEC 27001:2022 | Процес за одит и мониторинг на съответствието, контрол 5.36 | Мениджър на СУИС | Годишен план за одит, тримесечен мониторинг | Доклад от вътрешен одит, табло с KPI, журнал на коригиращите действия | | OBL-005 | Клиентски договор изисква уведомяване за инцидент по сигурността в рамките на 24 часа | Регистър на договорите, наръчник за комуникации при инциденти | Екип „Клиентски успех“ и правен отдел | При промяна на договор и при всеки инцидент | Извлечение от договорна клауза, запис за комуникации при инцидент |

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

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

„Отговорностите по управление (напр. преглед на политики, одобрение на изключения, надзор върху доставчици) трябва да бъдат възложени на конкретни лица или роли.“
От Политика за роли и отговорности в управлението - МСП, Изисквания за управление, клауза 5.3.

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

Пример за докладване на инциденти: един наръчник, множество задължения

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

Записът в регистъра трябва да улови задължението точно:

• Източник: NIS2 Article 23.
• Изискване: уведомяване на CSIRT или компетентния орган без неоправдано забавяне за значими инциденти, с ранно предупреждение в рамките на 24 часа, уведомяване в рамките на 72 часа и окончателен доклад в рамките на един месец.
• Приложимост: потенциално приложимо поради категорията услуга и дейностите в държави членки.
• Риск при неизпълнение: регулаторно нарушение, забавено уведомяване на заинтересованите страни, загуба на клиентско доверие.

След това го съпоставете с контроли. Контроли 5.24 до 5.28 от ISO/IEC 27002:2022 обхващат планиране на управлението на инциденти, оценка, реагиране, извличане на поуки и събиране на доказателства. Контрол 5.31 обхваща проследяването на правни задължения. Контрол 5.2 обхваща възлагането на роли. Контрол 5.36 обхваща мониторинга дали процесът се спазва.

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

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

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

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

Управлението на доказателства е мястото, където одитите често се провалят

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

Политика за одит и мониторинг на съответствието - МСП на Clarysec дава базовото изискване:

„Всички доказателства трябва да се съхраняват в централизирана одитна папка.“
От Политика за одит и мониторинг на съответствието - МСП, Изисквания за прилагане на политиката, клауза 6.2.1.

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

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

Третирането на контрол 5.31 в Zenith Controls свързва правните изисквания със съхранението на записи чрез контрол 5.33, поверителността и защитата на лично идентифицираща информация (PII) чрез контрол 5.34, независимия преглед чрез контрол 5.35 и вътрешното съответствие чрез контрол 5.36. Това е важно, защото самите доказателства могат да съдържат регулирана информация, като лични данни, форензични индикатори, журнали за привилегирован достъп или поверителни клиентски данни.

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

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

Одитор по ISO/IEC 27001:2022 ще започне с контекста, заинтересованите страни, обхвата, третирането на риска, Декларацията за приложимост, мониторинга, вътрешния одит и прегледа от ръководството. За контрол 5.31 одиторът ще очаква да види, че приложимите правни и договорни изисквания са идентифицирани, поддържат се актуални и са отразени в контролите. За контрол 5.2 той ще тества дали отговорностите са възложени и разбрани. За контрол 5.36 ще търси мониторинг, несъответствия и коригиращи действия.

Оценител, съгласуван с NIST, ще се фокусира върху управленските резултати. NIST Cybersecurity Framework 2.0 GOVERN включва GV.OC-03, който очаква правните, регулаторните и договорните изисквания относно киберсигурността, включително задълженията за поверителност и граждански свободи, да бъдат разбрани и управлявани. Оценителят може да поиска организационен профил, анализ на пропуските и приоритизиран план за действие, след което да тества извадково дали задълженията се превеждат в управление на активите, контрол на достъпа, защита на данните, протоколиране, реагиране и възстановяване.

Одитор по COBIT 2019 или ISACA ще разглежда през целите на управление и мениджмънт. MEA03, Managed Compliance With External Requirements, е особено релевантен. Одиторът може да тества дали външните изисквания са идентифицирани чрез MEA03.01, дали реакциите са оптимизирани чрез MEA03.02, дали съответствието е потвърдено чрез MEA03.03 и дали е получена увереност чрез MEA03.04.

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

Технически оценител може да валидира контрол 5.36 чрез конфигурационни доказателства. Ако регистърът посочва, че NIS2 и клиентските договори изискват MFA за привилегирован достъп, той може да провери настройките на доставчика на идентичност. Ако посочва, че GDPR и договорите изискват криптиране, той може да прегледа криптирането на базата данни, записите за управление на ключове и схемите на потоците от данни. Ако DORA изисква мониторинг на ИКТ услуги от трети страни, той може да провери прегледите на услуги, SLA отчетите и записите от тестове за изход.

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

Прегледът от ръководството затваря цикъла на отчетност

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

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

Политика за информационна сигурност на Clarysec е съгласувана с това очакване:

„Дейностите по преглед от ръководството (съгласно ISO/IEC 27001 Клауза 9.3) се извършват поне веднъж годишно и включват:“
От Политика за информационна сигурност, Изисквания за управление, клауза 5.3.

Политиката за одит за МСП добавя оперативната връзка:

„Одитните констатации и актуализациите на статуса трябва да бъдат включени в процеса на преглед от ръководството на СУИС.“
От Политика за одит и мониторинг на съответствието - МСП, Изисквания за управление, клауза 5.4.3.

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

Това превръща регистъра от файл за съответствие в управленски инструмент.

Често срещани модели на провал и как да ги избегнете

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

Вторият е проследяване на рамки вместо задължения. Запис в регистъра, който казва „DORA“, не е приложим на практика. Запис, който казва „DORA Article 28 управление на ИКТ риска от трети страни изисква надлежна проверка, договорни разпоредби, мониторинг и стратегии за изход“, е приложим.

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

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

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

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

Как Clarysec превръща регистъра в оперативен механизъм

30-стъпковият подход на Clarysec прави управлението на задълженията практично.

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

Blueprint посочва:

„Работете с правния отдел, функцията по съответствие или външен правен консултант, за да изградите регистър на приложимите закони, регулации и договорни задължения, свързани с информационната сигурност (5.31). Това трябва да включва закони за защита на данните (напр. GDPR), секторно специфични изисквания и задължителни изисквания за сертификация. Уверете се, че екипът на СУИС знае къде да прави справка и че промените се преглеждат поне на тримесечна база.“
От Zenith Blueprint, фаза „Контроли в действие“, Стъпка 23.

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

Zenith Controls предоставя компас за кръстосано съответствие. За контрол 5.31 той съпоставя управлението на задълженията с отчетността по GDPR, задълженията по киберсигурност по NIS2, управлението на ИКТ риска по DORA, управлението по NIST CSF, управлението на програми и непрекъснатия мониторинг по NIST SP 800-53 и мониторинга на външното съответствие по COBIT 2019. За контрол 5.2 той свързва отчетността по роли с GDPR, NIS2, DORA, NIST и COBIT. За контрол 5.36 той свързва мониторинга на съответствието с политики с отчетността по GDPR, очакванията за киберхигиена и контрол на достъпа по NIS2, оперативната устойчивост по DORA, непрекъснатия мониторинг по NIST и мониторинга на съответствието по COBIT.

Стойността е проста: един регистър, една архитектура на контролите, много резултати по съответствие.

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

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

Започнете със следните действия:

1. Създайте или актуализирайте регистъра си на задълженията за съответствие в киберсигурността.
2. Добавете NIS2, DORA, GDPR, ISO/IEC 27001:2022 и ключови договорни задължения към клиенти.
3. Съпоставете всяко задължение с политики, контроли от ISO/IEC 27002:2022, собственици, периодичност на прегледа и доказателства.
4. Идентифицирайте пропуски, изключения и доказателства с изтекъл срок.
5. Добавете статуса на регистъра към следващия преглед от ръководството на СУИС.
6. Използвайте Zenith Blueprint на Clarysec, за да поставите регистъра в 30-стъпковата пътна карта за СУИС.
7. Използвайте Zenith Controls, за да съпоставите кръстосано задълженията с очакванията по ISO, NIST, COBIT, GDPR, NIS2 и DORA.
8. Използвайте Политика за правно и регулаторно съответствие, Политика за правно и регулаторно съответствие - МСП, Политика за роли и отговорности в управлението - МСП, Политика за одит и мониторинг на съответствието - МСП и Политика за информационна сигурност на Clarysec, за да формализирате собствеността, прегледа, съхранението на доказателства и управленската отчетност.

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