Payment Card Data Security Procedures

Legislative History:

Approved by the Vice-President Finance and Administration, to give effect to the University Guideline on Payment Card Data Security issued July 1, 2012

Approval Authority: Vice-President Finance and Administration

Signature: Gary Brewer

Description: Describes the requirements and detailed procedures for York University departments, offices and units accepting payment card transactions to be compliant with the Payment Card Industry Data Security Standard (PCI DSS).


Acquirer: A financial services company that fulfills the dual role of providing merchant banking and card transaction processing services.

AOC: An Attestation of Compliance for the University must be completed annually and submitted to the acquirer.

ASV: An Accredited Scanning Vendor is a company that validates adherence to certain DSS requirements by performing vulnerability scans of Internet facing environments of merchants and service providers.

Card Brands: Also known as the Payment Card Companies or Payment Card Brands, are the multi-national acceptance companies that constitute the principal membership of the Payment Card Industry Security Standards Council (PCI SSC).

Cardholder Data (CHD): Primary information that is the object of PCI DSS security includes credit card account number, expiry date, security code and PIN, as issued by Card Brands. (YU-cards are not directly subject to PCI DSS or these payment card data procedures.)
EMV: A set of global standards that allow chip and PIN cards to operate with chip-enabled terminals, pinpad devices and ATMs.
ICT: The Information & Communication Technology Infrastructure unit within UIT that plans, develops and operates the University’s common IT infrastructure services including telecommunications, network, data centre, servers, storage, databases, workgroup technology and information security.

Merchant: Any University department, office or unit that generates revenues through arrangements that involve acceptance of payment cards.

Merchant Account/Merchant Identification (MID): A specific merchant arrangement with the University’s acquirer for direct acceptance of credit and debit card payments. Many types of merchant arrangements are possible including point-of-sale terminals, virtual terminals, eCommerce, and integrated. Each Merchant ID has associated Card Brand accounts (Ex: VI, MC, IN)

PA-DSS: Payment Application Data Security Standard.

PAN: The Primary Account Number for payment cards is the 8-digit number following the 6-digit BIN (Bank Identification Number). The last 4 digits are a validation algorithm.

Payment Brand Companies: Also known as the Card Brands or Payment Card Brands, are the multi-national acceptance companies that constitute the principal membership of the Payment Card Industry Security Standards Council (PCI SSC).

Payment Card: A payment card is a card that can be used by a cardholder and accepted by a merchant to make a payment for a purchase or in payment of some other obligation.

Payment Card Industry: PCI denotes the debit, credit, prepaid, e-purse, ATM, and POS cards and associated businesses.

PCI DSS: Payment Card Industry Data Security Standard.

PCI SSC: Payment Card Industry Security Standards Council is the governing body.

PTS: PIN Transaction Security standards apply to hardware.

QSA: A Qualified Security Assessor is a company qualified by the PCI SSC to have its accredited employees assess compliance with the PCI DSS standard.

SAQ: A Self-Assessment Questionnaire is a validation document for merchants and service providers that shall be completed for the purpose of self-evaluating compliance with PCI DSS. Types: SAQ-A, SAQ-B, SAQ-B-IP, SAQ-C, SAQ-D)

Service Provider: A third-party supplier or vendor that provides applications or services that incorporate payment card acceptance or processing.

UIT: University Information Technology is a department within the Finance and Administration Division of York University.


These Payment Card Data Security Procedures specify the standards that the University and its departments, offices and units accepting payment card transactions (“merchants”) shall fulfill in order to achieve and maintain compliance with cardholder data protection and security requirements as established in the PCI DSS.

1. The relevant PCI DSS is the current version as released by the PCI SSC. When transitioning from a previous release to the newest release, the University Steering Committee will control the timing of University-wide switchover while adhering to the deadlines for adoption specified in the newest release.

2. These Procedures apply to all University activities that involve any form of payment card handling.

3. PCI DSS applies to all card acceptance arrangements where the proceeds of revenue generating activities received from card-paying customers of the University are ultimately deposited to the University’s bank account for credit to the cost centre of the beneficiary department, office or unit.

4. PCI DSS applies to all merchants that generate revenues by the acceptance of credit cards (Visa, MasterCard, American Express, Discover).

5. Merchants that generate revenues through the acceptance of debit cards (Interac network) are also subject to these Procedures.

6. PCI DSS compliance requirements apply to the handling of credit cardholder data (CHD) and processing.

7. These Procedures apply to:

a. University merchants accepting card payments on University premises and at University events, including mobile operations;

b. University systems, infrastructure and networks when utilized for transacting, transmitting or storing card payments data; and

c. Service providers (third-party suppliers or vendors) that provide applications or services directly or indirectly to a department, office or unit of the University that incorporate payment card acceptance and/or processing.

d. Service provider types include:

i. Payment applications that are incorporated in software or on-line accessed services

ii. Systems and services that accept point of sale or eCommerce card payments on behalf of a University merchant that:
remit proceeds to the University by cheque or electronic funds transfer, or
interface with the University’s acquirer; and

iii. Hosting services that process card transactions for the University or its contracted service provider.


8. PCI DSS is a multi-faceted security standard intended to help organizations proactively protect customer account card data encountered as part of their business and information technology activities.

9. Compliance with PCI DSS represents a contractual requirement of the payment brand companies and the PCI SSC that obligates service providers and merchants to meet minimum security standards anywhere they store, transmit and/or process credit card account numbers and other credit cardholder data.

10. The PCI SSC has specified rules that apply to merchants and service providers each involving a series of required validation steps. These are:

Build and Maintain a Secure Network

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 - Use 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 - Assign a unique ID to each person with computer access
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 Policy

12 - Maintain a policy that addresses information security for all personnel

11. The University, its merchants and its systems are all required to be in compliance with this standard and are subject to validation at least annually.


12. The PCI DSS Steering Committee is an oversight committee established to govern and advise on PCI compliance at York University. Committee membership includes:

• Assistant Vice-President Campus Services and Business Operations
• Assistant Vice-President Finance and Chief Financial Officer
• Chief Information Officer
• Director, ICT Infrastructure and Information Security Officer
• Treasurer

13. PCI DSS Program Responsibilities of Treasury/Finance include the following activities:

a. Safeguarding the University financial assets and transactions.

b. Providing guidelines and instruction to merchants on PCI compliance.

c. Submitting required annual AOC to acquirer(s).

d. Advising and guiding merchants and prospective merchants on best practices and permissible arrangements for payment card acceptance.

e. Reviewing and approving applications from units for merchant accounts, eCommerce platforms, and changes to merchant arrangements.

f. Arranging banking and/or other financial services for approved applicants.

g. Assessing merchant compliance to the University and PCI DSS standards.

h. In consultation with Information Security/UIT, suspending or revoking a merchant account of any merchant determined to be both non-compliant and unremediated.

14. PCI DSS Program Responsibilities of Information Security/UIT include the following activities:

a. Overseeing and supporting the safeguarding of University payment card-related information, computing systems, infrastructure and networks.

b. Establishing and maintaining security standards for handling and transmitting payment card data.

c. Providing guidelines and instruction to merchants on PCI compliance and completion of SAQs.

d. Advising merchants and prospective merchants on best practices and permissible arrangements for payment card acceptance.

e. Reviewing and approving proposed systems that incorporate processing and handling payment card transactions.

f. Assessing merchant compliance to the University and PCI DSS standards.

g. Monitoring University systems and networks for non-compliant operation.

h. Advising Treasury/Finance of any merchants that are both non-compliant and unremediated

15. A merchant is a University department, office or unit that:

a) Directly accepts card payments to its merchant account over University systems, on University premises or at University events, including mobile operations.

b) Indirectly accepts card payments, contractually, through a third-party service provider, for services involving payment card acceptance and/or processing, including:

i. Payment applications that are incorporated in software or on-line accessed services;
ii. Systems and services that accept point of sale or eCommerce card payments on behalf of a University merchant and that (1) later remit proceeds to the University by cheque or electronic funds transfer or (2) interface with the University’s acquirer; and
iii. Hosting services that process card transactions for the University or its contracted service provider.

16. Steps to be taken by merchants and prospective merchants when making new or altered card acceptance arrangements are laid out below.

a. As part of planning for a new merchant arrangement or alteration to an existing arrangement, merchants and prospective merchants are responsible for arranging a required review process with Treasury and UIT.

b. Sufficient time should be allowed for PCI DSS review in addition to the merchant application process. A minimum of 8 weeks advance notice is recommended prior to a planned implementation date.

c. A merchant account application and documented description shall be submitted to the Treasurer in advance of launching new arrangements or making changes to existing arrangements that involve acceptance of payment cards.

d. Approval by Treasurer is required for new or altered merchant accounts and associated financial arrangements.

e. Approval by UIT Information Security Officer is required for new or altered connectivity to and use of University servers, infrastructure and networks.

