PCI DSS Compliance Blog

PA-DSS and PABP

One common point of confusion for software vendors when it comes to PCI Compliance revolves around this question:

What’s the difference between PA-DSS and PABP?

Here’s the low down.  In 2005, Visa developed the Payment Application Best Practices (PABP). The purpose of the program was to guide software vendors in creating secure payment applications that prevent storage of sensitive cardholder data and mitigate cardholder data compromises.

Three years later, in 2008, the PCI Security Standards Council – made up of the major payment card brands — adopted Visa’s PABP and released it as the Payment Application Data Security Standard, or PA-DSS for short. In doing so, the PA-DSS replaced PABP for the purpose of the Visa’s payment application compliance program.  In other words, think PA-DSS, not PABP! 

The PCI SSC is transitioning all 555 products previously validated under Visa’s PABP over to a consolidated list located at the PCI SSC website, comprised of the validated PABP applications and newly validated PA-DSS applications. All new payment application assessments should undergo PA-DSS validation by a Payment Application Qualified Security Assessor (PA-QSA) and listing with the PCI SSC.  Another option is to go out of scope for PA-DSS by transferring the responsibility of handling sensitive cardholder data to a third party.

Each payment card brand has different requirements and deadlines for PA-DSS compliance.  At least up to this point, Visa has the most stringent deadlines for PA-DSS.  View them as well as other PCI compliance deadlines for each payment card brand in our blog post, PCI Compliance Deadlines. 

PA-DSS in 2010 – Are you Prepared?

2010 marks an important year for PA-DSS compliance.  On July 1 Visa’s fifth PA-DSS security mandate takes effect.  While the first four Visa mandates allowed various PA-DSS workarounds, the Visa Phase 5 Security Mandate clearly will not.  Up until this mandate, merchants using payment applications before the adoption of PA-DSS and who have not switched processors since its adoption were grandfathered in and not required to update to a PA-DSS compliant application.  This is no longer the case as of July 1: all merchants will be required to use only PA-DSS compliant applications.

With these fast approaching deadlines and the effort required to achieve compliance, Independent Software Vendors (ISVs) are finding themselves faced with major resource constraints.  It’s tough enough for ISVs to keep up with the competition and customer demand to build feature rich functions much less plan for compliance mandates requiring significant development time and effort.  However, ISVs that don’t take these deadlines seriously or remove their applications from the scope of compliance will lose customers that they worked hard to get and will ultimately be forced out of business. 

Most ISVs should have a PA-DSS compliance plan in place by now.  If you don’t, start by reading our post on PA-DSS implementation and get moving fast.  For those with PA-DSS plans in place, be sure that you are reaching out to merchants using your software and informing them of the upcoming July 1 deadline.  If they haven’t upgraded to a PA-DSS compliant version of your application by this date, they risk losing the ability to process credit and debit card transactions. 

PCI Compliance Interview

PCI Compliance Thought Leader Q&A
Interview with Rick Dakin, President of Coalfire

PCI DSS Compliance Blog: Tell us about Coalfire.
Rick Dakin: Coalfire is an IT audit and compliance firm.  We spun out of an application hosting company in 2001 and have remained focused on a single mission since that time - to provide cost-effective IT audits and compliance advisory services.  This focus allows us to provide an independent view of compliance to stakeholders subject to Payment Card Industry (PCI), banking, healthcare and privacy regulations and laws.

The company provides a wide range of security and IT audit and advisory services through a team of 50 professionals from offices in Colorado, Washington and New York.

What work does Coalfire do in the area of PCI compliance?
Coalfire provides a full range of PCI assessment and compliance advisory services that includes certification to perform the following activities:
•    Qualified Security Assessor (QSA) – provide level 1 Report on Compliance (ROC) reports after on-site testing, and facilitation for completion of a Self Assessment Questionnaire (SAQ).
•    Payment Application – Qualified Security Assessor (PA-QSA) – Perform application testing and validation to the Payment Application-Data Security Standard (PA-DSS).
•    Approved Scan Vendor (ASV) –perform internal and external network vulnerability scans.
•    Penetration testing services are provided to all PCI clients.

What does it take to become a certified QSA? 
A QSA must work for a QSA company.  The requirements for QSA companies include registration (with fees), $2 million of professional liability insurance, and compliance to the rules published by the PCI Security Standards Council (PCI SSC).  All QSA companies are subject to review by the council.

