Background – PCI DSS: A Practical Guide to implementing and maintaining compliance, Third Edition


What is PCI?

In 2001, VISA and MasterCard each instigated basic levels of credit card security compliance programs, in which both retailers (known as merchants), banks and entities that provided cardholder authentication and authorisation services (known as service providers) were required to demonstrate compliance.

Visa had created CISP (Cardholder Information Security Programme) and MasterCard had created SDP (Site Data Protection). And each security standard placed a heavy burden on both merchants and service providers; as they had to comply with several different programs. Fortunately, by 2004 VISA and MasterCard had set up a joint data security standard known as the Payment Card Industry (PCI) Data Security Standard (DSS), which incorporated both the CISP and SDP requirements, and ensured merchants and service providers had only one security standard in which to demonstrate compliance.

By 2006, the PCI DSS had further evolved and included input from other credit card providers (JCB International, AMEX and Discovery), this agreement culminated in the formulation of the PCI Security Standards Council (PCI SSC). This council was then given the responsibility for the development, management, education, and awareness of PCI DSS and other related standards.


Adherence to the Standard may require (depending upon the quantity of cardholder data being stored, transmitted, accessed), specific compliance certification by PCI SSC sanctioned Approved Scanning Vendors (ASVs), which provide periodic vulnerability scanning of Internet facing systems, as well as Qualified Security Assessors (QSAs), which validate adherence to the PCI DSS to provide confidence that cardholder information is adequately protected.

In addition to PCI DSS, the Security Standards Council defines the Payment Application – Data Security Standard (PA-DSS). This standard allows vendors, manufactures and entities which develop payment processing applications and physical PIN Entry Devices (PED), to adhere to a standardised device security requirement, this standard also incorporates how the device will be tested (methodology) and the approval processes for manufacturers of Personal Identification Number (PIN) devices.

The PCI Security Standards Council first released version 1.1 of the PCI Standard, and then updated the Standard to version 1.2 in October 2008. This was further updated to 1.2.1 in July 2009, and version 2 was released in October 2010. Since its inception, it has become the ‘de-facto’ security standard within the card industry for both merchant6 and service provider.7

The purpose of PCI DSS is to ensure that sensitive cardholder data is always secure and the Standard comprises six high-level objectives, broken down further into twelve individual (mandatory) requirements:

  • 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 programme.
    • 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.

However, while the newly-established PCI Security Standards Council manages the underlying Data Security Standard, compliance requirements are set independently by individual payment card brands. While requirements vary between card networks, MasterCard’s Site Data Protection Plan and Visa’s Cardholder Information Security Programme are all representative. They stipulate separate compliance validation requirements for merchants and service providers, which vary depending on the size of the entity and its transaction/business throughput.

Summary of changes to latest version of PCI DSS

As you can imagine, the Standard is maturing and with that comes greater clarity and more specific direction on issues relating to ‘how to comply’ with the Standard.

Most of the changes pertain to clarification and in some cases ‘more obvious’ stipulations i.e. ‘unprotected PANs should not be sent using end-user messaging technologies such as e-mail and instant messaging’. Overall, more definition around ‘testing procedures’ and the use of other best practice sources, such as SANS CWE, CERT and, of course, OWASP, have been made.

The PCI Standards Council have also replaced ‘employee’ with ‘onsite personnel’ which is useful in our multi-regulatory environments. ‘Company’ has now been replaced with ‘entity’, thus I have changed all references to ‘company and organisation’ in the book to reflect this.

So, from these few examples you can see most of the changes were either clarification of words, technologies, phrases and examples, all of which have progressed since the Standard’s last publication.

Note: The ranking of vulnerabilities, as defined in Requirement 6.2.a, is considered a best practice until 30 June 2012, after which it becomes a requirement.

Note: Updated note regarding use of WEP as of 30 June 2010.

Top Ten myths about PCI

It is worth remembering at this stage that PCI DSS specifies 12 requirements entailing many security technologies and robust business (operating) processes; most of these reflect common best practice for securing sensitive information, but some also specify very stringent requirements that need to be met and compliance demonstrated.

The potential scope of your compliant cardholder data environment may seem daunting – especially for smaller merchants who have little or immature, existing security processes, or entities that don’t have endless amounts of IT professionals who can help guide them through what is required and what is not.

To complicate matters, some vendors, who sell security products or services, market their products in a broader context than just the PCI DSS requirements. This can make the process of becoming PCI compliant confusing; add this with the cost associated with compliance, and you end up believing many of the stories you hear about PCI. Thus, myths grow and can become mind-boggling if you don’t seek some clarity around terminology and applicability. Once again, the PCI Security Standards Council has come to the rescue in order to dispel some of these myths by preparing the top ten common myths about PCI DSS.

Myth 1 – One vendor and product will make us compliant

Many vendors offer an array of software and services for PCI compliance. No single vendor or product, however, fully addresses all 12 requirements of PCI DSS. When marketing focuses on one product’s capabilities and excludes positioning these with other requirements of PCI DSS, the resulting perception of a ‘silver bullet’ might lead some to believe that the point product provides ‘compliance’, when it’s really implementing just one or a few pieces of the Standard. The PCI Security Standards Council urges merchants and processors to avoid focusing on point products for PCI security and compliance. Instead of relying on a single product or vendor, you should implement a holistic security strategy that focuses on the ‘big picture’ related to the intent of PCI DSS requirements.

Myth 2 – Outsourcing card processing makes us compliant

