What is PCI?

The Payment Card Industry (PCI) Data Security Standards (DSS) are a mandated set of security controls created by the major credit card companies (Visa, MasterCard, American Express, Discover, and JCB International). These controls serve the purpose of offering merchants and service providers a complete, unified approach to safeguarding cardholder data for all payment card brands. The PCI DSS applies to all payment card network members, merchants, and service providers that process, store, or transmit cardholder data, as well as to all methods of credit card processing, whether manual or computerized.

As a result, PCI DSS requirements, in conjunction with the UAB Payment Card Processing and Security Policy, apply to all UAB employees, contractors, consultants, temporaries, vendors, other third-party workers, and any unit that processes, stores, maintains, transmits, or handles payment card information in a physical or electronic format on behalf of the UAB enterprise, or in use of the UAB brand name. This includes any entity that utilizes any part of the UAB network infrastructure for payment card transaction services. Hereafter, these groups shall be referred to as “PCI Entities.”

To sum up, if you have been approved by UAB’s Office of the Chief Financial Officer (CFO) to receive and operate a payment card account as a PCI Entity, you must meet the security requirements mandated by the PCI DSS and abide by all UAB policies related to PCI compliance.

What are the required security controls for PCI?

The PCI DSS defines 12 information security requirements spread across six goals. These goals and requirements, which consist of recognized security best practices, are:

Goals PCI DSS Requirements
Build and Maintain a Secure Network and Systems 1) Install and maintain a firewall configuration to protect cardholder data.
2) Do not use vendor-supplied defaults for system passwords and other security parameters.
Protect Cardholder Data 3) Protect stored cardholder data.
4) Encrypt transmission of cardholder data across open, public networks.
Maintain a Vulnerability Management Program 5) Protect all systems against malware and regularly update anti-virus software or programs.
6) Develop and maintain secure systems and applications.
Implement Strong Access Control Measures 7) Restrict access to cardholder data by business need to know.
8) Identify and authenticate access to system components.
9) Restrict physical access to cardholder data.
Regularly Monitor and Test Networks 10) Track and monitor all access to network resources and cardholder data.
11) Regularly test security systems and processes.
Maintain an Information Security Policy12) Maintain a policy that addresses information security for all personnel.

Every goal and requirement must be met in order to attest to PCI compliance and gain approval to conduct credit card transactions. Failure to meet the standard of even one requirement can negatively impact a merchant and lead to penalties, including added fees that must be paid to conduct credit card transactions or even the revocation of a merchant’s ability to process such transactions.

What constitutes PCI data and how does UAB classify it?

When the term “credit card data” is used, many people immediately think of a credit card number, an expiration data, and a cardholder’s name. These are examples of credit card data, as defined by the PCI DSS. But they are not the only types of credit card data that must be protected. The PCI DSS defines the following elements as either cardholder data or sensitive data that are classified as Restricted under UAB’s Data Classification Rule:

  • Primary account number (PAN)
  • Cardholder name
  • Expiration date
  • Service Code
  • PINs or PIN blocks
  • Full track data (magnetic stripe data or the equivalent residing on a card’s chip)
  • CAV2, CVC2, CVV2, or CID codes appearing on the back of the card

In addition to the PCI DSS requirements, UAB has established policies and standards that govern cardholder data. For example, the storage of cardholder data by any UAB entity is strictly prohibited. Also, the transmission of cardholder data via an unsecured channel, such as unencrypted email, is strictly prohibited. For more information regarding UAB’s policies and standards for PCI compliance and handling cardholder data, please visit the following sites:

How do I become an approved PCI merchant at UAB?

Each UAB PCI Entity must be approved by, and registered with, the Office of the Chief Financial Officer (CFO) to receive and operate a payment card account. The UAB CFO’s office has been designated as the administrative focal point for handling the PCI Entity approval and registration process.

In addition, the payment card associations (Visa, MasterCard, etc.) have mandated compliance with the PCI DSS for any UAB PCI Entity that transmits, stores, or processes cardholder information. This requires that each Entity be certified to be in compliance with the PCI DSS in order to be approved by the CFO’s office to begin accepting payment cards.

