Удостоверения за заличаване на лични данни при прекратяване на отношения с обработващ лични данни

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

“Потвърждаваме, че всички данни, свързани с вашия акаунт, са изтрити от нашите продукционни системи.”

Имейлът беше учтив, бърз и почти безполезен.

В продължение на три години DataLeap беше обработвал клиентски идентификатори, данни за взаимодействия с кампании, атрибути за скоринг на потенциални клиенти, метаданни за съгласие и поведенчески анализи за хиляди клиенти в ЕС. FinSecure се подготвяше за одит по DORA, длъжностното лице по защита на данните (DPO) преглеждаше доказателства за отчетност по GDPR, а екипът по снабдяване искаше да закрие записа за доставчика преди следващия период на фактуриране. Имейлът отговаряше само на един тесен въпрос: продукционните данни. Той не казваше нищо за резервни копия, журнали, билети за поддръжка, работни пространства за анализи, кешове при подизпълнители по обработване, тестови копия, идентификационни данни за API или архивирани отчети.

Мария зададе въпроса, пред който всеки CISO, DPO и мениджър по съответствието рано или късно се изправя при прекратяване на SaaS услуга:

Къде е удостоверението за заличаване?

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

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

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

Защо прекратяването на отношения с обработващ лични данни се превърна във високорискова зона за съответствието

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

Точно тази фрагментация проверяват одиторите и регулаторите.

GDPR определя обработването широко, включително съхранение, заличаване и унищожаване. Той разграничава администраторите, които определят целите и средствата, от обработващите лични данни, които действат от името на администраторите. Article 5 установява принципи като ограничение на целите, минимизиране на данните, ограничение на съхранението, както и цялостност и поверителност. Article 5(2) добавя принципа на отчетност, което означава, че администраторът трябва да може да докаже съответствие. Article 28(3)(g) изисква договорите с обработващи лични данни да предвиждат, че по избор на администратора обработващият лични данни трябва да заличи или върне всички лични данни след приключване на услугата и да заличи съществуващите копия, освен ако законът не изисква съхранение.

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

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

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

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

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

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

Зрелият работен поток при прекратяване на отношения с обработващ лични данни отговаря на три въпроса:

1. Кои данни, системи и подизпълнители по обработване са в обхвата?
2. Какво действие по връщане, предаване, заличаване или унищожаване се изисква по закон и по договор?
3. Какви доказателства потвърждават, че действието е завършено преди закриването на изхода?

В Zenith Controls: ръководство за съответствие между рамки този сценарий е съпоставен с ISO/IEC 27002:2022 контрол 5.20, „Информационна сигурност в споразуменията с доставчици“; контрол 8.10, „Заличаване на информация“; и контрол 7.14, „Сигурно унищожаване или повторно използване на оборудване“. Това не са отделни точки от контролен списък. Прекратяването на отношения с обработващ лични данни свързва споразуменията с доставчици, управлението на жизнения цикъл на данните, извеждането от облачни услуги, отнемането на достъп, собствеността върху активи, съхранението на доказателства и готовността за одит.

Zenith Blueprint: 30-стъпкова пътна карта на одитора на Clarysec поставя това във фазата „Контроли в действие“. В стъпка 23, „Организационни контроли“, споразуменията с доставчици трябва да покриват разпоредби при прекратяване на договора, контроли върху подизпълнители, права на одит и протоколи за инциденти. Blueprint описва типичните области на споразуменията с доставчици като включващи:

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

Това изречение е мястото, където се срещат отчетността по GDPR, доказателствата в СУИП по ISO/IEC 27701:2025, очакванията за изход по DORA, сигурността на веригата на доставки по NIS2 и оперативният контрол по ISO/IEC 27001:2022.

Същият Zenith Blueprint, в стъпка 19, „Технологични контроли I“, обяснява риска от заличаване, който стои зад прекратяването на отношения с обработващ лични данни:

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

Стъпка 18, „Физически контроли II“, превежда очакването за доказателства в практически план:

„Когато се използва външен доставчик, изисквайте и съхранявайте сертификати за унищожаване като доказателства за одит.“

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

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

Защо „изтрито“ не е същото като доказано

Честа одитна констатация изглежда така:

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

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

Наборът от политики на Clarysec превръща „изтрито“ в изискване за доказателства.

Политиката за сигурност на трети страни и доставчици [P26] изисква в клауза 6.5.1.2:

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

След това клауза 6.5.1.3 изисква:

„Окончателна проверка на съответствието (напр. преглед на журналите, удостоверения за съответствие)“

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

За МСП Политиката за сигурност на трети страни и доставчици - МСП [P26S] предоставя практическа базова линия. Клауза 5.3.6 в „Изисквания за управление“ изисква:

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

Клауза 6.4.2.3 в „Изисквания за прилагане на политиката“ изисква доставчиците да:

„Потвърдят писмено, че данните са били сигурно заличени“

Политиката за съхранение на данни и унищожаване [P14] добавя изискването за доказателства в клауза 4.7.2:

