To discover your PCI scope and what must be included for yourPCI compliance, you need to identify anything that processes, stores, or transmits cardholder data, and then evaluate what people and systems are communicating with your systems.
*This article was taken from our PCI Guide. For more information on this topic, download our free PCI Guide.
To discover your PCI scope and what must be included for your PCI compliance, you need to identify anything that processes, stores, or transmits cardholder data, and then evaluate what people and systems are communicating with your systems. In May 2017, the PCI Council released an informational supplement regarding PCI scoping. The document helps reinforce and clarify scoping points that have always been part of PCI scoping. The document can help you work through your annual scoping exercise and can lead you to discover card flows and in-scope systems that you may have previously ignored.
In my experience performing PCI audits, entities often overlook the ancillary or support types of systems when doing their own PCI scoping. For instance, call centers usually pay little attention to QA systems, which often store cardholder data in the form of call recordings. These systems are in scope for all PCI requirements!
Do not panic if you find data where it does not belong.
Simple questions can help you begin the scoping process. For example, ask yourself:
There are always processes you might not realize are in scope. For example, if you are a retail store that swipes cards, do you ever take card numbers over the phone or receive emails with card information? Are any paper orders received? Organizations often have finance, treasury, or risk groups that have post-transaction processes involving cardholder data. It is important to include these processes when determining scope.
Don’t forget power outage procedures where card data is sometimes taken down manually. For example, in most call centers, we’ve discovered that agents are typically unaware that card data should never be written down. But when the application they use for recording cardholder data freezes, they tend to resort to typing or writing it down in a temporary location and retrieving it later for entry. These temporary locations are rarely considered in an organization’s PCI compliance efforts but can lead to increased risk and should be included in your PCI scope.
Paper trails of hand-written information or photocopied payment card data can sometimes fill multiple rooms. Even if card data is ten years old, it is still in PCI scope.
If you access a web page for data entry, there’s a decent chance card data can be found in temporary browser cache files. In addition, it’s the website developer’s responsibility to make sure websites don’t generate cookies or temporary log files with sensitive data. However, you don’t always have full control of your website, which is why it’s important to evaluate all systems for cardholder data, even where you might not expect it to reside.
For organizations with web portals, if someone mistypes card data into an address or phone number field, it is still considered in PCI scope.
You might think your databases are set up to encrypt all cardholder data. However, servers you consider out of scope will often hold temporary files, log files, or backups with lots of unencrypted data. System administrator folders on file servers are also common culprits, as they often backup failing servers in a rush to prevent dataloss without considering the PCI implications.
Usually, organizations can find ways to fix processes and delete this sensitive data, rather than add servers to their scope. A simple way to find unencrypted card data is by running a card discovery tool, such as SecurityMetrics PANscan®. Organizations need to have methods to detect these mistakes and prevent or delete them. Some use a dataloss prevention (DLP) solution to help them with this process.
The next step in determining your PCI scope is to find everything that can communicate with the devices you have identified. This is often the hardest part about scoping because you may not understand what can communicate to your systems. Answer the following questions:
If you have a server that handles cardholder data, you must always consider what else communicates with that server. Do you have a database server in some other zone you consider out of scope but is reaching that web server to pull reports and save data? Anything that can initiate a connection to an in-scope server that handles cardholder data will be in scope for compliance.
In addition, if your system in the CDE initiates a communication out to a server in another zone, that server will also be in scope. There are very few exceptions to this.
.svg)
