In order to be PCI compliant, all acquirers, merchants and third parties using a card association’s payment system must not only abide by the PCI DSS requirements but also that association’s guidelines.  For example, any organization using Visa’s payment system (i.e. any organization which receives, processes or passes Visa branded cardholder information) must abide by Visa’s International Operating Guidelines.  Failure to comply can result in monetary fines and possible disqualification or merchant account termination.

Association compliance for merchants is based on levels of validation for each card association.  Visa, MasterCard, and Discover each have four levels of validation for merchants.  American Express has three levels and JCB has two levels.  Each level is based on annual transaction volume with Level 1 being the highest.  It is the responsibility of the merchant to check the criteria for each card brand it accepts and adhere to the validation requirements for the appropriate level in which it falls.

NOTE: MasterCard made some changes to their security program recently, whereby a merchant falls into a certain level based on its level with Visa.  So, if a merchant processes over 6 million Visa transactions (Level 1), but only 2 milllion with MasterCard (Level 2), it would be a Level 1 merchant with both associations.

Non-Compliant Activities

So, what type of activity can result in a fine or merchant termination?  Basically, two words – non-compliance.  Credit card compliance covers PCI DSS and card association guidelines.  Any activity violating those can result in fines, being put on MATCH or account termination.

Using Visa as an example again, per their operating guidelines, if Visa determines that a member, its agent, or a merchant has been deficient or negligent in securely maintaining the account or transaction information or reporting or investigating the loss of this information as specified in this section, Visa may fine the member, as specified in Section 1.6.D, or require the member to take immediate corrective action.  Visa members are financial institutions who issue and maintain account information (i.e. acquirers).

“Repetitive violations can incur heavier fines, possible listing on MATCH or account termination.”

Visa’s operating guidelines define the reason for terminating a merchant account (aka, Revocation of Privileges):

Visa may permanently prohibit a Merchant, IPSP, or any other entity, or one of its principals, from participating in the Visa or Visa Electron Program for any reasons it deems appropriate, such as:

• Fraudulent activity
• Presenting Transaction Receipts that do not result from an act between the Cardholder and the Merchant (laundering)
• Activity that causes the Acquirer to repeatedly violate the Visa International Operating Regulations
• Activity that has resulted in a Regional Office prohibiting the Merchant from participating in the Visa or Visa Electron Program
• Any other activity that may result in undue economic hardship or damage to the goodwill of the Visa system

Similarly, MasterCard’s rules state that failure by a Merchant or Acquirer or both to comply with any Standard may result in chargebacks, an assessment to the Acquirer, and/or other disciplinary action.

Repetitive violations can incur heavier fines, possible listing on MATCH or account termination.  Associations will also continue to levy fines if the merchant does not correct the action deemed as non-compliant.  Any fines from the card associations related to merchant activities will be passed down to the merchants.  If a merchant does not take correction action or neglects to pay the acquirer, the merchant account is at threat of being terminated and listed on MATCH.

Be Careful Using Third-Party Service Providers

Using third party vendors can certainly streamline your business operations and credit card sales.  However, they can also hurt your business if they are not compliant with industry guidelines.  Aside from any possible data breach, simply using a non-compliant vendor can result in fines from the associations as well.  Third party service providers include payment gateway, web hosting, or backup storage services.

There are many reasons to use a PCI compliant vendor – aside from following PCI compliance guidelines, using a compliant vendor helps to protect your customer records, which should be the number one priority.

According to PCI guidelines, merchants are required to verify service provider compliance.  The PCI DSS requirement 12.8 (outlined below) requires a merchant to “manage” any service providers:

12.8.1 Maintain a list of service providers.

12.8.2 Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess.

12.8.3 Ensure there is an established process for engaging service providers including proper due diligence prior to engagement.

12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status.

To assist with compliance on this level, the PCI SSC adopted the Payment Application Data Security Standard (PA-DSS), formerly managed by Visa as the Payment Application Best Practices (PABP), for software vendors or other companies who develop secure payment applications.  A list of validated payment applications is available on the PCI SSC web site.  Each payment application on the list is valid for one year, so application vendors and developers need to go through similar annual reviews and due diligence as required by the PCI DSS for organizations.

Additionally, card companies have put requirements into place regarding service provider compliance.  Visa, for example, stipulates that issuers and acquirers must use, and are responsible for ensuring that their merchants use, service providers that are compliant with the PCI Data Security Standard (DSS). Although there may not be a direct contractual relationship between merchant service providers and acquirers, Visa issuers and acquirers are responsible for any liability that may occur as a result of non-compliance.

