This is the last in our series on the Path to PCI compliance. First, if you've made it this far...thank you! If you haven't read the previous blogs you can start with the first one here. Taken altogether, sometimes it's hard to see the forest for the trees and the path to PCI compliance becomes overgrown and overwhelming. Let’s review just exactly what steps you need to take in order to successfully navigate PCI compliance with NISC card payment solutions. At the risk of oversimplifying, here is a quick breakdown of steps. First, we discussed that PCI-DSS is the shorthand for Payment Card Industry Data Security Standard, which is a set of standard security practices put in place to ensure that the acceptance of credit card payments, along with the processing, storage and transmission of credit card data, is done in a secure manner. Second, we discussed the 12 PCI requirements that help you control the size and scope of your cardholder data environment or CDE. Third, we discussed the Self-Assessment Questionnaire, or SAQ. The SAQ is a questionnaire for you to fill out based on your own assessment of how well you are abiding by the 12 PCI-DSS requirements. Your answers to the SAQ become your Attestation of Compliance, or AOC. Finally, keep on keeping on. Do not submit your SAQ and think you are finished for the next 365 days. So many of the requirements have what the PCI Security Standards Council has called "Business as usual" and sometimes require daily attention. PCI compliance is complicated, if only because many of the requirements necessitate a change in how we do business, not to mention the certain skill required to understand many of the [...]
Welcome to installment number four on the path to PCI compliance. Previously, we reviewed the 12 PCI requirements, discussed the SAQ and AOC and how different card payment solutions effect which SAQ you should follow. By way of a reminder, SAQ is Self-Assessment Questionnaire and AOC is Attestation of Compliance which are one in the same form. Today we’ll explain how you can submit your SAQ and AOC to your card processor. The SAQ and AOC must be submitted on an annual basis. The due date will coincide with the month you originally submitted your first SAQ. Of course, many of the requirements have much shorter time-intervals which require you to continually track and manage the controls that are in place. There are several ways to submit your SAQ and AOC. For NISC Members, the SAQ and AOC is submitted through First Data, who provides three main methods of submission. You may recall how we compared the PCI-DSS process to the April 15 Federal tax submission - same thing here. You can "e-file" using First Data's free Clover Security Portal, which is by far the simplest and most efficient. You can also download, print and email or snail-mail the SAQ and AOC documents. Or, you can hire a Qualified Security Auditor (QSA), just like you would hire a tax advisor, who can submit it for you, or at least help you fill out the necessary paperwork to "e-file" or manually submit it to First Data. Each approach has its benefits. With level 3 and level 4 merchants – every NISC Member falls into one of those two levels - all that is required is the SAQ and AOC. Hiring a QSA to assist in the [...]
This is the third part in a series on the path to PCI compliance. Previously, we covered scope and the 12 PCI-DSS requirements. In this part, we will discuss the Self-Assessment Questionnaire, or SAQ, and Attestation of Compliance. We’ll also review how to understand which version of the SAQ you need to fill out. The SAQ is a questionnaire for you to fill out based on your own assessment of how well you are abiding by the 12 PCI-DSS requirements. Your answers to the SAQ become your Attestation of Compliance, or AOC. The aim of the PCI-DSS SAQ and AOC (wow - lots of acronyms there) is to secure card data. In the case of a data breach, or a suspected data breach, in which you are allegedly the source of the breach, you will need to prove - with certainty - that you not only kept to the PCI-DSS requirements, but that you also had no lapses in control. Let’s start by explaining what you can't do when answering questions in the SAQ. You cannot answer 'no' to any question and pass. That is not possible*. For the most part, and generally with very few exceptions, for you to be in compliance you will answer 'yes' or 'n/a.' And with every 'n/a' you must have an acceptable explanation of non-applicability. The acquirer - First Data for NISC Members - decides what is acceptable and what is not. Also, they are the judge and jury for which SAQ you should fill out. There are several different SAQs, and exactly how the card data is captured and processed determines which SAQ you need to fill out. The SAQs vary from the SAQ A with 22-responses to [...]
The Path to PCI Compliance – The PCI Requirements Welcome back to the Path to PCI Compliance. In part one of this series we outlined the very high-level path for attaining and maintaining PCI compliance. With that in mind, let's take a quick run through exactly what the Payment Card Industry Data Security Standards (PCI-DSS) expect of you in order to be compliant. Scope. This is a word that gets included in nearly every conversation about PCI. If not, it should. What is Scope? Here is the official definition: The PCI DSS security requirements apply to all system components included in or connected to the cardholder data environment. The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or transmit cardholder data or sensitive authentication data. “System components” include network devices, servers, computing devices, and applications. The PCI-DSS gets pretty technical, so let’s define this a bit further. One of the keys to this definition is "cardholder data environment" or CDE. The CDE is where a credit card number can be found. If it is stored on a server (Think scanned Vault images. Think tape and disc backups. Think call recordings), that server is in scope. If it travels unencrypted across a network segment, that network segment is in scope – including the fireware that controls network access. If a keyboard is used to key in a card number, that keyboard and computer are in scope. All of these in-scope components need to be protected. We protect said in-scope components by way of network segmentation, encryption and restricting access. One early objective of the PCI-DSS is to narrow the scope of the CDE as much as reasonably [...]
Hello and welcome to the first in a five-part series of blog posts on the topic of PCI-DSS. PCI-DSS is the shorthand for Payment Card Industry Data Security Standard, which is a set of standard security practices put in place to ensure that the acceptance of credit card payments, along with the processing, storage and transmission of credit card data, is done in a secure manner. This series of blogs is meant to help provide some insight on PCI and to help you navigate the path to PCI compliance.