SWIFT Customer Security Controls Framework v2022

7.1.7. ИБ АБС должна обеспечиваться на всех стадиях ЖЦ АБС, автоматизирующих банковские технологические процессы, с учетом интересов всех сторон, вовлеченных в процессы ЖЦ (разработчиков, заказчиков, поставщиков продуктов и услуг, эксплуатирующих и надзорных подразделений организации БС РФ).

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

ВИО.11.3 Сторонних информационных сервисов поставщиков услуг.

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

ID.BE-5: Установлены требования к устойчивости для поддержки предоставления критически важных услуг для всех состояний функционирования (например, при атаке, во время восстановления, во время нормального функционирования) 

ID.GV-2: Роли и обязанности в области информационной безопасности скоординорованы и согласованы с внутренними ролями и внешними партнерами 

ID.SC-2: С использованием процесса оценки рисков в киберцепочке поставок идентфицированы, расставлены приоритеты и оценены поставщики и партнеры критически важных информационных систем, компонентов и услуг

ID.SC-1: Идентфицированы, устанавлены, оцениваются, управляются и согласовываются заинтересованными сторонами организации все процессы управления рисками в кибер-цепочке 

ID.SC-5: С критичными поставщиками проводится планирование, тестирование реагирования и восстановления 

ID.SC-3: Поставщики и партнеры обязаны по контракту принять соответствующие меры, предназначенные для достижения целей программы информационной безопасности или плана управления рисками кибер-цепочки поставок 

ID.SC-4: Производиться контроль поставщиков и партнеров, чтобы подтвердить, что они выполнили свои обязательства в соответствии с требованиями. Проводятся обзоры аудитов, сводки результатов тестов или другие эквивалентные оценки поставщиков 

РВН.5 Планирование, реализация, контроль и совершенствование мероприятий, направленных на уменьшение негативного влияния риска внутреннего нарушителя, применяемых в отношении работников поставщика услуг, привлекаемого в рамках выполнения бизнес- и технологических процессов.

ВПУ.3.1 Определение приоритета в отношении поставщиков услуг, реализующих необходимые процедуры по обеспечению безопасности на этапах жизненного цикла поставляемых объектов информатизации, в том числе обеспечивающих «прозрачность» в отношении реализуемых ими процессов производства и сопровождения объектов информатизации, а также имеющих необходимую зрелость собственных процессов обеспечения безопасности цепи поставок, подтвержденную посредством проведения независимой оценки (внешнего аудита)**;

РВН.6.3 Осуществление контроля за выполнением поставщиком требований, установленных в рамках договорных отношений.

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

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:

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: 

12.8.5
Defined Approach Requirements: 
Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity. 

Customized Approach Objective:
Records detailing the PCI DSS requirements and related system components for which each TPSP is solely or jointly responsible, are maintained and reviewed periodically. 

Defined Approach Testing Procedures:

Purpose:
It is important that the entity understands which PCI DSS requirements and sub-requirements its TPSPs have agreed to meet, which requirements are shared between the TPSP and the entity, and for those that are shared, specifics about how the requirements are shared and which entity is responsible for meeting each sub-requirement. 
Without this shared understanding, it is inevitable that the entity and the TPSP will assume a given PCI DSS sub-requirement is the responsibility of the other party, and therefore that subrequirement may not be addressed at all. 
The specific information an entity maintains will depend on the particular agreement with their providers, the type of service, etc. TPSPs may define their PCI DSS responsibilities to be the same for all their customers; otherwise, this responsibility should be agreed upon by both the entity and TPSP. 

Good Practice:
Entities can document these responsibilities via a matrix that identifies all applicable PCI DSS requirements and indicates for each requirement whether the entity or TPSP is responsible for meeting that requirement or whether it is a shared responsibility. This type of document is often referred to as a responsibility matrix. 
It is also important for entities 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 how the primary TPSP is monitoring performance of the service and the PCI DSS compliance status of the secondary TPSP(s). Note that it is the responsibility of the primary TPSP to manage and monitor any secondary TPSPs. 

Further Information:
Refer to Information Supplement: Third-Party Security Assurance for a sample responsibility matrix template. 

8.3.10
Defined Approach Requirements: 
Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any singlefactor authentication implementation), then guidance is provided to customer users including: 