Service providers must register with Visa in order to be included on their list of PCI DSS-compliant service providers.  Visa defines two levels (based on volume) of compliance for service providers.  Visa defines service providers as TPAs (Third Party Agents), which are entities that provide payment-related services, directly or indirectly, to a Visa client and / or stores, processes or transmits Visa account numbers. TPAs include Independent Sales Organizations (ISOs), Third Party Servicers (TPSs), Encryption and Support Organizations (ESOs) and Merchant Servicers (MSs).  TPAs must be registered in Visa’s Agent Registration Program, mandated by Visa to “ensure that Visa clients are in compliance with Visa Inc. Operating Regulations (“Visa rules”) and policies regarding their use of TPAs.”  Only Visa clients (i.e. acquirers) can register TPAs and are thus responsible and liable for their TPAs.  POS software providers that provide the payment application only and do not store, process and / or transmit Visa account numbers also need to adhere to the PA-DSS.  Fines from Visa include $10,000 for using an unregistered TPA.

Under its SDP program, MasterCard also requires third party service providers to follow compliance guidelines.  It defines service providers as a collective term for Third Party Processors (TPPs) and Data Storage Entities (DSEs).  It also defines two service provider levels for compliance.

PCI compliance for service providers includes onsite assessments, self-assessment questionnaires, and network security scanning.  Summed up by MasterCard, the compliance process for its service providers is a 3 step process:

1. Review the relevant PCI documentation, validation tools and procedures
2. Engage an approved vendor, as appropriate, and follow the validation procedures
3. Once compliant, work with a qualified security assessor to send a Certificate of Validation to MasterCard

In all cases with service provider compliance, PCI SSC Qualified Security Assessors and Approved Scanning Vendors must be used.  For a merchant to ensure complete compliance across the board, it is necessary for its service provider(s) to be on all relevant compliance lists.

View Visa’s current list (as of March 6) of PCI DSS Validated Service Providers here.

View MasterCard’s list of compliant service providers here.

Using a third-party vendor or company in the processing of credit cards does not exclude a merchant from PCI compliance responsibility.  The merchant is still responsible for data security and abiding by PCI compliance rules and the operating guidelines of the card brands.  Issuers and acquirers are also responsible for any liability that may occur as a result of non-compliance.

How Merchants Can Avoid Fines and Account Termination

Before account termination or being put on MATCH, a merchant may be warned and fined for non-compliance for risky activities, such as excessive chargeback ratios or not following PCI DSS.  That is a warning which should not be taken lightly by any merchant.  Corrections for any non-compliance should be fixed immediately.  If a data breach has occurred, it is the merchant’s responsibility to report it as soon as it is discovered.

Using a third-party vendor or company in the processing of credit cards does not exclude a merchant from PCI compliance responsibility.  The merchant is still responsible for data security and abiding by PCI compliance rules and the operating guidelines of the card brands.  Merchants are responsible for reading and understanding the card association guidelines in their entirety for each card type they accept.  Merchants should also use a payment processor who explains compliance and helps avoid fines by keeping an eye on chargeback ratios and understanding their third-party vendors.  Of all the parties (with the exception of the customer) involved the payment transaction process, the merchant is the one who loses out the most if data security is compromised or the merchant account is terminated.  Merchants can prioritize compliance by assigning a security officer – or other responsible party – to ensure that all necessary compliance requirements are being met.  This includes making sure service providers are consistently compliant as well.

Reference documents

Card association operating guidelines

MasterCard

Visa

American Express

Guidelines for Discover and JCB are not available online.  Merchants can obtain them from the card associations directly.

Card association requirements for merchant compliance

Visa Cardholder Information Security Program for Merchants

MasterCard Merchant Requirements

Discover Information & Security Compliance

American Express

JCB Data Security Program

The Importance of PCI Compliance

According to Privacy Rights Clearinghouse.org, more than 346 million records with sensitive information have been breached since January 2005.  According to the Ponemon Institute’s annual study, the cost of a data breach was $204 per compromised customer record for 2009.  The data, obtained from 45 companies that publicly acknowledged – and were willing to discuss – a breach of sensitive customer information.  The study also revealed that the average total cost of a data breach was $6.75 million in 2009.

