Куда я попал?
Стандарт Банка России № СТО БР ИББС-1.4-2018 от 01.07.2018
Управление риском нарушения информационной безопасности при аутсорсинге
Р. 10 п. 3
Для проведения оценки соответствия по документу войдите в систему.
Список требований
Похожие требования
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 8":
ПОН.8
ПОН.8 Распределение ответственности в рамках реализации процесса обеспечения операционной надежности при привлечении поставщиков услуг (в том числе поставщиков облачных услуг)
ГОСТ Р № 57580.3-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Управление риском реализации информационных угроз и обеспечение операционной надежности. Общие положения.":
ЗИУ.10.2
ЗИУ.10.2 Важность привлечения поставщиков услуг, отвечающих требованиям финансовой организации к обеспечению операционной надежности и защиты информации, а также заключения соглашения, определяющего детальные условия и разграничение ответственности;
ГОСТ Р № 57580.4-2022 от 01.02.2023 "Безопасность финансовых (банковских) операций. Обеспечение операционной надежности. Базовый состав организационных и технических мер. Раздел 7":
РВН.6.3
РВН.6.3 Осуществление контроля за выполнением поставщиком требований, установленных в рамках договорных отношений.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard":
Requirement 12.8.4
12.8.4
Defined Approach Requirements:
A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.
Customized Approach Objective:
The PCI DSS compliance status of TPSPs is verified periodically.
Applicability Notes:
Where an entity has an agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity (for example, via a firewall service), the entity must work with the TPSP to make sure the applicable PCI DSS requirements are met. If the TPSP does not meet those applicable PCI DSS requirements, then those requirements are also “not in place” for the entity.
Defined Approach Testing Procedures:
Defined Approach Requirements:
A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.
Customized Approach Objective:
The PCI DSS compliance status of TPSPs is verified periodically.
Applicability Notes:
Where an entity has an agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity (for example, via a firewall service), the entity must work with the TPSP to make sure the applicable PCI DSS requirements are met. If the TPSP does not meet those applicable PCI DSS requirements, then those requirements are also “not in place” for the entity.
Defined Approach Testing Procedures:
- 12.8.4.a Examine policies and procedures to verify that processes are defined to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.
- 12.8.4.b Examine documentation and interview responsible personnel to verify that the PCI DSS compliance status of each TPSP is monitored at least once every 12 months.
Purpose:
Knowing the PCI DSS compliance status of all engaged TPSPs provides assurance and awareness about whether they comply with the requirements applicable to the services they offer to the organization.
Good Practice:
If the TPSP offers a variety of services, the compliance status the entity monitors should be specific to those services delivered to the entity and those services in scope for the entity’s PCI DSS assessment.
If a TPSP has a PCI DSS Attestation of Compliance (AOC), the expectation is that the TPSP should provide that to customers upon request to demonstrate their PCI DSS compliance status.
If the TPSP did not undergo a PCI DSS assessment, it may be able to provide other sufficient evidence to demonstrate that it has met the applicable requirements without undergoing a formal compliance validation. For example, the TPSP can provide specific evidence to the entity’s assessor so the assessor can confirm applicable requirements are met. Alternatively, the TPSP can elect to undergo multiple on-demand assessments by each of its customers’ assessors, with each assessment targeted to confirm that applicable requirements are met.
Further Information:
For more information about third-party service providers, refer to:
Knowing the PCI DSS compliance status of all engaged TPSPs provides assurance and awareness about whether they comply with the requirements applicable to the services they offer to the organization.
Good Practice:
If the TPSP offers a variety of services, the compliance status the entity monitors should be specific to those services delivered to the entity and those services in scope for the entity’s PCI DSS assessment.
If a TPSP has a PCI DSS Attestation of Compliance (AOC), the expectation is that the TPSP should provide that to customers upon request to demonstrate their PCI DSS compliance status.
If the TPSP did not undergo a PCI DSS assessment, it may be able to provide other sufficient evidence to demonstrate that it has met the applicable requirements without undergoing a formal compliance validation. For example, the TPSP can provide specific evidence to the entity’s assessor so the assessor can confirm applicable requirements are met. Alternatively, the TPSP can elect to undergo multiple on-demand assessments by each of its customers’ assessors, with each assessment targeted to confirm that applicable requirements are met.
Further Information:
For more information about third-party service providers, refer to:
- PCI DSS section: Use of Third-Party Service Providers.
- Information Supplement: Third-Party Security Assurance.
Requirement 12.8.2
12.8.2
Defined Approach Requirements:
Written agreements with TPSPs are maintained as follows:
Defined Approach Requirements:
Written agreements with TPSPs are maintained as follows:
- Written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of the CDE.
- Written agreements include acknowledgments from TPSPs that they are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that they could impact the security of the entity’s CDE.
Customized Approach Objective:
Records are maintained of each TPSP’s acknowledgment of its responsibility to protect account data.
Applicability Notes:
The exact wording of an acknowledgment will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgment does not have to include the exact wording provided in this requirement.
Evidence that a TPSP is meeting PCI DSS requirements (for example, a PCI DSS Attestation of Compliance (AOC) or a declaration on a company’s website) is not the same as a written agreement specified in this requirement.
Defined Approach Testing Procedures:
Records are maintained of each TPSP’s acknowledgment of its responsibility to protect account data.
Applicability Notes:
The exact wording of an acknowledgment will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgment does not have to include the exact wording provided in this requirement.
Evidence that a TPSP is meeting PCI DSS requirements (for example, a PCI DSS Attestation of Compliance (AOC) or a declaration on a company’s website) is not the same as a written agreement specified in this requirement.
Defined Approach Testing Procedures:
- 12.8.2.a Examine policies and procedures to verify that processes are defined to maintain written agreements with all TPSPs in accordance with all elements specified in this requirement.
- 12.8.2.b Examine written agreements with TPSPs to verify they are maintained in accordance with all elements as specified in this requirement.
Purpose:
The written acknowledgment from a TPSP demonstrates its commitment to maintaining proper security of account data that it obtains from its customers and that the TPSP is fully aware of the assets that could be affected during the provisioning of the TPSP’s service. The extent to which a specific TPSP is responsible for the security of account data will depend on the service provided and the agreement between the provider and assessed entity (the customer).
In conjunction with Requirement 12.9.1, this requirement is intended to promote a consistent level of understanding between parties about their applicable PCI DSS responsibilities. For example, the agreement may include the applicable PCI DSS requirements to be maintained as part of the provided service.
Good Practice:
The entity may also want to consider including in their written agreement with a TPSP that the TPSP will support the entity’s request for information per Requirement 12.9.2. Entities will also want to understand whether any TPSPs have “nested” relationships with other TPSPs, meaning the primary TPSP contracts with another TPSP(s) for the purposes of providing a service.
It is important to understand whether the primary TPSP is relying on the secondary TPSP(s) to achieve overall compliance of a service, and what types of written agreements the primary TPSP has in place with the secondary TPSPs. Entities can consider including coverage in their written agreement for any “nested” TPSPs a primary TPSP may use.
Further Information:
Refer to the “Information Supplement: Third-Party Security Assurance for further guidance.
The written acknowledgment from a TPSP demonstrates its commitment to maintaining proper security of account data that it obtains from its customers and that the TPSP is fully aware of the assets that could be affected during the provisioning of the TPSP’s service. The extent to which a specific TPSP is responsible for the security of account data will depend on the service provided and the agreement between the provider and assessed entity (the customer).
In conjunction with Requirement 12.9.1, this requirement is intended to promote a consistent level of understanding between parties about their applicable PCI DSS responsibilities. For example, the agreement may include the applicable PCI DSS requirements to be maintained as part of the provided service.
Good Practice:
The entity may also want to consider including in their written agreement with a TPSP that the TPSP will support the entity’s request for information per Requirement 12.9.2. Entities will also want to understand whether any TPSPs have “nested” relationships with other TPSPs, meaning the primary TPSP contracts with another TPSP(s) for the purposes of providing a service.
It is important to understand whether the primary TPSP is relying on the secondary TPSP(s) to achieve overall compliance of a service, and what types of written agreements the primary TPSP has in place with the secondary TPSPs. Entities can consider including coverage in their written agreement for any “nested” TPSPs a primary TPSP may use.
Further Information:
Refer to the “Information Supplement: Third-Party Security Assurance for further guidance.
ГОСТ Р № ИСО/МЭК 27001-2021 от 01.01.2022 "Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования - Приложение А":
A.13.2.4
A.13.2.4 Соглашения о конфиденциальности или неразглашении
Мера обеспечения информационной безопасности: Требования в отношении соглашений о конфиденциальности или неразглашении, отражающие потребности организации в обеспечении защиты информации, должны быть идентифицированы, документально оформлены и регулярно пересматриваться
Мера обеспечения информационной безопасности: Требования в отношении соглашений о конфиденциальности или неразглашении, отражающие потребности организации в обеспечении защиты информации, должны быть идентифицированы, документально оформлены и регулярно пересматриваться
A.14.2.7
A.14.2.7 Разработка с использованием аутсорсинга
Мера обеспечения информационной безопасности: Организация должна осуществлять надзор и мониторинг разработки систем, выполняемой подрядчиками
Мера обеспечения информационной безопасности: Организация должна осуществлять надзор и мониторинг разработки систем, выполняемой подрядчиками
A.15.1.2
A.15.1.2 Рассмотрение вопросов безопасности в соглашениях с поставщиками
Мера обеспечения информационной безопасности: Все соответствующие требования информационной безопасности должны быть установлены и согласованы с каждым поставщиком, который может получить доступ к информации организации, обрабатывать, хранить, передавать информацию или предоставлять соответствующие компоненты ИТ-инфраструктуры
Мера обеспечения информационной безопасности: Все соответствующие требования информационной безопасности должны быть установлены и согласованы с каждым поставщиком, который может получить доступ к информации организации, обрабатывать, хранить, передавать информацию или предоставлять соответствующие компоненты ИТ-инфраструктуры
Положение Банка России № 802-П от 25.07.2022 "О требованиях к защите информации в платежной системе Банка России":
П. 7 п.п. 1
7.1. Участники ССНП, участники СБП, ОПКЦ СБП и ОУИО СБП должны разработать и утвердить внутренние документы, регламентирующие выполнение следующих процессов (направлений) защиты информации в рамках процессов (направлений) защиты информации, предусмотренных подпунктом 7.1.1 пункта 7.1 раздела 7 ГОСТ Р 57580.1-2017:
- обеспечение защиты информации при управлении доступом;
- обеспечение защиты вычислительных сетей;
- контроль целостности и защищенности информационной инфраструктуры;
- защита от вредоносного кода;
- предотвращение утечек информации;
- управление инцидентами защиты информации;
- защита среды виртуализации;
- защита информации при осуществлении удаленного логического доступа с использованием мобильных (переносных) устройств.
Framework № PCI DSS 4.0 от 01.03.2022 "Payment Card Industry Data Security Standard (RU)":
Requirement 12.8.2
12.8.2
Определенные Требования к Подходу:
Письменные соглашения с TPSP поддерживаются следующим образом:
Определенные Требования к Подходу:
Письменные соглашения с TPSP поддерживаются следующим образом:
- Со всеми TPPS, которым передаются данные учетной записи или которые могут повлиять на безопасность CDE, поддерживаются письменные соглашения.
- Письменные соглашения включают подтверждения от TPPS о том, что они несут ответственность за безопасность учетных данных, которыми владеют TPPS или иным образом хранят, обрабатывают или передают от имени организации, или в той степени, в какой они могут повлиять на безопасность CDE организации.
Цель Индивидуального подхода:
Ведутся записи о подтверждении каждым TPSP своей ответственности за защиту данных учетной записи.
Примечания по применению:
Точная формулировка подтверждения будет зависеть от соглашения между двумя сторонами, деталей предоставляемой услуги и обязанностей, возложенных на каждую сторону. Подтверждение не обязательно должно содержать точную формулировку, предусмотренную в этом требовании.
Доказательства того, что TPSP соответствует требованиям PCI DSS (например, сертификат соответствия PCI DSS (AOC) или декларация на веб-сайте компании), не совпадают с письменным соглашением, указанным в этом требовании.
Определенные Процедуры Тестирования Подхода:
Ведутся записи о подтверждении каждым TPSP своей ответственности за защиту данных учетной записи.
Примечания по применению:
Точная формулировка подтверждения будет зависеть от соглашения между двумя сторонами, деталей предоставляемой услуги и обязанностей, возложенных на каждую сторону. Подтверждение не обязательно должно содержать точную формулировку, предусмотренную в этом требовании.
Доказательства того, что TPSP соответствует требованиям PCI DSS (например, сертификат соответствия PCI DSS (AOC) или декларация на веб-сайте компании), не совпадают с письменным соглашением, указанным в этом требовании.
Определенные Процедуры Тестирования Подхода:
- 12.8.2.a Изучить политики и процедуры, чтобы убедиться, что процессы определены для поддержания письменных соглашений со всеми TPSP в соответствии со всеми элементами, указанными в этом требовании.
- 12.8.2.b Изучите письменные соглашения с TPSP, чтобы убедиться, что они поддерживаются в соответствии со всеми элементами, указанными в этом требовании.
Цель:
Письменное подтверждение от TPSP демонстрирует его приверженность поддержанию надлежащей безопасности учетных данных, которые он получает от своих клиентов, и что TPSP полностью осведомлен об активах, которые могут быть затронуты во время предоставления услуг TPSP. Степень, в которой конкретный TPSP несет ответственность за безопасность данных учетной записи, будет зависеть от предоставляемой услуги и соглашения между поставщиком и оцениваемой организацией (клиентом).
В сочетании с требованием 12.9.1 это требование призвано способствовать постоянному уровню понимания между сторонами их применимых обязанностей по PCI DSS. Например, соглашение может включать применимые требования PCI DSS, которые должны поддерживаться в рамках предоставляемой услуги.
Надлежащая практика:
Организация может также захотеть включить в свое письменное соглашение с TPSP, что TPSP будет поддерживать запрос организации о предоставлении информации в соответствии с требованием 12.9.2. Организации также захотят понять, имеют ли какие-либо TPSP “вложенные” отношения с другими TPSP, что означает, что первичный TPSP заключает контракты с другим TPSP (ами) на цели предоставления услуги.
Важно понимать, полагается ли первичный TPSP на вторичный TPSP(ы) для достижения общего соответствия услуги, и какие типы письменных соглашений заключены у первичного TPSP с вторичными TPSP. Организации могут рассмотреть возможность включения покрытия в свое письменное соглашение для любых “вложенных” TPSP, которые может использовать основной TPSP.
Дополнительная информация:
Дополнительные указания см. в разделе “Информационное дополнение: Обеспечение безопасности третьей стороной".
Письменное подтверждение от TPSP демонстрирует его приверженность поддержанию надлежащей безопасности учетных данных, которые он получает от своих клиентов, и что TPSP полностью осведомлен об активах, которые могут быть затронуты во время предоставления услуг TPSP. Степень, в которой конкретный TPSP несет ответственность за безопасность данных учетной записи, будет зависеть от предоставляемой услуги и соглашения между поставщиком и оцениваемой организацией (клиентом).
В сочетании с требованием 12.9.1 это требование призвано способствовать постоянному уровню понимания между сторонами их применимых обязанностей по PCI DSS. Например, соглашение может включать применимые требования PCI DSS, которые должны поддерживаться в рамках предоставляемой услуги.
Надлежащая практика:
Организация может также захотеть включить в свое письменное соглашение с TPSP, что TPSP будет поддерживать запрос организации о предоставлении информации в соответствии с требованием 12.9.2. Организации также захотят понять, имеют ли какие-либо TPSP “вложенные” отношения с другими TPSP, что означает, что первичный TPSP заключает контракты с другим TPSP (ами) на цели предоставления услуги.
Важно понимать, полагается ли первичный TPSP на вторичный TPSP(ы) для достижения общего соответствия услуги, и какие типы письменных соглашений заключены у первичного TPSP с вторичными TPSP. Организации могут рассмотреть возможность включения покрытия в свое письменное соглашение для любых “вложенных” TPSP, которые может использовать основной TPSP.
Дополнительная информация:
Дополнительные указания см. в разделе “Информационное дополнение: Обеспечение безопасности третьей стороной".
Requirement 12.8.4
12.8.4
Определенные Требования к Подходу:
Внедрена программа для мониторинга статуса соответствия TPSP PCI DSS не реже одного раза в 12 месяцев.
Цель Индивидуального подхода:
Статус соответствия TPSP стандарту PCI DSS периодически проверяется.
Примечания по применению:
Если у организации есть соглашение с TPSP о выполнении требований PCI DSS от имени организации (например, через службу брандмауэра), организация должна работать с TPSP, чтобы убедиться, что применимые требования PCI DSS соблюдены. Если TPSP не соответствует этим применимым требованиям PCI DSS, то эти требования также “не действуют” для организации.
Определенные Процедуры Тестирования Подхода:
Определенные Требования к Подходу:
Внедрена программа для мониторинга статуса соответствия TPSP PCI DSS не реже одного раза в 12 месяцев.
Цель Индивидуального подхода:
Статус соответствия TPSP стандарту PCI DSS периодически проверяется.
Примечания по применению:
Если у организации есть соглашение с TPSP о выполнении требований PCI DSS от имени организации (например, через службу брандмауэра), организация должна работать с TPSP, чтобы убедиться, что применимые требования PCI DSS соблюдены. Если TPSP не соответствует этим применимым требованиям PCI DSS, то эти требования также “не действуют” для организации.
Определенные Процедуры Тестирования Подхода:
- 12.8.4.a Изучайте политики и процедуры, чтобы убедиться, что определены процессы для мониторинга статуса соответствия TPSP PCI DSS не реже одного раза в 12 месяцев.
- 12.8.4.b Изучите документацию и опросите ответственный персонал, чтобы убедиться, что статус соответствия PCI DSS каждого TPSP контролируется не реже одного раза в 12 месяцев.
Цель:
Знание статуса соответствия PCI DSS всех задействованных TPPS обеспечивает уверенность и осведомленность о том, соответствуют ли они требованиям, применимым к услугам, которые они предлагают организации.
Надлежащая практика:
Если TPSP предлагает различные услуги, статус соответствия, который отслеживает организация, должен быть специфичным для тех услуг, которые предоставляются организации, и тех услуг, которые подпадают под оценку PCI DSS организации.
Если у TPSP есть сертификат соответствия PCI DSS (AOC), ожидается, что TPSP должен предоставить его клиентам по запросу, чтобы продемонстрировать их статус соответствия PCI DSS.
Если TPSP не проходил оценку PCI DSS, он может быть в состоянии предоставить другие достаточные доказательства, чтобы продемонстрировать, что он соответствует применимым требованиям, не проходя формальную проверку соответствия. Например, TPSP может предоставить конкретные доказательства эксперту по оценке организации, чтобы эксперт мог подтвердить выполнение применимых требований. В качестве альтернативы, TPSP может выбрать проведение нескольких оценок по требованию каждым из оценщиков своих клиентов, причем каждая оценка направлена на подтверждение соответствия применимым требованиям.
Дополнительная информация:
Для получения дополнительной информации о сторонних поставщиках услуг обратитесь к:
Знание статуса соответствия PCI DSS всех задействованных TPPS обеспечивает уверенность и осведомленность о том, соответствуют ли они требованиям, применимым к услугам, которые они предлагают организации.
Надлежащая практика:
Если TPSP предлагает различные услуги, статус соответствия, который отслеживает организация, должен быть специфичным для тех услуг, которые предоставляются организации, и тех услуг, которые подпадают под оценку PCI DSS организации.
Если у TPSP есть сертификат соответствия PCI DSS (AOC), ожидается, что TPSP должен предоставить его клиентам по запросу, чтобы продемонстрировать их статус соответствия PCI DSS.
Если TPSP не проходил оценку PCI DSS, он может быть в состоянии предоставить другие достаточные доказательства, чтобы продемонстрировать, что он соответствует применимым требованиям, не проходя формальную проверку соответствия. Например, TPSP может предоставить конкретные доказательства эксперту по оценке организации, чтобы эксперт мог подтвердить выполнение применимых требований. В качестве альтернативы, TPSP может выбрать проведение нескольких оценок по требованию каждым из оценщиков своих клиентов, причем каждая оценка направлена на подтверждение соответствия применимым требованиям.
Дополнительная информация:
Для получения дополнительной информации о сторонних поставщиках услуг обратитесь к:
- Раздел PCI DSS: Использование сторонних поставщиков услуг.
- Информационное Дополнение: Обеспечение безопасности Третьей Стороной.
Стандарт № ИСО/МЭК 27001:2022(E) от 25.10.2022 "Информационная безопасность, кибербезопасность и защита частной жизни — Системы управления информационной безопасностью — Требования. Приложение А":
А.5.20
А.5.20 Учет ИБ в соглашениях с поставщиками
С каждым поставщиком, в зависимости от типа отношений с ним, должны быть установлены и согласованы соответствующие требования ИБ
С каждым поставщиком, в зависимости от типа отношений с ним, должны быть установлены и согласованы соответствующие требования ИБ
А.6.6
А.6.6 Соглашения о конфиденциальности или неразглашении
Должны быть идентифицированы, задокументированы, регулярно пересматриваться и подписываться персоналом и иными соответствующими заинтересованными сторонами соглашения о конфиденциальности или неразглашении, отражающие потребности организации в защите информации.
Должны быть идентифицированы, задокументированы, регулярно пересматриваться и подписываться персоналом и иными соответствующими заинтересованными сторонами соглашения о конфиденциальности или неразглашении, отражающие потребности организации в защите информации.
А.8.30
А.8.30 Разработка программного обеспечения третьей стороной
Организация должна направлять, подвергать мониторингу и пересматривать деятельность, относящуюся к разработке систем сторонними подрядчиками.
Организация должна направлять, подвергать мониторингу и пересматривать деятельность, относящуюся к разработке систем сторонними подрядчиками.
ГОСТ Р № ИСО/МЭК 27002-2021 от 30.11.2021 "Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности":
14.2.7
14.2.7 Разработка с использованием аутсорсинга
Мера обеспечения ИБ
Организация должна осуществлять надзор за разработкой систем, выполняемой подрядчиками, и ее мониторинг.
Руководство по применению
В тех случаях, когда разработка системы осуществляется сторонними организациями, для всей цепочки поставок организации необходимо учесть следующее:
- a) лицензионные соглашения, права на код и интеллектуальную собственность, связанные с находящимися на аутсорсинге разработками (см. 18.1.2);
- b) договорные требования к безопасным методам проектирования, программирования и тестирования (см. 14.2.1);
- c) предоставление утвержденной модели угроз внешнему разработчику;
- d) приемочные испытания на качество и точность результатов;
- e) предоставление доказательств того, что были применены пороговые критерии безопасности для установления минимально приемлемых уровней защищенности и конфиденциальности;
- f) предоставление доказательств того, что было выполнено тестирование в достаточном объеме, чтобы подтвердить отсутствие преднамеренного или непреднамеренного вредоносного содержимого в поставляемых продуктах;
- g) предоставление доказательств того, что было проведено достаточное тестирование для защиты от известных уязвимостей;
- h) механизмы условного депонирования, например, если исходный код больше недоступен;
- i) закрепленное в договоре право на аудит процессов и мер разработки;
- j) действующая документация среды сборки, используемая для создания конечных продуктов;
- k) организация несет ответственность за соблюдение действующего законодательства и проверку эффективности мер обеспечения ИБ.
Дополнительная информация
Дополнительную информацию об отношениях с поставщиками можно найти в ИСО/МЭК 27036 [21], [22], [23].
13.2.4
13.2.4 Соглашения о конфиденциальности или неразглашении
Мера обеспечения ИБ
Требования в отношении соглашений о конфиденциальности или неразглашении, отражающие потребности организации в обеспечении защиты информации, должны быть идентифицированы, документально оформлены и регулярно пересматриваться.
Руководство по применению
В соглашениях о конфиденциальности или неразглашении должно содержаться требование по защите конфиденциальной информации, выраженное юридическими терминами, имеющими исковую силу. Соглашения о конфиденциальности или неразглашении применимы к внешним сторонам или работникам организации. Содержание соглашения должно определяться с учетом типа другой стороны, предоставляемого доступа или обработки конфиденциальной информации. При определении требований к соглашениям о конфиденциальности или неразглашении необходимо учитывать следующее:
- a) определение информации, подлежащей защите (например, конфиденциальной информации);
- b) ожидаемый срок действия соглашения, включая случаи, когда конфиденциальность должна обеспечиваться в течение неопределенного времени;
- c) действия, необходимые при расторжении соглашения;
- d) обязанности и действия лиц, подписавших соглашение, во избежание несанкционированного раскрытия информации;
- e) право собственности на информацию, коммерческую тайну и интеллектуальную собственность и то, как это связано с защитой конфиденциальной информации;
- f) разрешенное использование конфиденциальной информации и права лиц, подписавших соглашение, в отношении использования информации;
- g) право на аудит и мониторинг деятельности, связанной с конфиденциальной информацией;
- h) процесс уведомления и сообщения о несанкционированном раскрытии или утечке конфиденциальной информации;
- i) условия, при которых информация должна быть возвращена или уничтожена в случае прекращения действия соглашения;
- j) предполагаемые действия, которые должны быть предприняты в случае нарушения соглашения.
Исходя из требований ИБ организации, может потребоваться добавление других элементов в соглашения о конфиденциальности или неразглашении.
Соглашения о конфиденциальности и неразглашении должны соответствовать всем применимым законам и нормативным документам, под юрисдикцию которых они подпадают (см. 18.1).
Требования соглашений о конфиденциальности и неразглашении следует пересматривать периодически и в тех случаях, когда происходят изменения, затрагивающие эти требования.
Дополнительная информация
Соглашения о конфиденциальности и неразглашении защищают информацию организации, а также надежным и правомочным образом информируют лиц, подписавших соглашение, об их ответственности за защиту, использование и разглашение информации.
В зависимости от различных обстоятельств организации могут потребоваться различные формы соглашений о конфиденциальности или неразглашении.
15.1.2
15.1.2 Рассмотрение вопросов безопасности в соглашениях с поставщиками
Мера обеспечения ИБ
Все соответствующие требования по ИБ должны быть установлены и согласованы с каждым поставщиком, который может получить доступ к информации организации, обрабатывать, хранить, передавать информацию или предоставлять соответствующие компоненты ИТ-инфраструктуры.
Руководство по применению
Соглашения с поставщиками должны быть разработаны и задокументированы, чтобы гарантировать, что между организацией и поставщиком нет недопонимания относительно взаимных обязательств по выполнению соответствующих требований по ИБ.
Для выполнения установленных требований ИБ следует рассмотреть включение в соглашения следующих условий:
- a) описание предоставляемой информации или информации, к которой предоставляется доступ, а также методов предоставления информации или получения доступа к ней;
- b) категории информации в соответствии с системой категорирования организации (см. 8.2); сопоставление, при необходимости, системы категорирования организации с системой категорирования поставщика;
- c) законодательные и нормативные требования, включая требования по защите данных, прав на интеллектуальную собственность и авторских прав, а также описание того, как будет обеспечено их соблюдение;
- d) обязательства каждой стороны договора по осуществлению согласованного набора мер обеспечения ИБ, включая управление доступом, анализ производительности, мониторинг, отчетность и аудит;
- e) правила приемлемого использования информации, включая неприемлемое использование, в случае необходимости;
- f) точный перечень персонала поставщика, который авторизован на доступ к информации или получение информации организации, либо процедуры или условия для назначения и аннулирования прав на доступ к информации или получение информации организации персоналом поставщика;
- g) политики ИБ, относящиеся к конкретному договору;
- h) требования и процедуры по управлению инцидентами (особенно уведомление и совместная работа по устранению последствий инцидентов);
- i) требования к обучению и осведомленности о конкретных процедурах и требования к ИБ, например для реагирования на инциденты, процедуры авторизации;
- j) соответствующие регламенты для субподряда, включая меры обеспечения ИБ, которые должны выполняться;
- k) соответствующие партнеры по соглашению, включая контактное лицо по вопросам ИБ;
- l) требования к предварительной проверке персонала поставщика, если таковые установлены, включая обязанности по проведению процедур предварительной проверки и информирования в случае, когда проверка не была завершена или ее результаты дают основания для сомнений или опасений;
- m) право на аудит процессов поставщика и осуществление мер обеспечения ИБ, связанных с соглашением;
- n) процессы устранения дефектов и разрешения конфликтов;
- o) обязательство поставщика по периодическому предоставлению независимого отчета об эффективности мер обеспечения ИБ и соглашения о своевременном решении соответствующих проблем, упомянутых в отчете;
- p) обязательства поставщика по соблюдению требований безопасности организации.
Дополнительная информация
Соглашения могут значительно различаться для разных организаций и разных типов поставщиков. В связи с этим следует уделить внимание тому, чтобы учесть все актуальные риски и требования ИБ. Соглашения с поставщиками могут также допускать участие других сторон (например, субподрядчиков).
В соглашении необходимо учесть процедуры обеспечения непрерывности производственных процессов в случае, если поставщик не в состоянии поставлять свои продукты или услуги, во избежание любых задержек из-за замены продуктов и услуг.
Стандарт № ISO/IEC 27001:2022(E) от 25.10.2022 "Information security, cybersecurity and privacy protection — Information security management systems — Requirements. Annex A":
А.6.6
А.6.6 Confidentiality or non-disclosure agreements
Confidentiality or non-disclosure agreements reflecting the organization’s needs for the protection of information shall be identified, documented, regularly reviewed and signed by personnel and other relevant interested parties.
Confidentiality or non-disclosure agreements reflecting the organization’s needs for the protection of information shall be identified, documented, regularly reviewed and signed by personnel and other relevant interested parties.
А.8.30
А.8.30 Outsourced development
The organization shall direct, monitor and review the activities related to outsourced system development.
The organization shall direct, monitor and review the activities related to outsourced system development.
А.5.20
А.5.20 Addressing information security within supplier agreements
Relevant information security requirements shall be established and agreed with each supplier based on the type of supplier relationship.
Relevant information security requirements shall be established and agreed with each supplier based on the type of supplier relationship.
Связанные защитные меры
Ничего не найдено
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.