ISO 27001 SoA за готовност по NIS2 и DORA

В 08:30 ч. в понеделник Елена, директор по информационна сигурност (CISO) на бързоразвиващ се B2B финтех SaaS доставчик, отваря спешно искане от управителния съвет. Компанията току-що е постигнала сертификация по ISO/IEC 27001:2022, но голям банков потенциален клиент от ЕС задава по-трудни въпроси от обичайния въпросник за сигурност.

Те не питат само дали компанията криптира данни, използва многофакторна автентикация (MFA) или разполага с доклад от тест за проникване. Искат да знаят дали SaaS платформата подпомага техните задължения по DORA, дали доставчикът може да попадне в обхвата на NIS2 като ИКТ услуга или зависимост от цифрова инфраструктура и дали Декларацията за приложимост по ISO 27001 може да обоснове всеки включен контрол, всеки изключен контрол и всяко доказателство.

Управителният съвет задава въпроса, който всеки CISO, мениджър по съответствието и основател на SaaS компания чува все по-често:

Може ли нашата ISO 27001 SoA да докаже готовност по NIS2 и DORA?

Елена знае, че грешният отговор би бил да се стартират три отделни програми за съответствие — една за ISO 27001, една за NIS2 и една за DORA. Това би създало дублирани доказателства, противоречиви отговорности за контроли и постоянна мобилизация преди всяка клиентска оценка. По-добрият отговор е съществуващата СУИС да се използва като оперативна система за съответствие, а Декларацията за приложимост, или SoA, да служи като основен документ за проследимост.

SoA не е просто електронна таблица за сертификация по ISO. В среда на киберсигурност и оперативна устойчивост в ЕС тя е мястото, където организацията доказва защо съществуват контролите, защо изключенията са защитими, кой отговаря за всеки контрол, какви доказателства подкрепят внедряването и как наборът от контроли адресира NIS2, DORA, GDPR, клиентски договори и вътрешно третиране на риска.

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

СУИС трябва да включва дефинирани граници на обхвата, методология за оценка на риска, измерими цели и документирани контроли, обосновани в Декларацията за приложимост (SoA).

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

Защо NIS2 и DORA промениха значението на „приложимо“

Традиционната SoA по ISO/IEC 27001:2022 често започва с прост въпрос: „Кои контроли от Приложение A се прилагат към нашия план за третиране на риска?“ Това все още е правилно, но вече не е достатъчно за SaaS, облачни услуги, управлявани услуги, финтех компании и доставчици от критичната верига на доставки.

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

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

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

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

Това променя разговора за SoA. Въпросът вече не е: „Съдържа ли Приложение A този контрол?“ По-добрият въпрос е:

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

ISO 27001 е универсалният преводач за NIS2 и DORA

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

Клаузи 4.1 до 4.4 изискват организацията да разбира своя контекст, да идентифицира заинтересованите страни, да определи релевантните изисквания и да дефинира обхвата на СУИС. За финтех SaaS доставчик като компанията на Елена тези изисквания на заинтересованите страни могат да включват клиенти от ЕС, финансови клиенти, засегнати от DORA, секторна експозиция по NIS2, задължения като администратор и обработващ лични данни по GDPR, външно възложени облачни зависимости, интерфейси с доставчици и очаквания на управителния съвет.

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

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

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

Декларацията за приложимост (SoA) трябва да отразява всички решения за третиране и да се актуализира при всяка промяна в покритието на контролите.

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

Започнете с регистъра на съответствието, а не със списъка с контроли

Слаба SoA започва с Приложение A и пита: „Кои контроли вече имаме?“ Силна SoA започва с оперативната реалност на организацията и пита: „Кои задължения, услуги, рискове, данни, доставчици и клиенти трябва да обхване СУИС?“

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

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

Управителят трябва да поддържа прост, структуриран Регистър на съответствието, който изброява:

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

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

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

Това е клауза 6.2.1 на Политика за правно и регулаторно съответствие. Тя е управленският гръбнак за използването на Декларацията за приложимост по ISO 27001 за готовност за съответствие с NIS2 и DORA.

Изградете критерии за риск, които отразяват устойчивост, поверителност, доставчици и регулации

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

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

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

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

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

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

Съпоставете домейните на NIS2 и DORA с контролите по ISO 27001:2022

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

За Елена това съпоставяне промени разговора с управителния съвет. Вместо да представя NIS2 и DORA като отделни проекти, тя можеше да покаже припокриването: управление, управление на риска, инциденти, непрекъсваемост, доставчици, тестване, контрол на достъпа и криптография.

