Управление на съвместните администратори: ръководство за одит на Article 26 от GDPR

Обаждането дойде във вторник сутрин. За CISO на CareConnect, бързо разрастващ се доставчик на MedTech SaaS, това беше моментът, в който ситуацията рязко се промени.

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

След това правният отдел препрати второ съобщение. Младши разработчик в CareConnect беше изложил по невнимание некритична API крайна точка, съдържаща ограничен набор от идентификатори на пациенти. Проблемът изглеждаше управляем и 72-часовият срок по GDPR за уведомяване при нарушение все още не беше изтекъл. Но един и същ въпрос блокираше и двата екипа.

Кой уведомява надзорния орган? Кой комуникира с пациентите? Кой отговаря за уведомлението за поверителност? Кой валидира искането на субекта на данни? Кой записва решението?

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

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

GDPR определя задължението. ISO/IEC 27701:2025 дава на екипите по поверителност структура на система за управление. Политиките на Clarysec за СУНЛИ, Zenith Blueprint: 30-стъпкова пътна карта за одитора и Zenith Controls: ръководство за съответствие между рамки превръщат Article 26 в оперативни доказателства, готови за одит.

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

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

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

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

Практическите провали са предвидими:

1. Уведомлението за поверителност казва малко повече от „можем да споделяме данни с партньори“.
2. Инвентарът на дейностите по обработване идентифицира страните, но не и разпределението на задълженията.
3. Работният поток за права на субектите на данни няма маршрут за приемане, препращане, валидиране или отговаряне на искания.
4. Планът за инциденти казва „уведоми правния отдел“, но не посочва кой съвместен администратор води външната комуникация.
5. Договорът се третира като търговска документация, а не като доказателство за отчетност.
6. Разпоредбите за прекратяване не обхващат връщането на данни, изтриването, анонимизацията, отнемането на достъп или запазването на доказателства.

GDPR Article 5 прави тези провали чувствителни от гледна точка на одита, защото администраторите трябва не само да спазват принципи като законосъобразност, добросъвестност, прозрачност, ограничение на целите, свеждане на данните до минимум, точност, ограничение на съхранението, цялостност, поверителност и отчетност. Те трябва да могат да докажат съответствие. Article 6 добавя изискването за правно основание. Article 3 може да включи в обхвата доставчици на SaaS, fintech, health-tech и аналитични услуги извън ЕС, когато предлагат услуги на физически лица в ЕС или наблюдават тяхното поведение.

Изводът за CISO и мениджърите по съответствието е пряк: управлението на съвместни администратори не е „само правен въпрос“. То е междуфункционална контролна система, която включва поверителност, сигурност, снабдяване, продуктови екипи, инженеринг, поддръжка, реагиране при инциденти, маркетинг и надзор от висшето ръководство.

Принципът на СУНЛИ по ISO/IEC 27701:2025: решете преди началото на обработването

Система за управление на неприкосновеността на личната информация по ISO/IEC 27701:2025 работи само ако ролите по поверителността са определени преди началото на обработването. Това е оперативната дисциплина, която не позволява Article 26 да се превърне във възстановяване на фактите след инцидент.

Политиката за система за управление на неприкосновеността на личната информация на Clarysec, клауза 4.2.2, гласи:

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

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

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

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

Заедно тези клаузи създават доказателствената верига, която одиторите очакват:

• REG02 документира дейността по обработване, целта, категориите данни, правното основание, сроковете за съхранение, системите, получателите, предаването на данни и препратката към съвместния администратор.
• REG08 документира споразумението между съвместните администратори и разпределението на отговорностите.
• REG07 документира публично достъпното резюме за прозрачност.
• REG06 може да документира приемането, маршрутизирането, валидирането, сроковете и доказателствата за отговор при искания за упражняване на права.
• REG10 документира решенията при оценка на инциденти и нарушения.

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

Започнете с обхват, заинтересовани страни и RACI

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

В етапа „Основи и лидерство на ISMS“, стъпка 2, Потребности на заинтересованите страни и обхват на ISMS, Zenith Blueprint препоръчва анализ на заинтересованите страни, който обхваща явни и подразбиращи се изисквания:

Как да се идентифицират потребностите и очакванията: За всяка идентифицирана група заинтересовани страни посочете какво
изискват по отношение на информационната сигурност. Някои изисквания са явни (закони, договори,
SLA), а други са подразбиращи се (очаквания или общи добри практики). Полезно е да:

✓ Прегледате правните и регулаторните изисквания, приложими към вашия контекст (от анализа на
контекста в стъпка 1). Съставете списък на конкретни клаузи или задължения, свързани с информационната
сигурност или поверителността.
✓ Прегледате договорите и споразуменията: много бизнес договори съдържат приложения за поверителност или
сигурност. Извлечете тези изисквания.
✓ Проведете интервюта или работни срещи със заинтересовани страни: ангажирайте представители на
всяка група (например мениджър ЧР за гледната точка на служителите, мениджър продажби за клиентските
очаквания), за да разберете техните опасения или потребности.
✓ Вземете предвид индустриални стандарти или кодекси за практика, които заинтересованите страни очакват да
спазвате.

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

Стъпка 4, Роли и отговорности в ISMS, след това превръща този анализ в собственост. Zenith Blueprint подчертава стойността на RACI модел:

✓ Отчетност срещу отговорност: полезен инструмент тук е RACI матрица (Responsible,
Accountable, Consulted, Informed). За всеки основен процес или контрол в ISMS идентифицирайте
кой е Responsible (извършва работата), кой е Accountable (носи крайната отчетност, често
мениджър), кой е Consulted (предоставя входна информация) и кой е Informed.

За съвместните администратори RACI на практика не е опционален. Без него правният отдел приема, че екипът по поверителност отговаря на искането, екипът по поверителност приема, че поддръжката управлява опашката за приемане, поддръжката приема, че партньорът ще отговори, а законоустановеният срок продължава да тече.

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

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

Политиките на Clarysec за поверителност укрепват всеки слой.

Политиката за уведомления за поверителност и прозрачност, клауза 4.1.5, гласи:

[Съвместен администратор] Ръководителят по поверителността / мениджърът на СУНЛИ ТРЯБВА да запише публично достъпното резюме на отговорностите на съвместните администратори и точката за контакт в REG07 преди обработването от съвместни администратори да бъде стартирано или съществено променено.

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

[Съвместен администратор] Ръководителят по поверителността / мениджърът на СУНЛИ ТРЯБВА да документира отговорностите за обработване на права и маршрутите за контакт в REG02, REG06 или REG08 преди началото на обработването от съвместни администратори.

Политиката за управление на инциденти и нарушения с лични данни, клауза 4.2.5, добавя:

[Съвместен администратор] Ръководителят по поверителността / мениджърът на СУНЛИ ТРЯБВА да провери договорената отговорност при нарушение, водещата отговорност за комуникация и координационния механизъм преди всяко външно уведомяване или комуникация от съвместен администратор и ТРЯБВА да запише решението в REG08 и REG10.

Това е моментът, в който ISO/IEC 27701:2025 и GDPR стават оперативни. Организацията не само заявява, че отговорностите са разпределени. Тя показва къде са записани, кой ги е одобрил, кога са тествани и как се използват.

Практически пример: REG08 за платформа за отдалечен мониторинг

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

Първо, REG02 трябва да документира дейността по обработване:

• Наименование на обработването: услуга за отдалечен мониторинг на пациенти
• Роля на администратора: съвместен администратор
• Страни: CareConnect и MetroHealth
• Цел: мониторинг на пациенти, координация на грижите, подобрение на услугата, платформена аналитика
• Категории PII: данни за контакт, идентификатори на акаунти, клинични наблюдения, събития от устройства, взаимодействия с поддръжката
• Проверка за специална категория: обработват се здравни данни и са необходими засилени защитни мерки
• Правно основание: документирано по страна и цел
• Срок за съхранение: определен според клинични, платформени, правни и оперативни изисквания
• Системи: мобилно приложение, платформа за мониторинг, инструмент за поддръжка, аналитично хранилище, доставчик на идентичност
• Получатели: страните съвместни администратори, хостинг доставчик, доставчици на поддръжка, доставчици на уведомления
• Предаване на данни: оценени са отдалечен достъп и обработване извън ЕИП
• Препратка към REG08: JC-2026-004

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

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

Четвърто, тествайте работния поток преди стартиране. Изпратете симулирано искане за достъп до публикуваната точка за контакт. Потвърдете, че поддръжката го идентифицира като искане за права на субект на данни, насочва го към екипа по поверителност, проверява REG08, изисква входна информация от партньора, записва действията в REG06 и изготвя пакет за отговор. След това проведете настолно упражнение за нарушение със сценарий като „API крайна точка излага идентификатори на пациенти на неразрешени потребители“ или „потребители със спряно изтриване са включени по погрешка в кампания за ангажиране“.

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