f. New merchant arrangements and/or revised existing arrangements that involve a service provider contract are to be managed in conjunction with Procurement Services.

Examples of services that normally are accessed only with prior written contractual agreement between supplier and buyer are:

• licensing or use of software with incorporated payment application
• on-line or outsourced systems or services that include payment card acceptance

g. For all new vendor arrangements and vendor contract renewals, including but not constrained to the examples above, the (prospective) merchant is expected to engage with Procurement Services in collaboration with Treasury and UIT to ensure that PCI DSS specific language is properly incorporated into the process and documentation.

h. PCI DSS language, specific to York University, shall be incorporated into the documented vendor terms for all of the following:

Competitive bids and RFPs
New contracts and agreements
Renewed contracts and agreements.

17. Achieving PCI DSS compliance may require that the merchant undertake an upgrade or make arrangements for a completely new system. These may include costs which shall be covered as follows:

a. Each merchant is required to accept and cover their cost of acquiring and operating a PCI DSS compliant card acceptance arrangement.

b. Each merchant shall accept and cover the expenses incurred for remediation of non-compliant arrangements.

18. Each merchant is responsible for ongoing adherence to the current version of PCI DSS and York University’s Payment Card Data Security Guideline and Procedures.

19. Annual PCI DSS training is mandatory for the merchant site primary manager, the servicing information technology director or UIT manager, and front line supervisor and sales staff that deal directly with customers at the merchant site.

20. Each merchant shall annually complete the SAQ form. The SAQ type depends on the merchant arrangement and shall be confirmed with UIT.

21. Each merchant shall comply and cooperate with any required external PCI DSS security assessment as performed by York staff or the University’s QSA.

22. A merchant shall immediately report a security incident, breach or fraud attempt that involved payment cardholder data or systems to UIT Information Security and Treasury officers.


23. The primary account number (PAN) is the primary factor defining the applicability of PCI DSS requirements. PCI DSS is applicable when PAN data is stored, processed or transmitted. If the PAN is not stored, processed or transmitted by a York University merchant or service provider then PCI DSS requirements do not apply.

24. All cardholder data (CHD) is in scope for PCI DSS compliance validation if it is stored, processed or transmitted when the PAN is present in the cardholder data environment. CHD elements are formally defined to include the:

• primary account number (PAN)
• cardholder name
• expiration date
• service code

25. Sensitive authentication data should never be stored; its elements are:

• full magnetic stripe data or equivalent on a chip,
• security code (CAV2, CVC2, CVV2, or CID)
• PINs / PIN blocks

26. CHD and sensitive authentication data must never be communicated by unsecure email.

27. Responsibilities and activities of the PCI DSS Steering Committee and its delegates (the PCI Team) are to:

a. Maintain, update and communicate the Payment Card Data Security Guideline and Procedures.

b. Conduct annual PCI DSS training.

c. Advise on prudent actions and best practices for achieving and maintaining PCI DSS compliance.

d. Arrange for required assessments and validation by a Qualified Security Adviser (QSA) and an Accredited Scanning Vendor (ASV).

e. Gather, review and approve SAQs as prepared in tandem with merchants.

f. Prepare, validate and submit annual AOC to acquirer(s).

28. Merchants are responsible for adhering to the following requirements with respect to their card acceptance arrangements:

a. Version: Handling of cardholder data (CHD) and all related processes are to be conducted in compliance with the current version of PCI DSS.

b. Authorization: All card acceptance arrangements shall be disclosed to the Treasurer and/or UIT Director for validation and authorization.

c. No hosting: University servers shall not be used for hosting.

d. Encryption: Networks may only be used for protected transacting, transmitting or storing of encrypted, masked or redacted CHD.

e. Access persons: Only authorized staffmembers shall be permitted to have access to CHD. Access shall be strictly controlled and tracked by a management-level access person. Each merchant’s controls are subject to periodic audit.

f. Transmission: All CHD received in communications to merchants for the purpose of handling card payments must be safeguarded and encrypted and/or masked during processing then redacted prior to storing.

g. Storage: University servers, computer hard drives, and paper archives are not to be used for storing unprotected CHD in any form (electronic, physical, or otherwise). CHD should not be archived and should be destroyed in a timely and secure manner.

h. Devices: Card acceptance devices and pinpads are to be protected at all times from theft or tampering. Device inventory and controls must be maintained up to date at all times.

