Управление на биометрични данни съгласно GDPR и ISO 27701

Искането за извънредна среща се появи във входящата поща на CISO Мария Петрова с неприятна тежест. Темата гласеше: „СПЕШНО: биометрична автентикация — решение за старт/отлагане през Q3“.
Мария знаеше какво стои зад него. Нейната компания, бързо растяща финтех организация на име Finura, се подготвяше да стартира потвърждаване на плащания в приложението чрез лицево разпознаване и разпознаване на пръстов отпечатък. Продуктовият екип виждаше функция, която може да промени пазара. Съветът виждаше по-бързо възприемане от клиентите. Екипите за предотвратяване на измами виждаха по-малко фалшиви акаунти. COO виждаше по-малко триене в процеса. Мария виждаше друга картина: лични данни от специална категория, критерии за задействане на DPIA, зависимост от доставчик, риск при съхранението, оттегляне на съгласие, оперативна устойчивост и сценарий на нарушение, който не може да бъде решен чрез издаване на нова парола.
Още в началото на разговора натискът беше очевиден. „Конкуренцията изостава с месеци“, настоя ръководителят на продуктовия екип. „Не можем да си позволим забавяне.“
След това започнаха въпросите.
Беше ли проектирано и регистрирано изричното съгласие? Имаше ли валидно правно основание по GDPR Article 6 и условие по Article 9? Беше ли биометричният доставчик оценен като доставчик на ИКТ услуги от трета страна съгласно очакванията на DORA? Беше ли извършена оценка на въздействието върху защитата на данните (DPIA) преди началото на инженерната работа? Можеше ли Finura да докаже, че оттеглен лицев шаблон ще бъде изтрит от продукционните системи, резервните копия и средите на доставчика?
Мълчанието каза всичко.
Управлението на биометрични данни е различно, защото идентификаторът е самото лице. Парола може да бъде сменена. Карта може да бъде заменена. Компрометиран лицев шаблон, модел на пръстов отпечатък, гласов отпечатък, шаблон на вените на дланта или идентификатор, извлечен от ириса, реалистично не може да бъде променен. Когато биометричните данни се използват за еднозначна идентификация, GDPR ги третира като данни от специална категория. ISO/IEC 27701:2025 изисква система за управление на защитата на личната информация, или PIMS, която може да докаже защо обработването е необходимо, как се контролира, кой го е одобрил, колко дълго се съхраняват данните, кои доставчици имат достъп до тях и как се обработват исканията за упражняване на права и инцидентите.
Проблемът е, че много организации купуват продукт за биометрична идентичност, попълват въпросник по сигурност, добавят общо уведомление за поверителност и приемат, че шифроването решава въпроса. Не е така. Шифроването е необходимо, но управлението на биометрични данни изисква свързан оперативен модел.
Подходът на Clarysec комбинира управление на ISO/IEC 27701:2025 PIMS, доказателства за контроли по ISO/IEC 27001:2022, отчетност по GDPR и съпоставяне на изискванията за съответствие между рамки чрез Zenith Controls: The Cross-Compliance Guide Zenith Controls. В Zenith Controls клъстерът за управление на биометрични данни е изграден около ISO/IEC 27002:2022 контрол 5.34, Поверителност и защита на личната информация, подкрепен от 5.17, Информация за автентикация, 8.5, Сигурна автентикация, 8.10, Изтриване на информация, 8.24, Използване на криптография, както и контроли за доставчици като 5.20, Адресиране на информационната сигурност в споразуменията с доставчици.
Целта не е да се забавя иновацията. Целта е биометричната автентикация, проверката на самоличността, достъпът до работното място и предотвратяването на измами да бъдат защитими, пропорционални, сигурни и готови за одит.
Защо управлението на биометрични данни се проваля в зрели компании
Една компания може да има силна програма за сигурност и въпреки това да има слабо управление на биометрични данни.
Представете си SaaS доставчик, който въвежда лицева проверка при клиентски онбординг. Екипът по сигурност изисква TLS, шифровано съхранение, администраторска MFA, контроли на достъпа и регистриране. Доставчикът твърди, че биометричните шаблони са „необратими“. Продуктовият екип документира намаляването на измамите като бизнес обосновка. Правният отдел преглежда споразумението за обработване на лични данни. Закупуването отбелязва доставчика като проверен.
След това одиторът задава пет въпроса:
- Къде е регистрирана дейността по обработване на биометрични данни?
- Какво е правното основание по GDPR Article 6 и, когато е приложимо, условието за специална категория по Article 9?
- Извършена ли е DPIA преди началото на обработването?
- Можете ли да докажете, че биометричните шаблони се изтриват, когато целта отпадне?
- Какво се случва, ако биометричният доставчик претърпи нарушение или промени своите подизпълнители по обработване?
Ако отговорите са разпръснати в имейл кореспонденция, заявки към закупуването, продуктови бележки и портал на доставчика, програмата не е готова за одит.
GDPR Article 5 изисква законосъобразност, добросъвестност, прозрачност, ограничение на целите, свеждане на данните до минимум, точност, ограничение на съхранението, цялостност, поверителност и отчетност. Article 6 изисква правно основание. Article 9 добавя по-строго условие, когато биометричните данни се обработват с цел еднозначно идентифициране на лице. Дефинициите в Article 4 са важни, защото обработването включва събиране, съхранение, използване, разкриване, изтриване и унищожаване. Псевдонимизацията помага само когато допълнителната идентифицираща информация е защитена отделно с подходящи технически и организационни мерки.
За компании извън ЕС GDPR може да продължи да се прилага, когато те предлагат стоки или услуги на лица в ЕС или наблюдават поведение, което се осъществява в ЕС. Това прави биометричния клиентски онбординг, оценяването на риска от измама, отдалечения достъп на служители, гласовата проверка в контактен център и проверката на самоличността на клиенти релевантни далеч отвъд Европа.
Провалът в управлението рядко е един липсващ контрол. Обичайно той е липса на свързана доказателствена верига.
Доказателствената верига на Clarysec за биометричен PIMS
Clarysec третира биометричните случаи на употреба като обработване на лични данни, управлявано през целия жизнен цикъл, а не като самостоятелни функции за автентикация. Доказателствената верига започва преди системата да бъде закупена, конфигурирана или внедрена.
В Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, във фазата Controls in Action, Step 23, ISO/IEC 27002:2022 контрол 5.34 е описан така:
Имена, адреси, идентификатори, здравни досиета, финансови данни — тези данни разказват история за реални хора. Когато се обработват неправилно, бъдат откраднати или използвани неправомерно, последиците надхвърлят далеч неуспехите в съответствието. Това се превръща във въпрос на лична неприкосновеност, репутационен ущърб и правна експозиция.
Това послание е още по-остро при биометричните идентификатори. Биометричният шаблон не е просто данни за вход. Той е свързан с физически или поведенчески характеристики на лице и може да се използва за еднозначното му идентифициране.
Защитим работен процес за управление на биометрични данни свързва седем решения със седем вида доказателства:
| Точка на решение | Необходими доказателства | Опорна точка в инструментариума на Clarysec |
|---|---|---|
| Цел и необходимост | Бизнес цел, разгледани алтернативи, решение за пропорционалност | PII Processing Inventory and Lawful Basis Policy, REG02 |
| Правно основание и условие за специална категория | Основание по GDPR Article 6 и условие по Article 9, когато е приложимо | Data Protection and Privacy Policy, REG02 |
| Критерий за задействане и резултат от DPIA | Проверка за необходимост от DPIA, оценка на риска, одобрение на остатъчния риск | Privacy Risk Assessment and DPIA Policy, REG04 |
| Архитектура на сигурността | Шифроване, контрол на достъпа, автентикация, регистриране, сегментиране | PII Security and Access Control Policy, REG12 |
| Прозрачност и съгласие, когато е релевантно | Уведомление за поверителност, запис за изрично съгласие, когато се изисква, обработване на оттеглянето | Consent and Preference Management Policy, REG05 |
| Управление на доставчици | Роля на обработващ лични данни, договорни условия, преглед на подизпълнители по обработване, годишна повторна оценка | Processor, Subprocessor and Third-Party Privacy Management Policy, регистър на доставчиците |
| Съхранение и изтриване | График за сроковете за съхранение, журнали за изтриване, обработване на резервни копия, доказателства за изтриване | Data Protection and Privacy Policy, регистър на изтриванията |
Това е разликата между „използваме биометрията сигурно“ и „можем да докажем управление на биометрични данни съгласно GDPR и ISO/IEC 27701:2025“.
Правното основание не е отметка
Биометричните проекти често се провалят на етапа на правното основание, защото екипите бъркат стойността за сигурността с правно разрешение.
GDPR Article 6 изисква правно основание, като съгласие, необходимост за изпълнение на договор, правно задължение, жизненоважни интереси, задача от обществен интерес или легитимни интереси, когато са приложими. Article 9 по принцип забранява обработването на биометрични данни за еднозначна идентификация, освен ако не е приложимо конкретно изключение, като изрично съгласие, задължения в областта на трудовото право и социалната закрила по закон, жизненоважни интереси, значим обществен интерес, здравеопазване, обществено здраве, правни претенции или научни изследвания и архивиране с предпазни мерки.
Биометричен терминал за отчитане на работно време, достъп до врата с пръстов отпечатък, лицев клиентски онбординг и гласова автентикация може да изискват различен анализ. Една и съща технология може да доведе до различни резултати относно правното основание в зависимост от целта, избора на потребителя, дисбаланса във властовите отношения, местното законодателство, пропорционалността и наличието на небиометрични алтернативи.
Enterprise Data Protection and Privacy Policy на Clarysec Data Protection and Privacy Policy задава ясно базовото изискване:
Всяко обработване трябва да се основава на валидно правно основание (напр. съгласие, договор, правно задължение).
От раздел „Изисквания за прилагане на политиката“, клауза на политиката 6.1.1.
За данни от специална категория PII Processing Inventory and Lawful Basis Policy на Clarysec PII Processing Inventory and Lawful Basis Policy засилва изискването за доказателства:
[Условно] Собственикът на процеса / собственикът от бизнеса ТРЯБВА да запише условието за обработване на специална категория в REG02 преди обработването на лични данни от специална категория.
От раздел „Записи за целта и правното основание на администратора“, клауза на политиката 4.2.6.
За МСП Clarysec прилага същата дисциплина в по-опростен оперативен модел. SME Data Protection and Privacy Policy-sme Data Protection and Privacy Policy - SME посочва:
Координаторът по защита на личните данни трябва да поддържа регистър на всички дейности по обработване на лични данни, включително категории данни, цел, правно основание и срокове за съхранение
От раздел „Изисквания за управление“, клауза на политиката 5.2.1.
И добавя:
Правното основание (напр. съгласие, договор, правно задължение) трябва да бъде документирано в регистъра на дейностите по обработване
От раздел „Изисквания за прилагане на политиката“, клауза на политиката 6.1.2.
За управлението на биометрични данни регистърът на дейностите по обработване не е административна формалност. Той е контролната точка, чрез която организацията доказва, че биометричният случай на употреба е известен, класифициран, обоснован и ограничен.
Първо DPIA, после внедряване
Ако има едно оперативно правило за биометричните системи, то е просто: не допускайте закупуването да изпревари DPIA.
Биометричните технологии често включват лични данни от специална категория, еднозначна идентификация, систематично наблюдение, профилиране за измами, уязвими субекти на данни, дисбаланс в работната среда, иновативна технология или автоматизирано подпомагане при вземане на решения. Това са класически критерии за задействане на DPIA. DPIA не е просто формуляр за поверителност. Това е мястото, където организацията проверява необходимостта, пропорционалността, алтернативите, остатъчния риск, предпазните мерки, прозрачността, съхранението, зависимостта от доставчици и въздействието при инцидент.
Enterprise Data Protection and Privacy Policy изисква формален анализ за високорискови системи:
Моделиране на заплахите и оценки на въздействието върху защитата на данните (DPIA) са задължителни за високорискови системи за обработване.
От раздел „Изисквания за прилагане на политиката“, клауза на политиката 6.3.4.
Специфичната за PIMS Privacy Risk Assessment and DPIA Policy Privacy Risk Assessment and DPIA Policy е по-пряка:
[Администратор] Собственикът на процеса / собственикът от бизнеса ТРЯБВА да ескалира към ръководителя по защита на личните данни / PIMS мениджъра в REG04 обработване, включващо голям мащаб, систематично наблюдение, профилиране, автоматизирани решения, лични данни от специална категория, данни за присъди или нарушения, уязвими субекти на данни, иновативна технология или съществено променено обработване, преди обработването да започне.
От раздел „Критерии за задействане на DPIA и определяне на изискването“, клауза на политиката 4.2.2.
Биометричната DPIA трябва да отговори най-малко на следните въпроси:
- Каква биометрична модалност се обработва, например лице, пръстов отпечатък, глас, ирис, длан или поведенчески модел?
- Използват ли се биометричните данни за еднозначна идентификация или само за локална проверка на устройството?
- Организацията администратор, обработващ лични данни, съвместен администратор или подизпълнител по обработване ли е?
- Каква небиометрична алтернатива съществува и достъпна ли е при равни условия?
- Изисква ли се изрично съгласие и може ли то да бъде свободно дадено и оттеглено?
- Съхраняват ли се сурови биометрични изображения, аудио или шаблони?
- Къде се съхраняват шаблоните — например в защитен модул на устройството, централна система или облак на доставчик?
- Кой има достъп до шаблони, резултати от съпоставяне и биометрични журнали?
- Какви срокове за съхранение се прилагат за регистрирани потребители, отхвърлени кандидати, неактивни акаунти и служители с прекратено правоотношение?
- Как се доказва изтриването и изтичането на срока на резервните копия?
- Какво се случва след фалшиво положителни резултати, фалшиви откази или грешки при автоматизирани решения?
- Какви подизпълнители по обработване участват и къде се обработват данните?
Във Finura DPIA стана централният управленски документ. Тя не отмени старта. Тя превърна рискова идея в контролиран план за внедряване.
Изрично съгласие и проблемът с принуденото удобство
Биометричните програми често разчитат на съгласие, защото това изглежда интуитивно. Лицето регистрира своето лице, глас или пръстов отпечатък, следователно явно се е съгласило. Съгласието по GDPR трябва да бъде конкретно, информирано, недвусмислено и свободно дадено. Когато се изисква изрично съгласие по Article 9, стандартът е по-висок.
В трудов контекст или когато достъпът до необходима услуга зависи от биометрична регистрация, съгласието може да бъде трудно защитимо, освен ако не съществува реална алтернатива. „Удобна“ биометрична опция става проблемна, ако алтернативата е скрита, по-бавна, санкционираща или недостъпна.
Consent and Preference Management Policy на Clarysec Consent and Preference Management Policy предоставя оперативното правило:
[Условно] Ръководителят по защита на личните данни / PIMS мениджърът ТРЯБВА да отбележи съгласието като изрично в REG05 преди започване на обработването, когато за избраната цел се изисква изрично съгласие.
От раздел „Искане и регистриране на съгласие“, клауза на политиката 4.2.5.
За биометричните системи REG05 трябва да показва:
- Точната формулировка на съгласието.
- Биометричната цел, например автентикация, предотвратяване на измами, контрол на достъпа или проверка на самоличността.
- Дали съгласието е изрично.
- Датата, канала и версията на уведомлението.
- Методът за оттегляне.
- Небиометричната алтернатива.
- Дали отказът влияе върху достъпа до услуга.
- Системният тригер, който спира обработването след оттегляне.
SME Data Protection and Privacy Policy-sme посочва:
Защитата на личните данни още при проектирането и по подразбиране трябва да се прилага във всички нови системи и услуги
От раздел „Изисквания за управление“, клауза на политиката 5.3.1.
В биометричните системи защита на личните данни по подразбиране означава, че потребителите не се регистрират мълчаливо, суровите изображения не се съхраняват без обосновка, биометричното съпоставяне не се използва повторно за анализи без повторна оценка, а алтернативите не са скрити зад заявки към поддръжката.
Класифицирайте пълния набор от биометрични данни
Биометрична система не може да бъде управлявана, ако биометричните данни са невидими в инвентара на активите.
Enterprise Data Classification and Labeling Policy на Clarysec Data Classification and Labeling Policy посочва:
Гарантира, че личните данни, попадащи в обхвата на GDPR, DORA или други закони за поверителност, са правилно класифицирани (напр. маркирани като „Поверителни“ или „Ограничени“).
От раздел „Роли и отговорности“, клауза на политиката 4.6.1.
За МСП Data Classification and Labeling Policy-sme Data Classification and Labeling Policy - SME установява очакването за защита:
Всички данни, класифицирани като „Поверителни“, трябва да получават най-високото ниво на защита:
От раздел „Изисквания за управление“, клауза на политиката 5.2.
Класификацията трябва да включва повече от базата данни с шаблони:
| Обект на данни | Защо е важен | Типично класификационно третиране |
|---|---|---|
| Сурово изображение или аудио при заснемане | Може да разкрива биометрични характеристики и допълнителни лични данни | Ограничени или най-висока чувствителност |
| Биометричен шаблон | Използва се за еднозначна идентификация или проверка | Ограничени или най-висока чувствителност |
| Резултат от съпоставяне | Може да повлияе на достъп, клиентски онбординг или резултати при измами | Поверителни или Ограничени |
| Метаданни за регистрация | Свързват лице, устройство, време, местоположение и метод | Поверителни |
| Журнали за неуспешно съпоставяне | Могат да разкрият поведенчески модели или събития на фалшиво отхвърляне | Поверителни |
| Експорти за поддръжка от доставчика | Често се пропускат при отстраняване на проблеми | Ограничени, ако са биометрични или свързани с идентичност |
| Резервни копия и моментни снимки | Риск при съхранението и изтриването | Същото като изходните данни |
ISO/IEC 27001:2022 подсилва тази дисциплина. Clauses 4.1 до 4.4 изискват организацията да определи контекста, изискванията на заинтересованите страни, обхвата на ISMS и зависимостите. Clauses 6.1.1 до 6.1.3 изискват оценка на риска, третиране на риска, Декларация за приложимост и одобрение от собственик на риска. Ако биометричните системи влияят върху поверителността, целостта, наличността или защитата на личните данни, те трябва да бъдат включени в обхвата.
Контроли за сигурност: шифроването е само един слой
Биометричната сигурност изисква многостепенен контрол. Шифроването е важно, но не може да коригира слабо правно основание, прекомерно съхранение, неконтролиран достъп на доставчика или липсващи доказателства за изтриване.
Фазата Controls in Action, Step 20, в Zenith Blueprint обяснява ISO/IEC 27002:2022 контрол 8.24, Използване на криптография:
Този контрол не е просто „включване на шифроването“; той изисква криптографията да бъде вградена в дизайна, политиките и управлението на жизнения цикъл на организацията.
PII Security and Access Control Policy на Clarysec PII Security and Access Control Policy задава правилото на PIMS за чувствителни лични данни:
[И двете] Ръководителят по информационна сигурност ТРЯБВА да определи изискванията за шифроване или одобрени компенсиращи защитни мерки в REG12, преди лични данни с високо въздействие, чувствителни лични данни или лични данни, предавани извън организацията, да бъдат съхранявани, предавани или направени достъпни.
От раздел „Шифроване и сигурно съхранение“, клауза на политиката 4.5.1.
REG12 трябва да дефинира биометрични защитни мерки като шифроване на данни в покой, шифроване на данни при пренос, собственост върху ключове, ротация на ключове, администраторска MFA, одобрение на достъп, разделяне между данни за идентичност и биометрични шаблони, регистриране на събития по регистрация, съпоставяне, експорт и изтриване, мониторинг за необичаен достъп до шаблони, сигурно изтриване и критерии за задействане на инцидент при компрометиране на шаблон.
В Zenith Controls ISO/IEC 27002:2022 контрол 5.17, Информация за автентикация, и 8.5, Сигурна автентикация, са особено важни, защото биометрията често е вградена в потоци за автентикация. Въпросът не е само дали биометричният вход е сигурен. Въпросът е дали резервните методи, потоците за възстановяване, откриването на живост, привилегированият достъп и пътищата за заобикаляне на биометрията също са контролирани.
Съхранение, изтриване и биометричното гробище
Биометричните системи често съхраняват повече данни, отколкото екипите осъзнават: неуспешни регистрации, стари шаблони, неактивни потребители, пакети за поддръжка, архивирани бази данни, моментни снимки и резервни копия. Това създава проблема с биометричното гробище. Данните вече не са оперативно полезни, но остават силно чувствителни.
Enterprise Data Protection and Privacy Policy посочва:
Личната информация (PII) не трябва да се съхранява по-дълго от необходимото.
От раздел „Изисквания за прилагане на политиката“, клауза на политиката 6.5.1.
Фазата Controls in Action, Step 19, в Zenith Blueprint обяснява ISO/IEC 27002:2022 контрол 8.10, Изтриване на информация:
Този контрол гарантира, че данните не се съхраняват по-дълго от необходимото, и когато вече не са необходими, трябва да бъдат изтрити сигурно и надеждно.
За биометричните данни изтриването трябва да бъде заложено в системния дизайн. Правилата трябва да обхващат оттегляне на съгласие, закриване на акаунт, прекратяване на трудово правоотношение, неуспешен онбординг след изтичане на сроковете за обжалване, неактивни акаунти, замяна на устройство, прекратяване на договор с доставчик, правно задържане, изтичане на срока на резервни копия и криптографско изтриване, когато е приложимо.
Одиторите няма да приемат „доставчикът обработва изтриването“, освен ако не можете да докажете как, кога, при какъв тригер и с какви доказателства.
Управление на доставчици: доставчикът е част от контролната среда
Повечето организации не изграждат биометрични механизми от нулата. Те разчитат на доставчици за лицево съпоставяне, гласова проверка, откриване на живост, хардуер за контрол на достъпа, SDK, оценяване на риска от измама, облачно съхранение или анализи за поддръжка. Това превръща управлението на доставчици в централен елемент.
Enterprise Data Protection and Privacy Policy изисква повторна оценка на доставчиците:
Екипите по закупуване, правни въпроси и съответствие трябва да проверяват съответствието с Article 28 от GDPR и да изискват годишна повторна оценка на всички високорискови доставчици.
От раздел „Прилагане и съответствие“, клауза на политиката 8.5.2.
Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy добавя контролна точка за одобрение в PIMS:
[Условно] Длъжностното лице по защита на данните / съветникът по защита на личните данни ТРЯБВА да предостави становище в REG04 или REG12 преди одобряване на взаимоотношение, включващо висок остатъчен риск за защитата на личните данни, лични данни от специална категория, мащабно обработване, систематично наблюдение или нерешена класификация на ролите.
От раздел „Надлежна проверка и оценка на риска“, клауза на политиката 4.2.4.
SME Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME напомня на по-малките предприятия, че договорите са контролна повърхност:
Договорите трябва да включват задължителни клаузи, обхващащи:
От раздел „Изисквания за управление“, клауза на политиката 5.3.
Фазата Controls in Action, Step 23, в Zenith Blueprint описва ISO/IEC 27002:2022 контрол 5.20, Адресиране на информационната сигурност в споразуменията с доставчици:
Когато става въпрос за доставчици, доверието не може да почива на предположения. То трябва да бъде договорно закрепено.
Биометричните договори трябва да обхващат роля на обработващ лични данни, ограничение на целите, одобрение на подизпълнители по обработване, местоположение на данните, шифроване, контроли на достъпа, уведомяване при инцидент, права на одит, изтриване, връщане на данни, достъп за поддръжка, съдействие при нарушение, ограничения за обучение на модели и съдействие при изход.
За финансови субекти, попадащи в обхвата на DORA, доставчиците на биометрична идентичност може да бъдат доставчици на ИКТ услуги от трета страна. DORA се прилага от 17 януари 2025 г. и изисква финансовите субекти да управляват ИКТ риска, докладването на инциденти, тестването на оперативната устойчивост и риска от трети страни в областта на ИКТ. Ако биометричният онбординг поддържа критична или важна функция, договорите с доставчици, ескалацията при инциденти, тестването на устойчивостта и плановете за изход стават доказателства за оперативна устойчивост, както и доказателства за защита на личните данни.
NIS2 също е релевантна за много доставчици на облачни услуги, SaaS, управлявани услуги, управлявани услуги за сигурност, цифрова инфраструктура и управление на ИКТ услуги. Нейните очаквания за управление на риска се припокриват силно с ISO/IEC 27001:2022 и доказателствената верига за биометричен PIMS.
Съпоставяне на изискванията за съответствие между рамки за управление на биометрични данни
Управлението на биометрични данни не трябва да създава отделни силози за GDPR, ISO/IEC 27701:2025, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 и COBIT 19. Един модел на доказателства може да поддържа множество задължения.
| Управленски въпрос | GDPR | ISO/IEC 27001:2022 и ISO/IEC 27002:2022 | Релевантност за NIS2 и DORA | Одитна перспектива по NIST CSF 2.0 и COBIT 19 |
|---|---|---|---|---|
| Правно основание и условие за специална категория | Articles 6 and 9 | Контекст на ISMS, правни изисквания, третиране на риска и 5.34 Поверителност и защита на личната информация | Отчетност на ръководството и предоставяне на регулирани услуги | Резултатите GOVERN и целите на управлението изискват задълженията да са известни и управлявани |
| DPIA и риск за защитата на личните данни | Отчетност по Article 5, DPIA по Article 35, когато се изисква | Clauses 6.1.1 до 6.1.3 за оценка и третиране на риска, SoA, мониторинг и подобрение | Пропорционално управление на риска и ефективност на контролите | Апетит за риск, профили, съгласуване с корпоративния риск и увереност |
| Автентикация и достъп | Цялостност и поверителност | 5.17 Информация за автентикация, 8.5 Сигурна автентикация, контрол на достъпа, регистриране и криптография | MFA или непрекъсната автентикация, когато е подходящо, контроли за ИКТ риск | Идентичност, автентикация, минимално необходим достъп, резултати от регистриране и мониторинг |
| Обработване от доставчици | Задължения на обработващия лични данни по Article 28 | 5.19 до 5.22 сигурност на доставчиците и контроли за ИКТ веригата на доставки | Сигурност на веригата на доставки, риск от трети страни в областта на ИКТ, стратегии за изход | Жизнен цикъл на управление на риска във веригата на доставки, договори, надлежна проверка и мониторинг |
| Реагиране при инциденти | Оценка на нарушение на сигурността на личните данни и задължения за уведомяване | Планиране, оценка, реагиране, доказателства и извличане на поуки при инциденти | Поетапно докладване по NIS2, процес при съществен ИКТ инцидент по DORA | Откриване, реагиране, възстановяване, уведомяване на заинтересованите страни и цялост на доказателствата |
| Съхранение и изтриване | Ограничение на съхранението и изтриване | 8.10 Изтриване на информация, класификация и управление на архивирането | Устойчивост, непрекъсваемост и сигурно управление на жизнения цикъл | Защита на данните, проверка на резервни копия, документация за възстановяване и контроли по жизнения цикъл |
За субекти по NIS2 значимите инциденти може да изискват ранно предупреждение в рамките на 24 часа, уведомяване за инцидент в рамките на 72 часа и окончателен доклад в рамките на един месец. Ако платформа за биометрична идентичност бъде нарушена или компрометирана, работните процеси за докладване по сигурност, защита на личните данни и оперативна устойчивост може да се задействат едновременно.
Одитна перспектива: какво ще попитат проверяващите
Различните одитори тестват управлението на биометрични данни от различни ъгли. Clarysec използва Zenith Controls, за да свърже контролите по ISO/IEC 27002:2022 с доказателства за защита на личните данни, автентикация, доставчици, шифроване, изтриване, инциденти и одит.
| Одитна перспектива | Какво ще попитат | Доказателства, които Clarysec подготвя |
|---|---|---|
| Одитор по ISO/IEC 27001:2022 | Включено ли е биометричното обработване в обхвата, оценено ли е за риск, третирано ли е и подкрепено ли е от SoA? | Декларация за обхвата, регистър на риска, план за третиране, SoA, одобрения на политики, тестване на контролите |
| Одитор по ISO/IEC 27701:2025 PIMS | Можете ли да докажете цел, правно основание, роля, DPIA, обработване на права, съхранение и управление на обработващи лични данни? | REG02, REG04, REG05, REG12, уведомления за поверителност, график за сроковете за съхранение, надлежна проверка на доставчиците |
| Одитор или регулатор с фокус върху GDPR | Обосновано, прозрачно, необходимо, пропорционално и сигурно ли е обработването по Article 9? | Запис за правно основание, условие за специална категория, DPIA, доказателства за съгласие, журнали за изтриване |
| Оценител по NIST CSF | Внедрени ли са резултатите за управление, идентичност, защита на данните, мониторинг, реагиране и възстановяване? | Съпоставяне на CSF профил, план за пропуските, прегледи на правата за достъп, журнали, записи за инциденти, доказателства за възстановяване |
| Одитор по COBIT 19 или ISACA | Оперативно ефективни ли са целите на управлението, собствеността върху риска, увереността, контролът на промените и надзорът върху доставчици? | RACI, преглед от ръководството, показатели за контролите, преглед на трети страни, одитна следа, коригиращи действия |
| Проверяващ готовността по DORA или NIS2 | Може ли прекъсване или компрометиране на биометричната услуга да бъде управлявано, докладвано и възстановено? | Наръчник за класификация на инциденти, клаузи за доставчици, BIA, тестове за непрекъсваемост, работен процес за докладване |
Честите одитни констатации включват технически контроли без управленски решения, правно основание по Article 6 без условие по Article 9, DPIA, извършени след въвеждане в експлоатация, записи за съгласие без тригери за изтриване, договори с доставчици без специфични за биометрията клаузи и наръчници за инциденти, които третират компрометирането на биометричен шаблон като обикновено компрометиране на удостоверителни данни.
Практически работен процес за одобрение при биометричен онбординг
Организация, ръководена от Clarysec и обработваща лицева проверка при клиентски онбординг, би следвала структуриран път:
- Създаване на запис за обработване в REG02.
- Идентифициране на ролите на администратор, обработващ лични данни и подизпълнител по обработване.
- Записване на правното основание по Article 6 и условието по Article 9, когато биометричните данни се използват за еднозначна идентификация.
- Записване на категории данни като selfie, изображение на документ, биометричен шаблон, резултат от проверка на живост, резултат от съпоставяне, одитни журнали и експорти за поддръжка.
- Задействане на REG04 DPIA преди внедряване.
- Оценяване на необходимостта, пропорционалността и небиометричните алтернативи.
- Дефиниране на изрично съгласие в REG05, когато се изисква.
- Класифициране на суровите изображения и шаблони като Ограничени или с най-висока чувствителност.
- Дефиниране на изискванията за сигурност в REG12 за шифроване, управление на ключове, достъп, регистриране, мониторинг, ограничения за експорт и изтриване.
- Преглед на надлежната проверка на доставчика, списъка с подизпълнители по обработване, местоположението на хостинга, уведомяването при инцидент, правата на одит и процеса за удостоверение за изтриване.
- Добавяне на правила за съхранение при успешен онбординг, неуспешен онбординг, оттеглено съгласие, обжалвания, разследвания на измами и резервни копия.
- Одобряване на остатъчния риск с посочени собственици.
- Съхраняване на одитни доказателства в хранилището за доказателства на PIMS.
- Преглед на ефективността след старта и след промени при доставчика.
Това дава на CISO технически доказателства за контроли, на DPO — отчетност за защитата на личните данни, на закупуването — договорни контролни точки, на продукта — път към стартиране, а на одиторите — проследима история.
Превърнете биометричния риск в доверие
Във Finura Мария не отмени биометричната функция. Тя я пренастрои. Продуктовият и инженерният екип интегрираха изискванията на PIMS в жизнения цикъл на разработката. Потокът за съгласие стана изричен и отделен. Договорът с доставчика получи по-силни ангажименти за изтриване, одит, нарушения и подизпълнители по обработване. REG02, REG04, REG05 и REG12 станаха гръбнакът на доказателствата. Криптографско изтриване беше внедрено за оттеглени данни. Стартирането се измести с едно тримесечие, но се случи върху основа на доверие.
Това е смисълът на управлението на биометрични данни. То не забранява иновацията. То я прави защитима.
Следващите ви стъпки са ясни:
- Инвентаризирайте всеки биометричен случай на употреба, включително достъп до работното място, клиентски онбординг, автентикация на устройства, предотвратяване на измами и гласова проверка.
- Класифицирайте данните и потвърдете дали се използват за еднозначна идентификация.
- Запишете правното основание и всяко условие за специална категория в регистъра на дейностите по обработване.
- Извършете DPIA преди започване на ново или съществено променено обработване.
- Валидирайте изричното съгласие и алтернативите, когато се изискват.
- Прегледайте договорите с доставчици и подизпълнителите по обработване.
- Дефинирайте доказателства за шифроване, достъп, регистриране, мониторинг и изтриване.
- Съпоставете доказателствата с очакванията на ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 и COBIT 19.
Clarysec може да ви помогне да превърнете управлението на биометрични данни в готов за одит работен процес в PIMS. Започнете с Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, валидирайте съпоставянето между рамки с Zenith Controls: The Cross-Compliance Guide Zenith Controls и операционализирайте доказателствата чрез набора политики на Clarysec за ISO/IEC 27701:2025 PIMS, включително PII Processing Inventory and Lawful Basis Policy, Privacy Risk Assessment and DPIA Policy, Consent and Preference Management Policy, PII Security and Access Control Policy и Processor, Subprocessor and Third-Party Privacy Management Policy.
Биометрията може да засили сигурността и да подобри потребителското изживяване. Само управляваната биометрия печели трайно доверие.
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council