PCI Compliance Homepage PUT WITHIN TREASURY SECTION
As a business accepting card payments, Seattle Pacific University needs to take a number of steps to ensure we are protecting our customers, our business and reducing our exposure to fraud.
...
This policy addresses the people, processes and controls required to protect Cardholder Data (CHD) received, processed, transmitted, stored by, or stored on behalf of, Seattle Pacific University.
Overview
The PCI Security Standards Council is is a global forum for the ongoing development, enhancement, storage, dissemination and implementation of security standards for account data protection. They publish a set of standards for merchants to use to ensure secure handling of payment card transactions. The current standard is PCI DSS v4.0published in March 2022.
All card processing activities and related technologies must comply fully with the Payment Card Industry Data Security Standard (PCI DSS).
Types of transaction
There are many type of transaction performed on campus:
Card Present (CP) – card swipe/EMV chip read equipment at the time of transaction in the presence of the customer.
Card Not Present (CNP) – phone, web-based, paper forms, or other means.
Self-service (web based) via payment gateway - those transactions initiated and performed by the cardholder in which no SPU personnel or equipment are involved in directly handling or transferring cardholder data.
SPU Merchant Requirements
SPU schools and departments (SPU merchants) who accept payment via credit or debit cards, must:
Use existing "Payment Gateway Service Providers" such as Nelnet/Commerce Manager and Blackbaud Merchant Services.
Use "self service" (user initiated and completed) processes whenever possible to reduce the direct involvement of University employees in performing payment card transactions.
When card-present or card-not-present transactions are required, implement an approved Point-to-Point-Encryted (P2PE) hardware solution e.g. using Square services.
Eliminate payment card data from paper forms and processes.
Do not collect or store cardholder data in any system, database, document, worksheet, email, electronic or paper format ("data-at-rest"). This includes any computing device, file server, mobile device, thumb-drive, external storage device, etc.
Do not transmit cardholder data in email, SMS/text, FAX, instant messaging/chat, Telnt/FTP, SSH or any other electronic messaging or transmission system (whether encrypted or non-encrypted),
...
except via approved P2PE mechanisms.
Ensure all access to the cardholder data environment requires authorized credentials, unique and secure passwords, and proper login/logout procedures. Group, shared, or generic usernames and passwords are prohibited. Default passwords for any and all transaction services and resources must be disabled and never used.
Complete a PCI DSS self-assessment questionnaire to ensure compliance with the Payment Card Industry Data Security Standards (PCI DSS) each year.
Please reach out to Finance before contracting with any Payment Gateway Service Provider or P2PE.
PCI DSS Self Assessment Questionnaires
Annually, SPU merchants must complete annual a PCI DSS self-assessment questionnaires, must submit to periodic compliance inspections or audits, and may be required to submit to vulnerability scanning and penetration testing of systems which interact with and connect to the Cardholder Data Environment (CDE). questionnaire to ensure compliance with the Payment Card Industry Data Security Standards (PCI DSS).
SPU Merchants shall be responsible for costs associated with PCI DSS compliance as well as any fines or other fees associated with their non-compliance. In order to be able to interact with CHD and the CDE, SPU employees and Third Party Service Providers (TPSPs) must also complete internal and or external training, as directed, and attest to their understanding of PCI DSS compliance and their agreement to abide by the conditions of this policy. The policy applies to CHD received, processed, transmitted and/or stored on behalf of Northwestern University interests regardless of the processing channel or banking relationship, including but not limited to card swipe terminals, POS systems, e-Commerce/web applications, virtual terminals, paper forms, facsimile or telephone. All individuals involved in the processing of debit and/or credit card payments or who otherwise are exposed to credit and/or debit card information must comply with the Payment Card Industry Data Security Standard. This includes but is not limited to: Operational staff who handle, process, settle, reconcile, report on or otherwise interact with debit and credit card payments, or information. Technical staff who develop and/or maintain systems and solutions used to process cardholder information including hardware, software, networks and firewalls; this can include IT security personnel, network administrators, web administrators, web developers/programmers, project managers and any individual responsible for developing, implementing, integrating, managing securing and maintaining solutions which interact with the CDE. Third Party Service Providers (TPSPs) onsite or offsite (e.g. contractors, vendors, business partners, temporary help, etc.) who handle, process, settle, reconcile, report on or otherwise interact with debit and/or credit card payments, and information, or who are responsible for developing, implementing, integrating and managing solutions which interact with the Cardholder Data Environment, or which provider secure destruction of CHD. TPSPs with incidental access to the CDE and CHD, such as maintenance or custodial firms. Treasury Operations/e-Commerce Operations Page 2 of 4 http://www.northwestern.edu/controller/treasury-operations/e-commerce-operations/credit-card-security-pci-dss.html GENERAL REQUIREMENTS All card processing activities and related technologies must comply fully with the Payment Card Industry Data Security Standard (PCI DSS). Any activity conducted or any technology employed that obstructs compliance with any portion of the PCI DSS is a violation of this policy and is subject to immediate remedial action. Unless specified otherwise, each of these requirements applies to all merchant card locations. This policy shall be reviewed annually and updated as needed to reflect changes to business objectives, the risk environment or the applicable standards. Material policy changes will be communicated by email to NU merchants and through ongoing education in self-service or in-person presentation format. ADDITIONAL GUIDANCE FOR DEPARTMENTS Each merchant card location is responsible for compliance with PCI DSS. Please pay special attention to the following specific requirements where the department is usually the primary control point. This is not to imply that a merchant can focus on selected requirements, all merchants are required to ensure compliance with all PCI DSS requirements. NOTE: The specific PCI DSS requirements highlighted below are referenced by the PCI DSS v3.1 requirement numbers enclosed in parenthesis. (PCI DSSv3.1 2.1) Always change vendor-supplied defaults before installing a system on the network, including but not limited to passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts. (PCI DSSv3.1 2.2.a) Examine the organization’s system configuration standards for all types of system components and verify the system configuration standards are consistent with industry-accepted hardening standards. (PCI DSSv3.1 2.2.b) Verify that system configuration standards are updated as new vulnerability issues are identified, as defined in Requirement 6.2. (PCI DSSv3.1 2.2.c) Verify that system configuration standards are applied when new systems are configured. (PCI DSSv3.1 2.2.3.b) Verify that common security parameter settings are included in the system configuration standards. (PCI DSSv3.1 3.1) Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes. (PCI DSSv3.1 3.1.1) Implement a data retention and disposal policy (PCI DSSv3.1 3.2) Do not store sensitive authentication data after authorization (even if encrypted). (PCI DSSv3.1 3.3) Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed). (PCI DSSv3.1 4.1) Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks. Treasury Operations/e-Commerce Operations Page 3 of 4 http://www.northwestern.edu/controller/treasury-operations/e-commerce-operations/credit-card-security-pci-dss.html (PCI DSSv3.1 4.2) Never send unprotected PANs by end-user messaging technologies (for example, e-mail, instant messaging, chat, etc.). (PCI DSSv3.1 5.2) Ensure that all anti-virus mechanisms are current, actively running, and generating audit logs. (PCI DSSv3.1 6.1.b) Examine policies related to security patch installation to verify they require installation of all critical new security patches within one month. (PCI DSSv3.1 6.2) Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities. (PCI DSSv3.1 7.1) Limit access to system components and cardholder data to only those individuals whose job requires such access. (PCI DSSv3.1 8.5.8.b) Examine authentication policies/procedures to verify that group and shared passwords or other authentication methods are explicitly prohibited. (PCI DSSv3.1 9.1) Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment. (PCI DSSv3.1 9.7) Maintain strict control over the internal or external distribution of any kind of media. (PCI DSSv3.1 9.10.1) Shred, incinerate, or pulp hardcopy materials so that cardholder data cannot be reconstructed (PCI DSSv3.1 9.10.2) Render cardholder data on electronic media unrecoverable so that cardholder data cannot be reconstructed. (PCI DSSv3.1 11.1) Test for the presence of wireless access points and detect unauthorized wireless access points on a quarterly basis. (PCI DSSv3.1 11.2) Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades). (PCI DSSv3.1 12.1) Establish, publish, maintain, and disseminate a security policy (PCI DSSv3.1 12.1.1) Addresses all PCI DSS requirements (PCI DSSv3.1 12.1.2) Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment (PCI DSSv3.1 12.1.3) Includes a review at least annually and updates when the environment changes Policy References Payment Card Industry (PCI) Data Security Standard – Requirements and Security Assessment Procedures Version 3.1 815 ILCS 530 Illinois Personal Information Protection Act (PIPA) of 2006 Treasury Operations/e-Commerce Operations Page 4 of 4 http://www.northwestern.edu/controller/treasury-operations/e-commerce-operations/credit-card-security-pci-dss.html PCI DSS Glossary of Terms and Concepts: http://www.northwestern.edu/controller/treasuryoperations/e-commerce-operations/docs/PCI DSS-Glossary-v3
All SPU merchant locations are required to validate PCI-DSS compliance at least annually by completing a PCI DSS self-assessment questionnaire (SAQ) in a timely manner. A questionnaire must be completed for each merchant account, and a new questionnaire must be filled out whenever any of the following have occurred:
payment processing system changes
a year has elapsed since your last SAQ
upon Finance request
The SAQ should be completed throughhttps://pcicompliancemanager.com/.
There are 8 types of SAQ. Finance can help determine which type is required for your merchant location environment:
SAQ | Description |
---|---|
A | Card-not-present merchants (e-commerce or mail/telephone order) that have fully outsourced all cardholder data functions to PCI DSS compliant third-party service providers |
A-EP | Merchants accepting only e-commerce transactions that have partially outsourced the e-commerce payment channel to compliant third parties; merchant’s website does not receive account data, but controls how customers, or their account data, are re-directed to the third-party. |
B | Merchants using stand-alone, dial-out terminals |
B-IP | Merchants using stand-alone PTS-approved payment terminals with an IP connection to the payment processor |
C | Merchants with payment application systems connected to the Internet, no electronic cardholder data storage |
C-VT | Merchants with web-based virtual payment terminals provided and hosted by a PCI DSS compliant third-party service provider |
P2PE | All payment processing is via a validated PCI-listed P2PE solution |
D | Merchants with electronic storage of cardholder data; all merchants not included in the descriptions for above SAQ types |
D-SP | All service providers defined by a payment brand as SAQ-eligible |
...
SPU Merchant/Departmental credit card transaction procedures:
SPU provided laptops, desktop computers, mobile devices, and SPU network resources (wired, wireless, internet connection) can NOT be used to submit credit card transactions without an attached P2PE device.
Devices personally-owned by the SPU staff member facilitating the transaction (laptops, desktop computers, mobile devices, tablets, smartphones, etc..) must NOT be used to submit credit card transactions.
P2PE devices are required for:
Card-Present procedures: card-swipe or chip-insert at point of sale (P2PE device) with process in view of the customer. CVV must not be copied or stored.
Card-Not-present procedures (phone, postal mail, etc): card-entry at point of sale (P2PE device) on dedicated touch-pad.
Never use existing “self-service” systems to submit credit card data on behalf of the customer (you can use “Converge” during this transition to P2PE devices, but don not use the self-service systems).
If cardholder data is sent to you unsolicited via email -- immediately notify the customer that the University does not accept credit card data via email and provide alternative methods of completing the transaction. If email is sent back to the customer any credit card data must be deleted from the return message. Delete the email (permanent delete from email store, deleted items, and recover deleted items (DELETE/SHIFT) after the customer has been notified.
DO NOT direct customers to an SPU computer lab, classroom, or kiosk computer to enter their credit card information. Provide the URL where they can select a device of their choice to complete the transaction. We never recommend using public/shared systems for financial transactions, for SPU transactions or otherwise.
All departments will complete appropriate reconciliation and submittal of transaction charges on a timely basis (generally daily). Transactions are not to be held and batched at a later time.
Definition of Terms
...
Term | Definition |
---|---|
PCI DSS | Payment Card Industry - Data Security Standard (PCI DSS) The PCI Security Standards Council publishes a set of standards for merchants to use to ensure secure handling of credit card transactions. The current standard is PCI DSS v3.2.1 |
Cardholder Data (CD) | Name, card number/account number, expiration date, CVV2, CVC2, CID. In certain circumstances a portion of the card may be visible (final 4 or first 6 numbers). Includes both credit and debit cards. |
Cardholder Data Environment (CDE) | Any system, process, person, contractor, consultant, or device involved in submitting or completing credit card transactions. Any server, database, application, or network that stores or transmits card holder data. |
In-Scope vs. Out-of-scope | "In-scope" = any CDE that is under the control of the university and directly involved in the processing or submission of card holder data. "Out-of-scope" = transaction elements outside the control of the university (compliance rests with the outside resource or agent). |
Point-of-sale devices | P2PE -- Point-to-Point-Encrypted devices that are hardware solutions that provide PCI grade encryption. Many options are available from USB add-on hardware, to stand alone devices that connect to ethernet ports or cellular service providers. |
Merchant ID (MID) | The ID number that is provided by the bank or financial institution to the University. |
Card Swipe/EMV Reader | In a card-present transaction the card reader gathers cardholder data when the magnetic stripe is swiped. EMV stands for Europay, MasterCard, and Visa, the three companies that originally created the standard and refers to the security "chip" that is embedded in most credit cards. |
Types of transactions | There are many type of transaction performed on campus:
|
SAQ | A "Self Assessment Questionnaire" (SAQ) includes a series of questions for each applicable PCI Data Security Standard requirement. There are different questionnaires available to meet different merchant environments. |