Куда я попал?
SECURITM это SGRC система, ? автоматизирующая процессы в службах информационной безопасности. SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом и наработками для служб безопасности.

NIST Cybersecurity Framework (RU)

Framework

ID.RM-1

Для проведения оценки соответствия по документу войдите в систему.

Похожие требования

ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ОПР.19.2
ОПР.19.2 Рассмотрение вопросов, связанных с управлением риском реализации информационных угроз, при возможном влиянии такого риска на принимаемые решения, связанные с общей стратегией развития финансовой организации****; 
ВИО.6
ВИО.6 Организация и выполнение деятельности по анализу информации, полученной в рамках инициативного информирования работниками финансовой организации подразделений, формирующих «вторую линию защиты» и «третью линию защиты».
ОПР.8.5
ОПР.8.5 Участие совета директоров (наблюдательного совета) и коллегиального исполнительного органа финансовой организации в решении вопросов управления риском реализации информационных угроз, обеспечения операционной надежности и защиты информации.
ОПР.11.1
ОПР.11.1 Группа КПУР, характеризующих уровень совокупных потерь финансовой организации в результате событий риска реализации информационных угроз;
ОПР.4
ОПР.4 Установление функций и полномочий подразделений, формирующих «первую линию защиты», включающих:
  • идентификацию риска реализации информационных угроз (в пределах своей компетенции) в рамках реализуемых ими бизнеси технологических процессов;
  • сбор информации и информирование о внутренних событиях риска реализации информационных угроз и потерях подразделения, ответственного за регистрацию такой информации в базе событий риска реализации информационных угроз (службы ИБ);
  • оценку риска реализации информационных угроз (в пределах компетенции) в рамках реализуемых ими бизнес- и технологических процессов;
  • обеспечение соблюдения требований к планированию, реализации, контролю (в пределах компетенции) и совершенствованию мероприятий, направленных на уменьшение негативного влияния риска реализации информационных угроз;
  • мониторинг риска реализации информационных угроз (в пределах компетенции) и формирование соответствующей отчетности в рамках выполняемых ими бизнес- и технологических процессов;
  • информирование службы ИБ об остаточном риске  реализации информационных угроз, не уменьшенном выполняемыми мероприятиями, направленными на уменьшение негативного влияния риска реализации информационных угроз;
  • информирование о необходимости пересмотра ресурсного (кадрового и финансового) обеспечения для управления риском реализации информационных угроз
ВИО.5
ВИО.5 Организация и выполнение деятельности по анализу информации, полученной от подразделений, формирующих «третью линию защиты», и (или) в рамках внешнего аудита.
ВИО.11.2
ВИО.11.2 Взаимосвязей и взаимозависимостей между финансовой организацией и причастными сторонами (за исключением клиентов финансовой организации) в рамках выполнения бизнеси технологических процессов, в том числе взаимосвязей и взаимозависимостей объектов информатизации;
ОПР.7
ОПР.7 Установление функций и полномочий подразделений, формирующих «третью линию защиты», в части управления риском реализации информационных угроз, включающих:
  • проведение ежегодной оценки эффективности функционирования системы управления риском реализации информационных угроз*****;
  • оценку независимости деятельности подразделений, формирующих «вторую линию защиты», в части валидации данных и применения методологии в рамках управления риском реализации информационных угроз;
  • верификацию методологии и данных (последующая оценка адекватности методологии на предмет ее согласованности с внутренними политиками и требованиями финансовой организации, проверка полноты и корректности данных о риске реализации информационных угроз и событиях такого риска);
  • верификацию внутренней отчетности в рамках управления риском реализации информационных угроз, представляемой на рассмотрение совету директоров (наблюдательному совету);
  • содействие своевременному и адекватному реагированию подразделениями, формирующими «первую» и «вторую линии защиты», на недостатки функционирования системы управления риском реализации информационных угроз (в части их устранения)
