Куда я попал?
Стандарт Банка России № СТО БР ИББС-1.0-2014 от 01.06.2014
Обеспечение информационной безопасности организаций банковской системы Российской Федерации - Общие положения
Р. 8 п. 4 п.п. 5
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ОПР.1.5
ОПР.1.5 Порядок утверждения и условия пересмотра структуры и организации систем управления риском реализации информационных угроз, операционной надежности и защиты информации.
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 3
3. Кредитные организации с учетом требований главы 5 Положения Банка России N 716-П должны определить во внутренних документах для каждого технологического процесса и соблюдать значения следующих контрольных показателей уровня операционного риска для целей обеспечения операционной надежности (далее - целевые показатели операционной надежности):
- допустимого отношения общего количества банковских операций и иных операций, осуществляемых в рамках технологического процесса, совершенных во время нарушений технологических процессов, приводящих к неоказанию или ненадлежащему оказанию банковских услуг (далее - деградация технологического процесса (технологических процессов), в рамках события операционного риска или серии связанных событий операционного риска, вызванных информационными угрозами и (или) сбоями объектов информационной инфраструктуры, которые привели к неоказанию или ненадлежащему оказанию банковских услуг (далее - инцидент операционной надежности), к ожидаемому количеству банковских операций и иных операций, осуществляемых в рамках технологических процессов, за тот же период в случае непрерывного оказания банковских услуг, установленного кредитной организацией (далее - допустимая доля деградации технологического процесса);
- допустимого времени простоя и (или) деградации технологических процессов кредитных организаций в рамках инцидента операционной надежности (в случае превышения допустимой доли деградации технологического процесса). Значение данного целевого показателя устанавливается кредитной организацией не выше значений, предусмотренных приложением к настоящему Положению;
- допустимого суммарного времени простоя и (или) деградации технологического процесса кредитной организации (в случае превышения допустимой доли деградации технологического процесса) в течение очередного календарного года;
- показателя соблюдения режима работы (функционирования) технологического процесса (времени начала, времени окончания, продолжительности и последовательности процедур в рамках технологического процесса).
Значение допустимой доли деградации технологических процессов должно рассчитываться кредитной организацией на основании статистических данных за период не менее двенадцати календарных месяцев, предшествующих дате определения значения целевого показателя операционной надежности, за исключением случая, предусмотренного абзацем седьмым настоящего пункта, и (или) иных данных, обосновывающих их определение (по выбору кредитной организации).
В случае если технологический процесс функционирует менее двенадцати календарных месяцев, кредитные организации должны определять значение допустимой доли деградации технологических процессов на основании статистических данных за период с даты начала его функционирования и (или) иных данных, обосновывающих их определение (по выбору кредитной организации).
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Тело стандарта":
6.1.2 Оценка рисков информационной безопасности
6.1.2 Оценка рисков информационной безопасности
Организация должна определить и применять процесс оценки рисков информационной безопасности, который
Организация должна определить и применять процесс оценки рисков информационной безопасности, который
- а) устанавливает и поддерживает критерии рисков информационной безопасности, которые включают в себя:
- 1) критерии приемлемости рисков; а также
- 2) критерии выполнения оценок рисков информационной безопасности;
- b) обеспечивает выработку повторяющимися оценками рисков информационной безопасности цельных, достоверных и сравнимых результатов;
- c) выявляет риски информационной безопасности:
- 1) применение процесса оценки рисков информационной безопасности с целью выявления рисков, связанных с потерей конфиденциальности, целостности и доступности информации в пределах области действия системы менеджмента информационной безопасности; а также
- 2) выявление владельцев рисков;
- d) анализирует риски информационной безопасности:
- 1) оценка возможных последствий, которые могут произойти в результате реализации рисков, выявленных в п.6.1.2 с)1);
- 2) оценка реалистичной вероятности реализации рисков, выявленных в п.6.1.2 с)1); а также
- 3) определение уровней рисков;
- e) оценивает риски информационной безопасности:
- 1) сравнение результатов анализа рисков с критериями, установленными в п.6.1.2 а); а также
- 2) расставляет приоритеты обработки проанализированных рисков.
Организация должна сохранять документированную информацию о процессе оценки рисков информационной безопасности.
8.3 Обработка рисков информационной безопасности
8.3 Обработка рисков информационной безопасности
Организация должна внедрить план обработки рисков информационной безопасности.
Организация должна сохранять документированную информацию по результатам обработки рисков информационной безопасности.
Организация должна внедрить план обработки рисков информационной безопасности.
Организация должна сохранять документированную информацию по результатам обработки рисков информационной безопасности.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 12.3.1
12.3.1
Defined Approach Requirements:
Each PCI DSS requirement that provides flexibility for how frequently it is performed (for example, requirements to be performed periodically) is supported by a targeted risk analysis that is documented and includes:
Defined Approach Requirements:
Each PCI DSS requirement that provides flexibility for how frequently it is performed (for example, requirements to be performed periodically) is supported by a targeted risk analysis that is documented and includes:
- Identification of the assets being protected.
- Identification of the threat(s) that the requirement is protecting against.
- Identification of factors that contribute to the likelihood and/or impact of a threat being realized.
- Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized.
- Review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed.
- Performance of updated risk analyses when needed, as determined by the annual review.
Customized Approach Objective:
Up to date knowledge and assessment of risks to the CDE are maintained.
Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Defined Approach Testing Procedures:
Up to date knowledge and assessment of risks to the CDE are maintained.
Applicability Notes:
This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Defined Approach Testing Procedures:
- 12.3.1 Examine documented policies and procedures to verify a process is defined for performing targeted risk analyses for each PCI DSS requirement that provides flexibility for how frequently the requirement is performed, and that the process includes all elements specified in this requirement.
Purpose:
Some PCI DSS requirements allow an entity to define how frequently an activity is performed based on the risk to environment. Performing this risk analysis according to a methodology ensures validity and consistency with policies and procedures.
This targeted risk analysis (as opposed to a traditional enterprise-wide risk assessment) focuses on those PCI DSS requirements that allow an entity flexibility about how frequently an entity performs a given control. For this risk analysis, the entity carefully evaluates each PCI DSS requirement that provides this flexibility and determines the frequency that supports adequate security for the entity, and the level of risk the entity is willing to accept.
The risk analysis identifies the specific assets, such as the system components and data—for example, log files, or credentials—that the requirement is intended to protect, as well as the threat(s) or outcomes that the requirement is protecting the assets from—for example, malware, an undetected intruder, or misuse of credentials. Examples of factors that could contribute to likelihood or impact include any that could increase the vulnerability of an asset to a threat—for example, exposure to untrusted networks, complexity of environment, or high staff turnover—as well as the criticality of the system components, or volume and sensitivity of the data, being protected.
Reviewing the results of these targeted risk analyses at least once every 12 months and upon changes that could impact the risk to the environment allows the organization to ensure the risk analysis results remain current with organizational changes and evolving threats, trends, and technologies, and that the selected frequencies still adequately address the entity’s risk.
Good Practice:
An enterprise-wide risk assessment, which is a point-in-time activity that enables entities to identify threats and associated vulnerabilities, is recommended, but is not required, for entities to determine and understand broader and emerging threats with the potential to negatively impact its business. This enterprise-wide risk assessment could be established as part of an overarching risk management program that is used as an input to the annual review of an organization's overall information security policy (see Requirement 12.1.1).
Examples of risk-assessment methodologies for enterprise-wide risk assessments include, but are not limited to, ISO 27005 and NIST SP 800-30.
Some PCI DSS requirements allow an entity to define how frequently an activity is performed based on the risk to environment. Performing this risk analysis according to a methodology ensures validity and consistency with policies and procedures.
This targeted risk analysis (as opposed to a traditional enterprise-wide risk assessment) focuses on those PCI DSS requirements that allow an entity flexibility about how frequently an entity performs a given control. For this risk analysis, the entity carefully evaluates each PCI DSS requirement that provides this flexibility and determines the frequency that supports adequate security for the entity, and the level of risk the entity is willing to accept.
The risk analysis identifies the specific assets, such as the system components and data—for example, log files, or credentials—that the requirement is intended to protect, as well as the threat(s) or outcomes that the requirement is protecting the assets from—for example, malware, an undetected intruder, or misuse of credentials. Examples of factors that could contribute to likelihood or impact include any that could increase the vulnerability of an asset to a threat—for example, exposure to untrusted networks, complexity of environment, or high staff turnover—as well as the criticality of the system components, or volume and sensitivity of the data, being protected.
Reviewing the results of these targeted risk analyses at least once every 12 months and upon changes that could impact the risk to the environment allows the organization to ensure the risk analysis results remain current with organizational changes and evolving threats, trends, and technologies, and that the selected frequencies still adequately address the entity’s risk.
Good Practice:
An enterprise-wide risk assessment, which is a point-in-time activity that enables entities to identify threats and associated vulnerabilities, is recommended, but is not required, for entities to determine and understand broader and emerging threats with the potential to negatively impact its business. This enterprise-wide risk assessment could be established as part of an overarching risk management program that is used as an input to the annual review of an organization's overall information security policy (see Requirement 12.1.1).
Examples of risk-assessment methodologies for enterprise-wide risk assessments include, but are not limited to, ISO 27005 and NIST SP 800-30.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Body":
6.1.2 Information security risk assessment
6.1.2 Information security risk assessment
The organization shall define and apply an information security risk assessment process that:
The organization shall define and apply an information security risk assessment process that:
- a) establishes and maintains information security risk criteria that include:
- 1) the risk acceptance criteria; and
- 2) criteria for performing information security risk assessments;
- b) ensures that repeated information security risk assessments produce consistent, valid and comparable results;
- c) identifies the information security risks:
- 1) apply the information security risk assessment process to identify risks associated with the loss of confidentiality, integrity and availability for information within the scope of the information security management system; and
- 2) identify the risk owners;
- d) analyses the information security risks:
- e) evaluates the information security risks:
- 1) compare the results of risk analysis with the risk criteria established in 6.1.2 a); and
- 2) prioritize the analysed risks for risk treatment.
The organization shall retain documented information about the information security risk assessment process.
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.
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.
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 16.1
16.1. Участник СБП - банк плательщика должен осуществлять:
- выявление операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, установленным Банком России в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ (далее - признаки осуществления переводов денежных средств без согласия клиента), в рамках реализуемой им системы управления рисками при осуществлении переводов денежных средств с использованием сервиса быстрых платежей;
- приостановление в соответствии с частью 5.1 статьи 8 Федерального закона от 27 июня 2011 года N 161-ФЗ исполнения распоряжения в рамках выявленной операции, соответствующей признакам осуществления переводов денежных средств без согласия клиента, с учетом информации об уровне риска операции без согласия клиента (далее - индикатор уровня риска операции), включенной в электронное сообщение, полученной от ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП, содержащей в том числе информацию об индикаторе уровня риска операции, сформированном участником СБП - банком получателя;
- формирование индикатора уровня риска операции на основе оценки рисков операций в рамках реализуемой участником СБП - банком плательщика системы управления рисками и его направление в электронном сообщении в ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП, - в случае невыявления признаков осуществления перевода денежных средств без согласия клиента.
П. 16.2
16.2. Участник СБП - банк получателя должен осуществлять формирование индикатора уровня риска операции в рамках реализуемой им системы управления рисками, применяемой для выявления операций, соответствующих признакам осуществления переводов денежных средств без согласия клиента, и его направление в электронном сообщении в ОПКЦ СБП в формате и порядке, установленных договором об оказании услуг между участником СБП и ОПКЦ СБП.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 12.3.1
12.3.1
Определенные Требования к Подходу:
Каждое требование PCI DSS, обеспечивающее гибкость в отношении частоты его выполнения (например, требования, которые должны выполняться периодически), подкрепляется целевым анализом рисков, который документируется и включает:
Определенные Требования к Подходу:
Каждое требование PCI DSS, обеспечивающее гибкость в отношении частоты его выполнения (например, требования, которые должны выполняться периодически), подкрепляется целевым анализом рисков, который документируется и включает:
- Идентификация защищаемых активов.
- Идентификация угрозы (угроз), от которой защищает требование.
- Выявление факторов, которые способствуют вероятности и/или воздействию реализуемой угрозы.
- Итоговый анализ, который определяет и включает обоснование того, как часто должно выполняться требование, чтобы свести к минимуму вероятность реализации угрозы.
- Просматривайте каждый целевой анализ рисков не реже одного раза в 12 месяцев, чтобы определить, остаются ли результаты в силе или необходим обновленный анализ рисков.
- Проведение обновленного анализа рисков, когда это необходимо, в соответствии с ежегодным обзором.
Цель Индивидуального подхода:
Поддерживаются актуальные знания и оценка рисков для CDE.
Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Поддерживаются актуальные знания и оценка рисков для CDE.
Примечания по применению:
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 12.3.1 Изучите документированные политики и процедуры, чтобы убедиться, что определен процесс для выполнения целевого анализа рисков для каждого требования PCI DSS, который обеспечивает гибкость в отношении того, как часто выполняется требование, и что процесс включает все элементы, указанные в этом требовании.
Цель:
Некоторые требования PCI DSS позволяют организации определять, как часто выполняется та или иная деятельность, исходя из риска для окружающей среды. Выполнение этого анализа рисков в соответствии с методологией обеспечивает обоснованность и согласованность с политиками и процедурами.
Этот целевой анализ рисков (в отличие от традиционной общеорганизационной оценки рисков) фокусируется на тех требованиях PCI DSS, которые позволяют организации гибко выбирать, как часто организация выполняет тот или иной контроль. Для этого анализа рисков организация тщательно оценивает каждое требование PCI DSS, обеспечивающее такую гибкость, и определяет частоту, обеспечивающую надлежащую безопасность для организации, а также уровень риска, который организация готова принять.
Анализ рисков определяет конкретные активы, такие как системные компоненты и данные — например, файлы журналов или учетные данные, — для защиты которых предназначено требование, а также угрозы или последствия, от которых требование защищает активы — например, вредоносное ПО, необнаруженный злоумышленник, или неправильное использование учетных данных. Примеры факторов, которые могут способствовать вероятности или воздействию, включают любые, которые могут повысить уязвимость актива к угрозе, например, подверженность ненадежным сетям, сложность среды или высокая текучесть кадров, а также критичность компонентов системы или объем и критичность данных, поскольку защищенный.
Анализ результатов этих целевых анализов рисков не реже одного раза в 12 месяцев и при изменениях, которые могут повлиять на риск для окружающей среды, позволяет организации убедиться, что результаты анализа рисков остаются актуальными с учетом организационных изменений и развивающихся угроз, тенденций и технологий, а также что выбранные частоты по-прежнему адекватно учитывают риск организации..
Надлежащая практика:
Оценка рисков в масштабах всей организации, которая представляет собой оперативную деятельность, позволяющую организациям выявлять угрозы и связанные с ними уязвимости, рекомендуется, но не требуется, для определения и понимания более широких и возникающих угроз, которые могут негативно повлиять на их бизнес. Эта общеорганизационная оценка рисков может быть создана как часть всеобъемлющей программы управления рисками, которая используется в качестве вклада в ежегодный обзор общей политики информационной безопасности организации (см. Требование 12.1.1).
Примеры методологий оценки рисков для оценки рисков в масштабах предприятия включают, но не ограничиваются ими, ISO 27005 и NIST SP 800-30.
Некоторые требования PCI DSS позволяют организации определять, как часто выполняется та или иная деятельность, исходя из риска для окружающей среды. Выполнение этого анализа рисков в соответствии с методологией обеспечивает обоснованность и согласованность с политиками и процедурами.
Этот целевой анализ рисков (в отличие от традиционной общеорганизационной оценки рисков) фокусируется на тех требованиях PCI DSS, которые позволяют организации гибко выбирать, как часто организация выполняет тот или иной контроль. Для этого анализа рисков организация тщательно оценивает каждое требование PCI DSS, обеспечивающее такую гибкость, и определяет частоту, обеспечивающую надлежащую безопасность для организации, а также уровень риска, который организация готова принять.
Анализ рисков определяет конкретные активы, такие как системные компоненты и данные — например, файлы журналов или учетные данные, — для защиты которых предназначено требование, а также угрозы или последствия, от которых требование защищает активы — например, вредоносное ПО, необнаруженный злоумышленник, или неправильное использование учетных данных. Примеры факторов, которые могут способствовать вероятности или воздействию, включают любые, которые могут повысить уязвимость актива к угрозе, например, подверженность ненадежным сетям, сложность среды или высокая текучесть кадров, а также критичность компонентов системы или объем и критичность данных, поскольку защищенный.
Анализ результатов этих целевых анализов рисков не реже одного раза в 12 месяцев и при изменениях, которые могут повлиять на риск для окружающей среды, позволяет организации убедиться, что результаты анализа рисков остаются актуальными с учетом организационных изменений и развивающихся угроз, тенденций и технологий, а также что выбранные частоты по-прежнему адекватно учитывают риск организации..
Надлежащая практика:
Оценка рисков в масштабах всей организации, которая представляет собой оперативную деятельность, позволяющую организациям выявлять угрозы и связанные с ними уязвимости, рекомендуется, но не требуется, для определения и понимания более широких и возникающих угроз, которые могут негативно повлиять на их бизнес. Эта общеорганизационная оценка рисков может быть создана как часть всеобъемлющей программы управления рисками, которая используется в качестве вклада в ежегодный обзор общей политики информационной безопасности организации (см. Требование 12.1.1).
Примеры методологий оценки рисков для оценки рисков в масштабах предприятия включают, но не ограничиваются ими, ISO 27005 и NIST SP 800-30.
Методика экспресс-оценки уровня кибербезопасности организации РезБез:
1.2.4.1.
Топ-менеджмент, операционные руководители, ответственные за ключевые функции организации, совместно с представителями ИТ и ИБ
участвуют в определении недопустимых событий / ключевых рисков КБ
участвуют в определении недопустимых событий / ключевых рисков КБ
1.2.4.
В организации утвержден перечень НС / ключевых рисков КБ
1.2.4.2.
На регулярной основе осуществляется пересмотр перечня НС / ключевых рисков КБ
SWIFT Customer Security Controls Framework v2022:
7 - 7.4A Scenario Risk Assessment
7.4A Scenario Risk Assessment
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.3.
1.3. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны определить во внутренних документах для каждого осуществляемого ими технологического процесса, указанного в приложении к настоящему Положению, значения следующих целевых показателей операционной надежности:
- допустимого отношения общего количества финансовых операций, совершенных во время деградации технологического процесса в рамках события операционного риска или серии связанных событий операционного риска, вызванных информационными угрозами, которые привели к неоказанию или ненадлежащему оказанию финансовых услуг (далее - события операционного риска, связанные с нарушением операционной надежности), к ожидаемому количеству финансовых операций за тот же период в случае непрерывного оказания финансовых услуг (далее - доля деградации технологических процессов);
- допустимого времени простоя и (или) деградации технологического процесса в рамках события операционного риска, связанного с нарушением операционной надежности (в случае превышения допустимой доли деградации технологического процесса), не выше порогового уровня, установленного в приложении к настоящему Положению;
- допустимого суммарного времени простоя и (или) деградации технологического процесса (в случае превышения допустимой доли деградации технологического процесса) в течение последних двенадцати календарных месяцев к первому числу каждого календарного месяца;
- показателя соблюдения режима работы (функционирования) технологического процесса (времени начала, времени окончания, продолжительности и последовательности процедур в рамках технологического процесса).
Значение допустимой доли деградации технологических процессов должно рассчитываться некредитной финансовой организацией, обязанной соблюдать усиленный, стандартный или минимальный уровень защиты информации, на основании статистических данных за период не менее двенадцати календарных месяцев, предшествующих дате определения значения целевого показателя операционной надежности, за исключением случая, предусмотренного абзацем седьмым настоящего пункта, и (или) иных данных, обосновывающих их определение (по выбору некредитной финансовой организации).
В случае если технологический процесс функционирует менее двенадцати календарных месяцев, некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, должны определять значение допустимой доли деградации технологических процессов на основании статистических данных за период с даты начала его функционирования и (или) иных данных, обосновывающих их определение (по выбору некредитной финансовой организации).
В случае превышения допустимой доли деградации технологических процессов некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, должны обеспечить фиксацию:
- фактического времени простоя и (или) деградации технологического процесса, исчисляемого по каждому событию операционного риска, связанному с нарушением операционной надежности (с момента нарушения технологического процесса по причине реализации события операционного риска, связанного с нарушением операционной надежности, до момента восстановления выполнения технологического процесса);
- фактической доли деградации технологического процесса, исчисляемой по каждому событию операционного риска, связанному с нарушением операционной надежности;
- суммарного времени простоя и (или) деградации технологического процесса за последние двенадцать календарных месяцев, предшествующих событию операционного риска, связанному с нарушением операционной надежности.
При определении времени простоя и (или) деградации технологических процессов в расчет не включаются периоды времени проведения плановых технологических операций, связанных с приостановлением (частичным приостановлением) технологических процессов.
Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, должны обеспечить контроль за соблюдением значений целевых показателей операционной надежности.
Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, должны не реже одного раза в год проводить анализ необходимости пересмотра значений целевых показателей операционной надежности, по итогам которого указанные некредитные финансовые организации должны пересмотреть значения целевых показателей операционной надежности либо принять мотивированное решение об отсутствии необходимости в пересмотре указанных значений.
В случае если законодательством Российской Федерации, регулирующим деятельность некредитных финансовых организаций, обязанных соблюдать усиленный, стандартный или минимальный уровень защиты информации, установлена обязательность наличия у них системы управления рисками, указанные некредитные финансовые организации должны выполнять требования настоящего пункта в рамках системы управления рисками.
Связанные защитные меры
| Название | Дата | Влияние | ||
|---|---|---|---|---|
|
Community
48 / 170
|
Внедрение процесса управления рисками информационной безопасности
Вручную
Организационная
Детективная
08.05.2022
|
08.05.2022 | 48 / 170 |
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.