PCI DSS 3.2 and Changes to PCI SAQs

PCI DSS 3.2 became mandatory on the 1^st of November 2016. The standard has been updated to take into account changes to the threat landscape. This includes the removal of some redundant or duplicate requirements and the addition of new requirements. The new requirements are considered best practice until 31^st of January 2018. The new standard also introduces changes to the majority of the Self-Assessment Questionnaires (SAQs). This article will focus on the changes to the SAQs. Please note that there have been no changes to the eligibility criteria for the SAQs.

This article was prompted by several enquiries from concerned clients who suddenly had additional requirements that they needed to meet. A number of merchants appear to believe that changes to the SAQs are also considered best practice until 31^st of January 2018, similar to the new requirements introduced by the standard. This is incorrect and changes to the SAQs took effect as of the 1^st of November 2016. This means that any pre-existing PCI DSS requirement introduced to an SAQ is mandatory as of that date. Only new PCI DSS requirements introduced to an SAQ, such as using multi-factor authentication for non-console admin access to systems in the cardholder environment, will be considered best practice until 31^st of January 2018.

SAQ A

SAQ A has a number of new requirements. Due to the increased number of compromises the PCI Security Standards Council felt the need to enforce additional security requirements on card-not-present merchants which require them to improve their security. These can be summarised as follows:

Changing default passwords.
Deleting or disabling leavers accounts.
Enforcing password complexity.
Deleting or disabling generic and default accounts.
Prohibiting the use of shared user accounts to administer systems.
Implementing an incident response plan.

SAQ A-EP

SAQ A-EP has a large number of new requirements. Again, due to the increased number of compromises the Council feels the need to enforce additional security requirements on card-not-present merchants which require them to improve their security. These can be summarised as follows:

Network diagram and cardholder data flow diagrams.
Additional requirements for securing the network perimeter such as establishing processes for approving firewall changes, reviewing firewall configurations every 6 months and using a DMZ to host web facing services.
Additional requirements for software development to cover insecure communications and error handling.
Additional requirements for account management and security such as removing inactive accounts, enforcing session timeouts and verifying users’ identity before resetting their password.
Extending multi-factor authentication requirements to all non-console admin access. Please note that this is considered best practice until 31^st of January 2018.
Additional requirements for logging and monitoring such as monitoring access to all audit trails, protection of audit logs and time synchronisation.
Using intrusion detection or intrusion prevention systems to monitor and protect the cardholder data environment (CDE).
Ensuring that relevant policies and procedures are documented, in use and known to all affected parties.

SAQ B

There have been no changes to SAQ B in version 3.2.

SAQ B-IP

There have been no changes to SAQ B-IP in version 3.2.

SAQ C-VT

SAQ C-VT has a number of new requirements around authentication and physical security due to changes to the threat landscape. These can be summarised as follows:

Using unique accounts for users and using a secure authentication mechanism.
Deleting or disabling leavers accounts.
Enforcing password complexity.
Deleting or disabling generic and default accounts.
Prohibiting the use of shared user accounts to administer systems.
Enforcing physical access controls on the CDE.

SAQ C

SAQ C has a number of new requirements around change management, authentication and physical security due to changes to the threat landscape. These can be summarised as follows:

Ensuring that all changes are complaint with PCI DSS requirements and that these changes are documented as applicable. Please note that this is considered best practice until 31^st of January 2018.
Using unique accounts for users and using a secure authentication mechanism.
Enforcing account lockout after 6 failed login attempts.
Enforcing session timeouts.
Enforcing password complexity and password expiry.
Deleting or disabling generic and default accounts.
Prohibiting the use of shared user accounts to administer systems.
Extending multi-factor authentication requirements to all non-console admin access. Please note that this is considered best practice until 31^st of January 2018.
Ensuring that policies and procedures for identification and authentication are documented and communicated to all users.
Enforcing physical access controls on the CDE.

SAQ P2PE

The council has removed two requirements from SAQ P2PE due to improvement in hardware payment terminals. These are listed below:

Ensuring that the PAN is masked when displayed.
Ensuring that unprotected PANs are not sent via end-user messaging technologies such as emails.

SAQ D

There have been a number of new requirements for SAQ D, particularly for service providers. The following changes apply to both merchants and service providers:

Ensuring that all changes are complaint with PCI DSS requirements and that these changes are documented as applicable. Please note that this is considered best practice until 31^st of January 2018.
Extending multi-factor authentication requirements to all non-console admin access. Please note that this is considered best practice until 31^st of January 2018.
Ensuring that policies and procedures for monitoring all access to network resources and cardholder data. Are documented and communicated to all staff.

The following new requirements apply only to service providers. Please note that these are considered best practice until 31^st of January 2018:

Documenting the cryptographic architecture in use including details of the algorithms, protocols and keys used to protect the cardholder data. This should also include description of key usage and key management operations.
Implementing a process for the detection, reporting, alerting and responding to failures affecting critical security controls systems such as firewalls, intrusion detection systems and antivirus applications.
Carrying out penetration tests to assess the effectiveness of segmentation controls at least every six months and after any changes to the segmentation controls or methods.
Ensuring that executive management assign responsibilities for the protection of the cardholder data and management of the PCI DSS compliance program.
Defining processes for quarterly reviewing and confirming that personnel are following the defined policies and procedures. These should cover daily log reviews, firewall rule-set reviews, using configuration standards, responding to security incidents and change management.

Find out how we can help with your cyber challenge

Please enter your contact details using the form below for a free, no obligation, quote and we will get back to you as soon as possible. Alternatively, you can email us directly at [email protected]