Customized Approach Objective:
Passwords/passphrases for service providers’ customers cannot be used indefinitely. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 
This requirement does not apply to accounts of consumer users accessing their own payment card information. 
This requirement for service providers will be superseded by Requirement 8.3.10.1 once 8.3.10.1 becomes effective. 

Defined Approach Testing Procedures:

Purpose:
Using a password/passphrase as the only authentication factor provides a single point of failure if compromised. Therefore, in these implementations, controls are needed to minimize how long malicious activity could occur via a compromised password/passphrase. 

Good Practice:
Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase and less time to use a compromised password. 

12.5.3
Defined Approach Requirements: 
Additional requirement for service providers only: Significant changes to organizational structure result in a documented (internal) review of the impact to PCI DSS scope and applicability of controls, with results communicated to executive management. 

Customized Approach Objective:
PCI DSS scope is confirmed after significant organizational change. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 
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:

Purpose:
An organization’s structure and management define the requirements and protocol for effective and secure operations. Changes to this structure could have negative effects to existing controls and frameworks by reallocating or removing resources that once supported PCI DSS controls or inheriting new responsibilities that may not have established controls in place. Therefore, it is important to revisit PCI DSS scope and controls when there are changes to an organization’s structure and management to ensure controls are in place and active. 

Examples:
Changes to organizational structure include, but are not limited to, company mergers or acquisitions, and significant changes or reassignments of personnel with responsibility for security controls. 

12.4.2
Defined Approach Requirements: 
Additional requirement for service providers only: Reviews are performed at least once every three months to confirm that personnel are performing their tasks in accordance with all security policies and operational procedures. Reviews are performed by personnel other than those responsible for performing the given task and include, but are not limited to, the following tasks:

Customized Approach Objective:
The operational effectiveness of critical PCI DSS controls is verified periodically by manual inspection of records. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 

Defined Approach Testing Procedures:

Purpose:
Regularly confirming that security policies and procedures are being followed provides assurance that the expected controls are active and working as intended. This requirement is distinct from other requirements that specify a task to be performed. The objective of these reviews is not to reperform other PCI DSS requirements, but to confirm that security activities are being performed on an ongoing basis. 

Good Practice:
These reviews can also be used to verify that appropriate evidence is being maintained—for example, audit logs, vulnerability scan reports, reviews of network security control rulesets—to assist in the entity’s preparation for its next PCI DSS assessment. 

Examples:
Looking at Requirement 1.2.7 as one example, Requirement 12.4.2 is met by confirming, at least once every three months, that reviews of configurations of network security controls have occurred at the required frequency. On the other hand, Requirement 1.2.7 is met by reviewing those configurations as specified in the requirement. 

12.5.2.1
Defined Approach Requirements: 
Additional requirement for service providers only: PCI DSS scope is documented and confirmed by the entity at least once every six months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes all the elements specified in Requirement 12.5.2. 

Customized Approach Objective:
The accuracy of PCI DSS scope is verified to be continuously accurate by comprehensive analysis and appropriate technical measures. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 
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:

Purpose:
Service providers typically have access to greater volumes of cardholder data than do merchants, or can provide an entry point that can be exploited to then compromise multiple other entities. Service providers also typically have larger and more complex networks that are subject to more frequent change. The probability of overlooked changes to scope in complex and dynamic networks is greater in service providers’ environments.
Validating PCI DSS scope more frequently is likely to discover such overlooked changes before they can be exploited by an attacker. 

10.7.1
Defined Approach Requirements: 
Additional requirement for service providers only: 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:

Customized Approach Objective:
Failures in critical security control systems are promptly identified and addressed. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 
This requirement will be superseded by Requirement 10.7.2 as of 31 March 2025. 

Defined Approach Testing Procedures:

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. Typical failures include a system ceasing to perform its security function or not functioning in its intended manner, such as a firewall erasing all its rules or going offline. 

12.8.1
Defined Approach Requirements: 
A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided. 

Customized Approach Objective:
Records are maintained of TPSPs and the services provided. 

Applicability Notes:
The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity’s responsibility for its own PCI DSS compliance. 

Defined Approach Testing Procedures:

Purpose:
Maintaining a list of all TPSPs identifies where potential risk extends outside the organization and defines the organization’s extended attack surface. 

