Full Text Of The Proposed PCI 1.2




The PCI Security Standards Council has announced that version 1.2 of the PCI Data Security Standards will be available for general use October 1, 2008. The purpose of this document is to provide high level guidance on the changes to be brought about with this key milestone standard revision. Version 1.2 is an update to the current version 1.1 and follows the established approved lifecycle process, which provides for revisions or new versions on a 24 month cycle. While version 1.2 will not introduce any major new requirements, it will include clarifying items designed to fulfill the following goals inherent to the PCI Data
Security Standard:
  • Provide greater clarity on PCI DSS requirements

  • Offer improved flexibility

  • Manage any evolving risks and threats

  • Incorporate best practices

  • Clarify scoping and reporting

  • Eliminate redundant sub-requirements

  • Consolidate documentation


    As noted above, the revisions to version 1.2 do not incorporate any new major requirements. Therefore the changes summarized below reflect the same six guiding principles and 12 requirements currently in force under version 1.1. Note that this summary of changes does not include all changes made in version 1.2. The PCI Security Standards Council reserves the right to make final revisions to version 1.2 prior to publication; this summary is for initial preview purposes only, and does not supersede PCI DSS v1.1. Once PCI DSS v1.2 is publicly released, PCI DSS v1.2 will be the official version and further guidance will be provided about effective and sunset dates.

    Build and Maintain a Secure Network

    Requirement 1: Install and maintain a firewall configuration to protect cardholder data
  • Clarified requirement to illustrate that all sub-requirements apply to both routers and firewalls

  • Combined requirements and sub-requirements to clarify requirement 1

  • Added flexibility in the time frame for review of firewall rules, from quarterly to every 6 months, based on Participating Organization feedback. Now the control can be better customized to the organization's risk management policies.

  • Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
  • Clarified that the requirement applies to wireless environments "attached to cardholder environment or transmitting cardholder data.

  • Removed references to WEP in order to emphasize using strong encryption technologies for wireless networks, for both authentication and encryption

  • Removed requirement to disable SSID broadcast since disabling SSID broadcast does not prevent a malicious user from determining the SSID, as the SSID is broadcast over numerous other messaging/communication channels.

  • Protect Cardholder Data

    Requirement 3: Protect stored cardholder data
  • Emphasized use of consistent terms throughout, such as "PAN" and "strong

  • Clarified requirement for disk encryption to emphasize local user account databases

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

  • Wireless must now be implemented according to industry best practices (e.g., IEEE 802.11x) using strong encryption for authentication and transmission.

  • New implementations of WEP are not allowed after March 31, 2009.

  • Current implementations must discontinue use of WEP after June 30, 2010 Maintain a Vulnerability Management Program

  • Requirement 5: Use and regularly update anti-virus software
  • Clarified that requirement for use of anti-virus software applies to all operating system types
  • Clarified that anti-virus software must address all known types of malicious software

  • Requirement 6: Develop and maintain secure systems and applications
  • Added flexibility to the patching requirement by specifying that a risk-based approach may be used to prioritize patch installation

  • Requirement 6.6 is now mandatory. All public-facing web applications are subject to either 1) reviews of applications via manual or automated vulnerability assessment tools or methods, or 2) installing an application-layer firewall in front of public-facing web applications.

    Implement Strong Access Control Measures

    Requirement 7: Restrict access to cardholder data by business need-to-know
  • Clarified language around testing procedures

  • Requirement 8: Assign a unique ID to each person with computer access
  • Clarified that testing procedures must verify that passwords are unreadable in storage and transmission

  • Clarified user authentication by allowing both passwords and passphrases, and by combining previous bullets under "two-factor authentication" and providing examples

  • Requirement 9: Restrict physical access to cardholder data
  • Specified that offsite storage locations must be visited at least annually

  • Provided flexibility in the requirement for cameras to allow organizations to select other appropriate access control mechanisms

  • Clarified that the requirement to secure media applies to electronic and paper media that contains cardholder data

  • Clarified destruction requirements for media containing cardholder data Regularly Monitor and Test Networks

  • Requirement 10: Track and monitor all access to network resources and cardholder data
  • Clarified that logs for external facing technologies (for example, for wireless, firewalls, DNS and mail) must be copied to an internal log server

  • Provided flexibility and clarified that three months of audit trail history must be immediately available for analysis" or quickly accessible (online, archived or restorable from backup)

  • Requirement 11: Regularly test security systems and processes
  • Provided more guidance on use of wireless analyzers and/or wireless intrusion detection or prevention systems

  • Outlined that ASVs must be used for quarterly external vulnerability scans

  • Specified that both internal and external penetration tests are required and clarified that it is not required to use a QSA or ASV for penetration tests
  • Maintain an Information Security Policy

    Requirement 12: Maintain a policy that addresses information security
  • Expanded list of examples of critical employee-facing technologies to include "remote access technologies, wireless technologies, removable electronic media, email usage, internet usage, laptops, and Personal Data Assistants (PDAs)"

  • Updated timeframe that requires employees to acknowledge that they have read and understood the company's security policy and procedures to "at least annually"

  • Updated former "contract" and "connected entities" language to clarify that organizations must have policies and processes implemented to manage and monitor service providers.


    The entire PCI DSS version 1.2 (or "Security Assessment Procedures" version 1.2 that comprise the standard) along with supporting documentation will be made available to Participating Organizations the first week of September 2008. It will be discussed in further detail at the Council's Community Meeting in Orlando, Fla. September 23-25, 2008. Release of the standard will be made public October 1, 2008 and follow on discussions will take place at the Council's second Community Meeting, in Brussels, Belgium, October 22- 23, 2008. Please note that only representatives from Participating Organizations, QSAs,
    ASVs, and PED labs can attend the Council's Community Meetings and organizations interested in learning more about PCI DSS version 1.2 and related security standards are encouraged to join as a Participating Organization. Information can be found on the Council's Web site (www.pcisecuritystandards.org) or by emailing the Council at [email protected]"