12.5: 1. An inventory of system components that are in scope for PCI DSS, including a description of function/use, is maintained and kept current.
  • Examine the inventory to verify it includes all in-scope system components and a description of function/use for each.
  • Interview personnel to verify the inventory is kept current.

Description

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 inventory- management tool.

12.5: 2. 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: (a) Identifying all data flows for the various payment stages (for example, authorization, capture settlement, chargebacks, and refunds) and acceptance channels (for example, card- present, card-not-present, and e-commerce), (b) Updating all data-flow diagrams per Requirement 1.2.4, (c) Identifying all locations where account data is stored, processed, and transmitted, including but not limited to: 1) any locations outside of the currently defined CDE, 2) applications that process CHD, 3) transmissions between systems and networks, and 4) file backups, (d) Identifying all system components in the CDE, connected to the CDE, or that could impact security of the CDE, (e) Identifying all segmentation controls in use and the environment(s) from which the CDE is segmented, including justification for environments being out of scope, (f) Identifying all connections from third-party entities with access to the CDE, (g) Confirming that all identified data flows, account data, system components, segmentation controls, and connections from third parties with access to the CDE are included in scope.
  • Examine documented results of scope reviews and interview personnel to verify that the reviews are performed:
  • • At least once every 12 months.
  • • After significant changes to the in-scope environment.
  • Examine documented results of scope reviews performed by the entity to verify that PCI DSS scoping confirmation activity includes all elements specified in this requirement.

Description

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:

• Data stores (databases, files, cloud, etc.), including the purpose of data storage and the retention period,

• Which CHD elements are stored (PAN, expiry date, cardholder name, and/or any elements of SAD prior to completion of authorization),

• How data is secured (type of encryption and strength, hashing algorithm and strength, truncation, tokenization),

• How access to data stores is logged, including a description of logging mechanism(s) in use (enterprise solution, application level, operating system level, etc.).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: 2.1. 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.
  • Additional testing procedure for service provider assessments only: Examine documented results of scope reviews and interview personnel to verify that reviews per Requirement 12.5.2 are performed:
  • • At least once every six months, and
  • • After significant changes
  • Additional testing procedure for service provider assessments only: Examine documented results of scope reviews to verify that scoping validation includes all elements specified in Requirement 12.5.2.

Description

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.

12.5: 3. 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.
  • Additional testing procedure for service provider assessments only: Examine policies and procedures to verify that processes are defined such that a significant change to organizational structure results in documented review of the impact to PCI DSS scope and applicability of controls.
  • Additional testing procedure for service provider assessments only: Examine documentation (for example, meeting minutes) and interview responsible personnel to verify that significant changes to organizational structure resulted in documented reviews that included all elements specified in this requirement, with results communicated to executive management.

Description

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.