Програма за тестване по DORA: съпоставяне на тестовете с ISO 27001

Февруари 2026 г. е. Директорът по информационна сигурност (CISO) на средно голяма платежна институция има заседание на управителния съвет след два дни, надзорен одит по ISO/IEC 27001:2022 след шест седмици и надзорно искане по DORA, което чака във входящата поща на екипа по съответствие.

Регулаторът не иска лъскава киберстратегия. Искането е практическо:

• Представете програмата си за тестване на цифровата оперативна устойчивост за 2026 г.
• Покажете кои тестове покриват критични или важни функции.
• Докажете как констатациите се отстраняват и повторно се тестват.
• Предоставете доказателства за надзора от управителния орган.
• Обяснете как са включени доставчиците на ИКТ услуги от трети страни.
• Предоставете записи за анализ на уязвимости, сценарийни тестове, тестване на производителността и капацитета и тестове за проникване.

CISO отваря четири папки. Сканиранията за уязвимости са в системата за билети на SOC. Бележките от настолни упражнения са в споделен диск. Резултатите от тестовете за натоварване са собственост на инженерния екип. Докладите от тестове за проникване са в ограниченото хранилище на правния отдел. Проследяването на отстраняването е разпределено между Jira, електронна поща и електронна таблица, създадена за миналогодишния ISO одит.

Нищо не е фиктивно. Голяма част е качествено свършена работа. Но това все още не е управлявана програма за тестване на цифровата оперативна устойчивост по DORA. Това е набор от тестове.

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

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

Оперативният модел на Clarysec е изграден точно за този проблем. Чрез Zenith Blueprint: 30-стъпкова пътна карта за одитора, набора от политики на Clarysec, съгласувани с ISO, и Zenith Controls: Ръководство за кръстосано съответствие, организациите могат да превърнат разпръснатите дейности по устойчивост в контролиран годишен каталог на тестовете, който удовлетворява надзорни органи, одитори, клиенти и управителни съвети.

Защо DORA превръща тестването във въпрос на управление

DORA е ясен относно отговорността на изпълнителното ръководство. Article 5 възлага отговорността за управление на ИКТ риска на управителния орган. Article 6 изисква надеждна, цялостна и добре документирана рамка за управление на ИКТ риска, интегрирана в общата система за управление на риска на организацията. Article 4 въвежда пропорционалност, което означава, че изискванията трябва да се прилагат според размера, общия рисков профил и естеството, мащаба и сложността на услугите, дейностите и операциите.

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

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

Следователно програмата за тестване по DORA трябва да свързва:

• Бизнес услуги и критични или важни функции
• ИКТ активи, данни и зависимости от трети страни
• Оценка на риска, собственици на риска и планове за третиране на риска
• Видове тестове, честота и задействащи събития
• Разрешение, независимост и правила за изпълнение
• Констатации, срокове за отстраняване и повторно тестване
• Съхранение на доказателства и контрол на достъпа
• Докладване към ръководството и непрекъснато подобрение

За по-малки или по-нискорискови финансови субекти Article 16 предвижда опростена рамка за управление на ИКТ риска, но опростена не означава неформална. Дори мащабираните програми се нуждаят от документирано управление на ИКТ риска, мониторинг, устойчиви системи, идентифициране на източници на ИКТ риск и аномалии, ключови зависимости от ИКТ трети страни, мерки за непрекъсваемост и възстановяване, редовно тестване и извлечени поуки.

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

Какво трябва да включва програма за тестване по DORA за 2026 г.?

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

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

За повечето организации практическият каталог се изгражда около четири семейства тестове.

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

“Видове тестове: Програмата за тестване на сигурността трябва да включва най-малко: (a) сканиране за уязвимости, състоящо се от автоматизирани седмични или месечни сканирания на мрежи и приложения за идентифициране на известни уязвимости; (b) тестове за проникване, състоящи се от ръчно задълбочено тестване на конкретни системи или приложения от квалифицирани тестери за идентифициране на сложни слабости; и (c) упражнения с червен екип, състоящи се от сценарийни симулации на реални атаки, включително социално инженерство и други тактики, за тестване на цялостните способности на организацията за откриване и реагиране.”

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

“График за тестване: Организацията трябва да извършва тестване на сигурността по редовен график. Ключови системи, изложени към интернет, и критични вътрешни приложения трябва да преминават тестове за проникване най-малко веднъж годишно. Високорискови промени, като внедряване на нова критична система или съществени надстройки, изискват ad hoc тестване преди и/или скоро след въвеждане в експлоатация в продукционна среда.”