Трите ISO контрола, от които зависи всяка SoA за NIS2 и DORA

В Zenith Controls: The Cross-Compliance Guide Zenith Controls Clarysec разглежда три контрола от ISO/IEC 27002:2022 като централни за готовото за одит управление на SoA за NIS2 и DORA. Това са ISO контроли, обогатени с атрибути за съответствие между режими в ръководството Zenith Controls.

Тези контроли не са изолирани. Те се свързват пряко с контролите за взаимоотношения с доставчици A.5.19 до A.5.23, контролите за управление на инциденти A.5.24 до A.5.28, контролите за непрекъсваемост A.5.29 и A.5.30, контрола за поверителност A.5.34, управлението на уязвимости A.8.8, управлението на конфигурацията A.8.9, резервните копия на информация A.8.13, журналирането A.8.15, дейностите по мониторинг A.8.16, криптографията A.8.24, контролите за сигурна разработка A.8.25 до A.8.29 и управлението на промените A.8.32.

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

Използвайте Zenith Blueprint, за да изградите, тествате и защитите SoA

В Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint Clarysec поставя изграждането на SoA във фазата „Управление на риска“, Стъпка 13: Планиране на третиране на риска и Декларация за приложимост. Blueprint указва на организациите да използват листа за SoA в шаблона „Risk Register and SoA Builder.xlsx“, да решат дали всеки от 93-те контрола от Приложение A е приложим и да основат решението на третирането на риска, правните и договорните изисквания, релевантността спрямо обхвата и организационния контекст.

Blueprint посочва:

SoA на практика е свързващ документ: тя свързва вашата оценка/третиране на риска с действителните контроли, които имате.

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

Zenith Blueprint също указва на екипите да правят кръстосани препратки към регулации в бележките към SoA, когато е уместно. Ако контрол е внедрен за GDPR, NIS2 или DORA, това трябва да се вижда в регистъра на риска или в бележките към SoA. По-късно, в Стъпка 24, Blueprint указва на организациите да актуализират SoA след внедряване и да я проверят кръстосано спрямо плана за третиране на риска. В Стъпка 30, Подготовка за сертификация, окончателен преглед и пробен одит, Blueprint насочва екипите да потвърдят, че всеки приложим контрол от Приложение A има доказателства като политика, процедура, доклад, план или запис за внедряване.

Тази последователност превръща SoA в жив инструмент за съответствие:

1. Стъпка 13 я изгражда въз основа на третиране на риска и задължения.
2. Стъпка 24 я тества спрямо реалността на внедряването.
3. Стъпка 30 я защитава чрез окончателен преглед на доказателствата и пробен одит.

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

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

Полезна формула е:

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

За финтех SaaS доставчик един ред в SoA може да изглежда така:

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

Как да обосновавате изключения без създаване на одитна експозиция

Изключенията не са провали. Лошо обоснованите изключения са провали.

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

Базовият набор може да бъде адаптиран; изключенията обаче трябва да бъдат документирани с формално одобрение и обосновка в SoA.

Това е клауза 7.2.2 на Политика за информационна сигурност.

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

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

Това изискване произтича от клауза 7.2.1 на Политика за информационна сигурност за МСП.

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

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

Приемане: Обосновете защо не се изисква допълнително действие и запишете остатъчния риск.

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

Докладване на инциденти: доказвайте работен поток, а не наличие на политика

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

SaaS доставчик може невинаги да докладва директно на орган по DORA, но може да трябва да подпомага сроковете за докладване на финансовите си клиенти. Това прави контролите за инциденти изключително релевантни в SoA.

Слаба SoA казва: „Съществува Политика за реагиране при инциденти.“

Силна SoA казва: „Приложимо, защото организацията трябва да открива, оценява, класифицира, ескалира, комуникира, запазва доказателства, да подпомага регулаторните срокове за докладване, да уведомява засегнатите клиенти, когато това се изисква договорно, и да извлича поуки от инциденти, засягащи услуги, данни или регулирани клиенти.“

Доказателствата трябва да включват:

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

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

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

Тази цел произтича от клауза 3.4 на Политика за одит и мониторинг на съответствието.

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

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

Това е клауза 6.2.4 на Политика за одит и мониторинг на съответствието за МСП.

Една SoA, множество одитни разговори

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

