PCI DSS requires entities to perform internal and external quarterly vulnerability scans, identify and address vulnerabilities in a timely manner, and verify through rescans that vulnerabilities have been addressed. In order to achieve these objectives, an entity would need to show “clean” or “passing” quarterly scans for the previous four quarters, for both their external and internal environments. A “clean” or “passing” scan generally has the following characteristics:

• No configuration or software was detected that results in an automatic failure (such as the presence of default accounts and passwords, etc.)
• For external scans, no vulnerabilities with a score of 4.0 or higher on the Common Vulnerability Scoring System (CVSS)
• For internal scans, no “High” vulnerabilities as defined in PCI DSS Requirement 6.2 

 Any cardholder data that is stored, processed, or transmitted must be protected in accordance with PCI DSS. If faxes or emails are sent or received via modem over a traditional analogue phone line, these are not considered to be traversing a public network. On the other hand, if a fax or email is sent or received via the internet, they are traversing a public network and these transmissions must be encrypted per PCI DSS requirements 4.1 and 4.2. Any systems – such as fax or email servers – that the cardholder data passes through must be secured according to PCI DSS. Also, any cardholder data on the fax or email that is electronically stored must comply with PCI DSS requirement 3.4 to render the cardholder data unreadable. In addition, requirement 3.2 prohibits storage after authorization of sensitive authentication data (magnetic stripe, CAV2, CVC2, CVV2, CID and PIN block data). To ensure that prohibited data is not stored if received on a fax (for faxes and emails, this would only be the CAV2, CVC2, CVV2, or CID values printed on the front or back of payment cards), the data should be blacked-out or removed prior to retaining the fax in paper form, and the original fax transmission (via email, etc.) should be securely deleted from the system in a manner which ensures the data is non-recoverable. Entities should also protect paper documents that contain cardholder data in accordance with PCI DSS Requirements 9.6 through 9.10.

Wireless devices are “Dial” because the gateway is certified—we would not scan the “gateway”.  

 PCI DSS applies to any entity that stores, processes or transmits cardholder data. If a merchant outsources all their payment operations, the applicable PCI DSS requirements for the protection of account data would apply to the environment(s) where the data is actually stored, processed and transmitted, such as third party service providers, payment gateways, etc. However, it is the responsibility of the merchant to ensure that the data they share with third parties is properly handled and protected – just because a merchant outsources all payment processing does not mean that the merchant won’t be held responsible by their acquirer or payment brand in the event of an account data compromise. Additionally, the merchant’s acquirer or payment brand may still require the merchant to validate their PCI DSS compliance status. For example, the merchant may be required to complete SAQ A in which the merchant attests that they have outsourced all payment processing services, do not store account data, and that they are compliant with PCI DSS Requirement 12.8. PCI DSS Requirement 12.8 states that merchants must have written agreements with their service providers that include the service provider’s acknowledgement of their responsibility for securing the data in their possession, and also requires that merchants monitor their service provider’s compliance at least annually. Merchants should check with their acquirer or payment brand to determine their compliance obligations when all payment processing is outsourced.

 Network segmentation of, or isolating (segmenting), the cardholder data environment from the remainder of an entity’s network is strongly recommended as a method that may reduce the scope of a PCI DSS assessment. At a high level, adequate network segmentation isolates systems that store, process, or transmit cardholder data from those that do not. Network segmentation can be achieved through a number of physical or logical means, such as properly configured internal network firewalls, routers with strong access control lists, or other technologies that restrict access to a particular segment of a network.An important prerequisite to reduce the scope of the cardholder data environment is a clear understanding of business needs and processes related to the storage, processing or transmission of cardholder data. Restricting cardholder data to as few locations as possible by elimination of unnecessary data, and consolidation of necessary data, may require reengineering of long-standing business practices. Documenting cardholder data flows via a dataflow diagram helps fully understand all cardholder data flows and ensures that any network segmentation is effective at isolating the cardholder data environment. The adequacy of a specific implementation of network segmentation is highly variable and dependent upon a number of factors, such as a given network's configuration, the technologies deployed, and other controls that may be implemented. You should be validating the scope of your cardholder data environment as part of your annual PCI DSS assessment process, including validation of any network segmentation.

The system will scan quarterly. You may Scan on demand should you desire to Scan more often.

