You’re running around with your hair on fire because your QSA just informed your CISO that 3,000 call center agents that typed in customer credit card data were in scope because they’re processing payments.
Wait. What?
That’s right. I found out the hard way that not everyone defined the word “process” the same way. Security architects and management couldn’t wrap their heads around the call center agents and their devices as being in scope for PCI DSS Compliance. Oy.
Mistake #1: You Don’t Understand the Definition of Scope
Let’s recap the definition as written by the PCI Security Council:
The PCI DSS security requirements apply to all system components included in or connect to the cardholder data environment (CDE). The CDE is comprised of people, processes, and technologies that store, process, and / or transmit cardholder data (CHD) or sensitive authentication data (SAD).
PCI SSC
Furthermore, the PCI Security Council has a supplemental document that provides guidance on scope and network segmentation. For example, the Security Council makes it crystal clear that if you’ve got something in your CDE, regardless of its function, it’s in scope for PCI DSS assessment. No ifs, ands, or buts.
Mistake #2: You Overlook People and Processes
PCI DSS isn’t just about the technology, the servers, or the firewalls.
- Colin in Collections and Terry in Treasury are in scope because they process payments or they have access to payment account numbers that are either stored on premises or with your acquirer.
- Fran in Fraud is in scope because she maintains (stores) a list of customers with their payment account numbers while some investigation (process) is going on.
- Bart in Billing is in scope because he can access stored payment account numbers.
- And all your call center agents taking credit card numbers over the phone and typing them into their unencrypted keyboards are in scope because they’re processing the transaction.
- And those keyboards and laptops are in scope, too.
- And the process to accept payments over the phone is in scope, too.
- Which brings your VoIP telephone system in scope but we won’t go there. That’s a tale for another day.
Mistake #3: You Don’t Know Where The Data Resides
- Your cardholder data flows aren’t documented.
- You don’t know all the cardholder data flows.
- Cardholder data is being stored in voice recordings.
- Cardholder data is being stored in a delete file that hasn’t been deleted in 20 years.
- Cardholder data is being stored in places where it’s not supposed to be left unsupervised.
Mistake #4: Lack of Accountability and Ownership for Cardholder Data
It’s a bad episode of “Who’s On First.” Nobody knows who really owns the data and nobody knows who’s accountable for the protection of the data.
Even worse – cardholder data is appropriately classified with specific data protection and retention standards but nobody follows them.
Mistake #5: You Forgot Your Third Party Vendors
Third party vendors who either store, process, or transmit cardholder data on your behalf are in scope (see Requirement 12.8.x)
And third party vendors who connect to your CDE for any reason are in scope.
- Your third party vendors need to be vetted appropriately.
- You need to monitor their PCI DSS compliance.
- If your third party vendor does not have their QSA assessing them, then you need to bring them into the scope of your assessment (which is a lot harder and you may receive push back from your vendor.)
It’s Time to Get Your Scope In Order
Before you even start your next Report on Compliance or your next Self-Assessment, get your scope as accurate as humanely possible.
Order and download the PCA Report on Compliance Planner – this will guide you through your next scope assessment as well as your Report on Compliance.
And be sure to sign up for our weekly email/newsletter!