Одитор по ISO 27001 обикновено започва с логиката на клаузите: обхват, заинтересовани страни, оценка на риска, третиране на риска, SoA, цели, вътрешен одит, преглед от ръководството и подобрение. Преглеждащ, ориентиран към NIS2, се фокусира върху пропорционалност, управленска отчетност, обучение, верига на доставки, срокове за инциденти и въздействие върху услугите. Клиентски оценител, ориентиран към DORA, се фокусира върху ИКТ риск, критични или важни функции, съществени ИКТ инциденти, тестване на устойчивостта, договорни клаузи, права на одит, планове за изход, подизпълнение и риск от концентрация. Преглеждащ по поверителност се фокусира върху отчетност по GDPR и готовност за нарушения. Одитор в стил COBIT 2019 или ISACA тества управление, показатели, отговорност, уверение и коригиращо действие.

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

Чести слабости в SoA при проекти за готовност по NIS2 и DORA

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

1. SoA отбелязва контролите като приложими, но не е записан риск, задължение или бизнес причина.
2. NIS2 и DORA се споменават в политики, но не са съпоставени с контроли, отговорници или доказателства.
3. Контролите за доставчици са отбелязани като внедрени, но няма регистър на доставчиците, оценка на критичността, договорен преглед или план за изход.
4. Контроли за инциденти съществуват, но процесът не поддържа 24-часови, 72-часови, клиентски или окончателни работни потоци за докладване.
5. Одобрението от ръководството се подразбира, но няма запис за приемане на риска, одобрение на SoA или решение за остатъчен риск.
6. Изключенията са копирани от шаблон и не съответстват на действителния облачен, дистанционен, SaaS или финтех оперативен модел.
7. Доказателства съществуват в различни инструменти, но няма одитна следа, която да ги свързва със SoA.
8. Обработването на лични данни по GDPR не е свързано с контроли за сигурност, реагиране при нарушение, договори с доставчици или съхранение.
9. Вътрешният одит проверява документи, но не тества дали SoA отразява реалното внедряване.
10. SoA се актуализира само преди сертификация, а не след нови клиенти, доставчици, инциденти, одитни констатации или регулаторни промени.

Това не са проблеми с документацията. Това са проблеми в управлението.

Практически контролен списък за ISO 27001 SoA, готова за одит

Използвайте този контролен списък преди сертификационен одит по ISO 27001, преглед за готовност по NIS2, клиентска оценка по DORA, заседание на управителния съвет или процес на инвеститорска надлежна проверка.

Превърнете SoA в защитим мост за съответствие

Презентацията на Елена пред управителния съвет беше успешна, защото тя не представи три несвързани проекта за съответствие. Тя представи един контролиран, основан на доказателства оперативен модел, изграден върху ISO/IEC 27001:2022, със SoA като мост между регулации, риск, внедряване на контроли, доказателства и управленски надзор.

NIS2 и DORA не правят ISO 27001 остарял. Те правят добре изградената Декларация за приложимост по ISO 27001 по-ценна. SoA може да се превърне в единното място, където вашата организация обяснява защо съществуват контролите, защо изключенията са защитими, как се съхраняват доказателствата, как се управляват доставчиците, как се ескалират инцидентите и как ръководството знае, че СУИС работи.

Незабавното действие е просто:

1. Отворете текущата си SoA.
2. Изберете пет контрола, отбелязани като приложими, и попитайте: „Какъв риск, задължение или договор обосновава това?“
3. Изберете пет изключения и попитайте: „Би ли имало това все още смисъл за одитор по NIS2, DORA, GDPR или ISO/IEC 27001:2022?“
4. Проверете дали всеки приложим контрол има актуални доказателства.
5. Потвърдете, че ръководството е одобрило остатъчните рискове и решенията в SoA.
6. Актуализирайте регистъра на съответствието, регистъра на риска и SoA при всяка промяна в услуги, доставчици, клиенти, регулации или инциденти.

Clarysec помага на организациите да направят това чрез Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, корпоративни комплекти от политики и комплекти от политики за МСП, инструменти за регистър на риска, шаблони за SoA, подготовка за одит и съпоставяне на съответствието между режими за NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 и уверение за клиенти.

Ако вашата SoA не може да отговори защо контролът съществува, кой е неговият отговорник, какви доказателства го потвърждават и кое задължение подкрепя, тя все още не е готова. Използвайте Clarysec, за да я превърнете в готов за одит мост за съответствие, преди регулатор, одитор или клиент да зададе първи същите въпроси.