Вътрешен одит по ISO 27001 за NIS2 и DORA
Това е първото заседание на одитния комитет за 2026 г. Сара, CISO на FinSecure — бързо растящ доставчик на SaaS и финтех услуги — има петнадесет минути в дневния ред. Съветът има пет въпроса.
Готови ли сме за надзорния одит по ISO/IEC 27001:2022? Попадаме ли в обхвата на NIS2 като доставчик на управлявани услуги? Засяга ли ни DORA, защото поддържаме клиенти от финансовия сектор? Можем ли да докажем, че докладването на инциденти, надлежната проверка на доставчиците и непрекъсваемостта на дейността функционират? И защо прегледът на достъпа от миналото тримесечие все още откри акаунти, които е трябвало да бъдат премахнати?
Сара разполага с доказателства, но те са разпръснати. Инженерният екип има експорти от сканирания за уязвимости. Отделът по закупуване разполага с въпросници за доставчици. Правният отдел има договорни клаузи. Мениджърът по съответствие поддържа GDPR регистър за проследяване. SOC има тикети за инциденти. Нищо от това не е очевидно грешно, но нито едно не разказва последователна история на увереност.
Това е моментът, в който програмата за вътрешен одит по ISO 27001 или се превръща в стратегически механизъм за генериране на доказателства, или остава ежегодна кризисна подготовка.
За организации, засегнати от NIS2 и DORA, вътрешният одит вече не може да бъде формален контролен списък. Той трябва да се превърне в риск-базирана система за увереност, която потвърждава дали обхватът на ISMS е правилен, дали контролите работят на практика, дали регулаторните изисквания са картографирани, дали констатациите се класифицират последователно и дали коригиращите действия достигат до преглед от ръководството. През 2026 г. най-силните програми няма да питат само: „Проведохме ли одит?“ Те ще питат: „Можем ли месец по месец да докажем, че управлението на киберсигурността, ИКТ устойчивостта, сигурността на доставчиците и готовността за инциденти функционират?“
Това е подходът, който Clarysec вгражда в Zenith Blueprint: 30-стъпкова пътна карта за одитора, Zenith Controls: ръководство за съответствие между рамки и пакета политики на Clarysec. Целта не е да се създават отделни проекти за ISO, NIS2 и DORA. Целта е ISMS да бъде обогатена така, че една програма за одит да създава повторно използваеми доказателства за множество изисквания за увереност.
Защо програмите за вътрешен одит през 2026 г. трябва да се променят
NIS2 и DORA преместиха одитния разговор от документация към управлявана устойчивост.
NIS2 се прилага за много средни и големи организации в критични и важни сектори, включително цифрова инфраструктура, доставчици на облачни изчисления, доставчици на центрове за данни, доставчици на управлявани услуги, доставчици на управлявани услуги за сигурност, онлайн пазари, онлайн търсачки и платформи за социални мрежи. Държавите членки започнаха да прилагат национални мерки от октомври 2024 г., а през 2026 г. много организации вече работят в първата пълна година на зрели очаквания по NIS2.
DORA се прилага от 17 януари 2025 г. за широк кръг финансови субекти, включително кредитни институции, платежни институции, институции за електронни пари, инвестиционни посредници, доставчици на услуги за криптоактиви, застрахователни и презастрахователни предприятия, доставчици на услуги за колективно финансиране и съответните доставчици на ИКТ услуги от трети страни. DORA е секторният режим за цифрова оперативна устойчивост за обхванатите финансови субекти. ИКТ доставчиците, които обслужват финансови субекти, също могат да бъдат засегнати от DORA чрез договори, права на одит, участие в тестване, съдействие при инциденти, контроли върху подизпълнители и изисквания за изход.
И двете регулации повишават отчетността. Член 20 на NIS2 изисква органите на управление да одобряват и надзирават мерките за управление на риска за киберсигурността и да получават обучение по киберсигурност. Член 5 на DORA възлага крайната отговорност за ИКТ риска на органа на управление, включително одобрението и надзора върху стратегията за цифрова оперативна устойчивост, ИКТ политиките, механизмите за непрекъсваемост и риска от трети страни.
ISO 27001 е особено подходящ за тази среда, защото представлява система за управление. Той изисква организацията да разбира своя контекст, да определя заинтересованите страни и изискванията, да задава обхвата на ISMS, да оценява и третира рисковете, да наблюдава резултатността, да провежда вътрешни одити и да насърчава непрекъснато подобрение. Смисълът не е NIS2 и DORA да бъдат насилствено поставени в ISO форма. Смисълът е ISO 27001 да се използва като операционна система за повторяема увереност.
Започнете с обхвата: одитирайте системата, на която разчита съветът
Слаба програма за вътрешен одит започва с неясен обхват като „информационна сигурност“. Силната програма започва с бизнес и регулаторната граница.
ISO 27001 изисква обхватът на ISMS да отчита вътрешни и външни въпроси, изисквания на заинтересованите страни и интерфейси или зависимости с други организации. Това е важно, защото задълженията по NIS2 и DORA често се намират по краищата на организацията: облачни платформи, външно възложени SOC доставчици, управлявано откриване и реагиране, платежни системи, финтех приложно-програмни интерфейси (API), обработване на клиентски данни, услуги за резервни копия и партньори за ескалация при инциденти.
Политиката за одит и мониторинг на съответствието за МСП на Clarysec задава управленската базова линия:
Генералният мениджър (GM) трябва да одобри годишен план за одит.
От раздел „Изисквания за управление“, клауза на политиката 5.1.1.
За по-големи среди Политиката за одит и мониторинг на съответствието на Clarysec повишава очакването:
Риск-базиран план за одит трябва да се разработва и одобрява ежегодно, като се вземат предвид:
От раздел „Изисквания за управление“, клауза на политиката 5.2.
Следователно обхватът не е просто предпочитание на одитора. Той е одобрен от ръководството ангажимент за увереност.
Програма за вътрешен одит по ISO 27001 за 2026 г., която подпомага NIS2 и DORA, трябва да включва:
- Клаузи и процеси на ISMS, включително контекст, лидерство, управление на риска, цели, поддръжка, операции, оценка на резултатността и подобрение.
- Релевантни области на контроли от Приложение A на ISO/IEC 27001:2022, включително взаимоотношения с доставчици, управление на инциденти, непрекъсваемост на дейността, правни задължения, поверителност, регистриране, мониторинг, управление на уязвимостите, контрол на достъпа, криптография, сигурна разработка, управление на промените и управление на облачни услуги.
- Регулаторни наслагвания, включително членове 20, 21 и 23 на NIS2, членове 5, 6, 8–14, 17–19, 24–27 и 28–30 на DORA, както и изискванията за сигурност и отчетност по GDPR.
- Ключови услуги и бизнес процеси, особено критични или важни функции, съществени услуги, клиентски платформи и системи, които поддържат регулирани клиенти.
- Зависимости от трети страни, включително ИКТ доставчици, доставчици на облачни услуги, външна разработка, SOC, MSSP, обработващи лични данни и критични подизпълнители.
- Процеси, които създават доказателства, включително оценки на риска, прегледи на правата за достъп, отстраняване на уязвимости, упражнения за инциденти, тестове за възстановяване от резервни копия, прегледи на доставчици, тестове за непрекъсваемост и прегледи от ръководството.
Zenith Blueprint подсилва това във фазата „Одит, преглед и подобрение“, Стъпка 25, Програма за вътрешен одит:
Определете обхвата на вашата програма за вътрешен одит. В крайна сметка, в рамките на една година трябва да обхванете всички релевантни процеси и контроли на ISMS.
От фазата „Одит, преглед и подобрение“, Стъпка 25: Програма за вътрешен одит.
Не е необходимо да одитирате всичко всеки месец. Но в рамките на годишния цикъл следва да обхванете всички релевантни процеси и контроли на ISMS, с по-честа работа по високорискови и регулирани области.
Изградете одитната вселена около темите на контролите по NIS2 и DORA
Член 21 на NIS2 изисква подходящи и пропорционални технически, оперативни и организационни мерки. Базовият набор включва анализ на риска, политики за сигурност, обработване на инциденти, непрекъсваемост на дейността, управление на резервни копия, аварийно възстановяване, управление при кризи, сигурност на веригата на доставки, сигурно придобиване и разработка, обработване на уязвимости, оценка на ефективността, киберхигиена, обучение, криптография, сигурност на човешките ресурси, контрол на достъпа, управление на активите, MFA или непрекъсната автентикация, когато е подходящо, и сигурни комуникации.
DORA има сходен оперативен жизнен цикъл. Тя изисква финансовите субекти да идентифицират и класифицират бизнес функции, поддържани от ИКТ, информационни активи, ИКТ активи, зависимости и взаимовръзки с трети страни. Тя също така изисква защита, откриване, класификация на инцидентите, реагиране, възстановяване, резервни копия, възстановяване от резервни копия, тестване, извличане на поуки след инцидент, комуникация и управление на риска от ИКТ трети страни.
Единната одитна вселена предотвратява често срещаната грешка ISO 27001 да се одитира отделно от NIS2 и DORA.
| Одитна област | Одитна опора по ISO 27001 | Релевантност за NIS2 и DORA | Типични доказателства |
|---|---|---|---|
| Управление и правни задължения | Контекст, лидерство, третиране на риска, правни и договорни изисквания | Надзор от съвета по NIS2, отговорност на органа на управление по DORA, отчетност по GDPR | Правен регистър, регистър на заинтересованите страни, обхват на ISMS, апетит за риск, протоколи от съвета, преглед от ръководството |
| Оценка и третиране на риска | Оценка на риска, Декларация за приложимост, план за третиране | Подходящи и пропорционални мерки по NIS2, рамка за управление на ИКТ риска по DORA | Регистър на риска, критерии за риск, одобрения на третирането, приемане на остатъчния риск |
| Инвентар на активи и зависимости | Управление на активите, управление на облачни услуги, услуги от доставчици | ИКТ активи и взаимовръзки по DORA, системи за предоставяне на услуги по NIS2 | CMDB, карти на потоците от данни, регистър на доставчиците, облачен инвентар, класификация по критичност |
| Контрол на достъпа и идентичност | Сигурност на човешките ресурси, управление на достъпа, MFA, привилегирован достъп | Контрол на достъпа и MFA по NIS2, минимално необходим достъп и силна автентикация по DORA | Тикети за постъпващи, преместващи се и напускащи служители, прегледи на правата за достъп, отчети за MFA, журнали на привилегировани акаунти |
| Регистриране, мониторинг и откриване | Регистриране, мониторинг, оценка на събития | Откриване на аномалии и класификация на инцидентите по DORA, готовност за инциденти по NIS2 | SIEM аларми, правила за откриване, записи от триаж на инциденти, табла за мониторинг |
| Управление на инциденти | Планиране за инциденти, реагиране, събиране на доказателства, извлечени поуки | Работен поток за докладване по NIS2, жизнен цикъл на ИКТ инциденти по DORA | Журнал на инциденти, матрица на тежестта, шаблони за уведомяване, доклади за първопричина, записи от упражнения |
| Непрекъсваемост на дейността и възстановяване | ИКТ готовност, резервни копия, сигурност при прекъсвания | Резервни копия и управление при кризи по NIS2, непрекъсваемост и възстановяване по DORA | BIA, планове за непрекъсваемост, тестове на резервни копия, записи за RTO и RPO, тест на кризисна комуникация |
| Риск от доставчици и ИКТ трети страни | Споразумения с доставчици, ИКТ верига на доставки, придобиване на облачни услуги и изход | Сигурност на веригата на доставки по NIS2, регистър на ИКТ трети страни и договорни клаузи по DORA | Надлежна проверка на доставчици, договори, права на одит, планове за изход, анализ на риска от концентрация |
| Сигурна разработка и уязвимости | Сигурно придобиване, разработка, промени, управление на уязвимостите | Обработване на уязвимости по NIS2, прилагане на корекции и тестване по DORA | Сканирания за уязвимости, SLA за отстраняване, тикети за промени, преглед на изходния код, доклади от тестове за проникване |
| Мониторинг на съответствието и коригиращи действия | Мониторинг, вътрешен одит, несъответствие и коригиращо действие | Коригиращи мерки по NIS2, одит и последващо проследяване на отстраняването по DORA | Одитни доклади, CAPA регистър за проследяване, KPI табло, действия от прегледа от ръководството |
Тази структура превръща всяка одитна област в общ обект за увереност. Вътрешният одитор тества изискването по ISO 27001, след което записва дали същите доказателства подпомагат и очакванията по NIS2, DORA, GDPR, NIST CSF и COBIT 2019.
Планирайте годината около риска, а не около документацията
Zenith Blueprint дава на екипите практическа последователност за превръщане на одита в подобрение:
- Стъпка 25, Програма за вътрешен одит: планирайте обхвата, честотата, независимостта и риск-базираните приоритети.
- Стъпка 26, Изпълнение на одита: събирайте обективни доказателства чрез интервюта, преглед на документи, наблюдение и извадково тестване.
- Стъпка 27, Одитни констатации, анализ и първопричина: класифицирайте констатациите и идентифицирайте първопричината.
- Стъпка 28, Преглед от ръководството: подавайте резултати от одити, инциденти, несъответствия, цели, рискове и нужди от ресурси към прегледа от ръководството.
- Стъпка 29, Непрекъснато подобрение: изграждайте коригиращи действия, които премахват причините, а не само симптомите.
Zenith Blueprint е категоричен относно независимостта:
В идеалния случай вътрешният одитор не следва да одитира собствената си работа.
От фазата „Одит, преглед и подобрение“, Стъпка 25: Програма за вътрешен одит.
За по-малка SaaS или финтех компания това може да означава мениджър от друга функция да одитира процеси по сигурността, ротация на собственици на контроли или използване на външен консултант. Ключово е компетентността и независимостта да бъдат документирани, особено когато доказателства по NIS2 и DORA може по-късно да бъдат преглеждани от клиенти, регулатори, надзорни органи или външни одитори.
Политиката за одит и мониторинг на съответствието за МСП също определя минималната одитна структура:
Всеки одит трябва да включва определен обхват, цели, отговорен персонал и изисквани доказателства.
От раздел „Изисквания за управление“, клауза на политиката 5.2.3.
Практическа тримесечна структура за бързо растящ SaaS или ИКТ доставчик може да бъде:
| Тримесечие | Основен одитен фокус | Регулаторен акцент | Основни резултати |
|---|---|---|---|
| Q1 | Управление и докладване на инциденти | Член 23 на NIS2, членове 17–19 на DORA | Одитен доклад за инциденти, тест на работния поток за уведомяване, преглед на матрицата на тежестта |
| Q2 | Управление на риска от ИКТ трети страни | Член 21 на NIS2, членове 28–30 на DORA | Извадка от доставчици, преглед на договори, доказателства за надлежна проверка, преглед на планирането за изход |
| Q3 | Тестване на непрекъсваемостта на дейността и устойчивостта | Член 21 на NIS2, членове 11, 12 и 24–27 на DORA | Доказателства за възстановяване от резервни копия, упражнение за непрекъсваемост, отстраняване след тест за устойчивост |
| Q4 | Управление, риск и съответствие | Член 20 на NIS2, членове 5 и 6 на DORA, клаузи 5, 9 и 10 на ISO 27001 | Пакет за преглед от ръководството, CAPA статус, решения за остатъчен риск, план за одит за следващата година |
Това не заменя месечното събиране на доказателства. То задава ясен ритъм на увереност за годината.
Извадково тестване: колко доказателства са достатъчни?
Извадковото тестване е мястото, където много вътрешни одити стават или твърде повърхностни, или твърде скъпи. В регулирани ИКТ среди извадковото тестване трябва да бъде риск-базирано, обяснимо и документирано.
Zenith Blueprint, Стъпка 26, дава практичния принцип:
Използвайте извадки и проверки по извадка: не можете да проверите всичко, затова използвайте извадково тестване.
От фазата „Одит, преглед и подобрение“, Стъпка 26: Изпълнение на одита.
Корпоративната политика на Clarysec прави това одитируемо:
Документиране на стратегията за извадково тестване, обхвата на одита и ограниченията
От раздел „Изисквания за управление“, клауза на политиката 5.5.3.
За NIS2 и DORA извадковото тестване следва да отчита критичност, риск, значимост на доставчика, времеви период, история на инциденти, география и дали тестваният по извадка процес поддържа критични или важни функции.
| Област на контрол | Популация | Препоръчителна извадка | Риск-базирана корекция |
|---|---|---|---|
| Предоставяне на достъп | Всички нови потребителски акаунти през тримесечието | 10 акаунта или 10 процента, което е по-голямо | Включете всички привилегировани акаунти и администратори на критични приложения |
| Премахване на достъп при напускане | Всички прекратени потребители през тримесечието | 100 процента за привилегировани потребители, 10 стандартни потребители | Увеличете извадката, ако интеграцията с ЧР или IAM е променена |
| Надлежна проверка на доставчици | Активни ИКТ доставчици | Всички критични доставчици, 5 доставчици със среден риск, 3 доставчици с нисък риск | Включете доставчици, които поддържат финансови клиенти или съществени услуги |
| Отстраняване на уязвимости | Критични и високи констатации, затворени през тримесечието | 15 тикета в различни системи | Включете системи, достъпни от интернет, и повтарящи се изключения |
| Управление на инциденти | Всички инциденти по сигурността през тримесечието | Всички съществени инциденти, 5 незначителни инцидента, 3 примера за триаж на фалшиво положителен резултат | Включете инциденти с лични данни, клиентско въздействие или трансгранична релевантност |
| Възстановяване от резервни копия | Тестове на резервни копия, извършени през тримесечието | Всички тестове на критични системи, 3 некритични системи | Включете системи, които поддържат критични или важни функции |
| Управление на промените | Промени в продукционна среда през тримесечието | 15 промени, включително аварийни промени | Включете промени, засягащи автентикация, регистриране, шифроване или клиентски данни |
| Обучение по сигурност | Служители и външни изпълнители, активни през периода | 20 потребители от различни отдели | Включете членове на органа на управление и привилегировани технически роли |
За среди, засегнати от DORA, доказателствата от тестване изискват специално внимание. DORA изисква тестване на цифровата оперативна устойчивост за финансови субекти, с по-разширено тестване като тестове за проникване, базирани на разузнавателна информация за заплахи, за определени субекти поне веднъж на три години. Вашата одитна извадка трябва да включва не само доклади от тестове, но и доказателства, че констатациите са приоритизирани, отстранени и повторно тествани.
Практически пример за одит: риск от ИКТ трети страни
Сигурността на доставчиците често е най-бързият начин да се разкрият пропуските между документацията и оперативната реалност. Членове 28–30 на DORA изискват управление на риска от ИКТ трети страни, договорно съдържание и регистри на информацията. Член 21 на NIS2 изисква сигурност на веригата на доставки, която отчита уязвимостите и практиките на преките доставчици.
За одит през Q2 Сара избира извадка от пет критични доставчици, трима нови доставчици, въведени през последните шест месеца, и двама доставчици с наскоро подновени договори. Одиторът интервюира отдела по закупуване, правния отдел, собственици на услуги и собственици на контроли по сигурността.
| Изискване по DORA или NIS2 | Опора на контрол по ISO 27001:2022 | Одитен въпрос | Доказателства за събиране |
|---|---|---|---|
| Член 28 на DORA, регистър на ИКТ трети страни | A.5.19 Информационна сигурност във взаимоотношенията с доставчици | Има ли пълен и актуален регистър на договореностите с доставчици на ИКТ услуги от трети страни? | Актуален регистър на доставчиците и записи от извадката за критични доставчици |
| Член 28 на DORA, оценка на риска преди сключване на договор | A.5.19 Информационна сигурност във взаимоотношенията с доставчици | Извършена ли е надлежна проверка преди подписване или подновяване на договори с доставчици? | Доклади от надлежна проверка, оценки на риска и записи за одобрение |
| Член 30 на DORA, договорно съдържание | A.5.20 Разглеждане на информационната сигурност в споразуменията с доставчици | Включват ли договорите мерки за сигурност, права на одит, съдействие при инциденти и подкрепа при прекратяване, когато се изисква? | Договори, анекси, приложения за сигурност и бележки от правен преглед |
| Член 21 на NIS2, сигурност на веригата на доставки | A.5.21 Управление на информационната сигурност във веригата на доставки на ИКТ | Разбрани ли са практиките за сигурност на доставчиците, подизпълнителите и зависимостите на услугите? | Въпросници за доставчици, разкрития за подизпълнители и карти на зависимостите |
| Текущ мониторинг на доставчици | A.5.22 Мониторинг, преглед и управление на промените в услугите от доставчици | Преглеждат ли се във времето резултатността и сигурността на доставчиците? | Протоколи от QBR, SLA отчети, одитни доклади и записи от годишни прегледи |
Тази таблица прави повече от това да насочва събирането на доказателства. Тя доказва, че организацията е превела регулаторния текст в одитни критерии, съгласувани с ISO, и в конкретни доказателства.
Констатации: формулирайте ги така, че ръководството да може да действа
Одитната констатация не трябва да звучи като неясно оплакване. Тя трябва да бъде достатъчно структурирана, за да може ръководството да разбере риска, да възложи собственост и да одобри коригиращо действие.
Политиката за одит и мониторинг на съответствието за МСП посочва:
Всички одитни констатации трябва да бъдат документирани с оценки на риска и предложени действия.
От раздел „Изисквания за управление“, клауза на политиката 5.4.1.
Корпоративната Политика за одит и мониторинг на съответствието добавя дисциплина за коригиращите действия:
Всички констатации трябва да водят до документирана CAPA, която включва:
От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.2.1.
В Zenith Blueprint, Стъпка 27 препоръчва констатациите да се категоризират като съществени несъответствия, незначителни несъответствия или наблюдения, след което да се извърши анализ на първопричините. Същественото несъответствие показва сериозен пропуск или системен отказ. Незначителното несъответствие е изолиран пропуск в иначе съответстващ процес. Наблюдението е възможност за подобрение.
Силната констатация включва:
- Изискване или очакване към контрола.
- Наблюдавано състояние.
- Тествани по извадка доказателства.
- Риск и бизнес въздействие.
- Регулаторна релевантност.
- Класификация и оценка на риска.
- Първопричина.
- Собственик на коригиращото действие и краен срок.
Примерна констатация:
Констатация NC-2026-07, незначително несъответствие, забавяне на прегледа на сигурността на доставчик
Изискване: Прегледите на сигурността на доставчици за критични ИКТ доставчици трябва да се извършват поне ежегодно, като подпомагат контролите за доставчици по ISO 27001, очакванията за веригата на доставки по NIS2 и задълженията по DORA за риск от ИКТ трети страни.
Състояние: Двама от дванадесет критични ИКТ доставчици нямаха завършени прегледи на сигурността за 2026 г. към изискваната дата.
Доказателства: Експорт от регистъра на доставчиците с дата 15 юни 2026 г., регистър за проследяване на прегледите на доставчици, интервю с ръководителя на отдела по закупуване и два липсващи записа от преглед.
Риск: Забавеният преглед на доставчик може да попречи на своевременното идентифициране на уязвимости, промени при подизпълнители, пропуски в съдействието при инциденти или договорно несъответствие, засягащи критични услуги.
Първопричина: Отделът по закупуване не е бил автоматично уведомяван при наближаване на датите за преглед на доставчици, а собствеността върху доказателствата за доставчици, свързани с DORA, не е била възложена.
Коригиращо действие: Конфигурирайте автоматизирани напомняния за преглед, назначете именувани собственици на контроли за всички критични ИКТ доставчици, завършете просрочените прегледи до 31 юли 2026 г. и извършвайте тримесечни проверки по извадка.
За анализ на първопричините техниката „5 защо“ е полезна. Ако оценка преди сключване на договор е пропусната, истинската причина може да не е индивидуална грешка. Възможно е работният поток за закупуване да е позволявал ИКТ договори с ниска стойност да заобикалят прегледа по сигурността, въпреки че очакванията по DORA и NIS2 се прилагат според риска и зависимостта, а не само според разхода.
Календарът на доказателствата за 2026 г.
Календарът на доказателствата за 2026 г. превръща вътрешния одит в оперативен ритъм. Той разпределя генерирането на доказателства през годината и избягва годишната паника в края на периода.
Политиката за информационна сигурност на Clarysec очаква управленски преглед на:
Преглед на ключови показатели за изпълнение (KPI) в областта на сигурността, инциденти, одитни констатации и статус на риска
От раздел „Изисквания за управление“, клауза на политиката 5.3.2.
Доказателствата не се събират само за одиторите. Те захранват решения относно риск, бюджет, ресурси, доставчици, инструменти, обучение и коригиращи действия.
| Месец | Одитен фокус и фокус върху доказателства | Ключови доказателствени резултати |
|---|---|---|
| Януари | Потвърждаване на регулаторния обхват, обхвата на ISMS и плана за одит за 2026 г. | Одобрен план за одит, преглед на обхвата на ISMS, оценка на приложимостта на NIS2 и DORA, актуализация на правния регистър |
| Февруари | Управление, апетит за риск и обучение на органа на управление | Протоколи от съвета, записи за обучение, критерии за риск, актуализиран регистър на риска |
| Март | Инвентар на активи, данни и зависимости | CMDB експорт, карти на потоците от данни, списък на критични услуги, карта на взаимовръзките с ИКТ доставчици |
| Април | Одит на контрола на достъпа и MFA | Записи от прегледи на правата за достъп, извадка от привилегирован достъп, отчет за покритие на MFA, тестване при напускане |
| Май | Уязвимости, прилагане на корекции и сигурно управление на промените | Показатели за уязвимости, доказателства за отстраняване, извадка от тикети за промени, одобрения на изключения |
| Юни | Управление на доставчици и облачни услуги | Извадка за надлежна проверка на доставчици, преглед на договорни клаузи, права на одит, планове за изход, бележки за риск от концентрация |
| Юли | Упражнение за управление и докладване на инциденти | Симулация на инцидент, класификация на тежестта, тест на работния поток за докладване по NIS2, тест за ескалация на инцидент по DORA |
| Август | Регистриране, мониторинг и откриване | SIEM случаи на употреба, настройка на аларми, покритие на мониторинга, извадка от ескалации |
| Септември | Резервни копия, възстановяване и непрекъсваемост на дейността | Записи от тестове на резервни копия, доказателства за RTO и RPO, упражнение за непрекъсваемост, тест на кризисна комуникация |
| Октомври | Сигурна разработка и сигурност на приложенията | Доказателства за SDLC, извадка от прегледи на изходния код, резултати от тестове за сигурност, преглед на външна разработка |
| Ноември | Пълен вътрешен одит на ISMS и преглед на съответствието между рамки | Доклад от вътрешен одит, регистър на констатациите, картографиране към NIS2 и DORA, доказателства за отчетност по GDPR |
| Декември | Преглед от ръководството и приключване на коригиращи действия | Протоколи от преглед от ръководството, CAPA статус, приемане на остатъчния риск, входни данни за плана за одит за 2027 г. |
Този календар дава на одитния комитет ориентиран към бъдещето план за увереност и дава на собствениците на контроли време да създават доказателства чрез нормални операции.
Гръбнакът на ISO 27002:2022: 5.31, 5.35 и 5.36
Zenith Controls е ръководството на Clarysec за съответствие между рамки. То картографира областите на контроли по ISO/IEC 27001:2022 и ISO/IEC 27002:2022 към други стандарти, регулации, одитни очаквания и модели на доказателства. То е особено полезно за свързване на вътрешен преглед, правни задължения и съответствие с политиките.
Три области на контроли от ISO/IEC 27002:2022 формират гръбнака на единна програма за вътрешен одит:
| Област от ISO 27002:2022, подчертана в Zenith Controls | Одитен въпрос | Стойност за NIS2 и DORA |
|---|---|---|
| 5.31 Правни, законови, регулаторни и договорни изисквания | Знаем ли кои задължения се прилагат и картографирали ли сме ги към контроли и доказателства? | Подпомага приложимостта на NIS2, ИКТ задълженията по DORA, клиентските договори и отчетността по GDPR |
| 5.35 Независим преглед на информационната сигурност | Обективни, планирани и компетентни ли са прегледите и водят ли до действия? | Подпомага увереността относно мерките за киберсигурност, тестването на ИКТ устойчивостта и управленския надзор |
| 5.36 Съответствие с политики, правила и стандарти за информационна сигурност | Спазват ли се вътрешните правила на практика и наблюдават ли се непрекъснато? | Подпомага прилагането на политиките, киберхигиената, контрола на достъпа, готовността за инциденти и коригиращите действия |
Контрол 5.35 е крайъгълният камък на увереността, защото валидира дали ISMS се преглежда независимо. Контрол 5.36 потвърждава, че политиките не са просто одобрени, а реално се спазват. Контрол 5.31 свързва ISMS с правните, регулаторните и договорните задължения, включително NIS2, DORA, GDPR и клиентските изисквания за сигурност.
Картографиране на съответствието между рамки: един одит, много гледни точки за увереност
Зрял работен документ за вътрешен одит трябва изрично да показва как един елемент от доказателствата подпомага няколко очаквания за увереност.
| Одитно доказателство | Увереност по ISO 27001 | Релевантност за NIS2 | Релевантност за DORA | Релевантност за GDPR, NIST и COBIT |
|---|---|---|---|---|
| Правен и регулаторен регистър | Контекст и задължения по съответствие | Обхват, статус на субекта, основания по член 21 | Секторни задължения за ИКТ устойчивост | Отчетност по GDPR, NIST CSF GOVERN, външно съответствие по COBIT |
| Регистър на риска и план за третиране | Оценка на риска, третиране, Декларация за приложимост | Подходящи и пропорционални мерки | Рамка за управление на ИКТ риска и толеранс | Управление на риска по NIST, оптимизация на риска по COBIT |
| Доклад от настолно упражнение за инцидент | Готовност за инциденти и извлечени поуки | Готовност на работния поток за докладване | Класификация, ескалация, докладване и първопричина | Готовност за нарушения по GDPR, NIST CSF RESPOND, управлявани инциденти по COBIT |
| Досие за надлежна проверка на доставчик | Взаимоотношения с доставчици и ИКТ верига на доставки | Уязвимости и практики на доставчици | Регистър на ИКТ трети страни, надлежна проверка, планиране на изход | NIST C-SCRM, управление на доставчици по COBIT |
| Тест за възстановяване от резервно копие | ИКТ готовност и непрекъсваемост | Резервни копия, аварийно възстановяване, управление при кризи | Цели за възстановяване, възстановяване и проверки на целостта | Наличност по GDPR, NIST CSF RECOVER, непрекъсваемост по COBIT |
| Преглед на достъпа | Контрол на достъпа и сигурност на човешките ресурси | Контрол на достъпа и очаквания за MFA | Минимално необходим достъп и силна автентикация | Цялостност и поверителност по GDPR, NIST CSF PROTECT |
Това позволява на CISO да каже на съвета: „Нашият одит на инциденти през юли създаде доказателства за ISO 27001, NIS2, клиентска увереност по DORA, готовност за нарушения по GDPR, резултати за реагиране по NIST CSF и управление на инциденти по COBIT.“
Преглед от ръководството: където одитът се превръща в отчетност
Вътрешният одит има малка стойност, ако констатациите не достигат до ръководството. Прегледът от ръководството по ISO 27001 осигурява механизма, а NIS2 и DORA правят управленското очакване изрично.
Политиката за одит и мониторинг на съответствието за МСП изисква:
Одитните констатации и актуализациите на статуса трябва да бъдат включени в процеса на преглед от ръководството на ISMS.
От раздел „Изисквания за управление“, клауза на политиката 5.4.3.
Тя също посочва:
Генералният мениджър (GM) трябва да одобри план за коригиращи действия и да проследява неговото внедряване.
От раздел „Изисквания за управление“, клауза на политиката 5.4.2.
Прегледът от ръководството трябва да отговаря на следните въпроси:
- Правилно ли са отразени в обхвата на ISMS задълженията по NIS2, DORA, GDPR и договорите?
- Одитират ли се достатъчно често контролите с висок риск?
- Кои констатации показват системна слабост, а не изолирана грешка?
- Има ли просрочени коригиращи действия?
- Приемат ли собствениците на риска остатъчния риск осъзнато?
- Достатъчно ли са ресурсно обезпечени доставчиците, докладването на инциденти, непрекъсваемостта и тестването?
- Подсказват ли одитните тенденции нужда от промени в политики, инструменти, бюджет или обучение?
Ако тези отговори не са документирани, организацията може да има доказателства за дейност, но не и доказателства за управление.
Често срещани капани, които да избягвате през 2026 г.
Най-често срещаният провал е вътрешният одит по ISO 27001 да се третира като отделен от регулаторната увереност. Това създава дублиране и слепи зони.
Други капани включват:
- Обхватът изключва критични доставчици, облачни платформи или външно възложени SOC услуги.
- Приложимостта на NIS2 или DORA не е документирана в правния регистър.
- Планът за одит не е одобрен от ръководството.
- Извадково тестване се извършва, но не се документира.
- Вътрешните одитори преглеждат собствената си работа без смекчаващи мерки.
- Констатациите описват симптоми, но не и първопричини.
- Коригиращите действия актуализират документи, но не поправят процеси.
- Прегледът от ръководството получава одитни резултати, но не взема решения.
- Упражненията за инциденти тестват техническото реагиране, но не и регулаторното уведомяване.
- Одитите на доставчици преглеждат въпросници, но не и договори, планове за изход или риск от концентрация.
- Доказателствата за резервни копия показват успешни задачи, но не и целостта на възстановяването.
- Прегледите на правата за достъп се извършват, но изключенията не се проследяват до приключване.
Всеки капан може да се превърне в незначително или съществено несъответствие в зависимост от тежестта и системното въздействие. По-важното е, че всеки отслабва способността на организацията да доказва устойчивост пред NIS2, DORA и клиентски проверки.
Превърнете плана си за одит за 2026 г. в механизъм за доказателства
Ако вашата програма за вътрешен одит все още е еднократно годишно събитие, сега е моментът да я преосмислите.
Започнете с одобрен от ръководството план за одит. Дефинирайте обхвата на ISMS около реални услуги, регулирани задължения и зависимости от трети страни. Изградете риск-базирана одитна вселена. Документирайте извадковото тестване. Класифицирайте констатациите последователно. Използвайте анализ на първопричините. Проследявайте CAPA. Включвайте резултатите в прегледа от ръководството. Поддържайте месечен календар на доказателствата.
Clarysec може да ви помогне да напреднете по-бързо с:
- Zenith Blueprint: 30-стъпкова пътна карта за одитора за планиране на одит, изпълнение, констатации, преглед от ръководството и непрекъснато подобрение.
- Zenith Controls: ръководство за съответствие между рамки за картографиране на увереността по ISO 27001 към очакванията по NIS2, DORA, GDPR, NIST CSF и COBIT.
- Политика за одит и мониторинг на съответствието и Политика за одит и мониторинг на съответствието за МСП за готово за управление планиране на одита и управление на констатациите.
- Политика за информационна сигурност за преглед на KPI, инциденти, одитни констатации и статус на риска на ниво ръководство.
Изберете една област с висок риск, като докладване на инциденти или управление на ИКТ доставчици, и проведете фокусиран вътрешен одит, използвайки структурата на 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