PCI DSS Requirement 11.2.2 addresses the need for quarterly external vulnerability scans to be performed by a PCI SSC Approved Scanning Vendor (ASV). The ASV will produce a scan report that details the results of the vulnerability scan – this scan report is not an indication that any other PCI DSS requirements have been reviewed or are in place. ASVs are required to provide scan reports on official templates as defined in the ASV Program Guide. Any additional documentation provided by the ASV (for example, certificates, letters or other documentation) should be clearly identified as supplemental materials provided by the ASV Company – these supplemental materials have not been endorsed by the PCI SSC, nor should they be considered replacements for the official PCI SSC templates and forms which have been approved by the payment brands. 

All merchants, whether small or large, need to be PCI compliant. The payment brands have collectively adopted PCI DSS as the requirement for organizations that process, store or transmit payment cardholder data. PCI SSC is responsible for managing the security standards while each individual payment brand is responsible for managing and enforcing compliance to these standards. For questions regarding compliance validation requirements and deadlines as well as compliance reporting requirements, we recommend that you contact your acquirer. For more information regarding the PCI security standards and supporting documentation, including the “Navigating the PCI DSS” as well as targeted Self-Assessment Questionnaires to assist small and medium merchants, please visit the PCI SSC website at: www.pcisecuritystandards.org 

No, merchants using P2PE solutions are not required to engage a P2PE assessor [that is, a QSA (P2PE) or PA-QSA (P2PE)] for their PCI DSS assessments. Merchants using Council-listed P2PE solutions will continue to validate their PCI DSS compliance as determined by the payment brand compliance programs. For example, a merchant may need to engage a QSA to perform an onsite assessment, or they may be eligible to complete a self-assessment questionnaire (SAQ). Merchants should contact their acquirer (merchant bank) or payment brand directly to understand their validation requirements. Merchants wishing to engage a QSA for their PCI DSS review can find a list of QSAs on the Council website - https://www.pcisecuritystandards.org/approved_companies_providers/qsa_companies.php 

When your scan has completed you will see details under the date of the scheduled Scan hyperlink on the Portal. By clicking that link will lead you to a general overview of the scan and its results. Note that vulnerabilities with a risk level of Medium or higher will cause a scan to be noncompliant. Please contact the Support on the Portal for additional service questions or concerns.

Answer:
You may have unlimited Users associated with your account. Simple add the new user's name, title, and email address to request a new account.

Answer:
The system will save your responses as you go, therefore you do not need to fill out the entire process on your first login.

Answer:
There are services available that can link a hostname to a dynamic IP address. These services, known as dynamic DNS resolution. If you have a dynamic IP address, your best option is to register with a dynamic DNS provider. If you register your dynamic IP address instead of a hostname, you will need to monitor your IP address on a regular basis. At a minimum, you should check that your account has the correct IP address listed before a Scan begins.

Typical Scans may take between 30-60 minutes per IP. However, like all things completed over the Internet times vary based on the speed of your connection and/or how your firewall responds to the Scan tool. This is why we recommend you schedule your Scan after business hours and it can run in the background overnight.

Scanning is required to be completed once every calendar quarter (every 3 months or 4 times per year).  The system will auto schedule your Scans after you have scheduled the first Scan on your own.  If you are enrolled for Scans based on your requirements you may Scan or Re-Scan on the system as often as you like-- daily if desired. 

Answer:
The SAQ was designed to have you make affirmative answers "yes" or perhaps "N/A" with an explanation to meet compliance. Therefore you have failed because you have answered a question as "No". The most important step to take is to review that question and make the changes necessary within your organization to make it so you can honestly answer that question as "Yes". This will be the step needed to make your SAQ compliant. Ultimately to reach compliance, the SAQ must be updated or retaken to demonstrate compliance. Again, if all the questions are answered with "Yes" or "N/A," then you will be considered compliant for this portion of the PCI DSS. Note that if "N/A" is selected for any question, you must include a brief explanation of why this requirement is not applicable.

With a fully compliant SAQ complete your Scan requirement if you have one.  Remember, many merchants are not required to Scan.  With a compliant SAQ you may print or download your certificate for your records.  Remember that you are to update you SAQ should anything change within your business regarding how cardholder data is handled or stored.