ОПР.12
ОПР.12 Установление политикой управления риском реализации информационных угроз допустимого уровня такого риска (риск-аппетита финансовой организации) с учетом сигнальных и контрольных значений КПУР**.
ВИО.20
ВИО.20 Определение способов проведения оценки уровня риска реализации информационных угроз.
ОПР.11.2
ОПР.11.2 Группа КПУР, характеризующих уровень операционной надежности бизнес- и технологических процессов финансовой организации; 
ВИО.11.3
ВИО.11.3 Сторонних информационных сервисов поставщиков услуг.
ОПР.1.1
ОПР.1.1 Определение и описание состава процессов управления риском реализации информационных угроз, обеспечения операционной надежности и защиты информации; 
ОПР.6
ОПР.6 Установление функций и полномочий подразделений, формирующих «вторую линию защиты» в части управления риском реализации информационных угроз, включающих:
  • интеграцию системы управления риском реализации информационных угроз в систему управления операционным риском;
  • координацию деятельности по управлению риском реализации информационных угроз как одним из видов операционного риска;
  • валидацию данных (анализ данных о риске реализации информационных угроз или событиях такого риска на предмет их полноты и адекватности);
  • валидацию применения методологии в рамках управления риском реализации информационных угроз как одним из видов операционного риска (оценка корректности и адекватности в части согласованности методологии в рамках управления риском реализации информационных угроз с методологией управления операционным риском);
  • валидацию КИР;
  • расчет и обоснование сигнальных и контрольных значений КПУР (за исключением сигнальных и контрольных значений КПУР, расчет и обоснование которых осуществляется службой ИБ согласно ОПР.5.2 настоящей таблицы);
  • расчет фактических значений КПУР (за исключением фактических значений КПУР, расчет которых осуществляется службой ИБ согласно ОПР.5.2);
  • координацию деятельности по отражению информации о событиях риска реализации информационных угроз в базе событий операционного риска;
  • включение отчетности, формируемой в рамках управления риском реализации информационных угроз, в отчетность об управлении операционным риском;
  • определение (во взаимодействии со службой ИБ) согласованной или единой методологии управления риском реализации информационных угроз, обеспечивающей интеграцию процессов управления риском реализации информационных угроз в рамках процессов управления операционным риском
ВИО.17.3
ВИО.17.3 Агрегированную оценку уровня риска реализации информационных угроз** в разрезе элементов классификации такого риска (приведенных в рамках Приложений А, Б, В, Г), в том числе в соответствии с требованиями нормативных актов Банка России; 
РМ.2
РМ.2 Разработка плана реагирования на риск реализации информационных угроз, обеспечивающего достижение и поддержание допустимого уровня такого риска (риск-аппетита финансовой организации).
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 3
3. Кредитные организации с учетом требований главы 5 Положения Банка России N 716-П должны определить во внутренних документах для каждого технологического процесса и соблюдать значения следующих контрольных показателей уровня операционного риска для целей обеспечения операционной надежности (далее - целевые показатели операционной надежности):

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

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

ГОСТ Р № 22301 от 01.01.2022 "Надежность в технике. Системы менеджмента непрерывности деятельности. Требования":
Р. 8 п. 4 пп. 4 ппп. 1
 8.4.4.1 Организация должна документировать и поддерживать планы и процедуры обеспечения непрерывности деятельности. Эти планы должны обеспечивать руководство и информацию, чтобы помочь командам реагировать на нарушение деятельности организации и помочь организации в реагировании на нарушение деятельности и восстановлении последних. 
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Тело стандарта":
8.1 Операционное планирование и контроль
8.1 Оперативнное планирование и контроль
Организация должна планировать, внедрять и контролировать процессы, необходимые для выполнения требований информационной безопасности, а также для реализации действий, определенных в Разделе 6, посредством:
  • установление критериев для процессов;
  • осуществление контроля процессов в соответствии с критериями.
Документированная информация должна быть доступна в объеме, необходимом для уверенности в том, что процессы выполняются в соответствии с планом.
Организация должна контролировать запланированные изменения и анализировать последствия непреднамеренных изменений, предпринимая действия по снижению любых неблагоприятных последствий, если это необходимо.
Организация должна обеспечить контроль предоставляемых извне, относящихся к системе менеджмента информационной безопасности, процессов, продуктов или услуг.
9.3.2 Входная информация анализа со стороны руководства
9.3.2 Входная информация анализа со стороны руководства
Анализ со стороны руководства должен включать в себя рассмотрение следующего:
  • a) статус действий после предыдущего анализа со стороны руководства;
  • b) изменения внешних и внутренних параметров, которые относятся к системе менеджмента информационной безопасности;
  • с) изменения потребностей и ожиданий заинтересованных сторон, имеющих отношение к системе менеджмента информационной безопасности;
  • f) обратную связь в отношении исполнения информационной безопасности, включая тенденции в:
    • 1) несоответствиях и корректирующих действиях;
    • 2) результатах мониторинга и оценки защищенности;
    • 3) результатах аудита;
    • 4) достижении целей информационной безопасности;
  • d) обратную связи от заинтересованных сторон;
  • e) результаты оценки рисков и статус плана обработки рисков;
  • f) возможности для непрерывного улучшения
