PCI DSS Compliance Blog

How to Learn about PCI Compliance

When business owners or IT directors first become aware they need to comply with the Payment Card Industry Data Security Standard (PCI DSS) and haven’t gone through the process before, a period of learning, head scratching and sorting through the various PCI DSS requirements begins.  A similar trend applies for software vendors when they begin to understand the PA-DSS.

So when it comes to PCI compliance newbies, what’s the easiest way to get educated?

PCI Security Standards Council Website – First read through the PCI Security Standards Council  website, becoming familiar with the different PCI compliance standards.  The recently published Quick Guide is a good place to start.

Read PCI Compliance Related Blogs – Blogs are great for providing tips and in-depth analysis on the standards, technologies and strategies to help comply, etc.  Here are few of our favorites:

Storefront Backtalk

Anton Chuvakin “Security Warrior”

Treasury Institute for Higher Education (great for educators)

Read and Post Questions on PCI Compliance Forums – Post questions you have about PCI compliance on forums.  It’s amazing how much expert advice you will receive for free.  Or if you don’t have any specific questions yet surf the forums simply to gain more knowledge.   PCI Knowledge Base and Society of Payment Security Professionals are the best PCI compliance forums.

Listen to Podcasts and Attend Webinars – The PCI Security Council and several companies offer webinars and podcasts about PCI compliance.  Attend them live or download them later on, commonly for free.

Join LinkedIn Groups or Facebook Pages – Similar to forums, engage with a group of professionals working towards PCI compliance and experts in the field on social networking sites.  Check out the PCI DSS Forum group on LinkedIn or the Understanding PA-DSS Facebook page. 

Attend PCI DSS Training - The PCI Security Standards Council offers a two day training course based directly on the PCI SSC Qualified Security Assessor (QSA) training program. Attendees will learn what the QSAs learn so they can better prepare for an on-site PCI DSS assessment or perform the assessment internally. In addition to the QSA training materials, the Standards training course will also cover how to develop an internal PCI DSS compliance program to sustain PCI compliance after the on-site assessment is complete.  This is mainly for large companies. 

SANS also offers a general course on PCI DSS compliance and the Treasury Institute for Higher Education hosts a PCI workshop for higher education institutions.   Glenbrook offers a Payments Boot Camp that dives deeply into the current trends and issues of the U.S. payment system.

PCI Compliance for Franchisors

In an article on Storefront Backtalk last month franchisee columnist Todd Michaud wrote that when it comes to PCI compliance, franchise-based retailers “are screwed.”  We agree that franchise parent companies have a lot to weigh out when it comes to a PCI compliance strategy.  And for the three options Michaud outlines for handling PCI compliance with their franchisees – a completely hands off approach, requiring proof of an audit, and rolling out a comprehensive PCI compliance program – we’d lean towards the last.

PCI DSS compliance can be a confusing process, particularly for smaller franchisees that may lack IT personnel.  Franchisors should become a beacon of light to ease this process: it is part of their duty of service.  Part of the PCI compliance program should be a strategic partnership with a payment processing provider who is knowledgeable in the PCI compliance space and who can play the role of trusted advisor to franchisees.  Ideally, that merchant services partner will have a PCI DSS compliance program established themselves, relieving much of the heavy lifting for the franchisor.

The franchisor will have the opportunity to negotiate better rates this way, which both franchisor and franchisee will ultimately benefit from.  Look for a payment processor that offers the most security through technology like end-to-end encryption and tokenization, something Michaud describes as “daydream adventures,” but we know of a payment processor that offers it already (wink, wink). Franchisors leveraging their size will help make these cutting-edge technologies cost-effective for their franchisees, while reducing the risk of a data security breach. 

From a branding standpoint, franchisors have a lot to lose if one of their franchisees falls victim to a breach.  Depending on the level of media attention the breach garners, one for a store in downtown Philadelphia has the potential to negatively affect the brand – and, arguably, sales— across the state, regionally or even nationally. 

