Understanding PCI DSS Requirement 6.4.6

How do significant changes affect PCI DSS? PCI DSS 6.4.6. is a requirement for organizations to use to ensure that appropriate controls have been reviewed and implemented.
PCI DSS Requirement 6.4.6 requires that upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.

Understandably, A-LIGN clients often ask for guidance and clarification regarding this requirement, typically relating to the following three areas:

  1. How do we define what constitutes a significant change?
  2. Which controls do we validate in association with the significant change?
  3. How do we track this process and what documentation is required?

The following will help organizations properly address these questions and put appropriate controls in place to address this requirement.

How Do We Determine What Constitutes a Significant Change?

A significant change is any change or introduction of new controls within the environment that would introduce a significant risk of control failures. This would include:

  • Modifications to the existing network or network infrastructure (new network equipment, new network segments, etc.)
  • Adding new servers or technologies within the CDE or that connect to the CDE
  • Adding new software or performing “major” updates to software deployed within the CDE

The PCI Council has created an information supplement called Best Practices for Maintaining PCI DSS Compliance (January 2019). The objective of the document is to provide guidance on best practices for maintaining ongoing compliance with PCI DSS. The focus is to provide organizations with recommendations to plan for continuous compliance as opposed to a point-in-time, annual assessment approach. It also provides guidance for questions including what constitutes a significant change.

Best Practices for Maintaining PCI DSS Compliance, Section 3.10.3 outlines how to handle changes in the operational environment, which relates to Requirement 6.4.6:

Any change to the network architecture or infrastructures directly related to or supporting the CDE should be reviewed prior to implementation. Examples of such changes include, but are not limited to, the deployment of new systems or applications, changes in the system or network configurations, and changes in overall system topologies. Reviews of such changes related to the CDE are already required by PCI DSS Requirement 6.4. However, changes to the system, network, or security architectures and configurations—even those that seem unrelated to the CDE—may also have a downstream impact. Organizations should therefore thoroughly evaluate how any changes to the operating environments might impact the scope or status of the organization’s PCI DSS compliance (see Appendix C: Applicability of PCI DSS Requirements to Assets Type for additional information).

Prior to any modification to the environment, all the systems and networks affected by the change—including any new systems—should be identified. One question that should be asked  is, “do the changes introduce new connections between systems in the CDE and other systems that could bring additional systems or networks into scope for PCI DSS?” Consideration should also be given to how the proposed change may affect the technologies or underlying infrastructure that supports the security of the CDE. Examples of changes that may have such an impact include those made to network-traffic routing rules, firewall rules, DNS configurations, or other security-related functions.

After the impacted system components and networks have been identified, all applicable PCI DSS requirements for those systems and networks must be evaluated. For example, any new system added to the CDE would need to be configured in accordance with defined system configuration standards ⎯ including password-complexity settings, access-control configurations, etc.⎯ included in the updated network and dataflow diagrams and added to the system inventory. The new system would also need to be included in quarterly vulnerability scanning schedules and integrated into other security and monitoring processes such as centralized logging, file integrity monitoring, antivirus, etc.

This is the council’s answer to this question. Organizations that do their best to follow these guidelines should experience favorable audit results.

Which Controls Need Validation in Association with a Significant Change?

Another challenge we see regarding PCI DSS Requirement 6.4.6 is that once clients put a process in place to define a “significant change,” the organization is then challenged with clarifying what the next steps are. This becomes even more challenging in larger organizations that have countless different systems types and complex infrastructures. Unfortunately, there is no clear, one-size-fits-all template.

Every type of device, application, or technology will have different applicable controls, dependent upon how that system affects the security of cardholder data. To ensure that the intent of this requirement is met, it requires personnel with thorough knowledge and experience with the PCI DSS to be part of the change review process – for example, through a change review board.  If the review board consists of appropriate members (including technology, security and compliance knowledge), it can become a resource that can be leveraged to help determine what critical controls are relevant to a specific change taking place.

As an example, network equipment might include review items such as:

  • Verifying firmware is updated and patched
  • Verifying logs are written to a centralized log server
  • Verifying administration protocols utilized are restricted and secure
  • Verifying password policies are enforced
  • Verifying rule sets have been properly justified and approved

For a major software change, review items may include:

  • Verifying dependent software components are supported and properly patched
  • Verifying cardholder data is being encrypted and stored appropriately (if applicable)
  • Verifying application logs are reviewed and are confirmed to archive properly
  • Verifying the software change does not affect required controls on the system (e.g., A/V, FIM)

Again, the type of system or control that is being changed will directly affect which PCI DSS is applicable and should be verified as part of 6.4.6.

  • New systems are included in the quarterly vulnerability scanning process

Read more: Outline of Guidance for PCI DSS Scoping and Network Segmentation

How Do We Track This Process and What Documentation Is Required?

The third challenge will be determining how to track that the required verification actually occurred. Ultimately you will want to make sure your actions are auditable. Some organizations will incorporate some type of required documentation within the change control record itself, some will create implementation notes that might be attached or referenced in records and others may just have paper forms that are signed off. In the end, there must be some form of evidence that can be used to verify that the task was properly completed.


In conclusion, we recommend that organizations:

  • Follow the PCI SSC’s suggestions for significant changes (see Section 3.10.3 of “Best Practices for Maintaining PCI DSS Compliance”)
  • Include personnel with experience and knowledge with PCI DSS as part of the change review process related to changes associated with the CDE
  • Document that a review was performed within the change control records to verify that all applicable PCI DSS requirements were implemented as part of the change.

It is important to remember that just because an item is determined to be out-of-scope for PCI DSS, this does not mean it is impossible to compromise. It is important for organizations to pay attention to where information is considered both in and out-of-scope to continue to prevent data breaches by taking a holistic approach to information security. This guidance should provide additional clarification to help organizations address these challenges.

Read more: How A-LIGN Helped Cloudreach Become PCI DSS Compliant


Does your organization need assistance in determining how to segment your network for the purpose of PCI DSS scoping? A-LIGN’s Qualified Security Assessors (QSA) are available now to assist you with any of your PCI DSS needs. Contact us today at [email protected] or 888-702-5446.