Most laws involving credit card fraud and data security breaches target the criminals who conduct the breaches and obtain the card data.  Although, state attorney offices have investigated and filed suits against companies who were found to be non-compliant during a data breach.  In an effort to stay ahead of the curve, the only way the card associations are able to enforce the security standards is to penalize those who do not comply and/or jeopardize data protection.

The Payment Card Industry Data Security Standard (PCI DSS) applies to any organization or merchant that accepts, transmits or stores any cardholder data.  The PCI DSS was created in 2004 by the PCI Security Standards Council (SSC), which include the major card brands – otherwise known as associations – American Express, Discover, JCB, MasterCard, and Visa.  Each card association stipulates that the PCI DSS, in addition to the individual association guidelines, must be followed in order to be fully compliant.  Achieving PCI compliance means that you have met the technical requirements of the PCI DSS.

Consequences of Non-Compliance

Non-compliance can result in fines or other actions by the card associations.  Even though the PCI SSC managed the PCI DSS, any fines levied for non-compliance are done so by the card associations, not by the security council.  The card associations usually fine the acquirer under which the non-compliant merchant processes transactions.  The acquirer then passes the fine onto the merchant, ISO or third-party.  However, a merchant can be fined or terminated directly by the card association.

“T.J. Maxx agreed to pay as much as $40.9 million in a settlement with Visa.”

The amount of the fines and fees are dependent upon the type of activity.  A breach of data would cost a merchant a lot more than if they were discovered to be non-compliant with no data breach.  For example, in the largest data breach thus far, T.J. Maxx (TJX) agreed in November, 2007, to pay as much as $40.9 million in a settlement with Visa and the bank that processes the company’s credit card payments, as a result of a massive data breach, discovered in 2006, of TJX’s customer records.  (TJX admitted to 45.7 million compromised records, but court filings by the banks suing TJX estimate that about 100 million cards were affected.)  The settlement funds were reported to be used to help the U.S. credit card issuers (i.e. banks) recover costs related to the breach.  Last year, they agreed to pay $9.75 million to settle investigations by 41 state attorney generals.  That settlement was the sixth one that TJX announced regarding the breach.  Visa originally fined Fifth Third, TJX’s acquiring bank, close to $900,000 for non-compliance.  $500,000 was assessed “due to the seriousness of this security incident and the impact on the Visa system,” according to a Boston Globe report. $380,000 was assessed for “TJX’s failure to cease storing prohibited data.”

Visa announced, following the TJX breach, that it began fining level one merchants (6M + transactions annually) $25,000 per month if they fail to comply with the PCI DSS.  Although this information is relative to the largest data breach in U.S. history, merchants of every level should take these actions very seriously to avoid risking loss of data, not to mention customer confidence.

How Does Account Termination Affect A Merchant?

So, your processor terminated your account.  You may ask, “What’s the big deal?  I will just get a new merchant account elsewhere.”  Well, it’s not as easy as it sounds.  A merchant who has been terminated is put on MATCH, more or less known as a blacklist in the credit card processing industry.  Formerly known as the TMF (Terminated Match File), the MATCH (Member Alert to Control High-Risk) list is a file of merchants who have been terminated for “cause”.  Reasons include activities such as fraud or excessive chargebacks.  (See a previous blog on this subject here.)  The list is used primarily by acquirers to assess the risk of a business when it applies for a merchant account.  It is tied to MasterCard and Visa, so all acquirers check the MATCH file against any new merchants who apply for an account.  (It’s rare, with the exception of Costco for instance, for a merchant to accept other cards but not MasterCard and Visa.)  A MATCH listing includes the company name and principal names of the company, but a company’s inclusion on the list does not mean it, or its principals, would be prohibited from obtaining a merchant account again.  Acquirers use the MATCH file as an informational tool and will usually base a merchant application approval or denial on a complete investigation.  Once a merchant is on the MATCH list, it is almost impossible for them to removed, but it can be done.

Stay tuned for Part II, which will discuss who is really responsible for PCI compliance, working with third party service providers and how to avoid fines, MATCH and account termination.

Heartland’s 2008 data breach is supposedly the largest breach of that year, but not the only one hit by the same hacker. According to Bob Carr, CEO of Heartland, most of the companies affected did not come forward. However, news articles are blasting Heartland for not reporting the 2008 breach earlier so customers and merchants could take action and precautions. While the Department of Justice has been successful in capturing individuals behind the recent data breaches, this should be a strong sign to any company involved with sensitive data that they should be stepping up efforts in the prevention of data loss.

