Одна платформа может подпадать под несколько режимов данных
Региональный сервис может принимать запрос клиента в одной стране, хранить его в другой и позволять команде поддержки из третьей страны отвечать на него. Начните с этой реальной операции. Назовите сторону, решающую, зачем и как используется информация, сторону, эксплуатирующую систему, и каждого поставщика или сотрудника, который может ее видеть. Общий логотип или CRM не отменяют местную роль каждой компании группы.
Определите категории информации и вовлеченных лиц: клиентов, сотрудников, соискателей или посетителей. Отделите сведения, необходимые для оказания услуги, от аналитики, маркетинга и необязательных функций. Если ответ различается для двух рынков, ведите отдельные записи вместо одного регионального заявления, которое ни одна команда не сможет применить.
Проследите цепочку от сбора до удаления
Составьте схему формы или экрана приложения, точки сбора, облачного хостинга, резервных копий, доступа поддержки, внутренней передачи, выгрузок поставщикам и окончательного удаления. Записывайте страны хранения и доступа, а не только расположение сервера. Удаленный доступ и копии аварийного восстановления могут изменить фактический поток. Сравните схему с договорами, разрешениями и журналами доступа.
Пройдите реальный запрос клиента от подачи до разрешения. Какая организация отвечает и в какой системе хранится аудиторский след? Если поставщик поддержки может скачивать записи, определите его средства контроля доступа и процесс возврата или удаления. Проверьте, действительно ли уведомление о конфиденциальности соответствует продукту и цепочке поставщиков, а не копирует описание, написанное для другого сервиса.
Проверяйте обязанности по каждому рынку
Для каждого места, где возникает роль или поток данных, попросите квалифицированных местных консультантов проверить действующие требования к уведомлениям, запросам субъектов данных, хранению, безопасности, инцидентам и международным передачам. Записывайте изученное правило или источник, дату и факты бизнеса, от которых зависит консультация. Не полагайте, что шаблонный пункт одного рынка подходит для другого.
Ставьте каждый открытый вопрос рядом с его владельцем и планируемой датой решения. Матрица по странам должна различать подтвержденные факты, ожидаемые юридические заключения и изменения, которые еще внедряются в продукт. Она не должна превращать неопределенный статус в зеленую отметку из-за приближающейся даты запуска.
Перепроверяйте после изменений продукта или поставщиков
Новый поставщик аналитики, место резервного копирования, маркетинговая аудитория или региональная команда поддержки могут сделать вчерашнюю схему устаревшей. Установите для продуктовой и закупочной команд правило: любое изменение возвращает предложение на проверку потоков данных и договоров. Храните датированные версии, чтобы сотрудники знали, какой процесс действует сейчас.
Отрепетируйте один запрос субъекта данных и один сценарий инцидента. Определите, кто получает сообщение, кто может извлечь данные, кто принимает решение об ответе и кто связывается с поставщиками. Сравните репетицию с письменными сроками и полномочиями. Если фактическую запись нельзя найти или удалить описанным способом, исправьте процесс, прежде чем представлять его как обещание.
Досье первой проверки
- Действующие экраны продукта, уведомления и условия для клиентов по каждому рынку.
- Категории данных, схемы потоков и ролей для каждой организации.
- Договоры с поставщиками, места хостинга и резервного копирования, разрешения доступа.
- Правила хранения и удаления, проверенные на действующих системах.
- Датированные местные консультации, нерешенные вопросы и ответственные за инциденты и запросы субъектов данных.
В этом может помочь наша практика защиты данных и конфиденциальности.