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

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

ID.AM-1:  В организации инвентаризированы системы и физическое оборудование 

ID.AM-4: Каталогизированы внешние информационные системы  

ID.AM-3: В организации отображены коммуникации и потоки данных  

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

ID.AM-2:  В организации инвентаризированы программные платформы и приложения 

12.5.1
Defined Approach Requirements: 
An inventory of system components that are in scope for PCI DSS, including a description of function/use, is maintained and kept current. 

Customized Approach Objective:
All system components in scope for PCI DSS are identified and known. 

Defined Approach Testing Procedures:

Purpose:
Maintaining a current list of all system components will enable an organization to define the scope of its environment and implement PCI DSS requirements accurately and efficiently. Without an inventory, some system components could be overlooked and be inadvertently excluded from the organization’s configuration standards 
Good Practice:
If an entity keeps an inventory of all assets, those system components in scope for PCI DSS should be clearly identifiable among the other assets. 
Inventories should include containers or images that may be instantiated. 
Assigning an owner to the inventory helps to ensure the inventory stays current. 

Examples:
Methods to maintain an inventory include as a database, as a series of files, or in an inventorymanagement tool. 

12.5.2
Defined Approach Requirements: 
PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon significant change to the in-scope environment. At a minimum, the scoping validation includes:

Customized Approach Objective:
 PCI DSS scope is verified periodically, and after significant changes, by comprehensive analysis and appropriate technical measures. 
Applicability Notes:
 This annual confirmation of PCI DSS scope is an activity expected to be performed by the entity under assessment, and is not the same, nor is it intended to be replaced by, the scoping confirmation performed by the entity’s assessor during the annual assessment. 
Defined Approach Testing Procedures:

Purpose:
Frequent validation of PCI DSS scope helps to ensure PCI DSS scope remains up to date and aligned with changing business objectives, and therefore that security controls are protecting all appropriate system components. 

Good Practice:
Accurate scoping involves critically evaluating the CDE and all connected system components to determine the necessary coverage for PCI DSS requirements. Scoping activities, including careful analysis and ongoing monitoring, help to ensure that in-scope systems are appropriately secured. When documenting account data locations, the entity can consider creating a table or spreadsheet that includes the following information:

In addition to internal systems and networks, all connections from third-party entities—for example, business partners, entities providing remote support services, and other service providers—need to be identified to determine inclusion for PCI DSS scope. Once the in-scope connections have been identified, the applicable PCI DSS controls can be implemented to reduce the risk of a third-party connection being used to compromise an entity’s CDE. 
A data discovery tool or methodology can be used to facilitate identifying all sources and locations of PAN, and to look for PAN that resides on systems and networks outside the currently defined CDE or in unexpected places within the defined CDE— for example, in an error log or memory dump file. This approach can help ensure that previously unknown locations of PAN are detected and that the PAN is either eliminated or properly secured 

Further Information:
For additional guidance, refer to Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation. 

12.5.1
Определенные Требования к Подходу:
Ведется и поддерживается в актуальном состоянии перечень системных компонентов, подпадающих под действие стандарта PCI DSS, включая описание функций/использования.

Цель Индивидуального подхода:
Все системные компоненты, подпадающие под действие стандарта PCI DSS, идентифицированы и известны.

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

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

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

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

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

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

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

Надлежащая практика:
Точное определение области включает в себя критическую оценку CDE и всех подключенных компонентов системы для определения необходимого покрытия требований PCI DSS. Мероприятия по определению области охвата, включая тщательный анализ и постоянный мониторинг, помогают обеспечить надлежащую защиту систем в области охвата. При документировании местоположений данных учетной записи организация может рассмотреть возможность создания таблицы или электронной таблицы, включающей следующую информацию:
Хранилища данных (базы данных, файлы, облако и т.д.), Включая цель хранения данных и срок хранения,
Какие элементы CHD сохраняются (PAN, дата истечения срока действия, имя владельца карты и/или любые элементы SAD до завершения авторизации),
Как защищаются данные (тип шифрования и надежность, алгоритм хеширования и надежность, усечение, токенизация),
Как регистрируется доступ к хранилищам данных, включая описание используемого механизма (механизмов) ведения журнала (корпоративное решение, уровень приложения, уровень операционной системы и т.д.).
В дополнение к внутренним системам и сетям, все подключения от сторонних организаций - например, деловых партнеров, организаций, предоставляющих услуги удаленной поддержки, и других поставщиков услуг — должны быть идентифицированы для определения включения в сферу действия PCI DSS. Как только соединения в рамках области будут идентифицированы, могут быть реализованы соответствующие средства контроля PCI DSS, чтобы снизить риск использования стороннего подключения для компрометации CDE организации.
Инструмент или методология обнаружения данных могут быть использованы для облегчения идентификации всех источников и местоположений PAN, а также для поиска PAN, который находится в системах и сетях за пределами текущего определенного CDE или в неожиданных местах в пределах определенного CDE — например, в журнале ошибок или файле дампа памяти. Этот подход может помочь гарантировать, что ранее неизвестные местоположения PAN будут обнаружены и что PAN будет либо удален, либо должным образом закреплен

Дополнительная информация:
Дополнительные рекомендации см. в Информационном дополнении: Руководство по определению области действия PCI DSS и сегментации сети.