Examples:
Different types of TPSPs include those that: 

12.4.2.1
Defined Approach Requirements: 
Additional requirement for service providers only: Reviews conducted in accordance with Requirement 12.4.2 are documented to include:

Customized Approach Objective:
Findings from operational effectiveness reviews are evaluated by management; appropriate remediation activities are implemented. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 

Defined Approach Testing Procedures:

Purpose:
The intent of these independent checks is to confirm whether security activities are being performed on an ongoing basis. These reviews can also be used to verify that appropriate evidence is being maintained—for example, audit logs, vulnerability scan reports, reviews of network security control rulesets—to assist in the entity’s preparation for its next PCI DSS assessment. 

12.4.1
Defined Approach Requirements: 
Additional requirement for service providers only:  Responsibility is established by executive management for the protection of cardholder data and a PCI DSS compliance program to include: 

Customized Approach Objective:
Executives are responsible and accountable for security of cardholder data. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 
Executive management may include C-level positions, board of directors, or equivalent. The specific titles will depend on the particular organizational structure. 
Responsibility for the PCI DSS compliance program may be assigned to individual roles and/or to business units within the organization. 

Defined Approach Testing Procedures:

Purpose:
Executive management assignment of PCI DSS compliance responsibilities ensures executivelevel visibility into the PCI DSS compliance program and allows for the opportunity to ask appropriate questions to determine the effectiveness of the program and influence strategic priorities. 

8.3.10.1
Defined Approach Requirements: 
Additional requirement for service providers only: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either:

OR

Customized Approach Objective:
Passwords/passphrases for service providers’ customers cannot be used indefinitely. 

Applicability Notes:
This requirement applies only when the entity being assessed is a service provider. 
This requirement does not apply to accounts of consumer users accessing their own payment card information. 
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. 
Until this requirement is effective on 31 March 2025, service providers may meet either Requirement 8.3.10 or 8.3.10.1. 

Defined Approach Testing Procedures:

Purpose:
Using a password/passphrase as the only authentication factor provides a single point of failure if compromised. Therefore, in these implementations, controls are needed to minimize how long malicious activity could occur via a compromised password/passphrase. 

Good Practice:
Passwords/passphrases that are valid for a long time without a change provide malicious individuals with more time to break the password/phrase. Periodically changing passwords offers less time for a malicious individual to crack a password/passphrase and less time to use a compromised password. 
Dynamically analyzing an account’s security posture is another option that allows for more rapid detection and response to address potentially compromised credentials. Such analysis takes a number of data points which may include device integrity, location, access times, and the resources accessed to determine in real time whether an account can be granted access to a requested resource. In this way, access can be denied and accounts blocked if it is suspected that account credentials have been compromised. 

Further Information:
For information about using dynamic analysis to manage user access to resources, refer to NIST SP 800-207 Zero Trust Architecture. 

A.15.1.1 Политика информационной безопасности во взаимоотношениях с поставщиками 
Мера обеспечения информационной безопасности: Требования информационной безопасности, направленные на снижение рисков, связанных с доступом поставщиков к активам организации, должны быть согласованы с поставщиком и документированы 

12.8.4
Определенные Требования к Подходу:
Внедрена программа для мониторинга статуса соответствия TPSP PCI DSS не реже одного раза в 12 месяцев.

Цель Индивидуального подхода:
Статус соответствия TPSP стандарту PCI DSS периодически проверяется.

Примечания по применению:
Если у организации есть соглашение с TPSP о выполнении требований PCI DSS от имени организации (например, через службу брандмауэра), организация должна работать с TPSP, чтобы убедиться, что применимые требования PCI DSS соблюдены. Если TPSP не соответствует этим применимым требованиям PCI DSS, то эти требования также “не действуют” для организации.

Определенные Процедуры Тестирования Подхода:

Цель:
Знание статуса соответствия PCI DSS всех задействованных TPPS обеспечивает уверенность и осведомленность о том, соответствуют ли они требованиям, применимым к услугам, которые они предлагают организации.

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

Дополнительная информация:
Для получения дополнительной информации о сторонних поставщиках услуг обратитесь к:

8.3.10.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Если пароли / парольные фразы используются в качестве единственного фактора аутентификации для доступа пользователя клиента (т.е. в любой реализации однофакторной аутентификации), то либо:

