Регистър на информацията по DORA: ръководство по ISO 27001

Вторник е, 09:15 ч. Сара, CISO на бързо растяща финтех компания, участва в оценка на готовността заедно с мениджъра по съответствието, правния консултант, ръководителя по снабдяването и архитекта по сигурността на облачните услуги. Външният консултант изпълнява ролята на представител на надзорния орган по DORA.

„Благодаря за презентацията“, казва той. „Моля, предоставете вашия Регистър на информацията, както се изисква от DORA Article 28, включително договорните отношения за ИКТ услуги, които поддържат критични или важни функции, видимостта върху подизпълнителите, собствеността върху активите и доказателства, че регистърът се поддържа в рамката за управление на ИКТ риска.“

Първият отговор звучи уверено: „Имаме списък с доставчици.“

След това започват въпросите.

Кои доставчици поддържат авторизацията на плащания? Кои договори включват права на одит, съдействие при инциденти, ангажименти за местонахождение на данните, права за прекратяване и съдействие при изход? Кои SaaS платформи обработват лични данни на клиенти? Кои облачни услуги поддържат критични или важни функции? Кои подизпълнители стоят зад доставчика на управлявани услуги за сигурност? Кой вътрешен собственик на актив е одобрил зависимостта? Кои рискове в плана за третиране на риска по ISO/IEC 27001:2022 са свързани с тези доставчици? Кои записи в Декларацията за приложимост обосновават контролите?

До 10:30 ч. екипът е отворил четири електронни таблици, експорт от CMDB, SharePoint папка с PDF договори, списък на обработващи лични данни за целите на защитата на личните данни, отчет за облачно фактуриране и ръчно поддържан инструмент за проследяване на SaaS. Нито един от тези източници не съвпада с останалите.

Това е практическият проблем на Регистъра на информацията по DORA през 2026 г. Внедряването на DORA премина от „нуждаем се от пътна карта“ към „покажете доказателствата“. За финансовите субекти, доставчиците на ИКТ услуги от трети страни, CISO, вътрешните одитори и екипите по съответствието регистърът вече не е административен шаблон. Той е свързващият слой между ИКТ договорите, риска от доставчици, веригите от подизпълнители, облачните услуги, ИКТ активите, критичните функции, управленската собственост и доказателствата по ISO/IEC 27001:2022.

Подходът на Clarysec е прост: не изграждайте Регистъра на информацията по DORA като отделен артефакт за съответствие. Изградете го като жив слой от доказателства в рамките на вашата СУИС (ISMS), подкрепен от управление на активи, сигурност на доставчиците, управление на използването на облачни услуги, картографиране на правни и регулаторни задължения, одитни метаданни и проследимост на третирането на риска.

Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls определя три ключови контроли от Приложение A на ISO/IEC 27001:2022 като особено релевантни за тази тема: A.5.9, инвентар на информацията и други свързани активи; A.5.19, информационна сигурност във взаимоотношенията с доставчици; и A.5.20, уреждане на информационната сигурност в споразуменията с доставчици. Тези контроли не са допълнителна документация. Те са оперативната основа за доказване, че регистърът е пълен, има определена собственост, актуален е и е годен за одит.

Какво очаква DORA от Регистъра на информацията

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

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

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

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

Зрелият Регистър на информацията по DORA трябва да отговаря на четири практически въпроса.

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

Защо ISO 27001 е най-бързият път към защитим регистър по DORA

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

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

Клаузи 6.1.1 до 6.1.3 са мястото, където регистърът става основан на риска. ISO/IEC 27001:2022 изисква повторяем процес за оценка на риска, собственици на риска, анализ на вероятност и последствия, третиране на риска, избор на контроли, Декларация за приложимост и одобрение на остатъчния риск от собственика на риска. Регистър по DORA, който не е свързан с третиране на риска, се превръща в статичен списък. Регистър, свързан с рискови сценарии, контроли и собственици, се превръща в одитно доказателство.

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

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

Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint обяснява основата от активи във фазата „Controls in Action“, Step 22:

В най-стратегическата си форма инвентарът на активите служи като централната нервна система на вашата СУИС. Той определя как се предоставя достъп (8.2), къде трябва да се прилага шифроване (8.24), кои системи изискват резервно копиране (8.13), какви журнали се събират (8.15), както и как се прилагат политиките за класификация и съхранение (5.10, 8.10).

Този цитат обобщава практическия извод. Не можете да поддържате надежден Регистър на информацията по DORA, ако базовият инвентар на активите не е надежден. Ако регистърът ви посочва „Core Banking SaaS“, но инвентарът на активите не показва приложно-програмни интерфейси (API), служебни акаунти, набори от данни, източници на журнали, криптографски ключове, зависимости за резервни копия и собственици, регистърът е непълен от одитна гледна точка.

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

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

Минимално жизнеспособният модел има седем свързани обекта.