A PCI compliance program for franchisees could also help make the Self-Assessment Questionnaire (PCI SAQ) process easier.  While this might not be the case for every franchise, some franchisors can elect to answer the SAQ on behalf of all of their franchisees.  This would only be the option if every franchisee used the same software, card swiper and payment processor and comes with the possible drawback that if one franchise location suffers a data breach, then every location might be impacted negatively.  

Stakeholders in franchisors will ultimately need to weigh out their options when it comes to PCI compliance, of course.  But one thing is for sure: in today’s climate where high profile breaches are making national headlines, a well-thought out strategy is a must. 

MasterCard PCI Compliance

We’ve blogged recently about the evolutionary component of PCI compliance, of how PCI compliance is an ongoing, adaptive, process rather than a simple checklist.

For more proof of this, we present MasterCard’s most recent changes to its PCI DSS requirements.  As changes are made by credit card companies, we are reminded that adaptations by card issuers, processors, and merchants are necessary. 

The first change MasterCard announced was a change to the December 31, 2010 deadline for Level 2 merchants to have an onsite QSA assessment to six months later, June 30, 2011.

Effective June 30, 2011 MasterCard PCI compliance will also subject merchants to new PCI DSS requirements.  Those changes break down, depending on merchant level, as follows:

Level 1 merchants will no longer be required to contract a Qualified Security Assessor (QSA) to submit their Reports on Compliance (ROC).  Instead, level 1 merchants, provided that their internal auditor is certified effective June 30, 2011, will be permitted to submit their own ROC.  Certification for internal auditors will be overseen by the PCI Security Standards Council (PCI SSC), with PCI SSC training for certification beginning sometime after January 15, 2010.

Similarly, level 2 merchants will no longer be required to complete an annual onsite assessment.  Instead, level 2 merchants may rely on internal resources to submit a Self Assessment Questionaire (SAQ), provided that their internal auditor is certified as of June 30, 2011.  As an alternative to submitting the SAQ, level 2 merchants may also opt to utilize a QSA for assessment purposes.  As with level 1 merchants, certification training dates will begin sometime after January 15, 2010.

In addition to the above MasterCard PCI DSS requirements changes, MasterCard PCI compliance will require that third-party payment applications be validated, by July 12, 2012, as fully compliant with the Payment Application Data Security Standards.  PA-DSS compliant payment applications will be comprehensively listed on the PCI SSC website. Visa’s PA-DSS deadline, however, is July 1, 2010 so software providers still need to be cognizant of this looming compliance deadline. 

We have integrated the above changes into our past post regarding PCI Compliance Deadlines.

Related Blog Posts:

MasterCard Toughens Stance on PCI Compliance

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.

PCI Compliance & Data Security Around The Web

Looking around the web this month, we see that yet another hacking operation has resulted in the arrest and indictment of four men on charges of computer fraud and aggravated identity theft.  The men are accused of stealing more than $9 Million from ATMs in a matter of only hours last November.  The breach involved more than 2,100 ATMs globally and ended when the four men were arrested overseas, where they remain detained.  The four have been indicted by a grand jury in the U.S. District Court for the Northern District of Georgia.

Of course, data breaches seem to make big news, but the reality is that there are far more data breaches than are widely reported.  Looking at A Chronology of Data Breaches (hat tip - Application Security, Inc.), we see that the number of data breaches is, in fact, staggering.  While not all of those data breaches are related to payment cards or financial information, it is still a frightening number.  Perhaps the Federal Data Breach Legislation currently making its way through Congress will help. 

As we’ve discussed here before, PCI compliance alone isn’t sufficient.  In order to do more than just raise the bar, PCI compliance, vigilance, and a willingness to adapt to new threats helps to ensure that merchants, software vendors, and payment processors are as secure as possible. Martin McKeay makes this point in his Willingness to Do Anything post (great analogy in there).

With potential payment innovations on the horizon, and others being unveiled, the future of the payment space clearly involves ongoing evolution. 