ИЛИ

Цель Индивидуального подхода:
Пароли/парольные фразы для клиентов поставщиков услуг не могут использоваться бесконечно.

Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование не распространяется на учетные записи пользователей-потребителей, получающих доступ к информации о своих собственных платежных картах.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.
До тех пор, пока это требование не вступит в силу 31 марта 2025 года, поставщики услуг могут выполнять либо требование 8.3.10, либо 8.3.10.1.

Определенные Процедуры Тестирования Подхода:

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

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

Дополнительная информация:
Для получения информации об использовании динамического анализа для управления доступом пользователей к ресурсам обратитесь к NIST SP 800-207 Архитектура нулевого доверия.

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

Цель Индивидуального подхода:
Точность области применения PCI DSS проверяется на постоянную точность с помощью всестороннего анализа и соответствующих технических мер.

Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

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

12.4.2.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Проверки, проведенные в соответствии с требованием 12.4.2, документируются, чтобы включать:

Цель Индивидуального подхода:
Результаты проверок операционной эффективности оцениваются руководством; осуществляются соответствующие мероприятия по исправлению положения.

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

Определенные Процедуры Тестирования Подхода:

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

12.8.5
Определенные Требования к Подходу:
Сохраняется информация о том, какие требования PCI DSS выполняются каждым TPSP, которые управляются организацией, и о любых требованиях, которые совместно используются между TPSP и организацией.

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

Определенные Процедуры Тестирования Подхода:

Цель:
Важно, чтобы организация понимала, какие требования и подзаконные требования PCI DSS согласились выполнять ее TPSP, какие требования являются общими для TPSP и организации, а для тех, которые являются общими, конкретные сведения о том, как распределяются требования и какая организация отвечает за выполнение каждого подзаконного требования.
Без этого общего понимания неизбежно, что организация и TPSP будут считать, что данное дополнительное требование PCI DSS является обязанностью другой стороны, и, следовательно, это дополнительное требование может вообще не выполняться.
Конкретная информация, которую хранит организация, будет зависеть от конкретного соглашения с ее поставщиками, типа услуги и т.д. TPSP могут определять свои обязанности по PCI DSS как одинаковые для всех своих клиентов; в противном случае эта ответственность должна быть согласована как организацией, так и TPSP.

Надлежащая практика:
Организации могут документировать эти обязанности с помощью матрицы, которая идентифицирует все применимые требования PCI DSS и указывает для каждого требования, несет ли организация или TPSP ответственность за выполнение этого требования или это общая ответственность. Этот тип документа часто называют матрицей ответственности.
Для организаций также важно понимать, имеют ли какие-либо TPSP “вложенные” отношения с другими TPSP, что означает, что первичный TPSP заключает контракты с другим TPSP(ами) в целях предоставления услуги. Важно понимать, полагается ли первичный TPSP на вторичный TPSP(ы) для достижения общего соответствия сервиса, и как первичный TPSP отслеживает производительность сервиса и статус соответствия PCI DSS вторичного TPSP(ов). Обратите внимание, что ответственность за управление и мониторинг любых вторичных TPSP лежит на первичном TPSP.

Дополнительная информация:
Образец шаблона матрицы ответственности приведен в Информационном дополнении: Обеспечение безопасности третьей стороной.

12.5.3
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Значительные изменения в организационной структуре приводят к документированному (внутреннему) анализу влияния на сферу применения и применимость средств контроля PCI DSS, результаты которого доводятся до сведения исполнительного руководства.

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

Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Это требование является наилучшей практикой до 31 марта 2025 года, после чего оно станет обязательным и должно быть полностью рассмотрено во время оценки PCI DSS.

Определенные Процедуры Тестирования Подхода:

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

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

8.3.10
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Если пароли/парольные фразы используются в качестве единственного фактора аутентификации для доступа пользователя клиента к данным держателя карты (т.е. в любой реализации однофакторной аутентификации), то пользователям клиентов предоставляются рекомендации, в том числе:

Цель Индивидуального подхода:
Пароли/парольные фразы для клиентов поставщиков услуг не могут использоваться бесконечно.

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

Определенные Процедуры Тестирования Подхода:

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

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

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

Цель Индивидуального подхода:
Ведется учет TPPS и предоставляемых услуг.

