Overview: This Implementations resource provides information on PCI compliance and security best practices.
Table of Contents
Customers are responsible for making their own independent assessment of the information contained in this document. This document is solely for informational purposes and does not create any commitments or assurances from Payrix and its affiliates, suppliers, or licensors. This document does not contain an exhaustive list of prevailing security best practices and Customers are responsible for determining the most appropriate safeguards to institute for their organization. Customers are encouraged to review authoritative guidance set forth by the card networks, PCI Security Standards Council, and other applicable regulatory bodies to ensure that they fully understand the applicability of security and privacy requirements to their operations.
What is PCI-DSS?
As detailed on the PCI Security Standards site the Payment Card Industry Data Security Standard (“PCI DSS”) is a set of requirements for enhancing payment account data security. These standards were developed by the PCI Security Council (founded by American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc.) to facilitate industry-wide adoption of consistent data security measures on a global basis. The standard aims to increase awareness and promote best practices in the handling of sensitive information to minimize identity theft and fraudulent transactions.
Merchants can fall into different categories depending on the volume of transactions:
Level 1: Merchants that process over 6 million card transactions annually.
Level 2: Merchants that process 1 to 6 million transactions annually.
Level 3: Merchants that process 20,000 to 1 million transactions annually.
Level 4: Merchants that process fewer than 20,000 transactions annually.
Depending on the category that a Merchant falls under they will have specific compliance validation requirements as set forth by the card networks. For example, VISA’s validation requirements can be seen here.
In addition to the above information, some notable frequently asked questions (FAQs) to pay attention to, as illustrated by the PCI Security Standards Council are below.
Frequently Asked Questions (“FAQs”)
Scope and Applicability
I use a redirect to facilitate transactions. Do I still need to be PCI Compliant?
A technology setup that involves relying on a PCI-Compliant third-party provider that you redirect to will still require consideration for what may be in scope for PCI. As detailed in PCI Scoping Guidance there are two types of systems:
CDE Systems - System components that store, process or transmit Cardholder Data or Sensitive Authentication Data or system components that are on the same network segment. (e.g. subnet, VLAN, et al.)
Connected-to and/or Security-Impacting Systems - Among other things consists of system components that can impact the configuration or security of the CDE, or how CHD/SAD is handled. The example used is a web redirection server or name resolution server.
To use an example, in a setup where a web server uses a redirect it could be considered a Connected-to and/or Security-Impacting System that must satisfy applicable PCI requirements. Even though that server is not processing, transmitting, and/or storing any Cardholder Data the compromise of that server, for example, can directly impact how Cardholder and/or Sensitive Authentication Data is handled as well as the definition of what is in the Cardholder Data Environment.
It is important to consider Connected-to and/or Security-Impacting Systems as well as PCI Scoping Guidance to ensure that you do not unintentionally overlook scenarios that may require PCI requirements to be in place.
I only process a few hundred dollars a month. Does my merchant account still need to be PCI compliant?
Yes. All merchants, small or large, are required to be PCI compliant. The payment brands have collectively mandated PCI DSS compliance for any and all organizations that process, store, or transmit payment cardholder data. Inherent in having a merchant account is the ability to handle cardholder data.
I do not use the internet to process credit cards, do I still have to be PCI Compliant?
Yes. All merchants that store, process, or transmit cardholder data are required to comply with the PCI DSS, regardless of the medium in which they operate (hard copy or electronic) or method in which they communicate the data (IP, analog, cellular, or satellite).
Do I need to make all my accounts compliant?
Yes. Any division of a business that stores, processes, or transmits cardholder data must comply with the PCI DSS. However, if an entity has multiple merchant accounts that have the same network configuration, operate according to the same information security policies and procedures, and utilize the same equipment, they may be able to assess all locations under one SAQ.
How do I determine my compliance validation method?
As detailed in the PCI DSS FAQs merchants and service providers should always consult with their acquirer (merchant bank) or payment brand directly, as applicable, to confirm their PCI DSS validation and reporting method (e.g. whether to complete an onsite assessment and Report on Compliance (ROC), or a self-assessment and SAQ).
How should I handle sensitive data?
Sensitive data received from customers must be cleared to limit the exposure of PCI Data. These are the best practices for all parties who are dealing with sensitive information:
If a credit card number or bank account number is sent to you, you should delete the record of the attachment or email
When referring to a sensitive number, replace the center numbers with Xs. For example, a card number could be 4050-XXXX-XXXX-1234 or an SSN/TIN XX-XXX-1234
Will request a new record/ticket without the full PAN data
These are the best practices for all parties who are dealing with sensitive information:
If a merchant requests full PAN data, politely decline to provide the information
Self Assessment Questionnaire (“SAQ”)
What is the PCI DSS Self-Assessment Questionnaire?
The PCI DSS Self-Assessment Questionnaires (SAQs) are validation tools for merchants and service providers that are eligible to evaluate and report their PCI DSS compliance via self-assessment. There are a number of different SAQs available that are intended to meet the needs of particular types of environments. The PCI Security Standards Council makes resources available here with guidance on how to successfully complete.
Why am I being asked to complete this questionnaire?
All merchants accepting payment by credit or debit cards are required to comply with PCI DSS. This website provides the tools needed to achieve compliance with the least amount of time, effort, and expense.
What happens if I do not complete this questionnaire?
Merchants are contractually required to comply with the PCI DSS as part of their processing agreement to accept card payments with the Card Networks. Failure to meet the contractual obligations may result in the payment provider assessing fees, suspending the ability to process transactions, and/or termination of the agreement.
How do I renew my questionnaire?
The questionnaire can be renewed either by clicking on the Re-Assess button, if available or by completing a new SAQ. SAQs are valid for one year from the date they are submitted.
What is an EMV card?
EMV (Europay, MasterCard, and Visa) cards or “chip” cards have chips embedded in the card that is utilized much like the magnetic stripe in traditional cards. If a terminal is certified to read the chip and uses this functionality, the merchant is considered to be EMV compliant.
Am I allowed to select the PCI Compliance Team who does my compliance?
Unless your payment provider has other regulations in place, you can select any vendor to become PCI compliant.
What are the penalties for being non-compliant?
All merchants are required to be PCI DSS compliant. Refusal to comply may result in fines or the loss of the ability to accept debit and credit cards.
What is an ASV scan?
An ASV scan is a non-intrusive external scan against the public address of a merchant's card processing network. The scan checks for open TCP & UDP ports at the network gateway and tests for vulnerabilities and common misconfigurations which could put card data at risk. Additional information about the ASV scan can be found in the ASV Program Guide which is available from the PCI SSC website: https://www.pcisecuritystandards.org/documents/ASV_Program_Guide_v3.0.pdf.
Becoming PCI Compliant
What are the steps to compliance?
PCI security for merchants and payment card processors is the vital result of applying the information security best practices in the PCI DSS. The standard includes 12 requirements for any business that stores, processes, or transmits payment cardholder data. These requirements specify the framework for a secure payment environment. For PCI compliance purposes, there are three steps: Assess, Remediate, and Report.
To Assess is to take an inventory of your IT assets and business processes for payment card processing and analyze them for vulnerabilities that could expose cardholder data. Remediation is the process of fixing those vulnerabilities. Reporting entails compiling records required by PCI DSS to validate remediation and submitting compliance reports to the acquiring bank and global payment brands you do business with. Carrying out these three steps is an ongoing process for continuous compliance with the PCI DSS requirements. These steps also enable vigilant assurance of payment card data safety.
Step 1 – Assess
The primary goal of the assessment is to identify all technology and process vulnerabilities that pose risks to the security of cardholder data being transmitted, processed, or stored by your business. The Payment Card Industry Data Security Standard (PCI DSS) contains detailed requirements describing IT infrastructure and processes that access the payment account infrastructure. Determine how cardholder data flows from beginning to end of the transaction process – including PCs and laptops that access critical systems and storage mechanisms for paper receipts, etc. Check the versions of Personal Identification Number (PIN) entry terminals and software applications used for payment card transactions and processing to ensure they have passed PCI compliance validation.
Note: As your liability for PCI compliance extends to third parties involved with your process flow, you must also confirm that they are compliant. A comprehensive assessment is a vital part of understanding what elements may be vulnerable to security exploits and where to direct remediation.
Self-Assessment Questionnaire (SAQ) – The SAQ is a validation tool for merchants and service providers who are not required to do on-site assessments for PCI DSS compliance. Eight SAQs are specified for various situations.
Qualified Assessors – The Council provides programs for two types of independent experts to assist with your PCI assessment: Qualified Security Assessor (QSA) and Approved Scanning Vendor (ASV). QSAs have trained personnel and processes to assess and prove compliance with the PCI DSS. ASVs perform vulnerability scans for your systems.
Step 2 – Remediate
Remediation is the process of fixing vulnerabilities. This includes both technical flaws in software code and unsafe practices in how an organization processes or stores cardholder data.
Review and remediate vulnerabilities found in on-site assessment (if applicable) or through the Self-Assessment Questionnaire process.
Scan your network with software tools that analyze infrastructure and spot known vulnerabilities.
Classify and rank the vulnerabilities to help prioritize the order of remediation, from most serious to least serious.
Apply patches, fixes, workarounds, and changes to unsafe processes and workflow.
Re-scan to verify that remediation occurred.
Step 3 – Report
Regular reports are required for PCI compliance. These are submitted to the acquiring bank and global payment brands that you do business with. The Payment Card Industry Security Standards Council (PCI SSC) is not responsible for PCI compliance. All merchants and processors that are required to scan must submit a quarterly scan report completed by a PCI SSC Approved Scanning Vendor (ASV). Businesses with large flows must do an annual on-site assessment completed by a PCI SSC approved QSA and submit the findings to each acquirer. Most merchants are required to submit an annual Review and Sign within the Self-Assessment Questionnaire. You will be notified by your payment processor if an onsite assessment is required.
The Office of Foreign Assets Control (“OFAC”) within the U.S. Department of the Treasury governs and enforces economic and trade sanctions in accordance with U.S. policy. These policies may be specific to countries, regimes, terrorists, and other organizations or individuals as illustrated on the Treasury’s website. As detailed in Payrix Web Application Firewall Considerations Payrix implements certain controls to block traffic originating from certain geographic locations as part of Payrix’s OFAC Compliance program.
As part of shared responsibilities between Payrix and its Customers, OFAC Compliance controls must also be implemented by Customers who use Payrix Products and Services as part of their own OFAC Compliance Programs. Depending on how Customers are integrated with Payrix’s Products and Services this could include controls such as the following:
Web Application Firewall - similar to how Payrix leverages a Web Application Firewall, Customers can also procure and configure this type of solution to block traffic originating from certain geographic locations.
Application Logic - solutions could be developed to prevent any transactions associated with flagged geographic locations from processing without additional oversight and intervention.
Regular Transaction Reviews - transaction data can be reviewed on a regular basis to ensure that other controls are operating effectively and that transactions are being blocked or flagged as necessary.
Note: The above list is not exhaustive nor should it be interpreted as such. It is up to Customers to make their own determinations and tailor their OFAC Compliance controls to fit their organization and operating environment.
Additional Security Best Practices
The following sections illustrate a set of security best practices based on cyber threat trends applicable to the payments industry as well as prevailing threats applicable to all industries. Prior to covering the material, it can be useful to review resources published by industry leaders to get an idea of trends in security threats including, but not limited to, the following:
Brian Krebs - KrebsOnSecurity
Verizon - Data Breach Investigations Report
Note: These are just a few of many resources available publicly and that they may be updated from time to time with more current, relevant, information and content.
What is an endpoint?
For the purposes of this section, an endpoint is any device that can be used to process, transmit and/or store data or connect to or facilitate connections to other devices that may contain data and interconnectivity elsewhere. Common examples include laptops, mobile phones, printers, and tablets.
Why are endpoints relevant to information security?
Today’s interconnected world of what is often referred to as the Internet of Things (“IoT”) consists of devices containing devices running technologies to foster beneficial things like connectivity, productivity, and other aspects that are desirable by consumers. As a result, it has created an increasingly complex environment relative to information security due to the nature of how devices work, the state of the key technologies supporting those devices, and how humans interact with them.
To provide a more relatable example, in the fall of 2016 there was a distributed denial of service (“DDoS”) attack that rendered a sizable portion of the internet's backbone unusable. This attack was carried out by spreading malware to IoT devices such as cameras, baby monitors, printers, and routers to, in turn, flood internet infrastructure with a denial of service attack. The result was that business operations contingent on reliable internet came to a halt.
All of that said, endpoints are relevant in that they are internet-connected devices that, if compromised or used maliciously, can result in the unauthorized access to, disclosure of, modification of, or destruction of data as well as impairment of other devices or systems. When this type of undesirable occurrence takes place within an organization it can be quite disruptive and may result in regulatory proceedings, fines, etc.
What are some risk mitigations I can put into place for endpoints?
There are many options and approaches that can be pursued when trying to mitigate risks associated with endpoints. Below are several common approaches:
Inventory - establish a reliable inventory of devices to have as complete of a view on how many devices exist, how they are being used, and by whom.
Antivirus and Antimalware - deploy anti-virus and anti-malware solutions to detect and mitigate malware that presents itself on devices. There are solutions available today that also take more of an Artificial Intelligence and behavioral approach to detecting and mitigating threats applicable to devices.
Mobile Device Management - leverage a management solution to centrally deploy security configurations and technologies to all devices. This type of solution is often paired with antivirus and antimalware technologies and used as the bridge between the device and the technology.
Interacting with Payrix Staff
Support and Implementation teams will only ever communicate with Payrix Clients over email using ‘payrix.com' email addresses. Should you receive any communications from other domains that are attempting to engage in business activities with you please reach out to us immediately for review and any required action(s) deemed necessary. Further, in the course of providing support to Client's Payrix will never ask for sensitive information such as credentials (e.g. passwords).
In the event that you receive an unscheduled phone call from Payrix Staff requesting access to Confidential Information or that you take action on any of your systems or Payrix’s Products and Services please leverage the Support Portal to confirm that it is a valid Support activity. This portal can also be used for any other potentially suspicious behaviors that you observe.
What is Social Engineering?
Social engineering is a set of techniques used by malicious individuals to attempt to manipulate human psychology in order to achieve specific goals. Phishing is common when someone sends an urgent email to an individual with limited technological proficiency instructing them to provide payment to free their loved one from jail abroad or to click a link that routes them to a malicious site asking them to enter their login credentials. Other forms include attempting to gain physical entry to areas of a facility containing confidential information through manipulation of individuals or phone calls to individuals trying to trick them into providing sensitive information over the phone.
What are some risk mitigations I can put into place?
Identifying some training resources appropriate to your organization to have Staff review on an annual basis is a good place to start. There are a number of free resources available online that provide basic training on how to detect and thwart Social Engineering attacks.
Additionally, given how common phishing attempts have become, it is best practice to review email provider capabilities to determine the types of protections that can be put in place to mitigate against phishing attacks and deploy any mitigations determined to be appropriate and feasible.
How do I identify phishing attacks?
Malicious individuals use various spoofing techniques to trick users into believing an email is legitimate. Common themes include, but are not limited to, the following:
Enticing, urgent, or threatening language is commonly used to encourage the recipient to take immediate action.
Grammatical errors are an obvious red flag, but sophisticated hackers do not make glaring errors.
Emails including attachments.
Other things to consider:
Before clicking, hover over the link to see the URL of where the link actually leads, and beware of link shorteners, such as Bitly or TinyURL. Keep in mind that phishing emails can include clean URLs in addition to the phishing URL to trick users and email filters.
Pay special attention if a message states “I can’t talk right now” or “call me at this number instead”
Cybercriminals can easily replicate brand logos, images, and badges in emails and web pages that are indistinguishable from the real thing.
For further tips or examples, check out the Federal Trade Commission’s Phishing Guide.
Multi-Factor Authentication (“MFA”)
What is Multi-Factor Authentication?
Multi-Factor Authentication is authentication using two or more different factors to achieve authentication. Factors include: (i) something you know (e.g., password/PIN); (ii) something you have (e.g., cryptographic identification device, token); or (iii) something you are (e.g., biometric).
Shouldn’t a strong password be enough?
The unfortunate reality is that passwords alone are often not sufficient enough to prevent your or your users’ accounts from being compromised. With advancements in computing and technology, it has become much easier to carry out brute force or other password-specific attacks to gain unauthorized access to someone’s account. A strong password policy is important, however, by itself is not always sufficient to prevent an account compromise
Why is MFA important?
MFA is a simple step that can be leveraged to mitigate account compromises. Microsoft recently published a blog related to their cloud services indicative of the effectiveness of this type of mitigation relative to the percentage of account compromise attacks that would have been blocked, which is over 99.9%.
To provide a more user-friendly experience with MFA an Identity Provider (“IdP”) or centralized authentication platform can be leveraged to save time for your users. This type of technology can also provide valuable insights into security events such as where your users are logging in from and detail on failed logins. Many IDPs also provide the functionality to configure security alerting, restrict from where and how users can authenticate, and which factors can be used. (e.g. SMS, Google Authenticator, FIDO)
How an organization and individuals respond to an incident can materially alter how disruptive it is and the overall impact. As such, it is important to have a documented Incident Response Plan that is communicated to relevant stakeholders such as Staff and Vendors and is tested at least annually. Some simple steps to take when building out a plan are as follows:
Develop the Plan - there are many valuable resources out there to get an idea of how others structure their plans such as NIST 800-61, the PCI Security Standards Council guidance and the SANS Incident Handling Forms.
Review with Stakeholders - review the plan with relevant stakeholders to give them a chance to ask questions and provide feedback.
Test the plan - conduct a tabletop exercise to walk through incident scenarios to identify any gaps in your plan or room for improvement.
General Best Practices
Lock or secure confidential information at all times
Shred confidential documents when they’re no longer needed
Make sure you view confidential information on secure devices only
Only disclose information to other employees when necessary and authorized
Keep confidential documents inside company premises unless transporting is absolutely necessary
Staff are advised to lock their devices at their desks when not in use. When equipment is taken off company premises, employees are responsible for keeping it secure.
Restrict access to facilities and systems to only those who need to have that access to perform their duties.
Export cardholder information from the Card Data Environment (CDE) or from processor web portals
Use confidential information for your personal benefit or profit
Disclose confidential information to anyone outside of our company
Replicate confidential documents and files and store them on insecure devices
Grant more access to systems and users than is necessary to achieve a business objective
Payrix PCI Attestation of Compliance / AOC / ROC
For a copy of Payrix’s most current Attestation of Compliance (“AOC”) and/or Report on Compliance (“ROC”) please engage your relationship manager to obtain a copy. Note that a Non-Disclosure Agreement or contractual equivalent must be in place to obtain these reports.
PCI Shared Responsibilities Matrix
Security and Privacy within Payrix’s Cloud Services and Operations is a shared responsibility between Payrix, Payrix’s Third-Party Vendors including any applicable sub-processors (e.g. Amazon Web Services), and Clients. Payrix provides secure and privacy-friendly services that Partners and Merchants may use to build and manage world-class payments ecosystems. Payrix’s shared responsibility matrix is available here:
The above matrix is specific to Payrix’s PCI Scope and does fully not take into consideration any Partner or Merchant operating environments. Partners and Merchants are responsible for establishing their own PCI Responsibilities matrices based on their operating environments that leverage Payrix’s matrix as a complimentary document. For the avoidance of doubt, Payrix’s PCI Responsibilities Matrix should never be substituted for a Partner or Merchant’s matrix.