Управление на достъпа до лични данни за ISO 27701:2025 и GDPR

Въпросът на външния одитор остана във въздуха — привидно прост.

„Можете ли да ми покажете записа от прегледа на достъпа на вашия екип за поддръжка до продукционни лични данни за последното тримесечие?“

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

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

Аня отвори IAM конзолата. Имаше инженери по поддръжка, администратори на бази данни, служебен акаунт за интеграция, доставчик на управлявани услуги, две аварийни break-glass роли и бивш външен изпълнител, който все още присъстваше в група, защото билетът за освобождаване беше затворен преди правото за достъп да бъде премахнато. Отдел „Човешки ресурси“ показваше, че лицето е напуснало преди шест седмици. В електронната таблица за преглед на достъпа пишеше „в изчакване“. SIEM имаше логове, но никой не беше съпоставил кои събития доказват достъп до лични данни.

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

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

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

Управлението на достъпа до лични данни не е само IAM

Традиционната IAM програма задава въпроса: „Могат ли правилните потребители да имат достъп до правилните системи?“

Зряла СУНЛИ по ISO/IEC 27701:2025 задава по-трудни въпроси:

• Кои системи обработват лични данни?
• Кои роли изискват достъп до кои категории лични данни?
• Действа ли организацията като администратор на лични данни, обработващ лични данни, съвместен администратор или подизпълнител по обработване?
• Ограничен ли е достъпът според целта, документираната служебна необходимост и принципа на минимално необходимия достъп?
• Логват ли се и преглеждат ли се привилегированите действия?
• Може ли организацията да докаже, че достъпът на обработващи лични данни и подизпълнители по обработване е договорно контролиран?
• Включени ли са в доказателствата пътищата за облачна поддръжка, изолацията на тенанти, експортите и административните действия?
• Преглеждат ли се решенията за достъп след въвеждане в длъжност, промяна на роля, инцидент, освобождаване и съществена промяна в системата?

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

Zenith Blueprint: 30-стъпкова пътна карта за одитора на Clarysec поставя това във фазата „Контроли в действие“. В стъпка 23, която обхваща организационните контроли 5.19 до 5.37, той описва контрол 5.34 на ISO/IEC 27002:2022, „Поверителност и защита на личните данни“, като въпрос на доверие, а не само като въпрос на данни:

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

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

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

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

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

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

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

ISO/IEC 27001:2022 свързва тези задължения в система за управление, основана на риска. Клаузи 6.1.1 до 6.1.3 изискват организациите да разглеждат рисковете и възможностите, да дефинират процес за оценка на риска за информационната сигурност, да идентифицират рискове за поверителност, цялостност и наличност, да оценяват рисковете, да избират варианти за третиране, да определят контроли, да сравняват избраните контроли с Annex A, да документират Декларацията за приложимост, да получат одобрение от собственика на риска и да приемат остатъчните рискове. Клаузи 8.2 и 8.3 изискват оценки на риска на планирани интервали или след значителна промяна, както и прилагане на плана за третиране на риска с документирани резултати.

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

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

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

В Zenith Controls: ръководство за съответствие между рамки темата е основно свързана с три контрола от ISO/IEC 27002:2022:

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

Политиката за сигурност и контрол на достъпа до лични данни на Clarysec задава базовия набор от изисквания на езика на СУНЛИ:

[И двете] Собственикът на система / собственикът на приложение ТРЯБВА да ограничи достъпа до лични данни до одобрени роли и оторизирани потребители, записани или проследими в REG02 или REG12, преди достъпът да бъде активиран.

От раздел „4.2 Базов набор от контроли на достъпа“, клауза 4.2.1 от политиката.

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

Същата политика повишава изискванията за чувствителни лични данни или лични данни с високо въздействие:

[И двете] Собственикът на система / собственикът на приложение ТРЯБВА да преглежда достъпа на потребители до системи, обработващи лични данни с високо въздействие или чувствителни лични данни, най-малко на тримесечна база и да записва резултата от прегледа в REG12.

От раздел „4.2 Базов набор от контроли на достъпа“, клауза 4.2.3 от политиката.

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

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

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

SME Политиката за контрол на достъпа - SME на Clarysec задава принципа:

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

От раздел „Цел“, клауза 1.3 от политиката.

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

Достъпът на потребители до лични данни трябва да бъде ограничен до роли с документирана служебна необходимост

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

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

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

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

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

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

Най-честият отказ при достъпа до лични данни не е първоначалното одобрение. Това е устойчивото запазване на достъпа.

Zenith Blueprint, във фазата „Контроли в действие“, стъпка 22, обяснява контрол 5.18 „Права за достъп“ от ISO/IEC 27002:2022 така:

Контрол 5.18 гарантира, че правата за достъп не само се предоставят по подходящ начин, но и се преглеждат, коригират и отнемат по контролиран и проследим начин.

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

