Framework № PCI DSS 4.0 от 01.03.2022

6.5.1
Defined Approach Requirements: 
Changes to all system components in the production environment are made according to established procedures that include: 

Customized Approach Objective:
All changes are tracked, authorized, and evaluated for impact and security, and changes are managed to avoid unintended effects to the security of system components. 

Defined Approach Testing Procedures:

Purpose:
Change management procedures must be applied to all changes—including the addition, removal, or modification of any system component—in the production environment. It is important to document the reason for a change and the change description so that relevant parties understand and agree the change is needed. Likewise, documenting the impacts of the change allows all affected parties to plan appropriately for any processing changes. 

Good Practice:
Approval by authorized parties confirms that the change is legitimate and that the change is sanctioned by the organization. Changes should be approved by individuals with the appropriate authority and knowledge to understand the impact of the change. 
Thorough testing by the entity confirms that the security of the environment is not reduced by implementing a change and that all existing security controls either remain in place or are replaced with equal or stronger security controls after the change. The specific testing to be performed will vary according to the type of change and system component(s) affected.
For each change, it is important to have documented procedures that address any failures and provide instructions on how to return to a secure state in case the change fails or adversely affects the security of an application or system. These procedures will allow the application or system to be restored to its previous secure state. 

6.5.2
Defined Approach Requirements: 
Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable. 

Customized Approach Objective:
All system components are verified after a significant change to be compliant with the applicable PCI DSS requirements. 

Applicability Notes:
These significant changes should also be captured and reflected in the entity’s annual PCI DSS scope confirmation activity per Requirement 12.5.2. 

Defined Approach Testing Procedures:

Purpose:
Having processes to analyze significant changes helps ensure that all appropriate PCI DSS controls are applied to any systems or networks added or changed within the in-scope environment, and that PCI DSS requirements continue to be met to secure the environment. 

Good Practice:
Building this validation into change management processes helps ensure that device inventories and configuration standards are kept up to date and security controls are applied where needed. 

Examples:
Applicable PCI DSS requirements that could be impacted include, but are not limited to:

6.5.3
Defined Approach Requirements: 
Pre-production environments are separated from production environments and the separation is enforced with access controls. 

Customized Approach Objective:
Pre-production environments cannot introduce risks and vulnerabilities into production environments. 

Defined Approach Testing Procedures:

Purpose:
Purpose Due to the constantly changing state of preproduction environments, they are often less secure than the production environment. 

Good Practice:
Organizations must clearly understand which environments are test environments or development environments and how these environments interact on the level of networks and applications. 

Definitions:
Pre-production environments include development, testing, user acceptance testing (UAT), etc. Even where production infrastructure is used to facilitate testing or development, production environments still need to be separated (logically or physically) from preproduction functionality such that vulnerabilities introduced as a result of pre-production activities do not adversely affect production systems. 

6.5.4
Defined Approach Requirements: 
Roles and functions are separated between production and pre-production environments to provide accountability such that only reviewed and approved changes are deployed. 

Customized Approach Objective:
Job roles and accountability that differentiate between pre-production and production activities are defined and managed to minimize the risk of unauthorized, unintentional, or inappropriate actions. 

Applicability Notes:
In environments with limited personnel where individuals perform multiple roles or functions, this same goal can be achieved with additional procedural controls that provide accountability. For example, a developer may also be an administrator that uses an administrator-level account with elevated privileges in the development environment and, for their developer role, they use a separate account with user-level access to the production environment. 

Defined Approach Testing Procedures:

Purpose:
The goal of separating roles and functions between production and pre-production environments is to reduce the number of personnel with access to the production environment and account data and thereby minimize risk of unauthorized, unintentional, or inappropriate access to data and system components and help ensure that access is limited to those individuals with a business need for such access. 
The intent of this control is to separate critical activities to provide oversight and review to catch errors and minimize the chances of fraud or theft (since two people would need to collude in order to hide an activity). 
Separating roles and functions, also referred to as separation or segregation of duties, is a key internal control concept to protect an entity’s assets. 

6.5.5
Defined Approach Requirements: 
Live PANs are not used in pre-production environments, except where those environments are included in the CDE and protected in accordance with all applicable PCI DSS requirements. 

Customized Approach Objective:
Live PANs cannot be present in pre-production environments outside the CDE. 

Defined Approach Testing Procedures:

Purpose:
Use of live PANs outside of protected CDEs provides malicious individuals with the opportunity to gain unauthorized access to cardholder data. 

Good Practice:
Entities can minimize their storage of live PANs by only storing them in pre-production when strictly necessary for a specific and defined testing purpose and securely deleting that data after use. 
If an entity requires PANs specifically designed for test purposes, these can be obtained from acquirers. 

Definitions:
Live PANs refer to valid PANs (not test PANs) that have the potential to be used to conduct payment transactions. Additionally, when payment cards expire, the same PAN is often reused with a different expiry date. All PANs must be verified as being unable to conduct payment transactions before they are excluded from PCI DSS scope. It is the responsibility of the entity to confirm that PANs are not live. 

6.5.6
Defined Approach Requirements: 
Test data and test accounts are removed from system components before the system goes into production. 

Customized Approach Objective:
Test data and test accounts cannot exist in production environments. 

Defined Approach Testing Procedures:

Purpose:
This data may give away information about the functioning of an application or system and is an easy target for unauthorized individuals to exploit to gain access to systems. Possession of such information could facilitate compromise of the system and related account data.