Outsourcing simplifies payment card processing but does not provide automatic compliance. Don’t forget to address policies and procedures for cardholder transactions and data processing. Your business must protect cardholder data when you receive it, and process charge backs and refunds. You must also ensure that providers’ applications and card payment terminals comply with respective PCI standards and do not store sensitive cardholder data. You should request a certificate of compliance annually from providers.

Myth 3 – PCI compliance is an IT project

The IT staff implements technical and operational aspects of PCI-related systems, but compliance to the payment brand’s programs is much more than a ‘project’ with a beginning and end – it’s an ongoing process of assessment, remediation and reporting. PCI compliance is a business issue that is best addressed by a multi-disciplinary team. The risks of compromise are financial and reputational, so they affect the whole entity. Be sure your business addresses policies and procedures as they apply to the entire card payment acceptance and processing workflow.

Myth 4 – PCI will make us secure

Successful completion of a system scan or assessment for PCI is but a snapshot in time. Security exploits are non-stop and get stronger every day, which is why PCI compliance efforts must be a continuous process of assessment and remediation to ensure safety of cardholder data.

Myth 5 – PCI is unreasonable; it requires too much

Most aspects of the PCI DSS are already a common best practice for security. The Standard also permits the option using compensating controls to meet some requirements. The Standard provides significant detail, which benefits merchants and processors by not leaving them to wonder, ‘Where do I go from here?’. This scope and flexibility leads some to view PCI DSS as an effective standard for securing all sensitive information.

Myth 6 – PCI requires us to hire a Qualified Security Assessor

Because most large merchants have complex IT environments, many hire a QSA to glean their specialised value for on-site security assessments required by PCI DSS. The QSA also makes it easier to develop and get approval for a compensating control. However, PCI DSS provides the option of doing an internal assessment with an officer sign-off if your acquirer and/or merchant bank agrees. Mid-sized and smaller merchants may use the Self-Assessment Questionnaire found on the PCI SSC website to assess themselves.

Myth 7 – We don’t take enough credit cards to be compliant

PCI compliance is required for any business that accepts payment cards – even if the quantity of transactions is just one.

Myth 8 – We completed a SAQ so we’re compliant

Technically, this is true for merchants who are not required to do on-site assessments for PCI DSS compliance – for that particular moment in time when the Self-Assessment Questionnaire and associated vulnerability scan (if applicable) is completed. After that moment, only a postbreach forensic analysis can prove PCI compliance. But a bad system change can make you non-compliant in an instant. True security of cardholder data requires non-stop assessment and remediation to ensure that likelihood of a breach is kept as low as possible.

Myth 9 – PCI makes us store cardholder data

Both PCI DSS and the payment card brands strongly discourage storage of cardholder data by merchants and processors. There is no need, nor is it allowed, to store data from the magnetic stripe on the back of a payment card. If merchants or processors have a business reason to store front-card information, such as name and account number, PCI DSS requires this data to be encrypted or made otherwise unreadable.

Myth 10 – PCI is too hard

Understanding and implementing the 12 requirements of PCI DSS can seem daunting, especially for merchants without security or a large IT department. However, PCI DSS mostly calls for good, basic security. Even if there was no requirement for PCI compliance, the best practices for security contained in the Standard are steps that every business would want to take anyway to protect sensitive data and continuity of operations. There are many products and services available to help meet the requirements for security – and PCI compliance. When people say PCI is too hard, many really mean to say compliance is not cheap. The business risks and ultimate costs of non-compliance, however, can vastly exceed implementing PCI DSS, such as fines, legal fees, decreases in stock equity and, especially, lost business. Implementing PCI DSS should be part of a sound, basic enterprise security strategy, which requires making this activity part of your ongoing business plan and budget.

Why PCI?

Ensuring compliance with the PCI Standard is important for a number of reasons (listed below are just a few examples).

The first and perhaps the most significant reason to comply with PCI is because you have to. That is if your entity stores, processes, or transmits primary account numbers or data (PAN) i.e. credit card numbers, then your entity falls under PCI contractual requirements. So, despite PCI not being law (although a number of US states are making PCI legally binding), it is enforceable by the credit card brands through contractual penalties or sanctions; this could include revocation of the entity’s right to accept or process credit card transactions.

These contracted and mandated security requirements apply to all system components, which are defined ‘as any network component, server, or application that is included in or connected to the cardholder data environment’ – this typically includes a large amount of IT equipment within a target environment (see Chapter 2: Step 2 – Determine the Scope).

To add clarity, according to PCI DSS, handling and protection requirements are specified and must be handled as shown in Figure 1:

Figure 1: PCI handling and protection requirements

*These data elements must be protected if stored in conjunction with the PAN. This protection must be consistent with PCI DSS requirements for general protection of the cardholder environment. Additionally, other legislation (for example, related to consumer personal data protection, privacy, identity theft, or data security) may require specific protection of this data or proper disclosure of an entity's practices if consumer-related personal data is being collected during the course of business. PCI DSS; however, does not apply if PANs are not stored, processed, or transmitted.

** Sensitive authentication data must not be stored subsequent to authorisation (even if encrypted).

Although Figure 1 stipulates which data entities can and cannot store, your entity should carefully consider whether or not it actually needs to store cardholder data in the first place i.e. a merchant may consider outsourcing the credit card payment process to a merchant hosting entity or payment provider (a service provider).

The second and perhaps the more fundamental reason as to why PCI was introduced in the first place was to protect ‘us’ (the ‘consumer’), merchants and service providers from a variety of risks or ‘threats’.

There are several types of threats that plague payment networks and according to the FBI, financial fraud is the second-largest category of hacking events on the Internet today. To support this, Gartner estimates that 20-30% of Global 1000 entities suffer exposure due to privacy mismanagement. The costs to recover from these mistakes could range from $5-20 million per entity.

