Управление на споразуменията за споделяне на данни по GDPR и ISO 27701

Във вторник в 16:00 Сара, CISO в бързо растяща FinTech компания, преглежда споразумение за споделяне на данни от стратегически партньор за AI анализи. Търговският екип е ентусиазиран. Партньорът обещава по-добро разбиране на клиентите, по-силна персонализация и по-бързо прогнозиране на отлив на клиенти. Правният екип е предпазлив. Споразумението е пълно с неясни формулировки като „търговски разумна сигурност“ и почти не съдържа конкретика за срокове за реакция при инциденти, обработване на искания за упражняване на права от субектите на данни, съхранение, изтриване, права на одит или планиране при прекратяване.

Сара вижда риска веднага. Партньорът действа ли като обработващ лични данни, самостоятелен администратор или съвместен администратор? Кой валидира правното основание по GDPR? Ако клиент подаде искане за изтриване, кой процес гарантира, че данните ще бъдат изтрити от средата на партньора, производните набори от данни и, когато е приложимо, пайплайните за обучение на AI? Ако при партньора възникне нарушение на сигурността, кой кого уведомява, кога и с какви доказателства?

Това не е просто един лош договор. Това е отказ на оперативния модел.

Съвременните SaaS, FinTech, healthtech, managed service и платформени бизнеси постоянно споделят данни чрез приложно-програмни интерфейси (API), интеграции, аналитични партньорства, инструменти за поддръжка, облачни платформи, свързани дружества, искания от публичния сектор и AI услуги. Търговските договорености често се движат по-бързо от управлението. Договорът се подписва, API ключът се издава и личните данни започват да се предават, преди екипите по поверителност, сигурност, снабдяване, инженеринг и длъжностното лице по защита на данните (DPO) да са постигнали съгласие по основните въпроси.

По GDPR споразумението за споделяне на данни не е само правен артефакт. То е доказателство за законосъобразност, добросъвестност, прозрачност, ограничение на целите, свеждане на данните до минимум, ограничение на съхранението, цялостност, поверителност и отчетност. По ISO/IEC 27701:2025 то става част от система за управление на информацията за поверителност, или PIMS, чрез която организацията може да докаже, че личната информация се събира, използва, разкрива, споделя, съхранява, защитава и унищожава чрез управлявани процеси.

Clarysec разглежда управлението на споделянето на данни като междуфункционална система от контроли, а не като упражнение по попълване на договорен шаблон. Чрез Zenith Blueprint, Zenith Controls и набора от PIMS политики на Clarysec организациите могат да преминат от ad hoc преглед на споразумения към готов за одит жизнен цикъл, който свързва правни клаузи, регистри, решения по риска, технически контроли и доказателства за съответствие.

Защо споразуменията за споделяне на данни се провалят при реални одити

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

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

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

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

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

Zenith Blueprint, фазата Controls in Action, стъпка 23, формулира ясно одитната истина:

Основата на този контрол е осведомеността за данните. Организацията трябва да знае какви лични данни (PII) събира, къде се намират, защо се обработват и кой има достъп до тях. Без този базов набор всяко обещание за поверителност е кухо. Класификацията и етикетирането (5.12–5.13) стават съществени тук, защото личните данни (PII) не могат да бъдат защитени, ако не са идентифицирани.

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

Споделянето на данни не е същото като обработване от името на клиент

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

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

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

PIMS политиките на Clarysec превръщат тази класификация в задължителна контролна точка. Enterprise Processor, Subprocessor and Third-Party Privacy Management Policy посочва:

[И двете роли] Ръководителят по поверителността / мениджърът на PIMS ТРЯБВА да класифицира всяко взаимоотношение с трета страна във връзка с поверителността като администратор, съвместен администратор, обработващ лични данни, подизпълнител по обработване или друго взаимоотношение с трета страна в REG08 преди одобряване на договора или преди да започне обработването на лични данни (PII), което от двете настъпи по-рано.

