Регламент реагирования на инциденты

г. Санкт-Петербург, 22.04.2025

1. Общие положения

1.1. Настоящий регламент устанавливает порядок выявления, фиксации, анализа и устранения инцидентов, связанных с нарушением безопасности персональных данных (ПДн) в ООО «Персонализация».

1.2. Инцидентом считается любое событие, которое повлекло или могло повлечь:

• несанкционированный доступ к ПДн
• нарушение целостности или уничтожение ПДн
• нарушение установленных правил обработки и хранения ПДн

2. Идентификация инцидента

2.1. Инциденты могут быть выявлены:

• сотрудниками при выполнении обязанностей
• средствами мониторинга (Grafana, Zabbix, Loki)
• в процессе аудита или ревизии
• по обращениям субъектов ПДн, третьих лиц, регуляторов

2.2. Обнаруженный инцидент подлежит обязательной регистрации.

3. Регистрация инцидента

3.1. Регистрация инцидента осуществляется через создание GitHub Issue с префиксом [Incident].

3.2. В карточке инцидента указываются:

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

3.3. Каждому инциденту присваивается уникальный ID (номер тикета в GitHub).

3.4. Ответственный инженер назначается техническим директором или CISO.

4. Классификация инцидентов

4.1. Инциденты классифицируются по уровню риска:

• Low — потенциальная угроза, не зафиксирован факт нарушения
• Medium — локальное нарушение или утечка с ограниченным воздействием
• High — подтверждённая утечка ПДн, массовое нарушение, критический сбой

4.2. Критичность влияет на срок реакции (см. раздел 5.3).

5. Реагирование и устранение

5.1. Ответственный инженер обязан:

• начать расследование в течение допустимого SLA
• собрать и проанализировать артефакты (логи Loki, события VPN, Zabbix)
• определить зону риска и возможных затронутых субъектов ПДн
• инициировать временные или постоянные меры по устранению угрозы

5.2. При необходимости принимаются действия:

• отзыв доступа
• ротация ключей/паролей
• откат инфраструктурных изменений
• изоляция или выключение сервисов

5.3. Сроки реакции:

• Low — не позднее 3 рабочих дней
• Medium — в течение 1 рабочего дня
• High — немедленная эскалация, реакция в течение 2 часов

5.4. Все действия документируются в комментариях к тикету.

6. Пост-инцидентный анализ

6.1. После устранения инцидента тикет переводится в статус resolved.

6.2. Для инцидентов уровня Medium и High подготавливается отчёт в формате Markdown, размещаемый в docs/incidents/YYYY-MM-DD-ID.md.

6.3. Отчёт содержит:

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

6.4. Доступ к отчётам ограничен (по группам GitHub или ACL в репозитории).

7. Ответственность

7.1. Несвоевременное реагирование на инциденты, игнорирование процедур фиксации и сокрытие информации об инцидентах считаются нарушением требований ИБ.

7.2. Ответственные лица несут дисциплинарную или договорную ответственность в соответствии с ТК РФ и внутренними актами.

Генеральный директор ООО «ПЕРСОНАЛИЗАЦИЯ» Кечинов М.А.