Куда я попал?
Приказ ФСТЭК России № 239 от 25.12.2017
Состав мер по обеспечению безопасности для значимого объекта соответствующей категории значимости
ИНЦ.0
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
ИНЦ.0 Регламентация правил и процедур реагирования на компьютерные инцидентыОбязательно для категории значимости К1 К2 К3
Похожие требования
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 3
6.3. Кредитные организации должны обеспечивать выполнение следующих требований к выявлению, регистрации инцидентов операционной надежности и реагированию на них, а также восстановлению выполнения технологических процессов и функционирования объектов информационной инфраструктуры после реализации таких инцидентов:
- выявление и регистрация инцидентов операционной надежности;
- реагирование на инциденты операционной надежности в отношении критичной архитектуры;
- восстановление функционирования технологических процессов и объектов информационной инфраструктуры после реализации инцидентов операционной надежности;
- проведение анализа причин и последствий реализации инцидентов операционной надежности;
- организация взаимодействия между подразделениями кредитной организации, а также между кредитной организацией и Банком России, иными участниками технологического процесса в рамках реагирования на инциденты операционной надежности и восстановления выполнения технологических процессов и функционирования объектов информационной инфраструктуры после реализации инцидентов операционной надежности.
ГОСТ Р № 57580.1-2017 от 01.01.2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер. Раздел 7. Требования к системе защиты информации":
РИ.7
РИ.7 Определение и назначение ролей, связанных с реагированием на инциденты защиты информации
3-О 2-Н 1-Н
3-О 2-Н 1-Н
РИ.5
РИ.5 Установление и применение единых правил регистрации и классификации инцидентов защиты информации в части состава и содержания атрибутов, описывающих инцидент защиты информации, и их возможных значений
3-О 2-Т 1-Т
3-О 2-Т 1-Т
РИ.6
РИ.6 Установление и применение единых правил реагирования на инциденты защиты информации
3-О 2-О 1-О
3-О 2-О 1-О
РИ.13
РИ.13 Установление и применение единых правил сбора, фиксации и распространения информации об инцидентах защиты информации
3-О 2-О 1-О
3-О 2-О 1-О
NIST Cybersecurity Framework (RU):
PR.IP-9
PR.IP-9: Созданы и управляются планы реагирования (реагирование на инциденты и непрерывность бизнеса) и планы восстановления (восстановление после инцидентов и аварийное восстановление)
DE.AE-5
DE.AE-5: Установлены пороги оповещения об инциденте
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
ВРВ.21.5
ВРВ.21.5 Форматов и способов реализации информационного обмена о предпринятых действиях и статусе восстановления после инцидентов внутри финансовой организации, а также с причастными сторонами в рамках восстановления после реализации инцидентов;
ВРВ.21.1
ВРВ.21.1 Целевых показателей восстановления после реализации инцидентов;
ВРВ.26.4
ВРВ.26.4 Процедур восстановления данных** с помощью резервных копий в заданных объемах (согласно ЦТВД);
ВРВ.26.2
ВРВ.26.2 Процедур восстановления выполнения бизнес- и технологических процессов финансовой организации в заданные временные периоды (согласно ЦВВ);
ВРВ.13
ВРВ.13 Разработка** состава правил и процедур (playbooks) реагирования на инциденты на основе:
- информации, полученной в рамках консультации с подразделениями, формирующими «первую линию защиты» (центрами компетенции);
- возможных сценариев реализации информационных угроз (в том числе компьютерных атак);
- сценариев реализовавшихся информационных угроз (в том числе компьютерных атак).
ВРВ.25
ВРВ.25 Разработка состава правил и процедур (playbooks) восстановления функционирования бизнес- и технологических процессов и объектов информатизации после реализации инцидентов на основе:
- информации, полученной в рамках консультации с владельцами бизнес-процессов финансовой организации;
- условий функционирования объектов информатизации;
- сценариев реализовавшихся информационных угроз.
ВРВ.26.1
ВРВ.26.1 Процедур выявления и устранения причин реализации инцидентов, в том числе путем обновления состава объектов информатизации финансовой организации;
ВРВ.43
ВРВ.43 Организация и выполнение деятельности по информированию должностного лица, ответственного за функционирование системы управления риском реализации информационных угроз, по каждому факту реализации инцидентов:
- о масштабах влияния реализации инцидента на осуществление видов деятельности финансовой организации, влиянии на фактические значения КПУР, предусмотренные ГОСТ Р 57580.3;
- о бизнес- и технологических процессах, на непрерывность выполнения которых было оказано влияние в результате реализации инцидента;
- о сроках и условиях, при которых будет восстановлено выполнение бизнес- и технологических процессов, в том числе восстановлено функционирование задействованных объектов информатизации;
- о предпринятых и запланированных действиях в рамках реагирования на инциденты и восстановления после их реализации, а также статусе выполнения соответствующих работ;
- о сведениях, которые могут быть раскрыты и доведены до потребителей финансовых услуг.
ВРВ.44
ВРВ.44 Организация и выполнение деятельности по информированию причастных сторон (за исключением клиентов финансовой организации):
- о влиянии реализации инцидента на непрерывность выполнения взаимосвязанных и взаимозависимых бизнес- и технологических процессов;
- о предпринятых и запланированных действиях в рамках реагирования на инциденты и восстановления после их реализации, а также статусе выполнения соответствующих работ.
ВРВ.26.5
ВРВ.26.5 Процедур привлечения, в случае необходимости, компетентных специалистов соответствующих организаций – поставщиков услуг;
ВРВ.21.6
ВРВ.21.6 Определение критериев оценки завершения восстановления и условий закрытия инцидента;
ВРВ.31
ВРВ.31 Организация и выполнение деятельности по проведению оценки завершения восстановления функционирования бизнес- и технологических процессов и объектов информатизации согласно определенным критериям перед принятием решения о закрытии соответствующего инцидента.
ВРВ.7.1
ВРВ.7.1 Целевых показателей реагирования на инциденты;
ВРВ.21.2
ВРВ.21.2 Ролей, связанных с восстановлением после реализации инцидентов;
ВРВ.26.8
ВРВ.26.8 Процедур формирования отчетности в рамках восстановления после реализации инцидентов;
ВРВ.21.3
ВРВ.21.3 Правил и процедур (playbooks) восстановления после реализации инцидентов;
ВРВ.21.7
ВРВ.21.7 Определение показателей оценки эффективности восстановления после реализации инцидентов.
ВРВ.45
ВРВ.45 Организация и выполнение деятельности по информированию клиентов финансовой организации в рамках взаимодействия при реализации инцидентов:
- о влиянии инцидента на предоставление финансовых и (или) информационных услуг, а также на конфиденциальность данных клиентов финансовой организации, в том числе их аутентификационных данных, используемых в рамках каналов дистанционного обслуживания;
- о планируемых сроках и условиях, которые необходимы для восстановления предоставления финансовой организацией финансовых и (или) информационных услуг;
- о рекомендуемых действиях, которые следует предпринять клиентам финансовой организации для снижения риска реализации информационных угроз.
ВРВ.7.5
ВРВ.7.5 Правил и процедур (playbooks) реагирования на инциденты;
ВРВ.21.4
ВРВ.21.4 Перечня причастных сторон (за исключением клиентов финансовой организации), с которыми финансовая организация осуществляет взаимодействие в рамках восстановления после реализации инцидентов;
ВПУ.2
ВПУ.2 Разработка и применение процедур реагирования в случае реализации информационных угроз, в том числе компьютерных атак со стороны поставщиков услуг, а также в случае идентификации риска распространения вредоносного кода на вычислительные сети финансовой организации*.
ВРВ.26.7
ВРВ.26.7 Процедур сбора и фиксации технических данных (свидетельств) в рамках восстановления после реализации инцидентов для анализа причин и последствий реализации инцидентов;
ВРВ.26.6
ВРВ.26.6 Процедур по снижению СТП инцидентов;
ВРВ.26.3
ВРВ.26.3 Процедур восстановления функционирования объектов информатизации на каждом из уровней информационной инфраструктуры с учетом взаимосвязей и взаимозависимостей между объектами информатизации;
ВРВ.7.2
ВРВ.7.2 Методологии проведения предварительной оценки потенциала влияния (критичности) инцидента, включая его классификацию согласно типовому перечню и классификационным признакам;
ВРВ.26.9
ВРВ.26.9 Графика (приоритетности и последовательности) при восстановлении функционирования бизнес- и технологических процессов и объектов информатизации.
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 7 п.п. 1
7.1. Участники ССНП, участники СБП, ОПКЦ СБП и ОУИО СБП должны разработать и утвердить внутренние документы, регламентирующие выполнение следующих процессов (направлений) защиты информации в рамках процессов (направлений) защиты информации, предусмотренных подпунктом 7.1.1 пункта 7.1 раздела 7 ГОСТ Р 57580.1-2017:
- обеспечение защиты информации при управлении доступом;
- обеспечение защиты вычислительных сетей;
- контроль целостности и защищенности информационной инфраструктуры;
- защита от вредоносного кода;
- предотвращение утечек информации;
- управление инцидентами защиты информации;
- защита среды виртуализации;
- защита информации при осуществлении удаленного логического доступа с использованием мобильных (переносных) устройств.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 12.10.1
12.10.1
Определенные Требования к Подходу:
План реагирования на инциденты существует и готов к активации в случае предполагаемого или подтвержденного инцидента безопасности. План включает в себя, но не ограничивается:
Определенные Требования к Подходу:
План реагирования на инциденты существует и готов к активации в случае предполагаемого или подтвержденного инцидента безопасности. План включает в себя, но не ограничивается:
- Роли, обязанности, а также стратегии общения и контактов в случае предполагаемого или подтвержденного инцидента с безопасностью, включая, как минимум, уведомление платежных брендов и покупателей.
- Процедуры реагирования на инциденты с конкретными мероприятиями по локализации и смягчению последствий для различных типов инцидентов.
- Процедуры восстановления и обеспечения непрерывности бизнеса.
- Процессы резервного копирования данных.
- Анализ законодательных требований для сообщения о компромиссах.
- Охват и реагирование всех критически важных компонентов системы.
- Ссылка или включение процедур реагирования на инциденты от платежных брендов.
Цель Индивидуального подхода:
Поддерживается комплексный план реагирования на инциденты, соответствующий ожиданиям бренда card.
Определенные Процедуры Тестирования Подхода:
Поддерживается комплексный план реагирования на инциденты, соответствующий ожиданиям бренда card.
Определенные Процедуры Тестирования Подхода:
- 12.10.1.a Изучите план реагирования на инциденты, чтобы убедиться, что план существует и включает, по крайней мере, элементы, указанные в этом требовании.
- 12.10.1.b Опросите персонал и изучите документацию по ранее зарегистрированным инцидентам или предупреждениям, чтобы убедиться, что документированный план реагирования на инциденты и процедуры были соблюдены.
Цель:
Без всеобъемлющего плана реагирования на инциденты, который должным образом распространен, прочитан и понят ответственными сторонами, путаница и отсутствие единого ответа могут привести к дальнейшему простою бизнеса, ненужному освещению в средствах массовой информации, а также риску финансовых и/или репутационных потерь и юридической ответственности.
Надлежащая практика:
План реагирования на инциденты должен быть тщательным и содержать все ключевые элементы для заинтересованных сторон (например, юридические, коммуникационные), чтобы организация могла эффективно реагировать в случае нарушения, которое может повлиять на данные учетной записи. Важно поддерживать план в актуальном состоянии с учетом текущей контактной информации всех лиц, назначенных для участия в реагировании на инциденты. Другими соответствующими сторонами для уведомлений могут быть клиенты, финансовые учреждения (покупатели и эмитенты) и деловые партнеры.
Организациям следует рассмотреть вопрос о том, как устранить все нарушения данных в рамках CDE в своих планах реагирования на инциденты, включая данные учетной записи, беспроводные ключи шифрования, ключи шифрования, используемые для передачи и хранения, или данные учетной записи или данные о держателях карт и т.д.
Примеры:
Юридические требования к сообщению о компрометации включают требования большинства штатов США, Общего регламента ЕС по защите данных (GDPR) и Закона о защите персональных данных (Сингапур).
Дополнительная информация:
Для получения дополнительной информации обратитесь к Руководству по обработке инцидентов компьютерной безопасности NIST SP 800- 61 Rev. 2.
Без всеобъемлющего плана реагирования на инциденты, который должным образом распространен, прочитан и понят ответственными сторонами, путаница и отсутствие единого ответа могут привести к дальнейшему простою бизнеса, ненужному освещению в средствах массовой информации, а также риску финансовых и/или репутационных потерь и юридической ответственности.
Надлежащая практика:
План реагирования на инциденты должен быть тщательным и содержать все ключевые элементы для заинтересованных сторон (например, юридические, коммуникационные), чтобы организация могла эффективно реагировать в случае нарушения, которое может повлиять на данные учетной записи. Важно поддерживать план в актуальном состоянии с учетом текущей контактной информации всех лиц, назначенных для участия в реагировании на инциденты. Другими соответствующими сторонами для уведомлений могут быть клиенты, финансовые учреждения (покупатели и эмитенты) и деловые партнеры.
Организациям следует рассмотреть вопрос о том, как устранить все нарушения данных в рамках CDE в своих планах реагирования на инциденты, включая данные учетной записи, беспроводные ключи шифрования, ключи шифрования, используемые для передачи и хранения, или данные учетной записи или данные о держателях карт и т.д.
Примеры:
Юридические требования к сообщению о компрометации включают требования большинства штатов США, Общего регламента ЕС по защите данных (GDPR) и Закона о защите персональных данных (Сингапур).
Дополнительная информация:
Для получения дополнительной информации обратитесь к Руководству по обработке инцидентов компьютерной безопасности NIST SP 800- 61 Rev. 2.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.26
А.5.26 Реагирование на инциденты ИБ
Реагирование на инциденты ИБ должно осуществляться в соответствии с документированными процедурами.
Реагирование на инциденты ИБ должно осуществляться в соответствии с документированными процедурами.
Положение Банка России № 719-П от 04.06.2020 "О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств":
Глава 5 п. 1
5.1. Оператор платежной системы в целях реализации пункта 11 части 3 статьи 28 Федерального закона № 161-ФЗ (Собрание законодательства Российской Федерации, 2011, № 27, ст. 3872) в рамках системы управления рисками в платежной системе определяет в правилах платежной системы и иных документах порядок обеспечения защиты информации в платежной системе для операторов по переводу денежных средств, являющихся участниками платежной системы, операторов услуг платежной инфраструктуры с учетом требований к обеспечению защиты информации при осуществлении переводов денежных средств (далее - требования к обеспечению защиты информации в платежной системе).
Оператор платежной системы должен определить требования к обеспечению защиты информации в платежной системе в отношении следующих мероприятий:
- управление риском информационной безопасности в платежной системе как одним из видов операционного риска в платежной системе, источниками реализации которого являются: недостатки процессов обеспечения защиты информации, в том числе недостатки применяемых технологических мер защиты информации, недостатки прикладного программного обеспечения автоматизированных систем и приложений, а также несоблюдение требований к указанным процессам деятельности операторами по переводу денежных средств, являющимися участниками платежной системы, операторами услуг платежной инфраструктуры (далее - риск информационной безопасности в платежной системе);
- установление состава показателей уровня риска информационной безопасности в платежной системе;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры механизмов, направленных на соблюдение требований к обеспечению защиты информации при осуществлении переводов денежных средств, и контроль их соблюдения операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры процессов выявления и идентификации риска информационной безопасности в платежной системе в отношении объектов информационной инфраструктуры участников платежной системы, операторов услуг платежной инфраструктуры;
- выявление и анализ операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры риска информационной безопасности в платежной системе;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры процессов реагирования на инциденты защиты информации и восстановления штатного функционирования объектов информационной инфраструктуры в случае реализации инцидентов защиты информации;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры взаимодействия при обмене информацией об инцидентах защиты информации;
- реализация операторами по переводу денежных средств, являющимися участниками платежной системы, и операторами услуг платежной инфраструктуры мероприятий по противодействию осуществлению переводов денежных средств без согласия клиента, определенных пунктами 2.2 и 2.4 Указания Банка России от 8 октября 2018 года № 4926-У «О форме и порядке направления операторами по переводу денежных средств, операторами платежных систем, операторами услуг платежной инфраструктуры в Банк России информации обо всех случаях и (или) попытках осуществления переводов денежных средств без согласия клиента и получения ими от Банка России информации, содержащейся в базе данных о случаях и попытках осуществления переводов денежных средств без согласия клиента, а также о порядке реализации операторами по переводу денежных средств, операторами платежных систем, операторами услуг платежной инфраструктуры мероприятий по противодействию осуществлению переводов денежных средств без согласия клиента», зарегистрированного Министерством юстиции Российской Федерации 12 декабря 2018 года № 52988;
- реализация операторами платежных систем процессов применения в отношении операторов по переводу денежных средств, являющихся участниками платежной системы, и операторов услуг платежной инфраструктуры ограничений по параметрам операций по осуществлению переводов денежных средств в случае выявления факта превышения значений показателей уровня риска информационной безопасности в платежной системе, в том числе условий снятия таких ограничений.
SWIFT Customer Security Controls Framework v2022:
7 - 7.1 Cyber Incident Response Planning
7.1 Cyber Incident Response Planning
Приказ ФСТЭК России № 31 от 14.03.2014 "Состав мер защиты информации и их базовые наборы для соответствующего класса защищенности автоматизированной системы управления":
ИНЦ.0
ИНЦ.0 Разработка политики реагирования на компьютерные инциденты
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.6.
1.6. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать в отношении выявления, регистрации событий операционного риска, связанных с нарушением операционной надежности, и реагирования на них, а также восстановления выполнения технологических процессов, указанных в приложении к настоящему Положению, и функционирования своих объектов информационной инфраструктуры после реализации указанных событий выполнение следующих требований:
- выявление и регистрацию событий операционного риска, связанных с нарушением операционной надежности;
- реагирование на события операционного риска, связанные с нарушением операционной надежности, в отношении критичной архитектуры;
- восстановление выполнения технологических процессов, указанных в приложении к настоящему Положению, и функционирования своих объектов информационной инфраструктуры после реализации событий операционного риска, связанных с нарушением операционной надежности;
- проведение анализа причин и последствий реализации событий операционного риска, связанных с нарушением операционной надежности;
- организацию взаимодействия между подразделениями (работниками) некредитной финансовой организации, ответственными за разработку технологических процессов, указанных в приложении к настоящему Положению, поддержание их выполнения, их реализацию, между собой и Банком России, иными участниками технологического процесса в рамках реагирования на события операционного риска, связанные с нарушением операционной надежности, и восстановления выполнения технологических процессов, указанных в приложении к настоящему Положению, а также функционирования своих объектов информационной инфраструктуры после реализации событий операционного риска, связанных с нарушением операционной надежности.
Положение Банка России № 683-П от 17.04.2019 "Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента":
8.
8. Кредитные организации к инцидентам, связанным с нарушениями требований к обеспечению защиты информации при осуществлении банковской деятельности, связанной с осуществлением перевода денежных средств (далее - инциденты защиты информации), должны относить события, которые привели или могут привести к осуществлению банковских операций без согласия клиента, неоказанию услуг, связанных с осуществлением банковских операций, в том числе включенные в перечень типов инцидентов, согласованный с федеральным органом исполнительной власти, уполномоченным в области обеспечения безопасности, и размещаемый Банком России на официальном сайте Банка России в сети "Интернет" (далее - перечень типов инцидентов).
NIST Cybersecurity Framework (EN):
PR.IP-9
PR.IP-9: Response plans (Incident Response and Business Continuity) and recovery plans (Incident Recovery and Disaster Recovery) are in place and managed
DE.AE-5
DE.AE-5: Incident alert thresholds are established
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
16.1.5
16.1.5 Реагирование на инциденты информационной безопасности
Мера обеспечения ИБ
Реагирование на инциденты ИБ должно осуществляться в соответствии с документально оформленными процедурами.
Руководство по применению
Реагирование на инциденты ИБ должно осуществляться назначенными контактными лицами и другими соответствующими лицами из числа самой организации или сторонних организаций (см. 16.1.1).
Реагирование должно включать в себя следующее:
- a) как можно более быстрый сбор свидетельств произошедшего;
- b) проведение криминалистического анализа ИБ по мере необходимости (см. 16.1.7);
- c) эскалация, если требуется;
- d) обеспечение того, что все выполняемые действия по реагированию соответствующим образом зарегистрированы для дальнейшего анализа;
- e) информирование о факте инцидента ИБ или любых существенных деталях о нем других лиц из числа самой организации или сторонних организаций в соответствии с принципом "необходимого знания";
- f) устранение недостатка(ов) ИБ, которые могут стать причиной или способствовать возникновению инцидента;
- g) после того, как инцидент успешно отработан, необходимо формально закрыть и записать его.
После инцидента должен проводиться анализ для выявления первопричины инцидента.
Дополнительная информация
Первоочередной целью реагирования на инцидент является возобновление "нормального уровня безопасности", а затем инициирование необходимого восстановления.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.5.26
А.5.26 Response to information security incidents
Information security incidents shall be responded to in accordance with the documented procedures.
Information security incidents shall be responded to in accordance with the documented procedures.
Положение Банка России № 716-П от 08.04.2022 "О требованиях к системе управления операционным риском в кредитной организации и банковской группе":
Глава 8. Пункт 7.6
8.7.6. Кредитная организация (головная кредитная организация банковской группы) определяет во внутренних документах порядок обеспечения качества данных в информационных системах, обеспечивающих критически важные процессы, включающий следующие элементы:
- процедуры измерения показателей качества данных;
- процедуры обоснования, утверждения и корректировки предельно допустимых значений показателей качества данных, критериев оценки качества данных;
- процедуры реагирования на случаи нарушения установленных кредитной организацией (головной кредитной организацией банковской группы) предельно допустимых значений показателей качества данных, критериев оценки качества данных;
- процедуры, правила и периодичность контроля качества данных и формирования отчетов о качестве данных, о проведении мероприятий контроля качества данных;
- процедуры исправления выявленных ошибок в данных и документирования внесенных в них изменений;
- порядок взаимодействия органов управления, подразделений и должностных лиц кредитной организации (головной кредитной организации банковской группы) по вопросам обеспечения качества данных, устанавливающий их полномочия, ответственность, подотчетность и обеспеченность ресурсами, в том числе определяющий в кредитной организации (головной кредитной организации банковской группы) должностное лицо (должностные лица), несущее (несущие) персональную ответственность за обеспечение качества данных в информационных системах;
- порядок и периодичность (не реже одного раза в год) проведения независимой оценки качества данных.
Кредитная организация (головная кредитная организация банковской группы) определяет во внутренних документах другие элементы порядка обеспечения качества данных в информационных системах.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.