29. Prior to a department, office or unit entering into an arrangement with a service provider that involves acceptance of payment cards, the service provider must initially, and annually thereafter, provide Attestation of Compliance and security certification as proof that:

a. The service provider is PCI DSS compliant as validated by a QSA.

b. The service provider software application and payment application is certified compliant with the Payment Application Data Security Standard (PA-DSS) for developers.

c. The service provider hardware, equipment and devices are certified compliant with the PIN Transaction Security (PTS) standards for manufacturers.

d. The service provider devices are EMV (chip and PIN) enabled, to protect from fraudulent card attempts and attacks.

30. Service provider and outsourcing arrangements are subject to validation to prove the University’s systems, infrastructure and networks are not being used for hosting, processing, transacting or transmitting cardholder data.

31. The University will not be responsible for any service provider security breaches and will be indemnified by the service provider for all costs and damages associated with security breaches caused as a result of negligence on the part of the service provider.


32. The procedure for addressing matters of non-compliance with PCI DSS at single merchant sites is as follows.

a. An identification of the reason for non-compliance will be assessed by UIT and Treasury or an external validator (QSA).

b. Notification by the Steering Committee that remediation is required will be communicated to the merchant.

c. The merchant will produce and communicate its plan including a series of steps to attain remediation to the Steering Committee for approval.

d. A mutually-agreed upon and reasonable timeline for remediation will be established by the merchant with UIT and Treasury.

e. Post remediation, an SAQ shall be completed by the merchant and subject to review will be approved for documenting that remediation has occurred.

33. Should remediation not be attained as per the timeline above, the Steering Committee will consider further actions and will issue a notification to outline the actions that must be taken by the merchant.

34. A non-compliant merchant may face increased costs due to fines levied by the payment card brands.

35. A persistently non-compliant merchant is subject to suspension or termination of card acceptance arrangements.

36. Active merchant status may be restored only when the unit has completed all applicable steps associated with these procedures.


37. Payment card breaches or security incidents include but are not limited to:

a. Malicious attempts to access a payment system, electronic or paper payment record;

b. Unauthorized attempt(s) to compromise cardholder data

c. Unauthorized access to CHD information by employees (outside of employees job duties), even if accidental;

d. Lost, stolen or tampered device, including pinpads and terminals;

e. Unauthorized changes to hardware or software configuration;

f. Unplanned disruption or denial of service;

g. Any suspected or actual adverse event that impacts security of CHD or related systems.

38. The merchant site procedure to be followed by merchants upon discovery of a CHD Breach or Security Incident follows.

a. Discontinue card processing and disconnect related workstations and POS systems from the network;

b. Avoid shutting down systems unless this action is the only way to prevent further compromise due to system connectivity to the network;

c. Immediately report any suspected or known breach or security incident to UIT Information Security and Treasury, regardless of time of day, by telephone and email:

UIT Information Security:

Client Services (normal business hours) (416) 736-5800

Security Control Centre (after hours) (416) 650-8000


Treasury: Email: (416) 736-5539

UIT Information Security with Treasury shall assess the reported incident and coordinate actions and response in adherence to University policy and protocols.

d. The merchant must NOT resume normal business operations until notified by UIT or Treasury that it is safe to do so.

39. The procedures to be followed by UIT and Treasury upon discovery of a CHD breach or security incident are as follows:

a. Upon security incident notification, UIT and Treasury will assess a situation and immediately begin notifying necessary parties.

b. UIT and Treasury will determine whether circumstances surrounding a breach or security incident require notification of law enforcement.

c. If a security incident is confirmed, UIT and Treasury will coordinate the response in accordance with established University security and privacy incident guidelines and procedures, as well as the following PCI DSS requirements:

• Immediately contain the exposure of the security incident.
• Immediately notify the necessary institutional parties.
• Prepare the Incident Response Report and file with the merchant bank (acquirer) within 3 business days.
• Prepare a list of compromised accounts and file with the merchant bank (acquirer) within 10 business days.

40. If the security incident is contained to a single merchant, UIT and Treasury will assist that merchant with any required PCI DSS post-incident reporting.

41. The merchant if found to be responsible for a compromise may have its payment card handling privileges immediately revoked.

42. Costs associated with a security incident will be charged to the merchant, if found to be negligent or in violation of the University’s PCI DSS Guideline or Procedures at the time of the security incident.

43. UIT and Treasury shall include Breach and Incident Response Procedures in the annual training to ensure all merchants understand these responsibilities.


44. These Procedures will be reviewed by the Oversight Committee and revised or confirmed annually.