8.3 Обработка рисков информационной безопасности
8.3 Обработка рисков информационной безопасности
Организация должна внедрить план обработки рисков информационной безопасности.
Организация должна сохранять документированную информацию по результатам обработки рисков информационной безопасности.
6.1.3 Обработка рисков информационной безопасности
6.1.3 Обработка рисков информационной безопасности
Организация должна определить и применять процесс обработки рисков в целях:
  • a) выбора применимых вариантов обработки рисков информационной безопасности, учитывающих результаты оценки рисков;
  • b) определения всех средств управления информационной безопасностью, необходимых для внедрения выбранного варианта (-ов) обработки рисков информационной безопасности; 
ПРИМЕЧАНИЕ 1 Организация может разработать средства управления информационной безопасностью, по мере необходимости, или определить их из иного источника.

  • c) сравнения средств управления информационной безопасностью, вышеопределенных в п.6.1.3 b) и содержащихся в Приложении А, а также подтверждения того, что ни одно необходимое средство управления информационной безопасностью не пропущено;
ПРИМЕЧЕНИЕ 2 Приложение А содержит перечень средств управления информационной безопасностью. Пользователи настоящего документа отсылаются к Приложению А для обеспечения того, что ни одно необходимое средство управления информационной безопасностью не будет пропущено.
ПРИМЕЧАНИЕ 3 Перечисленные в Приложении А средства управления информационной безопасностью не являются исчерпывающими и, по необходимости, могут быть применены потребоваться дополнительные средства управления информационной безопасностью.

  • d) выработки Положения о Применимости, которое содержит:
    • необходимые средства управления информационной безопасностью (см. п.6.1.3 b) и с));
    • обоснование их применения;
    • сведения от том, реализованы они или нет, а также
    • обоснование исключения из применения приведенных в Приложении А средств управления информационной безопасностью.
  • e) разработки плана обработки рисков; а также
  • f) получения одобрения плана обработки рисков информационной безопасности и остаточных рисков информационной безопасности со стороны владельцев рисков.
Организация должна сохранять документированную информацию о процессе обработки рисков информационной безопасности.
ПРИМЕЧАНИЕ 4 Процесс оценки и обработки рисков информационной безопасности в настоящем документе соответствует принципам и общим указаниям, изложенным в ИСО 31000.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования":
8.3
 8.3 Обработка рисков информационной безопасности 
Организация должна реализовать план обработки рисков информационной безопасности. Организация должна хранить документированную информацию о результатах обработки рисков информационной безопасности. 
6.1.3
6.1.3 Обработка рисков информационной безопасности
Организация должна определить и применять процесс обработки рисков информационной безопасности:
а) для выбора подходящих вариантов обработки рисков информационной безопасности, учитывая результаты оценки рисков информационной безопасности;
b) определения всех мер и средств информационной безопасности, необходимых для реализации выбранного(ых) варианта(ов) обработки рисков информационной безопасности.
Примечание — При необходимости организация может разрабатывать меры обеспечения информационной безопасности или взять их из любого источника;
с) сравнения мер и средств информационной безопасности, определенных в соответствии с 6.1.3 Ь), с указанными в приложении А для проверки того, что никакие необходимые меры обеспечения информационной безопасности не были упущены.
Примечание 1 — Приложение А содержит базовый перечень мер и средств информационной безопасности и целей их применения. Пользователям настоящего стандарта следует обращаться к приложению А для обеспечения уверенности в том, что никакие необходимые меры обеспечения информационной безопасности не были упущены.
Примечание 2 — Цели применения мер и средств информационной безопасности неявным образом включены в выбранные меры обеспечения информационной безопасности. Приведенные в приложении А меры обеспечения информационной безопасности и цели их применения не являются исчерпывающими, и организация может рассматривать необходимость дополнительных мер и средств информационной безопасности и целей их применения;
d) подготовки ведомости применимости мер и средств информационной безопасности, которая содержит (Пункт 6.1.3 d) приведен с учетом технической правки к ISO/IEC 27001:2013.)
  •  необходимые меры обеспечения информационной безопасности [см. 6.1.3 Ь) и с)];
  •  обоснования их применения;
  •  информацию о том, реализованы или нет необходимые меры обеспечения информационной безопасности;
  •  обоснования неприменения мер и средств информационной безопасности, представленных в приложении А; 
