Chapter 7: Step 7 – Auditing – PCI DSS: A Practical Guide to implementing and maintaining compliance, Third Edition


The overall objective of auditing is to check over a specified regular audit period (which should last no more than one year) that all aspects of the PCI compliance programme are functioning as intended and that the minimum requirements, as specified in PCI DSS are being met.

Like many regulations, PCI can be intimidating because it is a broad-reaching set of requirements potentially including all of your information systems in scope. Unlike other regulations, PCI is highly prescriptive and there is a huge amount of supporting useful and free material available to help you determine if you need to comply; and therefore help your entity prepare for your external audit (QSA), external scan (ASV) or your self-assessment.

There are several activities that are essential to ensure that the PCI compliant environment continues to evolve and maintain its effectiveness in securing cardholder data.

These include:

1 Initiation of the audit (objectives and scope).

2 Auditor preparation.

3 Conduct the audit.

4 Report the findings.

5 Agree follow-up action and clearance of any findings.

Note: It is worth mentioning that whilst this section describes a generic approach to auditing, it is not intended to replace existing guidelines already provided. It is therefore recommended that you download, read and utilise the auditing guidelines freely available from the PCI DSS web site – PCI_audit_procedures_v2 and other good websites, such as ISACA.38

Initiation of the audit (objectives and scope)

What are the PCI auditing objectives?

Now that you have established your PCI compliance ‘baseline’, based on your SIP, policy update, gap analysis, and risk analysis a sufficient number of audits must be planned, so that the audit task is spread uniformly over the chosen period i.e. so that it doesn’t come all at once.

As with any management system, auditing is paramount to ensuring its continued success, improvement and evolution. Audits play a major part in ensuring this validation and should provide sufficient evidence when inviting external auditors (QSA) for PCI compliance approval i.e. the ROC and the executive summary.

Note: The quantity of auditing is dependent upon the level of credit card transactions.

Therefore, the effective operation of the audit schedule should be in place to confirm:

  • The information security policy is still an accurate reflection of the business requirements.
  • An appropriate risk assessment methodology is being used.
  • The documented procedures are being followed (i.e. within the scope of the PCI), and are meeting their desired objectives.
  • Technical controls (e.g. firewalls, network access controls) are in place, are correctly configured and working as intended.
  • The residual risks have been assessed correctly and are still acceptable to the management of the entity.
  • The agreed actions from previous audits and reviews have been implemented.
  • The PCI compliance programme is compliant with the PCI DSS Standard.
  • That completion of the improvements/audit findings has been made.

Tip – The audits should involve reviewing samples of current documents and records; this should involve interviews with all staff, from senior management to shop floor employees.

Auditing objectives

The objective of auditing your own entity is to ensure initial and ongoing PCI compliance and to ensure a successful audit is conducted prior to any external auditors coming in (QSA).

Tip – It is better to find your own vulnerabilities/gaps then have someone else find them for you!

Therefore, your auditing objectives should look to include:

  • An audit schedule – ideally as part of the original project initiation document (including scope of audit), but at least should include an annual breakdown of all audit dates and the areas to be reviewed.
  • A set of prepared audit questions – prepare a set of audit questions in line with PCI and using ISO27001 or other good (and free) audit guidance documentation such as the ISACA guidelines for auditors39.
  • To be professional – ensure you conduct the audits (business processes and technical) within all appropriate business and IT areas and be polite.
  • Audit deliverables – produce an audit report and conduct feedback meetings (to discuss findings, recommendations and improvements) and make sure you retain the evidence to back up your findings (including compliant and non-compliant).
  • Preparation – help your entity prepare for external PCI compliance and any simultaneous certification audits i.e. ISO27001, by holding a series of seminars and communication notices (including dos and don’ts).

Tip: Make sure you notify the relevant areas when they will be audited, this will ensure cooperation and adequate preparation (nobody likes surprises).

Technical audit objectives

The objective is to provide a fully auditable and traceable exploration and test programme as required under PCI DSS. This allows any issues identified to be validated and rated before being rectified. It also allows for any penetration test to be repeated, ensuring that the corrective action taken has had the required results.

Therefore, the objective of the technical audit is to gather background information, and specify technical solutions that will help rectify or mitigate any potential technical failures (risks/vulnerabilities) from a PCI DSS compatibility perspective.