To begin the PCI Entity evaluation process at UAB, first conduct these steps:

  • Familiarize yourself with an overview of the PCI DSS and its requirements, the PCI Self-Assessment Questionnaires (SAQs) and UAB's PCI DSS policy.
  • Discuss your objectives with the CFO’s office and Enterprise Information Security. This will include a review of your business processes and a determination of which payment alternative will best suit your business need.
  • Review the UAB PCI Entity Handbook, which provides a wealth of information regarding PCI compliance at UAB.

At a high level, the following workflow diagram reflects the process for requesting the creation of a PCI Entity Payment Card Account:

Detailed steps for requesting an account are provided below. Requests for new accounts should be made early enough to allow for sufficient time to achieve compliance.

  1. Contact the CFO’s office to request the PCI Entity Payment Card Account Request Form. Complete the form and have it reviewed and signed by the Entity Department Head and Dean/Associate Vice President. Additional instructions for completing the Account Request Form can be found on the PCI Compliance web site. Submit completed and signed form to CFO’s office for review and approval.
  2. The CFO’s office will submit the request form to First Data (the payment processor for Compass Bank, UAB’s acquiring bank) and Compass Bank, and notify the Entity when approval has been received. If the entity will use a swipe terminal, an order for a terminal is included in the account request.
  3. When established, First Data will notify the CFO’s office of the new merchant account number, indicating the Entity can begin processing payments, and the CFO’s office will notify the Entity.
  4. If the new merchant is accepting payments on-line, the CFO’s office will email the Applications and Consulting Services office to assist the Entity with TouchNet setup (TouchNet is an online payment application service provider). The CFO’s office will also visit the Entity to explain the depositing process, including accessing TouchNet, and completing and submitting deposit forms.
  5. If the new merchant is using a swipe terminal, the CFO’s office will notify the Entity when the terminal arrives and set up a time to deliver the terminal and explain how to operate the terminal and the depositing process.
  6. Meet with CFO’s office after verification that the account has been approved and set up by First Data and the bank. The purpose of the meeting is to explain the requirements of PCI compliance, the Entity’s responsibilities for PCI compliance, information concerning the online PCI training course, and gather information regarding the business process for the merchant account.
  7. Complete UAB’s online PCI training course, which can be accessed on the UAB Faculty & Staff Learning System web site at http://www.uab.edu/learningsystem/. The Entity is responsible for listing all individuals who will need to complete the PCI training on the Cardholder Data Flow and Fact Sheet form; and for notifying the CFO’s office when new individuals are hired and need to complete the training. The CFO’s office is responsible for assigning the PCI training course and verifying completion of the course by each individual assigned.
  8. The CFO’s office will create a merchant account in the TrustWave/TrustKeeper portal, using the Merchant ID information provided by First Data and the bank. The individual in the Entity who will be responsible for completing the SAQ and PCI documents will be designated on the account.
  9. Log on to the TrustKeeper portal (TrustKeeper will send a link when an account is set up) and complete the account registration information within three (3) business days from the time the email and link are received from TrustKeeper.
  10. Log on to the TrustKeeper portal and complete the on-line Self-Assessment Questionnaire (SAQ) within five (5) business days from the time the email and link are received from TrustKeeper. If applicable, identify systems that need to be included in monthly scans and successfully pass the first scan before accepting payment cards. For help in completing the SAQ, contact the CFO’s office.
  11. Note: the registration and SAQ can be done at the same time.
  12. The CFO’s office will log on to the TrustKeeper portal, access the merchant account, review the updated information provided by the merchant contact and the completed SAQ. The SAQ and PCI Certificate (which includes the completion date and name of the person completing the SAQ) will be saved and uploaded to the merchant account’s folder in the PCI Compliance web site Merchant Library.
  13. The CFO’s office will send the required PCI documents for completion to the contact person for the merchant account. The completed forms are to be returned to the CFO’s office via email within five (5) business days. The CFO’s office will review the forms and upload them to the merchant account’s folder in the PCI Compliance web site Merchant Library.
  14. Based on information gathered during the initial meeting between the merchant account contact and the CFO’s office, the CFO’s office will prepare a draft of the business process for the account regarding processing payment card transactions.
  15. The draft will be emailed to the merchant account contact for review, and revisions, if necessary, then sent back to the CFO’s office. Once the draft is final, the CFO’s office will upload a copy to the PCI Compliance web site Merchant Library and send a copy to the Entity contact.
  16. Contact the CFO’s office for any additional assistance on use of terminals, or the AskIT Help Desk for assistance on the setup and use of the TouchNet gateway. Training for payment applications should be requested through your application provider.

