Коллеги, давайте разбираться: в чём разница между DPIA, PIA и Privacy by Design 🔎
Во-первых, начнем с терминологии! Скорее всего, вместе с DPIA (data protection impact assessment) вы уже могли видеть аббревиатуру PIA (privacy impact assessment), например, в инструменте от CNIL. Некоторые исследователи ставят между ними знак равно, а другие рассматривают DPIA как более узкое понятие (формальную процедуру исключительно для высокорисковых обработок, которая проводится контролёром перед их запуском).
При этом некоторые privacy-профессионалы не относятся тепло ни к DPIA, ни к PIA.
Многие считают недостатком DPIA тот факт, что по умолчанию эта процедура учитывает только прямые последствия нарушений приватности, но не всегда обращает внимание на вторичные. Например, даётся ответ на вопрос, что сделать, чтобы не допустить утечки детализированной аналитики из продукта. Однако не всегда будет учитываться, а какова вероятность того, что человек подвергнется буллингу, если эта база аналитических данных всё-таки утечет.
Вторая и главная претензия в сторону PIA и DPIA - они направлены на снижение последствий рисков, а не на их недопущение. Именно в этом и выигрывает подход Privacy by Design.
📄 Джейсон Кронк проводит аналогию с человеком, который шпионит за своим супругом. Шпион сделает всё, чтобы снизить влияние нарушения того, за кем он следит: расставит вещи в том же порядке после рытья в них, сделает так, чтобы камеры было трудно найти, использует скрытное наблюдение и так далее. Но шпионаж при этом всё ещё остался шпионажем. Так и PIA / DPIA - к сожалению, чаще они работают не для того, чтобы не допускать риски, а для того, чтобы эти уже оправдать возникшие риски «костылями» в виде защитных мер.
У DPIA в этом вопросе небольшое преимущество перед PIA, ведь контролёр формально обязан проводить его до запуска обработки. Но даже это не обязывает запускать его на более ранних стадиях (до определения средств обработки). Яркий тому пример - один из самых первых вопросов, задаваемых в DPIA, какие категории персональных данных вы обрабатываете либо планируете обрабатывать. Но в тот момент, когда вы уже знаете или предполагаете, какую информацию будет обрабатывать система, решение уже принято и пространство для проектирования ограничено.
На практике, при встрече с владельцами процессов для DPIA, вы будете слышать фразы вроде «Нам нужны эти данные, чтобы сделать вот это» или «Запускаем продукт через месяц, что нам нужно сделать?»
Здесь тонка грань, где можно съехать с фактической работы с рисками на обычную легализацию процесса, где вы не станете задумываться, а есть ли в этом процессе манипуляция принятием решений или же какие-либо dark patterns. Высока вероятность ограничить себя важными, но самыми очевидными защитными мерами вроде шифрования, минимизации, контроля доступов, информирования об обработке. Это будет работать точечно, но ведь это не все варианты, как можно защитить субъекта данных.
💡 Мораль нашей высокорисковой басни: не ограничивайте себя лишний раз жёсткими рамками фреймворков. В любых правилах есть исключения, и по закону подлости, вам что-то да попадётся. И если уж вам выдалась удача работать DPO, то воспринимайте эту роль творчески и будьте открыты к изучению и применению разных подходов.
Автор: Юлия Богданова, CIPP/E, GDPR DPP, GDPR DPM, Privacy by Design
#opinion
Во-первых, начнем с терминологии! Скорее всего, вместе с DPIA (data protection impact assessment) вы уже могли видеть аббревиатуру PIA (privacy impact assessment), например, в инструменте от CNIL. Некоторые исследователи ставят между ними знак равно, а другие рассматривают DPIA как более узкое понятие (формальную процедуру исключительно для высокорисковых обработок, которая проводится контролёром перед их запуском).
При этом некоторые privacy-профессионалы не относятся тепло ни к DPIA, ни к PIA.
Многие считают недостатком DPIA тот факт, что по умолчанию эта процедура учитывает только прямые последствия нарушений приватности, но не всегда обращает внимание на вторичные. Например, даётся ответ на вопрос, что сделать, чтобы не допустить утечки детализированной аналитики из продукта. Однако не всегда будет учитываться, а какова вероятность того, что человек подвергнется буллингу, если эта база аналитических данных всё-таки утечет.
Вторая и главная претензия в сторону PIA и DPIA - они направлены на снижение последствий рисков, а не на их недопущение. Именно в этом и выигрывает подход Privacy by Design.
📄 Джейсон Кронк проводит аналогию с человеком, который шпионит за своим супругом. Шпион сделает всё, чтобы снизить влияние нарушения того, за кем он следит: расставит вещи в том же порядке после рытья в них, сделает так, чтобы камеры было трудно найти, использует скрытное наблюдение и так далее. Но шпионаж при этом всё ещё остался шпионажем. Так и PIA / DPIA - к сожалению, чаще они работают не для того, чтобы не допускать риски, а для того, чтобы эти уже оправдать возникшие риски «костылями» в виде защитных мер.
У DPIA в этом вопросе небольшое преимущество перед PIA, ведь контролёр формально обязан проводить его до запуска обработки. Но даже это не обязывает запускать его на более ранних стадиях (до определения средств обработки). Яркий тому пример - один из самых первых вопросов, задаваемых в DPIA, какие категории персональных данных вы обрабатываете либо планируете обрабатывать. Но в тот момент, когда вы уже знаете или предполагаете, какую информацию будет обрабатывать система, решение уже принято и пространство для проектирования ограничено.
На практике, при встрече с владельцами процессов для DPIA, вы будете слышать фразы вроде «Нам нужны эти данные, чтобы сделать вот это» или «Запускаем продукт через месяц, что нам нужно сделать?»
Здесь тонка грань, где можно съехать с фактической работы с рисками на обычную легализацию процесса, где вы не станете задумываться, а есть ли в этом процессе манипуляция принятием решений или же какие-либо dark patterns. Высока вероятность ограничить себя важными, но самыми очевидными защитными мерами вроде шифрования, минимизации, контроля доступов, информирования об обработке. Это будет работать точечно, но ведь это не все варианты, как можно защитить субъекта данных.
💡 Мораль нашей высокорисковой басни: не ограничивайте себя лишний раз жёсткими рамками фреймворков. В любых правилах есть исключения, и по закону подлости, вам что-то да попадётся. И если уж вам выдалась удача работать DPO, то воспринимайте эту роль творчески и будьте открыты к изучению и применению разных подходов.
Автор: Юлия Богданова, CIPP/E, GDPR DPP, GDPR DPM, Privacy by Design
#opinion