The delay of notification about data breaches is becoming too common and also a source of contention for those affected. The most recent news involved Radisson Hotels & Resorts, who recently revealed a breach which occurred between November, 2008 and May, 2009. According to the Associated Press, Radisson reported that the data breach affected cardholder names, card numbers and expiration dates of their North American customers but they did not specify how many were affected.

One approach to get companies to pay more attention to data security has been to hit violators financially. Visa and MasterCard impose fines for PCI compliance violations (MasterCard has recently increased their fines hoping that companies will take data security more seriously). Class action lawsuits have also been filed against companies like Heartland by customers whose credit cards were affected in data breaches. Lawsuits and the financial impact to companies who handle sensitive data shouldn’t be the reasons they impose stricter controls, but if that is, then companies who have been spared should take that as a lesson.

Following PCI DSS guidelines for securing data is simply not enough. Everyone in the “payment chain” (i.e. point of sale, processors, financial institutions) is responsible for ensuring data security. The stronger each piece is will help to strengthen the overall security of the data.  Additionally, although PCI compliance varies for different levels/tiers of processing volumes ($), everyone in the payment chain should go beyond what is required to protect the data. A processor using a third-party payment gateway should ensure that vendor is PCI compliant. That same third-party vendor should ensure their customers are PCI compliant as well. Finger pointing won’t solve the problem in a world where companies should work together to produce best practices.

Stronger encryption, along with the safety of, and restricted access to, physical data storage are just a few of the basics. Any company who handles sensitive data should have a dedicated team (or at least a key executive) assigned to manage those controls on a regular basis. A self assessment or qualified audit should be seen only as a guidepost. Companies relying only on auditors to determine their compliance are putting their company, and customers, in jeopardy. Being compliant doesn’t mean a company’s data is secure and the auditor cannot ensure that data is secure either. Their job is simply to report on the controls in place for data security.  VeriSign’s 2007 white paper about how to avoid an audit failure provides basic, yet necessary, measures for data security that are still valid, yet likely not practiced enough, today. Companies need to take these measures more personally on behalf of the security of their customer data.

The Open Web Application Security Project (OWASP) was created to help improve the security of application software. The project, whose online home is a wiki site, is a forum community open to anyone and its primary mission is to promote the visibility of web application security. The project also exists to aid organizations in making educated decisions about the security risks of web applications.

In an effort to establish an industry benchmark for the amount of dollars spent on web application security, the project conducted a survey and released the OWASP Security Spending Benchmark Report in March, 2009. The survey was conducted through the project’s 17 partners and resulted in valid responses from 51 organizations. The goal of the report was to measure spending habits regarding the development of web applications with secure code. However, it revealed a lot more.  The report revealed that only 61% of the 51 organizations surveyed used an independent third-party security organization to review their web application software code prior to going live. Twenty-two percent did not have an answer or only perform a review when requested by customers. Web application security only accounted for 10% of the overall security spending in 36% of the organizations. Additionally, a majority of the security checkpoints during the software development lifestyle occurred during the testing phase. The consensus is that checkpoints should occur at every stage, so as to find security issues earlier in the development process.

While organizations are spending money on data and application security, the costs are mainly based on regulatory compliance. The report also showed that over a third of the organizations surveyed also do not use web application firewalls to monitor or defend applications. The culmination of this information should raise a red flag for consumers and merchants alike (especially for merchants relying on third-party developers for their web applications).

According to Verizon’s 2009 annual Data Breach Investigation Report, the data breach was discovered by third parties in 69% of cases. The study, based on data analyzed from 285 million compromised records from 90 confirmed breaches in 2008, also found that 81% of affected organizations subject to the PCI DSS had been found non-compliant prior to being breached. The team conducting the study also stressed the importance of web application testing. 

In an attempt to assist developers in addressing application security risks, the OWASP created a Top 10 list of the most significant web application security vulnerabilities. More importantly the Payment Card Industry Data Security Standard has adopted the OWASP Top 10 with regards to secure coding guidelines. It is not a complete list, but considered a good starting point for developers writing secure code. The OWASP Top 10 list (created in 2004 and updated in 2007) is outlined below.

• A1 – Cross Site Scripting (XSS)
• A2 – Injection Flaws
• A3 – Malicious File Execution
• A4 – Insecure Direct Object Reference
• A5 – Cross Site Request Forgery (CSRF)
• A6 – Information Leakage and Improper Error Handling
• A7 – Broken Authentication and Session Management
• A8 – Insecure Cryptographic Storage
• A9 – Insecure Communications
• A10 – Failure to Restrict URL Access