Tokenization And PCI Compliance

In recent months, as the PCI Security Standards Council has continued to weigh the merits of what they have deemed “emerging technologies,” two terms have been highlighted most frequently. 

The first is end to end encryption, which we’ve written at length about here and here.  The other is tokenization.  As we mentioned in a recent post, these two solutions have quickly become the favorites among all other emerging technologies.

Tokenization is an attempt to mitigate the risks inherent in storing credit card data.  In the same way that end to end encryption helps to protect data in transit, tokenization helps to protect data at rest.  With data in transit is increasingly targeted by nefarious hackers (and making big headlines), it is easy to overlook the fact that data at rest can be equally prone to theft.

As a process, tokenization replaces credit card data with a unique "token" that acts as a reference pointer to that credit card data.  Using this logic, a credit card transaction sends this reference pointer token along the payment chain.  At the processing end of the payment chain, the token is verified and the transaction processed, all without having exposed any sensitive cardholder data to the various networks along the payment chain.  And because tokens are produced for accounts, rather than for specific transactions, stored tokens can be effectively used for scheduled automatic payments as well.

Because the merchant uses a “token,” rather than real credit card data, and relies on the payment processor to assign that token (and to transmit and/or store card data), merchants relying on tokenization decrease their “scope” relative to PCI compliance, transferring the onus of the most critical aspects of PCI compliance to the payment processor.     

Tokenization eliminates the need for actual credit card data to be stored or transmitted by the merchant and, in many cases, allows for an easier PCI SAQ process.  And with some payment solutions offering both tokenization and end to end encryption, the result is an integrated solution that protects data both in transit and at rest.  

Related Posts and Pages:

End-to-End Encryrption Emerges a Winner from PCI SSC Meeting

Tokenization

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

How to Become PCI Compliant

By now you have heard about PCI compliance and are vaguely familiar with how it may apply to your business. So now what?

We’ve created this two-part article to clearly outline the steps merchants and independent software vendors must complete in order to become PCI compliant (PCI DSS and PA-DSS compliant, respectively).  We hope it guides you through this process clearly.  

This week, we’ll focus on how merchants become PCI compliant:

Merchants

For starters, get familiar with the compliance standard that applies to you: the Payment Card Industry Data Security Standard (PCI DSS).  The PCI DSS requirements are broken down into six different categories:

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software
Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Assign a unique ID to each person with computer access
Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security

The next step is to figure out your PCI compliance level.  Merchants fall under four categories of PCI compliance, depending on the number of transactions they process each year, and whether those transactions are performed from a brick and mortar location or over the Internet. Remember: all merchants that process credit cards—whether small or large—must be PCI compliant. 

Now here is where PCI compliance for merchants can get a bit tricky: each payment card brand (Visa, MasterCard, etc.) has their own requirements for PCI 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 give you a general idea of what you need to do as a merchant, here are Visa’s PCI requirements for merchants:

Level 1 Merchants

- Annual Report on Compliance (ROC) by a Qualified Security Assessor (QSA)
- Quarterly network scan by Approved Scan Vendor (ASV)
- Attestation of Compliance Form

Level 2 and 3 Merchants

- Annual Self-Assessment Questionnaire (SAQ)
- Quarterly network scan by ASV
- Attestation of Compliance Form

Level 4 merchants

 - Annual SAQ recommended
- Quarterly network scan by ASV if applicable
- Compliance validation requirements set by acquirer

Some resources to help you complete these requirements:

•    List of approved QSAs
•    List of approved ASVs
•    Instructions on how to complete the SAQ
•    PCI Compliance Deadline List, including links to each payment brands’ PCI compliance sites
•    Article on how businesses that should complete the SAQ D can opt for a shortened SAQ

Depending on your compliance level, complete the appropriate requirements (above).  Then for each payment card brand you accept, check the site to see what kind of reporting you have to supply each brand. 

