DORA стратегии за изход от ИКТ доставчици с контроли по ISO 27001

В 07:42 в понеделник ръководителят на операциите във финтех компания получава съобщението, което никой не иска да прочете: облачният доставчик за мониторинг на трансакции е претърпял сериозно регионално прекъсване. В 08:15 директорът по управление на риска пита дали засегнатата услуга поддържа критична или важна функция. В 08:40 правният отдел иска да знае дали договорът предоставя на дружеството съдействие при преход, експорт на данни, изтриване и права на одит. В 09:05 директорът по информационна сигурност търси доказателства, че планът за изход е бил тестван, а не само написан.

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

Мисълта ѝ веднага се насочва към основния доставчик на облачни услуги, който хоства платформата, после към доставчика на управлявани услуги за сигурност, който наблюдава заплахите денонощно. Какво ако доставчикът на облачни услуги претърпи геополитически обусловено прекъсване? Какво ако доставчикът на управлявани услуги за сигурност (MSSP) бъде придобит от конкурент? Какво ако критичен SaaS доставчик стане неплатежоспособен, прекрати услугата или загуби доверието на клиентите след сериозен инцидент?

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

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

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

Подходът на Clarysec комбинира Zenith Blueprint: 30-стъпкова пътна карта за одитори Zenith Blueprint, шаблони за корпоративни политики и Zenith Controls: ръководство за кръстосано съответствие Zenith Controls, за да превърне въпроса от понеделник сутрин в подготвен отговор.

Защо DORA стратегиите за изход се провалят при реални одити

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

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

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

Малка финтех компания не може да каже: „Твърде малки сме за планиране на изход.“ Може да каже: „Нашата DORA стратегия за изход е съобразена с размера, рисковия ни профил и сложността на услугите.“ Разликата е в доказателствата.

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

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

Включете стратегията за изход в СУСИ

ISO/IEC 27001:2022 предоставя управленската основа за планиране на изход по DORA.

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

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

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

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

ISO/IEC 27005:2022 укрепва този подход. Клауза 6.2 препоръчва организациите да идентифицират изискванията на заинтересованите страни, включително контроли от ISO/IEC 27001:2022 Приложение A, секторно специфични стандарти, национални и международни регулации, вътрешни правила, договорни изисквания и съществуващи контроли от предходно третиране на риска. Клаузи 6.4.1 до 6.4.3 обясняват, че критериите за риска трябва да отчитат правни и регулаторни аспекти, взаимоотношения с доставчици, поверителност, оперативни въздействия, нарушения на договор, операции на трети страни и репутационни последици. Клаузи 8.2 до 8.6 подпомагат библиотека с контроли и план за третиране, които могат да комбинират ISO/IEC 27001:2022 Приложение A с DORA, NIS2, GDPR, клиентски ангажименти и вътрешни политики.

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

Контролите по ISO/IEC 27001:2022, които закрепват планирането на изход по DORA

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

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

За DORA стратегия за изход от доставчик на ИКТ услуги от трета страна одитната следа трябва да показва:

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

Договорният език е първият контрол за непрекъсваемост

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

В Zenith Blueprint, фазата „Контролите в действие“, Step 23, Control 5.20, се обяснява, че споразуменията с доставчици трябва да включват практическите изисквания за сигурност, които правят изхода възможен:

Основните области, които обичайно се обхващат в споразуменията с доставчици, включват:

✓ Задължения за поверителност, включително обхват, срок и ограничения за разкриване пред трети страни;

✓ Отговорности за контрол на достъпа, като например кой може да има достъп до вашите данни, как се управляват удостоверителните данни и какъв мониторинг е въведен;

✓ Технически и организационни мерки за защита на данните, шифроване, сигурно предаване, резервно копиране и ангажименти за наличност;

✓ Срокове и протоколи за докладване на инциденти, често с определени времеви рамки;

✓ Право на одит, включително честота, обхват и достъп до релевантни доказателства;

✓ Контроли за подизпълнители, които изискват доставчикът да прехвърли еквивалентни задължения за сигурност към своите партньори надолу по веригата;

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

Този списък свързва договорните очаквания по член 30 от DORA с контрола A.5.20 от ISO/IEC 27001:2022 Приложение A.

Езикът в корпоративните политики на Clarysec прави същия въпрос оперативен. В Политика за управление на риска от зависимост от доставчици Политика за управление на риска от зависимост от доставчици, раздел „Изисквания за внедряване“, клауза 6.4.3 гласи:

Технически резервни варианти: Осигурете преносимост и оперативна съвместимост на данните, за да се подпомогне преходът на услугата при необходимост (напр. регулярни резервни копия в стандартни формати от SaaS доставчик, които позволяват миграция).