Примечания по применению:
Использование TPSP, совместимого с PCI DSS, не делает организацию совместимой с PCI DSS и не снимает с организации ответственности за ее собственное соответствие требованиям PCI DSS.

Определенные Процедуры Тестирования Подхода:

Цель:
Ведение списка всех TPSP определяет, где потенциальный риск распространяется за пределы организации, и определяет расширенную зону атаки организации.

Примеры:
Различные типы TPSP включают те, которые:

10.7.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Сбои в критически важных системах контроля безопасности обнаруживаются, предупреждаются и оперативно устраняются, включая, но не ограничиваясь, сбои в следующих критически важных системах контроля безопасности:

Цель Индивидуального подхода:
Сбои в критически важных системах контроля безопасности оперативно выявляются и устраняются.

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

Определенные Процедуры Тестирования Подхода:

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

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

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

Цель Индивидуального подхода:
Оперативная эффективность критических средств контроля PCI DSS периодически проверяется путем ручной проверки записей.

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

Определенные Процедуры Тестирования Подхода:

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

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

Примеры:
Рассматривая требование 1.2.7 в качестве одного из примеров, Требование 12.4.2 выполняется путем подтверждения, по крайней мере, один раз в три месяца, что проверки конфигураций средств управления сетевой безопасностью проводились с требуемой периодичностью. С другой стороны, требование 1.2.7 выполняется путем проверки этих конфигураций, как указано в требовании.

12.4.1
Определенные Требования к Подходу:
Дополнительное требование только для поставщиков услуг: Ответственность за защиту данных о держателях карт устанавливается исполнительным руководством, а программа соответствия требованиям PCI DSS включает:

Цель Индивидуального подхода:
Руководители несут ответственность и подотчетны за безопасность данных о держателях карт.

Примечания по применению:
Это требование применяется только в том случае, если оцениваемый субъект является поставщиком услуг.
Исполнительное руководство может включать должности уровня С, совет директоров или аналогичные должности. Конкретные названия будут зависеть от конкретной организационной структуры.
Ответственность за программу соответствия требованиям PCI DSS может быть возложена на отдельные роли и/или на бизнес-подразделения внутри организации.

Определенные Процедуры Тестирования Подхода:

Цель:
Распределение обязанностей по соблюдению требований PCI DSS между исполнительным руководством обеспечивает видимость программы соблюдения требований PCI DSS на уровне руководства и дает возможность задавать соответствующие вопросы для определения эффективности программы и влияния на стратегические приоритеты.

10.1. Заключение с поставщиком услуг соглашения (контракта, пакета договорных документов) об аутсорсинге является одним из основных элементов управления и контроля в отношении риска нарушения ИБ при аутсорсинге существенных функций. 

9.6. При оценке возможности поставщика услуг обеспечить выполнение обязательств организации БС РФ следует рассмотреть следующие показатели:

11.4. В случае возникновения риска нарушения ИБ, связанного с аутсорсингом существенных функций, превышающего принятый приемлемый риск (риск-аппетит), организации БС РФ следует совершить оперативные корректирующие действия, направленные на обработку указанного риска:

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

9.2. Основными целями оценки поставщика услуг являются:

6.6. Основное требование 5. Организации БС РФ следует привлекать поставщиков услуг для аутсорсинга существенных функций только после принятия поставщиком услуг всех необходимых мер по обеспечению ИБ и заключения соглашения, определяющего детальные условия и разграничение ответственности по обеспечению ИБ.

Детализация условий по обеспечению ИБ в соглашении должна обеспечивать возможность проведения оперативных мероприятий по мониторингу и контролю со стороны организации БС РФ деятельности поставщика услуг в части обеспечения ИБ.

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

При заключении соглашения с поставщиками услуг на осуществление аутсорсинга существенных функций организации БС РФ следует обеспечить наличие следующих условий по обеспечению ИБ:

А.5.19 Информационная безопасность в отношениях с поставщиками
В целях управления рисками ИБ, связанными с использованием поставляемыми продуктами или услугами, должны быть определены и внедрены соответствующие процессы и процедуры.

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

А.5.19 Information security in supplier relationships
Processes and procedures shall be defined and implemented to manage the information security risks associated with the use of supplier’s products or services.