«id =» main «> Поделиться

GDPR, то есть Общее положение о защите данных, — это постановление ЕС от 27 апреля 2016 года, состоящее из 99 статей, устанавливающее новые требования к ИТ-системам. «Новые требования» в данном случае, конечно, эвфемизм. Чтобы соответствовать им, все ИТ-системы и бизнес-процессы, обрабатывающие персональные данные, должны будут претерпеть значительные изменения, непредвиденные во время создания ИТ-систем или построения бизнес-модели. Адаптация будет трудоемкой и дорогостоящей. К счастью, законодатели назначили дату вступления в силу постановлений 25 мая 2018 года. К сожалению, скоро осталось меньше года. Исследования даже показывают, что большинство организаций, подпадающих под действие правил GDPR, еще не приступили к корректировке. Итак, время идет. Что ты можешь сделать? Как сократить расходы? Как превратить необходимость в силу организации? На эти вопросы мы постараемся ответить в этой статье.

Самые важные правила

Вопрос защиты персональных данных нам уже известен в виде должности Администратора информационной безопасности. Серьезные утечки данных, часто затрагивающие десятки или сотни тысяч людей, означали, что защита данных была признана недостаточно эффективной. В мире цифровой экономики, которую должны стимулировать, например, Директива о платежных услугах на внутреннем рынке (PSD2) еще больше осложняется ситуацией.

В этом дивном новом цифровом мире теперь должны применяться следующие 6 основных принципов (статья 5):

законность, честность и прозрачность ограничение цели — минимизация данных novum — новое ограничение правильности хранения — целостность и конфиденциальность novum

Регламент будет применяться ко всем организациям, включая те, которые предоставляют бесплатные услуги из любого места на земле, до тех пор, пока они обрабатывают личные данные граждан Европейского Союза. Американские компании уже подсчитывают затраты на регулирование.

Чтобы обеспечить реализацию этих принципов, регулирование вводит следующие подробные решения:

Статья 35. Оценка воздействия на защиту данных. Для определенных категорий обработки: автоматическая, крупномасштабная, включая профилирование физических лиц, влияющее на их статус, необходимо проводить оценку воздействия на защиту данных; оценка основана на анализе рисков (ст. 39).

Ст. 7 (2). Согласие на обработку требует четкого определения объема согласия и возможности отзыва согласия.

Статья 17. Право на удаление (право на забвение) предоставляется по истечении периода, необходимого для обработки, а также в случае незаконной обработки данных.

Ст. 25. При проектировании ИТ-систем необходимо учитывать соблюдение защиты данных при разработке в форме, например, псевдонимизации/минимизации и защиты по умолчанию (ограничение доступа к данным минимальным количеством людей, необходимых для достижения цели обработки).

Ст. 30. Регистрация деятельности по обработке данных

Статья 32. Безопасность обработки включает, согласно оценке риска: псевдонимизацию, шифрование, целостность, доступность, долговечность и воспроизводимость.

Ст. 33-34. Уведомление надзорных органов о нарушении правил обработки данных (в течение 72 часов с момента обнаружения) необходимо в любом случае, когда существует риск нарушения прав и свобод физического лица. Аналогичным образом необходимо уведомить физическое лицо, чьи персональные данные были обработаны в нарушение правил, если риск для их прав и свобод высок.

Проблемы

Оптимизация времени реализации Основная проблема — это короткое время, оставшееся до реализации (315 дней на дату публикации)

Возможные изменения в толковании подробных положений Многие положения по-прежнему требуют интерпретации в отношении подробного понимания отдельные положения. Любое решение должно учитывать этот риск и обеспечивать гибкость.

Инвентаризация всех наборов персональных данных и способов их обработки и передачи. В более крупных организациях, особенно в тех, которые были построены на протяжении многих лет и имеют полевые отделения и весьма независимые отделы, они часто имеют несколько сотен различных ИТ-систем и бумажных наборов данных. Их правильный диагноз может быть трудоемким. Выявление повторяющихся данных уже было частью проектов управления основными данными. Учитывая тот факт, что в большинстве случаев эти проекты не были успешно завершены, задача возвращается в новой форме.

