skip to Main Content

Administrative Procedure 8.710 Administrative Procedure 8.710



Title

Credit Card Program

Header

Administrative Procedure Chapter 8, Business and Finance
Administrative Procedure AP 8.710, Credit Card Program
Effective Date:  January 2020
Prior Dates Amended:  June 1992, July 2001, April 2005, March 2015
Responsible Office: Office of the Vice President for Budget and Finance/Chief Financial Officer
Governing Board and/or Executive Policy: EP 1.102, Authority to Manage and Control the Operations of the Campus
Review Date:  January 2022

I. Purpose

This policy applies to credit card payments processed by the University designated as the merchant of record.  The purpose of this policy is to outline the responsibilities of departments that accept credit card payments and to provide procedures for these departments to follow.

To safeguard the University’s information technology resources and to protect the confidentiality of cardholder data, adequate security measures must be taken.  Credit card data stored, processed, or transmitted by the University merchant accounts must be protected and must conform to the Payment Card Industry Data Security Standard (PCI DSS).

The University requires that all departments that accept credit card payments comply with applicable PCI DSS requirements and related University policies and procedures.

Departments that fail to comply with PCI DSS and University policies and procedures may have their ability to accept credit cards suspended or revoked.  In addition, they may face penalties, fines, or restrictions.

Portions © 2019 Security Metrics, Inc.  All Rights Reserved.  Used by permission.

II. Definitions

A.  Contractor – The vendor contracted by the University to provide merchant processing services, including authorization, processing, settlement and reporting of credit and debit card transactions.  The Contractor also provides equipment, software, training and support necessary to process these transactions.

B.  Merchant Department – A University department that is approved to accept credit cards as a form of payment.  It is also referenced as the Merchant in this Administrative Procedure.

C.  Merchant Account Contact – A regular, full-time employee that has been designated as the primary contact of the merchant and who coordinates the merchant’s compliance with PCI DSS and related University policies and procedures.  The Merchant Account Contact shall be appointed by the Dean/Director or Department Head of the unit.

D.  Merchant Fee – The service fee paid to the contractor by the Merchant based on the terms of the University’s merchant contract.

E.  Merchant Identification Number (MID) - A unique identification number established and issued by the contractor that identifies the department as a merchant.

F.  Merchant Information Technology (IT) Contact – The department’s designated IT staff member that works with the Merchant Account Contact on implementing required safeguards related to the merchant’s technical PCI DSS requirements.

G.  Payment Card – For purposes of PCI DSS, payment cards includes any credit, debit or prepaid cards used in financial transactions that bear the logo of the five major card associations (Visa, MasterCard, American Express, Discover and JCB).  In this Administrative Procedure, the term credit card may be used in lieu of Payment Card.

H.  Payment Card Industry (PCI) – Includes Payment Card brands, issuing and acquiring banks, independent sales organizations, service providers and merchants who accept Payment Cards.

I.  PCI Security Standards Council (SSC) – A council comprised of the five major card associations including, Visa, MasterCard, American Express, Discover and JCB International.  The council is responsible for the development, management, education and awareness of the PCI DSS.

J.  PCI DSS – A set of twelve technical and operational requirements set by the PCI SSC to protect cardholder data and reduce credit card fraud.  These standards apply to all entities that store, process or transmit cardholder data.  The Merchant Department is required to meet the applicable requirements for their payment processing method/merchant environment. 

K.  Payment Processing Method – How a credit card transaction is processed, which includes:

    1.  In-Person/Card Present – in person transactions where the cardholder presents their credit card to
          make a payment.
    2.  eCommerce – a non-face-to-face, on-line transaction using electronic media over a public or private
          network.  Refers to all forms of business activities conducted over computer networks such as the
          Internet.
    3.  Mail order/telephone order (MOTO) – cardholder data is provided to the merchant by the cardholder
          via mail, facsimile or through the phone.  Credit card information sent via other electronic methods
        (e.g. email, text, etc.) is prohibited.