е) разработки плана обработки рисков информационной безопасности;
f) согласования и (или) утверждения плана обработки рисков информационной безопасности и принятия остаточных рисков информационной безопасности владельцами рисков.
Организация должна хранить документированную информацию о процессе обработки рисков информационной безопасности.

Примечание — Процесс оценки и обработки рисков информационной безопасности в настоящем стандарте согласуется с принципами и общими рекомендациями, представленными в ИСО 31000. 
9.3
 9.3 Проверка со стороны руководства 
Высшее руководство должно проводить проверку системы менеджмента информационной безопасности через запланированные интервалы времени в целях обеспечения уверенности в сохраняющейся ее приемлемости, адекватности и результативности. 
Проверка со стороны руководства должна включать рассмотрение: 
а) состояния выполнения решений по результатам предыдущих проверок со стороны руководства; 
b) изменений внешних и внутренних факторов, касающихся системы менеджмента информационной безопасности; 
с) отзывов о результатах деятельности по обеспечению информационной безопасности, включая тенденции: 
1) в выявлении несоответствий и применении корректирующих действий; 
2) результатах мониторинга и оценки защищенности; 
3) результатах аудита; 
4) достижении целей информационной безопасности; 
d) отзывов от заинтересованных сторон; 
е) результатов оценки рисков информационной безопасности и статуса выполнения плана обработки рисков информационной безопасности; 
f) возможностей для постоянного улучшения системы менеджмента информационной безопасности. 
Результаты проверки со стороны руководства должны включать решения, относящиеся к возможностям постоянного улучшения и к необходимости внесения любых изменений в систему менеджмента информационной безопасности организации. 
Организация должна хранить документированную информацию в качестве свидетельства результатов проверок со стороны руководства 
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 12.3.2
12.3.2
Defined Approach Requirements: 
A targeted risk analysis is performed for each PCI DSS requirement that the entity meets with the customized approach, to include:
  • Documented evidence detailing each element specified in Appendix D: Customized Approach (including, at a minimum, a controls matrix and risk analysis). 
  • Approval of documented evidence by senior management.
  • Performance of the targeted analysis of risk at least once every 12 months. 
Customized Approach Objective:
This requirement is part of the customized approach and must be met for those using the customized approach. 

Applicability Notes:
 This requirement only applies to entities using a Customized Approach. 

Defined Approach Testing Procedures:
  • 12.3.2 Examine the documented targeted riskanalysis for each PCI DSS requirement that the entity meets with the customized approach to verify that documentation for each requirement exists and is in accordance with all elements specified in this requirement. 
Purpose:
 A risk analysis following a repeatable and robust methodology enables an entity to meet the customized approach objective. 

Definitions:
The customized approach to meeting a PCI DSS requirement allows entities to define the controls used to meet a given requirement’s stated Customized Approach Objective in a way that does not strictly follow the defined requirement. These controls are expected to at least meet or exceed the security provided by the defined requirement and require extensive documentation by the entity using the customized approach. 

Further Information:
See Appendix D: Customized Approach for instructions on how to document the required evidence for the customized approach. 
See Appendix E Sample Templates to Support Customized Approach for templates that entities may use to document their customized controls. Note that while use of the templates is optional, the information specified within each template must be documented and provided to each entity’s assessor. 
Guideline for a healthy information system v.2.0 (EN):
41 STANDARD
/STANDARD
Each organization develops within a complex computing environment specific to itself. As such, any position taken or action plan involving the information system security must be considered in light of the risks foreseen by the management. Whether it is organisational or technical measures, their implementation represents a cost for the organization, which needs to ensure that they are able to reduce an identified risk to an acceptable level.
 
In the most sensitive cases, the risk analysis may call into question certain previous choices. This may be the case if the probability of an event appearing and its potential consequences prove critical for the organization and there is no preventive action to control it. 

The recommended approach consists, in broad terms, of defining the context, assessing the risks and dealing with them. The risk assessment generally works by considering two areas: the likelihood and the impacts. This is then followed by the creation of a risk treatment plan to be validated by a designated authority at a higher level. 

