Пътна карта за DORA в 8 практически стъпки
При проверка най-скъпият въпрос не е дали организацията разполага с политики по киберсигурност, а дали може да докаже, че те работят при реален инцидент. Добре изготвената пътна карта за DORA превръща това изискване от общ регулаторен риск в последователна програма с ясни отговорници, срокове, доказателства и измерими резултати.
Регламентът за оперативната устойчивост на цифровите технологии DORA се прилага от 17 януари 2025 г. и поставя високи изисквания пред финансовите субекти в Европейския съюз. Неговият обхват включва банки, застрахователи, инвестиционни посредници, платежни институции, дружества за управление на активи и други регулирани организации. За IT доставчиците DORA също е съществена тема: когато обслужват финансови клиенти, те трябва да предоставят прозрачност, контролируемост и договорни гаранции за услугите си.
Какво трябва да постигне една пътна карта за DORA
DORA не е проект за еднократно написване на документация. Регламентът изисква модел на управление, при който ръководството разбира цифровите рискове, критичните услуги са защитени, инцидентите се управляват навременно, а възстановяването се тества и документира.
Практически пътната карта трябва да обедини пет взаимосвързани области: управление на ICT риска, докладване и управление на инциденти, тестване на цифровата оперативна устойчивост, контрол над доставчиците на ICT услуги и обмен на информация за киберзаплахи. Ако една от тези области остане извън обхвата, организацията може да има добри технологични решения, но да не успее да докаже регулаторно съответствие.
Подходът зависи от размера, сложността и рисковия профил на организацията. Малка платежна институция не следва да копира процесите на голяма банка. Тя обаче трябва да може да покаже, че е идентифицирала критичните си услуги, оценила е зависимостите си и е приложила контроли, съразмерни на реалния риск.
1. Определете обхвата и отговорността на ръководството
Първата стъпка е да се установи кои дружества, процеси, системи и услуги попадат в обхвата на DORA. Това често е по-трудно, отколкото изглежда. Основна система може да се поддържа от външен доставчик, да използва облачна инфраструктура и да обменя данни с няколко други платформи. Ако тази зависимост не е видима, не може да бъде управлявана.
Ръководният орган носи крайната отговорност за управлението на ICT риска. Затова трябва да има формално определени роли, периодично отчитане, правила за ескалация и одобрение на ключови политики. Не е достатъчно задачата да бъде прехвърлена изцяло към IT отдела или външния доставчик.
Полезен начален резултат е регистър на обхвата, който свързва бизнес услугите, информационните активи, собствениците на процеси и приложимите нормативни изисквания. Той създава основа за следващите решения.
2. Картографирайте критичните бизнес услуги и зависимостите
DORA поставя фокус върху услугите, чиято недостъпност, забавяне или компрометиране би засегнало клиентите, пазара или регулаторните задължения на организацията. Затова анализът не започва от списък със сървъри, а от бизнес процесите.
Определете кои услуги са критични, какъв е приемливият период на прекъсване и каква загуба на данни може да бъде допусната. След това проследете зависимостите им: приложения, бази данни, мрежова свързаност, облачни услуги, идентичности, резервни копия, външни интерфейси и ключови доставчици.
Тази карта често открива скрити единични точки на отказ. Например организацията може да разполага с резервно копие, но възстановяването да зависи от един администратор, недостъпен лиценз или неописана конфигурация. Резервното копие е полезно само когато възстановяването е проверено, достатъчно бързо и изпълнимо от оторизиран екип.
3. Направете анализ на пропуските спрямо DORA
След като обхватът и зависимостите са ясни, следва оценка на текущото състояние. Анализът на пропуските сравнява съществуващите политики, технически мерки, договори и оперативни практики с изискванията на DORA.
Проверката трябва да разглежда не само наличието на документ, а неговото реално прилагане. Политика за управление на достъпа без периодичен преглед на правата не е достатъчен контрол. План за реакция при инцидент, който не е упражняван, не дава сигурност, че екипът ще действа координирано под напрежение.
Резултатът е регистър на несъответствията с оценка на риска, собственик, необходим ресурс и целеви срок. Така организацията избягва неефективното изпълнение на множество паралелни задачи без приоритет.
4. Изградете управляем модел за ICT риск
Управлението на ICT риска трябва да свързва активите, заплахите, уязвимостите, контролите и остатъчния риск. За много организации практичният проблем не е липсата на технологии, а липсата на единен процес, който показва защо даден контрол е въведен, кой го наблюдава и как се доказва ефективността му.
Тук попадат управлението на достъпа, защитата на крайни устройства, криптирането, сегментацията на мрежата, управлението на уязвимости, регистрите на активите и наблюдението на логове. Приоритет следва да имат контролите около критичните услуги и чувствителните данни, а не тези, които просто се внедряват най-лесно.
Съществуващите практики по ISO 27001, GDPR или NIS2 могат да бъдат добра основа, но не покриват автоматично DORA. Регламентът има специфични изисквания за оперативна устойчивост, докладване, тестове и контрол върху външните ICT зависимости.
5. Подгответе процес за инциденти и регулаторно докладване
При киберинцидент времето за вземане на решение е ограничено. Организацията трябва предварително да е определила какво се счита за инцидент, кой оценява неговата тежест, как се събира информация и кой комуникира с ръководството, клиентите, доставчиците и компетентните органи.
DORA изисква управление и докладване на значими ICT инциденти по определени критерии и срокове. Затова е необходима връзка между техническите сигнали и бизнес въздействието. Само екипът по информационна сигурност не може винаги да прецени дали прекъсването на дадена услуга засяга критична функция, договорно задължение или голям брой клиенти.
Процедурата трябва да включва шаблони за оценка, дневник на действията, правила за запазване на доказателства и последващ анализ на причините. Този анализ е ценен не само за регулатора, а и за предотвратяване на повторен инцидент.
6. Превърнете тестването във възстановима способност
Тестът за възстановяване не е формално включване на резервен сървър. Той трябва да покаже дали критичната услуга може да бъде възстановена в договорения срок, с необходимата цялост на данните и при реалистични ограничения.
Планирайте тестове на резервни копия, сценарии за отказ на облачна услуга, компрометирани потребителски акаунти, ransomware и прекъсване на комуникационна свързаност. Документирайте резултатите, установените отклонения и коригиращите действия. Ако тестът покаже, че възстановяването отнема два дни вместо допустимите четири часа, това е полезна информация, която трябва да доведе до промяна в архитектурата, процедурите или договорените нива на услугата.
При по-висок риск DORA предвижда и усъвършенствано тестване на проникване, базирано на заплахи. Не всяка организация ще има еднакъв обхват на такива тестове, но всяка трябва да може да обоснове избрания подход.
7. Поставете доставчиците под договорен и оперативен контрол
Външният доставчик не премахва риска, а променя начина, по който той се управлява. DORA изисква организацията да поддържа регистър на договорните си отношения с доставчици на ICT услуги и да оценява риска от концентрация, подизпълнители, локализация на данните и зависимост от една платформа.
Договорите трябва ясно да уреждат нивата на услугата, изискванията за сигурност, уведомяването при инциденти, правата за одит, условията за достъп до данни, подпомагането при възстановяване и стратегията за прекратяване или миграция. Особено критична е възможността организацията да запази контрол над данните и услугите си при прекъсване на отношенията с доставчика.
За доставчиците на IT услуги това е възможност да покажат зрялост чрез проследими процеси, документация, проверими резервни копия и ясни ангажименти при инцидент.
8. Управлявайте пътната карта като постоянна програма
Последната стъпка е да се създаде реалистичен план за изпълнение. В него всяка мярка трябва да има собственик, бюджет, срок, зависимост и критерий за приемане. Практичният ред обикновено започва с критичните услуги, основните рискове и слабостите, които биха блокирали реакцията при инцидент.
Ефективното управление използва периодични отчети към ръководството: напредък по мерките, открити рискове, резултати от тестове, състояние на доставчиците и неизпълнени коригиращи действия. Това превръща DORA от задача на отделен проектен екип в управленска дисциплина.
За организации без голям вътрешен капацитет външен партньор като Буллсофт може да комбинира оценката на съответствието с технологични мерки, резервно копиране, възстановяване, документация и текущ контрол. Решаващото условие е отговорностите да останат ясни и да има доказателства за всяко съществено решение.
Най-полезната пътна карта не е тази с най-много мерки, а тази, която позволява на ръководството спокойно да отговори на три въпроса: кои услуги са критични, как ги възстановяваме и как доказваме, че ще го направим навреме.