L.  Third-Party Payment Processing Service Provider – A third-party that provides connectivity among merchants, customers and financial networks to process authorization and payments and securely stores Payment Card data.  The provider must be a PCI DSS validated third-party. 

M.  Self-Assessment Questionnaire (SAQ) – An annual self-assessment and attestation intended to demonstrate compliance with PCI DSS.

Portions © 2019 Security Metrics, Inc.  All Rights Reserved.  Used by permission.

III. Administrative Procedure

A.  Roles and Responsibilities

    1.  Treasury Office

          a.  Establish and document policies and procedures related to University’s credit card program.
          b.  Establish merchant accounts.  This includes approval or disapproval of requests to participate in
                the credit card program, including requests to use a third party payment processing service. 
          c.  Create the Credit Card Vendor Number in the University’s financial system.
          d.  Close merchant accounts.
          e.  Establish and maintain relationships with Contractor and other entities related to credit card
              processing.
          f.  Coordinate review for new merchant requests and modifications to existing merchant set up and
              collaborate with Information and Technology Services (ITS), as needed, for review of network
              segmentation configuration and other technical safeguards.
          g.  Coordinate University PCI compliance process, including coordinating training and distribution of
              information notifications to University merchant personnel.
          h.  Submit University’s consolidated SAQ on an annual basis, based on information received from the
              Merchant Account Contacts and in accordance with terms of the merchant service contract.

    2.  Merchant Department

          a.  Protect credit card data by complying with security requirements and safeguard of cardholder data
              as set forth by the PCI DSS.  Failure to comply may increase the University’s exposure to increased
              fraudulent activity.
          b.  Comply with University policies and procedures and with terms of the University’s contract for
              credit card processing.
          c.  Comply with any Merchant Department specific procedures.
          d.  Fiscal Staff
              (1)  Make timely payment of all merchant fees, rental costs of equipment or software, dedicated
                    analog lines and data costs.
              (2)  Respond to chargeback notices in timely manner.
          e.  Dean/Director or Department Head
              (1)  Appoint Merchant Account Contact.
              (2)  Understand responsibilities with compliance related to accepting credit card payments for the
                    Campus/School or department.
              (3)  Accept responsibility for any fines, fees, or penalties assessed for data breaches due to
                    merchant’s non-compliance of PCI DSS requirements.
              (4)  Ensure Merchant Account Contact is completing the required documentation.
          f.  Merchant Account Contact
              (1)  Notify the Treasury Office by completing and submitting the Credit Card Program – Participation
                    and Change Request Form (Appendix B) for establishment of a new MID and for any changes to
                    the existing merchant environment (changes to contact information, payment processing
                    method, payment processing device, third party service provider, etc.) prior to implementing
                    change.
                (2)  Coordinate with department and information technology (IT) staff as needed for PCI DSS
                    compliance program process.
                (3)  Compile and maintain merchant documentation, as required.
                (4)  Complete the PCI DSS Checklist review, as applicable.
                (5)  On an annual basis, complete the applicable merchant SAQ and submit as requested to the UH
                      Treasury Office by due dates established.  Failure to submit the SAQ will cause the University to
                      be out of compliance.
                (6)  Leads Merchant Department incident response and remediation procedures for merchant’s
                      unit, to include but not limited to, reporting incidents to the UH Chief Information Security
                      Officer  (CISO) & Incident Response Team (IRT) and conduct incident handling and remediation
                      as directed by CISO and IRT.
                (7)  Coordinate PCI DSS security activities, to include but not limited to information and physical
                      security.
          g.  Merchant IT Support Staff/Department
              (1)  Supports and implements PCI DSS process, to include but not limited to internal vulnerability
                    scanning, developing and maintaining secure systems and applications, protection of systems
                    (e.g. anti-virus), and maintaining properly configured firewalls in consultation with ITS
                    Information Security Team as necessary.
                (2)  Support Merchant for IT security-related incident response and remediation.

    3.  ITS Information Security Team

          a.  Collaborate with UH Treasury Office on technical requirements and coordinates policies and
              procedures related to the University’s PCI DSS security.
          b.  Assist UH Treasury Office with reviews of merchant departments SAQs and overall submission of
              University SAQ.
          c.  Assist merchant departments with PCI DSS technical training, technical guidance, and compliance
              services.
          d.  As part of the IRT, direct and coordinate technical investigation for security-related incidents.
          e.  Provide technical guidance to merchant as needed.

