Готовност за DORA за финансовите субекти и техните доставчици на ИКТ услуги

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

Въпросът пред ръководството е практически: може ли организацията да обясни кои финансови услуги от кои ИКТ системи зависят, как ще бъде овладяно прекъсване и какви доказателства подкрепят допусканията ѝ за възстановяване? Политиките имат значение, но сами по себе си не могат да отговорят на този въпрос. Ръководството се нуждае от свързан поглед върху отговорностите, зависимостите, договорите, тестовете, инцидентите и неразрешените рискове.

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

Започнете с документирано решение за приложимостта за всяко съответно юридическо лице. Член 2 от DORA посочва обхванатите категории и изключенията. Предприятие, което се описва като FinTech, стартъп или МСП, не попада автоматично в обхвата, нито е автоматично освободено.

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

При доставчиците разграничавайте три позиции:

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

Местоположението не решава въпроса за доставчика. Доставчик на облачни услуги или софтуер със седалище в САЩ може да се сблъска със свързани с DORA изисквания на клиенти, когато обслужва финансови субекти от ЕС. Това търговско отношение не го прави автоматично субект на всяко задължение, наложено на финансов субект.

Пропорционалността също изисква обоснована оценка. Член 4 отчита фактори като размера, цялостния рисков профил и естеството, мащаба и сложността на услугите. Член 16 предвижда опростена рамка за управление на ИКТ риска за посочени категории. Това не са взаимозаменяеми понятия, а обичайният статус на МСП не е универсален пряк път. Пазете анализа на допустимостта заедно с решението за обхвата.

Направете отговорността на ръководството видима

Съгласно член 5 от DORA ръководният орган носи крайната отговорност за управлението на ИКТ риска на финансовия субект. Делегирането на изпълнението на CISO, технологичен екип или външен доставчик не прехвърля тази отговорност.

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

Практическа препоръка е ръководството да получава пакет от доклади, фокусиран върху решенията, вместо табло с процент на изпълнение. Включете:

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

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

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

Изградете програмата около финансовите функции

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

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

Получената карта трябва да свързва всяка функция със:

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

Валидирайте картата както с оперативните, така и с бизнес екипите. Записите от снабдяването показват какво е закупено; те не показват непременно как дадена услуга функционира днес.

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

Превърнете управлението на ИКТ риска във финансирана работа

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

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

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

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

Подгответе решенията при инциденти преди прекъсването

DORA изисква от финансовите субекти да управляват свързаните с ИКТ инциденти и да докладват големите инциденти на съответния компетентен орган. Членове 17–23 установяват рамката; приложимите регулаторни технически стандарти и техническите стандарти за изпълнение съдържат подробните критерии за класификация, праговете, съдържанието на докладите и процедурите.

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

Процесът на реагиране трябва да прави няколко решения изпълними под натиск:

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

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

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

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

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

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

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

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

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

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

Третирайте риска от трети страни като въпрос на непрекъснатост на услугата

Съгласно DORA финансовият субект остава отговорен за своите задължения, когато използва доставчици на ИКТ услуги. Членове 28–30 свързват оценката на риска от трети страни, договорните договорености, наблюдението и планирането на излизането.

Поддържайте регистъра и оперативната картина

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

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

Преглеждайте договорите спрямо действителната услуга

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

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

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

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

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

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

Разберете къде се срещат DORA и NIS2

DORA е регламент на ЕС с пряко приложение. NIS2 е директива, която се прилага чрез националното право, като приложимостта зависи от сектора, размера, услугата и правилата за включване. Срокът за транспонирането ѝ в националното право беше 17 октомври 2024 г.; организациите трябва да проучат приложимото национално изпълнение, вместо да приемат, че съществува единен идентичен оперативен режим.

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

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

Общите контроли могат да подпомагат DORA, ISO 27001, задълженията за защита на личните данни и увереността на клиентите, когато обхватът и доказателствата съвпадат. Използвайте повторно преглед на достъпа или тест за възстановяване, когато той наистина подкрепя няколко изисквания, като запазвате спецификите на финансовия сектор. Сертификатът по ISO 27001 не доказва съответствие с DORA.

Прилагането също се различава. Надзорните правомощия и санкциите по DORA спрямо финансовите субекти зависят от нейните разпоредби и приложимите национални мерки; определените критични доставчици имат отделен режим на надзор. Не планирайте бюджета за риска около някаква предполагаема универсална глоба по DORA. Оценете относимата правна експозиция и оперативните последици от неадекватна устойчивост.

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

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

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

Ръководството възлага три свързани работни пакета:

Бизнес собственикът проверява дали целите за възстановяване на плащанията остават постижими. Отделът за съответствие проверява дали процедурите за докладване и записите в регистъра отразяват договореностите. Ръководството одобрява необходимото финансиране и преглежда оставащите ограничения.

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

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

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

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

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

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