Overview: This Implementations resource provides information on PCI compliance and security best practices.

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?

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?

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.

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.

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
IBM - Cost of a Data Breach Report
Verizon - Data Breach Investigations Report

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

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:

PCI Compliance & Information Security

Table of Contents