B.  Procedure to Participate in Payment Card Program

    1.  Merchant Account Contact submits a Credit Card Program – Participation and Change Request Form
          to the UH Treasury Officer.  Among other information, the request shall include the following:

          a.  The justification for participating in the Payment Card program;
          b.  The legal authority that permits the campus/department to collect and deposit receipts (Consult
              with FMO Tax Services for review of any Unrelated Business Income Tax considerations, as
              necessary);
          c.  For eCommerce payment processing:
              (1)  The University has implemented a third party (TouchNet Information Systems, Inc. (TouchNet))
                    secure, PCI DSS compliant, hosted eCommerce management system that supports payment
                    processing for a variety of eCommerce applications. Merchant departments shall use the
                    designated eCommerce system, unless an exception is granted.
                    (a)  Exceptions may be granted if:
                          (i)    TouchNet cannot meet the business needs of the merchant.
                          (ii)  The alternate system is in compliance with PCI DSS.
                          (iii)  The alternate system must be able to process credit card transactions utilizing the
                                  Contractor’s processor (i.e. FISERV (FKA First Data)).
                          (iv)  The information about the proposed alternate system must be included on the Credit
                                  Card Program – Participation and Change Request Form.
                    (b)  Departments granted an exception to use an alternate system will be responsible for any
                          costs to operate and maintain the system.
                    (c)  Departments granted such exceptions also assume all responsibility and liability for the
                          security of all transactions and data, including any monetary loss suffered by the University
                          due to theft or improper use of credit card numbers and data breach remediation costs from
                          failure to comply with PCI DSS.
              (2)  The Credit Card Program – Participation and Change Request Form must be signed by the
                    Merchant Account Contact, merchant department IT contact, fiscal administrator, and
                    Dean/Director or Department Head.
              (3)  Once approved, the Treasury Office will submit the request to the Contractor for MID
                      application process.
              (4)  Contractor will provide MID once application is approved.
              (5)  Departments are prohibited from contracting directly for credit card services from the
                    Contractor or any other entity. 

C.  Receipting, Recording and Reconciling
    1.  Refer to Administrative Procedure 8.701, Receipting and Depositing Funds Received by the University,
          Section III.E. for procedures on receipting, recording and reconciling credit card transactions.
 
D.  Responding to Dispute Notifications

    1.  Should a cardholder dispute a credit card transaction, a dispute notice will be provided to the
          merchant’s fiscal administrator.
    2.  A response must be submitted by the merchant for all dispute notifications to the processor as
          directed on the chargeback notice. 
    3.  The merchant will receive an invoice from the Contractor for the chargeback amount, regardless of
          the outcome of the dispute decision.  The merchant shall promptly process payment to the
          Contractor.
    4.  Should the dispute be decided in favor of the University and the chargeback reversed, the UH
          Treasury Office will notify the merchant contact and the merchant will record the receipt of the funds
          in the University’s financial system. 

E.  Procedures to Withdraw from the Credit Card Program

    1.  Submit the Credit Card Program – Participation and Change Request Form (mark as “Request to
          Close”) with applicable signatures and explanation of reason to withdraw from the program to the UH
          Treasury Office.
    2.  Upon approval, the UH Treasury Office shall coordinate the closing procedures with merchant
          department and Contractor.
    3.  Any equipment obtained from the Contractor must be promptly returned.