Същата политика, клауза 6.8.2, изисква:

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

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

За по-малки субекти Политика за сигурност на трети страни и доставчици - SME Политика за сигурност на трети страни и доставчици - SME, раздел „Изисквания за управление“, клауза 5.3.6, изисква:

Условия за прекратяване, включително сигурно връщане или унищожаване на данни

За корпоративни среди Политика за сигурност на трети страни и доставчици Политика за сигурност на трети страни и доставчици, раздел „Изисквания за прилагане на политиката“, клауза 6.5.1.2 изисква:

Връщане или сертифицирано унищожаване на цялата информация, притежавана от организацията

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

Изход от облачни услуги: тествайте преносимостта, преди да ви потрябва

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

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

Политика за използване на облачни услуги - SME на Clarysec Политика за използване на облачни услуги - SME, раздел „Изисквания за прилагане на политиката“, клауза 6.3.4 изисква:

Потвърдена възможност за експорт на данни преди въвеждане (напр. за избягване на зависимост от доставчик)

Клауза 6.3.5 изисква:

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

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

Практическият тест за изход от облачна услуга по DORA трябва да включва:

1. Експорт на представителен набор от данни в договорения формат.
2. Валидиране на пълнота, цялостност, времеви маркери, метаданни и контроли за достъп.
3. Импорт на набора от данни в тестова среда или алтернативен инструмент.
4. Потвърждение на управлението на ключове за шифроване и ротацията на тайни.
5. Потвърждение на експорта на журнали и съхранението на одитната следа.
6. Документиране на процедурите на доставчика за изтриване, включително съхранение на резервни копия и сертифициране на изтриването.
7. Записване на проблеми, коригиращи действия, собственици и крайни срокове.
8. Актуализиране на оценката на риска, свързан с доставчици, Декларацията за приложимост и плана за изход.

Преносимостта не е обещание в процеса на набавяне. Тя е тествана способност.

Едноседмичен спринт за DORA план за изход, готов за одит

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

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

Ден 1: класифицирайте доставчика и дефинирайте сценария за изход

Използвайки Zenith Blueprint, фазата „Контролите в действие“, Step 23, Action Items for Controls 5.19 to 5.37, екипът започва с преглед и класификация на портфейла от доставчици:

Съставете пълен списък на текущите доставчици и доставчици на услуги (5.19) и ги класифицирайте според достъпа до системи, данни или оперативен контрол. За всеки класифициран доставчик проверете дали очакванията за сигурност са ясно включени в договорите (5.20), включително поверителност, достъп, докладване на инциденти и задължения по съответствие.

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

Екипът дефинира три тригера за изход:

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

Ден 2: изградете инвентар на изискванията и запис на риска

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

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

Записът на риска включва следното:

Ден 3: отстранете пропуските в договора

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

Политика за непрекъсваемост на дейността и аварийно възстановяване Политика за непрекъсваемост на дейността и аварийно възстановяване, раздел „Изисквания за прилагане на политиката“, клауза 6.5.1 гласи:

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

За SME Политика за непрекъсваемост на дейността и аварийно възстановяване - SME Политика за непрекъсваемост на дейността и аварийно възстановяване - SME, раздел „Третиране на риска и изключения“, клауза 7.2.1.4 изисква екипите да:

документират планове за временно заместване на доставчик или партньор

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

Ден 4: тествайте преносимостта на данните и възстановимостта от резервни копия

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

Политика за архивиране и възстановяване - SME Политика за архивиране и възстановяване - SME, раздел „Изисквания за управление“, клауза 5.3.3 изисква:

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

Корпоративната Политика за архивиране и възстановяване Политика за архивиране и възстановяване, раздел „Прилагане и съответствие“, клауза 8.3.1 добавя:

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

В Zenith Blueprint, фазата „Контролите в действие“, Step 19, Control 8.13, Clarysec предупреждава защо това е важно:

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

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

Ден 5: проведете сценарийно упражнение за изход и преглед на доказателствата

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

В Zenith Blueprint, фазата „Контролите в действие“, Step 23, Control 5.30, Clarysec обяснява стандарта за теста:

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

Същият раздел добавя:

Целевите стойности за време за възстановяване (RTO) и целевите точки за възстановяване (RPO), дефинирани в плана за непрекъсваемост на дейността, трябва да бъдат отразени в техническите конфигурации, договорите и дизайна на инфраструктурата.

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

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

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

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

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

Zenith Controls на Clarysec помага на екипите да се подготвят за тези одитни перспективи, като свързва контролите по ISO/IEC 27001:2022 с одитни доказателства и очаквания от различни рамки.

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

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

Контролен списък на Clarysec за DORA стратегия за изход

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

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

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

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

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

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