What are the different types of threats (or vulnerabilities)?

The threat and vulnerability landscape* facing our entities is in a constant state of flux, with new threat types emerging and existing threats becoming ever more sophisticated. At first sight, it might be fair to say there is nothing ground breaking in this observation, as all security and IT professionals have lived with this situation for decades, but how vulnerable your environment is to those threats and what time difference between the threats becoming known (i.e. CERT) and the response (i.e. patch) required to fix them has become minimal. Such threats are known as ‘Zero day attacks’ and are now the threat of every entity connected using a computer.

* Note: The ranking of vulnerabilities (threats) as defined in Requirement 6.2.a is considered a best practice until June 30, 2012, after which it becomes a requirement.

But we would not forget that many of the macro-environmental factors, such as political, legal, economic, socio-cultural and technical, that often go unnoticed, have greater significance for the types of threat that challenge information security and IT professionals daily.

These factors range from the well-publicised, such as the rise in incidents related to organised crime and increasing signs of internal misuse of information by employees concerned with job security, to the less obvious, such as entities outsourcing critical business services to entities that can help reduce costs, but which may not always be able to provide the level of protection expected.

The question of what actions entities should take, requires an approach that can flex with this dynamic threat landscape whilst maintaining value to the business. There is no silver bullet (and never will be) to selecting appropriate controls to mitigate all information security (and PCI) related threat types, but there are key areas of focus that entities need to consider – here are just a few examples:

Threat type 1: Information theft and leakage

The risk of cardholder data being stolen from unsecured databases by individuals or criminal entities is rampant. The US Federal Trade Commission estimates 27 million Americans had their identities compromised between 2000 and 2005.

Threat type 2: Brute force attack

This is the way hackers leverage computing power to breach security and in this case access cardholder data. Only real-time monitoring solutions can help quickly identify attacks and block them before any real damage occurs and another major credit card breach is announced.

Threat type 3: Insider breech

Recent statistical reports indicate that most security breaches are internal (as much as 70%), as staff on the inside are often privy to vast amounts of data, some of which could be cardholder data.

Threat type 4: Process and procedure control failures

Well-established policies and procedures are sometimes ignored in the normal course of business, such examples might include when sensitive data is taken home to be worked upon, or when data is not transferred following the correct procedures – a recent example being the UK HM Revenue and Customs transferring confidential data files from one site to another UK government department, sent on an unencrypted CD, and consequently lost in the post.

Threat type 5: Identity theft

Trying to protect against identity theft is one of the biggest challenges facing today’s society, it is all too easy to obtain (fraudulently) someone else’s information to be used against an unknowledgeable victim.

Threat type 6: Operating failures

The risk to some entities is often surrounding data leaving the site, such as back-up data, or this can simply be a lack of concentration that can quickly become the cause of catastrophic data loss e.g. back-up to wrong file server.

Unfortunately, should any of these threat types be exploited, not only do these security breaches put consumers at risk, they have serious consequences for the entities affected. According to Gartner, 42% of security related complaints involve credit card fraud. For each case of credit card fraud, the average cost to entities is £8,800 ($15,000), and IT departments spend an average of 175 hours on remediation after an incident. Additionally, reputational damage results in dwindling consumer trust and therefore can affect the bottom line.

To make matters worse, the negative publicity that accompanies any breach in security can be very damaging to an entity’s image and share value. If you operate a business in California, you are required to disclose any security breach publicly under state regulation CA-1386, and as you can imagine, being forced to report publicly that credit card numbers have been stolen is one sure way to lose customers.

In fact, further studies from Forrester show that breaches in data security can result in the direct loss of up to 20 per cent of an existing customer base. This represents a significant figure to any size entity, and will end up hurting the bottom line and/or shareholder confidence.

The final reason for ensuring compliance with the PCI Standard is to avoid fines and additional regulatory scrutiny. Failure to comply with the PCI Data Security Standard can result in fines that range from £100,000 to £300,000 ($500,000) per security breach, and in the States, the US Government can levy additional fines that can range from $5 million to $20 million.

To make matters worse, once an entity has failed a PCI audit, it is given an elevated risk status and becomes subject to more extensive PCI audits. The ultimate penalty can be a suspension of status and the loss of the ability to accept and process credit cards.

Just from these few examples, it is easier to understand and appreciate why the credit card brands got together to formulate the Payment Card Industry Data Security Standard. The appropriate treatment and use of confidential data has long been the plight of many security officers around the world, at last, the PCI has taken the first proactive (and bold) step to help regulate and constrain the loss of both consumer and business confidence and help reduce the level of losses being incurred by both business and the consumer.

How does PCI compliance work?

Unlike legal and regulatory compliance, such as the US Sarbanes-Oxley Act 2002 (monitored and enforced by the US Security and Exchange Commission – SEC), or the UK Data Protection Act 1998 (monitored and enforced by the UK Information Commissioner’s Office) PCI is a ‘contractual’ requirement between the merchants and service providers, including hosting providers.8

At a fundamental level, any entity that comes into contact with credit card information must be in compliance with the PCI Data Security Standard. So there are no differing requirements for small, medium or large entities e.g. shops, clubs, online betting agencies, hotels, holiday entities, insurance entities, etc.

There are however, varying levels of compliance proof or validation required; each requiring different and very specific requirements for merchants and service providers, as well as various levels based on the number of transactions processed annually.