Тази структура позволява един регистър да обслужва множество искания за доказателства. Надзорен орган по DORA може да преглежда договорните отношения, поддържащи критични или важни функции. Одитор по ISO може да проследи контролите за доставчици до препратки в Приложение A и третиране на риска. Проверяващ по GDPR може да види обработващи лични данни, категории данни, местоположения и ангажименти за защита на данните. Оценител, ориентиран към NIST, може да прегледа управление на веригата на доставки, критичност на доставчиците, договорни изисквания и мониторинг на жизнения цикъл.

Регистърът става повече от отговор на въпроса „кои са нашите доставчици?“. Той се превръща в граф на зависимостите.

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

Наборът от политики на Clarysec дава на регистъра оперативно място. За малки и средни предприятия Third-Party and Supplier Security Policy-sme Политика за сигурност на трети страни и доставчици - МСП започва с ясно изискване за регистър:

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

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

Договорите трябва да включват задължителни клаузи, които обхващат:

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

За корпоративни среди Clarysec Supplier Dependency Risk Management Policy Политика за управление на риска от зависимост към доставчици е още по-близка до надзорните очаквания на DORA:

Регистър на зависимостите от доставчици: VMO трябва да поддържа актуален регистър на всички критични доставчици, включително детайли като предоставяни услуги/продукти; дали доставчикът е единствен източник; налични алтернативни доставчици или възможност за замяна; текущи договорни условия; и оценка на въздействието, ако доставчикът откаже или бъде компрометиран. Регистърът трябва ясно да идентифицира доставчици с висока степен на зависимост (напр. такива, за които няма бърза алтернатива).

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

Корпоративната Third party and supplier security policy на Clarysec Политика за сигурност на трети страни и доставчици прави обхвата изричен:

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

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

Договорните доказателства също са важни. Същата корпоративна политика включва:

Права на одит, проверка и искане на доказателства за сигурност

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

Доказателствата за активи са също толкова важни. SME Asset Management Policy на Clarysec Политика за управление на активите - МСП гласи:

Ръководителят по ИТ трябва да поддържа структуриран инвентар на активите, който включва най-малко следните полета:

Корпоративната Asset Management Policy Политика за управление на активите аналогично гласи:

Инвентарът на активите трябва да съдържа най-малко:

Регистърът не трябва да дублира всяко поле за актив, но трябва да препраща към инвентара на активите. Ако SaaS за мониторинг на плащания поддържа откриване на измами, регистърът по DORA трябва да сочи към актива приложение, актива набор от данни, служебните акаунти, интеграциите чрез приложно-програмни интерфейси (API), източниците на журнали и собственика на бизнес процеса.

Облачните услуги заслужават отделен изглед. SME Cloud Usage Policy на Clarysec Политика за използване на облачни услуги - МСП изисква:

Регистър на облачните услуги трябва да се поддържа от ИТ доставчика или GM. Той трябва да записва:

Това е особено ценно за откриване на неуправлявани ИТ услуги (shadow IT). Регистър по DORA, който изключва облачни услуги, закупени извън процеса по снабдяване, ще се провали при практическата проверка за пълнота.

Накрая, Legal and Regulatory Compliance Policy на Clarysec Политика за правно и регулаторно съответствие превръща съответствието между рамки в изискване на СУИС:

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

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

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

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

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

Практически пример: съпоставяне на един ИКТ договор с доказателства по ISO 27001

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

Слаб ред в регистъра гласи: „Доставчик: FraudCloud. Услуга: анализ на измами. Договор подписан. Критична: да.“

Ред в регистър на ниво надзорен преглед изглежда съвсем различно.

Сега екипът по съответствието може да изготви съгласуван пакет от доказателства. Регистърът на доставчиците доказва, че доставчикът съществува и има собственик. Инвентарът на активите доказва, че вътрешните системи, приложно-програмни интерфейси (API), набори от данни и журнали са известни. Контролният списък за договори доказва, че задължителните клаузи по DORA са прегледани. Оценката на риска доказва, че концентрацията, подизпълнението, защитата на данните и оперативната устойчивост са разгледани. Декларацията за приложимост показва кои контроли са избрани. Прегледът на мониторинга доказва, че отношението не е забравено след въвеждането.

Zenith Blueprint, фазата „Risk Management“, Step 13, препоръчва точно такъв вид проследимост:

Кръстосано съпоставяйте регулациите: ако определени контроли са внедрени специално за съответствие с GDPR, NIS2 или DORA, можете да отбележите това или в Регистъра на риска (като част от обосновката на въздействието на риска), или в бележките към SoA.

Така регистърът по DORA се превръща в доказателство по ISO 27001, а не в паралелна бюрокрация.

Веригата от доставчици и подизпълнители е мястото, където качеството на регистъра се проваля

Най-големите провали на регистъра не се дължат на липсващи доставчици от най-горно ниво. Те се дължат на скрити вериги от зависимости.

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

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

Clarysec Zenith Blueprint, фазата „Controls in Action“, Step 23, дава практическо указание:

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

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

Съответствие между рамки: DORA, NIS2, GDPR и NIST се нуждаят от една и съща истина за зависимостите