If your scan has completed and you are non-compliant on the Portal go to your Merchant Dashboard where you can review your results. Click on the Scan Remediation portion of your Dashboard. Within this section of the Portal details as to what steps to take will be defined. If you get stuck again please call (or email) the support contacts on the Portal for additional assistance.

The scan will not disrupt anything that the merchant would be doing. We do not run any Denial of Service attacks that would take down their systems. If they had an IT person monitoring the scan, the only thing they would generally notice is a bit of a slow-down in their Internet speed as we will be sending traffic over it to conduct the test. Please let them know they can continue to process cards as usual. However, if the merchant for somereason did have a small Internet pipe (dial up or related slower speeds) and did notice any impact to their system during the can, we do have the ability to run the scan at a slower speed to accommodate these instances when needed. They would need to contact us for additional support to accommodate this need. But in all, the system is designed to run during production times and we generally see limited issues with our clients if any issues at all.

A payment application is a commercial application that stores, processes, or transmits cardholder data as part of authorization or settlement. A common example of a payment application is the software running on a point of sale (POS) terminal. To obtain details about a payment application on a POS, please contact the point of sale terminal provider or your acquiring bank (merchant bank). 

 YES. Remember there are other requirements within the SAQ such as Policies from Requirement 6.6 and requirement 11.3. Additionally SAQ’s are only due once per year if no changes are made in how you accept credit card payments—if this changes the SAQ must be updated. Also, Scans are quarterly so the system will schedule and run these throughout the year. Lastly, Compliance is an on-going fluid process, use the tools provided by this Portal as a springboard toward training and supervising proper credit card security within your organization.

These are locations which handle card holder in an identical manner with the same ownership and doing business as name. This enables merchants to complete one SAQ which would apply to multiple locations. 

This means there are merchant locations which share a single login credentials. This is for the merchant to have convenience in viewing multiple businesses with a single login. 

 Keep in mind that the general idea of the Security Council regarding PCI DSS is to provide a platform where the Card Brands can reach across the layers of entities (Banks, Processors, ISOs, and Sales Representatives) to directly communicate with the merchant. The requirement of the ISO is to provide the Self-administered tools set to the merchant-- that is all. The tools must provide the merchant the ability to complete their PCI DSS steps which include the Self-Assessment Questionnaire (SAQ) and a Scan provided by an Approved Scan Vendor (ASV). By providing the merchant with access to these tools the ISO has gone a long way toward fulfilling their role in PCI DSS.

Any fines and/or penalties associated with non-compliance with the PCI DSS and/or confirmed security breaches are defined by each of the payment card brands. For more specific information, please contact the individual payment card brands. 

Answer:
If your merchant bank or service provider requests proof of your compliance, please contact the support person indicated on the Portal to request a Letter of Compliance. Our team will take a cursory review of your account and provide you with a letter that details what you have done to validate your compliance.

 Data Security Standard

PCI DSS focuses on the protection of cardholder data throughout the transaction process whether in a retail environment or over the internet, or anywhere in between. The payment card industry is more diverse today than ever. Each day new payment applications expand the methods on how consumers can use the credit cards to purchase goods and services. 

 Payment Card Industry

It is when an ASV (Approved Scanning Vendor) scans your IP address and/or website to check for any “vulnerabilities”. Vulnerabilities are essentially “holes” in the system hackers can use to gain unauthorized access. The scan usually includes your websites, IP address, referred to as an outward facing IP address. If you transfer your customers to a third-party shopping cart during the checkout process, then you should include their IP address to be scanned as well. This is very important because you could be held liable for potential fines should an unauthorized individual gets a hold of your client's payment card information anywhere along the transaction process. 

This is the home page of the PCI Compliance Portal. 

Answer:
A hostname is an IP address name. This makes it easier to remember than the IP address itself which is numbers. If your business desires a means to be reached on the Internet then you will typically have a hostname registered for your IP address.

The P2PE solution provider is a third-party entity (for example, a processor, acquirer, or payment gateway) that has overall responsibility for the design and implementation of a specific P2PE solution, and manages P2PE solutions for its merchant customers.The solution provider has overall responsibility for ensuring that all P2PE requirements are met, including any P2PE requirements performed by third-party organizations on behalf of the solution provider (for example, certification authorities and key-injection facilities). Please refer to the P2PE Standard and P2PE Program Guide for further information. 