SME Политиката за управление на потребителски акаунти и привилегии - SME на Clarysec определя базова периодичност:

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

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

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

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

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

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

1. Класифициране на системата и категориите лични данни.
2. Дефиниране на одобрени роли и документирана служебна необходимост.
3. Съпоставяне на ролите с целите на обработването.
4. Одобряване на достъпа преди активиране.
5. Прилагане на минимално необходим достъп, разделение на задълженията и силна автентикация.
6. Логване на автентикация, достъп, експорт, конфигурация и привилегировани действия.
7. Преглед на достъпа с периодичност, основана на риска.
8. Премахване на достъпа при промяна на роля, прекратяване на правоотношение, приключване на проект, изтичане на договор или нареждане на клиента.
9. Съхраняване на доказателства в регистъра на СУНЛИ и в одитната следа.

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

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

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

Първо тя цитира Политиката за сигурност и контрол на достъпа до лични данни, клауза 4.2.3, която изисква тримесечен преглед на достъпа до лични данни с високо въздействие или чувствителни лични данни и записване на резултата от прегледа в REG12.

След това тя преведе одитора през предходното тримесечие:

• ИТ генерира списък на всички потребители, групи, привилегировани роли, служебни акаунти, акаунти на доставчици, break-glass роли и разрешения за поддръжка за продукционната база данни, съдържаща данни за пациенти.
• Списъкът беше изпратен до собственика на приложението — ръководителя на клиентското обслужване, който отговаряше за оперативната необходимост на екипа за поддръжка.
• Собственикът на приложението прегледа списъка ред по ред спрямо текущата роля, отговорността за клиентска поддръжка и целта на обработването.
• Двама агенти по поддръжка, които бяха преминали в други екипи, бяха маркирани за отнемане на достъп.
• В системата за управление на ИТ услуги беше създаден билет, свързан с прегледа на достъпа, с определен SLA, и беше затворен след отнемането.
• REG12 беше актуализиран със записа от прегледа, одобряващото лице, изключенията, билета за отстраняване, доказателствата за приключване и датата на следващия преглед.

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

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

Достъп на доставчици и обработващи лични данни: сляпото петно в одитите на СУНЛИ

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

Съгласно GDPR администраторите трябва да използват обработващи лични данни, които предоставят достатъчни гаранции. Съгласно ISO/IEC 27701:2025 управлението на обработващи лични данни и подизпълнители по обработване трябва да бъде превърнато в оперативна практика чрез документирани нареждания, договорни контроли, уверение и мониторинг. ISO/IEC 27002:2022 подкрепя това чрез контроли за взаимоотношения с доставчици, включително 5.19 Информационна сигурност във взаимоотношенията с доставчици, 5.20 Разглеждане на информационната сигурност в споразуменията с доставчици и 5.21 Управление на информационната сигурност във веригата за доставки на ИКТ.

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

✓ Отговорности за контрол на достъпа, например кой може да има достъп до вашите данни, как се управляват удостоверителните данни и какъв мониторинг е въведен;

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

Политиката за управление на поверителността при обработващи лични данни, подизпълнители по обработване и трети страни на Clarysec превръща това в доказателства от страна на администратора в СУНЛИ:

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

От раздел „4.3 Договорни контроли и контроли за документирани нареждания“, клауза 4.3.2 от политиката.

Достъпът на доставчици също се контролира пряко в SME и корпоративните политики за доставчици на Clarysec. SME Политиката за сигурност на трети страни и доставчици - SME посочва:

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

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

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

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

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

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

Достъп до лични данни в облака: споделената отговорност не е споделена отчетност

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

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

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

Той също предупреждава:

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

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

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

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

За организации, действащи като обработващи лични данни в облачни среди, Политиката за обработващи лични данни в облачна среда на Clarysec дефинира по-конкретно задължение за преглед в СУНЛИ:

[Обработващ лични данни] Ръководителят по информационна сигурност ТРЯБВА да преглежда привилегирования облачен достъп, достъпа за поддръжка, достъпа до клиентски лични данни и покритието на логването в REG12 най-малко на тримесечна база.

От раздел „4.2 Облачна конфигурация, изолация на тенанти, достъп и логване“, клауза 4.2.4 от политиката.

Тази клауза е особено приложима за SaaS дружества, облачно хоствани платформи, управлявани услуги за данни и B2B обработващи лични данни.

Управлението на достъпа до лични данни в облака не е завършено, ако cloud-native логове, IAM политики, служебни акаунти, привилегировани роли, инструменти за клиентска поддръжка, API ключове и функции за експорт на данни не се преглеждат заедно.

Логване и мониторинг: паметта на управлението на личните данни

Програма за контрол на достъпа в СУНЛИ без логове е обещание без памет.

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

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

