For all the talk about PCI DSS, the technical side only covers systems that handle cardholder data. So if you limit those systems, you can shrink the portion of your network that has to meet the many technical requirements.
Think of it this way: pretend PCI DSS compliance is a highbar. How you handle cardholder data will determine whether you have to throw a small, light portion of your network over the bar or the whole hulking mass of it.
Obviously, getting part of your network over the bar is easier than hefting over the whole thing. That’s why you want to limit the systems that handle cardholder data – it limits your exposure to PCI DSS.
Shrinking the portion of your network that has to comply can cut your risk, cut your costs, and make compliance easier. But how do you do it?
The PCI DSS council has specific, approved scenarios you can use to limit access to cardholder data on a network. If you can configure your transaction process to fit one of these scenarios, then congratulations, only part of your network has to clear the bar.
However, if you can’t fit one of the scenarios, then you have to throw your entire network over – and that’s easier said than done.
The “scenarios” are really the criteria for the PCI DSS Self-Assessment Questionnaires, specifically SAQs A through C.
The SAQs are put out by the PCI Security Standards council. They are designed to help merchants know if they comply. Every merchant has to complete one to achieve full compliance.
Here are descriptions for SAQs A through C (use the links below to download the full SAQs to get all the details):
This questionnaire is for merchants who accept card-not-present transactions and who completely outsource payment acceptance and processing. The merchant must have no direct control over how cardholder data is captured, processed, transmitted, or stored and must outsource these functions entirely to third parties. Only paper records can be retained and no cardholder data can be stored electronically.
This questionnaire is for merchants who use an imprint machine or a standalone dial-out terminal. The terminal cannot be connected to another system or the internet. It must be connected via phone line to the processor. No cardholder data can be sent on the internet or transmitted over the internal network. Cardholder data cannot be stored electronically and only paper records can be retained.
This questionnaire is for merchants who use a web-based virtual terminal hosted by a third-party. The merchant’s computer that handles the transactions must be isolated and cannot be connected to another system in the network. Except for a transaction, no other cardholder data can be transmitted and it can never be stored electronically. Only paper records can be retained.
This questionnaire is for merchants who have a single-store location with a single point-of-sale or a payment system connected to the internet. The POS or payment system must be on the same device or LAN as the internet but it cannot connect to any other systems. The building that holds the POS environment cannot be connected to any other premises, and if a LAN is set up it must be for a single location only. Only paper records can be retained and no cardholder data can be stored.
If you cannot configure your transaction process to fit one of the above scenarios, then you’re stuck with SAQ-D. Think of it as a training manual to throw your whole network over the highbar.
As an IT service provider, if you’re helping a client get compliant, you should strive to qualify for one of the other SAQs. Having to use SAQ-D means more work for you and more exposure for your client.
For smaller merchants (those who accept fewer than 1 million card transactions each year), your merchant acquirer should walk you through the steps to achieve full compliance.
That process will undoubtedly require you to complete an SAQ. It will also likely require you to complete the following:
Some merchants have a long road to compliance, but by controlling how you handle cardholder data, you can make that road a little easier and a little shorter.
Simple and Powerful Security for PCI DSS
PCI DSS for IT Providers: 4 steps for compliance with clients
How AccessEnforcer Fits with PCI DSS
Slide Presentation - PCI DSS for IT Providers: The rules and impact on MSPs and VARs