Картографирайте Article 26 към контролите на ISO/IEC 27002:2022 чрез Zenith Controls

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

Три контрола от ISO/IEC 27002:2022 са особено релевантни.

Контрол 5.2, Роли и отговорности по информационна сигурност, поддържа оперативния модел. Той се свързва с ISO/IEC 27001:2022 Клауза 5.3, Организационни роли, отговорности и правомощия. Той също така поддържа готовността за инциденти, защото неясните роли подкопават ISO/IEC 27002:2022 Контрол 5.24, Планиране и подготовка за управление на инциденти по информационна сигурност. В управлението на съвместни администратори Контрол 5.2 е мястото, където RACI, собствениците на REG08, обработващите DSR, водещите при нарушения и контактите за ескалация се превръщат в одитни доказателства.

Контрол 5.31, Правни, законови, регулаторни и договорни изисквания, е мястото, където GDPR Article 26 става част от ISMS, а не въпрос само за правния отдел. Той поддържа идентифицирането и управлението на отчетността по GDPR Article 5, правното основание по Article 6, разпределението на отговорностите по Article 26, сигурността по Article 32, уведомяването на надзорния орган по Article 33 и комуникацията със засегнатите лица по Article 34. Той също така се свързва с ISO/IEC 27001:2022 Клауза 4.2, разбиране на потребностите и очакванията на заинтересованите страни, и Клауза 6.1.3, третиране на риска за информационната сигурност.

Контрол 5.34, Поверителност и защита на PII, въвежда защитата на PII в оперативния модел за сигурност. Той е особено важен, когато споразумението използва облачна аналитика, споделени информационни табла, data clean rooms, платформи за мониторинг, маркетингова автоматизация или инструменти за поддръжка. Свързаните защитни мерки могат да включват ISO/IEC 27002:2022 Контрол 5.23, Информационна сигурност при използване на облачни услуги, и Контрол 8.11, маскиране на данни.

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

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

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

Политиката за правно и регулаторно съответствие на Clarysec, клауза 5.3.1.2, изрично включва видовете договори в управлението, включително:

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

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

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

За МСП същият принцип се мащабира към оперативната реалност. Политиката за защита на данните и поверителност-sme - SME, клауза 5.2.1, гласи:

Координаторът по поверителност трябва да поддържа регистър на всички дейности по обработване на лични данни, включително категории данни, цел, правно основание и срокове за съхранение

Клауза 5.2.2 добавя:

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

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

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

Управление на инциденти и нарушения: определете водещия преди нарушението

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

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

Политиката за реагиране при инциденти-sme - SME на Clarysec, клауза 5.3.2, отразява дисциплината относно сроковете:

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

Zenith Blueprint, стъпка 5, Комуникация, осведоменост и компетентност, подчертава планирането на външната комуникация, включително с клиенти, регулатори, партньори и обществеността. За съвместни администратори матрицата за инциденти трябва да идентифицира кой извършва първоначалната класификация на нарушението, кой се свързва с другия администратор, кой определя дали са засегнати PII, кой оценява праговете за уведомяване, кой изготвя уведомленията до органите, кой комуникира с физическите лица, кой координира докладването по NIS2 или DORA, кой одобрява публичните изявления и кой записва доказателствата в REG10.

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

Най-сигурната практика е съвместно настолно упражнение преди стартиране. Добрият сценарий принуждава екипите да използват REG08, REG10, процедурата за инциденти, контактите на партньорите, шаблоните за уведомяване, дърветата за ескалация и журналите с доказателства под времеви натиск.

Съответствие между рамки: Article 26 рядко съществува самостоятелно

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

NIS2 може да се прилага за средни и големи съществени или важни субекти в сектори като цифрова инфраструктура, облачни изчисления, центрове за данни, доставчици на управлявани услуги, доставчици на управлявани услуги за сигурност, онлайн пазари, търсачки и платформи за социални мрежи. NIS2 Article 20 възлага надзора върху управлението на риска за киберсигурността на ръководните органи. Article 21 изисква технически, оперативни и организационни мерки, включително анализ на риска, обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, сигурна разработка, обработване на уязвимости, обучение, шифроване, сигурност на ЧР, контрол на достъпа, управление на активите и автентикация. Article 23 въвежда поетапно докладване за значителни инциденти.