Once a QSA company is established, an individual QSA must first obtain a security industry certification like a CISSP or CISA certification, 3 or more years of industry experience and hands-on PCI experience supporting another certified QSA.  All QSA participants must then pass a background check and complete formal PCI training and certification testing. 

At Coalfire, we estimate that each individual QSA costs us $7,500 per year to maintain industry certification, registration fees and insurance in addition to 50+ hours per year in training or off-site testing.  In short, it is a significant commitment by both the QSA and the QSA company to provide certified services in the industry. 

Merchants and software developers are often confused by the various levels of advice available to them.  Some companies do not complete the rigorous QSA training, testing, certification or peer reviews that guide our processes and methods to determine compliance to PCI standards.  Accordingly, the advice provided by a certified QSA may differ from advice provided by an industry observer who is not subject to the QSA process.

How many assessments are you doing per year?
Coalfire will perform over 1,000 assessments this year for more than 600 clients.  Over 60% of those assessments will be performed for clients with PCI DSS or  PA-DSS requirements.  Our processes and methods to determine compliance have been developed and vetted through thousands of tests, council peer review and success in preventing compliance failure for any of our validated clients.

Are more of your customers concerned with PA-DSS (ISVs) or PCI DSS (merchants)?
Since merchants outnumber the payment application vendors in the market, we conduct more merchant and service provider level 1 and 2 ROC and SAQ testing.  However, we are seeing a dramatic increase in the amount of PA-DSS compliance validation work from payment application developers.  This trend clearly verifies that merchants are improving security infrastructure more quickly than payment applications are being updated to comply with the Payment Application Data Security Standard (PA-DSS).

As a result, processors and merchants are facing critical deadlines to verify that payment application vendors comply with PA-DSS or force merchants to switch applications to a version that is already compliant.  This change is disruptive to many merchants since the updated applications typically require changes to platforms or infrastructure.

The problem cascades through the payment ecosystem because payment application vendors are having trouble finding a PA-QSA with resource availability to complete pre-audit testing or final validation testing on a timetable that will enable merchants to fully deploy PA-DSS compliant applications prior to the July 2010 deadline.

Can you walk us through a brief step-by-step process that you go through with your clients in the area of PCI compliance?
Our process is consistent across all product areas to include ROC, SAQ and PA-DSS test and reporting.  The following example is provided to outline the payment application validation process.

1.    Prospects enroll in an online audit preparation and self assessment tool called Navis.  The Navis platform has RapidPA-DSS, RapidSAQ and RapidROC modules.
2.    Prospects enter evidence that they meet specific controls in a “Turbo Tax” styled online questionnaire and data collection portal.
3.    Once the prospect data is entered and indicates that the payment application is ready to test, Coalfire’s staff reviews the data entered into the online platform and advises the prospect on the process to complete PA-DSS validation testing.
4.    After a contract is signed, Coalfire performs PA-DSS validation testing and provides a final gap analysis report to the developer to complete program modifications required to comply with PA-DSS standards.
5.    Final testing is completed and a PA-DSS reporting is submitted to the PCI Council.
6.    To become registered on the PCI Council PA-DSS list, each payment application vendor must sign a compliance agreement and pay a registration fee to the PCI Council.

What’s the area of greatest confusion for your customers? (ISVs or merchants)
The biggest area of confusion that we typically see is the separation of compliance responsibility between the ISV and their merchant clients.  Many clients think that the payment application vendor is solely responsible for PCI compliance.

Another common misconception among some merchants is that if they use PA-DSS-compliant payment applications, the merchant itself has met its obligations for PCI validation.  Coalfire works with payment application developers to help them guide their customers through a process to meet the full PCI standard and reduce the merchants’ risk of fines and penalties for non-compliance.  At the same time, this helps mitigate the payment application developer’s risk from civil claims from merchants using their technologies. 

There is perhaps no greater concern for merchants and software vendors than the cost of PCI DSS and PA-DSS compliance. How do you see the costs of PCI compliance weighing out against the cost of non-compliance?
How does the old Carpenters’ song go? … “We’ve only just begun.”

While the amount of investment in data security is growing at a breath taking rate, so is the investment being made in the personal injury litigation market.  We are seeing a dramatic increase in the amount of litigation being pursued to recover costs associated with identity theft and data breach, including credit card compromise.

In the last 3 years, over 40 states have passed aggressive new data breach legislation that will enable even more litigation.  Most breached merchants contact us with fears that they will be fined by VISA.  This is the least of their concerns.  I see most of the losses associated with litigation, fraud recovery costs, breach notice and post-breach system remediation.