What merchants need to know is that they cannot rely on firewall, network or host layer security to prevent data threats. If they are left to rely on developers and payment processors for payment security, merchants should be managing, or at least overseeing, these efforts to ensure that their e-commerce payment applications are tested completely before going live. If they are outsourcing application development, merchants should also review the development organization’s current customers as well as any history of data breaches involving the development organization and its web applications.

OWASP plans to release the benchmark report on a quarterly basis. This should help provide more exposure and a call to action in support of secure coding in e-commerce web applications.

A Little History

The PCI Security Standards Council (PCI SSC) was formed in December, 2004 by the major card brands (Visa, MasterCard, American Express, Discover and JCB) to educate and enhance the security standards in the credit card industry.  Prior to 2004, each card company had developed their own set of data security standards programs:

• Visa – CISP (Cardholder Information Security Program)
• MasterCard – SDP (Site Data Protection)
• American Express – DSS (Data Security)
• Discover – DISC – (Data Security Guidelines)

Some of the requirements were redundant and merchants were confused as to which one to follow. Even if a merchant only accepted Visa and MasterCard (bundled together in merchant processing agreements), there were some differences in each of their security programs. The agreement within the council was that if a merchant is CISP compliant, all the other card companies would consider the merchant to be compliant. After all, Visa has been the principal initiator for compliance over the years, with the other companies following suit with their own flavor. Additionally, the council agreed upon a uniform set of standards (PCI DSS) to simplify compliance for merchants.

The Standard Today

The PCI DSS (Payment Card Industry Data Security Standard) is the generalized term for PCI compliance today and governs all payment channels – retail (swiped), mail order, telephone order and e-commerce. It is divided into 12 security requirements, originally developed by Visa in 1999 (known then as the “digital dozen”).

The Standards Security Council does not validate PCI compliance or impose fines for non-compliance. What they do is own and enforce a uniform set of data security standards as well as provide training and certification for Qualified Security Assessors (QSAs) and Approved Scan Vendors (ASVs). The QSAs and ASVs exist to validate compliance and to interpret the PCI DSS for merchants and acquiring banks. On the flip side, each card brand has outlined specific fines for non-compliance and merchants are fined accordingly. For example, Visa imposes a $5,000 fine for a mid-sized retailer who is not in compliance with the PCI DSS. The good news is that in January of 2008, according to Visa, more than three-quarters of large U.S. merchants, and nearly two-thirds of medium-sized retailers, are in compliance with the Payment Card Industry Data Security Standard (PCI DSS). To further promote PCI DSS, Visa has also imposed financial incentives for compliance.

Although important for merchants to follow the current compliance standards, it is more important for merchants, software developers, payment processors and acquirers to be proactive in data security. Hackers will always be out there trying to break in, even if just to say they can do it. The PCI SSC is doing a good job, but I give kudos to anyone staying one step ahead of the game. Be a leader, not a follower.

There are two notable changes, one requires that off-site data storage locations be visited and validated as compliant with PCI DSS. The other imposes a sunset date on wired equivalency privacy (WEP) use. For those of us who don’t speak techie, WEP is a software application intended to protect data as it travels across wireless networks. In previous posts, I have talked about WEP having to be upgraded by June 30^th, 2010 to Wi-Fi protected access (WPA).

Here are the 12 core requirements as outlined by the card associations:

1. Install and maintain a firewall configuration to protect card holder data
2. Change all default passwords on all systems
3. Protect stored card holder data
4. Encrypt transmission of cardholder data across open public networks
5. Use and regularly update anti-virus software
6. Develop and maintain secure systems and applications
7. Restrict access to cardholder data on a need to know basis
8. Assign a unique ID to each person with computer access
9. Restrict physical access to card holder data
10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes
12. Maintain a policy that addresses security information

Many acquirers and large ISO’s have begun charging PCI compliance fees to their merchants to offset the costs they have had to incur in becoming compliant. As a merchant, I would want to know why they were not compliant to begin with and why I am being charged an additional amount for something they should already be doing. Online merchants can take matters into their own hands and ensure that their networks are following current PCI DSS guidelines and dispute compliance fees that are charged to them directly by their processor.

