PCI Council Publishes Version 3.0 of PCI DSS and PA DSS

November 13th, 2013
Resources & Tools

PCI Council Publishes Version 3.0 of PCI DSS and PA DSS


by Austin Mills

On November 7, 2013, the PCI Security Standards Council (PCI SSC) published Version 3.0 of the PCI Data Security Standard (PCI DSS) (available here) and Payment Application Data Security Standard (PA-DSS) (available here).

The PCI SSC develops its security standards in accordance with a 36-month lifecycle.[1] The PCI SSC has stated that Version 3.0 will, among other things:

  1. Provide stronger focus on some of the greater risk areas in the threat environment.
  2. Provide increased clarity on PCI DSS & PA-DSS requirements.
  3. Improve flexibility for all entities implementing, assessing, and building to the Standards.
  4. Help manage evolving risks / threats.
  5. Align with changes in industry best practices.[2]

The core 12 security areas of PCI DSS remain the same, but several new sub-requirements have been added. In summary, the major changes to PCI DSS relate to offering additional stability controls, making security a part of everyday business, user awareness, and enhanced testing procedures (including penetration testing).

With regard to PA DSS, the changes emphasize training of integrators so that responsibilities are shared between vendors providing the application, merchants using the application, and integrators putting the application into action.

With a few exceptions as noted below, the new requirements are effective January 1, 2014. Version 2.0 shall continue to apply until that time. The new requirements that do not go into effect immediately are considered to be best practices until July 1, 2015.  New requirements include:


  • Req. 5.1.2 – evaluate evolving malware threats for any systems not considered to be commonly affected
  • Req. 8.2.3 – combined minimum password complexity and strength requirements into one, and increased flexibility for alternatives
  • Req. 8.5.1 – for service providers with remote access to customer premises, use unique authentication credentials for each customer (best practices until July 1, 2015)
  • Req. 8.6 – where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.) these must be linked to an individual account and ensure only the intended user can gain access
  • Req. 9.3 – control physical access to sensitive areas for onsite personnel, including a process to authorize access, and revoke access immediately upon termination
  • Req. 9.9 – protect devices that capture payment card data via direct physical interaction with the card from tampering and substitution (best practices until July 1, 2015)
  • Req. 11.3 and 11.3.4 – implement a methodology for penetration testing; if segmentation is used to isolate the cardholder data environment from other networks, perform penetration tests to verify that the segmentation methods are operational and effective (best practices until July 1, 2015)
  • Req. 11.5.1 – implement a process to respond to any alerts generated by the change-detection mechanism
  • Req. 12.8.5 – maintain information about which PCI DSS requirements are managed by each service provider, and which are managed by the entity
  • Req. 12.9 – for service providers, provide the written, agreement/acknowledgment to their customers as specified at requirement 12.8.2 (best practices until July 1, 2015)


  • Req. 5.1.5 – payment application developers to verify integrity of source code during the development process
  • Req. 5.1.6 – payment applications to be developed according to industry best practices for secure coding techniques
  • Req. 5.4  payment application vendors to incorporate versioning methodology for each payment application
  • Req. 5.5 – payment application vendors to incorporate risk assessment techniques into their software development process
  • Req. 7.3 – application vendor to provide release notes for all application updates
  • Req. 10.2.2 – vendors with remote access to customer premises (for example, to provide support/maintenance services) use unique authentication credentials for each customer
  • Req. 14.1 – provide information security and PA-DSS training for vendor personnel with PA-DSS responsibility at least annually


[2] https://www.pcisecuritystandards.org/documents/DSS_and_PA-DSS_Change_Highlights.pdf

The information herein is presented for educational and informational purposes and is not intended to constitute legal advice. Additional information is at www.www.mmmtechlaw.com/privacy-policy-and-disclaimer/ . For more information about the author, Austin Mills, click here