PCI DSS v4.0: Incident Response for a Lost or Stolen Payment Card Device

Article PCI DSS

Credit card device

Requirement 12.10 of the PCI DSS version 4.0 is all about ensuring organizations can respond immediately to suspected and confirmed security incidents that could impact the cardholder data environment (CDE). Organizations must have an up-to-date incident response plan (IRP) that includes all elements outlined in Requirement 12.10.1.

Requirement 12.10.2 also states that at least once every 12 months, the IRP is reviewed and updated as needed and tested. The test of the incident response plan can include simulated incidents in the form of a tabletop exercise with relevant stakeholders, or this requirement can be met if a real-life incident occurred, and the plan was utilized.

Does your organization include payment card merchants in regular incident response exercises?

Walking through various scenarios with selected merchant staff can ensure all team members understand how and when to report a suspected incident, can locate the incident response plan, and know their individual roles and responsibilities during an event. By testing the plan and identifying and remediating any gaps in the process, when an actual compromise occurs the team will be ready to respond quickly and effectively and limit the potential damage.

One potential incident that can occur within your merchant areas is if a payment card device is lost or stolen. Do your merchants know what to do if they cannot locate an issued payment card terminal?

Below are suggested steps to follow if your organization learns of a missing device:

  • Deactivate the Terminal ID (TID). If this device came from your acquiring bank, you should be able to work directly with your merchant services account representative. If the device is part of a validated P2PE solution, you would most likely manage the terminal activation/deactivation through the P2PE solution provider. This will prevent the missing terminal from being able to run transactions that may not be authorized, especially refunds.
  • Report the loss or possible theft immediately. Notify the appropriate teams on campus (PCI Team, Merchant Services, Information Technology/Security, Campus Security/law enforcement, etc.). This task may be completed by filing or submitting a missing device ticket or directly contacting the teams responsible for managing/distributing payment card equipment.
  • Initiate your PCI Incident Response process.
  • Follow procedures related to device tampering/substitution. While you might not necessarily know that something malicious has taken place, it is possible, so following your IRP procedures for terminal tampering makes sense. This may include reviewing the most recent inspection logs for the missing terminal to determine when the device was last inspected, identifying who the last person was with authorized access to the device, reviewing any physical security restrictions that may have been breached (i.e., office locks, safes, device tethers, etc.), and reviewing security camera footage if available.
  • Notify your acquiring bank and follow any additional requirements/guidance.
  • Monitor batch settlement reports and activities, and verify all transactions align with expected activities. Any refunds should get careful scrutiny.
  • If the missing terminal is located and just appears to have been misplaced (not stolen), you should still always examine it carefully to ensure that it has not been tampered with before you reactivate or return the device to service.

Bringing different stakeholders across your organization together to practice a potential breach or compromise will ensure that merchants understand the importance of protecting cardholder data, know how to effectively respond (what to do vs. what not to do), and will also help build relationships across merchants/departments and improve communications ongoing.

Other possible scenarios that might be of value to review as part of a PCI-focused tabletop exercise include:

  • An employee discovers a skimming device attached to a card reader during a routine inspection/check.
  • Your bank reported that one of your merchant locations was a common Point of Purchase in a recent credit card breach.
  • An employee sharing they cannot complete a credit card transaction at any of the registers because the card readers are not communicating.
  • A third-party vendor in use for student payments announced that accounts and passwords have been compromised within their organization. (How does responding to an incident impacting a vendor or third-party service provider look different than an internal incident?)
  • A merchant noticed an increased number of transactions occurring through one of their payment sites, with the majority of the transactions for only $.05.
  • It appears the site is being used in a carding attack, in which a cybercriminal is testing stolen account numbers to determine valid cards.

If you are interested in having your dedicated QSA team help facilitate a PCI-focused exercise with your PCI team and selected merchants, please reach out to your CampusGuard team to discuss this process in more detail.


About the Author
Katie Johnson

Katie Johnson


Manager, Operations Support

As the manager of Operations Support, Katie leads the team responsible for supporting and delivering CampusGuard services including online training, vulnerability scanning, and the CampusGuard Central® portal. With over 15 years of experience in information security awareness training, Katie is also the Product Lead for CampusGuard’s online training services. As a Senior Customer Relationship Manager for a limited number of customers, Katie assists organizations with their information security and compliance programs and is responsible for coordinating the various teams involved.