Добре проектираният Регистър на информацията по DORA поддържа повече от DORA.

NIS2 Article 20 превръща киберсигурността в отговорност на управителния орган чрез одобрение, надзор и обучение. Article 21 изисква анализ на риска, политики, обработване на инциденти, непрекъсваемост, сигурност на веригата на доставки, сигурно придобиване и поддръжка, оценка на ефективността, киберхигиена, криптография, сигурност в областта на човешките ресурси, контрол на достъпа, управление на активите и MFA, когато е приложимо. Тези области силно се припокриват с ISO/IEC 27001:2022 и модела за доказателства в регистъра.

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

NIST CSF 2.0 предоставя още една полезна перспектива. Неговата функция GOVERN изисква организациите да разбират мисията, очакванията на заинтересованите страни, зависимостите, правните и договорните изисквания, услугите, от които други зависят, и услугите, от които организацията зависи. Резултатите GV.SC за веригата на доставки изискват програма за управление на риска във веригата на доставки, дефинирани роли на доставчици, интеграция в корпоративното управление на риска, критичност на доставчиците, договорни изисквания, надлежна проверка, мониторинг на жизнения цикъл, координация при инциденти и планиране след прекратяване на взаимоотношенията.

Практическият изглед за съответствие между рамки изглежда така.

Целта не е да се създадат пет работни потока за съответствие. Целта е да се създаде един модел на доказателства, който може да се филтрира за всяка рамка.

През погледа на одитора

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

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

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

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

Zenith Controls помага тези перспективи да се преведат в практическа структура, като закотвя темата в контролите A.5.9, A.5.19 и A.5.20 от Приложение A на ISO/IEC 27001:2022, след което използва интерпретация за съответствие между рамки, за да свърже активи, взаимоотношения с доставчици и споразумения с доставчици с регулаторни, управленски и одитни очаквания. Това е разликата между „имаме регистър“ и „можем да защитим регистъра“.

SME Audit and Compliance Monitoring Policy на Clarysec Политика за одит и мониторинг на съответствието - МСП също разглежда качеството на доказателствата:

Метаданните (напр. кой ги е събрал, кога и от коя система) трябва да бъдат документирани.

Това изискване е малко, но силно. При искане за доказателства през 2026 г. електронна таблица без метаданни за събирането е слабо доказателство. Експорт от регистър, който показва изходна система, дата на извличане, отговорен собственик, статус на одобрение и периодичност на прегледа, е по-силен.

Често срещани констатации по Регистъра на информацията по DORA през 2026 г.

Най-честите констатации са практически.

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

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

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

Четвърто, слаба връзка с активите. Регистрите изброяват доставчици, но не ги свързват с приложения, набори от данни, приложно-програмни интерфейси (API), идентичности, журнали, инфраструктура или бизнес услуги. Това затруднява анализа на въздействието при инциденти и откази на доставчици.

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

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

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

Тези проблеми са решими, но само ако регистърът има собственици и работни потоци.

Практически 30-дневен план за подобрение

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

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

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

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

Картографирайте доказателствата по ISO за всяко критично отношение. Свържете го със записи за активи, записи от оценка на риска, контроли в SoA, надлежна проверка на доставчици, прегледи на мониторинга, планове за непрекъсваемост, наръчници за инциденти и доказателства за стратегия за изход.

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

Използвайте този контролен списък, за да превърнете регистъра в работещ процес:

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

Тук 30-стъпковият метод за внедряване на Clarysec, наборът от политики и Zenith Controls работят заедно. Zenith Blueprint предоставя пътя за внедряване — от третиране на риска и проследимост на SoA в Step 13 до инвентар на активите в Step 22 и контроли за доставчици в Step 23. Политиките определят кой трябва да поддържа регистрите, какви договорни доказателства и доказателства за активи трябва да съществуват и как се улавят метаданните за съответствие. Zenith Controls предоставя компаса за съответствие между рамки при съпоставяне на едни и същи доказателства с одитните очаквания по DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST и COBIT 19.

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

Ако вашият Регистър на информацията по DORA все още е електронна таблица, откъсната от договори, активи, доставчици, подизпълнители и доказателства по ISO 27001, 2026 г. е годината да го поправите.

Започнете с Zenith Blueprint Zenith Blueprint, за да свържете третиране на риска, инвентар на активите и управление на доставчиците. Използвайте Zenith Controls Zenith Controls, за да картографирате контролите A.5.9, A.5.19 и A.5.20 от Приложение A на ISO/IEC 27001:2022 към доказателства за съответствие между рамки. След това приложете изискванията оперативно чрез политиките на Clarysec за доставчици, активи, облачни услуги, правно съответствие и одитен мониторинг, включително Политика за сигурност на трети страни и доставчици - МСП, Политика за управление на риска от зависимост към доставчици, Политика за сигурност на трети страни и доставчици, Политика за управление на активите - МСП, Политика за управление на активите, Политика за използване на облачни услуги - МСП, Политика за правно и регулаторно съответствие и Политика за одит и мониторинг на съответствието - МСП.

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