ISO 27001 като основа за доказателства по NIS2 и DORA

Сблъсъкът на изискванията за съответствие в понеделник сутрин
В 08:12 в понеделник Мария, CISO на европейски обработвател на плащания, получава три съобщения, които на пръв поглед нямат връзка помежду си.
Мениджърът по вътрешен одит иска доказателства, че Декларацията за приложимост по ISO 27001:2022 е актуална. Правният екип препраща въпросник от банков партньор относно надзора върху ИКТ риска от трети страни по DORA. Директорът „Операции“ пита дали същият наръчник за инциденти може да покрие очакванията за уведомяване по NIS2 за новопридобито бизнес звено в ЕС.
До 09:00 бялата дъска в офиса на Мария е покрита със съкращения: ISO 27001, NIS2, DORA, GDPR, NIST, COBIT 2019. Организацията ѝ има контроли. Има управление на достъпа, резервни копия, въпросници за доставчици, шифроване, реагиране при инциденти, одобрения на политики, прегледи от ръководството и записи за обучения. Това, което липсва, е единна одитно готова основа от доказателства, която обяснява защо тези контроли съществуват, кои рискове третират, кои регулации подкрепят, кой отговаря за тях и къде се намират доказателствата.
Този проблем става все по-често срещан в Европа. NIS2 изисква управление на риска за киберсигурността, управление, обработване на инциденти и устойчивост на веригата на доставки. DORA добавя подробни изисквания за управление на ИКТ риска, тестване на устойчивостта, докладване на инциденти и надзор върху ИКТ трети страни за финансови субекти. GDPR продължава да изисква отчетност, сигурност на обработването, управление на обработващи лични данни и оценка на нарушения на сигурността на личните данни.
Грешният подход е да се изградят три паралелни програми за съответствие. Това води до дублирани контроли, непоследователни доказателства и претоварени екипи.
По-силният подход е ISO 27001:2022 да се използва като контролна основа. Не като сертификат на стената, а като оперативна система за риск, политики, управление на доставчици, реагиране при инциденти, съпоставяне на изискванията за съответствие и одитни доказателства.
Практическият модел на Clarysec е прост: използвайте СУИС по ISO 27001:2022 като организационна система, използвайте Декларацията за приложимост като мост, използвайте политиките като приложими оперативни правила и използвайте Zenith Controls: ръководство за кръстосано съответствие като ориентир за кръстосано съответствие. Изграждайте веднъж, съпоставяйте внимателно, доказвайте непрекъснато.
Защо ISO 27001:2022 работи като основа за съответствие
NIS2 и DORA имат различен обхват, правни механизми и надзорни модели. NIS2 се прилага за съществени и важни субекти в различни сектори. DORA се прилага за финансови субекти и създава подробни изисквания за цифрова оперативна устойчивост. GDPR се фокусира върху обработването на лични данни и отчетността.
Въпреки това оперативните въпроси зад тези рамки се припокриват:
- Управлява ли се киберсигурността чрез политики, одобрени от ръководството?
- Идентифицират ли се, оценяват ли се и третират ли се рисковете за информационната сигурност и ИКТ рисковете?
- Избират ли се контролите въз основа на риск, бизнес контекст и правни задължения?
- Управляват ли се доставчиците чрез надлежна проверка, договори, мониторинг и контроли при прекратяване?
- Може ли персоналът да разпознава и докладва своевременно събития по сигурността?
- Могат ли инцидентите да бъдат триажирани, ескалирани, разследвани и оценени за регулаторно уведомяване?
- Може ли организацията бързо да извлече доказателства при одит, клиентски преглед или надзорно запитване?
ISO 27001:2022 предоставя на ръководството система за управление, чрез която тези въпроси се адресират последователно. ISO/IEC 27007:2022 третира Декларацията за приложимост като одитируем списък на избраните контроли за информационна сигурност, включително контроли от приложение A на ISO 27001:2022, други стандарти или специфични за организацията мерки, с документирана обосновка за включване или изключване. ISO/IEC 27006-1:2024 потвърждава, че SoA и свързаната документация на СУИС формират основна доказателствена база, която показва кои контроли са необходими, как са разпределени отговорностите и как политиките са внедрени и комуникирани.
Това прави SoA много повече от електронна таблица. Тя се превръща в контролен договор между риска, съответствието, операциите, правния отдел, снабдяването, одита и управителния съвет.
[P01] Политика за информационна сигурност на Clarysec закрепва това управленско изискване:
Организацията трябва да внедри и поддържа Система за управление на информационната сигурност (СУИС) в съответствие с ISO/IEC 27001:2022 Clauses 4 through 10.
От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.1.1.
Това е важно, защото исканията за доказателства по NIS2 и DORA рядко пристигат на езика на ISO. Регулатор, клиент или комитет към управителния съвет може да поиска доказателства за управление на риска за киберсигурността, управление на ИКТ, надзор върху зависимости от трети страни, ескалация на инциденти или тестване на оперативната устойчивост. СУИС по ISO 27001:2022 дава структура на тези отговори.
SoA е мостът, а не упражнение по документация
В Zenith Blueprint: 30-стъпкова пътна карта за одитори, фаза „Управление на риска“, стъпка 13, Clarysec определя SoA като ключов механизъм за проследимост между третирането на риска и внедрените контроли:
SoA на практика е мостов документ: тя свързва вашата оценка/третиране на риска с реалните контроли, с които разполагате.
Това изречение е същността на кръстосаното съответствие. Контрол без проследимост се превръща в изолиран артефакт. Контрол, свързан с риск, правно задължение, политика, собственик, запис с доказателства и резултат от тест, става одитно готов.
Стъпка 13 препоръчва също към рисковите сценарии да се добавят препратки към контроли, например свързване на сценарий за нарушение на клиентска база данни с контрол на достъпа, криптография, управление на уязвимостите, реагиране при инциденти и контроли за доставчици. Тя препоръчва също да се отбелязва кога контролите поддържат външни изисквания като GDPR, NIS2 или DORA.
[P06] Политика за управление на риска на Clarysec прави това оперативно правило изрично:
Решенията за контроли, произтичащи от процеса на третиране на риска, трябва да бъдат отразени в SoA.
От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.5.1.
За по-малки организации Политика за управление на риска – SME използва същата логика:
Тя гарантира, че управлението на риска е активен компонент на планирането, изпълнението на проекти, избора на доставчици и реагирането при инциденти, в съответствие с ISO 27001, ISO 31000 и приложимите регулаторни изисквания.
От раздел „Цел“, клауза на политиката 1.2.
Ако третиране на риск от трета страна по DORA, мярка за обработване на инциденти по NIS2 или изискване за сигурност към обработващ лични данни по GDPR не са отразени в SoA или свързания регистър на съответствието, организацията може все пак да извършва дейността. Но ще ѝ бъде трудно да я докаже последователно.
Практическа съпоставка на ISO 27001:2022 с NIS2 и DORA
Следната съпоставка не е правен съвет. Тя е практически модел за доказателства за CISO, ръководители по съответствие, вътрешни одитори и собственици на процеси, които трябва да съгласуват доказателствата по ISO 27001:2022 с очакванията на NIS2 и DORA.
ENISA, съвместно с Европейската комисия и Групата за сътрудничество по NIS, е предоставила консултативни насоки за кръстосани препратки, които подпомагат съгласуването на изискванията на ЕС за киберсигурност с международни и национални стандарти, включително ISO 27001. Тези насоки не са правно обвързващи и трябва да бъдат допълнени с указания на националните органи, секторни правила и правен преглед. Въпреки това те подкрепят защитим подход за съпоставяне.
| Въпрос за съответствие | Доказателства от основата по ISO 27001:2022 | Значение за NIS2 | Значение за DORA | Артефакт с доказателства на Clarysec |
|---|---|---|---|---|
| Управлява ли се киберсигурността чрез политики, одобрени от ръководството? | Политика за информационна сигурност, обхват на СУИС, роли, записи от прегледи от ръководството, SoA | Очаквания за управление на риска за киберсигурността и управление | Управление на ИКТ и рамка за управление на ИКТ риска | Политика за информационна сигурност, SoA, пакет за преглед от ръководството |
| Оценяват ли се и третират ли се рисковете? | Регистър на риска, План за третиране на риска, обосновки в SoA, одобрения на остатъчен риск | Риск-базирани мерки за киберсигурност по Article 21 | Идентифициране, защита, превенция, откриване, реагиране и възстановяване при ИКТ риск | Регистър на риска, План за третиране на риска, SoA_Builder.xlsx |
| Контролират ли се доставчиците? | Политика за доставчици, записи от надлежна проверка, договори, права на одит, клаузи за уведомяване при нарушение | Киберсигурност на веригата на доставки по Article 21(2)(d) | Управление на ИКТ риск от трети страни по Articles 28 to 30 | Политика за сигурност на трети страни и доставчици, регистър на доставчиците |
| Откриват ли се, ескалират ли се и докладват ли се инцидентите? | План за реагиране при инциденти, канал за докладване, записи от триаж, настолни учения, извлечени поуки | Обработване и докладване на значими инциденти по Article 23 | Управление и докладване на ИКТ-свързани инциденти по Articles 17 to 19 | Политика за реагиране при инциденти, билети за инциденти, доклад от учение |
| Централизирани и одитируеми ли са доказателствата? | Програма за вътрешен одит, хранилище за доказателства, регистър на съответствието, коригиращи действия | Готовност на доказателствата за надзор | Готовност за регулаторни и надзорни проверки | Политика за одит и мониторинг на съответствието, централна папка за одит |
Съпоставката работи, защото не създава дублирани контроли за всяка регулация. Тя използва ISO 27001:2022 като контролна основа и добавя регулаторни етикети, собственост и очаквания за доказателства.
Три контрола по ISO 27001:2022, които отключват основата
За NIS2 и DORA са важни редица контроли, но три контрола по ISO/IEC 27002:2022 често се превръщат в гръбнака на модела за доказателства: 5.1, 5.19 и 5.24. Четвърти контрол, 6.8, често определя дали докладването на инциденти работи в реални условия.
| Контрол по ISO/IEC 27002:2022 | Защо е важен | Стойност за кръстосано съответствие |
|---|---|---|
| 5.1 Policies for information security | Установява одобрена от ръководството посока за сигурност и отчетност | Подкрепя управлението по NIS2, управлението на ИКТ по DORA, отчетността по GDPR и доказателствата за политики по ISO 27001 |
| 5.19 Information security in supplier relationships | Определя очакванията за сигурност към доставчиците при въвеждане, мониторинг и управление на взаимоотношенията | Подкрепя киберсигурността на веригата на доставки по NIS2, ИКТ риска от трети страни по DORA и надзора върху обработващи лични данни по GDPR |
| 5.24 Information security incident management planning and preparation | Създава рамката за управление на инциденти, ролите, пътищата за ескалация и дейностите за готовност | Подкрепя обработването на инциденти по NIS2, докладването на ИКТ-свързани инциденти по DORA и оценката на нарушения по GDPR |
| 6.8 Information security event reporting | Гарантира, че персоналът може бързо да докладва подозирани събития чрез ясни канали | Подкрепя ранното откриване, ескалацията, оценката за уведомяване и качеството на доказателствата за инциденти |
В Zenith Controls контрол 5.1 по ISO/IEC 27002:2022, Policies for information security, е описан като превантивен контрол, който подкрепя поверителност, цялостност и наличност, като управлението и управлението на политики са основни оперативни способности. Кръстосаното съпоставяне обяснява, че GDPR Articles 5(2), 24 и 32 изискват отчетност, отговорност и сигурност на обработването. Същият контрол е съпоставен и с очакванията на NIS2 за управление на риска за киберсигурността и управление, както и с изискванията на DORA за управление на ИКТ и рамка за управление на риска.
Затова политиката за информационна сигурност не е просто поредната политика. Оценител по NIS2 може да я разглежда като доказателство за управление. Надзорен орган по DORA може да я разглежда като доказателство за рамка за ИКТ риск. Преглеждащ по GDPR може да я разглежда като доказателство за отчетност. Одитор по ISO 27001:2022 може да я разглежда като част от структурата на политиките на СУИС.
Контрол 5.19, Information security in supplier relationships, е мястото, където се срещат снабдяване, правни въпроси, сигурност, поверителност и устойчивост. Zenith Controls го съпоставя със задълженията към обработващи лични данни по GDPR, киберсигурността на веригата на доставки по NIS2 и управлението на ИКТ риск от трети страни по DORA. За DORA тези доказателства стават още по-силни, когато са подкрепени от контроли 5.20, Addressing information security within supplier agreements, 5.21, Managing information security in the ICT supply chain, и 5.23, Information security for use of cloud services.
Контрол 5.24, Information security incident management planning and preparation, е оперативният двигател на готовността за инциденти. Zenith Controls го съпоставя с обработване и уведомяване за инциденти по NIS2, уведомяване при нарушение на сигурността на личните данни по GDPR и управление и докладване на ИКТ-свързани инциденти по DORA. Неговите доказателства не са само политика за реагиране при инциденти. Те включват канали за докладване, критерии за триаж, записи за ескалация, правни оценки за уведомяване, настолни учения, билети за инциденти и извлечени поуки.
Контрол 6.8, Information security event reporting, затваря пропастта между писмения план и човешкото поведение. Ако персоналът не знае как да докладва подозирани фишинг съобщения, изтичане на данни, прекъсвания при доставчик или подозрителна системна активност, организацията може да загуби критично време още преди да започнат правните или регулаторните оценки за докладване.
Един инцидент при доставчик, една координирана верига от доказателства
Представете си, че доставчик на облачна аналитика, използван от обработвателя на плащания на Мария, открива неоторизиран достъп до портал за поддръжка. Доставчикът хоства псевдонимизирани данни за клиентско използване и поддържа работен процес за докладване от критично значение за бизнеса. Инцидентът може да засегне лични данни, регулирана ИКТ устойчивост и наличност на услугата.
Фрагментирана програма за съответствие отваря три отделни работни потока: оценка на нарушение по GDPR, преглед на ИКТ инцидент по DORA и билет за доставчик по ISO 27001. Всеки екип иска сходни доказателства в различен формат. Снабдяването търси договора. Правният отдел пита дали доставчикът е обработващ лични данни. Сигурността пита дали инцидентът достига праговете за докладване. Съответствието започва нова електронна таблица.
Зряла основа по ISO 27001:2022 отваря една координирана верига от доказателства.
Първо, събитието се регистрира в процеса за реагиране при инциденти. Докладващият използва определен канал, екипът по сигурност извършва триаж на събитието, а правният отдел оценява задълженията за уведомяване. [P30] Политика за реагиране при инциденти на Clarysec изисква инцидентите с регулирани данни да бъдат оценявани от правния отдел и DPO:
Ако инцидент доведе до потвърдено или вероятно експониране на лични данни или други регулирани данни, правният отдел и DPO трябва да оценят приложимостта на:
От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.4.1.
За по-малки организации Политика за реагиране при инциденти – SME възлага същата практическа точка за решение:
Когато са засегнати клиентски данни, Управителят трябва да оцени правните задължения за уведомяване въз основа на приложимостта на GDPR, NIS2 или DORA.
От раздел „Третиране на риска и изключения“, клауза на политиката 7.4.1.
Второ, преглежда се взаимоотношението с доставчика. Класифициран ли е доставчикът като критичен? Включва ли договорът задължения за уведомяване при нарушение, права на одит, отговорности за защита на данните, очаквания за непрекъсваемост на услугите и условия за прекратяване? Политика за сигурност на трети страни и доставчици на Clarysec задава това очакване:
Въвеждайте стандартизирани изисквания за сигурност във всички договори с доставчици, включително задължения за уведомяване при нарушение, права на одит и отговорности за защита на данните.
От раздел „Цели“, клауза на политиката 3.2.
За SME Политика за сигурност на трети страни и доставчици – SME прави целта за кръстосано съответствие изрична:
Подкрепяйте съответствието с ISO/IEC 27001:2022, GDPR, NIS2 и DORA задълженията, свързани с управлението на доставчици.
От раздел „Цели“, клауза на политиката 3.6.
Трето, регистърът на риска, планът за третиране и SoA се актуализират, ако инцидентът разкрие пропуск. Може би договорът с доставчика няма конкретен регулаторен срок за уведомяване. Може би честотата на мониторинг на доставчика е твърде ниска за критичен ИКТ доставчик. Може би планът за реагиране при инциденти не разграничава ясно критериите за нарушение на сигурността на личните данни от критериите за прекъсване на ИКТ услуга.
Целта не е да се създаде нова вселена на съответствие. Целта е да се актуализира една интегрирана верига от доказателства, така че едни и същи записи да могат да отговорят на множество одитни въпроси.
Превръщане на SoA в карта на доказателствата за NIS2 и DORA
Стандартната SoA често отговаря добре на въпросите по ISO: кои контроли са приложими, защо са избрани и дали са внедрени. За да я превърнете в практическа карта на доказателствата за NIS2 и DORA, обогатете я с регулаторни и оперативни полета за доказателства.
Отворете SoA_Builder.xlsx от Audit Ready Toolkit, посочен в Zenith Blueprint, фаза „Одит, преглед и подобрение“, стъпка 24. Стъпка 24 обяснява, че одиторите често избират контрол от SoA като извадка и питат защо е внедрен. Колоната с обосновка и свързаният риск или изискване трябва да отговарят на този въпрос.
Добавете тези колони:
| Нова колона в SoA | Цел | Примерен запис |
|---|---|---|
| Регулаторен фактор | Показва дали контролът подкрепя NIS2, DORA, GDPR, клиентски договори или устойчивост | NIS2, DORA, GDPR |
| Съпоставен идентификатор на риска | Свързва контрола с регистъра на риска | R-017 Прекъсване при доставчик, засягащо регулирано докладване |
| Собственик на доказателствата | Идентифицира кой поддържа доказателствата | Ръководител „Операции по сигурността“ |
| Основни доказателства | Определя артефакта, който одиторите трябва първо да проверят | План за реагиране при инциденти и журнал на билетите за инциденти |
| Оперативни доказателства | Показва, че контролът работи във времето | Доклад от настолно учение, тест на уведомяване при нарушение от доставчик |
| Статус при одит | Проследява готовността | Тествано, отворен пропуск, предстоящо коригиращо действие |
След това го приложете към основния набор от контроли.
| Контрол по ISO/IEC 27002:2022 | Регулаторен фактор | Основни доказателства | Оперативни доказателства | Заключение на одитора |
|---|---|---|---|---|
| 5.1 Policies for information security | NIS2, DORA, GDPR | Одобрена политика за информационна сигурност, обхват на СУИС, възлагане на роли | Запис от преглед на политиката, потвърждение за завършено обучение, протоколи от преглед от ръководството | Управлението е налице, ръководството е одобрило посоката, отчетността е документирана |
| 5.19 Information security in supplier relationships | NIS2, DORA, GDPR | Политика за доставчици, регистър на доставчиците, класификация на доставчиците | Прегледи от надлежна проверка, оценки на критичността, прегледи на договори, доказателства за право на одит | Рискът от трети страни се управлява през въвеждане, договаряне, мониторинг и прекратяване |
| 5.20 Addressing information security within supplier agreements | NIS2, DORA, GDPR | Стандартни договорни клаузи, приложение за сигурност, условия за обработване на данни | Извадково тестване на договори, одобрения на изключения от клаузи, записи от правен преглед | Изискванията за сигурност са вградени в споразуменията с доставчици |
| 5.23 Information security for use of cloud services | DORA, NIS2, GDPR | Стандарт за облачна сигурност, оценка на риска за облачни услуги, одобрение на архитектура | Преглед на облачен доставчик, преглед на риска от концентрация, тест на облачен инцидент | Рискът от облачни услуги е идентифициран, управляван, наблюдаван и тестван |
| 5.24 Information security incident management planning and preparation | NIS2, DORA, GDPR | Политика за реагиране при инциденти, матрица за ескалация, дърво за решения за уведомяване | Билети за инциденти, доклади от настолни учения, извлечени поуки, оценки за уведомяване | Инцидентите могат да бъдат откривани, триажирани, ескалирани и оценявани за регулаторно докладване |
| 6.8 Information security event reporting | NIS2, DORA, GDPR | Канал за докладване, материали за осведоменост, процедура за докладване на събития | Доклади за фишинг, журнали на гореща линия, записи от симулации, интервюта с персонал | Персоналът знае как бързо да докладва подозирани събития по сигурността |
След това изпълнете примерна проследимост. Изберете един инцидент при доставчик от последната година и го проследете от билета за инцидент до договора с доставчика, от класификацията на доставчика до регистъра на риска, от третирането на риска до SoA и от SoA до прегледа от ръководството.
Ако веригата се прекъсне, това не е провал. Това е точното коригиращо действие, което трябва да предприемете, преди одитор, клиент, регулатор или комитет към управителния съвет да открие пропуска.
Централизираните доказателства са пренебрегваният ускорител
Много организации имат адекватни контроли, но слабо извличане на доказателства. Доказателствата са разпръснати в електронна поща, системи за билети, папки в SharePoint, хранилища за договори, HR платформи, GRC инструменти и портали на доставчици. По време на одитния сезон екипът по съответствие прекарва седмици в търсене на екранни снимки.
Това не е готовност за одит. Това е възстановяване на доказателства за целите на одита.
[P33S] Политика за одит и мониторинг на съответствието – SME на Clarysec посочва:
Всички доказателства трябва да се съхраняват в централизирана папка за одит.
От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.2.1.
Централизирана папка за одит не означава неконтролирано място за събиране на всичко. Тя означава структурирано хранилище, съгласувано със СУИС, SoA, регистъра на риска, плана за одит и регистъра на съответствието.
| Папка | Съдържание | Използване за кръстосано съответствие |
|---|---|---|
| 01 Управление | Обхват на СУИС, политика за информационна сигурност, възлагане на роли, протоколи от прегледи от ръководството | Управление по NIS2, управление на ИКТ по DORA, отчетност по GDPR |
| 02 Риск и SoA | Регистър на риска, план за третиране на риска, SoA, одобрения на остатъчен риск | Управление на риска по NIS2, управление на ИКТ риска по DORA |
| 03 Доставчици | Регистър на доставчиците, надлежна проверка, договори, оценки на критичността, записи от преглед | Верига на доставки по NIS2, ИКТ риск от трети страни по DORA, обработващи лични данни по GDPR |
| 04 Инциденти | Билети за инциденти, оценки на нарушения, решения за уведомяване, настолни учения | Докладване по NIS2, управление на инциденти по DORA, уведомяване при нарушение по GDPR |
| 05 Одит и подобрение | Доклади от вътрешен одит, коригиращи действия, извадково тестване на доказателства, последващи действия от ръководството | Готовност за одит по ISO 27001:2022, готовност за надзор |
Политика за правно и регулаторно съответствие – SME на Clarysec адресира директно проблема със съпоставянето:
Когато дадена регулация се прилага в множество области (напр. GDPR се прилага към съхранение, сигурност и поверителност), това трябва ясно да бъде картиранo в Регистъра на съответствието и материалите за обучение.
От раздел „Изисквания за управление“, клауза на политиката 5.2.2.
Точно така ISO 27001:2022 се превръща в контролна основа за NIS2 и DORA. Не разчитате на неформално знание. Съпоставяте регулациите с процеси, политики, контроли, доказателства и обучение.
Докладването на инциденти започва с хората, не с порталите
Честа слабост при одит възниква, когато планът за реагиране при инциденти изглежда силен, но служителите не знаят кога или как да докладват. Това е опасно за NIS2, DORA и GDPR, защото регулаторните срокове за оценка зависят от откриването, ескалацията и класификацията.
В Zenith Blueprint, фаза „Контроли в действие“, стъпка 16, Clarysec подчертава докладването на инциденти, водено от персонала, по контрол 6.8 на ISO/IEC 27002:2022. Насоката посочва, че реагирането при инциденти започва с хората. Организациите трябва да създадат ясен, прост и достъпен канал за докладване, като наблюдаван имейл адрес, вътрешен портал, гореща линия или категория в системата за билети. Препоръчват се също обучение за осведоменост, култура за докладване без обвинения, поверителност, нисък праг за докладване и периодични симулации.
Въздействието върху кръстосаното съответствие е пряко. Zenith Blueprint свързва тази способност за докладване от персонала с GDPR Article 33, NIS2 Article 23 и DORA Article 17. Ако служителите се колебаят да докладват подозрителна дейност, организацията може да загуби критично време, преди правните, сигурностните или регулаторните екипи да оценят задълженията за уведомяване.
Практическият тест на контрола е прост:
- Попитайте петима служители как да докладват подозрителен фишинг имейл.
- Проверете дали каналът за докладване се наблюдава.
- Потвърдете дали системата за билети има категория за инцидент по сигурността.
- Прегледайте последната симулация или настолно учение.
- Проверете дали извлечените поуки са разгледани в преглед от ръководството.
Ако някой отговор е неясен, актуализирайте инструкционния лист за инциденти, учебния материал, канала за докладване и препратката към доказателствата в SoA.
Как различните одитори проверяват една и съща основа
Доказателствата за кръстосано съответствие трябва да издържат на различни одитни гледни точки. Един и същ контрол може да бъде тестван различно според мандата на проверяващия.
| Одиторска гледна точка | Вероятен въпрос | Очаквани доказателства | Честа слабост |
|---|---|---|---|
| Одитор по ISO 27001:2022 | Защо този контрол е приложим и работи ли както е описан? | Обосновка в SoA, връзка с третиране на риска, политика, оперативни записи, резултати от вътрешен одит | Контролът съществува, но обосновката в SoA е неясна или остаряла |
| Оценител, ориентиран към NIS2 | Можете ли да докажете риск-базирани мерки за киберсигурност и координация на инциденти? | Регистър на риска, политика за управление, план за инциденти, работен поток за докладване, доказателства за риск от доставчици | Съпоставянето с NIS2 съществува в набор от слайдове, но не и в оперативните доказателства |
| Надзорен орган, ориентиран към DORA | Можете ли да докажете управление на ИКТ риска, класификация на инциденти, тестване и надзор върху трети страни? | Регистър на ИКТ риска, критичност на доставчиците, класификация на инциденти, тестове за устойчивост, договорни клаузи | Записите за доставчици не разграничават критичните ИКТ доставчици от обикновените доставчици |
| Преглеждащ, ориентиран към GDPR | Можете ли да докажете отчетност, сигурност на обработването, контроли върху обработващи лични данни и оценка на нарушения? | Съпоставяне със защитата на данните, клаузи за обработващи лични данни, записи от оценка на нарушения, доказателства за достъп и шифроване | Контролите за сигурност са внедрени, но не са свързани с рисковете за личните данни |
| Одитор, ориентиран към NIST | Можете ли да покажете управление, идентифициране на риск, защита, откриване, реагиране и възстановяване? | Управление на политики, записи за активи и риск, журнали за откриване, доказателства за инциденти и възстановяване | Техническите доказателства съществуват, но управленската собственост е слаба |
| Одитор по COBIT 2019 или в стил ISACA | Дефинирани ли са управленските цели, отговорностите, мониторингът на изпълнението и дейностите за увереност? | RACI, собственост на контролите, докладване към ръководството, план за одит, показатели, коригиращи действия | Контролите са технически, но не се управляват чрез измерима отчетност |
Тук Zenith Controls добавя стойност отвъд проста таблица за съпоставяне. Той помага да се преведат контролите по ISO/IEC 27002:2022 в релевантни за одита гледни точки, включително атрибути на контролите, регулаторни връзки и очаквания за доказателства. За контрол 5.1 атрибутите подкрепят управление, управление на политики, отчетност и цели за сигурност. За контрол 5.24 атрибутите подкрепят концепциите за реагиране и възстановяване, готовност за инциденти и коригиращо действие. За контрол 5.19 атрибутите на взаимоотношенията с доставчици свързват управление, риск в екосистемата, защита и надзор върху трети страни.
Какво трябва да вижда управителният съвет
Управителният съвет не се нуждае от всеки ред в SoA. Но се нуждае от историята, която SoA разказва.
Силен пакет за управителния съвет относно съгласуването с ISO 27001:2022, NIS2 и DORA трябва да включва:
- Обхват на СУИС и покрити бизнес услуги.
- Най-значими рискове за информационната сигурност и ИКТ.
- Обобщение на приложимите контроли по области.
- Статус на съпоставяне с NIS2, DORA и GDPR.
- Критични доставчици и рискове от концентрация.
- Показатели за докладване на инциденти и резултати от настолни учения.
- Отворени коригиращи действия и просрочени третирания на риска.
- Необходими решения относно приемане на риска, бюджет, собственост и ресурси.
Това превръща съответствието в доказателство за управление. То също се съгласува с целта на контрол 5.1 в Zenith Controls, където политиките за информационна сигурност подкрепят посоката на ниво висше ръководство, отчетността и целите за сигурност.
Чести грешки, които трябва да се избягват
Първата грешка е да се приема, че сертификацията по ISO 27001:2022 автоматично доказва съответствие с NIS2 или DORA. Не го прави. ISO 27001:2022 ви дава силна система за управление и контролна основа, но все още са необходими регулаторно определяне на обхвата, правен анализ, специфично за сектора тълкуване, работни потоци за уведомяване и познаване на очакванията на националните органи.
Втората грешка е SoA да се третира като статична. SoA трябва да се развива, когато се появяват нови доставчици, системи, инциденти, регулации, услуги или рискове. Zenith Blueprint, стъпка 24, препоръчва кръстосана проверка на SoA спрямо регистъра на риска и плана за третиране, като се гарантира, че всеки избран контрол има обосновка въз основа на съпоставен риск, правно изискване или бизнес необходимост.
Третата грешка е съпоставянето да остане твърде високо ниво. Слайд, който казва „ISO 27001 се съпоставя с DORA“, не е одитно доказателство. Конкретен запис в SoA, който свързва сигурността във взаимоотношенията с доставчици с критичен риск от ИКТ доставчик, договорна клауза, запис от преглед на доставчик и очакване за надзор върху трети страни по DORA, е много по-силен.
Четвъртата грешка е липсата на централизиране на доказателствата. Ако мениджърът по съответствие прекарва две седмици в събиране на екранни снимки преди всеки одит, организацията има проблем с извличането на доказателства.
Петата грешка е пренебрегването на контролите за персонала. Докладването на инциденти, въвеждането на доставчици, прегледите на правата за достъп, приемането на политики и ескалацията зависят от човешкото поведение. Изчистен процес, който никой не следва, ще се провали при извадково тестване от одитора.
Оперативният модел на Clarysec за кръстосано съответствие
Методът на Clarysec свързва историята на съответствието от стратегията до доказателствата:
- В Zenith Blueprint, фаза „Управление на риска“, стъпка 13, съпоставяте контролите с рисковете и изграждате SoA като мостов документ.
- В Zenith Blueprint, фаза „Управление на риска“, стъпка 14, правите кръстосани препратки между изискванията на GDPR, NIS2 и DORA и политиките и контролите.
- В Zenith Blueprint, фаза „Контроли в действие“, стъпка 16, въвеждате в действие докладването на инциденти, водено от персонала, така че ескалацията да започва рано.
- В Zenith Blueprint, фаза „Одит, преглед и подобрение“, стъпка 24, финализирате и тествате SoA, проверявате я кръстосано спрямо плана за третиране на риска и я подготвяте като един от първите документи, които одиторът ще поиска.
Този метод се подкрепя от политиките на Clarysec, които превръщат принципите в оперативни правила: управление на информационната сигурност, третиране на риска, сигурност на доставчиците, реагиране при инциденти, правно и регулаторно съпоставяне и съхранение на доказателства.
Резултатът не е само готовност по ISO 27001:2022. Това е многократно използваема система за доказателства за съответствие за NIS2, DORA, GDPR, искания от клиенти за потвърждение на контролите, вътрешен одит и надзор от страна на управителния съвет.
Следващи стъпки: изградете веднъж, доказвайте многократно
Ако вашата организация е изправена пред NIS2, DORA, GDPR, клиентски одити или натиск за сертификация по ISO 27001:2022, започнете с основата.
- Прегледайте своята SoA и добавете колони за регулаторен фактор за NIS2, DORA и GDPR.
- Проверете SoA спрямо регистъра на риска и плана за третиране на риска.
- Съпоставете критичните доставчици с контролите за сигурност на доставчици, договорните клаузи и доказателствата от мониторинг.
- Тествайте работния поток за докладване на инциденти с настолно учение.
- Централизирайте одитните доказателства по контрол, регулация, собственик и статус на тестване.
- Използвайте Zenith Controls, за да преведете контролите по ISO/IEC 27002:2022 в доказателства за кръстосано съответствие.
- Използвайте Zenith Blueprint, за да преминете от третиране на риска към одитно готова валидация на SoA.
- Внедрете набора от политики на Clarysec, включително Политика за информационна сигурност, Политика за управление на риска, Политика за сигурност на трети страни и доставчици и Политика за реагиране при инциденти, за да ускорите внедряването.
Най-бързият път не е повече несвързани контролни списъци. Той е една интегрирана СУИС, една проследима SoA, един централизиран модел за доказателства и един оперативен ритъм за кръстосано съответствие.
Clarysec може да ви помогне да превърнете ISO 27001:2022 от проект за сертификация в практическа контролна основа за NIS2 и DORA. Изтеглете Zenith Blueprint, разгледайте Zenith Controls или резервирайте оценка от Clarysec, за да изградите одитно готов модел на доказателства, преди следващият регулатор, клиент или комитет към управителния съвет да поиска доказателства.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