За МСП същият принцип е изразен по-просто. Data Protection and Privacy Policy - SME, Governance Requirements 5.2.2, изисква:

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

Практическият извод е ясен: преди изготвянето на клаузи класифицирайте взаимоотношението. Ролята определя споразумението, одобренията, предпазните мерки, отговорностите и доказателствата.

Жизнен цикъл на управлението на споделянето на данни

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

Enterprise PII Collection, Use, Disclosure and Sharing Policy прави изискването от страна на администратора изрично:

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

REG08 е регистърът на получателите и взаимоотношенията с трети страни във връзка с поверителността. Той не трябва да съществува отделно от инвентара на дейностите по обработване. Enterprise PII Processing Inventory and Lawful Basis Policy изисква:

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

Това затваря често срещан одитен пропуск. REG02 може да посочва „продуктова аналитика за вътрешно подобрение“, докато REG08 посочва „аналитичен партньор за бенчмаркинг“. Ако целта, получателят, правното основание, категориите данни или правилата за съхранение не са съгласувани, организацията има дефект в отчетността.

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

Споразумението за споделяне на данни по GDPR и ISO 27701:2025 не трябва да разчита на общи клаузи за поверителност. То трябва да отразява реалния поток на данни, класификацията на ролите, рисковия профил и оперативните интерфейси.

Zenith Blueprint, фазата Controls in Action, стъпка 23, дава гледната точка на споразуменията с доставчици:

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

✓ Задължения за поверителност, включително обхват, срок и ограничения за разкриване пред трети страни; ✓ Отговорности за контрол на достъпа, като кой може да има достъп до вашите данни, как се управляват удостоверителните данни и какъв мониторинг се прилага; ✓ Технически и организационни мерки за защита на данните, криптиране, сигурно предаване, резервно копиране и ангажименти за наличност; ✓ Срокове и протоколи за докладване на инциденти, често с определени времеви рамки (напр. „уведомяване в рамките на 24 часа“); ✓ Права на одит, включително честота, обхват и достъп до релевантни доказателства (напр. доклади от тестове за проникване, SoA, сертификации); ✓ Контроли за подизпълнители, изискващи доставчикът да прехвърли еквивалентни задължения за сигурност към своите партньори надолу по веригата; ✓ Разпоредби при изтичане на договора, като връщане или унищожаване на данни, възстановяване на активи и деактивиране на акаунти.

Корпоративното правно управление засилва този извод. Legal and Regulatory Compliance Policy, Governance Requirements 5.3.1.2, идентифицира договори, включващи:

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

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

Класификацията и сигурното предаване са липсващият мост

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

Политиката на Clarysec Data Classification and Labeling Policy - SME посочва:

Споразуменията за споделяне на данни или споразуменията за неразкриване на информация (NDA) трябва да препращат към изискванията за боравене с данните според класификацията.

За корпоративни среди Data Classification and Labeling Policy изисква определени данни:

Могат да се споделят външно само по NDA или при еквивалентни договорни предпазни мерки.

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

Zenith Blueprint, фазата Controls in Action, стъпка 22, обяснява оперативната страна на предаването на информация:

В своята същност този контрол изисква организацията да:

✓ Определи как може да се предава информация — както вътрешно, така и външно; ✓ Определи кои методи са разрешени (напр. криптирана електронна поща, защитени портали, SFTP, приложно-програмни интерфейси (API), физическо предаване с криптиране); ✓ Съгласува методите за предаване с класификацията на информацията (както е определена в 5.12 и визуализирана чрез 5.13); ✓ И гарантира, че всички страни, участващи в предаването, разбират своите роли, отговорности и задължения.

За МСП Third-Party and Supplier Security Policy - SME формулира очакването директно:

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

Корпоративното управление на доставчиците добавя повече детайли. Third party and supplier security policy изисква изисквания за боравене с данните, включително:

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

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

Пример: одобряване на партньора на Сара за AI анализи

