One of the most frequent questions we get is what the term “Significant Change” means for PCI. In this article we try to demystify this term a little and help you understand the various ways that the term is used in PCI DSS.

What is Significant Change?

The PCI SSC says that a significant change varies depending on your environment and your organisation (What is a “significant change” for PCI DSS Requirements 11.2 and 11.3?).

They help by providing some examples of things that are considered as the minimums for significant change, which are:

  • Changes affecting access to cardholder data
  • Changes affecting the security of the cardholder data environment

And examples of the above may include, but are not limited to:

  • Network upgrades
  • Additions or updates to firewalls or routing devices
  • Upgrades to servers

Even with these examples of significant changes, the key thing to keep in mind is that you and your organisation need to have a clear definition of what constitutes a significant change so that changes can be identified and analysed to determine if they meet the criteria for a significant change. If you don’t have a documented common understanding of what represents a significant change in your environment, there may be a significant risk that someone else in your organisation doesn’t identify a change as significant and some of the PCI requirements that apply could be missed.

What Does This Actually Mean?

What this actually means for your environment is not as straight forward. There are five key requirements in the PCI Report on Compliance (RoC) and Self-Assessment Questionnaires (SAQs) that relate to significant changes, one part of the AoC that relates to significant changes, and two additional requirements in the Supplemental Report on Compliance / Designated Entities Supplemental Validation (S-RoC / DESV) that relate to significant changes.

  • Requirement 6.4.6: 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.
  • Requirement 11.2.3: Perform internal and external scans, and rescans as needed, after any significant change. Scans must be performed by qualified personnel.
  • Requirement 11.3.1: Perform external penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).
  • Requirement 11.3.2: Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment)
  • Requirement 12.2: Implement a risk-assessment process that:
    • Is performed at least annually and upon significant changes to the environment (for example, acquisition, merger, relocation, etc.)
    • Identifies critical assets, threats, and vulnerabilities, and
    • Results in a formal, documented analysis of risk.
  • Requirement A3.2.1 (DESV): Document and confirm the accuracy of PCI DSS scope at least quarterly and upon significant changes to the in-scope environment.
  • Requirement A3.2.5 (DESV): Implement a data-discovery methodology to confirm PCI DSS scope and to locate all sources and locations of clear-text PAN at least quarterly and upon significant changes to the cardholder data environment or processes.
  • Part 3a (AoC): If my environment changes, I recognise that I must reassess my environment and implement any additional PCI DSS requirements that apply.

What you will need to do to meet each of these requirements varies from performing an out of cycle vulnerability scan through to performing a full re-assessment of your environment.

Documenting Significant Changes

The starting point for understanding what it means for your environment though is Requirement 6.4.6 which focuses on ensuring that you have a process to identify significant changes and that your change management process includes documenting the supporting evidence for the steps you have taken in relation to a significant change.

The guidance in Requirement 6.4.6 states:

A change management process should include supporting evidence that PCI DSS requirements are implemented or preserved through the iterative process. Examples of PCI DSS requirements that could be impacted include, but are not limited to:

  • Network diagram is updated to reflect changes.
  • Systems are configured per configuration standards, with all default passwords changed and unnecessary services disabled.
  • Systems are protected with required controls – e.g. file integrity monitoring (FIM), antivirus, patching, audit logging.
  • Sensitive authentication data (SAD) is not stored and all cardholder data (CHD) storage is documented and incorporated into data-retention policies and procedures.
  • New systems are included in the quarterly vulnerability scanning processes.

These examples are not meant to be exhaustive, but should provide a starting point for how you can review your changes to first understand if they are significant and next to understand what additional steps you need to take for them.

We recommend storing all the associated evidence with the significant change to make it easier for your team to locate the evidence when requested by the QSA.

We also recommend considering how you can template certain types of significant changes so that everyone involved in the change understands what further steps need to be taken. But to do this, you need to understand what kinds of events will be considered significant changes for your organisation.

Common Challenges

The most common thing that we come across is that people do not want to consider a change as significant or do not have a clear definition of a significant change. The result is that staff don’t understand what PCI considers as a baseline significant change, and tasks may not be completed. For example:

  • Vulnerability scans may be missed or not occur as part of the change
  • Penetration testing may not be completed or may be booked significantly after the change has occurred.
  • PCI controls may not be applied and not discovered until the PCI assessment
  • Firewall rules for decommissioned servers may not be removed.
  • Documents may not be updated and network diagrams may be missing new systems or showing systems that were removed.
  • Change documentation may not show all the detail required for Requirement 6.4.6.

We’ve repeated it a lot in this article, but the best way to avoid these challenges is to remove the stigma of a significant change by:

  • breaking down what is required for types of significant changes, and
  • making sure that the definition of a significant change is clear to the staff who are working with these changes on a daily basis.

Make sure that key staff are involved in the discussion of what a significant change is so that you have something that works within your organisation and develop processes that minimise the challenge of identifying what steps to take if you have a significant change.

A change might be significant, but if you’ve set up your processes well, a significant change can become just another part of your business as usual (BAU) activities.

Thinking of Making a Change?

If you’re thinking of making a significant change to your environment, Confide can help review it and make sure that it won’t negatively affect your PCI DSS compliance. Contact us to find out more.