Приложимост на контролите по ISO 27701 според ролите по GDPR

Вторник е, 08:40 ч., и Мария, CISO на бързо растящо SaaS дружество в сферата на здравните технологии, преглежда четири имейла от клиенти, които изглеждат почти еднакво, но означават съвсем различни неща.

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

Дружеството на Мария не действа небрежно. То има ISMS, съгласувана с ISO/IEC 27001:2022, политики за поверителност, регистър на дейностите по обработване, MFA, криптиране, прегледи на правата за достъп и обучение по защита на личните данни още при проектиране. Но заявката поставя по-трудния въпрос, който одиторите и клиентите реално проверяват:

Може ли дружеството да докаже, че правилните контроли на PIMS по ISO 27701 се прилагат към правилната роля по GDPR, за правилната дейност по обработване, с правилния собственик, доказателства и обосновка?

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

Защо приложимостта на контролите по ISO 27701 е липсващият слой на PIMS

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

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

Приложимостта на контролите по ISO 27701 е дисциплината, която не позволява тези роли да се сведат до неясни твърдения. Тя поставя следните въпроси:

• Коя дейност по обработване е в обхвата?
• Каква роля по GDPR изпълнява организацията за тази дейност?
• Кои контроли на PIMS се прилагат поради тази роля?
• Кои контроли са изключени и защо?
• Кои доказателства доказват внедряването?
• Кое правно, договорно, рисково или обхватно изискване е довело до решението?

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

„[И двете] Собственикът на процеса / собственикът на бизнес процеса ТРЯБВА да класифицира ролята на организацията в PIMS за всяка дейност по обработване на PII в REG02, преди дейността по обработване да започне.“

От раздел „Определяне на ролята в PIMS“, клауза 4.2.1 от политиката.

Същата политика свързва това решение за роля с приложимостта на контролите:

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

От раздел „Политика за поверителност, цели и приложимост на контролите“, клауза 4.3.3 от политиката.

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

Изградете PIMS върху логиката на SoA по ISO/IEC 27001:2022

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

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

„ISMS следва да включва определени граници на обхвата, методология за оценка на риска, измерими цели и документирани мерки, обосновани в Декларацията за приложимост (SoA).“

От раздел „Изисквания за внедряване на политиката“, клауза 6.1.2 от политиката.

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

„Декларацията за приложимост (SoA) следва да отразява всички решения за третиране и следва да се актуализира при всяка промяна в покритието на контролите.“

От раздел „Изисквания за управление“, клауза 5.4 от политиката.

За поверителността REG03 се превръща в регистър за приложимост на контролите в PIMS, който следва дисциплината на SoA. Той не заменя SoA по ISO/IEC 27001:2022. Той я допълва, като добавя специфични за ролите по GDPR решения за поверителност за администратори, обработващи лични данни, съвместни администратори и подизпълнители по обработване.

Политиката за инвентар на обработването на PII и правно основание прави тази връзка изрична:

„[И двете] Ръководителят по поверителност / мениджърът на PIMS ТРЯБВА да свърже приложимите дейности по обработване от REG02 със записите за приложимост на контролите в REG03 преди прегледа за готовност за сертификация.“

От раздел „Експлоатация на инвентара на дейностите по обработване“, клауза 7.1.5 от политиката.

Одиторът трябва да може да избере една дейност по обработване в REG02, да идентифицира ролята по GDPR, да проследи приложимите контроли в REG03, да прегледа съответните контроли по ISO/IEC 27001:2022 в SoA и да провери доказателства като DPA, запис за правно основание, преглед на достъпа, одобрение на подизпълнител по обработване, процедура за инциденти или журнал за изтриване.

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

Най-бързият начин ISO 27701 да стане приложим на практика е приложимостта да се определя на ниво дейност по обработване, а не на ниво дружество.

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

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

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

Класифицирайте преди одобрение на договора или преди започване на обработването

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

Това забавяне създава последващи проблеми. Използва се неправилният DPA. Подизпълнителите по обработване не са оповестени. DPIA са пропуснати. Срокът за съхранение е неясен. Поддръжката на клиенти не знае кой срок за уведомяване при нарушение се прилага. Закупуването третира доставчик с въздействие върху поверителността като „просто инструмент“.

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

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

От раздел „Идентифициране и класифициране на взаимоотношенията“, клауза 4.1.3 от политиката.

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

За по-малки организации Политиката за сигурност на трети страни и доставчици - SME изисква екипите да вземат предвид:

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

От раздел „Изисквания за управление“, клауза 5.2.4 от политиката.

Тя също така поставя ясно изискване преди споделяне:

„Клаузите на споразумение за обработване на лични данни (DPA) или еквивалентни договорни условия трябва да бъдат договорени преди споделяне на каквито и да е лични или чувствителни данни.“

От раздел „Изисквания за внедряване на политиката“, клауза 6.3.2 от политиката.

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

Съпоставяйте контролите с ролята, риска, закона и договора

Zenith Blueprint, фаза „Управление на риска“, стъпка 13: „Планиране на третирането на риска и Декларация за приложимост“, обяснява основната логика за приложимост. Контролите са приложими поради решения за третиране на риска, правни или договорни изисквания, релевантност към обхвата и организационен контекст. Изключенията се нуждаят от ясни причини, а приложимите контроли трябва да могат да се проследят до риск или изискване.

В стъпка 13 Zenith Blueprint посочва:

„Осигурете съгласуване с вашия регистър на риска: всеки смекчаващ контрол, който сте записали в Плана за третиране на риска, следва да съответства на контрол от Annex A, отбелязан като „приложим“. Обратно, ако даден контрол е отбелязан като приложим, трябва да имате или риск, или изискване, което го налага.“

За ISO 27701 същият метод се прилага към контролите за поверителност. Контрол може да е приложим, защото:

1. GDPR го изисква за ролята на организацията.
2. Клиентски договор, DPA или договореност между съвместни администратори го изисква.
3. Третиране на риска за поверителността го изисква.
4. Обработването включва специални категории данни, данни на деца, мащабно наблюдение, чувствително профилиране или лични данни с високо въздействие.
5. Рискът, свързан с доставчик, облачна услуга, подизпълнител по обработване или трансгранично предаване, прави контрола необходим.
6. Контролът поддържа обхвата на сертификация, готовност за одит или одобрени цели за поверителност.

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

„Когато дадена регулация се прилага в множество области (напр. GDPR се прилага за съхранение, сигурност и поверителност), това трябва ясно да бъде съпоставено в Регистъра на съответствието и материалите за обучение.“

От раздел „Изисквания за управление“, клауза 5.2.2 от политиката.

Същата Политика за правно и регулаторно съответствие е изрична относно интеграцията в корпоративната ISMS:

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

От раздел „Изисквания за внедряване на политиката“, клауза 6.2.1 от политиката.

Следователно REG03 никога не трябва да бъде отделна таблица за поверителност. Той трябва да свързва дейностите по обработване, правните задължения, третиранията на риска, договорите, контролите по ISO/IEC 27001:2022 и собствениците на доказателствата.

Практически пример: работен поток за SaaS поддръжка

Разгледайте работен поток за поддръжка в SaaS платформата на Мария. Клиентите подават тикети, които могат да съдържат имена, имейли, идентификатори на акаунти, екранни снимки и понякога чувствителен бизнес контекст. Агентите по поддръжка имат достъп до ограничени записи. Облачен доставчик на тикетинг хоства данните и използва свои подизпълнители по обработване.

Стъпка 1: Запишете дейността в REG02

Ръководителят по поверителност записва:

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

Политиката за защита на данните и поверителност - SME поддържа този базов набор:

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

От раздел „Изисквания за управление“, клауза 5.2.1 от политиката.

Стъпка 2: Класифицирайте доставчика в REG08

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

Стъпка 3: Запишете приложимостта в REG03

Корпоративната Политика за защита на данните и поверителност добавя критерий за задействане при висок риск:

„Моделиране на заплахите и оценки на въздействието върху защитата на данните (DPIA) са задължителни за високорискови системи за обработване.“

От раздел „Изисквания за внедряване на политиката“, клауза 6.3.4 от политиката.

Политиката за защита на данните и поверителност - SME включва очакването за проектиране:

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

От раздел „Изисквания за управление“, клауза 5.3.1 от политиката.

Стъпка 4: Съгласувайте с контролите по ISO/IEC 27001:2022

Ако платформата за поддръжка е в обхвата на ISMS, SoA следва да включва поддържащи контроли по ISO/IEC 27002:2022, като взаимоотношения с доставчици, споразумения с доставчици, управление на ИКТ веригата на доставки, контрол на достъпа, управление на идентичности, предаване на информация, облачни услуги, управление на инциденти, регистриране и мониторинг, управление на промените, правно съответствие и защита на поверителността.

Zenith Blueprint, фаза „Управление на риска“, стъпка 14: „Политики за третиране на риска и регулаторни кръстосани препратки“, препоръчва GDPR, NIS2 и DORA да се съпоставят с политики и контроли, особено за защита на личните данни, реагиране при инциденти, контрол на достъпа, непрекъсваемост на дейността и ИКТ риск от трети страни.

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

