Рискът от трети страни по ОРЗД, NIS2 и DORA

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

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

Установете приложимостта, преди да комбинирате оценките

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

Член 28 от ОРЗД изисква администраторите да използват обработващи, които предоставят достатъчни гаранции. Споразумение по член 28 не е подходящо само защото доставчикът получава данни: първо установете действителната роля при обработването.

Членове 20–23 от NIS2 уреждат надзора от ръководството, мерките за управление на риска и докладването на значителни инциденти. NIS2 е директива, прилагана чрез националното право, затова обхватът и процедурите изискват проверки за конкретната юрисдикция.

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

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

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

Като практическа базова линия запишете:

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

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

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

Използвайте повторно доказателствата, без сляпо да използвате повторно заключенията

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

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

Поддържайте матрица, свързваща доказателствата с въпросите:

Сертификат по ISO или доклад SOC 2 подкрепя увереността в рамките на своя обхват; нито едното не доказва съответствие с ОРЗД или NIS2. Запазвайте мотивите на проверяващия, а не само качения документ. Оценката на увереността в сигурността трябва да бъде повторяем технически преглед, а не проверка на значки.

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

Съгласно член 28 от ОРЗД условията за обработващия трябва да уреждат предмета, срока, естеството и целта на обработването, вида на данните и категориите субекти. Те обхващат и документираните нареждания, поверителността, сигурността, условията за подизпълнители, съдействието, изтриването или връщането, както и задълженията за информация и одит. Международните предавания изискват отделна оценка по глава V; хостингът в ЕС сам по себе си не решава въпросите за достъпа или последващите предавания.

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

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

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

Проектирайте предаването при инциденти преди инцидента

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

Съгласно членове 33–34 от ОРЗД обработващият уведомява администратора без ненужно забавяне. Администраторът оценява уведомяването на надзорния орган без ненужно забавяне и, когато това е осъществимо, не по-късно от 72 часа след узнаването, освен ако не е вероятно нарушението да породи риск за правата и свободите на физическите лица. Високият риск може да изисква съобщаване на лицата, при спазване на изключенията. Запишете мотивите, когато уведомяване не се изисква.

Етапите на докладване на значителни инциденти по NIS2 на равнището на ЕС включват ранно предупреждение в рамките на 24 часа, уведомление в рамките на 72 часа и по правило окончателен доклад в рамките на един месец от уведомлението; проверете националните и секторните правила. DORA има собствена рамка за докладване на големи свързани с ИКТ инциденти. Не заменяйте тези оценки с един-единствен флаг „нарушение“ за доставчика.

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

Практически пример: една услуга, три пътя на преглед

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

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

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

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

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

Доказателствата се използват повторно, но нито едно от трите заключения не се извежда от друго. Успешно преминат преглед на сигурността не затваря пропуските в защитата на личните данни или устойчивостта.

Наблюдавайте промените, концентрацията и изпълнимото излизане

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

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

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

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

Започнете с една зависимост с последици

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

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