Coalfire is not a law firm, but we see the damage caused by data breach up close.  This has taught us that the cost of compliance is really the investment to defend your organization from growing claims of negligence.  In the retail sector, the PCI Data Security Standard is the reasonable standard being used to determine negligence.

The trade off that we have experienced from our support of compromised merchants is that a dollar of compliance investment will save $10 of potential breach costs. Accordingly, we see the card brands like VISA moving into a secondary role.  We see state data privacy laws and the liability attorneys driving the need to validate compliance in the future.

How aggressive do you foresee credit card companies like MasterCard and Visa being with the new fines for non-compliance? What about specifically for smaller businesses?
For level 1 and 2 merchants, fines for non-compliance have become commonplace.  For level 3 and 4 merchants, enforcement has been “spotty” due to the various levels of tracking performed by the merchant processor.  We expect this random review of merchant compliance to change in 2010 since every processor must understand the status of merchants using only validated payment applications. 

Processors are making significant investments in their ability to track compliance of their level 3 and 4 merchants as a part of the process to inventory all payment applications to the PA-DSS requirement.  Accordingly, we expect fines for level 3 and 4 merchants to grow starting later in 2010.

Again, the fines are secondary.  We see the bigger risk that software vendors are offering non-compliant payment applications to customers who use them after July 2010 as a reason for the liability attorneys to pursue claims of negligence in the case of a data breach.  The PCI Council set the standard for reasonableness and now the attorneys have a clear path to collect huge sums for negligence on the part of merchants, processors and software developers who continue to use non-validated payment applications.

With PCI standards evolving, how do you stay at the forefront of the industry?
Unfortunately, the demands for more secure payments are driving investment in evolving PCI requirements at a time when merchants want their software developers to help them provide higher quality and more focused service to consumers. 

It is clear that the PCI standards that are being used today are not yet adequate to mitigate all risks to the payment processes.  The PCI Security Standards Council is providing leadership for a number of “next-generation” controls that will likely be included in future PCI Data Security Standards at both the application and infrastructure levels.

Many larger payment application vendors are removing payment modules from other merchant application services in order to contain the cost of data security.  By removing payment modules from commerce platforms and installing a shared payment service (managed by the application or by a third party), payment application developers can release updates to other non-payment modules without the expense associated with PA-DSS testing.  For the payment modules, application developers can focus more effort on enhancing controls when the platform is shared.  As a result, we see the trend for payment application developers continuing to move towards shrinking the payment environment and continuing to remove payment modules from other commerce functions.  Over the next few years, we would expect that the number of payment modules to shrink by a significant percentage.

Where do you see this industry in five years?
The payment industry is maturing.  Merchants and payment application vendors are faced with the market demand to simplify the PCI-compliance process and to reduce the cost of compliance.

Over the next 5 years, I expect that this overwhelming market demand will be met with solutions like centralized management of payment data to dramatically reduce the amount of data that is placed at risk in a distributed commerce environment.  The industry will have to keep innovating to allow consumers to get in and out of a retail environment more quickly while receiving higher quality and inherently more secure service.

The sophistication of payment processes will also have to continue developing at a rapid pace to keep up with online, mobile, in-store and unattended commerce opportunities.  Accordingly, only a few players will be able to make the investment in these dramatically shifting payment solutions to embed more encryption and continuous monitoring.

PA-DSS Implementation

Last week we wrote about how merchants become PCI compliant.  Today we want to outline the steps independent software vendors (ISVs) must take in order to become PA-DSS compliant.

Step 1 of PA-DSS implementation: Get familiar with the compliance standard that applies to you: the Payment Application Data Security Standard (or PA-DSS for short).  PA-DSS applies to software developers and integrators of applications that store, process or transmit payment cardholder data as part of authorization or settlement. It also applies to these applications that are sold, distributed or licensed to third parties.

PA-DSS requirements include:

1. Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CIV2, CW2) or PIN block data
2. Provide secure password features 
3. Protect stored cardholder data
4. Log application activity
5. Develop secure applications
6. Protect wireless transmissions
7. Test applications to address vulnerabilities
8. Facilitate secure network implementation
9. Do not store cardholder data on a server connected to the Internet
10. Facilitate secure remote software updates
11. Facilitate secure remote access to application
12. Encrypt sensitive traffic over public networks
13. Encrypt all non-console administrative access
14. Maintain instructional documentation and training programs for customers, resellers and integrators