Each audit should be used to determine both the adequacy of its part in contributing towards PCI compliance and how it helps to achieve the PCI objectives effectively (i.e. secure cardholder configuration database, secure user working practices). Ultimately, PCI audit and compliance should be built into the existing audit processes and procedures, using auditing as a way to measure your level of PCI compliance (possibly using a dashboard effect).

Tip: Don’t forget the continuing accuracy of the PCI compliance must be included with the report on compliance submission.

Auditor preparation

When assessing compliance against the PCI Standard, it is essential to examine whether the items that should have been produced in accordance with the PCI DSS, were available (e.g. evidence of logs and records). If there are deviations from the requirements laid down in the PCI Standard, the audit team should attempt to determine the causes and help suggest ways to avoid these potential issues.

It is conceivable that some parts of the Standard are never used. In these cases the audit team should consider whether the unused part of the PCI is still relevant, and if not, make a recommendation on whether it should be removed from the ROC.

The auditor may select a representative sample of system components to test. The sample must be a representative selection of all of the types of system components, and include a variety of operating systems, functions, and applications that are applicable to the area being reviewed. For example, the reviewer could choose Sun servers running Apache WWW, NT servers running Oracle, mainframe systems running legacy card processing applications, data transfer servers running HP-UX, and Linux Servers running MYSQL. If all applications run from a single operating system (for example, NT, Sun), then the sample should still include a variety of applications (for example, database servers, web servers, data transfer servers).

In addition to the PCI auditing requirements set out in the PCI_Audit_Procedures v2, the following information can be used to help when auditing against the Standard.

Technical audit preparation

Technical audits can be achieved by:

1 Conducting interviews with appropriate personnel as nominated by IT management. These interviews should be used to gather information on technical background, threats and vulnerabilities, business impacts, and general security management.

2 Where available, review existing documentation to determine network or application architecture.

3 Review other pertinent information relevant to those services being supported by external third parties.

4 Automated IP discovery tools. These IP discovery scans should be able to provide a further vulnerability assessment of devices against known operating system and applications security vulnerabilities.

5 Manual inspection of specific device configuration. This should provide the technical auditor with assurance that information supplied during the interview, coupled with the details provided in the documentation, was current and can be verified.

As it is recognised that whilst the use of testing tools provides assurance against basic attempts to circumvent the security mechanisms designed to protect the system, more in-depth analysis by skilled, trained practitioners should augment this process, as many of the attacks that are known, would not be detected by simply using a vulnerability scanning tool.

A number of non-intrusive vulnerability scans of the network and network elements using industry recognised tools must also be performed. This work should involve technical network mapping, system interrogation and some aspects of security assessment.

Where firewall systems and intrusion detection and prevention tools are deployed, it may be necessary to have connections on each separate leg, to enable scanning traffic to reach all connected systems.

Conduct the audit

There are many areas to be reviewed during the auditing process and the PCI provided guides should not be used exclusively when conducting audits. The following sections provide some sample areas that will help determine the maturity of the security management practices within your entity (ideally – this list should be refined and agreed during the scoping workshop) and help you manage PCI compliance going forward:

There are seven components and their supporting functions that need to be reviewed during the auditing process. These include:

Task 1) Review the information security management system components

  • Visible management commitment to information security.
  • Identification of business and security objectives as well as legal, regulatory and contractual requirements for compliance.
  • Risk management and assessment.
  • Control selection process.
  • Internal auditing (including technical penetration assessments).
  • Performance and effectiveness measurement.
  • Management review processes (continuous improvement).
  • Security improvement programme.
  • Communication and enforcement of minimum standards across the estate.

Task 2) Review policy components

For all policies listed below, associated processes, procedures and standards may also need to be reviewed and therefore audited against, including:

  • Information security policy.
  • Acceptable use policies (including use of e-mail for sensitive information).
  • Data retention and disposal policies.
  • Data classification and labelling policies (specifically classification of UK Visa application data).
  • Password policies.
  • Access control policies (logical access).
  • Third party access policies.
  • Physical access control policies (physical access).
  • Physical storage and media handling policies (including evidence of inventory).
  • Anti-virus and malicious code policies.
  • Patching and vulnerability management policies.
  • System testing policies.
  • Any code of connection (required for UK government departments).