FinTech компанията на Сара иска да споделя псевдонимизирани клиентски идентификатори, модели на транзакции, показатели за използване и информация за ниво на поддръжка с партньор за AI анализи за персонализация и прогнозиране на отлив на клиенти. Партньорът може да комбинира данните със своите аналитични модели и да предоставя прозрения обратно на FinTech компанията.

Управляваният работен поток би изглеждал така.

Първо, собственикът „Доставчици“ или „Снабдяване“ създава запис в REG08. Ръководителят по поверителността или мениджърът на PIMS класифицира взаимоотношението. Ако партньорът определя аналитичните цели и дизайна на модела извън указанията на Сара, ролята може да бъде самостоятелен администратор или съвместен администратор, а не обработващ лични данни.

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

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

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

Пето, уведомлението за поверителност и работният поток за DSR се актуализират. Enterprise PII Principal Rights Management Policy изисква:

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

За МСП Data Protection and Privacy Policy - SME дава практическо очакване за ниво на обслужване:

Координаторът по поверителност трябва да потвърди получаването на исканията в рамките на 3 работни дни и да отговори в рамките на 30 дни.

Накрая инженерният екип прилага споразумението. Обхватът на API удостоверителните данни се ограничава. Предаванията използват HTTPS. Журналите записват извличанията на данни. Предупрежденията откриват необичайна дейност. Достъпът се преглежда. Съхранението се автоматизира, когато е възможно. Споразумението се превръща в жива система от контроли, а не в PDF файл.

Съпоставяне на изискванията за съответствие между GDPR, ISO 27701, DORA, NIS2, NIST и COBIT 19

Управлението на споделянето на данни рядко принадлежи само на една рамка. То засяга отчетността по GDPR, операциите по поверителност по ISO/IEC 27701:2025, изискванията към системата за управление по ISO/IEC 27001:2022, контролите за сигурност по ISO/IEC 27002:2022, риска от трети страни по DORA, сигурността на веригата на доставки по NIS2, резултатите по NIST CSF 2.0 и управленските очаквания по COBIT 19.

ISO/IEC 27001:2022 клауза 4.2 изисква организациите да разбират заинтересованите страни и техните релевантни изисквания. Клауза 5.1 изисква ръководството да интегрира изискванията за информационна сигурност в бизнес процесите. За споделянето на данни това означава, че зависимостите от партньори, договорните изисквания, регулаторните задължения и решенията по риска трябва да бъдат вътре в ISMS и PIMS, а не извън тях.

Най-релевантните контроли от ISO/IEC 27002:2022 са:

• 5.14 Information transfer
• 5.20 Addressing information security within supplier agreements
• 5.34 Privacy and protection of PII

Zenith Controls помага на организациите да използват тези контроли като опорни точки за съпоставяне. Той свързва ISO/IEC 27002:2022 контрол 5.14 със защитата на данните при пренос и договорните изисквания, включително NIST CSF 2.0 PR.DS-02 и GV.SC-05, DORA Article 30(2)(d) и GDPR Article 46, когато предпазните мерки при международни предавания са релевантни. Той свързва контрол 5.20 с управлението на споразуменията с доставчици, включително NIS2 Article 21(2)(d) за сигурност на веригата на доставки и DORA Chapter V относно ИКТ риска от трети страни. Той свързва контрол 5.34 с поверителността и защитата на лични данни (PII), включително отчетността по GDPR Article 5(2) и поддържащи контроли като криптиране, изтриване, управление на доставчици и ограничение на целите.

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

Как одиторите ще тестват вашите споразумения за споделяне на данни

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

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

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

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

Оценител по NIST CSF 2.0 ще търси резултати GOVERN в управлението на риска от доставчици, резултати PROTECT в контролите за данни при пренос, резултати RESPOND в интерфейсите за инциденти и резултати RECOVER в планирането за прекратяване и непрекъснатост.

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

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

Често срещани пропуски в управлението на споделянето на данни

Clarysec многократно вижда пет модела на неуспех.

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

Вторият е слабата дисциплина при поддържане на регистрите. REG02 и REG08 си противоречат. Уведомлението за поверителност се позовава общо на „бизнес партньори“, но в инвентара на дейностите по обработване няма съответстваща цел на разкриване.

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

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

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