Most ISVs then have two options from here: achieve PA-DSS compliance by undergoing an audit by a Qualified Security Assessor (QSA) or go out of scope of PA-DSS. 

To stay in scope of PA-DSS, software vendors must undergo the process of validating their application or applications.  This involves a security audit from a PA-DSS Qualified Security Assessor (QSA), as well as any development changes needed to bring the application into compliance.  ISVs are required to pay $1,250 annually (per software application) to have their solution listed as a validated PA-DSS-compliant solution.

Each payment card brand has their own terms for PA-DSS compliance.  We’ve written a comprehensive article on the different PCI compliance deadlines for each payment card brand, along with their different PCI compliance requirements.

To go out of scope of PA-DSS, ISVs need to transfer the responsibility of handling sensitive cardholder data to a third party.  Some payment processing companies offer hosted solutions where sensitive credit and debit card data bypasses your software all together and is transmitted directly to the payment processor.

Some resources to fulfill PA-DSS requirements:

PCI SSC’s page on PA-DSS compliance

Element’s comparison of PA-DSS certification and going out of scope of PA-DSS

Element’s solution for going out of scope for PA-DSS compliance

Related Blog Posts:

Visa PA-DSS

PA-DSS Case Study

Visa and PCI Compliance

Visa PCI compliance can seem like the veritable fast-moving train upon which you should already be seated, ticket in hand.  Fortunately, the conductors of the train (Visa), have chosen to bring the train out of the station slowly enough to give everyone a fair chance to board it or, in some cases, catch up.

By implementing PA-DSS in distinct phases, Visa has afforded merchants and software vendors the opportunity to meet security standards at a gradual and manageable pace.  Rather than implementing wholesale security compliance mandates all at once, Visa’s compliance program has evolved through various phases.

As we wrote a post about recently, Visa’s Phase 4 Security Mandate for software vendors is quickly approaching.  While this is an important deadline, next year’s Visa Phase 5 Security Mandate represents the final stage in PA-DSS compliance.  All previous Visa security mandates have focused on identifying and phasing out payment applications that are not PA-DSS compliant.  The Visa Phase 5 Security Mandate, effective July 1, 2010, goes beyond removing non-compliant applications to require that only PA-DSS compliant applications be used:

Acquirers must ensure their merchants, VNPs and agents use only PA-DSS compliant applications.

While the first four Visa mandates allowed various PA-DSS workarounds, the Visa Phase 5 Security Mandate clearly will not.  Put simply, the advent of Phase 5 will only permit the use of PA-DSS compliant payment applications. 

With less than a year remaining, software vendors should begin planning for the final Visa PCI compliance mandate.

Related Posts and Pages:

Visa PA-DSS

PCI Compliance Deadlines

MasterCard PCI Compliance

Top 10 Questions About PA-DSS By Independent Software Vendors

By Jeff Gross, Element Payment Services

We speak with software vendors all day long about their applications and what the payment industry security standards mean to them. The questions they ask are very insightful, so we thought we’d share the top ten most common questions we receive.

Hope this helps you understand the PA-DSS and the complex issues surrounding it on a deeper level.  Feel free to pose any other questions you have about PA-DSS in the comment section. We’d be happy to answer them.

1. Q: PA what?

A: We still get responses like “PA-what?” when mentioning PA-DSS for the first time to software providers. There clearly needs to be more education around this security standard. 

PA-DSS stands for the Payment Application Data Security Standard. It was created by the major credit card brands (under the umbrella of the Payment Card Industry Security Standards Council) to combat the growing number of credit and debit cardholder data breaches. Seventy five percent of all data security attacks are against software applications. The PA-DSS mandates all payment applications that store, process or transmit payment cardholder data as part of authorization or settlement be certified on a continuous basis using an approved Payment Application Quality Security Assessor (PA-QSA).  The PA-DSS applies to applications that are sold, distributed or licensed to third parties.

Learn more about the PA-DSS requirements.

2. Q: What is the difference between PA-DSS and PCI DSS?

A: The PA-DSS applies to software applications that store, transmit or process credit card data, whereas the PCI DSS applies to merchants that accept payment cards.  Both were created to protect consumer cardholder data.

Learn more about PCI DSS requirements.

3. Q: I’m confused. I thought the credit card brands had their own security standards, like Visa’s PABP.

A:  In September 2006, American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International formed the Payment Card Industry (PCI) Data Security Standard, an independent council designed to improve payment account security. 