Three kinds of approach can be considered to control the risks associated with the information system:
  • the recourse to best IT security practices;
  • a systematic risk analysis based on feedback from users;
  • a structured risk management formalised by a dedicated methodology. 
In this last case, the EBIOS method referenced by ANSSI is recommended. It is able to write down security needs, identify the security objectives and determine the security demands 
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Body":
8.3 Information security risk treatment
8.3 Information security risk treatment
The organization shall implement the information security risk treatment plan.
The organization shall retain documented information of the results of the information security risk treatment.
6.1.3 Information security risk treatment
6.1.3 Information security risk treatment
The organization shall define and apply an information security risk treatment process to:
  • a) select appropriate information security risk treatment options, taking account of the risk assessment results;
  • b) determine all controls that are necessary to implement the information security risk treatment option(s) chosen;
NOTE 1 Organizations can design controls as required, or identify them from any source.

  • c) compare the controls determined in 6.1.3 b)  above with those in Annex A and verify that no necessary controls have been omitted;
NOTE 2 Annex A contains a list of possible information security controls. Users of this document are directed to Annex A to ensure that no necessary information security controls are overlooked.
NOTE 3 The information security controls listed in Annex A are not exhaustive and additional information security controls can be included if needed.

  • d) produce a Statement of Applicability that contains:·  the necessary controls (see 6.1.3 b) and c));· justification for their inclusion;· whether the necessary controls are implemented or not; and· the justification for excluding any of the Annex A controls.;
  • e) formulate an information security risk treatment plan; and
  • f) obtain risk owners’ approval of the information security risk treatment plan and acceptance of the residual information security risks.
The organization shall retain documented information about the information security risk treatment process.
NOTE 4 The information security risk assessment and treatment process in this document aligns with the principles and generic guidelines provided in ISO 31000.
9.3.2 Management review inputs
9.3.2 Management review inputs
The management review shall include consideration of:
  • a) the status of actions from previous management reviews;
  • b) changes in external and internal issues that are relevant to the information security management system;
  • c) changes in needs and expectations of interested parties that are relevant to the information security management system;
  • d) feedback on the information security performance, including trends in:
    • 1) nonconformities and corrective actions;
    • 2) monitoring and measurement results;
    • 3) audit results;
    • 4) fulfilment of information security objectives;
  • e) feedback from interested parties;
  • f) results of risk assessment and status of risk treatment plan;.
  • g) opportunities for continual improvement
8.1 Operational planning and control
8.1 Operational planning and control
The organization shall plan, implement and control the processes needed to meet information security requirements, and to implement the actions determined in Clause 6, by:
  • establishing criteria for the processes;
  • implementing control of the processes in accordance with the criteria.
Documented information shall be available to the extent necessary to have confidence that the processes have been carried out as planned.
The organization shall control planned changes and review the consequences of unintended changes, taking action to mitigate any adverse effects, as necessary.
The organization shall ensure that externally provided processes, products or services that are relevant to the information security management system are controlled.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 12.3.2
12.3.2
Определенные Требования к Подходу:
Целевой анализ рисков выполняется для каждого требования PCI DSS, которому организация соответствует с помощью индивидуального подхода, чтобы включить:
  • Документированные доказательства с подробным описанием каждого элемента, указанного в Приложении D: Индивидуальный подход (включая, как минимум, матрицу контроля и анализ рисков).
  • Утверждение документально подтвержденных доказательств высшим руководством.
  • Проведение целевого анализа рисков не реже одного раза в 12 месяцев.
Цель Индивидуального подхода:
Это требование является частью индивидуального подхода и должно быть выполнено для тех, кто использует индивидуальный подход.

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

Определенные Процедуры Тестирования Подхода:
  • 12.3.2 Изучить документированный целевой анализ рисков для каждого требования PCI DSS, которому соответствует организация, с помощью индивидуального подхода, чтобы убедиться, что документация по каждому требованию существует и соответствует всем элементам, указанным в этом требовании.
Цель:
Анализ рисков с использованием повторяемой и надежной методологии позволяет предприятию достичь цели индивидуального подхода.

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