Модификация проверенных бизнес-процессов и документов Предприятия разработали, иногда за счет многолетнего непрерывного улучшения, свои бизнес-процессы обслуживания клиентов, создавая их конкурентные отличительные черты. Пришло время просмотреть и снова проверить их на соответствие нормативным требованиям. Ключевыми вопросами здесь являются минимизация данных, особые правила, касающиеся профилирования людей, безопасная передача данных.

Оптимизация затрат на модификацию ИТ-систем (новые технологии) ИТ-системы с точки зрения возможности адаптации к нормативным требованиям условно делятся на 3 группы:

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

Уровень сложности во многом зависит от технологии и архитектуры. Решения по ограничению изменений путем переноса обработки данных из развертываемых систем обеспечат больший контроль над затратами на адаптацию.

Дополнение функциональности унаследованных ИТ-систем Многие ИТ-системы все еще работают, хотя гарантийный и послегарантийный период истек, производитель больше не существует или утратил свои компетенции. Любая модификация такой системы может оказаться очень дорогостоящей или просто невозможной. Настоятельно рекомендуется решение, позволяющее избежать модификации таких систем.

Треугольник предположений Сокращение времени ожидания в пользу Снижение затрат Снижение операционного риска Модель

Решение, которое объединяет ИТ-системы и бизнес-процессы, должно соответствовать минимальной концептуальной модели данных. Центральным узлом модели является индивидуальная цель обработки, с которой согласился субъект (физическое лицо), все в контексте бизнес-процесса, требуемых данных и людей, участвующих в нем. Процесс должен свести к минимуму раскрытие личных данных путем: ограничения данных до необходимого минимума и ограничения числа лиц, обрабатывающих их.

GDPR Элементы решения GDPRE Элементы решения Элементы решения

Использование машинного анализа данных и методов науки о данных Обеспечение соответствия требует использования методов массового анализа машинных данных. Открытые аналитические платформы предлагают здесь наибольшие преимущества, обеспечивая гибкость — с одной стороны, в отношении зачастую довольно сложной топографии данных в организации, а с другой стороны, в отношении потенциальных изменений в интерпретации нормативных требований.

Сведение к минимуму объема модификаций в существующих информационных системах Элементом решения, предложенного Linux Polska, является максимальное использование данных, генерируемых во время обработки данных, без вмешательства в структуры данных и процессы систем, подлежащих контролю. Для этой цели используются методы анализа машинных данных с использованием мониторинга вызовов, которые, возможно, улучшают реактивность систем за счет незначительных дополнений кода — в зависимости от архитектуры и технологии систем.

Панель соответствия Важный элемент для Персонального Data Inspector и другие ответственные лица позволяют быстро просмотреть соблюдение правил. Постоянная переоценка рисков на основе данных из кабины экипажа — существенная добавленная стоимость решения.

Отчеты о несоответствии Отчеты о несоответствии являются важным элементом внутренней коммуникации — для выявления «горячих точек» в бизнес-процессах, где чаще всего происходят инциденты с нарушением нормативных требований, и на более позднем этапе их анализа. С другой стороны, это основной материал для сотрудничества с надзорными органами по реализации Регламента.

Предупреждения о несоблюдении В некоторых случаях, требующих немедленного ответа, лица, ответственные за защиту данных, получат сообщение сразу после наступления события/событий, указывающих на вероятность нарушения Правил.

Анализ инцидентов На основе отчетов и дополнительных данных можно определить причины инцидента с помощью метода анализа первопричин (RCA). Чтобы углубить анализ, точки в бизнес-процессах и вспомогательных системах, в которых были выявлены причины инцидентов, будут проанализированы с точки зрения типов ошибок и их последствий (FMEA). Этот анализ, основанный на подходе, основанном на оценке риска, укажет на ключевые элементы улучшения процесса. Необходимым элементом анализа также является решение о необходимости предпринять шаги, связанные с уведомлением надзорных органов и субъекта данных.

Связь с SIEM Утечка персональных данных или другие действия, нарушающие положения Положения составляют элемент широко понимаемой безопасности ИТ. Естественным следствием этого является связывание решения, поддерживающего GDPR, с системами SIEM. Решение, предлагаемое Linux Polska, предлагает такую ​​интеграцию.

Подробнее о IT-решениях, поддерживающих GDPR, читайте в следующих статьях.