Which of your systems are in PCI scope?

What PCI scope covers

Scope is the list of everything PCI DSS reaches in your business. The Council's Quick Reference Guide puts it in layers. First the cardholder data environment (CDE): “System components, people, and processes that store, process, and transmit cardholder data and/or sensitive authentication data,” plus components that handle none of it but “have unrestricted connectivity” to those that do. Then, on top of the CDE, “System components, people, and processes that could impact the security of the cardholder data and/or sensitive authentication data.”

The Council's scoping supplement sorts every component into categories, checked from the top: “if a system meets any criteria in CDE Systems, it is a CDE system regardless of whether it also meets a description for a lower category,” and to be out of scope “a system must meet ALL the criteria of the out-of-scope category and NONE of the criteria of a higher category.” The checker runs exactly that order. Open each category for the Council's criteria:

Being in scope does not switch on every requirement. The supplement: “being in scope does not mean that all PCI DSS requirements apply to a given system component.” If you qualify for a self-assessment questionnaire, the requirements that apply are the ones in your SAQ; the SAQ type finder tells you which one, and the PCI compliance checklist lists its tasks.

How to use the scope checker

1. 01List every device, person and place a card payment passes through, from the moment a customer hands over a card or reads out a number to the moment the record is shredded or deleted. Use the chips for the usual suspects and add your own lines.
2. 02For each, answer the questions. “Freely” means nothing sits between it and a card system: the same router, the same Wi-Fi, no firewall rule in the way.
3. 03Read the category. Anything in the CDE or connected to it is in scope; “Not settled” stays on the in-scope list until you know.
4. 04Copy or print the result, keep it with your network and data-flow diagrams, and check it again after any change to how you take cards.

The list is the same exercise the standard asks of you each year: Requirement 12.5.2 has you identify “all system components in the CDE, connected to the CDE, or that could impact security of the CDE.” The checker does not see your network, so it is only as good as your answers. Ask whoever set up your router or POS when an answer is a guess.

Worked example: a café

The checker opens on a café that takes cards at the counter, takes catering orders by phone and sells online through a website that redirects to its processor's payment page. It comes out at 5 of 7 items in scope:

The back-office PC is the surprise. It never sees a card, but it sits on the same router as the terminal with nothing between them, and the supplement is blunt about that: “In a flat network, all systems are in scope if any single system stores, processes, or transmits account data.” A firewall that stops the PC reaching the terminal can move it out, which is what a PCI compliant firewall is for. The terminal itself shrinks most with a validated P2PE solution (what P2PE is), and the order pad disappears if staff key the number straight into the terminal instead of writing it down.

Phone lines, call recordings and paper

Phone orders put people in scope as well as wires. The Council's telephone supplement: “Accepting spoken account data over the telephone puts personnel, the technology used, and the infrastructure to which that technology is connected into scope of PCI DSS.”

• A traditional landline. You are generally “not considered responsible for the transmission of card data over an external traditional telephone line,” because the risk of interception on those lines “is considered low.” §2.3.1
• VoIP. Where VoIP carries card data between a customer and you, “the entity's systems and networks used for those transmissions are in scope.” §2.3.1
• Writing it down. If someone notes the number, or an answering machine captures it, that “would be considered ‘storage,’” and the process is in scope. §2.3.1
• Recordings. A recording of a spoken card number “must be correctly stored and secured in accordance with PCI DSS requirements,” and security codes must not survive in it after authorization. §5.2.6

Ways to take the card off the call altogether, from payment links to keypad masking, are compared in PCI compliant phone payments. Paper and files that hold card numbers are covered in how to store credit card information.