SAQs Explained

SAQ – Summary

How do we determine your Self-Assessment Questionnaire and what does each one mean?

Once you have completed your business profile in the compliance portal, you will be assigned to an acceptance channel – how your business accepts payments:

Face to face

transactions made where the card holder is physically present.

E-commerce

via a customer facing website that takes card payments.

Mail or telephone orders (MOTO)

payments made over the phone or mail ordering services.

1.

Payment Method
The type and setup of the solution your business uses to accept and process payments.

2.

Storage of data
If you store any cardholder data electronically, you will automatically be assigned an SAQ D. The SAQ D includes all the security measures necessary to securely store electronic cardholder data.

SAQs can be categorized based on what a business uses to take payments.

Expand the sections below to see the changes applicable to each SAQ type.
Note: None of the SAQ types listed are applicable to Service Providers.

Click here to understand how an SAQ type is determined.

    • Acceptance: E-commerce and/or MOTO
    • Third-Party Service Provider (TPSP): Any third party acting as a service provider on behalf of an entity. For merchant businesses, this includes any third-party organization that processes, transmits and/or stores payment card data on the merchant’s behalf, that manages systems included in the scope of the merchant’s PCI DSS assessment, or that could otherwise impact the security of the merchant’s Cardholder Data Environment (CDE) or payment card data.
    • E-commerce: E-commerce merchant websites that either redirect cardholders to a PCI DSS validated and compliant TPSP/payment processor for payment processing; or include a PCI DSS validated and compliant TPSP/payment processor’s embedded payment page/ form, in one or more iFrames. All elements of all payment page(s)/form(s) delivered to the customer’s browser originate only and directly from the PCI DSS-compliant TPSP/payment processor.
    • E-commerce: All e-commerce website operations are fully outsourced to a Third-Party Service Provider (TPSP); TPSP is PCI DSS compliant for the services being used.
    • Pay by link: This is an example of fully outsourced e-commerce. Merchants send a secure payment link (in an invoice, email, or other message) that takes the customer to a third-party hosted payment page, supplied by a PCI DSS-compliant TPSP.
    • MOTO: All mail and/or telephone operations are fully outsourced to a Third-Party Service Provider (TPSP), such as a call center, mail order, or order fulfillment service. TPSP is PCI DSS compliant for the services being used.
    • All payment acceptance and account data processing is fully outsourced to PCI DSS-validated and compliant third parties.
    • No electronic storage, processing, or transmission of Account Data (cardholder data and/or sensitive authentication data) on merchant systems or premises.
    • If your e-commerce website redirects cardholders to (or embeds an iFrame from) a PCI DSS validated and compliant Third-Party Service Provider (TPSP)/payment processor for payment processing, an external vulnerability scan performed by a PCI SSC-approved scanning vendor (ASV) at least once every three months is required. A list of Approved Scanning Vendors can be found here on the PCI SSC website.
    What recent changes apply are applicable to SAQ A?

    Changes clarifying eligibility for and applicability within SAQ A, include:

    • Updating references to ‘cardholder data’ to ‘account data.’
    • Merchants must confirm their TPSPs are PCI DSS compliant for the services being used.
    • E-commerce merchants must confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).
    • The note on page iii of the PCI DSS SAQ A document clarifies the applicability of Requirements 2, 6, 8 and 11 and Requirements that refer to the “cardholder data environment.” These Requirements apply to e-commerce merchants whose website redirects customers to a third-party service provider (TPSP)/payment processor for payment processing or include a TPSP/payment processor’s embedded payment page/form (for example, an inline frame or iFrame).
    • Notes and completion guidance throughout SAQ A explain how Requirements apply to merchants and/or their web servers.
    Recent updates to Requirements
    • Data retention and disposal policies and procedures to cover any Sensitive Authentication Data (SAD) stored pre-authorization (3.2.1).
    • Minimum of 12-character alphanumeric password length if passwords/passphrases are used to authenticate users and administrators (8.3.6); or minimum 8 characters if the system does not support 12 characters.
      • Applicable to merchant web servers that host the page(s) that either 1) redirect customers from the merchant website to a TPSP / payment processor for payment processing (for example, with a URL redirect) or 2) include a TPSP / payment processor’s embedded payment page/ form (for example, an inline frame or iFrame).
      • Not applicable to application or system accounts.

    Note: merchants accepting payments in multiple ways and reporting their PCI DSS compliance under a single portal account or MID (Merchant ID Number) may be able to complete a Composite (or Hybrid) SAQ D assessment, which is a combination of two or more of the above SAQ types that the merchant is individually eligible for.

    • Acceptance: E-commerce only
    • Payment processing is partially outsourced to PCI DSS-validated and compliant third parties. Third-Party Service Provider (TPSP): Any third party acting as a service provider on behalf of an entity. For merchant businesses, this includes any third-party organization that processes, transmits and/or stores payment card data on the merchant’s behalf, that manages systems included in the scope of the merchant’s PCI DSS assessment, or that could otherwise impact the security of the merchant’s Cardholder Data Environment (CDE) or payment card data.
    • All payment acceptance and account data processing, with the exception of the payment page, is fully outsourced to PCI DSS-validated and compliant third parties.
    • Merchant’s website does not itself receive account data but can affect the security of the payment transaction and/or the integrity of the page that accepts customer account data.
    • Each element of the payment page(s) delivered to the customer browser originates from either the merchant’s website or a PCI DSS-compliant TPSP/payment processor.
    • No electronic storage, processing, or transmission of Account Data (cardholder data and/or sensitive authentication data) on merchant systems or premises.
    • If the merchant website is hosted by a TPSP, the TPSP must be compliant with all applicable PCI DSS requirements (including PCI DSS Appendix A if the TPSP is a multi-tenant hosting provider*).
    • Example – Direct Post: Merchant’s website creates the payment page, which is displayed in the customer’s browser. Account data is sent directly to the PCI DSS- compliant TPSP/payment processor.
    • Example – JavaScript created form: The payment page configured by the merchant instructs the customer browser to request and execute some JavaScript from the TPSP/payment processor, creating the payment form elements for account data capture that appear on the payment page in the customer browser. Entered account data is sent directly to the PCI DSS-compliant TPSP/payment processor.

    An External Vulnerability Scan performed by a PCI SSC Approved Scanning Vendor (ASV) at least once every three months is required.

    What recent changes apply to SAQ A-EP?

    Changes clarifying SAQ eligibility and applicability include:

    Updating references to ‘cardholder data’ to ‘account data’. Merchants must confirm their TPSPs are PCI DSS compliant for the services used. Notes and completion guidance throughout the SAQ A-EP.

    Recent updates to Requirements
    • Data retention and disposal policies and procedures to cover any Sensitive Authentication Data (SAD) stored pre-authorization (3.2.1).
    • Confirm certificates used to safeguard Primary Account Numbers (PAN) during transmission over open, public networks are valid and not expired or revoked (4.2.1).
    • Anti-malware solution for removable electronic media (5.3.3).
    • Implement automated mechanisms to detect and protect against phishing attacks, include phishing and social engineering in security awareness training (5.4.1, 12.6.3.1).
    • Maintain an inventory of all bespoke software (developed to the entity’s specifications by a third party), custom software (developed by the entity), and third-party software components (6.3.2).
    • Deploy an automated technical solution for public-facing web applications that continually detects and prevents web-based attacks (6.4.2) (removal of the 6.4.1 option to review web applications via application vulnerability assessment tools or methods).
    • Manage payment page scripts to ensure each script is necessary, its use authorized, and its integrity assured (6.4.3).
      • Applicable to any scripts on the payment page(s) provided from the e-commerce merchant’s website(s) to the customer’s browser.
      • Applicable to all scripts loaded from the merchant’s environment and scripts loaded from third and fourth parties.
    • Review user accounts and related access privileges, including third-party/vendor accounts, at least once every six months (7.2.4).
    • Manage application and system accounts (7.2.5, 8.6.1, 8.6.2, 8.6.3).
      • Minimum of 12-character alphanumeric password length, if passwords/passphrases are used to authenticate users and administrators (8.3.6); or minimum of 8 characters if the system does not support 12 characters. Applicable to merchant web servers that host the payment page(s) provided from the merchant’s website to the customer’s browser.
      • Not applicable to application or system accounts.
    • Additional requirements for multi-factor authentication (MFA) (8.4.2, 8.5.1).
      • MFA to be implemented for all non-console access into the Cardholder Data Environment (CDE).
      • Configure MFA systems to ensure they are not susceptible to replay attacks, cannot be bypassed by any users without authorization, use at least two different types of authentication factors, and grant access only after all authentication factors are successful.
    • Implement automated mechanisms to perform audit log reviews (10.4.1.1).
    • Implement a change- and tamper-detection mechanism to detect and alert unauthorized modification to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser (11.6.1).
      • Applicable to merchant web servers that host the payment page(s) provided from the merchant’s website to the customer’s browser.
    • Perform targeted risk analyses to determine the frequency a requirement is performed (12.3.1).
      • Applicable to Requirements 5.2.3.1, 5.3.2.1, 8.6.3, 10.4.2.1, 11.6.1.

    *Note: Multi-Tenant Service Provider: A type of Third-Party Service Provider that offers various shared services to merchants and other service providers, where customers share system resources (such as physical or virtual servers), infrastructure, applications (including Software as a Service (SaaS)), and/or databases. Services may include, but are not limited to, hosting multiple entities on a single shared server, providing e-commerce and/or “shopping cart” services, web-based hosting services, payment applications, various cloud applications and services, and connections to payment gateways and processors.

    https://www.pcisecuritystandards.org/glossary/#glossary-m

    Note: merchants accepting payments in multiple ways and reporting their PCI DSS compliance under a single portal account or MID (Merchant ID Number) may be able to complete a Composite (or Hybrid) SAQ D assessment, which is a combination of two or more of the above SAQ types that the merchant is individually eligible for.

    • Acceptance: Face-to-face and/or mail/telephone-order.
    • Payment method: Standalone terminal with a phone line connection to the payment processor.
    • No electronic storage of Account Data (cardholder data and/or sensitive authentication data).
    • No External Vulnerability Scan requirement.
    What recent changes apply to SAQ B?

    As with the other version 4.X SAQs, SAQ B now references ‘merchant’ instead of ‘company’ and ‘account data’ instead of ‘cardholder data.’

    SAQ eligibility criteria have been simplified with ‘Your company does not transmit cardholder data over a network (either an internal network or the Internet)’ removed.

    No recent updates have been made to SAQ B Requirements.

    Note: merchants accepting payments in multiple ways and reporting their PCI DSS compliance under a single portal account or MID (Merchant ID Number) may be able to complete a Composite (or Hybrid) SAQ D assessment, which is a combination of two or more of the above SAQ types that the merchant is individually eligible for.

    • Acceptance: Face-to-face and/or mail/telephone order.
    • Payment method: Standalone terminal with an IP (Internet) connection to the payment processor. The payment terminal must be an approved PIN Transaction Security (PTS) point-of-interaction device listed on the PCI SSC website here.
    • No electronic storage of Account Data (cardholder data and/or sensitive authentication data).
    • An External Vulnerability Scan performed by a PCI SSC Approved Scanning Vendor (ASV), at least once every three months, is required, unless the standalone terminal only utilizes GPRS/3G/4G (mobile/cellular network) connectivity.
    What recent changes apply to SAQ B-IP?

    Changes clarifying SAQ eligibility include:

    • The exclusion of not just approved PTS POI devices classified as Secure Card Readers (SCRs) but also devices classified as Secure Card Reader – PIN (SCRPs).
    • Footnote advising merchants using PCI PTS POI devices with expired approval to check the acceptability of the SAQ B-IP with their acquirer or with the payment brands.

    SECURE (ENCRYPTING) CARD READER (SCR)

    An encrypting card reader that either:

    • Is intended for use with a non-secure device, such as a mobile phone or other device; or
    • May be defined as an Original Equipment Manufacturer (OEM) product type to be integrated into a POI terminal or ATM.

    SECURE (ENCRYPTING) CARD READER – PIN (SCRP):

    An encrypting card reader that is intended for use with a commercial-off-the-shelf (COTS) device, such as a mobile phone or tablet.

    See the Approval Class filter on the Approved PTS Device List.

    Recent updates to Requirements

    Confirm certificates used to safeguard Primary Account Numbers (PAN) during transmission over open, public networks are valid and not expired or revoked (4.2.1).

    Note: merchants accepting payments in multiple ways and reporting their PCI DSS compliance under a single portal account or MID (Merchant ID Number) may be able to complete a Composite (or Hybrid) SAQ D assessment, which is a combination of two or more of the above SAQ types that the merchant is individually eligible for.

    • Acceptance: Face-to-face and/or mail/telephone order.
    • Payment method: Virtual payment terminal accessed via an Internet-connected web browser. Merchants manually enter account data from an isolated computing device via a securely connected web browser.
    • The virtual payment terminal solution is provided and hosted by a PCI DSS- compliant TPSP.
    • The computing device does not have any hardware devices attached (e.g., card readers) that are used to capture or store account data.
    • No electronic storage of Account Data (cardholder data and/or sensitive authentication data).
    • No External Vulnerability Scan requirement.
    What recent changes apply to SAQ C-VT?

    The SAQ C-VT, in line with the other v4.X SAQs, now also references ‘merchant’ instead of ‘company’ and ‘account data’ instead of ‘cardholder data.’

    The version 4.X SAQ places more emphasis on the requirement for ‘isolation’ of the computing device used to access the virtual payment terminal than in the version 3.2.1 SAQ:

    • ‘Self-Assessment Questionnaire (SAQ) C-VT includes only those PCI DSS requirements applicable to merchants that process account data only via third-party virtual payment terminal solutions on an isolated computing device connected to the Internet.’
    • ‘Using this solution, the merchant manually enters account data from an isolated computing device via a securely connected web browser.’
    Recent updates to Requirements
    • Implement automated mechanisms to detect and protect against phishing attacks, include phishing and social engineering in security awareness training (5.4.1, 12.6.3.1).
    • Anti-malware solution for removable electronic media (5.3.3).
    • Minimum of 12-character alphanumeric password length, if passwords/passphrases are used to authenticate users and administrators (8.3.6); or minimum of 8 characters if the system does not support 12 characters.
      • Not applicable to application or system accounts, or user accounts on POS terminals that only access one card number at a time to facilitate a transaction.

    Note: merchants accepting payments in multiple ways and reporting their PCI DSS compliance under a single portal account or MID (Merchant ID Number) may be able to complete a Composite (or Hybrid) SAQ D assessment, which is a combination of two or more of the above SAQ types that the merchant is individually eligible for.

    • Acceptance: Face-to-face and/or mail/telephone order.
    • Payment method: Payment application systems connected to the Internet. For example, Point of Sale (POS) systems, other applications/software supporting card payments via the Internet, and some types of mobile payment solutions (mPOS).
    • An External Vulnerability Scan performed by a PCI SSC Approved Scanning Vendor (ASV), at least once every three months, is required. Scanning may not be required for mobile payment solutions (mPOS).
    • No electronic storage of Account Data (cardholder data and/or sensitive authentication data).
    What recent changes apply to SAQ C?

    In line with the other version 4.X SAQs, SAQ C now references ‘merchant’ instead of ‘company’ and ‘account data’ instead of ‘cardholder data’; in all other respects, the v4.x SAQ C eligibility criteria remain unchanged.

    PCI DSS version 4.X has had the greatest impact on the number of Requirements now included in the SAQ C. The majority of the additions affect Requirement 8: ‘Identify Users and Authenticate Access to System Components’ and Requirement 10: ‘Log and Monitor All Access to System Components and Cardholder Data.’

    If the merchant’s POS or payment application system is custom or bespoke software developed and maintained in accordance with the PCI SSC Secure Software Standard and/or the Secure SLC Standard (which together comprise the PCI Software Security Framework) that can help to meet several of SAQ C’s new Requirements from Requirement 6 ‘Develop and Maintain Secure Systems and Software.’ For more details, see the PCI DSS Appendix F ‘Leveraging the PCI Software Security Framework to Support Requirement 6.’

    Recent updates to Requirements
    • Confirm certificates used to safeguard Primary Account Numbers (PAN) during transmission over open, public networks are valid and not expired or revoked (4.2.1).
    • Anti-malware solution for removable electronic media (5.3.3).
    • Implement automated mechanisms to detect and protect against phishing attacks, include phishing and social engineering in security awareness training (5.4.1, 12.6.3.1).
    • Additional requirements for multi-factor authentication (MFA) (8.4.2, 8.5.1).
      • MFA to be implemented for all non-console access into the CDE.
      • Configure MFA systems to ensure they are not susceptible to replay attacks, cannot be bypassed by any users without authorization, use at least two different types of authentication factors, and grant access only after all authentication factors are successful.
    • Review user accounts and related access privileges, including third-party/vendor accounts, at least once every six months (7.2.4).
    • Manage application and system accounts (7.2.5, 8.6.1, 8.6.2, 8.6.3).
    • Minimum of 12-character alphanumeric password length, if passwords/passphrases are used to authenticate users and administrators (8.3.6); or minimum of 8 characters if the system does not support 12 characters.
    • Additional requirements for multi-factor authentication (MFA) (8.4.2, 8.5.1).
      • MFA to be implemented for all non-console access into the CDE.
      • Configure MFA systems to ensure they are not susceptible to replay attacks, cannot be bypassed by any users without authorization, use at least two different types of authentication factors, and grant access only after all authentication factors are successful.
    • Implement automated mechanisms to perform audit log reviews (10.4.1.1).
    • Perform targeted risk analyses to determine the frequency a requirement is performed (12.3.1).
      • Applicable to Requirements 5.2.3.1, 5.3.2.1, 8.6.3, 10.4.2.1.

    Note: merchants accepting payments in multiple ways and reporting their PCI DSS compliance under a single portal account or MID (Merchant ID Number) may be able to complete a Composite (or Hybrid) SAQ D assessment, which is a combination of two or more of the above SAQ types that the merchant is individually eligible for.

    • Acceptance: Face-to-face and/or mail/telephone order.
    • Payment method: Validated, PCI-listed P2PE (Point to Point Encryption) solution. The list of Approved P2PE solutions can be found here on the PCI SSC website.
    • No electronic storage of Account Data (cardholder data and/or sensitive authentication data).
    • No access to clear-text data.
    • Due to the use of a validated P2PE Solution, no External Vulnerability Scan is required.
    What recent changes apply to SAQ P2PE?

    Minor changes have been made to terminology, as noted above for the other version 4.X SAQs, and to further clarify the SAQ P2PE eligibility criteria. A footnote advises merchants using P2PE Solutions with an Expired Validation (as listed on the PCI SSC website) to check their eligibility to complete the SAQ P2PE with their acquirer or with the payment brands, as expired P2PE Solutions are no longer considered ‘validated.’

    The SAQ P2PE Part 2e is specific to the PCI Validated P2PE Solution and better explains the required information using language taken from the Solution’s P2PE listing (e.g., ‘PTS POI Devices Supported’). It also asks for the P2PE Solution Reassessment date.

    Recent updates to Requirements

    Data retention and disposal policies and procedures to cover any Sensitive Authentication Data stored pre-authorization (3.2.1).

    Note: merchants accepting payments in multiple ways and reporting their PCI DSS compliance under a single portal account or MID (Merchant ID Number) may be able to complete a Composite (or Hybrid) SAQ D assessment, which is a combination of two or more of the above SAQ types that the merchant is individually eligible for.

    • Acceptance: Face-to-face only (attended card present payment acceptance only).
    • Payment method: Secure Card Reader-PIN (SCRP) device and commercial off-the-shelf (COTS) mobile device (for example, merchant’s smartphone) used as part of a validated PCI-listed Software-based PIN Entry on COTS (SPoC) solution. The list of approved SPoC solutions can be found here on the PCI SSC website.
    • All account data entry via the SCRP, which must be a PCI-listed approved PTS device included as part of the PCI-listed SPoC solution in use.
    • No electronic storage of Account Data (cardholder data and/or sensitive authentication data).
    • No External Vulnerability Scan requirement.
    What recent changes apply to SAQ SPoC?

    The SAQ SPoC was new with PCI DSS v4.0 and is very similar to the SAQ P2PE – with only one additional requirement – for authentication of the users of the merchant COTS mobile device, e.g. PIN or biometric such as FaceID (8.3.1).

    Recent updates to Requirements

    Data retention and disposal policies and procedures to cover any Sensitive Authentication Data stored pre-authorization (3.2.1).

    Note: merchants accepting payments in multiple ways and reporting their PCI DSS compliance under a single portal account or MID (Merchant ID Number) may be able to complete a Composite (or Hybrid) SAQ D assessment, which is a combination of two or more of the above SAQ types that the merchant is individually eligible for.

    • Acceptance: Any acceptance channel (Face-to-Face/Mail or Telephone Order/E-commerce).
    • Payment method: May be any payment method – relates to all merchants not eligible for any of the above SAQ types. For example, merchants that accept account data on their e-commerce website, store cardholder data electronically, capture account data in call recordings, receive card details via email, etc.
    • An External Vulnerability Scan performed by a PCI SSC Approved Scanning Vendor (ASV), at least once every three months, is required. Additionally, penetration testing and internal vulnerability scanning are required.
    What recent changes apply to SAQ D?

    The SAQ D for Merchants applies to all other self-assessment eligible merchants who do not meet the criteria for any other SAQ type. The examples of merchant environments to which SAQ D may apply are the same as those given in the v3.2.1 SAQ D for Merchants but now referencing ‘account data’ instead of ‘cardholder data’:

    • E-commerce merchants that accept account data on their website.
    • Merchants with electronic storage of account data.
    • Merchants that don’t store account data electronically but that do not meet the criteria of another SAQ type.
    • Merchants with environments that might meet the criteria of another SAQ type, but that have additional PCI DSS requirements applicable to their environment.

    The SAQ D for Merchants supports the completion of either a full or partial assessment as ‘Not Tested’ is an available assessment response, in addition to the ‘In Place,’ ‘In Place with CCW’ (Compensating Control Worksheet), ‘Not Applicable’ and ‘Not In Place’ responses available in the other SAQ types. ‘Not Tested’ means the requirement was not considered in the merchant’s assessment and was not tested in any way.

    A partial assessment is one in which only a subset of Requirements has been assessed; one or more Requirements are marked as ‘Not Tested’. Part 3 of the SAQ D AOC ‘PCI DSS Validation,’ provides space to indicate whether a full or a partial PCI DSS assessment was completed. Appendix D must be used to explain any requirement that was Not Tested.

    Under v3.2.1 a Compliant ‘partial’ assessment was not possible as a ‘Not Tested’ result was not considered an affirmative assessment answer for a Requirement. Now, under v4.X, as long as the merchant subject to the partial assessment has demonstrated compliance with all other Requirements, they can be validated as Compliant.

    The most significant recent updates to Requirements:
    • Data retention and disposal policies and procedures to cover any Sensitive Authentication Data (SAD) stored pre-authorization (3.2.1).
    • SAD stored electronically before completion of authorization is encrypted using strong cryptography (3.3.2).
    • When using remote-access technologies, technical controls prevent copy and/or relocation of PAN for all personnel (3.4.2).
    • Hashes used to render PAN unreadable (per 3.5.1) are keyed cryptographic hashes of the entire PAN (3.5.1.1).
    • If disk-level or partition-level encryption is used to render PAN unreadable, it is implemented only on removable electronic media (3.5.1.2):
      • Or, if used for non-removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1.
    • Confirm certificates used to safeguard Primary Account Numbers (PAN) during transmission over open, public networks are valid and not expired or revoked (4.2.1).
    • Maintain an inventory of trusted keys and certificates used to protect PAN during transmission (4.2.1.1).
    • Anti-malware solution for removable electronic media (5.3.3).
    • Implement automated mechanisms to detect and protect against phishing attacks, include phishing and social engineering in security awareness training (5.4.1, 12.6.3.1).
    • Maintain an inventory of all bespoke software (developed to the entity’s specifications by a third party), custom software (developed by the entity), and third-party software components (6.3.2).
    • Deploy an automated technical solution for public-facing web applications that continually detects and prevents web-based attacks (6.4.2) (removal of the 6.4.1 option to review web applications via application vulnerability assessment tools or methods).
    • Manage payment page scripts to ensure each script is necessary, its use authorized, and its integrity assured (6.4.3).
    • Review user accounts and related access privileges, including third-party/vendor accounts, at least once every six months (7.2.4).
    • Manage application and system accounts (7.2.5, 7.2.5.1, 8.6.1, 8.6.2, 8.6.3).
    • Minimum of 12-character alphanumeric password length, if passwords/passphrases are used to authenticate users and administrators (8.3.6); or minimum of 8 characters if the system does not support 12 characters.
    • Additional requirements for multi-factor authentication (MFA) (8.4.2, 8.5.1):
      • MFA to be implemented for all non-console access into the CDE.
      • Configure MFA systems to ensure they are not susceptible to replay attacks, cannot be bypassed by any users without authorization, use at least two different types of authentication factors, and grant access only after all authentication factors are successful.
    • Implement automated mechanisms to perform audit log reviews (10.4.1.1).
    • Failures of critical security control systems are detected, alerted, addressed, and responded to promptly (10.7.2, 10.7.3).
      • Now including two additional critical control systems: audit log review mechanisms and automated security testing tools (if used).
    • Address all other applicable internal vulnerabilities (that is, vulnerabilities ranked lower than high-risk or critical) based on the risk and associated timeline, defined by a targeted risk analysis (11.3.1.1).
    • Internal vulnerability scans must be performed via authenticated scanning (11.3.1.2).
    • Implement a change- and tamper-detection mechanism to detect and alert unauthorized modification to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser (11.6.1).
    • Security incident response plan (12.10.5) to include monitoring and responding to alerts from the change-and tamper-detection mechanism for payment pages.
    • Perform targeted risk analyses to determine the frequency a requirement is performed (12.3.1).
      • Applicable to Requirements 5.2.3.1, 5.3.2.1, 7.2.5.1, 8.6.3, 9.5.1.2.1, 10.4.2.1, 11.3.1.1, 11.6.1, 12.10.4.1.
    • Document and review cryptographic cipher suites and protocols in use at least once every 12 months (12.3.3).
    • Review hardware and software technologies in use at least once every 12 months (12.3.4).
    • Security awareness program to be reviewed and updated at least once every 12 months (12.6.2), and shall include:
      • Awareness of threats and vulnerabilities that could impact the security of the CDE, including but not limited to: Phishing and related attacks; Social engineering (12.6.3.1).
      • Awareness about the acceptable use of end-user technologies (12.6.3.2).
    • Security incident response procedures to be in place and initiated upon detection of stored PAN anywhere it is not expected (12.10.7).
More resources:

The PCI SSC publishes regular guidance updates here:

https://www.pcisecuritystandards.org/faqs/all/ You can filter FAQs by publication date to see the most recent FAQs.

You can also search FAQs by keyword/topic and or FAQ number:

https://www.pcisecuritystandards.org/faqs/

The PCI SSC also publishes information supplements and guidance documents in the Document Library:

https://www.pcisecuritystandards.org/document_library/ (filter by ‘Guidance Document’).

Topics include: ASV Resource Guide, Multi-Factor Authentication Guidance, Penetration Testing Guidance, Best Practices for Implementing a Security Awareness Program, Skimming Resource Guide, Best Practices for Securing E-commerce, PCI DSS Scoping, and Segmentation Guidance for Modern Network Architectures.

Need more help?

If you need additional assistance, your support options are available on your online portal or program email communications.

Or visit PCI DSS v4.X Resource Hub.