Processor, Subprocessor and Third-Party Privacy Management Policy улавя оперативната връзка при взаимоотношения с обработващи лични данни и подизпълнители по обработване:

[И двете роли] Собственикът „Доставчици / Снабдяване“ ТРЯБВА да гарантира, че договорите с обработващи лични данни и подизпълнители по обработване включват съдействие по поверителност, уверение за сигурността, интерфейс за инциденти чрез PII15, връщане или изтриване чрез PII10, връзка с предаването чрез PII13 и сътрудничество при одит или уверение преди одобрение.

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

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

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

• Потвърдете ролята на получателя от гледна точка на поверителността в REG08.
• Потвърдете, че REG02 и REG08 са съгласувани преди одобрение.
• Документирайте целта на разкриването и правното основание.
• Проверете дали нова цел изисква оценка за съвместимост.
• Идентифицирайте категориите лични данни (PII), категориите субекти на данни и специалните категории данни.
• Приложете свеждане на данните до минимум и премахнете ненужните полета.
• Посочете в споразумението изискванията за боравене според класификацията.
• Определете одобрени методи за предаване и изисквания за криптиране.
• Конкретизирайте очакванията за контрол на достъпа, журнализиране, мониторинг и местоположение на съхранение.
• Разпределете отговорностите за прозрачност и актуализации на уведомлението за поверителност.
• Определете маршрутизиране на DSR, потвърждение за получаване, проследяване и доказателства за приключване.
• Определете доказателства за съхранение, изтриване, връщане и прекратяване.
• Ограничете последващото разкриване и изисквайте уведомяване при промяна.
• Включете срокове за уведомяване при инциденти и изисквания за сътрудничество.
• Включете права за одит, уверение или преглед на доказателства.
• Планирайте периодичен преглед и тригери за повторна оценка.

Къде се вписва Clarysec

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

Zenith Blueprint дава на екипите по внедряване 30-стъпкова пътна карта за превръщане на изискванията за контрол в работещи практики. За споделянето на данни стъпка 22 помага на екипите да проектират правила за предаване на информация, а стъпка 23 свързва поверителността, споразуменията с доставчици, правните изисквания, защитата на лични данни (PII) и договорните задължения.

Zenith Controls предоставя компаса за съпоставяне на изискванията за съответствие между рамки. За тази тема той свързва ISO/IEC 27002:2022 контроли 5.34, 5.14 и 5.20 с по-широката одитна картина: защита на поверителността, предаване на информация и управление на споразуменията с доставчици. Той помага на CISO, DPO, мениджъри по съответствието, екипи по снабдяване и одитори да говорят на един език при съпоставяне на очакванията по GDPR, ISO/IEC 27701:2025, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 и COBIT 19.

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

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

Използвайте Zenith Blueprint: An Auditor’s 30-Step Roadmap, за да поставите споделянето на данни във вашия план за внедряване на ISMS и PIMS. Използвайте Zenith Controls: The Cross-Compliance Guide, за да съпоставите ISO/IEC 27002:2022 контроли 5.34, 5.14 и 5.20 спрямо очакванията за уверение по GDPR, NIS2, DORA, NIST и COBIT. След това внедрете PIMS политиките на Clarysec, включително PII Collection, Use, Disclosure and Sharing Policy, PII Processing Inventory and Lawful Basis Policy и Processor, Subprocessor and Third-Party Privacy Management Policy, така че всяко споразумение да бъде подкрепено с регистри, работни потоци, предпазни мерки и доказателства.

Практическото следващо действие е просто: изберете трите си най-високорискови външни взаимоотношения за споделяне на данни и ги тествайте спрямо REG02, REG08, правното основание, маршрутизирането на DSR, контролите при предаване, съхранението и доказателствата за одит. Ако доказателствената верига се прекъсне, Clarysec може да ви помогне да я изградите отново като готов за одит модел за управление на споделянето на данни.