Credit Card Risks: Update on PCI Compliance Monday, May 23 2:40pm 3:55 CPE: 2 Joe Helmy, VP Emerging Verticals, MasterCard Jennifer Cooperman, MBA, CPFO, Treasurer, City of Portland, OR Tod Burton, Financial Planning & Debt Project Manager, Tualatin Valley Water District, OR
Credit Card Risks: PCI Introductions Mary Christine Jackman, Director of Treasury Management
Credit Card Risks: PCI Joe Helmy, VP Emerging Verticals, MasterCard
PCI Compliance What is PCI? Why is it important? Main Goals of PCI PCI DSS Requirements
What is PCI?
PCI Overview: What is PCI? Payment Card Industry Data Security Standard (PCI DSS) Framework for a robust payment card security process including: Prevention Detection Remediation/Mitigation Applies to any application that transmits, processes or stores credit card data Payment Brands such as the card networks of MasterCard and Visa helped develop the PCI DSS framework PCI compliance must be reviewed by a third party, the Qualified Security Accessor (QSA) company
Why Is It Important?
Why PCI is Important? The goal of PCI is to protect cardholder data & sensitive authorization data The risk of being non-compliant could lead to data breaches which can impact your organization s reputation, ability to conduct business, stock prices etc. Adhering to the PCI standards helps reduce the risk of potential data breaches The PCI DSS Standards are a great resource to help develop and maintain a secure application. They provide guidelines on how credit card data should be transmitted, processed, and stored securely Compliance is an ongoing process, not annual!
WHEN DOES PCI RELATE TO ME? PCI applies to your application if: You transmit credit card data You process credit card data You store credit card data
2015 Verizon PCI Compliance Report Just one new uncontrolled Wi-Fi access point, unprotected account, or unencrypted drive could take you out of compliance.
Main Goals of PCI
Data Storage Do s & Don'ts Do understand the payment card data flows for the entire transaction process. Do retain cardholder data only if there is a business need and authorized. Ensure it s protected. Do mask the Primary Account Number (PAN) whenever it is displayed. The first six and last four digits are the maximum number of digits that may be displayed or first six and any other four (truncation) Do document and limit users who need to view full PAN with a business case. Do ensure any third parties with access to this data is in compliance with PCI DSS.
Data Storage Do s & Don'ts Don t store cardholder data unless necessary Don t permit any unauthorized people access to stored credit cardholder data Don t store full contents of any track from the card s magnetic stripe or chip (referred to as full track, track, track 1, track 2,or magnetic stripe data). If required for business purposes, the cardholder s name, PAN, expiration date, and service code may be stored as long as they are protected in accordance with PCI DSS requirements. Don t store the Card Verification Code (CVC/CVV) code or PIN/PIN Block
Guidelines for Card Data Storage
PCI Requirements
PCI Requirement Breakdown
Credit Card Risks: PCI Jennifer Cooperman, CPFO, City Treasurer, City of Portland
Portland s Payment Card Program 2005: Began accepting card payments 2006: Deployed internally developed, customized payment gateway 2008: Began using a QSA 2010: Achieved Level 1 merchant status 2016: 82 MIDs, >10 million transactions/year, >$175 million/year
Where We Weren t Compliant Access to payment gateway / PCI data QA process for payment gateway code Security policies and procedures Security patches and passwords Penetration testing Monitoring service providers
Changes To Comply With PCI Replace payment gateway Turned off IVR Stop collecting CVV on recorded calls VoIP telephony Point-to-point encryption on devices Education and awareness Documentation
What It Took To Get Compliant (1) Taking PCI seriously Having a champion Working as one organization Defining PCI as a Citywide project Retaining on-call PCI audit services Sharing progress and setbacks with our bank
What It Took To Get Compliant (2) Understanding PCI DSS requirements Understanding risks of non-compliance Researching compliant entities Methodical analysis of each location and business process Commitment to reducing PCI scope Changing business processes and turning off non-compliant services
Project Challenges Enterprise-level project Education and awareness Scope identification Communication platform and plan Trade-off between business wants and requirements and need to change
New City Policy On PCI Compliance All city bureaus and designated agents to be fully compliant with PCI DSS. Treasury SME and Technology SME required in RFP / contract development. AOC required from designated agents Failure to deliver AOC is material breach. Bureaus to have remediation plans (including termination) if designated agent cannot deliver AOC.
What Keeps Me Up At Night? Will we get compliant before deadline? What new services are City bureaus contracting for that involve card processing and PCI data? Now that we have policies/procedures, are they being followed? Are all designated agents compliant? What will be in PCI DSS v4.0?
Credit Card Risks: Update on PCI Compliance Tod Burton, Finance/Debt Project Manager, Tualatin Valley Water District
About Us Overview Steps to PCI Compliance Lessons Learned The Sweet Side of PCI: Compliance 29
Tualatin Valley Water District Special district only water Population 218,000 Service connections 61,000 Billing for partner entities brings total accounts to over 80,000 Over 500,000 bills sent annually 70% paid through E Commerce methods 22% paid by credit card and growing Home To:
Steps to PCI Compliance Plan: Identify Target SAQ Where You Are Now (SAQ D?) How to Reach Target (SAQ B Questionnaire) Organize Team: System & Customer Focus Software Development, System Migration Communications: Customer, Employee, Governing Body Customer Transition and Volume Planning Institutionalize: Change Management Policies, Incident Response, PCI Training Culture Changes 31
PCI/DSS Levels and Validation Requirements Levels Criteria Required Actions Level 1 All merchants processing over 6,000,000 transactions per year NEW: Level 1 merchants no longer able to self assess unless they attend PCI DSS QAA training by PCI DSS Council and become accredited (information available in March). Effective 6/30/11 Level 2 Any merchant processing 1,000,000 to 6,000,000 transactions per year NEW: Level 2 merchants that conduct self assessment must attend PCI SSC training and become accredited (information available in March). Effective 6/30/11 Level 3 Any merchant processing 20,000 to 1,000,000 Visa or MC e commerce transactions per year Level 4 Any merchant processing fewer than 20,000 Visa or MC e commerce transactions per year, and all other merchantsregardless of acceptance channel processing up to 1,000,000 Visa or MC trans. per year Annual Onsite PCI DSS audit & ROC validated by a Qualified Security Assessor or Internal Audit (if PCI SSC certified) Quarterly Network Security Scan by ASV Complete self assessment (if PCI SSC certified), or Complete an annual onsite assessment conducted by a Qualified Security Assessor Quarterly Network Scan by ASV Annual PCI DSS Self Assessment Questionnaire Quarterly Network Security Scan Annual PCI DSS Self Assessment Questionnaire Quarterly Network Security Scan 3
SAQ Definitions Questionnaire SAQ A Definition Addresses requirements applicable to Acceptors that have outsourced all cardholder data storage, processing and transmission. SAQ A EP SAQ B SAQ B IP SAQ C SAQ C VT SAQ D SAQ P2PE HW Addresses requirements applicable to ecommerce Acceptors that capture the cardholder data as part of the transaction process. This also requires vulnerability scanning and penetration testing on the cardholder data environment. Addresses requirements pertinent to Acceptors that process cardholder data via imprint machine or standalone dial up terminals only. Addresses requirements related to Acceptors cardholder data via a POS terminal using a Ethernet (internet) connection. Constructed to focus on requirements applicable to Acceptors whose payment applications systems are connected to the internet. Developed for Acceptors who process using a virtual terminal (access POS via a hosted user interface). Addresses requirements relevant to all Acceptors defined by a payment brand as storing cardholder data electronically or those acceptors who do not fall under the types addressed by SAQ A, B or C. Acceptors using only hardware payment terminals including in a PCI SSC listed, validated, P2PE solution, no electronic cardholder data storage. 3
Plan: Identify Target SAQ District used Trustwave Compliance management site used by bank Provided advice and clarifications SAQ B merchant terminals 3 rd party hosted payment site + payment portal Not easy Need objective evaluators Teams are invested in existing systems and processes Will be expensive, don t underestimate the costs 34
Organize Team: System & Customer Focus Project Drivers Size and scope of system changes Utility Billing & Web Site System migration to Velocity Payment Availability of 3 rd party providers Limitations of new system Management and governing body oversight Customer service training and volume management Billing and payment changes for customers 35
Institutionalize: Change Management PCI policy requires Cybersecurity policy Risk Management is natural fit PCI Incident Response Plans Essential for employees that handle payment card information PCI Training, PCI Inspection & Auditing, PCI Device Selection Criteria Employee and governing body adoption of new security requirements 36
Lessons Learned Maturity needed for project Organization s experience with chartered projects Ability to grasp vision and target environment The need for team ownership and change management cannot be overstated Do not underestimate the potential customer response Coordination with so many parts in flux creates risk Need to stay on top of risks Expect on going work for at least 6 months post go live 37
The Sweet Side of PCI: Compliance 38
Resources www.pcisecuritystandards.org Best Practices Treasury and Investment Management Committee www.gfoa.org/best practices Your friendly banker and merchant services provider
Thank You Questions