Next week we will post an article on how ISVs become PA-DSS compliant.  Sign up for our email updates in the top right corner or to the RSS feed to be sure you don't miss it!

Related Posts and Pages:

PCI Compliance Reflects a Moment in Time

PCI Compliance for Franchisors

Are you a PCI Compliance Guru?

PCI Compliance Deadline List

Remote Credit Card Storage Facilitates PCI Compliance

PCI Compliance Costs

PCI DSS Compliance for Merchants

PCI Compliance: A Moment In Time

When it comes to PCI compliance, merchants and software vendors alike often make the mistake of viewing their compliance as a “checklist” rather than an ongoing process.  Too many people assume that PCI compliance is achieved once.  In reality, however, it is maintained, through vigilant adaptation to both PCI requirements and evolving security threats. 

A closer look at PCI DSS requirements should make it quite clear that compliance is an ongoing exercise.  For example, requirement 1 reads, “Install and maintain a firewall configuration to protect cardholder data.”  Requirement 5 mandates that you “Use and regularly update anti-virus software.”  Requirement 6 states that you “Develop and maintain secure systems and applications.”  Requirement 11 implores that you “Regularly test security systems and processes.”  And, of course, Requirement 12 states that you must “Maintain a policy that addresses information security.”

Clearly, five of the twelve PCI requirements explicitly mention either maintaining or updating, which should make it clear to all paying attention that there is no finality to PCI compliance.  

In fact, any proclamation of “PCI compliance” is best viewed as a snapshot of compliance at a specific time.  While merchants and software vendors are able to use a variety of means to test compliance at any given date, the truth remains that ongoing compliance requires both vigilance and, often, quarterly and yearly compliance assessments.   

Merchants and software vendors must ensure that their processes, or their applications as the case may be, are PCI compliant.    But how does one know if they are PCI compliant?  What is PCI compliant?  Well, the answer to those questions is slightly more complicated that it might seem.

Assuming that you have a good understanding of PCI compliance basics, and that you’ve moved beyond the “checklist” mentality, verifying your compliance involves understanding the ongoing nature of PCI compliance.  At its root, PCI compliance is about securing data and, by that process, protecting cardholders/customers.  For PCI standards to be effective, periodic re-evaluation and adaptation is imperative.

People sometimes forget that PCI compliance requirements apply to all “system components,” and that ongoing assessments, on both a quarterly and yearly basis, are mandatory for most merchants.  This means, of course, that any change in hardware or software within your network must meet PCI requirements on an ongoing basis.

PCI compliance is dynamic, requiring ongoing adaptation.  PCI compliance starts with a set of 12 basic requirements, it continues with vigilance and adaptation, and it ends with….well, it doesn’t end. 

Related Posts and Pages:

How to Become PCI Compliant

PA-DSS Implementation

PCI DSS Compliance for Merchants

The Present and Future of PCI Compliance

Looking around the internet this week…

Chris McClean, at the Forrester Blog for Security and Risk Professionals, suggests that in the future PCI compliance audits, and the auditors who perform them, will “be set under the most finely tuned of microscopes to be examined for accuracy and thoroughness.” 

Despite such increasing scrutiny, it’s unlikely that the human element of data security will ever disappear entirely, even if people do stop, but for one example, disabling personal firewalls. 

Data security, it would seem, isn’t important to nearly enough people, with the notable exception of CPAs, who place it at the top of their list.   As with anything, though, prioritization is a relative concept, and “data classification” (and PCI compliance) often isn’t prioritized the way it should be.

Perhaps if people better understood the “enormity of the threat,” (hat tip – Database Security 3.0) and the need for prioritizing internal controls, they could ease the “struggles” of the credit card industry in keeping data secure. 

The future of the payment and data security industries could include a variety of partial solutions, from biometric-based security to SMS-based messaging.  Regardless of what the future may portend, however, the tools of the present (PCI compliance coupled with strict internal controls) are the best way to keep your, and your customers’ data secure.