Task 3) Review the process functions

  • HR process.
  • Business justified Role Based Access Control (RBAC).
  • Documented information security roles and responsibilities.
  • Entity of information security (e.g. management responsibilities and entity charts).
  • Security awareness programmes and training.
  • Screening of staff (employees and contractors).
  • Contract clauses with service providers.
  • Change management.
  • Incident response provisions, including:
    • Incident management.
    • Disaster recovery.
    • Business continuity and crisis management.
    • Fraud detection and subsequent investigations.
  • Log analysis and retention.
  • Application testing and acceptance process.
  • Security testing procedures.

Task 4) Review the procedure components

  • Operational security procedures.
  • Back-up and retrieval procedure.
  • Procedures for all of the above policies and processes.

Task 5) Review the standards

  • Secure build standards.
  • Hardening standards.
  • System development lifecycle management.
  • Website design standards.
  • Security architecture standard.
  • Secure coding standards.
  • Application development standards, including:
    • Web application standards.
    • Portable device standards.
    • Database standards.
    • Independent verification standards.

Task 6) Review the user management

During the audit review, the application and implementation of user and account management policies needs to be examined and reviewed for accuracy. This is usually carried out by interviewing staff responsible for the technical environment.

It is also imperative that you review the access controls around third party access to your infrastructure and systems i.e. for remote support, maintenance and upgrades. This should include reviewing and auditing:

  • Provisioning of new user accounts.
  • Deletion of old and unused accounts.
  • Password management.
  • Appropriate use of strong authentication / 2 factor authentication.
  • Use of RADIUS/TACACS where necessary.
  • Use of administrator accounts (specifically access to system components).
  • Audit and accountability, including audit policies and synchronisation of system clocks and audit logs
  • Storage of audit logs.

Task 7) Review the technical components

A detailed technical audit of specific critical network systems (such as core switches and routers) and representative devices (where many are configured similarly) through manual inspection of configuration files and access policies must be conducted. This task should focus on understanding the operation of the network elements that provide core switching functions, external access points and security devices including firewalls and how this all hangs together within the target (cardholder data) environment.

This review should not be limited to the target environment (cardholder data), as vulnerabilities found in other adjacent networks (for example: within the VLAN), may be used to exploit or launch an attack on the target. Technical analysis should, as a minimum, include each of the following areas of review:

  • Network configuration including servers, routers, switches, firewalls, and remote access facilities.
  • Virus protection.
  • Internal network security.
  • Network management, maintenance and operational support.
  • Content management (SMTP/HTTP/FTP).
  • Laptop and desktop security.
  • Security of existing handheld devices e.g. PDA/Blackberry.
  • Review current plans for securing USB connectivity.
  • Mobile e-mail services including personal accounts.
  • Emerging technologies such as wireless.
  • Any arrangements in support of the PCI compliance programme.
  • Technical regulatory requirements such as SOX or the DPA.

Validating that your systems meet the technical criteria of the PCI requirements is no easy task, therefore if you don’t already have technical vulnerability expertise within your entity, or you wish to be totally impartial, then the role (and relationship) with your chosen approved scanning vendor or qualified security assessor, becomes crucial.

Report the findings

Audit reporting

During the reporting phase, management and the PCI sponsors need to receive formal feedback from the audit team. This knowledge transfer should be an open and transparent process. Almost every audit identifies opportunities for improvement.

Audit deliverables

The audit results and recommendations must be captured and presented in the following format:

  • Audit improvement plan that feeds into the security improvement plan.
  • Technical updates to the report on compliance.
  • This audit should not only identify areas of non-compliance, but also provide clear guidance as to what needs to be done to achieve compliance, in a given timeframe and by highlighting appropriate recommendations, with appropriate technical solutions.
  • Inputs into the risk register.

The above approach should ensure a skills transfer to enable key personnel to carry on, for instance, with the audits in the future. This element of the PCI project also requires multiple templates for all auditing checklists to be completed in advance; this will enable your entity to continue auditing well into the future.

Agree follow-up action and clearance of any findings

The primary goal of management and auditors should be to address critical issues first, followed by important issues. Both management and auditors should work to ensure that, whatever action plans they set, the goals are achievable and beneficial to the entity.

During the reporting phase, management must determine which corrective actions it will implement and when, based on audit findings. Managers must provide oversight and support to ensure the timely resolution of found issues. Although the audit team may make recommendations based on its assessments of risks and their consequences facing the entity, it should not make or dictate managerial decisions. The objective of the audit is to identify, inform and provide recommended ways to resolve and close any gaps found.


38 d_History/Overview_and_History.htm.

39 for IS auditing.