Когда вы внедряете чат-бот и интегрируете коммуникации с бизнес-процессами, переписка попадает в контур чувствительных данных. На практике именно на этом участке чаще всего нет единого понимания: что подрядчик обязан обеспечить, где и как это хранится, кто имеет доступ, как ведется аудит действий и что происходит при сбоях.
Ваша цель на ступени Ханта 3 — не «получить успокоение», а заранее зафиксировать критерии, по которым потом можно принять результат. Если требования размыты, риски выходят за пределы ИТ: страдает доверие клиентов, растут простои из-за ошибок доступа, а исправлять приходится уже после того, как система набрала обороты.
Если не закрыть эти вопросы заранее, обычно появляется несколько последствий:
- переписку сложно найти или восстановить из-за отсутствия связного контура хранения и статуса данных
- доступ к данным оказывается шире, чем вы планировали, и часть действий не оставляет следов
- при ошибке или сбое синхронизация данных деградирует без прозрачного плана восстановления
- вы не можете подтвердить, какие данные хранились, в каких сроках и по каким правилам
- инциденты обрабатываются дольше, потому что заранее не определены роли и порядок действий
Типичная ситуация из практики: команда слышит «мы все зашифруем», но в ТЗ не прописаны уровни доступа, журналирование и политика хранения. В итоге через некоторое время выясняется, что часть администраторских действий не отражается в аудит-логах, а сроки хранения завязаны на настройки сторонних сервисов, к которым у бизнеса нет понятного доступа и контроля.
Безопасность и хранение переписки: что должен обеспечить подрядчик
1) Где хранится переписка и связанные метаданные
Попросите схему контура хранения: какие компоненты участвуют, какие данные попадают в хранилище, и где фиксируется связь с заявкой/клиентом.
2) Шифрование при передаче и при хранении
Важно не только «шифруем», а как именно: протоколы обмена и защита данных на диске, а также как обеспечивается управление ключами.
3) Управление доступом и роли
Требуйте разграничение прав (минимально необходимые роли), отдельные сценарии для поддержки и для администрирования, а также подтверждение, как предотвращается лишний доступ.
4) Аудит и журналирование действий
Нужен журнал: кто, когда и что сделал (включая административные действия), и как этот журнал сохраняется и доступен для проверки.
5) Политика хранения и удаления
Определите сроки хранения, правила удаления и порядок, как реализуется изменение статусов (например, завершение обращения) без «ручных чисток».
6) Резервное копирование и восстановление
Попросите описание RPO/RTO в терминах бизнеса и порядок восстановления после сбоя, чтобы не оказалось, что бэкапы есть только «в документах».
7) Надежность синхронизации и обработка ошибок
Спросите, как защищаются данные от повторов и разъездов версий при сбоях, и где видно, что событие дошло до системы хранения.
8) Сторонние компоненты и субподрядчики
Если используются внешние сервисы, зафиксируйте, какие данные туда уходят, какие у них правила доступа и как вы контролируете цепочку передачи.
Что сделать прямо сейчас
- Возьмите этот список и превратите его в раздел ТЗ: по каждому пункту запрашивайте описание, как это будет реализовано и как проверяется.
- Попросите у подрядчика материалы для приемки: схема данных, правила доступа, аудит-логика и политика хранения/удаления.
- Зафиксируйте, кто отвечает за безопасность в вашем проекте и как вы будете видеть статус обработки инцидентов.
Можете ли вы ответить, где именно хранится переписка и кто имеет к ней доступ внутри вашей команды?
Есть вопросы — напишите в Telegram @sergio_4e, подскажу, какие критерии безопасности и хранения лучше зафиксировать в вашем ТЗ.