The PCI Security Standards Council serves as an advisory group and manages the underlying PCI security standards; however, each payment card brand is responsible for its own compliance programs.  Even though the PCI Security Standards Council developed these standards, each payment card brand is responsible for its own compliance programs and has different deadlines for PCI compliance for merchants and software providers.

4. Q: How serious is this PA-DSS stuff?  We haven’t seen anything as far as fines or anything for non-compliance.

A: All payment applications have to be compliant by July 1, 2010 (Visa’s Final Security Deadline) or risk their customers not being able to process Visa credit cards at all.  And as of October 1, 2009, VisaNet processors must decertify all vulnerable payment applications.  While non-compliance with PA-DSS hasn’t yet been addressed with fines, the card brands are addressing the issue by removing the ability to process payments entirely. 

If it is any indication, MasterCard has begun fining merchants for non-PCI DSS compliance. 

5. Q: How much does the PA-DSS assessment cost?

A:  To achieve PA-DSS compliance, software providers must undergo the process of validating their application. This involves a security audit from a PA-DSS Qualified Security Assessor (QSA) and the development time and expense to bring the application into compliance. These PA-DSS certification costs generally range between $10,000 to $30,000.  Some software providers also have the option of going out of scope for PA-DSS certification, which cuts down on PA-DSS compliance costs. 

6. Q:  Could our merchants just stop taking credit cards? 

While merchants could stop taking credit cards, customers using credit cards tend to spend 2 to 3 times more than customers who only carry cash or check.  And since the major credit card brands are accepted worldwide, you expose your business to customers from all around the globe, instead of just locally.

7. Q: If we are PA-DSS-compliant, does that mean my merchants are compliant? 

A: PA-DSS and PCI DSS are still two separate compliance standards.  All merchants must still meet the PCI DSS requirements.  Using a PA-DSS compliant application does not remove this requirement.  At a minimum, the appropriate PCI Self-Assessment Questionnaire and network scan should be completed by all merchants.  However, since PA-DSS is a part of PCI compliance standards, new merchants or merchants that change processing providers cannot meet PCI requirements if they are using non-compliant applications.  And, the requirements are only getting tougher.  As of 7/1/2010, all merchant account providers are required to ensure that their merchants use only PA-DSS compliant applications.

8. Q: "Ok, here’s my PCI network scan.  We’ve been confirmed compliant.  Please set us up so that our merchants can process payment cards.”

A: Vulnerability scans are required by the PCI DSS, not the PA-DSS.  Software vendors must pass a PA-DSS review performed by a Payment Application QSA, as well as fulfill all of the PA-DSS requirements.  

9. Q: If I’m just passing card numbers to the merchant, but not storing card numbers, then why do I have to have a PA-DSS assessment?

A: If your software application comes in contact with sensitive cardholder data, the application is in scope of PA-DSS. 

10. Q: Is there anything I can do to get around the requirement of a PA-DSS assessment?

A: The only way this could be done is to have your application not store, process or transmit sensitive cardholder data AT ALL.  Element’s Hosted Payments solution takes software providers entirely out of scope of PA-DSS.   

VISA PA DSS - Phase 4 Security Mandate

As Ben Rothke wrote in a recent article, the much-ballyhooed debates in regard to PCI Compliance seem to shun the notion that PCI DSS is, effectively, evolutionary.  The PCI DSS “Lifecycle Process” (PDF) is intended to ensure that changes to PCI DSS follow a pre-determined 24-month cycle that allows for a gradual implementation of standards rather than drastic changes that would result in many organizations being suddenly non-compliant. 

Ironically, the very merchants for whom this gradual phasing-in was developed have been among the most vocal critics of PCI DSS.   Given such concern, it is hard to imagine the ferocity with which PCI DSS might be attacked were the entire PCI DSS “lifecycle” condensed and implemented at once; gradual implementation isn’t necessarily ideal for lockstep security, but it makes compliance among retailers far more realistic (and convenient), despite occasional assertions to the contrary. 

Similarly, merchants and software providers are witnessing Payment Application Data Security Standards (PA DSS) compliance continue on an evolutionary path, the ultimate goal being the elimination of vulnerable payment applications.   Accordingly, the payment application security mandates (PDF) set forth by Visa continue to move through the pre-determined five phases.

Visa PA DSS Compliance Deadline Approaching

As of October 1, 2009 merchants and software providers must decertify all known vulnerable payment applications, including those published on Visa's list of vulnerable payment applications. As future vulnerable payment applications are identified, VisaNet Processors, and agents, must decertify these, too, within 12 months.