However, it is important to note that despite full compliance being mandatory, compliance requirements are set independently, by individual payment card brands i.e. Visa, MasterCard and Amex. Despite these potential differences, the merchant and service provider still have to demonstrate full compliance in order to process, store and undertake credit card transactions, so in the end it becomes a simple choice of if the merchant and service provider want to provide the facility of using a credit card, then they have to comply and demonstrate compliance with the PCI Standard at all times.

How is PCI compliance demonstrated?

In order to fully comply with the PCI Standard, every entity that the Standard applies to must implement all of the controls9 (unless existing controls can be applied – also known as ‘compensating controls’) to the target environment and annually audit the effectiveness of the controls in place.

This requires the merchant and service provider to ensure that a formal validation and compliance (audit) structure is in place; and that validation requirements (including self-audits and vulnerability scans) are undertaken on a regular basis and results are fed into an information security management system10 for ongoing review and improvement (e.g. PCI validation requirements are based on the number of transactions – the more transactions handled, the greater the quantity and detail of audits that are required).

Participating entities can be barred from processing credit card transactions, higher processing fees can be applied, and in the event of a serious security breach, fines of up to £300,000 ($500,000) can be levied for each instance of non-compliance. Since compliance validation requirements and enforcement measures are subject to change, merchants and service providers need to closely monitor the requirements of all card networks in which they participate.

There are three types of validation requirements; these include:

1   Annual on-site security audits – MasterCard and Visa require the largest merchants (Level 1) and service providers (Levels 1 and 2) to have a yearly on-site compliance assessment performed by a certified third-party auditor, which is similar to an ISO27001 certification programme.

2   Quarterly external network scans – All merchants and service providers are required to have external network security scans performed quarterly by a certified third-party vendor. Scan requirements11 are rigorous: all 65,535 ports must be scanned, all vulnerabilities detected of Level 3–5 severity must be remedied, and two reports must be issued – a technical report that details all vulnerabilities detected with solutions for remediation, and an executive summary report with a PCI approved compliance statement suitable for submission to acquiring banks for validation.

