What is a Significant Change Within an Environment?

Across the globe, we’ve become accustomed to the routine of the FIFA World Cup. It occurs every four years, and the renowned football—or soccer, depending on where you’re from—tournament progresses the same way each time. Aside from the athletes chosen to play for their respective teams, really the only major thing that changes significantly about the World is the location where it’s held.

When a city or country is selected for the World Cup, it requires a substantial investment from that place, its governing body, and the people impacted—the place itself must undergo tons of abnormal yet necessary preparation.

Hosting a World Cup is a significant change to a location’s day-to-day that must be dealt with for the tournament to proceed smoothly. While your PCI DSS assessment occurs annually rather than every four years, similarly, you must address any significant changes to stay in compliance.

But what qualifies as a “significant change” to your cardholder environment? As PCI QSAs, we’re glad you asked, because, in this article, we’re going to clearly define the term. Using a couple of situational examples, we’re also going to detail the actions that must occur after a significant change, how to document your approach, and proactive measures to take.

Your scoped environment may be dynamic and things will change, but the following information will make all the difference during your next PCI DSS assessment.

Defining a Significant Change in PCI DSS  

Simply defining the term is easy. The PCI SSC, per FAQ 1317 and post caveat, defines a significant change as:

“Generally, changes affecting access to cardholder data or the security of the cardholder data environment (CDE) could be considered significant. Examples of a significant change may include network upgrades, additions or updates to firewalls or routing devices, upgrades to servers, etc.”

The PCI DSS v4 includes more specific examples:

• New hardware, software, or networking equipment added to the CDE.
• Any replacement or major upgrades of hardware and software in the CDE.
• Any changes in the flow or storage of account data.
• Any changes to the boundary of the CDE and/or to the scope of the PCI DSS assessment.
• Any changes to the underlying supporting infrastructure of the CDE (including, but not limited to, changes to directory services, time servers, logging, and monitoring).
• Any changes to third party vendors/service providers (or services provided) that support the CDE or meet PCI DSS requirements on behalf of the entity.

How Does NIST Define a “Significant Change?”                                                                   

Though we are focusing on PCI DSS in this article, we would be remiss if we didn’t mention that NIST also has something to say in this vein as well. It defines a significant change as, “…a change that is likely to substantively affect the security or privacy posture of a system.” (SP 800-37 Revision 2)

NIST’s provided examples include:

• Installation of a new or upgraded operating system, middleware component, or application
• Modifications to system ports, protocols, or services
• Installation of a new or upgraded hardware platform
• Modifications to how information, including PII, is processed
• Modifications to cryptographic modules or services
• Changes in information types processed, stored, or transmitted by the system
• Modifications to security and privacy controls.

How to Determine What is a Significant Change?

These definitions help a bit, but when it comes to PCI DSS at least, it also probably introduces some questions:

• What’s a “major upgrade” to CDE software? What conditions were software changes made under that result in increments its major version?
• Do updated logging configurations based upon new hardening requirements require another penetration test? What would that test look like?
• If we “hot swap” a time server with another of the same model and operating system and apply the same configuration package, does this apply?

The good news is that PCI DSS v4.0 includes guidance regarding “applicable PCI DSS requirements” that you should consider. Despite any lingering questions, this should help to allay concerns around necessary sweeping follow-up actions, allowing you to confine penetration testing, internal scanning, and other reviews/tests based upon the actual change and its impact.

5 Common Significant Changes to CDEs

Every environment is different, and to understand what constitutes a significant change for you internally, you’ll need to consider how your environment interacts with cardholder data and what can impact the security or handling of that data.

That being said, we can take things a step further than that v4.0 guidance. What follows is a list of generalized examples of common significant changes and specific follow-up actions you should take in order to meet PCI DSS’s requirements. These should be considered strictly general guidance and not a binary delineator or one-size-fits all response.

Though they do not account for environmental specifics, these will help orient you in defining all the relevant updates within your organization and taking the appropriate action.

1. If you deploy additional, mirrored copies of web servers to manage increased traffic:
   • Specific queries and internal scans can confirm the efficacy of these changes.
   • A new penetration test is probably not required.
2. If you move network segments and member systems from an on-premise environment to a cloud provider:
   • This is a very likely significant change across the board, from the management of the new environment to the decommissioning/secure deletion of systems if you stored cardholder data within these systems.
   • As for follow-up actions, these are a good start:
     • Confirm configuration baselines.
     • Conduct internal and external scans on the new system.
     • Complete an internal and external penetration test on this hosted environment.
     • Document the decommissioning of the old environment – to include the secure deletion of cardholder data repositories. 

3. If you stand up a new public-facing web server in your CDE that provides non-sensitive reporting data to customers but does not interact with cardholder data, consider:
   • Conducting internal and external scans on the new system.
   • Confirming configuration baselines.
   • Completing a penetration test, specifically on that system.
4. If you deploy a new log aggregation server on an in-scope, non-CDE network—i.e., a network segment that does not store, process, or transmit cardholder data—to accommodate the volume of logs:
   • Conduct an internal scan of the new system.
   • Confirm configuration baselines.
   • However, it’s not required that you complete a new penetration test.
5. If you update servers in your CDE to the most current, major version (i.e., CentOS version 7 to version 8):
   • Conduct an internal scan on the new system.
   • Confirm configuration baselines.
   • A new penetration test is required.

If your environment does undergo these scenarios we’ve listed above, document the result of these actions. But remember, these are all common changes many organizations introduce—identifying and classifying the rest of yours will mean a realistic analysis of how your environment’s security can be impacted. We emphasize that the convenience of classification and follow-up action should not be your deciding factor in moving forward.

To help you get started, use previous changes made to your environment as examples and:

• Review the tracking procedures you used for those. Maybe there’s a flag in said change control process or ticketing system that can indicate if a review for a significant change is required. You might assign a related task to the related, properly trained project management teams.
• Written policies can also provide guidance around these types of issues and remove the ambiguity for staff identifying these change types. 

In the end, as long as your assessor can review your updates to correctly assign the significance of changes based upon some metric, then the subsequent actions should all fall into place. With the exception of a penetration test, most of the required tasks defined within the DSS can be applied in a business-as-usual fashion.

What Happens if You Do Not Take Appropriate Follow-Up Action to “Significant Changes?”

Of course, the big question then becomes “do you have to take any action after a significant change?” What would the actual impact to your next PCI DSS assessment be?

The short answer is you wouldn’t necessarily “fail” the assessment. However, under the new PCI DSS v4.0, your assessor will document that you didn’t follow requirements for the entire time within the Executive Summary of your report.

Again, that doesn’t mean you’d fall out of compliance, but you are expected to take and document the necessary actions. Of course, if you continue to delay on reconciling your significant changes with DSS requirements, that will indicate negligence and could result in your falling out of compliance with the standard.

Moving Forward with Your Next PCI DSS Assessment

Compliance with PCI DSS assessment may be a desired constant, but the reality is that your environment won’t be. As technology continues to advance and standards update, your organization will adjust and it will be up to you to deal with the changes—especially the significant ones—properly.

Now, you understand a little bit better what constitutes such a change and how to determine if you’ve implemented one, along with some basic actions to take.

For more information on payment card compliance and PCI DSS—including the latest version of the standard—check out our other content on the subject:

• Services Beyond PCI DSS
• How to Keep Your Legacy Systems Compliant Under PCI DSS v4.0
• Understanding the Updates to Risk Management in PCI DSS v4.0