PCI security standards: A high-level overview Prepared by: Joel Dubin, Manager, RSM US LLP joel.dubin@rsmus.com, +1 312 634 3422 Many merchants often have difficulty understanding how they must comply with Payment Card Industry Data Security Standard (PCI DSS). Some may assume that PCI applies only to certain businesses or service providers, for example. Banks that outsource credit and debit card processing also may be uncertain as to compliance requirements. Questions may further arise if the bank does not issue credit or debit cards at all. Many merchants who accept credit cards for transactions often struggle to determine exactly what they must do to be compliant with PCI DSS. And now, with the standard being updated more frequently than every three years, as it has been up until this year, many merchants are at a loss to keep up with the changes. The most recent version of the standard, version 3.2, came out this year and is already in force. Even if a community bank, for example, knows it must comply, understanding which guidelines are applicable to its institution can be challenging. Yet noncompliance could result in significant financial penalties and reputational damage to the community bank. Customer accounts could also be compromised. To clarify this issue, this white paper will examine how PCI DSS affect different types of merchants and financial institutions, such as retailers, restaurants and hotels, and banks, under what circumstances, and which standards should be followed in certain situations.
A short history lesson To understand the purpose and scope of PCI standards, consider how the standard came to be. First of all, protection for cardholder data has long been a hot topic in the financial services industry. The issue was highlighted by the 1999 passage of the Gramm Leach Bliley Act, which (among other things) stipulated that financial institutions must have a policy in place to protect information from security threats. In the end, however, the PCI standard was developed not as a law or regulation, but as a private initiative by the payment card industry. The PCI Security Standards Council (SSC) was launched in 2006 by the five global payment brands, Visa, Inc., MasterCard Worldwide, American Express, Discover Financial Services and JCB International; it was responsible for the development, management and education of the PCI standards. Shortly thereafter, the council introduced Payment Card Industry Data Security Standards (PCI DSS), a set of standards designed to ensure that merchants met minimum levels of security when they handled cardholder data. Later, the scope was broadened to include other entities. PCI standards defined The PCI standards are comprised of the following: Data Security Standard (PCI DSS): The security standard for any organization that processes, stores or transmits cardholder data such as merchants and service providers Payment Application Data Security Standard (PA-DSS): Security standard for the development of application software that processes, stores or transmits cardholder data PIN transaction security (PCI PTS): Security standard for PIN entry devices such as credit card terminals Point-to-point encryption (PCI P2PE): Security standard for the encryption of communications between two endpoints PCI standards apply to any merchant or service provider handling credit cards Any merchant accepting credit cards for payment of transactions is required to meet PCI compliance. The question of how to comply whether a full Report on Compliance (ROC), or just a Self-Assessment Questionnaire (SAQ), is based on what the credit card brands and the SSC define as merchant levels. Four merchant levels were established; the highest level, Level 1, conducts one million or more transactions a year. Level 1 merchants are required to undergo a full PCI assessment every year, including an onsite review by a Qualified Security Assessor (QSA) and the submission of a completed ROC to the merchant s acquiring bank or card brand. The other merchant levels only require the filing of an SAQ, which can be done by the merchant themselves, or by a QSA. It s often better to have a QSA complete the SAQ, since the QSA can navigate the technical fine points in the SAQ. Whether a merchant is a large retail or hotel chain, or a middle market business using credit cards for payments, PCI applies and needs to be considered. Service providers are companies that handle credit cards but don t conduct transactions. A data storage company, for example, or a third party that handles credit cards for a merchant, would be in scope for PCI. QSA companies, like RSM, can help navigate the maze of the 12 PCI requirements. Whether providing advice on network segmentation to isolate card data and reduce PCI scope, or providing advice on PCI-compliant logging and scanning, or identifying best PCI practices for user authentication and vulnerability management, QSA companies can assist. A gray area might be banks, which issue and process cards but don t neatly fit into the merchant or service provider box. As we ll see in the following section, banks are in scope for PCI. 2
PCI standards do apply to banks Unbeknownst to some community banks, the above PCI standards do apply to them, as well as to merchants and service providers. The specific requirement is spelled out on page 5 of the PCI DSS, and it states that the standard applies to all entities involved in payment card processing including merchants, processors, acquirers, issuers and service providers, as well as all other entities that store, process or transmit cardholder data. According to the standards, a financial institution is considered a merchant if it accepts credit or debit cards for payment of goods and services such as for safety deposit boxes, public utility payments, payments for insurance policies or any other payments. An institution is considered a service provider if it is connected to card processing networks such as VisaNet, NYCE (New York Currency Exchange) or First Data, and processes card transactions on behalf of merchants or other entities. If a financial institution issues credit or debit cards (i.e., the card carries the financial institution s name or logo), it is considered an issuer, regardless of whether it physically issues the cards or has outsourced card issuance to a third party. However, a financial institution is only required to conform to the relevant PCI standards for issuers if the financial institution physically issues cards with the payment card brand logos. A financial institution is considered an acquiring bank or acquirer if it contracts with merchants for the acceptance of credit or debit cards for payment. Even though the financial institution may have outsourced the processing of transactions to a third party, the financial institution is still considered the acquirer. Acquiring banks need to establish and maintain a merchant PCI compliance tracking and reporting system and must periodically report their compliance statistics to the appropriate payment card brand. Community banks frequently ask questions about special circumstances affecting their bank. Here are three of the most common questions asked about PCI DSS. If a bank outsources credit and debit card issuance and processing, is it required to comply with PCI standards? Many financial institutions outsource credit and debit card issuance and processing to a third party and may assume that they are not required to comply with PCI standards. Even with a Service Organization Control report from the contracted third party, this is not the case. With outsourcing, a financial institution s applications and networks can still come into contact with cardholder data in a number of ways. The most common ways are: The switching and transmission of automated teller machine transactions over the institution s data network Storing of debit card full primary account numbers (PAN) in the institution s core application Accounting department personal computers or servers storing spreadsheets from Visa or MasterCard that contain full PANs Processing of credit or debit cards through dedicated card terminals or teller terminals for payments Storing credit or debit card full PANs in statement consolidation and rendering systems or as PDF files from a third party who creates the statements These forms of contact are very common within financial institutions and dictate that the bank must demonstrate compliance with PCI standards. Does PAN encryption and PA DSS certification negate the need to demonstrate PCI compliance? As a part of developing a secure network architecture, a financial institution s application providers can encrypt the full PANs stored by their applications. These vendors also ensure that financial institution applications are PA-DSS certified. With these measures in place, many financial institutions may think that compliance with the PCI standards is not necessary. 3
However, even when applications utilize encryption for storing cardholder data, that data still has to have been processed or transmitted to or from those applications. Also, while an application may be PA-DSS certified, a financial institution must ensure that the application was implemented according to the vendor s explicit requirements to maintain this certification. As a result, the financial institution is still responsible under PCI DSS for ensuring, at a minimum, that: Cardholder data is securely transmitted over the financial institution s network. Cardholder data is securely processed by the financial institution s applications. Any encryption used is based on an industry-tested and accepted algorithm such as the advanced encryption standard. Any encryption algorithm used employs strong key lengths and proper key management practices. If a community bank does not issue credit or debit cards, does it have to comply with the PCI standards? If the bank signs up merchants for accepting credit or debit cards for payment of goods and services, and the bank processes card transactions for those merchants, then the bank is required to comply with PCI DSS. Even if the bank does not process merchant transactions, it is still required to establish a merchant PCI compliance program, as well as periodically assess that program for the applicable payment card brand, and report its merchant PCI compliance statistics to the card brand. In addition, while banks may not physically issue credit or debit cards, they may issue PANs to their commercial customers to use like a debit or credit card for purchasing airline reservations, office supplies and other business needs. If those PANs are processed or stored by any of the bank s application systems or are transmitted over their networks, then it needs to comply with the PCI standards. What is new in PCI version 3.2? The changes in PCI 3.2 are incremental revisions and clarifications to PCI 3.1. Some of the highlights include the following: All administrative access to cardholder data now requires a two-factor authentication Updated dates for the required migration from SSL to TLS for transmission of cardholder data over public networks, like the internet Support for display of PAN beyond the first six and last four, if there is a business justification PCI compliance starts with an assessment At a minimum, all banks should conduct an assessment of their applications and networks to determine if they process, store or transmit cardholder data. If they do, the findings should be analyzed to determine if each area is in compliance with the PCI security standards. Part of the assessment will involve an evaluation of which standards are relevant to the organization. Based on the outcome of that assessment, the bank will know if they have any compliance gaps and what steps should be taken to close those gaps. If the organization is considered an acquiring bank, then they need to have established an appropriate merchant PCI compliance program for their affiliated card brand. Finally, bringing your systems into compliance with PCI has intangible benefits for your bank. Customer satisfaction is enhanced when cardholder data is secure, because customers feel they can trust you with their sensitive card information. If customers trust a bank, they are more likely to remain loyal to it. Likewise, compliance improves your reputation with your payments processing partners (acquirers, merchants, et al.) that will feel more confident in doing business with the bank. 4
+1 800 274 3978 www.rsmus.com This document contains general information, may be based on authorities that are subject to change, and is not a substitute for professional advice or services. This document does not constitute audit, tax, consulting, business, financial, investment, legal or other professional advice, and you should consult a qualified professional advisor before taking any action based on the information herein. RSM US LLP, its affiliates and related entities are not responsible for any loss resulting from or relating to reliance on this document by any person. Internal Revenue Service rules require us to inform you that this communication may be deemed a solicitation to provide tax services. This communication is being sent to individuals who have subscribed to receive it or who we believe would have an interest in the topics discussed. RSM US LLP is a limited liability partnership and the U.S. member firm of RSM International, a global network of independent audit, tax and consulting firms. The member firms of RSM International collaborate to provide services to global clients, but are separate and distinct legal entities that cannot obligate each other. Each member firm is responsible only for its own acts and omissions, and not those of any other party. Visit rsmus.com/aboutus for more information regarding RSM US LLP and RSM International. RSM and the RSM logo are registered trademarks of RSM International Association. The power of being understood is a registered trademark of RSM US LLP. 2016 RSM US LLP. All Rights Reserved. tl-nt-ras-all-1016