What this means for merchants and software providers is that the age of relying on anything but compliant payment applications is nearing an end.  With the ability to accept credit cards at stake, trusting non-compliant applications hardly seems like a risk worth taking.

October 1 will be here quicker than you might realize.  Are you ready? 

Related Posts and Pages:

PA DSS Compliant Applications
Payment Application Data Security Standard (PA DSS)
PA DSS and PABP
Integrated Payment Processing
Hosted Payments

Are You A PCI Compliance Guru?

We’re excited to announce the launch of the PCI Compliance Quiz Widget, created to help widen the knowledge base of Payment Card Industry (PCI) compliance.

The PCI compliance standards were developed by the major payment card brands in response to a recent growth in data security breaches. They apply to all businesses that handle payment cards.  The three PCI standards are the Payment Card Industry Data Security Standard (PCI DSS), for merchants and processors, the Payment Application Data Security Standard (PA-DSS), for developers and integrators, and the Payment Card Industry PIN Entry Device Security Requirements (PCI PED), for manufacturers.

The PCI Compliance Quiz Widget is an interactive widget that can be embedded at any website.  The quiz tests participants’ knowledge of PCI Compliance with ten true-false questions.  After completing the quiz, the participant is given a score and a corresponding title ranging from “PCI Compliance Green” to “PCI Compliance Guru.”

Available free of charge to any site administrator or blogger, the PCI Compliance Quiz Widget is a unique educational and informational tool that can build or bolster knowledge of PCI compliance. 

Take The PCI Compliance Quiz

How’d you do?  If you enjoyed the Quiz Widget and would like to post it on your site or blog, please feel free to do so.  Just cut and paste this the HTML code on the bottom of the quiz pages and you’re ready to go.

PCI Compliance Deadlines

Knowing the critical deadlines for the Payment Card Industry Standards - PCI DSS, PA-DSS, and PCI PED - is vital for any merchant or payment service provider.  But finding all the PCI compliance dates can be tricky: even though the PCI Security Standards Council (PCI SSC) developed these standards, compliance is actually mandated by the individual payment card brands - Visa, Master Card, American Express, Discover and JCB International.

The PCI SSC does not currently maintain a comprehensive list of the PCI compliance deadlines on their site, so we compiled one here for each payment card brand, along with a link to their PCI compliance program section of their sites.  We hope you find this list useful.

Visa CISP (Cardholder Information Security Program)

Merchants

All compliance dates for Visa merchants have passed. Visa's PCI compliance validation requirements for merchants:

Level / Tier	Merchant Criteria	Validation Requirements
1	Merchants processing over 6 million Visa transactions annually (all channels) or Global merchants identified as Level 1 by any Visa region	Annual Report on Compliance (“ROC”) by Qualified Security Assessor (“QSA”) Quarterly network scan by Approved Scan Vendor (“ASV”) Attestation of Compliance Form
2	Merchants processing 1 million to 6 million Visa transactions annually (all channels)	Annual Self-Assessment Questionnaire (“SAQ”) Quarterly network scan by ASV Attestation of Compliance Form
3	Merchants processing 20,000 to 1 million Visa e-commerce transactions annually	Annual SAQ Quarterly network scan by ASV Attestation of Compliance Form
4	Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually	Annual SAQ recommended Quarterly network scan by ASV if applicable Compliance validation requirements set by acquirer

 

Service Providers

Level*	Validation Action	Validated By	Due Date
1	Annual On-Site PCI Data Security Assessment Quarterly Network Scan	Qualified Security Assessor Approved Scanning Vendor	2/1/2009
2	Annual PCI Self-Assessment Questionnaire Quarterly Network Scan	Service Provider Approved Scanning Vendor	2/1/2009

*Visa Service Provider Levels are defined as:
Level 1 - VisaNet processors or any service provider that stores, processes and/or transmits over 300,000 transactions per year
Level 2 - Any service provider that stores, processes and/or transmits less than 300,000 transactions per year

 

Software Applications - US and Canada*

Phase	Compliance Mandate	Effective Date
1	Newly boarded merchants must not use known vulnerable payment applications, and VisaNet Processors (VNPs) and agents must not certify new payment applications to their platforms that are known vulnerable payment applications	1/1/2008
2	VNPs and agents must only certify new payment applications to their platforms that are PA-DSS-compliant	7/1/2008
3	Newly boarded Level 3 and 4 merchants must be PCI DSS compliant or use PA-DSS-compliant applications	10/1/2008
4	VNPs and agents must decertify all vulnerable payment applications	10/1/2009
5	Acquirers must ensure their merchants, VNPs and agents use only PA-DSS compliant applications	7/1/2010