F.  University PCI DSS Compliance Process

    1.  Background
          a.  The PCI SSC set forth PCI DSS, a set of twelve technical and operational requirements to protect
              cardholder data and reduce credit card fraud. 
          b.  The PCI DSS requirements apply to all organizations that store, process or transmit credit card
              data, thus, as such an organization, the University is required to comply with PCI DSS.
          c.  Each University Merchant is required to comply with University policies and procedures and the
              applicable PCI DSS requirements based on their payment processing method/merchant
              environment.
          d.  University policies and procedures and PCI DSS requirements apply to all University Merchant
              personnel involved with University merchant operations that could affect the security of cardholder
              data.

    2.  The SAQ is an annual PCI-mandated attestation intended to demonstrate compliance with PCI DSS.
          Depending on the payment processing method/ merchant environment, a specific set of PCI DSS
          requirements are applicable and are detailed in the applicable SAQ.  Failure to meet the PCI DSS
          requirements may increase exposure to fraudulent activity.  In addition, failure of the Merchant
          Account Contact to submit the SAQ on an annual basis will cause the University to be out of
          compliance. 

Descriptions for each SAQ type are provided below:
______________________________________________________________________________________________________________
SAQ Type                                                              Description
A                          Card not present (eCommerce) merchants that have fully outsourced all cardholder data
                            functions to PCI DSS compliant third-party service providers with no electronic storage,
                            processing, or transmission of any cardholder data on the merchant’s systems or premise.
                            This SAQ is applicable for the University merchants utilizing TouchNet.
______________________________________________________________________________________________________________
A-EP                    eCommerce merchant who outsources all payment processing to a PCI DSS validated third
                            party, but whose website may impact the security of the payment transaction.  No
                            electronic storage, processing or transmission of cardholder data on merchant’s systems or
                            premises.
______________________________________________________________________________________________________________
B                          Card-present merchant that uses a standalone dial-out terminal (analog or cellular phone
                            line) to process credit cards or imprint machines; no electronic cardholder data storage.
______________________________________________________________________________________________________________
B-IP                      Merchants using only standalone, PIN Transaction Security (PTS) approved payment
                            terminals with an Internet Protocol (IP) connection to the payment processor with no
                            electronic cardholder data storage.
______________________________________________________________________________________________________________   
C                          Merchants with payment application systems connected to the Internet, no electronic
                            cardholder data storage.
______________________________________________________________________________________________________________
C-VT                      Merchants that manually enter a single transaction at a time via keyboard into an internet-
                              based virtual terminal solution that is provided and hosted by a PCI-DSS validated third-
                              party service provided.  The terminal used shall only process payments. No electronic
                              cardholder data storage.
_______________________________________________________________________________________________________________
P2PE                    Merchants using only hardware payment terminals included in and managed via a
                              validated, PCI SSC-listed Point-to-Point Encryption (P2PE) solution (the P2PE solution must
                              be listed at: https://www.pcisecuritystandards.org/assessors_and_solutions
                              /point_to_point_encryption_solutions) with no electronic cardholder data storage.
_______________________________________________________________________________________________________________
D                          All merchants not included in descriptions for the above SAQ types.  Applies to merchants
                              that electronically store cardholder data.  Electronic storage of cardholder data is not
                              allowed at the University.