What’s an SAQ?

An SAQ is a classification type for each Entity, as determined according to the following guidelines:

  • SAQ A – Card‐not‐present merchants; all cardholder data functions are outsourced.
  • SAQ A-EP – E-commerce merchants who outsource all payment processing to PCI DSS validated third parties. Websites do not directly receive cardholder data with no electronic storage, processing or transmission of any cardholder data.
  • SAQ B – Imprint‐only or stand‐alone dial‐up terminal merchants with no electronic cardholder data storage.
  • SAQ B-IP - Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor, with no electronic cardholder data storage.
  • SAQ C-VT - Web-Based Virtual Terminals, No Electronic Cardholder Data Storage.
  • SAQ C – Merchants with payment application systems connected to the Internet with no electronic cardholder data storage.
  • SAQ P2PE-HW - Hardware payment terminals included in a PCI SSC-listed, validated, P2PE solution with no electronic cardholder data storage.
  • SAQ D for Merchants - All merchants not included in descriptions for the above SAQ types.
  • SAQ D for Service Providers - All service providers defined by a payment brand as eligible to complete a SAQ.

Each PCI Entity will receive a compliance certificate once they have completed and passed the following requirements:

  • The completion of an annual SAQ and Attestation of Compliance (AOC) provided on-line by TrustKeeper, a certified PCI vendor. This questionnaire provides a means for assessing an Entity's compliance to PCI standards.
  • Successful completion of remote network vulnerability monthly scans of all outward facing IP addresses on the same subnet as computers dealing with payment cards (for SAQ-C and SAQ- D Entities Only) by Trustwave, a PCI Approved Scanning Vendor (ASV).
  • Submission of the SAQ, evidence of a passing scan (where applicable), and the Attestation of Compliance, along with any other requested documentation.

Glossary of terms and acronyms related to PCI

This is a list of acronyms and PCI-specific terms:

Card Processing Environment – The area of computer systems and networks that possess cardholder data or sensitive authentication data and those systems and segments that directly attach or support cardholder processing, storage, or transmission. Adequate network segmentation, which isolates systems that store, process, or transmit cardholder data from those that do not, may reduce the scope of the card processing environment.

Cardholder – Customer to whom a card is issued or individual authorized to use the card.

Cardholder Data – Any personally identifiable data associated with the cardholder, to include primary account number, cardholder name, expiration date, service code, address, social security number, card service verification code, or any other data stored on the magnetic stripe of the payment card.

Information Security – Encompasses both the UAB Enterprise Information Security Office (EISO) and the UAB Health System Information Security (HSIS) Office. Depending on the operating environment of the UAB PCI Entity, Entities are required to report to one of the two Information Security Offices for evaluation and approval for the implementation and maintenance of their payment card processing environments.

Magnetic Stripe Data (Track Data) – Data encoded in the magnetic stripe used for authentication during transactions when the card is presented. Entities must not retain full magnetic stripe data subsequent to transaction authorization. Only the PAN, expiration date, name, and service code may be retained if needed for business purposes. Merchants – Authorized acceptors of payment cards for the purchase of goods, services, or information.