Какво добавя Zenith Controls към приложимостта в PIMS

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

• 5.34 Поверителност и защита на PII
• 5.19 Информационна сигурност във взаимоотношенията с доставчици
• 5.20 Адресиране на информационната сигурност в споразумения с доставчици
• 5.21 Управление на информационната сигурност в ИКТ веригата на доставки
• 5.22 Мониторинг, преглед и управление на промените в услугите на доставчици

За 5.34 Zenith Controls класифицира контрола като превантивен, съпоставен с поверителност, цялостност и наличност, съгласуван с Identify и Protect и свързан с възможности за защита на информацията, правни въпроси и съответствие.

Съпоставянето му с GDPR посочва:

„Внедряването на 5.34 е пряко доказателство за способността на организацията да изпълнява изискванията на GDPR за отчетност.“

От Zenith Controls, „Поверителност и защита на PII“, кръстосано съпоставяне с GDPR.

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

Zenith Controls също свързва поверителността и защитата на PII със свързани стандарти като ISO/IEC 27018 за обработване на PII в публичен облак, ISO/IEC 29100 за принципи на поверителност и ISO/IEC 29151 за практики за защита на PII. Управлението на поверителността при доставчици се поддържа от семейството ISO/IEC 27036 за взаимоотношения с доставчици и сигурност на ИКТ веригата на доставки, както и от ISO/IEC 27017 за споделени отговорности при облачна сигурност.

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

Задълженията на администратори и обработващи лични данни често се срещат на границата с доставчика.

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

Това прави контролите 5.19 и 5.20 по ISO/IEC 27002:2022 централни за приложимостта на контролите по ISO 27701.

За 5.19 Zenith Controls поставя акцент върху сигурността във взаимоотношенията с доставчици в областите на управление, екосистема и защита. Контролът е пряко свързан с 5.20 споразумения с доставчици, 5.21 сигурност на ИКТ веригата на доставки, 5.14 предаване на информация, 5.36 съответствие с политики, правила и стандарти за информационна сигурност и 5.10 допустима употреба на информация и други свързани активи.

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

Zenith Blueprint, фаза „Контроли в действие“, стъпка 23: „Организационни контроли“, дава практическа инструкция за подизпълнители по обработване:

„За всеки критичен доставчик установете дали използва подизпълнители (подизпълнители по обработване), които могат да имат достъп до вашите данни или системи. Документирайте как вашите изисквания за информационна сигурност се прехвърлят към тези страни — чрез договорните условия на вашия доставчик или чрез ваши преки клаузи.“

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

Съответствие между рамки без дублиращи се системи за контрол

Приложимостта на контролите по ISO 27701 става по-ценна, когато поддържа разговори за уверение по GDPR, NIS2, DORA, NIST CSF 2.0 и COBIT 2019 от една и съща доказателствена база.

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

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

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

NIST CSF 2.0 осигурява управленски слой чрез функцията GOVERN, включително правни, регулаторни, договорни и свързани с поверителността задължения, роли, апетит за риск, надзор върху политики и управление на веригата на доставки.

COBIT 2019 добавя практики за управление и мениджмънт. За поверителност Zenith Controls съпоставя 5.34 с COBIT DSS06.02, DSS06.08 и APO13.01. За доставчици 5.19 и 5.20 поддържат практиките за риск, свързан с доставчици, и споразумения с доставчици.

Стратегическият извод е прост. REG03 трябва да бъде повече от артефакт по ISO 27701. Той трябва да бъде многократно използваема карта на приложимостта на контролите за клиентски одити, регулаторни прегледи и уверение на ниво съвет.

Как одиторите тестват приложимостта на контролите по ISO 27701

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

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

Одитор или DPO с фокус върху GDPR тества логиката на ролите. Той ще извади извадка от дейности, ще прегледа правно основание, уведомления за поверителност, DPA, подизпълнители по обработване, DPIA, обработване на DSAR, срокове за съхранение и вземане на решения за нарушения.

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

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

За 5.34 Zenith Controls описва как одиторите преглеждат политики за поверителност, инвентари на данни, DPIA, логове от обучението, технически предпазни мерки, извадки от DSAR, инциденти с PII и доказателства за защита на личните данни още при проектиране. За 5.19 и 5.20 одиторите изискват инвентари на доставчици, рискови класификации, записи от надлежна проверка, договори, условия за нарушения, права на одит, одобрение на подизпълнители, доказателства за изход и доказателство, че докладите от доставчици се преглеждат.