DORA се прилага от 17 януари 2025 г. за много финансови субекти. Той обхваща управление на ИКТ риска, докладване на съществени инциденти, свързани с ИКТ, тестване на цифровата оперативна устойчивост, ИКТ риск от трети страни, договорни споразумения с ИКТ доставчици и надзор върху критични доставчици на ИКТ услуги от трети страни. DORA Article 5 поставя управлението на ИКТ риска на ниво ръководен орган. Articles 8 to 14 обхващат идентифициране на активи, защита, откриване, непрекъсваемост, архивиране, възстановяване, извлечени поуки, обучение и кризисни комуникации. Articles 17 to 20 определят жизнения цикъл и докладването на инциденти. Articles 28 to 30 превръщат ИКТ риска от трети страни, договорните условия, регистрите, риска от концентрация, правата на одит и планирането на изхода в централни задължения.

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

Предимството на модела на Clarysec е повторното използване на доказателства. REG08 не е само запис по GDPR. Той поддържа отчетност по ISO/IEC 27701:2025, управление по ISO/IEC 27001:2022, яснота на ролите на доставчиците по NIST CSF 2.0, управление на трети страни по DORA, когато са включени финансови услуги, и надзор от ръководството по NIS2, когато субектът е в обхват.

Какво ще тестват одиторите и регулаторите

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

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

Например GDPR Article 26 изисква разпределение на отговорностите между съвместните администратори. Политиката за система за управление на неприкосновеността на личната информация изисква REG08 преди началото на обработването. REG08 показва разпределението на отговорностите за уведомления, права, нарушения, съхранение, управление на доставчици и контакти. REG07 показва публично достъпното резюме. DSR симулация доказва, че работният поток функционира. Протоколите от преглед от ръководството показват изключения, решения и подобрения.

Това е подлежащо на одит управление.

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

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

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

Политиката за роли и отговорности в управлението-sme - SME на Clarysec, клауза 5.5, гласи:

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

За корпоративни организации Политиката за роли и отговорности в управлението, клауза 5.2, изисква:

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

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

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

• Нови и променени споразумения между съвместни администратори
• Статус на попълване на REG08
• Високорискови дейности по обработване и статус на DPIA, когато е приложимо
• Отворени въпроси по правно основание или прозрачност
• Резултатност на DSR и просрочени действия от партньори
• Резултати от настолни упражнения за нарушения и нерешени пропуски
• Зависимости от доставчици, подизпълнители по обработване, облак и предаване на данни
• Изключения относно съхранение и прекратяване
• Одитни констатации и статус на ремедиация
• Въздействие върху докладването по GDPR, NIS2, DORA, NIST CSF 2.0 и COBIT 2019

Петстъпков подход на Clarysec за подлежащ на одит Article 26

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

Използвайте този петстъпков подход:

1. Използвайте стъпка 2 от Zenith Blueprint, за да идентифицирате заинтересованите страни, правните изисквания, очакванията на партньорите, задълженията за поверителност и регулаторния обхват.
2. Използвайте стъпка 4 от Zenith Blueprint, за да изградите RACI за уведомления, правно основание, права, комуникация при нарушения, съхранение, предаване на данни, доставчици, одитни доказателства и прекратяване.
3. Запишете дейността по обработване в REG02 и разпределението на отговорностите между съвместните администратори в REG08, като използвате набора от политики на Clarysec за СУНЛИ.
4. Картографирайте споразумението чрез Zenith Controls, особено ISO/IEC 27002:2022 Контрол 5.2, Контрол 5.31 и Контрол 5.34.
5. Тествайте споразумението с DSR симулация и настолно упражнение за нарушение преди началото на обработването.

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

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

Clarysec може да ви помогне да внедрите управление на СУНЛИ по ISO/IEC 27701:2025, да го съгласувате с GDPR Article 26, да го интегрирате във вашата ISMS по ISO/IEC 27001:2022 и да създадете доказателства, готови за одит, спрямо очакванията на GDPR, NIS2, DORA, NIST CSF 2.0 и COBIT 2019.

Готови ли сте да замените неяснотата около съвместните администратори с доказателства, готови за одит? Разгледайте Zenith Blueprint: 30-стъпкова пътна карта за одитора, използвайте Zenith Controls: ръководство за съответствие между рамки или се свържете с Clarysec за оценка на СУНЛИ и ISMS, която превръща Article 26 в действаща контролна система, преди следващото ви партньорство да бъде въведено в експлоатация.