„При поискване трябва да се предоставят документирани доказателства за съответствие (напр. журнали за заличаване, сертификати за унищожаване).“

За МСП Политиката за съхранение на данни и сигурно унищожаване - МСП изисква в клауза 6.2.3:

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

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

ISO/IEC 27701:2025: ролево базирани доказателства при изход

ISO/IEC 27701:2025 добавя слой за управление на поверителността към СУИС. Прекратяването на отношения с обработващ лични данни трябва да отразява ролята на организацията в СУИП. Администратор, който прекратява отношения с обработващ лични данни, има различни отговорности от обработващ лични данни, който прекратява отношения с подизпълнител по обработване. Обработващ лични данни, който действа по нареждания на клиента, трябва да документира, че е изпълнил тези нареждания. Обработващ лични данни в облачна среда трябва да покаже, че връщането, предаването, заличаването или унищожаването са извършени в договорения с клиента срок.

Наборът от политики на Clarysec за СУИП използва ролеви маркери, за да направи това оперативно приложимо. „Both“ се прилага независимо дали организацията е администратор или обработващ лични данни. „Processor“ се прилага при обработване на лични данни по документирани нареждания на администратора. „Subprocessor“ се прилага при ангажиране от друг обработващ лични данни.

Политиката за управление на поверителността при обработващи лични данни, подизпълнители по обработване и трети страни изисква в клауза 4.5.6:

„[Both] Собственикът на доставчика / отговорникът по снабдяване ТРЯБВА да получи доказателства за връщане, заличаване, унищожаване или преход в REG08 в срок до 30 дни след прекратяване на договора, изтичане на срока му, нареждане на клиента или одобрено събитие за изход, освен ако се прилага по-кратък договорен срок.“

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

„[Processor] Собственикът на доставчика / отговорникът по снабдяване ТРЯБВА да изпълни или потвърди насочено от клиента връщане, предаване, заличаване или унищожаване в REG08 до договорния срок или документираната дата на нареждането на клиента.“

Клауза 4.3.4 гласи:

„[Subprocessor] Собственикът на доставчика / отговорникът по снабдяване ТРЯБВА да получи доказателства от подизпълнител по обработване за връщане, заличаване или унищожаване в REG08 в рамките на договорния срок за доказателства след нареждане на клиента, приключване на услугата или прекратяване на подизпълнителя по обработване.“

Клауза 7.1.7 връща изискването към закриването:

„[Both] Собственикът на доставчика / отговорникът по снабдяване ТРЯБВА да получи доказателства от обработващ лични данни, подизпълнител по обработване или външна услуга за изискваните действия по връщане, предаване или окончателно действие в REG08 преди закриване на изхода от услугата.“

За облачни услуги Политиката за обработващ лични данни в облачна среда изисква в клауза 4.6.3:

„[Processor] Собственикът на системата / собственикът на приложението ТРЯБВА да завърши одобреното от клиента връщане, предаване, заличаване или унищожаване на лични данни в договорения с клиента срок и да регистрира доказателства за завършване в REG08 или REG12.“

Оперативното подобрение е незабавно. Не чакайте одит. Създайте изискването за доказателства при тригера за изход, възложете го на собственик, задайте срок и не допускайте закриване, докато REG08 или REG12 не бъде попълнен.

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

Удостоверението за заличаване не трябва да бъде неясен PDF с лого и едно изречение. То трябва да поддържа структуриран пакет с доказателства, който може да издържи на запитване по GDPR, одит на СУИП по ISO/IEC 27701:2025, надзорен одит по ISO/IEC 27001:2022, надзорно искане по DORA, клиентски преглед за уверение или вътрешен одит.

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

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

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

За облачни услуги корпоративната Политика за използване на облачни услуги изисква в клауза 5.4.4:

„Клаузи за прекратяване, които позволяват сигурно и проверимо извеждане“

За МСП Политиката за използване на облачни услуги - МСП изисква в клауза 6.3.5:

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

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

Примерна клауза: връщане, заличаване и доказателства за данни

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

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

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

Този текст превръща отчетността в оперативен резултат.

Практически пример: изход от SaaS услуга за заплати

Да разгледаме МСП, което преминава от PayrollCloud A към PayrollCloud B. PayrollCloud A е обработвал имена на служители, адреси, данъчни идентификатори, банкови данни, история на възнагражденията, записи за болнични и билети за поддръжка. Той е използвал доставчик на облачен хостинг и платформа за поддръжка като подизпълнители по обработване.

Изход, съобразен с Clarysec, би протекъл по следния начин.

1. Отворете билет за изход на доставчик

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

2. Съпоставете изхода с договора

Собственикът на доставчика проверява договора за клаузи за връщане, заличаване, одит, преход и подизпълнители по обработване. Ако договорът е слаб, собственикът все пак изпраща формално нареждане, изискващо връщане, заличаване и потвърждение от подизпълнители по обработване. Очакването за доказателства е закрепено в политиките на Clarysec, включително P26, P26S, P14, Политиката за използване на облачни услуги и Политиката за използване на облачни услуги - МСП.

3. Определете обхвата на личните данни

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