On Tuesday January 20^th, 2009 Heartland Payment Systems, a New Jersey based payment processor, disclosed that they had been hacked. Heartland Payment Systems processes about 100 million transactions a month for over 250,000 merchants. Although Heartland has not released numbers on how many card numbers have been compromised, it has been said that this breach will set a historic record. A breach of this magnitude will no doubt create a surge in fraudulent transactions all across a wide range of ecommerce sites and affect online purchases for a long time.

If you are an online business owner, be prepared for a rise in chargebacks and declined transactions. It is now more important than ever to have systems in place to monitor fraudulent activity. Implementing alert systems that detect a fraudulent transaction before they go through is a way to stay one step ahead. Another is to make sure you require AVS and CVV2 confirmations on your online orders.  Most importantly, have clear purchase terms and conditions on your site.

Only Heartland and the U.S. Secret Service will know the true extent of the breach but I am sure that we will all feel it in one way or another. If you are worried you are a card holder who may have been compromised, immediately notify your bank and have a new card issued. Contact all three credit bureaus and put an alert on your account.

PCI Compliance is a key element in protecting card holder data. So how can your business stay compliant without breaking the bank?

1.     Although a firewall provides a first line of defense, by itself it can still leave a website vulnerable. You or your service provider should perform manual reviews of all application source code. There are tools available that auto scan source code for vulnerability and security risks.

2.     In addition to a standard Network Firewall, it is recommended to put in place a web application firewall between your web server and end-point devices.

3.     As of September 30^th, 2009, all Level 1 and Level 2 merchants who are classified as large merchants (processing one to over six million visa transactions) will no longer be allowed to retain any data that is currently encoded on a magnetic stripe. If you are a merchant that falls into this category, you will be required to do annual on site PCI Assessment and a quarterly network scan. By September 30^th, 2010, acquiring banks must prove that all Level 1 Merchants have demonstrated compliance with the PCI DSS. For more information you can refer to Visa’s website and download compliance policies and procedures.

Compliance regulations get added each year, so my recommendation is to stay ahead of pack. A small amount of money invested in security now can save you a lot of money in fines and lost data later.

With hand-keyed transactions you run a greater risk of fraud because the magnetic strip information is not available. If you are in a retail environment you can do the following:

1. Check your terminal and make sure it is working properly. You can try to swipe your own card to ensure the issue is not with your equipment.
2. You can also check to see if the number embossed on the front of the card is the same as the number indented on the back. There are scams where thieves will shave the numbers to alter the embossed numbers on the front of a card.
3. Look at the expiration date and make sure it is valid.
4. It is important to get an imprint of the card and have the customer sign the imprint slip. This way you can confirm the signature matches the back of the card.

If you take cards over the internet, make sure you are following Payment Card Industry Data Security Standards. Seeking out proper fraud control software is a key element to keeping your transactions safe and keeping site secure.

Most people that are going to use fraudulent stolen cards follow the same patterns. Some key things to look out for are people making large purchases without any regard for size, color, or price. Some will try to distract you or rush the sale by asking questions about other items while they are at the register being rung up. Many will make a purchase then return to the store to make another purchase shortly after.

Visa and MasterCard both have security features in place on their cards that I believe all retail sales people should be trained on. For example, all Visa Cards have a Dove or Flag Hologram on the front, or a mini Dove on the back.  It is important to become familiar with the items (or lack thereof) that can easily signal an instance of fraud. 

Some online merchants think if they select a PCI Compliant gateway and shopping cart that they are automatically PCI Compliant. It is important that online merchants remember that physical location security and written policy is part of the process as well. Merchants are required to submit a SAQ (Self Assessment Questionnaire) to their acquirer once a year, but just submitting the SAQ may not be enough. It is also important that employees undergo training on security policies. Businesses must have ongoing assessment and remedies.

Merchants may think that PCI Compliance is for large businesses and may be too expensive for the average small retailer; however fines from noncompliance are much greater. Businesses will not only lose out on audit fees but also will have to consider a loss of reputation. Even if you are a smaller business, you are still required to be PCI Compliant regardless of the volume your business does.

Some businesses think if they install a firewall they are able to effectively and safely store card holder data. Although the storing of card holder data is strongly discouraged, if you have to store data a firewall will not be enough. Firewalls don’t ensure your devices, such as laptops, will not be stolen or sent out for repair. Make sure that all laptops are properly wiped before being transported.

The majority of small business owners don’t really have an IT person, or any idea of where to start. There are many websites that can support small business owners in ensuring their compliance. The PCI Security Standards Council website is a helpful resource.