Разграничението е критично. Готовност за одит не означава „имаме клауза“. Готовност за одит означава „използвахме клаузата, наблюдавахме я, прегледахме доказателствата и предприехме действия, когато рискът се промени“.

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

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

Първо, организациите класифицират цялото дружество с една роля по GDPR. Това не работи за SaaS, fintech, HR tech, health tech, управлявани услуги или доставчици на облачни услуги със смесени потоци от данни.

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

Трето, те изключват контроли, без да документират защо. В логиката на SoA по ISO/IEC 27001:2022 и логиката за приложимост в PIMS изключенията трябва да бъдат съзнателни, мотивирани и подкрепени от анализ на обхвата, ролята, риска или правните изисквания.

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

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

Контролен списък на Clarysec за приложимост на контролите в REG03

Използвайте този контролен списък преди прегледи за готовност по ISO 27701, клиентско уверение по GDPR или оценки на доставчици, водени от DORA:

• Създайте или актуализирайте REG02 за всяка дейност по обработване, включваща PII.
• Класифицирайте ролята в PIMS за всяка дейност преди започване на обработването.
• Класифицирайте всяко взаимоотношение с трета страна в REG08 преди одобрение на договора или обработване на PII.
• Идентифицирайте задълженията въз основа на ролята: администратор, обработващ лични данни, съвместен администратор или подизпълнител по обработване.
• Запишете приложимите контроли на PIMS в REG03 със собственик, статус на внедряване и доказателства.
• Запишете изключените контроли с ясна обосновка.
• Свържете решенията в REG03 с рискове, правни задължения, договори или обосновка на обхвата.
• Съгласувайте REG03 със SoA по ISO/IEC 27001:2022, когато контролите за сигурност поддържат поверителността.
• Съпоставете контролите за поверителност с ISO/IEC 27002:2022 5.34, когато се изисква защита на PII.
• Съпоставете изискванията за доставчици и подизпълнители по обработване с 5.19, 5.20, 5.21 и 5.22.
• Добавете кръстосани препратки за съответствие към GDPR, NIS2, DORA, NIST CSF 2.0 и COBIT 2019, когато е релевантно.
• Тествайте доказателствената следа чрез извадка във вътрешен одит преди прегледа за готовност за сертификация.
• Получете одобрение от висшето ръководство, когато обхватът на PIMS или приложимостта на контролите се променя.

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

„[И двете] Висшето ръководство ТРЯБВА да одобри промени в обхвата на PIMS и приложимостта на контролите в REG01 и REG03, преди да бъдат подадени промени в обхвата на сертификация.“

От раздел „Управление на PIMS“, клауза 6.1.3 от политиката.

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

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

Приложимостта на контролите по ISO 27701 е мястото, където теорията за ролите по GDPR се превръща в оперативна реалност. Администраторът се нуждае от доказателства за правно основание, прозрачност, срокове за съхранение, DPIA, обработване на права и надзор върху обработващи лични данни. Обработващият лични данни се нуждае от доказателства за документирани указания, поверителност, сигурност, съдействие, подизпълнители по обработване, съдействие при нарушения и изтриване. Съвместният администратор се нуждае от прозрачна договореност за отговорностите. Подизпълнителят по обработване се нуждае от прехвърляне на задължения надолу по веригата и подкрепящо уверение.

Clarysec помага на организациите да изградят този доказателствен слой чрез:

• Инвентар на дейностите по обработване REG02 и структура за правно основание.
• Записи за приложимост на контролите в PIMS в REG03.
• Класификация на взаимоотношенията с трети страни във връзка с поверителността в REG08.
• Съгласуване със SoA по ISO/IEC 27001:2022.
• Клаузи в политики, които възлагат собственици, срокове и изисквания за одобрение.
• Съпоставяне на изискванията за съответствие между рамки чрез Zenith Controls.
• Последователност на внедряване чрез Zenith Blueprint.

Ако организацията ви се подготвя за готовност на PIMS по ISO 27701, клиентско уверение по GDPR, прегледи на доставчици по DORA или управление на сигурността, съгласувано с NIS2, започнете с една високорискова дейност по обработване. Класифицирайте ролята. Съпоставете приложимите контроли. Свържете доказателствата. След това повторете, докато програмата ви за поверителност стане не само съответстваща на хартия, но и обяснима при одит.

Изтеглете пакета политики за PIMS на Clarysec, разгледайте Zenith Blueprint или резервирайте оценка на готовността от Clarysec, за да превърнете решенията за администратор, обработващ лични данни, съвместен администратор и подизпълнител по обработване в регистър с доказателства за поверителност, готов за сертификация.