The Payment Card Industry, or PCI, is the entity that sets the standards of compliance for credit card security. In 2004, directly in response to card transaction fraud, PCI was formed and the first revision of the Data Security Standard was released.
To maintain compliance with PCI, any organization who stores, processes, or transmits cardholder information must adhere to the relevant portions of the DSS that apply to their environment. PCI has broken these different subsets of the DSS into standalone documents called Self-Assessment Questionnaires, or SAQs. These SAQs vary depending on the environment.
A term you will frequently see and hear in regards to PCI compliance is SCOPE. For instance, you may hear that components are either “in scope” or “out of scope”. You may also hear the terms “increase your scope” or “reduce your scope”. So: what does any of this mean, and why should you care?
What Does “In Scope” Mean?
PCI hosts a library of information on their website. Along with the DSS and other related standards are other useful documents, such as PCI’s Glossary of Terms.
While “in-scope” is not a glossary term directly, PCI provides a definition for “scoping”:
The process of identifying all system components, people, and processes to be included in a PCI DSS assessment. The first step of a PCI DSS assessment is to accurately determine the scope of the review.
In easy-to-understand terms: scope is defined as “all system components, people, and processes to be included in a PCI DSS assessment”. These are the components that you’ll need to include in your annual security audit to meet your compliance requirements.
Defining Your PCI Scope
Like the definition of scoping states – the first step in any PCI assessment is to establish your scope. This is a critical, and sometimes ever-evolving, first step.
Ultimately:
Authoritative determinations about anything PCI related must be made by a PCI Qualified Security Assessor. PCI maintains a list of PCI-validated QSAs. So, final determination can only be validated with authority by a QSA.
With that said, there are a few “knowns” one can consider:
- PCI considers any entity who stores, process, or transmits card data to be in scope.
- Additionally, any system component, person, or process that can impact cardholder data or the security of cardholder data is considered in scope.
Your scope also depends on the type of organization you are. Each entity must be assessed individually for its role in PCI compliance; PCI offers several documents against which these entities could be audited, depending on that role. Service Providers, for example, are audited against the entire Data Security Standard. Merchants have several Self-Assessment Questionnaires (SAQs A – D) categorizing the various infrastructure configurations to cover the potential methods merchants use to accept cardholder data. The idea is for merchants to complete any combination of the reduced SAQs (A – C) or to complete one SAQ D.
Once your scope has been established, you can select the data security standard(s) you will need to meet to uphold compliance. Some standards are more arduous than others, requiring more time and resources to complete. However, you can take certain steps to reduce your scope (by removing systems, people and processes) in order to qualify for a reduced audit, which will directly save you time and money.
Reducing your scope also helps you maintain a smaller attack surface when it comes to your customer’s card data! Fewer potential vulnerabilities means greater security for your customers’ information. If you are responsible for your organization’s PCI compliance, then your initial question should be “How can I reduce our scope as much as possible?” That is exactly what Curbstone’s technologies offer.
In Scope vs. Out of Scope
Bullet point #2 above is where you start to enter a gray area. For example, if a system is in scope, then its entire network segment is in scope. Any system that would be LOCAL to this scoped system and could communicate with it would be considered in scope. The router would be in scope. Any switches on that segment would be in scope. Although these systems may not directly store, process, or transmit cardholder data, they all have the potential to impact the security of the cardholder data. Therefore, they are considered “in scope” and must be audited.
In contrast, components that are considered “out of scope” do not need to be included in your formal audit or reporting efforts.
PCI Scope Reduction
Since scope relies on so many variables, it should be considered fluid. You can make a change and increase it. In that same vein, you can make a change and reduce it, too! If you remove a system’s (or person’s or process’s) ability to affect or interact with cardholder data within your environment, then that item may qualify to be removed from your scope.
E-Commerce Environments
Scope removal can be accomplished in many ways. With e-commerce, if your web server is hosting the payment collection page that is presented to your customer, then your web server is in scope and auditable. However, if you can process payments through your webserver without your webserver collecting the cardholder data, then your web server is not in scope for PCI. Many merchants accomplish this by outsourcing their e-commerce payments to a PCI-validated third-party payment provider. PCI allows merchants who do this to qualify for the reduced SAQ A.
MOTO Environments
With mail-order/phone order (MOTO) environments, PCI defines the reduced SAQ C/VT as applicable to “merchants that process account data only via third-party virtual payment terminal solutions on an isolated computing device connected to the Internet.” Network segmentation, coupled with a third-party solution provider, can remove most of the computing infrastructure. There are also solutions to remove the audible speaking of the cardholder data to operators for MOTO (mail order and telephone order) environments. Without this, most MOTO environments qualify for SAQ D, by default.
For retail and POS systems, PCI created the MOST-REDUCED SAQ, the SAQ P2PE. This is the shortest of all SAQs. However, to qualify for the P2PE, you must purchase and deploy a P2P-validated terminal solution.
There are other solutions and methods for reducing scope. Tokenization removes direct handling of card data in many instances. Again, without qualification for any combination of the reduced SAQs, the default standard to which you would be audited is the SAQ D.
It is worth saying that when it comes to meeting your security requirements, completing a SAQ-D is just as compliant as completing a SAQ-A or SAQ C/VT. This is where I encourage you to consider the business impacts BEYOND compliance. With these reduced SAQs comes cost savings, time savings, and increased security.
How Curbstone Can Help You Reduce Your PCI Scope
At Curbstone, this is our bread and butter. We aren’t just professionals in the payment space with decades of experience – all of our technologies were developed to help you reduce your compliance obligations as much as possible – without sacrificing the security of your environment.
Choosing Curbstone as your payment solution means choosing a partner in payment security. To help you save money and streamline your operations, we can help you qualify for a reduced SAQ. That means fewer compliance costs and more time to allocate to other projects.
Take a real-life look at how we were able to help Bartlett Bearing Company avoid the SAQ-D, or find out which parts of your environment we can remove from your PCI compliance requirements. To learn more about reducing your own PCI scope, contact us today.