Това подпомага отчетността по GDPR, доказателствата в СУИП по ISO/IEC 27701:2025, оперативния контрол по ISO/IEC 27001:2022 и, за финансови субекти, очакванията за регистър на информацията за ИКТ услуги от трети страни по DORA.

4. Изискайте доказателства за връщане, заличаване и подизпълнители по обработване

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

5. Регистрирайте завършването в REG08 или REG12

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

6. Извършете окончателна проверка преди закриване

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

Едва тогава билетът за изход се закрива.

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

DORA, NIS2 и ИКТ устойчивост: доказателства при изход отвъд поверителността

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

Удостоверението за заличаване от обработващ лични данни може да засегне няколко въпроса по DORA:

• Непрекъсваемост на клиентските услуги
• Регулаторно докладване
• Цялостност на данните
• Реагиране при инциденти
• Права на одит
• Оперативна устойчивост
• Планиране на възстановяване и преход
• Управление на критична или важна функция

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

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

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

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

Стойността на добре проектирания работен поток при прекратяване на отношения с обработващ лични данни е, че той удовлетворява няколко рамки едновременно.

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

Какво ще попитат одиторите

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

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

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

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

Същият пакет с доказателства трябва да отговори на всички тези въпроси.

Чести модели на неуспех

Clarysec многократно вижда едни и същи слабости при прегледи на прекратяване на отношения с обработващи лични данни:

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

Сценарият с външна разработка е особено често срещан. Политиката за външна разработка - МСП изисква в клауза 7.4.1.2:

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

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

Контролен списък при прекратяване на отношения с обработващ лични данни

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

• Идентифицирайте тригера за изход: прекратяване, изтичане, нареждане на клиента, смяна на доставчик, реакция при нарушение, одобрен преход или прекратяване на подизпълнител по обработване.
• Потвърдете ролята в СУИП: администратор, обработващ лични данни, подизпълнител по обработване, съвместен администратор или обработващ лични данни в облачна среда.
• Свържете записа за доставчика: договор, собственик на услугата, бизнес функция, критичност и категории данни.
• Идентифицирайте обхвата на личните данни: продукционни данни, резервни копия, журнали, експорти, билети за поддръжка, анализи, тестови данни и подизпълнители по обработване.
• Издайте писмени нареждания: връщане, предаване, заличаване, унищожаване или изключение от срока за съхранение.
• Получете доказателства: удостоверение за заличаване, сертификат за унищожаване, журнали, удостоверение от подизпълнител по обработване и доказателство за закриване на достъп.
• Регистрирайте доказателствата в REG08 или REG12: местоположение на доказателствата, дата, метод, отговорно лице и преглеждащо лице.
• Проверете преди закриване: сравнете доказателствата с обхвата на данните, договора и нарежданията на клиента.
• Ескалирайте изключенията: липсващи доказателства, забавено изтичане на резервни копия, спорно съхранение, несътрудничещ доставчик или остатъчен достъп.
• Подайте вход към подобрение: актуализирайте шаблоните на договори, рисковата оценка на доставчика, графика за сроковете за съхранение, плана за одит и докладването към ръководството.

Така Zenith Blueprint, Zenith Controls и наборът от политики на Clarysec работят заедно. Blueprint показва къде принадлежи контролът в пътя на внедряване. Политиките определят изискваното поведение. Zenith Controls съпоставя контролната връзка между ISO/IEC 27002:2022, GDPR, DORA, NIS2, NIST и одиторските очаквания.

Посланието към управителния съвет

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

Удостоверението за заличаване е ценно само когато е свързано с:

• Известно взаимоотношение с доставчик
• Определен обхват на данните
• Договорно или клиентско нареждане
• Сигурен метод за заличаване или унищожаване
• Доказателства за прехвърляне на задълженията към подизпълнители по обработване надолу по веригата
• Закриване на достъп
• Третиране на резервни копия и архиви
• Контролиран регистър на доказателствата
• Окончателна проверка на съответствието

Без тази верига организацията разчита на доверие точно в момента, в който трябва да разчита на доказателства.

Следващи стъпки с Clarysec

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

Clarysec може да ви помогне да внедрите практичен модел за прекратяване на отношения с обработващ лични данни, готов за одит, чрез:

• Zenith Blueprint: 30-стъпкова пътна карта на одитора, за да поставите изхода на доставчика, заличаването и унищожаването в правилните стъпки на внедряване.
• Zenith Controls: ръководство за съответствие между рамки, за да съпоставите споразуменията с доставчици, заличаването на информация и сигурното унищожаване в ISO/IEC 27002:2022, GDPR, DORA, NIS2, NIST и одиторските очаквания.
• Политика за управление на поверителността при обработващи лични данни, подизпълнители по обработване и трети страни и Политика за съхранение, заличаване и унищожаване на лични данни, за да операционализирате доказателствата в REG08.
• Политика за сигурност на трети страни и доставчици, Политика за съхранение на данни и унищожаване и Политика за обработващ лични данни в облачна среда, за да направите доказателствата при изход приложими.

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

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