Card-data breach response: preserve evidence and call the acquirer before rebuilding everything

When a merchant suspects payment-card data has been compromised, the first instinct can be to wipe the server or replace the terminal immediately. That can destroy evidence. PCI guidance emphasises a prepared incident-response plan, rapid containment and coordination with the acquirer, card brands and approved forensic investigators where required.

Maintain a tested incident-response plan before a breach occurs

PCI SSC guidance says PCI DSS Requirement 12.10 requires an incident-response plan and recommends testing it. The plan should identify internal roles, acquirer contacts, technical response and evidence preservation.

Keep contact details offline as well as in the compromised environment. An attacker can disable access to the same systems where the response plan is stored.

Stop further exposure without destroying evidence

Isolate affected systems or payment channels where practical and work with security specialists to preserve logs, memory or device evidence.

Do not immediately rebuild every system unless advisers confirm that is appropriate. Investigators can need the original state to determine what happened and how long data was exposed.

Contact the acquirer or payment provider promptly

The acquirer coordinates payment-brand requirements and can advise whether card acceptance should continue or be restricted. Use known official contacts.

Provide facts rather than speculation: discovery time, suspected systems, merchant IDs and actions already taken.

A PCI Forensic Investigator may be required

PCI SSC says payment brands can require an independent forensic investigation by a listed PCI Forensic Investigator after suspected cardholder-data compromise.

Cooperate with evidence requests and preserve independence. The PFI's role is to determine technical facts and compliance conditions, not to protect the merchant from uncomfortable findings.

Assess wider personal-data notification obligations

A card breach can also involve personal data, triggering UK GDPR assessment and possible notification duties. Payment-brand reporting and data-protection reporting are separate obligations.

Involve legal and data-protection specialists early so the company meets each relevant timetable and communicates accurately.

Fix the root cause before returning to normal

Remove malicious code or compromised devices, rotate credentials, patch vulnerabilities and validate the environment under the required process.

Then update the incident plan with lessons learned. A restored checkout that still contains the original weakness is not recovery.

Worked example: a merchant discovers malicious JavaScript on checkout that may have been active for two weeks. The first task is not to delete the server history and announce that the issue is fixed. The team should isolate the affected page, preserve logs and deployment evidence, notify the acquirer and security advisers, and determine which transactions could have been exposed.

Prepare customer communication only after facts are sufficiently clear and legal obligations are assessed. Premature statements can be inaccurate, while unexplained silence can damage trust. Coordinate payment-network, ICO, insurer and customer communications from one verified incident timeline.

After recovery, compare the breach with PCI scope and provider responsibilities. If a third-party script caused the incident, the merchant should review vendor governance and change controls rather than simply replacing the script. The response is complete only when the organisational weakness is addressed.

Keep cyber-insurance notification requirements in the same incident checklist. Some policies require rapid notification or insurer-approved forensic providers. Missing the insurer's process while following only PCI steps can reduce coverage for investigation and recovery costs.

Run a tabletop exercise at least annually. Simulate a checkout breach or stolen terminal, require staff to find acquirer and ICO contacts, and test who can take the payment channel offline. Exercises reveal missing phone numbers and unclear authority long before a real incident turns those gaps into delay.

Assign one decision-maker for whether card acceptance is paused. A technical team can identify suspicious activity but may not understand the revenue impact, while commercial teams may be reluctant to shut checkout. The incident plan should define who has authority to stop payments when customer data is at risk.

Keep a clean recovery environment. Restoring from backups is useful only if administrators know the backup predates the compromise and does not contain the same vulnerable code or stolen credentials. Validate before reconnecting payment systems to production.

Document business-continuity alternatives for the period when card acceptance is restricted. A merchant may switch temporarily to bank transfer, payment links on a clean environment or another approved terminal route. The fallback should be pre-approved so staff do not improvise by collecting card numbers insecurely.

After the incident closes, quantify direct and indirect cost: forensic work, chargebacks, replacement terminals, downtime and customer support. That evidence helps management justify security improvements and insurance decisions rather than treating the breach as a one-off IT event.

Keep executive decisions and technical findings in one incident log. Directors may need to decide on customer communication, downtime and public disclosure while investigators work, so a single verified chronology helps prevent contradictory actions.