PCI Compliance & Information Security
Overview: This Implementations resource provides information on PCI compliance and security best practices.
Table of Contents
Notice
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.
PCI DSS
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?
I only process a few hundred dollars a month. Does my merchant account still need to be PCI compliant?
I do not use the internet to process credit cards, do I still have to be PCI Compliant?
Do I need to make all my accounts compliant?
How do I determine my compliance validation method?
How should I handle sensitive data?
Self Assessment Questionnaire (“SAQ”)
What is the PCI DSS Self-Assessment Questionnaire?
Why am I being asked to complete this questionnaire?
What happens if I do not complete this questionnaire?
How do I renew my questionnaire?
General
What is an EMV card?
What are the penalties for being non-compliant?
What is an ASV scan?
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.
Important Terms:
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.
Remediation Process:
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.
For more details, contact your acquirer or visit www.pcisecuritystandards.org.
OFAC Compliance
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.
Endpoint Protection
What is an endpoint?
Why are endpoints relevant to information security?
What are some risk mitigations I can put into place for endpoints?
Social Engineering
Interacting with Payrix Staff
What is Social Engineering?
What are some risk mitigations I can put into place?
How do I identify phishing attacks?
Multi-Factor Authentication (“MFA”)
What is Multi-Factor Authentication?
Shouldn’t a strong password be enough?
Why is MFA important?
MFA Strategies
Incident Response
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
Security “Do’s”
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.
Security “Don'ts”:
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:
Payrix PCI DSS Responsibilities Matrix.xlsx
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.
Visa Global Registry PCI Compliance
Visa_Global_Registry_of_Service_Providers_December_31_2020.pdf