This is the company which processes your credit card transactions 

This is an "approved scan vendor". The vendor we use to complete your Scan requirement for partial PCI DSS Compliance. Approved Scan Vendors can be verified on the www.pcisecuritystandards.org website. 

This is an optional protection policy which covers dollars in the event of a PCI event and subsequent forensic investigation and/or fine. See your Processor for details on availability of this protection if desired. 

Answer:
Getting your proper IP address or hostname is very important to perform your vulnerability scans correctly. Our system will guide you toward determining your IP Address as you complete the security tests. Or you can visit www.whatismyip.com, from the computer that processes payment cards and it will show you the IP address for that Public Network.

Answer:
Computer on a network have an address (similar to an address of a home or business) which identifies where it can be found by other computers on the Internet. This number will be formatted using four numbers separated by dots (e.g., x.x.x.x), and this is your IP address.

 

Answer:
There are services available that can link a hostname to a dynamic IP address. These services, known as dynamic DNS resolution. If you have a dynamic IP address, your best option is to register with a dynamic DNS provider. If you register your dynamic IP address instead of a hostname, you will need to monitor your IP address on a regular basis. At a minimum, you should check that your account has the correct IP address listed before a Scan begins.

This is a unified security standard all card brands agreed such as Visa, MasterCard, Discover and others to use as security steps to protect card holder data. 

Answer:
For the Scan performed on your system we will need only your external IP address (or your public IP address) because we'll be testing only the outside (outward facing side) of your network. A private IP address is all the various computers on the Network "inside" your office. These are not Scanned in these PCI security tests.

Answer:
A Static IP address is always the same and assured to never change while a "dynamic" IP address means your IP address may change over time (such as during resets or power surges or periodically). The frequency with which a dynamic IP address changes will depend on the practices of your Internet Service Provider.

 

The PCI Data Security Standard represents a common set of industry tools and measurements to help ensure the safe handling of sensitive information. Initially created by aligning Visa's Account Information Security (AIS)/Cardholder Information Security (CISP) programs with MasterCard's Site Data Protection (SDP) program, the standard provides an actionable framework for developing a robust account data security process - including preventing, detecting and reacting to security incidents. The updated version, version 1.1, developed by the founding members of the PCI Security Standards Council, became effective with the launch of the PCI Security Standards Council. 

The PCI Data Security Standard Self-Assessment Questionnaire is a validation tool intended to assist merchants and service providers who are permitted by the payment brands to self-evaluate their compliance with the Payment Card Industry Data Security Standard (PCI DSS). There are four versions of the PCI DSS SAQ to choose from to meet your business need. See “Selecting the SAQ and Attestation that Best Apply to Your Organization” in the Self- Assessment Questionnaire Instructions and Guidelines. https://www.pcisecuritystandards.org/documents/pci_dss_saq_instr_guide_v2.0.pdf 

The PCI Point-to-Point Encryption (P2PE) Standard contains detailed security requirements and testing procedures for application vendors and providers of P2PE solutions to ensure that their solutions can meet the necessary requirements for the protection of payment card data. Version 1.1 of the P2PE Standard contains security requirements and testing procedures for third-party, hardware-based P2PE solutions. Subsequent releases of the P2PE program will address requirements for securing software-based decryption and key management operations, as well as scenarios where merchants manage their own cryptographic keys. P2PE assessors and PA-QSA are qualified by the Council to evaluate P2PE solutions and applications. 

Answer:
The Scan is designed to have a minimal effect on your network. The scans can be run during regular business hours and have little impact. The system is automated and maybe set to Scan after business hours if desired.

Please refer to the “Selecting the SAQ and Attestation that Best Apply to Your Organization” section in the PCI DSS SAQ Instructions and Guidelines document for information about the different SAQs and the types of environments that each SAQ is intended for. Merchants should also consult with their acquirer (merchant bank) or payment brand to determine if they are eligible or required to submit an SAQ, and if so, which SAQ is appropriate for their environment. 

45.33.64.15
69.164.195.28
69.164.203.238
69.164.207.99
45.79.22.69
45.79.22.70
45.56.64.216
45.56.66.52
45.56.70.138
173.255.200.220