________________________________________________________________________________________________________________

    3.  PCI DSS Requirements
          a.  PCI DSS is comprised of 6 primary goals with 12 requirements.  These goals and requirements were
              designed to ensure safe-handling of sensitive information related to credit card transactions.  The 
              goals and requirements are listed below.  To see the complete PCI DSS requirements and additional
              information on PCI DSS, see the PCI SSC website at:  https://www.pcisecuritystandards.org/

          Goal - Build and Maintain a Secure Network and Systems
          b.  Requirement #1 – Install and maintain a firewall configuration to protect cardholder data
              Firewalls are devices that control computer traffic allowed between the University’s networks
              (internal) and untrusted networks (external), as well as traffic into and out of more sensitive areas
              within an entity’s internal trusted networks. The cardholder data environment is an example of a
              more sensitive area within an entity’s trusted network.  A firewall examines all network traffic and
              blocks those transmissions that do not meet the University’s specified security criteria.

              All systems must be protected from unauthorized access from untrusted networks, whether
              entering the system via the Internet as e-commerce, employee Internet access through desktop
              browsers, employee e-mail access, dedicated connections such as business-to-business
              connections, via wireless networks, or via other sources. Often, seemingly insignificant paths to and
              from untrusted networks can provide unprotected pathways into key systems. Firewalls are a key
              protection mechanism for any computer network.

              Other system components may provide firewall functionality, as long as they meet the minimum
              requirements for firewalls as defined in this requirement. Where other system components are
              used within the cardholder data environment to provide firewall functionality, these devices must
              be included within the scope and assessment of requirement 1.

          c.  Requirement # 2- Do not use vendor-supplied defaults for system passwords and other security
              parameters
              System components used in sensitive networks often will come with default vendor settings
              (usernames, passwords, configuration settings, etc.).  Vendor-supplied defaults for system
              passwords and other security parameters must be changed before systems are installed in the
              secure network environment (cardholder data network).

              Individuals with malicious intent (external and internal to an entity) often use vendor default
              passwords and other vendor default settings to compromise systems. These passwords and
              settings are well known by hacker communities and are easily determined via public information.

          Goal - Protect Cardholder Data
          d.  Requirement #3 – Protect cardholder data
          Cardholder data is defined as:
            •    Primary Account Number (PAN)
            •    Card Validation Code (CVV, CVV2, and CVC2)
            •    Credit Card Personal Identification Number (PIN)
            •    Any form of magnetic stripe data from the card (Track 1, Track 2)

          Cardholder data must be protected when stored or in transit over public (or untrusted) networks.
          Strong industry standard encryption methodologies must be used to protect data stored on hard
          drives, removable media, backups, etc. 

          Protection methods such as encryption, truncation, masking, and hashing are critical components of
          cardholder data protection. If an intruder circumvents other network security controls and gains
          access to encrypted data, without the proper cryptographic keys, the sensitive data is unreadable and
          unusable to that person.

          e.  Requirement #4 – Encrypt transmission of cardholder data across open, public networks
              Cardholder data must be encrypted during transmission over networks that are easily accessed by
              malicious individuals. Misconfigured wireless networks and vulnerabilities in legacy encryption and
              authentication protocols continue to be targets of malicious individuals who exploit these
              vulnerabilities to gain privileged access to cardholder data environments.

          Goal - Maintain a Vulnerability Program
          f.  Requirement #5 – Protect all systems against malware and regularly update anti-virus software or
              programs
              System components within the cardholder data network must be part of an active vulnerability
              maintenance program.  This program will control the existence of malicious software (e.g., anti-
              virus software) and provide policies covering development efforts and system or software
              updates/upgrades such that security is maintained.

              Malicious software, commonly referred to as “malware”—including viruses, worms, and Trojans
              —enters a sensitive network segment during many business approved activities, including
              employees’ e-mail and use of the Internet, mobile computers, and storage devices, resulting in the
              exploitation of system vulnerabilities. Anti-virus software must be used on all systems commonly
              affected by malware to protect systems from current and evolving malicious software threats.

          g.  Requirement #6 – Develop and maintain secure systems and applications
              Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of
              these vulnerabilities are fixed by vendor-provided security patches, which must be installed by the
              entities that manage the systems. All systems must have all appropriate software patches to
              protect against the exploitation and compromise of cardholder data by malicious individuals and
              malicious software.

              Note: Appropriate software patches are those patches that have been evaluated and tested
              sufficiently to determine that the patches do not conflict with existing security configurations.

          Goal - Implement Strong Access Control Measures
          h.  Requirement #7 – Restrict access to cardholder data by business need to know
              Access to system components and software within the cardholder data network must be controlled
              and restricted to those with a business need for that access.  This is achieved using active access
              control systems, strong controls on user and password management, and restricting physical
              access to critical or sensitive components and software to individuals with a “need to know.”

              Systems and processes must be in place to limit access to critical data and systems based on an
              individual’s need to know and according to job responsibilities.

              Need to know is when access rights are granted to the least amount of data and privileges needed
              to perform a job.

          i.  Requirement #8 - Identify and authenticate access to system components
              It is critical to assign a unique identification (ID) to each person with access to critical systems or
              software. This ensures that each individual is uniquely accountable for his or her actions. When
              such accountability is in place, actions taken on critical data and systems are performed by, and can
              be traced to, known and authorized users.

          j.  Requirement #9 – Restrict physical access to cardholder data
              Any physical access to data or systems that house cardholder data provide the opportunity for
              individuals to access devices or data and to remove systems or hardcopies, and should be
              appropriately restricted.

          Goal - Regularly Monitor and Test Networks
          k.  Requirement #10 – Track and monitor all access to network resources and cardholder data
              Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or
              minimizing the impact of a data compromise. The presence of logs in all environments allows
              thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of
              a compromise is very difficult without system activity logs.  Detailed monitoring procedures should
              be developed and documented.

          l.  Requirement #11 – Regularly test security systems and processes
              Vulnerabilities are continually being discovered in current, and introduced by new software. System
              components, processes, and custom software must be tested frequently to ensure security controls
              continue to reflect a changing environment. Detailed testing procedure should be developed and
              documented.

          Goal - Maintain an Information Security Policy
          m.  Requirement #12 – Maintain a policy that addresses information security for all personnel
                Consistent policies and procedures are required to be practiced and followed at all times.

              All employees should be aware of the sensitivity of data and their responsibilities for protecting it.
              The University’s information security policy and procedures apply to all employees (full-time, part-
              time, casual hires, student employees) and others (i.e. volunteers) that work within the University’s
              cardholder data environment. 

              Refer to Appendix C for University’s PCI Incident Response Plan Guidelines.

    4.  Applicable University Policies
          a.  The Information Security Governance Leadership Group ensures that all information security
              policies, procedures and other initiatives are implemented and maintained within their authorities.
          b.  University policies related to Information Security are available at https://www.hawaii.edu/infosec
              /policies/ and include the following, but are not limited to:
              (1)  EP 2.210 – Use and Management of Information Technology Resources Policy
              (2)  EP 2.214 – Institutional Data Classification Categories and Information Security Guidelines
                    (a)  Credit card information is categorized as “Regulated.”  This means that inadvertent
                          disclosures or inappropriate access requires breach notification in accordance with HRS
                          §487N and is subject to financial fines.
                    (b)  Refer to General Information Security Practices, and Technical Guidelines Table for
                            Regulated data at: https://www.hawaii.edu/infosec/techguidelines/#regTable
              (3)  EP 2.215 – UH Institutional Data Governance Policy
              (4)  EP 8.200 – Policy on Contracts and Signing Authority
              (5)  AP 2.215 – Mandatory Training and Continued Education Requirements for Data Users
                    (a)  All personnel that handle cardholder data are required to meet requirements of AP 2.215,
                          including:
                          (i)  Submission of General Confidentiality Notice (GCN)
                          (ii)  Completion of Information Security Awareness Training (ISAT)
              (6)  AP 8.450 – Records Management Guidelines and Procedures
        c.  External standards and regulations include:
              (1)  HRS 487N – Security Breach of Personal Information (https://www.capitol.hawaii.gov/hrscurrent
                    /Vol11_Ch0476-0490/HRS0487N/HRS_0487N-.htm)
              (2)  PCI  DSS – Payment Card Industry Data Security Standard https://www.pcisecuritystandards.org
                    /pci_security/
          d.  The University’s policies and procedures related to the University’s PCI DSS compliance process is
              reviewed at least annually.  Merchant departments that establish supplemental procedures for
              their departments should annually review their procedures to reflect changes to business
              objectives or risk environment.

    5.  Merchant PCI DSS Compliance Process
          a.  The Merchant must determine the applicable SAQ type required for the MID based on the payment
              processing method/merchant environment as described in the table above.  Whenever there is a
              change in the merchant’s processing method or environment the Merchant Account Contact must
              complete the Credit Card Program – Participation and Change Request Form before any change is
              implemented, and the merchant’s SAQ type should be re-evaluated.  The SAQ type will govern the
              PCI DSS requirements applicable to the Merchant.

          b.  At mid-year, or whenever there is a change in the Merchant’s processing method or environment,
              the Merchant Account Contact should complete the applicable SAQ checklist, as provided by the UH
              Treasury Office,  to determine compliance with PCI DSS and University requirements.

          c.  To provide Merchant Departments with assistance on technical requirements, refer to the UH ITS
              PCI Technical Guidelines document (Appendix A).

          d.  The Merchant Account Contact shall compile and maintain all required PCI DSS documentation for
              the merchant.  The SAQ checklist provides information on supporting documentation that should
              be maintained and references to templates available.  The Merchant should identify and maintain
              additional documentation to support the applicable PCI DSS requirement compliance efforts.

          e.  All merchants must be compliant with PCI DSS.  Any non-complying requirements identified must
              be remediated or brought to the attention of the UH Treasury Office for assistance in resolution.

          f.  The UH Treasury Office will send out a request for completion and submission of the annual SAQ
              and attestation.  The checklist and required documentation serve as back-up documentation for
              completion and support of the preparation of the merchant’s annual SAQ and attestation of
              compliance.  The Merchant Account Contact shall submit the SAQ and any other required
              documents by the due date established by the UH Treasury Office.

          g.  The Treasury Office and/or ITS Information Security may request information to review and validate
              responses to the mid-year checklist and/or annual SAQ.  Required PCI DSS documents should be
              maintained and may be requested in this validation process.

    6.  University SAQ Process
          a.  On an annual basis, the Treasury Office is required to submit a SAQ on behalf of the entire
              University to its Contractor. 

          b.  The University’s SAQ is based on the individual SAQ submissions by merchant departments.  The
              Treasury Office will review the merchant prepared SAQs in consultation with ITS for technical
              requirements, as necessary.

          c.  The University is required to be in compliance with PCI DSS, therefore, all merchants must be in
              compliance.

Portions © 2019 Security Metrics, Inc.  All Rights Reserved.  Used by permission.

IV. Delegation of Authority

There is no administrative specific delegation of authority.

V. Contact Information

    
Treasury Office, 956-7638, or jyama@hawaii.edu
Website: http://www.fmo.hawaii.edu/cash_handling/index.html#tab1

VI. References

PCI Security Standards Council:  https://www.pcisecuritystandards.org/pci_security/

PCI DSS validated payment applications: https://www.pcisecuritystandards.org/assessors_and_solutions/payment_applications?agree=true.

Visa Global Registry of Service Providers:
https://www.visa.com/splisting/searchGrsp.do

General Information Security Practices, and Technical Guidelines Table for Regulated data: https://www.hawaii.edu/infosec/techguidelines/#regTable

VII. Exhibits and Appendices

Appendix A – UH PCI Technical Guidelines
    
Appendix B - Credit Card Program – Participation and Change Request Form
    
Appendix C – UH PCI Incident Response Plan Guidelines

Approved

    Signed    
    Kalbert Young    
    January 31, 2020    
    Date    
    Vice President for Budget and Finance/Chief Financial Officer

Topics

credit card payments; merchants; payment processing methods; PCI DSS

Attachments