*In Asia Pacific, Central and Eastern Europe, Middle East and Africa, Latin America and the Caribbean (LAC), Visa acquirers must ensure that newly signed merchants use PA-DSS compliant applications by July 1, 2010. By July 1, 2012, those acquirers must ensure existing merchants and agents in the Visa network use PA-DSS compliant applications.

Visa CISP Program Home

Mastercard SDP Program (Site Data Protection)

Merchants

Merchant Definition	Criteria	Onsite Review	Self Assessment	Network Security Scan	Initial Compliance Validation Date
Level 1	Any merchant that has suffered a hack or an attack that resulted in an account data compromise Any merchant having greater than six million total combined MasterCard and Maestro transactions annually Any merchant meeting the Level 1 criteria of Visa Any merchant that MasterCard, in its sole discretion, determines should meet the Level 1 merchant requirements to minimize risk to the system	Required Annually	Not Required	Required Quarterly	6/30/2011
Level 2	Any merchant with greater than one million but less than or equal to six million total combined MasterCard and Maestro transactions annually Any merchant meeting the Level 2 criteria of Visa	At Merchant Discretion	Required Annually	Required Quarterly	06/30/2011
Level 3	Any merchant with greater than 20,000 combined MasterCard and Maestro e-commerce transactions annually but less than or equal to one million total combined MasterCard and Maestro ecommerce transactions annually Any merchant meeting the Level 3 criteria of Visa	Not Required	Required Annually	Required Quarterly	6/30/2005
Level 4	All other merchants	Not Required	Required Annually	Required Quarterly	Consult Acquirer

 

Service Providers

All compliance dates for Mastercard Service Providers have passed. Required validation procedures by level:

Service Provider Definition	Criteria	Requirement
Level 1	All TPPs All DSE’s that store, transmit, or process greater than 1,000,000 total combined MasterCard and Maestro transactions annually	Annual Onsite review performed by a Qualified Security Assessor (QSA)  Quarterly scan by an Approved Scanning Vendor (ASV)
Level 2	Includes all DSE’s that store, transmit, or process less than 1,000,000 total combined MasterCard and Maestro transactions annually	Annual Self-Assessment Questionnaire (SAQ)  Quarterly scan by an Approved Scanning Vendor (ASV)

Mastercard SDP Program Home

American Express Data Security

American Express requires merchants and service providers agree with their Data Security Operating Policy. American Express compliance dates are based on the date of the validation documentation: 90 days from the date of a scan, an updated scan document is due. One year (365 days) from the date of an Annual Onsite Audit, an updated Annual Onsite Audit is due.

Merchants

Level	Definition	Validation Documentation	Requirement
1	2.5 million American Express Card transactions or more per year; or any merchant that has had a data incident; or any merchant that American Express otherwise deems a Level 1	Annual Onsite Security Audit Report and Quarterly Network Scan	Mandatory
2	50,000 to 2.5 million American Express Card transactions per year	Quarterly Network Scan	Mandatory
3	Less than 50,000 American Express Card transactions per year	Quarterly Network Scan	Strongly Recommended

 

Service Providers

Compliance Requirements

Comply with the PA-DSS and the American Express Data Security Operating Policy Annual Onsite Security Audit Validation Documentation Quarterly Network Scan Validation Documentation

American Express Data Security Home

Discover Information Security & Compliance (DISC)

Merchants

Discover's Merchant Activity Calendar:

Activity	Date
Assessments started prior to 12/31/2008 may use PCI DSS v1.1 or PCI DSS v1.2	12/31/2008
All new assessments must use PCI DSS v1.2	1/1/2009
Last date that PCI DSS v1.1 assessments will be accepted	12/31/2009
All assessments must use PCI DSS v1.2 – PCI DSS v1.1 assessments no longer accepted	1/1/2010

Discover's Merchant Levels and Compliance Requirements:

Level	Description	Compliance Validation Requirements
1	All merchants processing a total of more than 6 million Discover Network card transactions per year Any merchant Discover Network, in its sole discretion, determines should meet the Level 1 compliance validation and reporting requirements All merchants required by another payment brand to validate and report their compliance as a Level 1 merchant	Complete an annual on-site assessment using the PCI DSS Requirements and Security Assessment Procedures. On-site assessment may be performed by a Qualified Security Assessor OR merchant’s internal auditor Complete Quarterly Network Vulnerability Scans performed by an Approved Scanning Vendor
2	All merchants processing a total of 1 million to 6 million Discover Network card transactions per year All merchants required by another payment brand to validate and report their compliance as a Level 2 merchant	Complete an annual self-assessment using the applicable PCI DSS Self-Assessment Questionnaire ("SAQ") Complete Quarterly Network Vulnerability Scans performed by an Approved Scanning Vendor
3	All merchants processing a total of 20,000 to 1 million Discover Network card-not-present only transactions per year All merchants required by another payment brand to validate and report their compliance as a Level 3 merchant	Complete an annual self-assessment using the applicable PCI DSS SAQ Complete Quarterly Network Vulnerability Scans performed by an Approved Scanning Vendor
4	All other merchants	Validation and Reporting Requirements determined by the merchant's acquirer. Annual self-assessment using the applicable PCI DSS SAQ AND Quarterly Network Vulnerability Scans performed by an Approved Scanning Vendor are recommended

 

Service Providers

All service providers that process, store or transmit Discover Network cardholder data are required to report their compliance status to Discover Network on an annual basis. All compliance reports must be submitted by December 31 for the current year.

Assessment	Requirement
On-Site Assessment	Service providers that completed an on-site assessment using PCI DSS v1.2 are required to submit Appendix E of the PCI DSS Requirements and Security Assessment Procedures v1.2: Attestation of Compliance - Service Providers, as well as the Executive Summary of the Report on Compliance (ROC). Discover Network requires service providers that are not fully compliant with the PCI DSS to also complete the "Action Plan for Non-Compliant Status" section of the Attestation of Compliance.
Self-Assessment	Service providers that perform a self-assessment are required to complete PCI DSS Self-Assessment Questionnaire D and submit the Service Provider Version of the Attestation of Compliance. Discover Network requires service providers that are not fully compliant with the PCI DSS to also complete the "Action Plan for Non-Compliant Status" Section of the Attestation of Compliance.

Discover also strongly recommends that service providers and their agents use payment applications that have been validated as compliant with the PCI Payment Application Data Security Standard (PA-DSS).

DISC Home

JCB International

Contact JCB International directly for PCI compliance deadlines.

Cost of PCI Compliance

'What does it cost be PCI compliant?’ is a common question by business owners and software providers facing compliance requirements.  Several estimates have been generated by industry leaders on PCI compliance costs. 

For Merchants (Complying with PCI DSS)

IT security firms Solidcore Systems, Emagined Security and Fortrex Technologies have identified three main categories of PCI compliance costs:

•    Upgrading payment systems and security infrastructure,
•    Verifying compliance (assessments), and
•    Sustaining compliance.

New components that might have to be installed to upgrade payment systems and security infrastructure include additional firewalls, upgraded anti-virus and anti-spyware software, secure wireless systems, data encryption technologies and file-integrity monitoring software. 

Compliance assessments include the PCI Self-Assessment Questionnaire (PCI SAQ) for Level 2, 3 and 4 merchants and an on-site audit for Level 1 merchants. 

In 2008, IT research giant Gartner reported that merchant spending to protect cardholder data and become PCI compliant increased nearly fivefold during the previous 18 months.  Among the Level 1 retailers Gartner surveyed, an average of $2.7 million was spent to become PCI compliant, excluding the costs of PCI assessment services. That number compares with an average of $568,000 reported by Level 1 merchants in a fall 2006 Gartner survey. Level 1 merchants spent an average of $237,000 on PCI security assessments.

Level 2 merchants reported spending $1.1 million on PCI compliance (compared to $267,000 in fall 2006) and an average of $135,000 on assessment.   Level 3 merchants, those processing between 20,000 and one million transactions per year, spent an average of $155,000, excluding security assessment.  Gartner did not discuss Level 4 merchants in the report.

For Software Developers (Complying with PA-DSS)

To achieve PA-DSS compliance, software providers must undergo the lengthy and costly process of validating their application. This involves a security audit from a PA-DSS Qualified Security Assessor (QSA) and the development time and expense to bring the application into compliance. These PA-DSS certification costs can range from tens to hundreds of thousands of dollars.

Additionally, software providers are required to pay $1,250 annually per software application to have their solution listed as a validated PA-DSS-compliant solution.