Куда я попал?
Стандарт № GMP Annex 11: Computerised Systems (RU) от 30.11.2011
Правила надлежащей производственной практики. Приложение 11: Компьютеризированные системы
Р. 4 п. 13 п.п. 1
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
Положение Банка России № 787-П от 12.01.2022 "Обязательные для кредитных организаций требованиях к операционной надежности при осуществлении банковской деятельности в целях обеспечения непрерывности оказания банковских услуг":
п. 6. п.п. 3
6.3. Кредитные организации должны обеспечивать выполнение следующих требований к выявлению, регистрации инцидентов операционной надежности и реагированию на них, а также восстановлению выполнения технологических процессов и функционирования объектов информационной инфраструктуры после реализации таких инцидентов:
- выявление и регистрация инцидентов операционной надежности;
- реагирование на инциденты операционной надежности в отношении критичной архитектуры;
- восстановление функционирования технологических процессов и объектов информационной инфраструктуры после реализации инцидентов операционной надежности;
- проведение анализа причин и последствий реализации инцидентов операционной надежности;
- организация взаимодействия между подразделениями кредитной организации, а также между кредитной организацией и Банком России, иными участниками технологического процесса в рамках реагирования на инциденты операционной надежности и восстановления выполнения технологических процессов и функционирования объектов информационной инфраструктуры после реализации инцидентов операционной надежности.
Стандарт № GMP Annex 11: Computerised Systems (EN) от 30.11.2011 "Good Manufacturing Practice. Annex 11: Computerised Systems":
Р. 4 п. 13 п.п. 1
All incidents, not only system failures and data errors, should be reported and assessed. The root cause of a critical incident should be identified and should form the basis of corrective and preventive actions.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 10.4.3
10.4.3
Defined Approach Requirements:
Exceptions and anomalies identified during the review process are addressed.
Customized Approach Objective:
Suspicious or anomalous activities are addressed.
Defined Approach Testing Procedures:
Defined Approach Requirements:
Exceptions and anomalies identified during the review process are addressed.
Customized Approach Objective:
Suspicious or anomalous activities are addressed.
Defined Approach Testing Procedures:
- 10.4.3.a Examine security policies and procedures to verify that processes are defined for addressing exceptions and anomalies identified during the review process.
- 10.4.3.b Observe processes and interview personnel to verify that, when exceptions and anomalies are identified, they are addressed.
Purpose:
If exceptions and anomalies identified during the log-review process are not investigated, the entity may be unaware of unauthorized and potentially malicious activities occurring within their network.
Good Practice:
Entities should consider how to address the following when developing their processes for defining and managing exceptions and anomalies:
If exceptions and anomalies identified during the log-review process are not investigated, the entity may be unaware of unauthorized and potentially malicious activities occurring within their network.
Good Practice:
Entities should consider how to address the following when developing their processes for defining and managing exceptions and anomalies:
- How log review activities are recorded, • How to rank and prioritize exceptions and anomalies,
- What procedures should be in place to report and escalate exceptions and anomalies, and
- Who is responsible for investigating and for any remediation tasks.
Requirement 10.7.2
10.7.2
Defined Approach Requirements:
Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
Defined Approach Requirements:
Failures of critical security control systems are detected, alerted, and addressed promptly, including but not limited to failure of the following critical security control systems:
- Network security controls.
- IDS/IPS.
- Change-detection mechanisms.
- Anti-malware solutions.
- Physical access controls.
- Logical access controls.
- Audit logging mechanisms.
- Segmentation controls (if used).
- Audit log review mechanisms.
- Automated security testing tools (if used).
Customized Approach Objective:
Failures in critical security control systems are promptly identified and addressed.
Applicability Notes:
This requirement applies to all entities, including service providers, and will supersede Requirement 10.7.1 as of 31 March 2025. It includes two additional critical security control systems not in Requirement 10.7.1.
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:
Failures in critical security control systems are promptly identified and addressed.
Applicability Notes:
This requirement applies to all entities, including service providers, and will supersede Requirement 10.7.1 as of 31 March 2025. It includes two additional critical security control systems not in Requirement 10.7.1.
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:
- 10.7.2.a Examine documentation to verify that processes are defined for the prompt detection and addressing of failures of critical security control systems, including but not limited to failure of all elements specified in this requirement.
- 10.7.2.b Observe detection and alerting processes and interview personnel to verify that failures of critical security control systems are detected and reported, and that failure of a critical security control results in the generation of an alert.
Purpose:
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE.
Good Practice:
The specific types of failures may vary, depending on the function of the device system component and technology in use. However, typical failures include a system no longer performing its security function or not functioning in its intended manner—for example, a firewall erasing its rules or going offline.
Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise system components and steal account data from the CDE.
Good Practice:
The specific types of failures may vary, depending on the function of the device system component and technology in use. However, typical failures include a system no longer performing its security function or not functioning in its intended manner—for example, a firewall erasing its rules or going offline.
Requirement 10.7.3
10.7.3
Defined Approach Requirements:
Failures of any critical security controls systems are responded to promptly, including but not limited to:
Defined Approach Requirements:
Failures of any critical security controls systems are responded to promptly, including but not limited to:
- Restoring security functions.
- Identifying and documenting the duration (date and time from start to end) of the security failure.
- Identifying and documenting the cause(s) of failure and documenting required remediation.
- Identifying and addressing any security issues that arose during the failure.
- Determining whether further actions are required as a result of the security failure.
- Implementing controls to prevent the cause of failure from reoccurring.
- Resuming monitoring of security controls.
Customized Approach Objective:
Failures of critical security control systems are analyzed, contained, and resolved, and security controls restored to minimize impact. Resulting security issues are addressed, and measures taken to prevent reoccurrence.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider until 31 March 2025, after which this requirement will apply to all entities.
This is a current v3.2.1 requirement that applies to service providers only. However, this requirement is a best practice for all other entities until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Defined Approach Testing Procedures:
Failures of critical security control systems are analyzed, contained, and resolved, and security controls restored to minimize impact. Resulting security issues are addressed, and measures taken to prevent reoccurrence.
Applicability Notes:
This requirement applies only when the entity being assessed is a service provider until 31 March 2025, after which this requirement will apply to all entities.
This is a current v3.2.1 requirement that applies to service providers only. However, this requirement is a best practice for all other entities until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
Defined Approach Testing Procedures:
- 10.7.3.a Examine documentation and interview personnel to verify that processes are defined and implemented to respond to a failure of any critical security control system and include at least all elements specified in this requirement.
- 10.7.3.b Examine records to verify that failures of critical security control systems are documented to include:
- Identification of cause(s) of the failure.
- Duration (date and time start and end) of the security failure.
- Details of the remediation required to address the root cause.
Purpose:
If alerts from failures of critical security control systems are not responded to quickly and effectively, attackers may use this time to insert malicious software, gain control of a system, or steal data from the entity’s environment.
Good Practice:
Documented evidence (for example, records within a problem management system) should provide support that processes and procedures are in place to respond to security failures. In addition, personnel should be aware of their responsibilities in the event of a failure. Actions and responses to the failure should be captured in the documented evidence.
If alerts from failures of critical security control systems are not responded to quickly and effectively, attackers may use this time to insert malicious software, gain control of a system, or steal data from the entity’s environment.
Good Practice:
Documented evidence (for example, records within a problem management system) should provide support that processes and procedures are in place to respond to security failures. In addition, personnel should be aware of their responsibilities in the event of a failure. Actions and responses to the failure should be captured in the documented evidence.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.16.1.3
A.16.1.3 Сообщения о недостатках информационной безопасности
Мера обеспечения информационной безопасности: Работники и подрядчики, использующие информационные системы и услуги организации, должны обращать внимание на любые замеченные или предполагаемые недостатки информационной безопасности в системах или сервисах и сообщать о них
Мера обеспечения информационной безопасности: Работники и подрядчики, использующие информационные системы и услуги организации, должны обращать внимание на любые замеченные или предполагаемые недостатки информационной безопасности в системах или сервисах и сообщать о них
A.16.1.4
A.16.1.4 Оценка и принятие решений в отношении событий информационной безопасности
Мера обеспечения информационной безопасности: Должна быть проведена оценка событий информационной безопасности, и должно быть принято решение, следует ли их классифицировать как инциденты информационной безопасности
Мера обеспечения информационной безопасности: Должна быть проведена оценка событий информационной безопасности, и должно быть принято решение, следует ли их классифицировать как инциденты информационной безопасности
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 10.7.3
10.7.3
Определенные Требования к Подходу:
На сбои любых критически важных систем контроля безопасности оперативно реагируют, включая, но не ограничиваясь этим::
Определенные Требования к Подходу:
На сбои любых критически важных систем контроля безопасности оперативно реагируют, включая, но не ограничиваясь этим::
- Восстановление функций безопасности.
- Определение и документирование продолжительности (даты и времени от начала до конца) сбоя системы безопасности.
- Выявление и документирование причины (причин) сбоя и документирование необходимых исправлений.
- Выявление и устранение любых проблем безопасности, возникших во время сбоя.
- Определение того, требуются ли дальнейшие действия в результате сбоя системы безопасности.
- Внедрение средств контроля для предотвращения повторного возникновения причины сбоя.
- Возобновление мониторинга средств контроля безопасности.
Цель Индивидуального подхода:
Сбои в критически важных системах контроля безопасности анализируются, локализуются и устраняются, а средства контроля безопасности восстанавливаются для минимизации последствий. Возникающие в результате проблемы безопасности устраняются, и принимаются меры для предотвращения повторения.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемая организация является поставщиком услуг до 31 марта 2025 года, после чего это требование будет применяться ко всем организациям.
Это действующее требование версии v3.2.1, которое применяется только к поставщикам услуг. Однако это требование является наилучшей практикой для всех других организаций до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Сбои в критически важных системах контроля безопасности анализируются, локализуются и устраняются, а средства контроля безопасности восстанавливаются для минимизации последствий. Возникающие в результате проблемы безопасности устраняются, и принимаются меры для предотвращения повторения.
Примечания по применению:
Это требование применяется только в том случае, если оцениваемая организация является поставщиком услуг до 31 марта 2025 года, после чего это требование будет применяться ко всем организациям.
Это действующее требование версии v3.2.1, которое применяется только к поставщикам услуг. Однако это требование является наилучшей практикой для всех других организаций до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 10.7.3.a Изучите документацию и опросите персонал, чтобы убедиться, что процессы определены и внедрены для реагирования на сбой любой критической системы контроля безопасности и включают, по крайней мере, все элементы, указанные в этом требовании.
- 10.7.3.b Изучите записи, чтобы убедиться, что сбои критически важных систем контроля безопасности задокументированы, чтобы включить:
- Определение причины (причин) сбоя.
- Продолжительность (дата и время начала и окончания) сбоя системы безопасности.
- Подробная информация о мерах по устранению неполадок, необходимых для устранения основной причины.
Цель:
Если на предупреждения о сбоях критически важных систем контроля безопасности не реагируют быстро и эффективно, злоумышленники могут использовать это время для внедрения вредоносного программного обеспечения, получения контроля над системой или кражи данных из среды организации.
Надлежащая практика:
Документированные доказательства (например, записи в системе управления проблемами) должны подтверждать наличие процессов и процедур для реагирования на сбои в системе безопасности. Кроме того, персонал должен быть осведомлен о своих обязанностях в случае сбоя. Действия и реакции на сбой должны быть отражены в документированных доказательствах.
Если на предупреждения о сбоях критически важных систем контроля безопасности не реагируют быстро и эффективно, злоумышленники могут использовать это время для внедрения вредоносного программного обеспечения, получения контроля над системой или кражи данных из среды организации.
Надлежащая практика:
Документированные доказательства (например, записи в системе управления проблемами) должны подтверждать наличие процессов и процедур для реагирования на сбои в системе безопасности. Кроме того, персонал должен быть осведомлен о своих обязанностях в случае сбоя. Действия и реакции на сбой должны быть отражены в документированных доказательствах.
Requirement 10.4.3
10.4.3
Определенные Требования к Подходу:
Исключения и аномалии, выявленные в ходе процесса проверки, устраняются.
Цель Индивидуального подхода:
Рассматриваются подозрительные или аномальные действия.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Исключения и аномалии, выявленные в ходе процесса проверки, устраняются.
Цель Индивидуального подхода:
Рассматриваются подозрительные или аномальные действия.
Определенные Процедуры Тестирования Подхода:
- 10.4.3.a Изучите политики и процедуры безопасности, чтобы убедиться, что определены процессы для устранения исключений и аномалий, выявленных в процессе проверки.
- 10.4.3.b Наблюдайте за процессами и проводите собеседования с персоналом, чтобы убедиться, что при выявлении исключений и аномалий они устраняются.
Цель:
Если исключения и аномалии, выявленные в процессе просмотра журнала, не исследуются, организация может не знать о несанкционированных и потенциально вредоносных действиях, происходящих в ее сети.
Надлежащая практика:
Организациям следует рассмотреть вопрос о том, как учитывать следующее при разработке своих процессов определения и управления исключениями и аномалиями:
Если исключения и аномалии, выявленные в процессе просмотра журнала, не исследуются, организация может не знать о несанкционированных и потенциально вредоносных действиях, происходящих в ее сети.
Надлежащая практика:
Организациям следует рассмотреть вопрос о том, как учитывать следующее при разработке своих процессов определения и управления исключениями и аномалиями:
- Как записываются действия по проверке журнала, • Как ранжировать и расставлять приоритеты исключений и аномалий,
- Какие процедуры должны быть предусмотрены для сообщения об исключениях и аномалиях и их эскалации, а также
- Кто отвечает за расследование и за любые задачи по исправлению положения.
Requirement 10.7.2
10.7.2
Определенные Требования к Подходу:
Сбои критических систем контроля безопасности обнаруживаются, предупреждаются и оперативно устраняются, включая, но не ограничиваясь, отказ следующих критических систем контроля безопасности:
Определенные Требования к Подходу:
Сбои критических систем контроля безопасности обнаруживаются, предупреждаются и оперативно устраняются, включая, но не ограничиваясь, отказ следующих критических систем контроля безопасности:
- Средства управления сетевой безопасностью.
- IDS/IPS.
- Механизмы обнаружения изменений.
- Решения для защиты от вредоносных программ.
- Контроль физического доступа.
- Логический контроль доступа.
- Механизмы ведения журнала аудита.
- Элементы управления сегментацией (если они используются).
- Механизмы проверки журналов аудита.
- Автоматизированные средства тестирования безопасности (если они используются).
Цель Индивидуального подхода:
Сбои в критически важных системах контроля безопасности оперативно выявляются и устраняются.
Примечания по применению:
Это требование распространяется на все организации, включая поставщиков услуг, и заменит требование 10.7.1 с 31 марта 2025 года. Он включает в себя две дополнительные критически важные системы контроля безопасности, не указанные в требовании 10.7.1.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
Сбои в критически важных системах контроля безопасности оперативно выявляются и устраняются.
Примечания по применению:
Это требование распространяется на все организации, включая поставщиков услуг, и заменит требование 10.7.1 с 31 марта 2025 года. Он включает в себя две дополнительные критически важные системы контроля безопасности, не указанные в требовании 10.7.1.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
Определенные Процедуры Тестирования Подхода:
- 10.7.2.a Изучите документацию, чтобы убедиться, что определены процессы для оперативного обнаружения и устранения сбоев критических систем управления безопасностью, включая, но не ограничиваясь отказом всех элементов, указанных в этом требовании.
- 10.7.2.b Наблюдайте за процессами обнаружения и оповещения и опрашивайте персонал, чтобы убедиться, что сбои критических систем контроля безопасности обнаружены и сообщены, и что сбой критического контроля безопасности приводит к генерации предупреждения.
Цель:
Без формальных процессов обнаружения и оповещения о сбое критических средств защиты сбои могут оставаться незамеченными в течение длительного времени и предоставлять злоумышленникам достаточно времени для компрометации системных компонентов и кражи данных учетной записи из CDE.
Надлежащая практика:
Конкретные типы отказов могут варьироваться в зависимости от функции системного компонента устройства и используемой технологии. Однако типичные сбои включают в себя то, что система больше не выполняет свою функцию безопасности или не функционирует должным образом — например, брандмауэр стирает свои правила или переходит в автономный режим.
Без формальных процессов обнаружения и оповещения о сбое критических средств защиты сбои могут оставаться незамеченными в течение длительного времени и предоставлять злоумышленникам достаточно времени для компрометации системных компонентов и кражи данных учетной записи из CDE.
Надлежащая практика:
Конкретные типы отказов могут варьироваться в зависимости от функции системного компонента устройства и используемой технологии. Однако типичные сбои включают в себя то, что система больше не выполняет свою функцию безопасности или не функционирует должным образом — например, брандмауэр стирает свои правила или переходит в автономный режим.
Requirement 12.10.6
12.10.6
Определенные Требования к Подходу:
План реагирования на инциденты безопасности модифицируется и развивается в соответствии с извлеченными уроками и с учетом отраслевых разработок.
Цель Индивидуального подхода:
Эффективность и точность плана реагирования на инциденты пересматриваются и обновляются после каждого вызова.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
План реагирования на инциденты безопасности модифицируется и развивается в соответствии с извлеченными уроками и с учетом отраслевых разработок.
Цель Индивидуального подхода:
Эффективность и точность плана реагирования на инциденты пересматриваются и обновляются после каждого вызова.
Определенные Процедуры Тестирования Подхода:
- 12.10.6.a Изучить политики и процедуры для проверки того, что определены процессы для изменения и совершенствования плана реагирования на инциденты безопасности в соответствии с извлеченными уроками и с учетом отраслевых разработок.
- 12.10.6.b Изучите план реагирования на инциденты безопасности и опросите ответственный персонал, чтобы убедиться, что план реагирования на инциденты изменен и доработан в соответствии с извлеченными уроками и с учетом отраслевых разработок.
Цель:
Включение извлеченных уроков в план реагирования на инциденты после инцидента и в соответствии с развитием отрасли помогает поддерживать план в актуальном состоянии и реагировать на возникающие угрозы и тенденции в области безопасности.
Надлежащая практика:
Работа по извлечению уроков должна охватывать персонал всех уровней. Хотя он часто включается как часть анализа всего инцидента, он должен быть сосредоточен на том, как можно улучшить реакцию организации на инцидент.
Важно не просто рассмотреть элементы реагирования, которые не привели к запланированным результатам, но и понять, что сработало хорошо, и могут ли уроки из тех элементов, которые сработали хорошо, быть применены в тех областях плана, которые не сработали.
Другим способом оптимизации плана реагирования на инциденты организации является понимание атак, совершенных против других организаций, и использование этой информации для точной настройки процедур обнаружения, локализации, смягчения последствий или восстановления организации.
Включение извлеченных уроков в план реагирования на инциденты после инцидента и в соответствии с развитием отрасли помогает поддерживать план в актуальном состоянии и реагировать на возникающие угрозы и тенденции в области безопасности.
Надлежащая практика:
Работа по извлечению уроков должна охватывать персонал всех уровней. Хотя он часто включается как часть анализа всего инцидента, он должен быть сосредоточен на том, как можно улучшить реакцию организации на инцидент.
Важно не просто рассмотреть элементы реагирования, которые не привели к запланированным результатам, но и понять, что сработало хорошо, и могут ли уроки из тех элементов, которые сработали хорошо, быть применены в тех областях плана, которые не сработали.
Другим способом оптимизации плана реагирования на инциденты организации является понимание атак, совершенных против других организаций, и использование этой информации для точной настройки процедур обнаружения, локализации, смягчения последствий или восстановления организации.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.8.16
А.8.16 Деятельность по мониторингу
Сети, системы и приложения должны быть объектом мониторинга на предмет выявления аномального поведения и выполнения соответствующих действий по оценке возможных инцидентов ИБ.
Сети, системы и приложения должны быть объектом мониторинга на предмет выявления аномального поведения и выполнения соответствующих действий по оценке возможных инцидентов ИБ.
А.5.25
А.5.25 Оценка и принятие решений в отношении событий ИБ
Организация должна оценивать события ИБ и решать, следует ли их относить к инцидентам ИБ.
Организация должна оценивать события ИБ и решать, следует ли их относить к инцидентам ИБ.
Положение Банка России № 779-П от 15.11.2021 "Обязательные для некредитных финансовых организаций требований к операционной надежности при осуществлении видов деятельности, предусмотренных частью первой статьи 76.1 Федерального закона от 10 июля 2002 года N 86-ФЗ "О Центральном банке"":
п. 1.6.
1.6. Некредитные финансовые организации, обязанные соблюдать усиленный, стандартный или минимальный уровень защиты информации, в рамках обеспечения операционной надежности должны обеспечивать в отношении выявления, регистрации событий операционного риска, связанных с нарушением операционной надежности, и реагирования на них, а также восстановления выполнения технологических процессов, указанных в приложении к настоящему Положению, и функционирования своих объектов информационной инфраструктуры после реализации указанных событий выполнение следующих требований:
- выявление и регистрацию событий операционного риска, связанных с нарушением операционной надежности;
- реагирование на события операционного риска, связанные с нарушением операционной надежности, в отношении критичной архитектуры;
- восстановление выполнения технологических процессов, указанных в приложении к настоящему Положению, и функционирования своих объектов информационной инфраструктуры после реализации событий операционного риска, связанных с нарушением операционной надежности;
- проведение анализа причин и последствий реализации событий операционного риска, связанных с нарушением операционной надежности;
- организацию взаимодействия между подразделениями (работниками) некредитной финансовой организации, ответственными за разработку технологических процессов, указанных в приложении к настоящему Положению, поддержание их выполнения, их реализацию, между собой и Банком России, иными участниками технологического процесса в рамках реагирования на события операционного риска, связанные с нарушением операционной надежности, и восстановления выполнения технологических процессов, указанных в приложении к настоящему Положению, а также функционирования своих объектов информационной инфраструктуры после реализации событий операционного риска, связанных с нарушением операционной надежности.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.8.16
А.8.16 Monitoring activities
Networks, systems and applications shall be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents.
Networks, systems and applications shall be monitored for anomalous behaviour and appropriate actions taken to evaluate potential information security incidents.
А.5.25
А.5.25 Assessment and decision on information security events
The organization shall assess information security events and decide if they are to be categorized as information security incidents.
The organization shall assess information security events and decide if they are to be categorized as information security incidents.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.