3   Self-Assessment Questionnaires – In lieu of an on-site audit, smaller merchants and service providers (Levels 2, 3 & 4) are required to complete a self-assessment questionnaire (SAQ) to document their security status. This is similar to ISO27001, as there should be a formal audit structure of scheduled audits that enables early identification of ‘weak spots’ and should feed into an existing ‘enterprise risk structure’ that enables the entity to fulfil other contractual, legal and regulatory requirements (regulatory requirements such as Basel II, SOX, Corporate Governance – Combined Code, US SEC, the UK FSA regulations and the EU Directive 95, Safe Habor, HIPPA and Data Protection Act 1998.

Under quarterly external network scans (heading 2) there are a number of additional requirements, that should be noted. In order to demonstrate compliance, the quarterly external scan must not contain high level vulnerabilities. The scan report must not contain any vulnerabilities that indicate features or configurations that are a PCI DSS violation. If these exist, the Approved Scanning Vendor (ASV) must consult with the entity to determine if these are, in fact, PCI DSS violations and therefore warrant a noncompliant scan report.

High-level vulnerabilities are designated as Level 3, 4, or 5 in Figure 2.

Figure 2 – Vulnerability severity levels






Trojan Horses; file read and writes exploit; remote command execution.



Potential Trojan Horses; file read exploit.



Limited exploit of read; directory browsing; DoS.



Sensitive configuration information can be obtained by hackers.



Information can be obtained by hackers on configuration.

  • Validation Enforcement – While non-compliance penalties also vary among major credit card networks, they can be substantial. Participating entities can be barred from processing credit card transactions, higher processing fees can be applied and in the event of a serious security breach, fines of up to £300,000 or $500,000 can be levied for each instance of non-compliance.

Since compliance validation requirements and enforcement measures are subject to change, merchants and service providers should closely monitor the requirements of all card networks in which they participate.

Validation requirements

Implementing the compliance requirements is only the start of the process. PCI contains a set of validation requirements that are required to ensure that entities continue to meet the PCI Standard on an ongoing basis. The validation steps for the PCI DSS are described in Figure 3.

Figure 3 – Validation table


Validation action

Validation by


Annual on-site PCI data security assessment and quarterly network scan

Qualified security assessor or internal auditor if signed by officer of the entity


Annual PCI self-assessment questionnaire and quarterly network scan

Approved scanning vendor Merchant


Annual PCI self-assessment questionnaire and quarterly network scan

Approved scanning vendor Merchant


Annual PCI self-assessment questionnaire and quarterly network scan

Approved scanning vendor Merchant

One important thing to note is that PCI have created security audit procedures (a tick box/checklist document) that provides information on the requirements for technical PCI compliance and also provides details on the expected content that should form part of the annual submission report – the ‘Report on Compliance’ (ROC) or ‘Executive Summary Report’.

To assist the merchant or service provider in this compliance process an ‘accreditation’ scheme has been established. This has been designed to allow pre-approved PCI security and audit entities to offer ‘Qualified Security Assessor’ (i.e. auditor of system) services or Approved Security Vendors (i.e. penetration testers), or both. These services will appeal to the many merchants and service providers that need to comply on all levels with PCI DSS, but ultimately, every merchant or service provider will have the option of whom they choose to work with – in order to verify they meet all the technical requirements of PCI DSS.

Figure 4 – PCI DSS validation enforcement table

For service providers, there are three levels of compliance. Level 1 encompasses members and non-members of all payment gateways. Level 2 is made up of service providers who process more than one million transactions annually, and Level 3 includes any service providers who are not in Level 1 and who do less than one million transactions in any given year. Therefore, audits for PCI compliance vary depending on a merchant’s or service provider’s level. A merchant that processes more than six million Visa transactions each year is assigned to ‘Level 1’, as is an entity that has experienced a security breach. Those at Level 1 are subject to significantly higher levels of scrutiny than merchants at Level 2, 3, or 4.

While PCI DSS non-compliance penalties also vary among major credit card brands (Amex, Visa, MasterCard), they can be substantial and, perhaps more worryingly, they can represent a major embarrassment and lead to reputation damage (which is difficult to quantify).

What is the role of the QSA?

Entities that validate an entity’s adherence to PCI DSS requirements are known as Qualified Security Assessors (QSAs). Validation of these requirements by independent and qualified security entities is important to the effectiveness of PCI DSS. The quality, reliability, and consistency of a QSA’s work provides confidence that cardholder data is adequately protected.

PCI DSS requirements, when implemented appropriately, provide a well-aimed defence against data exposure and compromise. As a result, on-site PCI DSS assessments performed by QSAs have become increasingly critical in today’s complex online environment. The proficiency with which a QSA conducts an assessment can have a tremendous impact on the consistent and proper application of PCI measures and controls.

Each individual approved QSA will be trained by the PCI Security Standards Council regarding the underlying requirements of the PCI DSS and the evaluation of compensating controls for certain complex requirements and operating environments. QSAs will themselves determine whether a compensating control is sufficient, as they determine their recommendation of compliance to the various payment brands. Each individual payment brand will separately determine whether to accept the recommendation of compliance and whether a detailed review of the Report on Compliance (ROC) and compensating controls is warranted.

What is the role of the ASV?

Entities that validate adherence by performing vulnerability scans of Internet-facing environments of merchants and service providers are known as Approved Scanning Vendors (ASVs). The compliance tools applicable to Internet-facing systems include specific requirements for scans of merchants and service providers and periodic remote PCI scanning services of these entities by recognised scanning vendors. Validation of these requirements by independent and qualified security entities is important to ensure the effectiveness of PCI DSS. The quality, reliability, and consistency of an ASV’s work is essential to ensure the protection of cardholder data.

Publicly available documents on PCI DSS for Approved Scanning Vendors v212 provides guidance and requirements applicable to ASVs in the framework of the PCI DSS and associated payment brand data protection programmes. Security scanning entities interested in providing scan services in conjunction with the PCI programme, must comply with the requirements set in this document and must successfully complete the PCI security scanning vendor testing and approval process.

Getting started with PCI

Nearly every aspect of PCI needs to start by establishing a baseline,13 as each entity will need to understand where and if PCI is applicable; and what should be done to ensure compliance i.e. what the scope of the PCI target environment is.

As the security requirements of PCI extends to all system components that are connected to the cardholder data environment (scope), the scope of PCI compliance becomes extremely difficult to determine and therefore requires much effort and constant re-clarification.

Scoping the target environment is so critical that it should only be done by holding a series of scope workshops, in which senior management should be invited to contribute. The workshops also serve to better understand a holistic overview of the entire end-to-end business process, and thus, the scope is often not concluded, until completion of the gap analysis or risk analysis steps. Process mapping can also become a huge undertaking in itself, as understanding where the cardholder data traverses the network, infrastructure and file servers can easily become complex. Processes in themselves can also be complex, as often overlapping processes within a business are evident and yet all this needs to be understood up front to ensure adequate protection and eventual PCI compliance.

The gap analysis step can also be achieved by conducting a series of workshops or interviews. During which, the interviewer should seek to establish a thorough understanding of the level of compliance against existing policies, their supporting procedures and technical controls that have been employed (supporting evidence should be supplied). In addition, it is imperative that your entity can demonstrate it has identified all risks facing all its confidential data (and in this case – cardholder data) and how these risks have been analysed, addressed and/or mitigated i.e. accepted, transferred, avoided or treated – in line with PCI baseline (minimum recommend) controls.

The gap analysis can become very technical and detailed and therefore is recognised that sometimes, this level of analysis can be done more efficiently with the use of software automation tools.14 That said, this only works if the entity has the ability to identify and report on the entire IT environment/estate – no easy feat in itself.

Figure 5 – Sample of components that need to be reviewed during PCI gap analysis

Certain vendor software solutions can also help cover critical infrastructure components, from operating systems, to network devices and firewalls, mail servers, application enablers and directory services by automatically collecting15 hundreds of thousands of critical configuration settings needed to recover, secure, report on, and track infrastructure changes – all required under PCI.

Entities that can capture granular information about baseline variance and generate specific reports to demonstrate what is taking place in the environment have a distinct advantage over their peers. The consolidated change log report, for example, meets one of the key requirements of the PCI audit.

Much of this evidence provided by the interviewee, must then be further analysed, understood, reviewed and compared against PCI DSS (as the minimum baseline) culminating in the production of a PCI Gap Analysis Report. This report should detail where the scope of the PCI compliance requirement is (currently based on available information); and what can be done about any gaps found during the analysis (recommendations). This report should look to be an honest self-assessment of the entire (potential PCI) IT environment and include recommendations on how any policy, procedural and technical gaps can be filled by way of a roadmap and remediation plan (see Chapter 8: Step 8 – Remediation Planning).

Other related PCI Standards to take into consideration

Payment Application – Data Security Standard (PA-DSS)

One of the more demanding aspects of PCI is the requirement governing application security (Req.6.3), which mandates that you develop software applications based on industry best practice and incorporate information security throughout the software development lifecycle. Such techniques could include the possibility of using an ISO900116 based review process. Other alternatives include developing an approach to application development similar to those prescribed within TickIT,17 and/or the governance process defined in COBIT.

PA-DSS v2 Section 5 – Develop secure payment applications requires all web applications to be developed based upon secure coding guidelines, and covered the prevention of common coding flaws such as the OWASP Top Ten, SANS CWE Top 25, CERT Secure Coding. However, PA-DSS v2 now requires all software applications to be developed based on industry best practices and a secure software development lifecycle (including load and performance testing) and ultimately – good configuration management. This therefore becomes the challenge (if it isn’t already) of every IT operating environment. There simply is no easy way to avoid coding issues, other than to address, specify and test (and test again) the inputs and outputs to ensure a clean code at the very beginning of the design stage – see also ISO27001:2005 – Appendix A10.9.2 On-line Transactions.

It is also worth pointing out that PCI v2, requires all web facing applications to have either a code review and/or a web application firewall, which will be costly especially if it is not budgeted or planned for. Other relevant standards that are applicable include:

  • PIN Transaction Security (PTS) Point of Interaction (POI)
  • Modular Security Requirements - v3.0
  • Encrypting PIN Pad (EPP) Security Requirements - v2.1
  • POS PIN Entry Device Security Requirements - v2.1
  • Hardware Security Module (HSM) Security Requirements - v1.0
  • Unattended Payment Terminal (UPT) Security Requirements - v1.0.

Despite there not being accepted industry best practice, below are some of references which may help your entity in its secure software development lifecycle:

  • US Department of Homeland Security - Secure Software Development Life Cycle Processes18
  • The Trustworthy Computing Security Development Lifecycle19 (For Windows® applications – Microsoft have published The Security Development Lifecycle.)20
  • For Web applications – OWASP have published three ‘How to Guides’.21
  • For Java (and web) applications – Sun provide training.[81]22

Comment [81]: Check for more links?


PIN Transaction Security refers to the framework within PCI standards and requirements that deals with the evaluation and approval of payment security devices.

Security is a never-ending race against potential attackers. As a result, it is necessary to regularly review, update, and improve the security development lifecycle and application requirements used to evaluate PIN entry devices and hardware security modules, collectively referred to as ‘payment security devices’.

During 2009, the PCI Security Standards Council expanded its PIN Entry Device Security Requirements framework to cover two new types of devices: unattended payment terminals (UPTs) and hardware security modules (HSMs) under the PTS Standard.

Unattended payment terminals are an increasingly popular form of conducting payment transactions and are used in a variety of scenarios such as museum and concert ticketing, kiosks, automated fuel dispensers and car parking facilities. Hardware security modules are non-user facing devices used in PIN translation, payment card personalisation, data protection and e-commerce.

Both UPT and HSM hardware devices can now undergo a rigorous testing and approval process by Council labs to ensure they comply with the industry standards for securing sensitive cardholder account data at all points in the transaction process. The evaluation process includes the logical and physical security of each product. The Council will also provide a list of approved devices on its website, provide documentation and training for labs evaluating these devices and be the single source of information for device vendors and their customers

To gain approval by PCI Security Standards Council, PIN transaction security must now comply with the requirements and guidelines as specified and documented by the Council.

The PTS Security framework consists of the following manuals that contain the physical and logical security requirements for all payment security devices, as well as device management requirements for activity prior to initial key loading. The manuals listed below are specific to the particular payment security device approval class being evaluated, i.e. POS PED, HSM, UPT or EPP.

  • Payment Card Industry (PCI) POS PIN Entry Device Security Requirements.
  • Payment Card Industry (PCI) Encrypting PIN PAD (EPP) Security Requirements.
  • Payment Card Industry (PCI) Unattended Payment Terminal (UPT) Security Requirements.
  • Payment Card Industry (PCI) Hardware Security Module (HSM) Security Requirements.

For more information, or should you wish to understand this area of PCI compliance further, then please download the appropriate documents from the PCI Security Standards website:

Compensating controls – Using what you already have in place

This does not mean an entity can simply hide behind this get-out-of-jail ‘clause’ – it simply allows for any compensating controls i.e. controls that you already have in place on any of the 12 requirements, except for the storage of sensitive authentication data, BUT only if the control sufficiently mitigates the associated risk.23

Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a technical specification of a requirement, but has sufficiently mitigated the associated risk.

Therefore, you are required (on top of the risk analysis evidence) to provide and document the following: (see the publicly available documented example – PCI DSS Security Audit Procedures v2).24

1 Constraints precluding compliance with the original requirement.

2 Objective of requirement; objective met by control.

3 Risk – incurred by not using specified control.

4 Compensating control: how it meets objective; how it addresses any increased risk.

The effectiveness of a compensating control is dependent on the specifics of the environment in which the control is implemented, the surrounding security controls, and the configuration of the control. You should be aware that a particular compensating control will not be effective in all environments. Each compensating control must be thoroughly evaluated after implementation to ensure effectiveness.

An example of where a compensating control is often used can be found in Requirement 3.4 – Render Primary Account Number, at a minimum, unreadable anywhere it is stored.

For entities unable to render cardholder data unreadable (for example, by encryption) due to technical constraints or business limitations, compensating controls may be considered.

Entities that consider compensating controls for rendering cardholder data unreadable must understand the risk to the data posed by maintaining readable cardholder data. Generally, the controls must provide additional protection to mitigate any additional risk posed by maintaining readable cardholder data. The controls considered must be in addition to controls required in the PCI DSS, and must satisfy the ‘compensating controls’ definition in the PCI DSS Glossary.25

Compensating controls may consist of either a device or combination of devices, applications, and controls that meet all of the following conditions:

1 Provide additional segmentation/abstraction (for example, at the network-layer).

2 Provide ability to restrict access to cardholder data or databases based on the following criteria:

a. IP address/Mac address.

b. Application/service.

c. User accounts/groups.

d. Data type (packet filtering).

3 Restrict logical access to the database.

a. Control logical access to the database independent of Active Directory or Lightweight Directory Access Protocol (LDAP).

4 Prevent/detect common application or database attacks (for example, SQL injection).

Therefore, only entities that have undertaken risk analysis and have legitimate technological or documented business constraints can consider the use of compensating controls to achieve compliance.

A prioritised approach to compliance

The final consideration before getting started needs to be regarding a more prioritised approach to achieving PCI compliance.

The PCI Standards Council have come under pressure to help entities prioritise their approach to PCI, and as such, the table below provides six security milestones that will help merchants and other entities incrementally protect against the highest risk factors and escalating threats while on the road to PCI DSS compliance. The prioritised approach and its milestones are intended to provide an overview, which includes the following benefits:

  • A roadmap that an entity can use to address its risks in priority order.
  • A pragmatic approach that allows for ‘quick wins’.
  • Supports financial and operational planning.
  • Promotes objective and measurable progress indicators.
  • Helps promote consistency among Qualified Security Assessors.

The prioritised approach includes six milestones. The below summarises the high-level goals and intentions of each milestone:

Milestone 1

Remove sensitive authentication data and limit data retention. This milestone targets a key area of risk for entities that have been compromised. Remember – if sensitive authentication data and other cardholder data are not stored, the effects of a compromise will be greatly reduced. If you don’t need it, don’t store it.

Milestone 2

Protect the perimeter, internal, and wireless networks. This milestone targets controls for points of access to most compromises – the network or a wireless access point.

Milestone 3

Secure payment card applications. This milestone targets controls for applications, application processes, and application servers. Weaknesses in these areas offer easy prey for compromising systems and obtaining access to cardholder data.

Milestone 4

Monitor and control access to your systems. Controls for this milestone allow you to detect the who, what, when, and how concerning who is accessing your network and cardholder data environment.

Milestone 5

Protect stored cardholder data. For those entities that have analysed their business processes and determined that they must store Primary Account Numbers, Milestone Five targets key protections mechanisms for that stored data.

Milestone 6

Finalise remaining compliance efforts, and ensure all controls are in place. The intent of Milestone Six is to complete PCI DSS requirements and finalise all remaining related policies, procedures, and processes needed to protect the cardholder data environment.

Some strategic thoughts

It is well worth mentioning again that you’ll need to ensure that senior management are fully committed and behind implementing the PCI DSS requirements. Failure here will lead to project delays and potential embarrassing non-compliance, notwithstanding the implications for your entity’s reputation.

The same could be said for other legal and regulatory requirements – your entity will need to consider other compliance requirements that may affect you, such as: Sarbanes Oxley, Gramm-Leach-Bliley Act, Foreign Corrupt Practices Act of 1977, l, Basel II, Health Insurance Portability and Accountability Act (HIPAA), Markets in Financial Instruments Directive (MiFID), Data Protection Act 1998, Combined Code, Computer Misuse Act, Regulation of Investigatory Powers Act 2000 (RIPA), etc – all require a level of evidence that security and a system of internal controls (usually achieved through combination of risk, financial and IT Control mechanisms) are being effectively managed and applied within your entity.

Furthermore, being PCI compliant may keep you out of jail – as some US states, such as Minnesota, are enacting laws that use PCI DSS requirements to define what information can and cannot be stored within a given environment. This effectively means that PCI can be used in those states, as either criminal defence or non-compliance may be used against your entity as evidence. As much of the US legislation and regulation ends up here, it is worth considering how our UK and/or European governments could potentially use this to become future legislation.

Conceptually, compliance with ISO27001 involves establishing an Information Security Management System (ISMS) to support the defined critical business processes, and then making any necessary security improvements within this scope to comply with the Standard. Within the context of the PCI project, the primary focus will be to establish an Information Security Management System that can manage ongoing risk, irrespective of source or motive and ensure appropriate controls are in place to provide consistent assurance to both the entity’s entities and stakeholders.

It is also well worth considering that as PCI DSS applies to all system components that are in, or connected to, the cardholder data environment, reducing the size and complexity of that environment, may provide better security, achievable management, and limit the scope of your PCI compliance initiative. Whilst this may be non-trivial in some environments, it is usually well worth investigating (at the least) to see if your compliance requirements could be reduced to tolerable levels or, if outsourcing to a hosting provider should be seriously considered.

As previously mentioned, any legal, regulatory and/or contractual compliance requirements should be addressed not in isolation, but in unison with each other – ideally as part of an ongoing and operational ISMS. Each requirement may have its own objectives, but this usually boils down into the same few fundamentals – effective risk management, good logging and reporting, comprehensive monitoring and rigorous auditing.

Benefits of a combined approach to compliance

By combining the requirements of PCI DSS with the requirements of ISO27001 – Information Security Management Systems (ISMS) your overall defence mechanisms and internal control systems could provide significant business benefits and result in both PCI and ISO27001 compliance.

In addition, when combining PCI and ISO27001 audit steps, strategic business initiatives can achieve the information technology governance objectives as outlined in COSO,26 COBIT27 and ITIL.28 So, in effect, your entity could have implemented the prescribed procedures as outlined in PCI, whilst simultaneously achieving compliance with other regulatory requirements such as Sarbanes-Oxley or the Combined Code.

The obvious benefit of this integrated and holistic approach is that entities and corporations will be able to demonstrate that they have good internal controls over financial processes (US SEC and UK FSA requirements), but even more importantly, that they can help mitigate for information security threats before they become an incident.

Tip: In order to help your entity in this area of implementing a more holistic29 approach to compliance, there is an international course that can provide help. The objective of this course is to provide you with the necessary skills to implement a corporate Information Security Management System (ISMS) framework that is compliant with the requirements of ISO27002, UK Data Protection Act, EU Directive on Privacy, HIPAA Security, , GLBA, Sarbanes-Oxley Act (Security), FACT Act, PCI Data Security, California SB-1386, OSFI, PIPEDA, PIPA, Canadian Bill C-198 and meets certification requirements of ISO27001.

This combined or integrated approach may also result in significant cost-savings – in some cases it has actually resulted in entities having a PCI (ROC) audit completed as well as obtaining ISO27001 certification; with little or minimal costs added during the same time period of your PCI compliance implementation programme!

This very cost-effective approach provides true value, because not only are such forward-thinking entities able to meet PCI driven requirements, but they will also be able to meet international best practice requirement for Information Security Management – and at the end of the day they will end up with a very strong, comprehensive and robust information security management system.

As COBIT and COSO are internationally accepted IT governance frameworks, this combined approach could also save your entity time and money; and in the long-term, provide true value to your ‘defence in depth’ tactics by strengthening your overall security programme.

Other benefits include:

  • A confirmed effective and risk justified PCI compliance programme.
  • Effective COSO and corporate governance through a risk management framework that addresses information security, audit, legal and regulatory compliance.
  • Justified security controls based on a formal risk assessment.
  • Effective targeting of resources in the treatment of identified and related risks to PCI compliance.
  • Reduction in the overall cost of information assurance delivered at a higher level of assurance in a higher level of collaboration – reduced cost of audits.
  • Business focused and more appropriate policies and procedures.
  • Good security awareness and a wider sense of ownership with clearer security responsibilities and accountability.
  • Improved measurement of security control effectiveness through objective, independent assurance.
  • Senior management assurance that information security controls are both auditable and being audited effectively.
  • A single framework for many internal control initiatives.
  • Reduced operational risk.
  • Greater preparedness for emerging threats and vulnerabilities, whilst maximising the business opportunities from new technologies.
  • Increased business efficiency.
  • Closer integration of business continuity management, quality and information security initiatives to address business critical assets.
  • Information security, quality and risk assurance to stakeholders.

The approach of this book

Below is the nine-step programme necessary to build a sustainable PCI compliance framework:

  • Step 1 – Establishing the PCI project.
  • Step 2 – Determine the scope.
  • Step 3 – Review the information security policy.
  • Step 4 – Conduct gap analysis.
  • Step 5 – Conduct risk analysis.
  • Step 6 – Establish the baseline.
  • Step 7 – Auditing.
  • Step 8 – Remediation planning.
  • Step 9 – Maintaining and demonstrating compliance.


6 Merchant: Business entity that is directly involved in the processing, storage, transmission, and switching of transaction data and cardholder information or both.

7 Service provider: Business entity that is not a payment card brand member or a merchant directly involved in the processing, storage, transmission, and switching of transaction data and cardholder information or both. This also includes entities that provide services to merchants, services providers or members that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, intrusion detection software and other services, as well as hosting providers and other entities. Entities that only provide communication links without access to the application layer of the communication link, such as telecommunications entities, are excluded.

8 Hosting provider: Offer various services to merchants and other service providers. Services range from simple to complex; from shared space on a server to a whole range of ‘shopping cart’ options; from payment applications to connections to payment gateways and processors; and for hosting dedicated to just one customer per server.

9 Compensating controls: Unless risk justified and compensating controls can be applied in full.

10 Information security management system: For more information download ISO/IEC27001:2005 from or read the further information which is provided in this guide.

11 PCI scans: PCI security scans are scans conducted over the Internet by an Approved Scanning Vendor (ASV). PCI security scans are an indispensable tool to be used in conjunction with a vulnerability management programme. Scans help identify vulnerabilities and misconfigurations of websites, applications, and information technology (IT) infrastructures with Internet-facing Internet protocol (IP) addresses.

12 You can download this document from:

13 Baseline: A baseline in most circumstances is used to measure the normal environment against a set of predetermined ‘best practice’ standards. Think of it as a minimum level of security required for operating an IT data centre – you’ll need a building, electricity, water, floor capacity, environment controls, access controls, CCTV, etc. In PCI terms, this is what is required as a minimum level of security for handling, storing and transacting cardholder data.

14 Software (data identification) automation tools (also known as Data Leak Prevention – DLP_: Notwithstanding the need for conducting the policy, process and procedural gap analysis, it is worth considering an automated software solution as one of the ways to meet PCI compliance without a substantial investment of time and resources physically, as checking your IT estate can be achieved automatically (i.e. discovery tools) by using software automation and software compliance tools.

15 There are a large number of data automation collection tools, and some are extremely powerful, but can sometimes be difficult to configure.

16 ISO9001 provides a number of requirements which an organisation needs to fulfil if it is to achieve customer satisfaction through consistent products and services which meet customer expectations.

17 TickIT is about improving the quality of software and its application. COBIT For more information go to






23 Compensating controls: Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a technical specification of a requirement, but has sufficiently mitigated the associated risk.



26 COSO: Internal control – integrated framework to assist companies in ensuring the effectiveness of their financial, operational, and compliance-related internal controls.

27 COBIT: COBIT is an IT governance framework and supporting toolset that allows managers to bridge the gap between control requirements, technical issues and business risks.

28 ITIL: IT Infrastructure Library –ITIL is the only consistent and comprehensive documentation of best practice for IT service management

29 HISP: Holistic Information Security Practitioner course: