PCI compliance often involves complex scenarios making it difficult to understand how to apply the standard to your environment. Here below are a few questions and answers selected by the QSA. If you have any questions, please sign up on the home page so you can contact the QSA directly and confidentially.
This likely means that the scan tool was blocked. If you can browse to that website then that scan should be reported as an inconclusive scan until you can rescan the open ports. If you cannot navigate a web browser to that website then a "Passing" ASV scan that detected no ports would be the correct finding.
No. From the v4.0 ASV Program Guide (pg. 31): "While only unauthenticated web application scan testing is required, authenticated scan testing is more thorough since user interaction and functionality (such as conducting payment transactions) can be more accurately simulated."
Yes, with approval from your merchant bank. MasterCard has guidance on doing this: "However, low security risk Level 2 merchants completing SAQ B, B-IP, C-VT, C or P2PE may now self-assess without the use of a QSA or ISA for compliance validation." https://www.mastercard.com/content/dam/public/mastercardcom/globalrisk/pdf/Revised_PCI_DSS_Compliance_Requirements_for_L2_Merchants.pdf
Yes. An AOC and responsiblity summary for a serverless PaaS hosting solution removes a lot of compliance burden and covers the ASV scan for the IP address for your web app (if you don't have control of the IP). However, the ASV program guide says that you still need to have an ASV scan on the domain name and not just the IP. Additionally, when you do an ASV scan if there is a finding with a CVSS score of 4.0 or greater, but it is a finding under the responsibility of the serverless PaaS and covered by their AOC then work with your ASV scanner to show that the finding is a false positive and coverend under the PaaS service provider AOC.
No. From the PCI security standards website the FAQ 1485 says "Where an entity is being assessed to a PCI DSS requirement with a defined timeframe for the first time—for example, if the addition of a new payment acceptance channel results in an additional PCI DSS requirement(s) becoming applicable or where a PCI DSS requirement(s) with a defined timeframe is added to a ROC or SAQ—the first assessment of the additional requirement(s) could be considered an initial assessment for that specific requirement(s)." And per the ROC report an initial assessment only requires one passing ASV scan.
Yes. If you are a Level 1 or Level 2 merchant and process 75% or more of your transactions you could be eligible for a card brand program.
VISA Technology Innovation Program: https://usa.visa.com/content/dam/VCOM/download/merchants/tip-participation-application.pdf
MasterCard Validation Exemption Program:
Discover Information Security & Compliance Program:
AMEX Security Technology Enhancement Program:
JCB & UnionPay:
Could not find a similar program for either of these card brands.
Typically, no. A softphone is a headset device that plugs into your computer that works with an VoIP application running on the computer. Receiving cardholder data over that application would bring that system into scope, as well as any systems that are on same network (including the upstream network gear) into scope. So cardholder data received electronically would not meet the merchant eligibility requirements for the SAQ P2PE. However, I have recently reviewed an Amazon Connect solution where they state that "Softphone calls are established to the agent’s browser with an encrypted WebSocket connection using TLS. The audio media traffic to the browser is encrypted in transit using DTLS-SRTP." Testing this setup Amazon Connect threw an error when the headset was uplugged from the workstation. As long as you implement Amazon Connect best practices it could work as a PCI compliant softphone solution (see: https://docs.aws.amazon.com/connect/latest/adminguide/data-handled-by-connect.html)
There are a lot of expensive ways to satisfy a PCI requirement, however here are a few low cost or free options to consider. Something to consider is that Google's ad revenue is dependent on them ensuring that page scripts don't do malicious things to a webpage that would interfere with the display and functionality of their advertising network. Malicious individuals could create a script that would click on an ad in order to fabricate user ad clicks and ultimately erode advertiser confidence. So you can leverage the free tools that Google offers to ensure a page is not running malicious code, malware or other nefarious client-side browser tactics.
6.4.3
You can satisfy this requirement using some Mozilla developer documents, combined with a manual list of scripts and those identified by the Google Search Console URL Inspection Tool.
Method to authorize scripts: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
Method to assure script integrity: https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity
Inventory of all scripts: Manual list compared with Google Search Console URL Inspection Tool (https://support.google.com/webmasters/answer/9012289?hl=en&ref_topic=9456557&sjid=10517685211046521394-NC)
11.6.1
You can satisfy this requirement using a combination of a paid service like VisualPing.io with the Google Search Console.
VisualPing.io: header and page change alerts.
Google Search Console Security Issues Report: https://support.google.com/webmasters/answer/9044101?sjid=10517685211046521394-NC#zippy=