Payment Card Security (Policy 98)

Policy Statement

Governors State University is committed to establishing appropriate security controls and 
ensuring compliance with the Payment Card Industry Data Security Standard (PCI DSS), helping 
to protect payment card information and ensuring the security of transactions.

Purpose

The Payment Card Industry Security Standards Council (PCI SSC) has developed a set of security standards (the Payment Card Information Data Security Standard or “PCI DSS”) to protect payment card information. PCI DSS governs all merchants and organizations that collect, process, store, or transmit credit card information. As an agency of the State of Illinois, the University is required to comply with PCI DSS. This Policy outlines the requirements for safeguarding payment card information and complying with PCI DSS.

Scope

All individuals, departments, and groups that handle cardholder data or use or maintain in scope systems must comply with this Policy.

Roles and Responsibilities

Individuals are required to comply with the components of this Policy as applicable.

Credit and Source

This Policy was developed internally.

1. Cardholder - Non-consumer or consumer customer to whom a payment card is issued or any individual authorized to use the payment card.
2. Cardholder Data Environment (CDE) - The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data. These, along with any system that connects to or can affect the security of the CDE, are referred to as “in-scope.” 
3. Card Not Present (CNP) Transactions - Cardholder is not physically present at the point of sale. These transactions occur online, over the phone, or through mail order, requiring the use of card information (such as card number, expiry date, and security code) provided by the cardholder to complete the transaction. 
4. Card Validation Code 2 (CVC2) – For MasterCard payment cards. A three or four-digit code that is used to verify the authenticity of a credit card. 
5. Card Verification Value 2 (CVV2) – For Visa payment cards. A three or four-digit code that is used to verify the authenticity of a credit card. 
6. Card Identification Number (CID) – For American Express and Discover payment cards. A three or four-digit code that is used to verify the authenticity of a credit card. 
7. E-commerce - Buying and selling goods and services online. 
8. EMV – Global standard for secure payment transactions. Commonly referred to as the “chip” that provides enhanced security features, reducing the risk of card fraud. 
9. Encryption - Rendering data unreadable except to holders of a specific cryptographic key. 
10. Magstripe - Short for magnetic stripe, is the thin strip on the back of a payment card that contains encoded information. It is used for card authentication and data storage, allowing the card to be swiped through a magnetic stripe reader for transaction processing. 
11. Merchant - For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, 2 Discover, JCB International, MasterCard Worldwide or Visa, Inc.) as payment for goods and/or services. 
12. NFC (Near Field Communication) - Short-range wireless technology used for contactless communication between devices, utilized for secure and convenient contactless payments. 
13. Patch - Update to existing software to add functionality or to correct a defect. 
14. Payment Card - For purposes of PCI DSS, any payment card/device that bears the logo of the founding members of PCI SSC, which are American Express, Discover Financial Services, JCB International, MasterCard Worldwide, or Visa, Inc. 
15. Payment Application - Any application that stores, processes, or transmits cardholder data as part of authorization or settlement. 
16. Payment Card Information/Cardholder Data (CHD) - At a minimum, this type of data consists of the full Primary Account Number (PAN) and may also appear in the form of the full PAN plus any of the following: cardholder name; expiry date; and/or service code. 
17. Point-to-Point Encryption (P2PE) – PCI-DSS Point-to-Point Encryption: a solution that cryptographically protects account data from the point where a merchant accepts the payment card to the secure point of decryption. 
18. Primary Account Number (PAN)/Account Number - Unique payment card number (typically for credit or debit cards) that identifies the issuer and the particular cardholder account. 
19. Personal Identification Number (PIN) - Secret numeric password known only to the user and a system to authenticate the user to the system. The user is only granted access if the PIN the user provides matches the PIN in the system. 
20. Point of Sale (POS) or Payment Terminal - A hardware device and/or software used to process payment card transactions at merchant locations. 
21. Self-Assessment Questionnaire (SAQ) - Tool used by any entity to validate its own compliance with the PCI DSS. 
22. Sensitive Authentication Data (SAD) - Security-related information (including but not limited to card validation codes/values, full track data (from the magnetic stripe or equivalent on a chip), PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions. 

1. Security Incidents

   Any suspected or actual incident relating to a breach of payment card information including but not limited to unauthorized disclosure, unsecure transmission, tampering of devices or substitution, impersonation, theft, fraud, or any other activity that could negatively impact the cardholder or the University must be reported to the ITS Helpdesk immediately.

2. Attestation of Compliance 
   1. Each University merchant is required to complete the relevant PCI DSS Self-Assessment Questionnaire (SAQ) yearly and must satisfy the related requirements to remain compliant with PCI DSS. The Information Security and Compliance Office will guide each merchant through this process unless otherwise noted.
   2. Any modifications to in-scope devices, networks, software, services, or processes must follow the ITS change management process and may require the completion of a new SAQ.

3. Payment Processors

   The University’s preferred payment processor must be used unless another processor is explicitly approved. Requests to use a non-preferred payment processor must be approved in writing by each of the following University offices prior to entering into an agreement and must be reviewed yearly thereafter:

   1. Finance 
   2. Procurement 
   3. ITS 
   4. Information Security
4. Payment Terminals
   1. Payment terminals must be part of a P2PE solution offered by an approved payment processor and must be P2PE compliant.
   2. Payment terminals may not be purchased or replaced without approval by each of the following University offices:
      1. Finance 
      2. Procurement 
      3. ITS 
      4. Information Security
   3. An inventory of payment terminals must be maintained and verified at least yearly. The inventory must contain at least:
      1. Make and model of the devices 
      2. Location of the devices 
      3. Device serial number or other methods of unique identification
   4. Payment terminals may only use vendor-supported operating systems and applications and all security patches must be installed within 30 days of release.
5. ECommerce Sites
   1. The University’s preferred e-commerce solution (uPay) must be used to accept online payments unless another e-commerce solution is explicitly approved.
      1. Requests to use an alternate must be approved in writing by each of the following University offices prior to entering into an agreement and must be reviewed yearly thereafter:
         1. Finance 
         2. Procurement 
         3. ITS 
         4. Information Security
      2. E-commerce solution providers must provide evidence of current PCI DSS compliance prior to entering into an agreement and yearly thereafter.
      3. E-commerce solution providers must provide a PCI DSS responsibility matrix prior to entering into an agreement and yearly thereafter.
   2. Groups who wish to accept online payments may request a uPay site from ITS.
6. Alternative Solutions
   1. The use of any unauthorized devices, software, or services to accept payments or store or process CHD is prohibited.
   2. The use of P2PE solutions and uPay sites dramatically reduces the amount of time, effort, and resources required to implement and maintain a PCI DSS compliant payment solution. Merchants that opt to use an alternate solution may be responsible for any additional expense required for implementation and ongoing maintenance and may be required to accept full responsibility for ensuring compliance with PCI DSS.
7. Third-Party Service Providers
   1. The use of any third-party service providers that store or process cardholder data, including payment processors, must be explicitly approved in writing by each of the following University offices:
      1. Finance 
      2. Procurement 
      3. ITS 
      4. Information Security
   2. Agreements with all third-party service providers that store or process cardholder data must explicitly require that the service provider provide supply the following:
      1. Evidence of current PCI DSS compliance prior to entering into an agreement and yearly thereafter.
      2. A PCI DSS responsibility matrix prior to entering into an agreement and yearly thereafter.
8. Handling Account Data
   1. Payment card information may only be used for the purpose for which it has been provided by the cardholder. Violations of this policy may result in discipline, up to and including termination.
   2. Except as otherwise provided herein, payment card information such as the PAN, PIN, CVC2, CVV2, or CID, or Sensitive Account Data may not be stored in any form, digitally (on any computer or University network) or on paper after a payment is authorized. Account data shall be securely deleted when no longer needed.
   3. The last four digits of the PAN may be stored for record purposes and audit trail.
   4. No system or device may transmit or store CHD in any unencrypted manner.
   5. University employees may not handle a customer’s payment card.
   6. University employees may not handle mobile devices of customers wishing to use contactless payments with Apple Pay, Google Pay, or other contactless payment app.
   7. Card Not Present Transactions
      1. Manual entry of cardholder data is not permitted except when entered directly by the customer onto an approved e-commerce site. 
      2. Acceptance of non-functioning or damaged payment cards is not permitted. 
      3. Telephone payment card transactions are not permitted. 
      4. Mail order payment card transactions are not permitted.

   8. EMV Transactions

      EMV compatible payment cards contain a chip that establishes a secure connection with the payment terminal when inserted. EMV compatible cards should only be processed by inserting (dipping) the card into the chip card slot or reader.

9. Personnel
   1. All employees who handle payment card information:
      1. Must participate in the annual security awareness training provided by the University. 
      2. Must participate in PCI DSS training provided by the University and formally acknowledge their responsibilities as stated within this policy annually. The annual security awareness training and PCI DSS training will be administered by the Information Security and Compliance Office, which will adopt procedures with which University merchants can identify those employees who must complete the trainings.
   2. All employees who use payment terminals:
      1. Must be trained to be aware of suspicious behavior and to report any tampering or substitution of devices. 
      2. Must verify the identity of any third-party persons claiming to be repair or maintenance personnel prior to granting access to modify or troubleshoot devices. 
      3. May not install, replace, or return devices without authorization. 
      4. Must ensure payment terminals are physically secured when not in use.
   3. Employees who have not taken the appropriate cybersecurity training and PCI DSS training within the last 12 months may not handle cardholder data or use any in-scope systems.
10. Infrastructure
    1. Dedicated Network
       1. All systems considered in-scope for each University merchant (including but not limited to payment gateway devices, workstations, card readers, servers, applications, databases, etc.) must be hosted and operated only on an isolated network or VLAN dedicated for card payment operations unless the systems are P2PE compliant. 
       2. Only explicitly allowed traffic may enter or leave the dedicated network. 
       3. Physical and/or logical controls must be implemented to restrict access to network jacks that are part of the dedicated network.
    2. Software
       1. All in-scope devices must be updated per the University’s patch management processes plus any supplemental PCI DSS requirements.
       2. Where possible, all in-scope devices must have antivirus software installed and must be patched regularly to maintain vendor-supported operating systems and applications.
    3. Access
       1. Where practical, a lock screen must be enabled on devices used for card payment operations when users are away from the devices. 
       2. All default system passwords and other security parameters must be changed and unnecessary default accounts must be removed prior to the system being used. 
       3. Access and permissions to in-scope systems may be granted only as required for an individual’s job function. 
       4. User access must be terminated immediately when it is no longer required or when employment ends. 
       5. A monthly audit of user access and associate permissions for in-scope devices must be performed and documented by the merchant. 
       6. Passwords for in-scope devices must comply with the University’s password policy plus any additional PCI DSS requirements.
    4. Audit logs
       1. Audit logs must be kept for all in-scope systems and software that are not P2PE compliant.
       2. Audit logs must be retained for at least one year with a three-month record immediately available for analysis. Where applicable, the audit trail/log should contain the following:
          1. User identification 
          2. Type of event 
          3. Date and time 
          4. Success or failure indication 
          5. Origination of event 
          6. Identity or name of affected data, system components, or resources.

    5. Change detection

       For non-P2PE systems, mechanisms must be implemented to detect unauthorized modification of critical system files, configuration files, or content files. The change detection mechanism must alert the appropriate personnel to investigate.

    6. P2PE Implementation Manuals

       P2PE service providers will provide a P2PE Implementation Manual (PIM). Merchants must comply with any rules established by the service provider within the PIM.

PCI DSS Precedence

Although intended to be comprehensive, some requirements established by PCI DSS may not be included in this Policy. Additionally, PCI DSS may change or add requirements that are not immediately reflected in this Policy. In such cases, and in cases where PCI DSS imposes stricter requirements than University policies, the PCI DSS requirements must take precedence.