Това е критично за DORA. Статичен годишен план не е достатъчен, ако субектът внедрява нов платежен шлюз, мигрира основна система към облак, сменя доставчик на управлявани услуги или пуска нов поток за автентикация на клиенти. Високорисковата промяна трябва да задейства допълнително тестване.

Изградете годишния каталог на тестовете като единен източник на истина

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

Всеки тест трябва да отговаря на пет одиторски въпроса:

1. Коя услуга, актив, доставчик, приложение или процес беше тестван?
2. Кой риск, задължение или изискване за контрол задейства теста?
3. Кой разреши и извърши теста?
4. Какви констатации бяха идентифицирани, приети, отстранени или отложени?
5. Какви доказателства потвърждават, че тестът е извършен и резултатът е прегледан?

Практически каталог в стила на Clarysec включва следните полета.

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

“Всеки одит трябва да включва определен обхват, цели, отговорен персонал и изисквани доказателства.”

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

Същата политика посочва:

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

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

Съпоставете видовете тестове по DORA с доказателства по ISO 27001

Силата на интегрираната програма е, че един тест може да покрие множество задължения. Ключът е доказателствата да се маркират правилно и да се свържат със СУИС.

Zenith Blueprint обяснява това във фазата „Одит, преглед и подобрение“, Step 24:

“Вашата Декларация за приложимост (SoA) трябва да бъде съгласувана с вашия Регистър на риска и План за третиране на риска. Проверете повторно дали всеки контрол, който сте избрали като третиране на риска, е маркиран като „Приложим“ в SoA.”

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

Тази таблица помага на CISO да отговори на често срещания въпрос на главния изпълнителен директор: “Достатъчни ли са нашите ISO тестове за проникване и сканирания за уязвимости за DORA?”

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

Анализ на уязвимости: непрекъснати доказателства, не само резултати от сканиране

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

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

“Идентифициране и оценяване на известни уязвимости във всички ИТ активи по своевременен и последователен начин”

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

Силен запис от анализ на уязвимости трябва да включва:

• Снимка на инвентара на активите, използвана за определяне на обхвата
• Дата на сканиране, инструмент и удостоверен или неудостоверен метод
• Изключения и бизнес обосновка
• Констатации по тежест, експлоатируемост и бизнес услуга
• Съпоставяне с критични или важни функции и видове данни
• Референции към билети и собственик на риска
• SLA за отстраняване и краен срок
• Резултат от повторно тестване
• Изключения с одобрение на остатъчния риск

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

Сценарийни тестове: докажете вземането на решения преди реалния инцидент

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

DORA Articles 17 to 20 изискват формален жизнен цикъл на инцидент, свързан с ИКТ: откриване, управление, уведомяване, записване, мониторинг, обработване, последващи действия, документиране на анализ на първопричините, отстраняване, класификация на тежестта, възлагане на роли, ескалация на съществени инциденти и докладване през изискваните етапи. Когато са засегнати финансовите интереси на клиентите, клиентите трябва да бъдат информирани без неоправдано забавяне.

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

Zenith Blueprint, във фазата Controls in Action, Step 23, дава практическия модел за доказателства:

“Изберете скорошно събитие или проведете настолно упражнение, за да валидирате плана си. Заснемете и журнализирайте всички решения, роли и комуникации (5.26) и актуализирайте плана с извлечените поуки (5.27).”

Сценарийният тест по DORA трябва да произвежда одитируеми записи, а не само бележки от среща:

• Кратко описание на сценария и цели
• Участници и роли, включително правен отдел, комуникации, ИТ, SOC, собственик на бизнеса и контакти при доставчици
• Хронология на injects и решенията
• Решение за класификация и анализ на праговете за докладване
• Проекти на вътрешни и външни комуникации
• Действия за запазване на доказателства
• Извлечени поуки
• Собственици на действия и крайни срокове
• Актуализирани процедури за инциденти, непрекъсваемост или комуникации

Политиката за непрекъсваемост на дейността и аварийно възстановяване за МСП на Clarysec затвърждава очакването за ежегодно тестване:

“Организацията трябва да тества както своя план за непрекъсваемост на дейността (BCP), така и своите способности за аварийно възстановяване (DR) най-малко веднъж годишно. Тестовете трябва да включват:”

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

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

Тестването на производителността често се третира като инженерна тема. По DORA то се превръща в доказателство за устойчивост.

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

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

Добър запис от тест за производителност и капацитет трябва да съдържа:

• Базови предположения за нормално и пиково натоварване
• Тествани критични транзакционни пътеки
• Тествани инфраструктурни и облачни лимити
• Табла за мониторинг и прагове за предупреждения
• Режими на отказ, като насищане на опашки или тесни места в база данни
• Релевантност на RTO и RPO, когато се тества превключване към резервен ресурс или възстановяване
• Въздействие върху бизнеса при нарушаване на праговете
• Действия за отстраняване, решения за мащабиране или промени в архитектурата
• Приемане от ръководството на остатъчния риск за капацитета

Zenith Blueprint, Step 23, свързва очакванията за възстановяване с доказателствата:

“Проверете дали целевите времена за възстановяване (RTO) и целевите точки на възстановяване (RPO) за критични системи са съгласувани с очакванията за непрекъсваемост на дейността (5.30). Проведете най-малко един технически тест за възстановяване или симулация на превключване към резервен ресурс и документирайте резултатите.”

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

Тестове за проникване и упражнения с червен екип: силните доказателства изискват силен контрол

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

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

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

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

Политиката за тестване на сигурността и упражнения с червен екип укрепва веригата за отстраняване:

“Отстраняване на констатации: Всички идентифицирани уязвимости или слабости трябва да бъдат документирани в доклад с констатации и оценки на тежестта. След получаване на доклада собствениците на системи отговарят за създаването на план за отстраняване с крайни срокове; например критичните констатации трябва да бъдат отстранени в рамките на 30 дни, а констатациите с висока тежест — в рамките на 60 дни, в съответствие с Политиката за управление на уязвимости и корекции на организацията. STC трябва да проследява напредъка по отстраняването. Трябва да се извършва повторно тестване, за да се потвърди, че критичните проблеми са отстранени или адекватно смекчени.”

Същата политика дефинира очакванията за докладване:

“Докладване: В края на всеки тест трябва да бъде издаден формален доклад. За тестове за проникване докладът трябва да включва резюме за ръководството, методология и подробни констатации с подкрепящи доказателства и препоръки.”

Zenith Blueprint, Step 21, също подчертава защитата по време на одит и тестване:

“Нито един тест или одит не трябва да започва без документирано одобрение от собствениците на системи или съответните заинтересовани страни.”

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

Включете доставчиците на ИКТ услуги от трети страни, преди тестът да се провали

DORA превръща риска от ИКТ трети страни в централен въпрос на устойчивостта. Article 28 изисква финансовите субекти да управляват риска от ИКТ трети страни в рамката за управление на ИКТ риска, да запазват отговорността си при използване на ИКТ услуги, да поддържат информационен регистър, да докладват определени договорености, да извършват оценки преди сключване на договор и да използват доставчици, отговарящи на подходящи стандарти за информационна сигурност. Articles 29 and 30 разглеждат риск от концентрация, подизпълнение, възстановяване на данни, договорни защити, нива на обслужване, съдействие при инциденти, права на одит, тестване на аварийни мерки при доставчика, участие в тестване, когато е приложимо, и договорености за изход.

ISO/IEC 27001:2022 Приложение A предоставя поддържащи контроли за доставчици, включително 5.19 Информационна сигурност във взаимоотношенията с доставчици, 5.20 Адресиране на информационната сигурност в споразумения с доставчици, 5.21 Управление на информационната сигурност във веригата за доставка на ИКТ, 5.22 Мониторинг, преглед и управление на промените в услугите на доставчици и 5.23 Информационна сигурност при използване на облачни услуги.

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

• Предположения за превключване към резервен ресурс при доставчик на облачни услуги
• Ескалация от управляван SOC и запазване на доказателства
• Комуникация при инцидент с основна банкова платформа
• Сценарий за прекъсване при платежен процесор
• Тест за възстановяване на доставчик на идентичност
• Уверения за тестове за проникване от SaaS доставчик
• Оценка на въздействието от веригата на критични подизпълнители

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

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

Добре проектираната програма за тестване по DORA намалява умората от одити. Същите доказателства могат да подпомогнат DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST CSF 2.0 и прегледи на управлението по COBIT 2019, ако са правилно маркирани, съхранявани и докладвани.

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

Как одиторите ще тестват същата програма

Надзорен орган по DORA, ISO одитор, оценител по NIST, проверяващ по COBIT и клиентски одитор могат да прегледат едни и същи доказателства през различни перспективи.

Zenith Controls е полезен тук като компас за кръстосано съответствие. За тестване по DORA Clarysec подчертава 5.35 Независим преглед на информационната сигурност, 8.8 Управление на технически уязвимости и 8.6 Управление на капацитета като особено важни опори в ISO/IEC 27001:2022 Приложение A. Те помагат на собствениците на контроли да свържат тестването с независимо уверение, обработване на уязвимости и оперативен капацитет.

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

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

