PCI DSS V4.0 Frequently Asked Questions
- PCI DSS stands for the Payment Card Industry Data Security Standard.
- PCI DSS compliance is mandatory for any business that accepts credit and debit cards.
- It is a set of technical and operational requirements set by the PCI Security Standards Council (SSC) to protect payment card data.
- Merchants need to show to their acquiring banks or payment service providers that they are processing the payments in such a way that does not leave their business at risk of a data breach, in line with the PCI DSS Compliance Programs set out by the card schemes (VISA, Mastercard etc.).
Version 4.0 marks the first significant change to the standard in nearly a decade. It is a response to both changes in technology and the evolving threat landscape facing businesses today. It aims to better support businesses in their efforts to secure payment card data and improve security measures to protect against potential risks.
There are some new requirements for certain business types and some requirements have been removed. In addition, many of the existing requirements now include new controls. What will change for your business depends on your SAQ (Self-Assessment Questionnaire) type.
How these changes impact you will be determined by your Self-Assessment Questionnaire SAQ type. The portal journey has been updated to ensure that all changes have been factored in, to ensure that you are reporting against version 4.0.
Once you have completed your business profile on the portal, your SAQ type will be displayed on your dashboard, under “Your business profile, SAQ type” see image below. It is important that you answer as accurately as possible.
Portal Dashboard showing SAQ Type – This business is SAQ Type B-IP.
The portal will guide you through the changes. As you may have some new requirements, we recommend starting your assessment as early as possible in advance of your renewal date. If you need assistance, you can reach out to us using the support information available on your portal or email communications.
From within our portal, you can validate against the current version of the standard version 4.0, up until the date that version 4.0.1 is implemented. After the update has been applied and version 4.0.1 is available, your reporting journey will be against version 4.0.1 of the standard. If you do have a valid Attestation of Compliance (AoC) for version 4.0 that you wish to upload, you can do so up until version 4.0 is retired.
If you have started but not completed your compliance journey, you will need to restart once version 4.0 is implemented.
Completing version 4.0.1 assessment may take longer due to newly applicable requirements. It may help to be prepared in advance – know who to call in relation to the set up and security of your payment systems e.g., your eCommerce website, point-of-sale system etc.
No, some of the more advanced new requirements are designated with a future date to give businesses extra time to complete their implementation. Requirements that are future dated are considered as best practice until March 31, 2025, at which point they become effective. To remain compliant you must implement all applicable new requirements on or before the March 31, 2025. After this date, these requirements become mandatory. You will receive ample notification with instructions to help you meet future dated requirements applicable to your SAQ type.
Yes, you can.
If your third party’s PCI DSS assessment is current (that is, completed within the last 12 months) and was against the version of the PCI DSS current at the time of that assessment (so v3.2.1), then your assessor may mark as “Not Applicable” those Requirements for which you rely upon the TPSP but for which they have not yet been assessed.
The other scenario is where your TPSP has been assessed to version 4.0 but that assessment was completed prior to the effective date of new Requirements. Those future-dated new Requirements – that the TPSP will be responsible for meeting on your behalf – were not included in the TPSP’s assessment; they are marked as Not Applicable. Which means for your own assessment, those new Requirements for which you will rely upon the TPSP can again be marked as ‘Not Applicable’ by your own assessor.
There are a couple of FAQs that explain the scenarios here: FAQ 1282 and 1564.
Yes, If your website uses a URL redirect/embedded iFrame you will need to complete ASV scanning. ASV or External Vulnerability Scans is a non-intrusive website scan, that helps identify vulnerabilities that may lead to a compromise of your customers’ card data.
If you are currently required to complete External Vulnerability Scanning, there are no changes. You will continue to scan and attest to your scans in exactly the same way. Please note, that some Ecommerce merchants who are classified as SAQ A may be required to perform External Vulnerability Scanning for the first time. If your website uses a URL redirect/embedded iFrame you will need to complete ASV scanning. If you are unsure, please check with your web developer. If scanning is required, you will receive detailed instructions.
If you meet the requirements for an External Vulnerability Scan, you must obtain a new scan within 90 days of a significant change to your website or web servers.
Note: The target environment for the external vulnerability scans must include your ecommerce web redirection servers.
Historical records relating to previously attested, completed/submitted SAQ and scan documentation will continue to be available from within the scan and SAQ widgets on your merchant dashboard, as they are today.
Where applicable, policy and procedure templates have been updated. We recommend you review your existing policy and procedure documents and update them if necessary.
Each question in the Self Assessment Questionnaire (SAQ) has supporting guidance and applicability notes. If you need additional assistance, you can reach out to us using the support information available on your portal or email communications.
In PCI DSS version 4.0 question 8.3.6 states that password complexity will require a minimum length of twelve characters (where twelve characters are supported, otherwise a minimum of eight characters is required), however this is a future dated requirement, best practice until after 31st March 2025. Until then, the PCI DSS version 3.2.1 version of this same requirement (8.2.3) should be applied.
8.2.3 asks: (a) Are user password parameters configured to require passwords/passphrases meet the following? – A minimum password length of at least seven characters – Contain both numeric and alphabetic characters Alternatively, the passwords/passphrases must have complexity and strength at least equivalent to the parameters specified above.
The version 4.0 SAQ question itself does not include any text from the version 3.2.1 question, and only refers to it in the applicability notes. Therefore, we have included a screen in the profile, that is presented to merchants of the following SAQ types: D, A-EP, C, C-VT and A.
“Do you enforce a minimum password length of seven characters, containing both numeric and alphabetic characters, for user accounts on all POS devices, computers and systems in your business?”
If the question is answered ‘Yes’, we auto-answer SAQ question 8_3_6 as ‘Yes’ and present a pop-up advising it is best practice until 31st March 2025.
Pop-up alert if answered yes: Please note: this is best practice until 31st March 2025, after which password complexity will require a minimum length of twelve characters (where twelve characters are supported, otherwise a minimum of eight characters is required)
If the question is answered ‘No’, we do not auto-answer SAQ question 8_3_6 and instead you will need to respond to this question directly in the SAQ.
Yes, all answers previously provided as part of your profile will be retained following the update so you can review what was previously submitted. You will be able to change these answers as you progress through the profile should anything with respect to how you store, process and/or transmit payment card data have changed. Depending on your processing methods, you may be asked additional questions that may or may not change the outcome of your subsequent profile questions, your SAQ type, SAQ auto-answering effects and requirement to perform ASV scanning on your environment.
On completion of your business profile, we will determine what answers from your previous assessment can be mapped and applied to the same or similar question in the current version so you do not need to answer those questions again.
There are exceptions to this:
- If we detect a change in SAQ type following completion of your business profile
- If you previously indicated that you are not compliant with a particular requirement, you will be required to re-assess and provide a response to that question again.
- Any of your previous assessment questions that were auto answered by the system, because of how you answered your business profile, will not be retained with the new version. However, on re-completion of your business profile, a new set of auto-answer effects will be applied to your current assessment based on the new rules defined for the current version of your PCI DSS SAQ(s).
- If your previous assessment was against PCI DSS v3.2.1, then we will only apply your previous answers where they are applicable to your assessment under the current version. For example, multiple version 3.2.1 requirements were merged into a single requirement in the latest version, so we will only apply your previous answers if all answers to the now merged questions were the same.
SAQs can be broken into categories based on what a business uses to take payments.
- Acceptance: E-commerce and/or MOTO
- E-commerce: Website is fully outsourced, or they are using an iFrame or re-directed payment page
- MOTO: May outsource their payments to a Call Centre or mail ordering service
- Pay by link: Merchants can send their customers a secure link which is supplied by a PCI compliant third party provider, this allows customers to safely input their card details and submit them to the payment service provider
- Payments are fully outsourced to a PCI Compliant third-party service provider
- No electronic storage of Account Data (cardholder data and/or sensitive authentication data)
- An external vulnerability scan is required if your website uses a URL redirect/embedded iFrame.
- Acceptance: E-commerce only
- Merchants website controls how cardholder data is re-directed (The website does not receive cardholder data but controls how customers/data are redirected to a PCI compliant 3rd party provider)
- Silent post is used to transport data to PSP which results in unnecessary storage – (potential storage)
- Risk reduction to be provided: need to have an iFrame or hosted re-directed payment page in place
- SAQ goes back to the merchant or web developer if they do not want to take on the risk reduction advice
- Scan requirement on the domain (www.test.com)
- Acceptance: F2F and/or MOTO
- POS Setup: Standalone terminal connected to the phone line
- No electronic storage of Account Data (cardholder data and/or sensitive authentication data)
- No external vulnerability scan requirement
- Acceptance: F2F and/or MOTO
- POS Setup: Standalone terminal connected to the internet
- No electronic storage of Account Data (cardholder data and/or sensitive authentication data)
- An external vulnerability scan is required
- Acceptance: F2F and/or MOTO
- POS Setup: Standalone terminal connected via a SIM card
- No electronic storage of Account Data (cardholder data and/or sensitive authentication data)
- No external vulnerability scan requirement
- Acceptance: F2F and/or MOTO
- POS Setup: Access to a virtual terminal provided by a PCI compliant third-party
- No electronic storage of Account Data (cardholder data and/or sensitive authentication data)
- No external vulnerability scan requirement
- Acceptance: F2F and/or MOTO
- POS Setup: iPOS/ePOS system
- Scan is required for an IPOS/EPOS system
- No electronic storage of Account Data (cardholder data and/or sensitive authentication data)
- Risk reduction: If the merchant has an iPOS/ePOS they cannot be using the batch settlement file feature with full credit card numbers.
- Acceptance: F2F and/or MOTO
- Mobile phone or tablet with POI (Point of Interaction) device attached
- No electronic storage of Account Data (cardholder data and/or sensitive authentication data)
- No external vulnerability scan if it is a mobile/tablet with an application
- Risk reduction: A merchant using a mobile phone or tablet needs to have a POI device attached.
- Acceptance: F2F and/or MOTO
- POS Setup: iPOS/ePOS system that is a P2PE (Point to point encryption) hardware solution (must be on the list of approved solutions)
- No electronic storage of Account Data (cardholder data and/or sensitive authentication data)
- Due to the level of encryption on these terminals, no external vulnerability scan is required
- Acceptance: Any acceptance channel (Face to Face/MOTO/Ecommerce)
- POS Setup: Multiple POS setups under one MID
- No electronic storage of Account Data (cardholder data and/or sensitive authentication data)
- An external vulnerability scan may or may not be required depending on the SAQs assigned within the composite
- ISP (Information security policy) question will not come up in this profile path, so make sure you inform, ask and explain how to implement ISP.
- Acceptance: Any acceptance channel (Face to Face/MOTO/Ecommerce)
- POS Setup: Any POS setup
- An external vulnerability scan is required
- SAQ D merchants indicate high-risk behavior.
There are many examples of high-risk behavior, below is a list of the most common:
- Accepting CHD or SAD by email
- Storing CHD or SAD electronically
- Custom built iPOS/ePOS system
- Directly integrated payment page on customer facing website
- No POI device attached with mobile device or tablet
- Batch settlement files with the full PAN
- Recording calls with account data
- Fax server that converts faxes to emails