Дополнительная информация:
См. Приложение D: Индивидуальный подход для получения инструкций о том, как документировать необходимые доказательства для индивидуального подхода.
Смотрите Примеры шаблонов в Приложении E для поддержки индивидуального подхода к шаблонам, которые организации могут использовать для документирования своих настраиваемых элементов управления. Обратите внимание, что, хотя использование шаблонов необязательно, информация, указанная в каждом шаблоне, должна быть задокументирована и предоставлена оценщику каждой организации.
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.3.
1.3. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны определить во внутренних документах для каждого осуществляемого ими технологического процесса, указанного в приложении к настоящему Положению, значения следующих целевых показателей операционной надежности:
  • допустимого отношения общего количества финансовых операций, совершенных во время деградации технологического процесса в рамках события операционного риска или серии связанных событий операционного риска, вызванных информационными угрозами, которые привели к неоказанию или ненадлежащему оказанию финансовых услуг (далее - события операционного риска, связанные с нарушением операционной надежности), к ожидаемому количеству финансовых операций за тот же период в случае непрерывного оказания финансовых услуг (далее - доля деградации технологических процессов);
  • допустимого времени простоя и (или) деградации технологического процесса в рамках события операционного риска, связанного с нарушением операционной надежности (в случае превышения допустимой доли деградации технологического процесса), не выше порогового уровня, установленного в приложении к настоящему Положению;
  • допустимого суммарного времени простоя и (или) деградации технологического процесса (в случае превышения допустимой доли деградации технологического процесса) в течение последних двенадцати календарных месяцев к первому числу каждого календарного месяца;
  • показателя соблюдения режима работы (функционирования) технологического процесса (времени начала, времени окончания, продолжительности и последовательности процедур в рамках технологического процесса).
Значение допустимой доли деградации технологических процессов должно рассчитываться некредитной финансовой организацией, обязанной соблюдать усиленный, стандартный или минимальный уровень защиты информации, на основании статистических данных за период не менее двенадцати календарных месяцев, предшествующих дате определения значения целевого показателя операционной надежности, за исключением случая, предусмотренного абзацем седьмым настоящего пункта, и (или) иных данных, обосновывающих их определение (по выбору некредитной финансовой организации).

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

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

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

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

В случае если законодательством Российской Федерации, регулирующим деятельность некредитных финансовых организаций, обязанных соблюдать усиленный, стандартный или минимальный уровень защиты информации, установлена обязательность наличия у них системы управления рисками, указанные некредитные финансовые организации должны выполнять требования настоящего пункта в рамках системы управления рисками.
NIST Cybersecurity Framework (EN):
ID.RM-1 ID.RM-1: Risk management processes are established, managed, and agreed to by organizational stakeholders
Положение Банка России № 716-П от 08.04.2022 "О требованиях к системе управления операционным риском в кредитной организации и банковской группе":
Глава 7. Пункт 8.
7.8. В политике информационной безопасности кредитная организация (головная кредитная организация банковской группы) в целях управления риском информационной безопасности определяет:
  • функции и ответственность коллегиального исполнительного органа и работников кредитной организации (головной кредитной организации банковской группы) в рамках управления риском информационной безопасности;
  • основные принципы функционирования системы обеспечения информационной безопасности и задачи управления риском информационной безопасности; (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
  • сигнальные и контрольные значения контрольных показателей уровня риска информационной безопасности;
  • основные принципы организации контроля за функционированием системы обеспечения информационной безопасности;
  • требования к созданию ресурсных (кадровых и финансовых) условий системы обеспечения информационной безопасности;
  • требования к третьим лицам (внешним подрядчикам, контрагентам, участникам банковской группы), которым могут быть переданы функции кредитной организации (головной кредитной организации банковской группы) по обеспечению информационной безопасности, а также определение порядка взаимодействия и распределения ответственности между кредитной организацией (головной кредитной организацией банковской группы) и привлеченными ею третьими лицами. (Абзац в редакции, введенной в действие с 1 октября 2022 года указанием Банка России от 25 марта 2022 года N 6103-У. - См. предыдущую редакцию)
Политика информационной безопасности должна утверждаться коллегиальным исполнительным органом кредитной организации (головной кредитной организации банковской группы).

Коллегиальный исполнительный орган кредитной организации (головной кредитной организации банковской группы) несет ответственность за соблюдение требований политики информационной безопасности.
Глава 7. Пункт 1.
7.1. Кредитная организация (головная кредитная организация банковской группы) определяет во внутренних документах порядок управления риском информационной безопасности.