Това изречение трябва да се превърне в оперативно правило. Всеки собственик на тест трябва да знае какво да съхранява, къде да го съхранява, как да го защитава и как то се свързва с доказателства за риск и контрол.

Изградете пакет доказателства DORA към ISO за една седмица

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

Ден 1: Дефинирайте обхват и критичност

Използвайте логиката на ISO/IEC 27001:2022 Clauses 4.1 to 4.4. Идентифицирайте заинтересованите страни, регулаторните задължения, договорните задължения, интерфейсите и зависимостите. Избройте бизнес услугите, критичните или важни функции, ключовите активи, видовете данни и доставчиците на ИКТ услуги.

Резултат: регистър на обхвата на тестването по DORA.

Ден 2: Създайте годишния каталог на тестовете

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

Резултат: каталог за тестване на цифровата оперативна устойчивост за 2026 г.

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

Съпоставете всеки тест с ISO/IEC 27001:2022 Приложение A, регистъра на риска, SoA, DORA articles, задълженията към доставчици и релевантните записи в Zenith Controls. Например месечните външни сканирания за уязвимости се съпоставят с 8.8 Управление на технически уязвимости, третиране на риска, мониторинг, управление на ИКТ риска по DORA и резултати за уязвимости по NIST CSF.

Резултат: матрица за съпоставяне на контролите.

Ден 4: Стандартизирайте папките за доказателства

Създайте контролирана структура за доказателства:

• 01 План и разрешение
• 02 Обхват и правила за изпълнение
• 03 Сурови резултати
• 04 Окончателен доклад
• 05 Регистър на констатациите
• 06 Билети за отстраняване
• 07 Доказателства от повторно тестване
• 08 Докладване към ръководството
• 09 Извлечени поуки и актуализации на политики

Резултат: хранилище за доказателства с правила за съхранение.

Ден 5: Прегледайте констатациите и докладването

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

Резултат: табло за тестване по DORA и ISO, готово за управителния съвет.

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

Най-честият провал не е липсата на тестване. Той е липсата на управление.

Следете за тези проблеми:

• Тестове за проникване се извършват ежегодно, но констатациите не се проследяват до приключване
• Сканирания за уязвимости се изпълняват често, но критични активи липсват от обхвата
• Провеждат се настолни упражнения, но няма журнал на решенията или план за действия по извлечените поуки
• Тестове за възстановяване на резервни копия са завършени, но не са съпоставени с RTO и RPO
• Тестове за натоварване се изпълняват от инженерния екип, но не се докладват към риска или съответствието
• Доставчици на ИКТ услуги са изключени от сценарийни и възстановителни тестове
• Доказателствата се съхраняват в лични папки, чат нишки или неуправлявани дискове
• Докладите към управителния съвет се фокусират върху броя дейности, а не върху нерешения риск за устойчивостта
• SoA посочва, че даден контрол е приложим, но няма доказателства от тестове
• Тестването създава риск за продукционната среда, защото разрешението и границите са неясни

Всеки пропуск е решим. Решението не е повече произволно тестване. Решението е една контролирана програма, която свързва риск, тестови дейности, отстраняване, доказателства и надзор от ръководството.

Какво всъщност трябва да вижда управителният съвет

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

Силен тримесечен или полугодишен доклад включва:

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

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

От разпръснати тестове към стратегическа устойчивост

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

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

Така тежестта на съответствието се превръща в стратегическа способност.

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

Нашият подход комбинира:

• Zenith Blueprint за поетапно внедряване на ISO и готовност за одит
• Zenith Controls за кръстосано съпоставяне на съответствието между контроли, рамки и одиторски очаквания
• Политики за предприятия и МСП относно тестване на сигурността, одитен мониторинг, управление на уязвимости, сигурност на приложенията, непрекъсваемост и информационна сигурност
• Практически регистри, структури за доказателства и шаблони за докладване към ръководството

Ако вашите доказателства за тестване по DORA за 2026 г. са разпръснати между инструменти за сканиране, инженерни папки, бележки от настолни упражнения и PDF доклади от тестове за проникване, сега е моментът да ги консолидирате.

Започнете с един годишен каталог на тестовете, съпоставен с третирането на риска по ISO/IEC 27001:2022, вашата SoA, критични или важни функции, ИКТ трети страни и докладване към ръководството. След това използвайте Zenith Blueprint, Zenith Controls и инструментариума от политики на Clarysec, за да превърнете този каталог в защитими одиторски доказателства.

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