Please note that Carleton’s Corporate Cards (e.g. PCard, eCard and Travel Card) are not in scope of this Plan. Contact Carleton’s Procurement Services if you suspect Corporate Card Fraud.
Below is the process to be followed by merchants for responding to security incidents involving the unauthorized disclosure or modification of cardholder data (as defined by the Payment Card Industry (PCI) Data Security Standard). A security incident refers to any malicious attempt, either successful or unsuccessful, by an unauthorized party to negatively impact the confidentiality, integrity or availability of cardholder data is within scope of this incident response plan.
Merchant Leads are expected to:
- Be familiar with the university’s Cardholder Data Security Incident Response Plan.
- Integrate the university’s Cardholder Data Security Incident Response Plan into their departmental procedures.
- Appoint from among the merchant team a designated incident response lead and a deputy.
- Ensure that departmental staff who process credit card payments as part of their job are aware of the Cardholder Data Security Incident Response Plan, are able to recognize signs of a potential breach, and know who to contact if an incident is suspected.
Recognizing signs of a potential breach. Follow Steps 1-7 if you observe any of the following:
Merchants:
- A secured, locked cabinet with payment card data has been broken into or looks damaged;
- Lost paper forms containing payment card data;
- Suspicious behaviour around devices;
- A skimming device or unusual attachment on a POS device;
- A tamper warning message or broken tamper-proof seal on a POS device;
- Serial numbers on the PIN pad device not matching those on record, indicating a switch;
- A missing POS device, indicating theft or loss;
- Unfamiliar equipment surrounding your PCI terminal or POS device;
- QR code tampering;
- Hidden camera recording entry of authentication credentials;
- Multiple refunds going to the same card;
- Multiple small transactions in quick succession through an online store or e-commerce account;
- Customer reports compromised credit/ debit card;
- Third-party partner reports a breach;
- Loss of access to services provided by a third-party partner;
- Unknown or suspicious activity on the merchant account(s);
- Unknown or suspicious activity on the public-facing Application/Payment Page;
- Gateway and application’s daily financial reports don’t reconcile;
- Suspected malware on the virtual terminal device.
Information Technology Services (ITS):
- A vulnerability appears in scans of the Point of Sale VLANs;
- Possible issue found on the PCI network and in PCI Applications;
- Unauthorized access to a system or network detected;
- Suspected malware;
- System crashes due to unidentified causes.
Procedures to be Followed in the Event of a Suspected or Confirmed Security Incident
PDF VERSIONS by Payment Stream: Please download and post at your Merchant Location
Step 1 | Merchant | Contain or limit the exposure:
|
Step 2 | Merchant | Report the suspected breach or incident:
|
Step 3 | Merchant | Document any actions taken and await instructions:
Document any actions taken prior to the arrival/engagement of representatives from ITS or Business Operations, including dates, times, and individuals involved. Do not restart processing transactions until cleared to do so by ITS Security or Business Operations. |
Step 4 | ITS Security | Validate and assess the incident:
ITS Security will investigate the incident in accordance with ITS Incident Handling Procedures. As part of the investigation, ITS Security and Business Operations will:
|
Step 5 | Business Operations | If breach suspected and/or confirmed, notify the Acquirer immediately:
|
Step 6 | ITS Security | Implement security controls (either physical, procedural, or technical):
Once the root cause of the incident has been identified, implement security controls (either physical, procedural, or technical) to prevent future incidents. |
Step 7 | Governance, Risk and Compliance (GRC):
Business Operations, ITS Security, Privacy |
Incident Closure, Decision to Restart Operations:
|