Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


11:00 AM
Connect Directly

An SMB Guide To Credit Card Regulations, Part I: PCI DSS Q&A

This article is the first in a short series designed to help small businesses understand the regulations around securing credit card transactions, specifically the PCI DSS (Payment Card Industry's Data Security Standard) requirements.

This article is the first in a short series designed to help small businesses understand the regulations around securing credit card transactions, specifically the PCI DSS (Payment Card Industry's Data Security Standard) requirements.In an effort to provide the most tangible information, I've consulted with a Qualified Security Assessor (QSA). Portions of content and resources in this series have been contributed by trusted security colleague Martin McKeay, QSA and host of the Network Security Podcast.

Let's jump right in and start looking at some of the most intriguing questions surrounding the PCI DSS requirements as they apply to smaller businesses.

Q1: What exactly does PCI DSS cover and does it apply to me? There are many parts to the PCI DSS requirements. Simply put, you're required to meet certain standards to protect cardholder data. Most notably, the PCI DSS puts requirements on ANY merchant who is storing, processing or transmitting cardholder data. Storing covers not only digital, but also physical storage, an often overlooked situation. The PCI DSS also covers what parts of the cardholder data you can and cannot store, how it can be stored and what type of protection to apply to specific combinations of data. If you're processing, transmitting or storing (on paper or digitally) credit card, debit card or bank account numbers, then PCI DSS applies to you. This includes, but isn't limited to, any organizations that have recurring billing data on computers, credit card machines or readers and/or filed documents with credit card or bank numbers.

Q2: We don't process many credit cards--do we still have to meet PCI DSS requirements? Yes! Even if you don't process many credit cards (in number of transactions or in dollar amounts) you still fall under the PCI DSS requirements. Generally speaking, there are four tiers of merchants and the tiers are based on the number of transactions, not the sum of the money. If you're processing less than 20,000 transactions a year (that's an average of 55 a day), then you're a Level 4 Merchant. If you process more than 20,000 but less than a million a year, you're a Level 3 Merchant. There are also Levels 1 and 2 for larger transaction volumes. Your merchant level only dictates the type of accounting and reporting you're responsible for and doesn't make you less responsible for compliance.

Q3: How do I know if my business is compliant? You probably won't know for sure, but there are a variety of self-assessments available to get you thinking about the appropriate security. PCI DSS provides four Self-Assessment Questionnaires (SAQs) for use by lower level merchants. The SAQ you use will depend on your business model. Larger merchants are audited and reviewed by QSAs, like Martin. Smaller merchants are mostly on an honor system--now. The complication with self-assessments is that even though the questions included are less exhaustive than a QSA review, the smaller merchants are still responsible for meeting ALL the requirements. You can view more on the PCI DSS SAQs here.

Q4: What happens if we're not compliant? Several things could happen. Lever 3 and Level 4 merchants have different relationships with PCI DSS than their larger counterparts, but one component is the same. Your agreement is not directly with the credit card company, but instead is with the acquiring bank--the bank that processes transactions for you and manages your merchant account. To simplify the relationships, you and your acquiring bank have an agreement, and your acquiring bank has a responsibility to the credit card companies for PCI DSS. If you're not compliant but it hasn't resulted in a breach (yet) then one of several things may happen. How they handle the gap depends on your contract, the situation and your relationship with the bank. They might choose to absorb the fees from the credit card companies, they could pass the fees on to you, or they can even impose their own additional fines for noncompliance. Most often, being noncompliant will result in higher per-transaction fees for you, large monthly fees and possibly fines passed from the credit card company via the acquiring bank. On the other hand, if your noncompliance has resulted in a breach and cardholder data is lost or stolen, then you're going to have a mess on your hands. The breach laws and fine structures are enough to put most small companies out of business.

We'll be talking more about PCI DSS's specific requirements like wireless networks in subsequent parts of this series. PCI DSS is still a fairly new concept, relative to other regulations and data security laws. Because of its novelty, the bugs and logistics are still being ironed out but QSA professionals predict more interaction and responsibilities for Level 3 and 4 merchants down the road. The honor system will fade into a framework with more validation and QSA consulting. This series will serve as a springboard to help SMBs prepare for current and future PCI DSS regulations.

Jennifer Jabbusch is a CISO and infrastructure security specialist at Carolina Advanced Digital. By day she architects enterprise security solutions and by night, well, she does the same thing. For Dark Reading, she melds her enterprise experience and intimate knowledge of small business operations to deliver relevant security guidance for SMBs everywhere. Jennifer Minella is VP of Engineering and consulting CISO at Carolina Advanced Digital, and an author, speaker and consultant for infrastructure security for government, education and Fortune 100 and 500 corporations. View Full Bio

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
DevSecOps: The Answer to the Cloud Security Skills Gap
Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
Attackers' Costs Increasing as Businesses Focus on Security
Robert Lemos, Contributing Writer,  11/15/2019
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2019-11-20
A CWE-200: Information Exposure vulnerability exists in Modicon Controllers (M340 CPUs, M340 communication modules, Premium CPUs, Premium communication modules, Quantum CPUs, Quantum communication modules - see security notification for specific versions), which could cause the disclosure of FTP har...
PUBLISHED: 2019-11-20
A CWE-79: Failure to Preserve Web Page Structure vulnerability exists in Andover Continuum (models 9680, 5740 and 5720, bCX4040, bCX9640, 9900, 9940, 9924 and 9702) , which could enable a successful Cross-site Scripting (XSS attack) when using the products web server.
PUBLISHED: 2019-11-20
Cross-site Scripting (XSS) in Dolibarr ERP/CRM 3.3.1 allows remote attackers to inject arbitrary web script or HTML in functions.lib.php.
PUBLISHED: 2019-11-20
Dolibarr ERP/CRM 3.3.1 does not properly validate user input in viewimage.php and barcode.lib.php which allows remote attackers to execute arbitrary commands.
PUBLISHED: 2019-11-20
The snprintf implementation in PostgreSQL before 9.0.20, 9.1.x before 9.1.16, 9.2.x before 9.2.11, 9.3.x before 9.3.7, and 9.4.x before 9.4.2 does not properly handle system-call errors, which allows attackers to obtain sensitive information or have other unspecified impact via unknown vectors, as d...