Multi-factor Authentication – Authentication that requires users to produce multiple credentials to access a system. Credentials consist of something the user knows (UserID, Password), something the user has in their possession (smartcard, hardware token), or something the user is (biometric characteristic). To access a system, the user must produce at least two of the three credentials.

Network members – Acceptors of payment cards for the purchase of goods, services, or information that have been granted direct authorization to perform payment card transactions by the major credit card companies. Generally these include banking and financial institutions. Payment Application Data Security Standards (PA-DSS) – The Payment Card Industry Security Standards Council program established to help software vendors and others develop secure payment applications that do not store prohibited data, such as full magnetic stripe, CVV2 or PIN data, and to ensure their payment applications support compliance with the PCI DSS. Payment applications that are sold, distributed or licensed to third parties are subject to the PA-DSS requirements.

Payment Card Industry Data Security Standards (PCI DSS) – A multifaceted set of comprehensive requirements and security standards developed to enhance payment account data security, security management, policies, procedures, network architecture, software design and other critical protective measures. This comprehensive standard is intended to help organizations proactively protect customer account data.

PCI Entity – Any UAB department, office, section, or affiliated association or group that has been approved to accept, process, transmit, or store credit card transactional or cardholder data as a member, merchant, or service provider operating on behalf of UAB, or in use of the UAB brand name.

Penetration Test – Security-oriented probing of computer systems or networks to seek out vulnerabilities that an attacker could exploit. Beyond probing for vulnerabilities, this testing may involve actual penetration attempts. The objective of a penetration test is to detect and identify vulnerabilities and suggest security improvements. Primary Account Number (PAN) – Payment card number (credit or debit) that identifies the issuer and the particular cardholder account.

Senior Management – Persons in the positions of dean, chair, or division or program director, or persons specifically designated by a dean, chair, or division or program director, that make executive decisions and are authorized to accept risks for the administrative unit in the area of information security.

Separation of Duties – The practice of dividing steps in a function among different individuals to keep a single individual from being able to subvert established processes.

Sensitive Areas – Any data center, server room, or area that houses systems that store, process, or transmit cardholder data. This excludes areas where only point-of-sale terminals are present, such as cashier areas in a campus retail store.

Sensitive Authentication Data – Security-related information that includes Card Validation Codes/Values, complete track data, PIN numbers and PIN blocks used to authenticate cardholders. Disclosure, modification, or destruction of this information could compromise the security of a cryptographic device or information system, or cardholder information could be used in a fraudulent transaction.

Service Code – The three or four-digit number on the magnetic stripe of a payment card that specifies acceptance requirements and limitations for a magnetic stripe read transaction.

Service Providers – Any business entity that is not a payment card brand network member or a merchant directly involved in the processing, storage, transmission, and switching of transaction data or cardholder information, or both. This includes companies that provide services to merchants, service providers, or members that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, intrusion detection systems and other services as well as hosting providers and other entities. Entities such as telecommunications companies that only provide communication links without access to the application layer of the communication link are excluded.

Strong Cryptography – General term to indicate cryptography that is extremely resilient to cryptanalysis.

UAB Enterprise – The University of Alabama at Birmingham, the University of Alabama at Birmingham Health System, University Hospital, The Kirklin Clinic, the University of Alabama Health Services Foundation, the UAB Health Centers, the Ophthalmology Services Foundation, and Callahan Eye Foundation Hospital.

UAB PCI Entity – Any UAB department, office, section, or affiliated association or group that has been approved to accept, process, transmit, or store payment card transactional or cardholder data as a member, merchant, or service provider operating on behalf of UAB, or in use of the UAB brand name.

Verification Code – The three or four digit value printed on the front or back of a payment card; Card Validation Code CVC2 (Mastercard), Card Verification Value CVV2 (VISA), Card Member ID (Discover), or the Card Identification Number CID (American Express).

Vulnerability – A weakness in system security procedures, system design, implementation, or internal controls that could be exploited to violate system security policy.

Vulnerability Scan – Scans used to identify vulnerabilities in operating systems, services, and devices that could be used by hackers to target an organization’s private network.