От раздел „4.6 Логване и мониторинг“, клауза 4.6.1 от политиката.

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

Логове за достъп: достъп до файлове (особено за чувствителни или лични данни), промени в разрешенията, използване на споделени ресурси

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

Корпоративната Политика за регистриране и мониторинг се фокусира върху използваемостта за одит:

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

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

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

• Кой е имал достъп до личните данни?
• Бил ли е достъпът оторизиран?
• Бил ли е достъпът свързан с билет за поддръжка, правно искане, оперативна задача или нареждане на клиента?
• Данните били ли са експортирани, копирани, променени или изтрити?
• Използван ли е привилегирован достъп?
• Променени ли са разрешенията преди или след достъпа?
• Дейността показвала ли е инцидент по сигурността или нарушение на сигурността на личните данни?

Логовете не са само за SOC. Те са доказателства в СУНЛИ, доказателства за клиентско уверение, доказателства за уверение относно обработващи лични данни и доказателства за реагиране при инциденти.

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

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

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

Стойността на Zenith Controls е, че екипите могат да върнат тези гледни точки към едни и същи доказателства за контрол, вместо да поддържат отделни силози за съответствие.

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

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

Стъпка 1: Дефинирайте контекста на обработване на лични данни

Запишете в REG12:

• Име и собственик на системата
• Категории лични данни
• Категории субекти на данни
• Роля на администратор или обработващ лични данни
• Цел на обработването
• Индикатор за лични данни с високо въздействие или чувствителни лични данни
• Зависимости от облачни услуги, доставчици и подизпълнители по обработване

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

Стъпка 2: Извлечете списъка с достъп

Експортирайте всички потребители, групи, привилегировани роли, служебни акаунти, роли за поддръжка, break-glass акаунти, API ключове и акаунти на доставчици. Сравнете всяко право за достъп с одобрените роли.

Стъпка 3: Потвърдете минимално необходимия достъп и съответствието с целта

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

Стъпка 4: Проверете обхвата на логване

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

Стъпка 5: Затворете цикъла

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

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

Чести одитни констатации при управлението на достъпа до лични данни

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

Честите констатации включват:

• Системите с лични данни не са напълно посочени в инвентара на СУНЛИ.
• Ролите за достъп са дефинирани технически, но не са съпоставени с целите на обработването.
• Чувствителни лични данни са достъпни чрез широки оперативни групи.
• Тримесечните прегледи обхващат служители, но не и служебни акаунти, API ключове или потребители на доставчици.
• Достъпът за облачна поддръжка е възможен, но не се преглежда като достъп до лични данни.
• Логовете съществуват, но не доказват достъп до лични данни, експорт или привилегирована дейност.
• Договорите с обработващи лични данни включват общи клаузи за поверителност, но не и конкретни контроли за контрол на достъпа, одит, подизпълнители по обработване, връщане, изтриване или прекратяване.
• Бивши служители или външни изпълнители запазват достъп чрез споделени групи или неуправлявани токени.
• Достъпът до хранилището за данни е по-широк от достъпа до изходното приложение.
• Break-glass акаунти съществуват без преглед след използване.
• Имперсонирането в клиентската поддръжка не се логва с контекст на билет.
• Декларацията за приложимост включва контроли на достъпа, но доказателствата не показват внедряване, специфично за лични данни.

Всяка от тези констатации може да се превърне в проблем с отчетността по GDPR, въпрос на клиентско уверение, слабост в управлението по NIS2 или DORA или несъответствие по ISO/IEC 27001:2022 в зависимост от обхвата.

Как изглежда добрата практика

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

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

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

Трето, контролите се прилагат технически. IAM, RBAC, управление на привилегирован достъп, MFA, условен достъп, контроли на тенанта, шифроване и разделяне на средите прилагат очакванията на политиките.

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

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

Шесто, доказателствата са повторно използваеми. Едни и същи записи поддържат отчетността по GDPR, функционирането на СУНЛИ по ISO/IEC 27701:2025, третирането на риска по ISO/IEC 27001:2022, мерките за управление на риска по NIS2, управлението на ИКТ риска по DORA, резултатите от GOVERN по NIST CSF 2.0 и управленското уверение по COBIT 2019.

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

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

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

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

Започнете с Политиката за сигурност и контрол на достъпа до лични данни, съгласувайте задълженията на обработващите лични данни и облачните задължения чрез Политиката за управление на поверителността при обработващи лични данни, подизпълнители по обработване и трети страни и Политиката за обработващи лични данни в облачна среда, след това използвайте Zenith Blueprint: 30-стъпкова пътна карта за одитора, за да внедрите контролите в правилната последователност. Накрая използвайте Zenith Controls: ръководство за съответствие между рамки, за да съпоставите доказателствата за достъп до лични данни в ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, NIST CSF 2.0 и COBIT 2019.

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