Scoping is not a new topic for PCI DSS, and it could arguably be one of the most debated topics that we face. Several years ago the Council formed a Special Interest Group (SIG) to try and address this, but the results were mixed. You can find something called the Open PCI Scoping Toolkit that can provide some additional guidance, but the danger here is that it is not sanctioned by the Council, therefore it is not official documentation to be used to determine the scope of an assessment.

In the next version of our PCI Compliance book, due out later this year, we spent some more time on scoping. The results are still virtually the same, however. Removing things from scope is challenging and subjective, as are the risk tolerance definitions for both assessors and assessees. Finding a middle ground can be challenging, and all bets are off if a breach occurs.

Laughter, by Jimmy_Joe

Laughter, by Jimmy_Joe

Perhaps the biggest problem we have is the QA process when combined with a lack of direction from the Council. We’ ve talked about risk ratings and other ways to allow for judgement calls to be made based on raw numbers, but it’s still subjective. There are no objective definitions here. So imagine for a moment that you are a Level 1 retailer and you get the new guy showing up to your place to do the assessment. How do you handle bringing the new guy up to speed on the last decade of decisions that got you to where you are today?

Anyone who has participated in a project at some point in their life knows about “Scope Creep.” This is the concept that Parties A and B get together and agree to a set of tasks for a certain delivery schedule and price, but then both sides sometimes start to push that number after agreement. A simple example might be asking someone who is painting your wall to throw a little bit of paint on a door that was not included in the original work, or asking someone to test these four other IPs that were not in the original 100 for testing. With PCI DSS environments, we have the exact same problem.

Scope creep in these environments comes from the years of negotiating scoping with assessors, and then building upon wins or losses. As a merchant, you may “win” by getting a pesky system out of scope, and then scope creep occurs when you generalize the factors that allowed that system to be removed from scope across your environment to selectively remove more hosts from scope. You use the justification of the previous “win” to push further reductions which sometimes are done without a firm foundational argument. It’s a game, yo!

The lesson here is two fold. If you are a QSA, ensure that what you agree to keeps you in check with your obligations to the Council. If you are a Merchant, you can push as hard as you want; all breach responsibility falls upon you anyway. When that breach happens, don’t scream at your QSA if you let scope creep get you into that situation.

This post originally appeared on BrandenWilliams.com.

Possibly Related Posts:


0