Chapter 4: Step 4 – Conduct Gap Analysis – PCI DSS: A Practical Guide to implementing and maintaining compliance, Third Edition


This activity is the information gathering and analysis part of the PCI project and relies on interviewing staff and assimilating information from existing policies, processes and supporting procedures and includes a technical review of systems, including:

  • Network components, such as firewalls, switches, routers, wireless access points, network appliances and other security appliances.
  • Servers, including: web, database, authentication, domain name service (DNS), mail, proxy, network time protocol (NTP).
  • Applications such as all purchased and custom/bespoke applications, internal and external (Web) applications.

Business process analysis and reviews must be conducted with security management and support resources, business personnel, and other key stakeholders at appropriate levels to ensure minimum disruption to key staff. This will assist in identifying the core IT systems in scope and ensure that the fundamental business requirements for the infrastructure are captured and reviewed.

Gap analysis objectives

The objective of the gap analysis is to gain an understanding of the operation of the IT target environment from a business perspective and how any policies and supporting procedures, particularly in relation to access, installation and connectivity, could result in access to confidential cardholder data.

Therefore, the information gathered must be analysed to:

  • Identify areas of compliance and non-compliance (based on PCI DSS and possibly ISO27001).
  • Identify the key processes that have yet to be defined under PCI DSS.
  • Identify the work that needs to be undertaken to achieve compliance with PCI DSS and prioritise accordingly.
  • Develop a prioritised work programme for gaining PCI compliance by addressing the key processes and groups of controls required to implement and operate the PCI compliance programme (with realistic and cost-effective solutions).
  • Highlight areas excluded from the review and why.
  • Produce a brief description or high-level drawing of network topology and controls.
  • Establish a list of individuals interviewed.
  • Establish a list of documentation reviewed.

At the same time, information regarding the approach adopted for security management can be gathered. Additional interviews may be required to gauge the overall level of PCI compliance and how the different departments implement common security management and technical standards across the user base. Such analysis should look to include how information is reported to an information security working group/forum and whether there are office based nominees responsible (i.e. security officer) for security and risk within a geographically diverse entity e.g. France, UK, US.

Gap analysis approach

A simple approach that has been used in the industry for years can be employed to ensure that the key aspects of PCI compliance are considered against each relevant objective and are controlled within the Data Security Standard. This methodology is based on the assertion that true compliance requires the following aspects to be fully addressed for each of the 200 plus controls:

The following approach will help to ensure the information gathering is fully objective, repeatable and complete.

R –

Is the person(s) who is Responsible for that aspect of delivery defined?

I –

Are risked based controls or PCI based controls Implemented effectively?

D –

Are the supporting procedures and policies Documented appropriately?

E –

Can Evidence of effective implementation be made available?

The gap analysis will therefore examine the health of your entity’s information security practices in all of the areas covered by PCI DSS, from the viewpoint of how they support the scope of the PCI and ultimately support the wider confidentially, integrity and availability requirements of your entity.

Some of the areas that need to be reviewed under the PCI gap analysis should include the following (not an exhaustive list) functions:

  • Third parties (from a technical and physical access perspective).
  • ISO9001 – to at least identify local functional gaps/requirements, establish and document necessary variants to high level horizontal business process.
  • Information, configuration and asset management – including classification, handling and control (COBIT, ITIL and PCI DSS requirement).
  • Communications and operations management.
  • Localised and remote access control.
  • Business continuity management and crisis management.
  • Legal and regulatory compliance.
  • Security incident management and reporting.
  • Virus and mobile code management.
  • Incident and problem management.
  • Configuration management.
  • Change control and change approval process.
  • Security awareness, education and training.
  • Personnel, HR and security vetting.
  • Physical and environmental security.
  • Systems development lifecycle and management.

Areas of compliance should be carefully documented such that the gap analysis report can be easily translated into a statement of applicability (SOA)33. This is particularly helpful, should your entity choose to demonstrate ISO27001 compliance at the same time.

PCI gap analysis reporting and security improvement plan

All gap analysis results and recommendations should be captured and presented in an information security improvement plan and should include the following:

  • A security improvement plan (SIP) including detailed recommendations, time frames, resources required (this document will become your only way of tracking all the actions required throughout the PCI programme).
  • A roadmap, indicating effort and time required to ensure all actions are resolved before PCI ‘compliance’ is achieved and by when (key milestones).
  • Identification of areas of PCI non-compliance and clear guidance on what needs to be done to achieve compliance, highlighting appropriate recommendations with appropriate policy recommendations and cost-effective solutions (where appropriate).
  • Any areas where compensating controls may be used – this will need to be validated during the next step – risk analysis.


33 The statement of applicability (also known as an SOA) is a document which identifies the controls chosen for your environment, and explains how and why they are appropriate. The SOA is derived from the output of the risk assessment/ risk treatment plan and, if ISO27001 compliance is to be achieved, must directly relate the selected controls back to the original risks they are intended to mitigate. Normally the controls are selected from ISO17799, but it is possible to also include own controls. A number of sector specific schemes are being introduced which stipulate additional mandatory controls. The SOA should make reference to the policies, procedures or other documentation or systems through which the selected control will actually manifest. It is also good practice to document the justification of why those controls not selected were excluded.