A suspected payment card breach isn’t a normal IT outage. You can’t just simply restore a backup, rebuild a server and move on. You have an obligation to your stakeholders to investigate the breach and determine how it occurred.

The decisions you make when you first detect a breach can determine whether investigators identify the root cause or whether critical evidence disappears forever.

This is why working with a Payment Forensic Investigator (PFI) is essential.

A PFI is specially qualified to investigate incidents involving payment card data. Their role is to determine what happened, how it happened, which systems were affected, whether cardholder data was compromised, and what must be reported to acquirers and payment brands.

Stratica brings a unique perspective to this work. We are Australia’s only firm accredited as both a Qualified Security Assessor (QSA) and a PFI. As QSAs, we assess whether PCI DSS compliant security controls exist. Through our forensic work, we understand how systems fail in real incidents: and how attackers exploit gaps that may look minor on paper.

So, what actually happens during the first 72 hours?

Hour 0-4: Contain the threat without destroying evidence

The first priority is to stop further exposure.

That does not necessarily mean shutting everything down. In fact, powering off a compromised system can destroy volatile evidence, including active processes, malware in memory and network connections.

Think of a suspected breach scene like a physical crime scene. You would not clean the room before collecting fingerprints. It’s the same for digital evidence.

Your incident response team should:

  • Activate the organisation’s incident response plan.
  • Identify the suspected systems, applications, accounts or payment pages involved.
  • Isolate affected systems from the network where possible.
  • Avoid rebooting or powering off compromised systems unless directed by the PFI.
  • Preserve firewall, web server, database, endpoint, application and authentication logs.
  • Record when the incident was discovered, who discovered it and what actions have already been taken.
  • Restrict unnecessary access to affected systems.
  • Engage legal, executive, technical and communications representatives as appropriate.

Do not log into, patch, clean or reconfigure a suspected system before obtaining forensic advice. By overwriting timestamps and removing malware, well-intentioned remediation can make it harder to establish the attack timeline and even destroy vital evidence of how the breach occurred.

Containment must also be practical. If card data is actively being exfiltrated, isolating a payment server will be urgent. A PFI will help balance the need to stop the attack with the need to preserve evidence.

This is why a tested PCI DSS incident response plan is crucial. Under PCI DSS Requirement 12.10, your plan must support an immediate, coordinated response that’s been tested under incident-like conditions.

Hour 4-24: Notify the right parties and engage a PFI

Once you suspect a payment card compromise has occurred, your notification obligations begin.

Your first call should generally be to your acquirer, merchant bank or payment processor. Report it straight away – don’t run an internal investigation while you decide whether the event is serious enough to report.

Acquirers and payment brands have their own rules, thresholds and deadlines. In many cases, the acquirer coordinates communications with the relevant card brands and may require you to engage an approved PFI.

You should be prepared to provide:

  • A short description of the suspected incident.
  • The date and time it was detected.
  • Systems, locations or payment channels potentially affected.
  • Known indicators of compromise.
  • Any containment actions already taken.
  • Contact details for your incident lead and executive sponsor.
  • The name and contact details of the PFI once engaged.

Notification requirements vary according to the card brand, acquirer, jurisdiction and nature of the incident. Your organisation shouldn’t rely on a generic breach checklist. Your incident response plan should contain current acquirer and payment brand contacts, escalation paths and brand-specific procedures.

PCI Security Standards Council guidance on responding to a cardholder data breach recommends preparing these arrangements before an incident occurs.

What does the PFI do at this stage?

The PFI establishes the investigation process, confirms what evidence is available and identifies the initial investigative scope.

That scope may be broader than your existing Cardholder Data Environment (CDE).

For example, an attacker may have entered through a compromised administrator account, remote access tool, web application, service provider or development environment before reaching payment systems. Therefore, the PFI might need to examine:

  • Payment applications and databases.
  • Point-of-sale systems.
  • E-commerce platforms and payment pages.
  • Web servers and content management systems.
  • Active Directory and identity systems.
  • Remote access infrastructure.
  • Cloud environments.
  • Third-party hosting or service provider systems.
  • Network devices and security monitoring platforms.

The PFI, not the affected organisation, determines the full scope required to investigate the incident.

Hour 24-48: Acquire and analyse the evidence

Forensic acquisition is the controlled collection of digital evidence for examination.

Depending on the incident, this could include:

  • Full forensic disk images.
  • Memory captures.
  • Endpoint detection and response data.
  • Operating system and application logs.
  • Firewall, VPN and proxy logs.
  • Web access and database activity logs.
  • Malware samples.
  • File metadata and timestamps.
  • Payment application and transaction records.
  • Source code and web page versions.
  • Access-control and authentication records.

The PFI will typically use forensic tools and documented procedures to preserve the integrity of this evidence. Chain of custody is important because the evidence may need to support card brand reporting, regulatory enquiries, legal proceedings, or law enforcement activity.

During analysis, the investigator begins reconstructing the incident as a timeline:

  1. Initial access: How did the attacker enter?
  2. Persistence: How did they maintain access?
  3. Privilege escalation: Did they obtain higher-level permissions?
  4. Lateral movement: Which systems did they reach?
  5. Data access: Could they access, collect or view cardholder data?
  6. Exfiltration: Was data transferred outside the environment?
  7. Detection and containment: When was the activity stopped?

Attackers may delete tools, use legitimate administrative utilities or compromise a third-party component. The PFI compares multiple evidence sources to distinguish normal business activity from attacker behaviour.

Hour 48-72: Establish scope, exposure and root cause

By this stage, the investigation is developing a clearer picture of the incident.

One critical output of the PFI investigation is the at-risk timeframe. This is the period during which cardholder data was vulnerable. It is not necessarily the entire period that data existed in your environment.

For example, if evidence shows that an attacker gained access on 14 April at 6:30 pm and the affected system was isolated on 17 April at 7:15 am, the at-risk timeframe is that period of approximately 60 hours.

The PCI SSC definition of at-risk timeframe explains that the timeframe concerns when data was exposed or accessible to an unauthorised entity.

The PFI will work to determine:

  • Which payment channels were affected.
  • Which systems stored, processed or transmitted cardholder data.
  • Whether data was accessed, acquired, or exfiltrated.
  • Which card numbers may be at risk.
  • The earliest and latest evidence of compromise.
  • Whether sensitive authentication data was involved.
  • Whether third parties contributed to the incident.
  • Whether the attacker remains present.
  • Whether containment has been effective.

Root cause: what failed, and why?

Root cause analysis goes beyond identifying the immediate vulnerability.

A breached organisation may initially conclude that “malware caused the incident.” That is a symptom, not a root cause.

The deeper cause might be:

  • An unpatched public-facing application.
  • Excessive administrative privileges.
  • Weak remote access controls.
  • Inadequate network segmentation.
  • Missing multi-factor authentication.
  • Poor third-party access management.
  • Insufficient log retention.
  • Undetected changes to a payment page.
  • An unauthorised or compromised JavaScript dependency.

This is where Stratica’s dual QSA and PFI capability creates practical value. Our forensic experience informs the way we assess preventive controls. We know what suspicious activity looks like in real environments, not just what a policy says should happen.

Payment-page attacks and PCI DSS Requirements 6.4.3 and 11.6.1

Not every payment breach begins with a database intrusion.

In e-commerce environments, attackers increasingly target the payment page itself. A Magecart-style attack may inject malicious JavaScript that captures payment details as a customer enters them into a browser.

In this case, two PCI DSS v4.0 requirements are especially relevant:

Requirement 6.4.3: Payment-page script management

This control requires organisations to manage scripts running in the consumer’s browser by:

  • Maintaining an inventory of scripts.
  • Confirming each script is authorised.
  • Establishing a business or technical justification for each script.
  • Protecting scripts from unauthorised changes.

Requirement 11.6.1: Payment-page change and tamper detection

This control focuses on detecting unauthorised changes to payment pages, including additions, modifications and deletions. Alerts must be generated and investigated according to defined procedures.

These controls can help determine how a breach happened. During a PFI investigation, evidence may show that a new script was added, an existing script was altered or a third-party tag was compromised.

They are also preventive measures. Effective script inventories, authorisation processes and change detection can reduce the time between a malicious modification and its detection.

Read about these requirements in more detail in our guide to protecting payment pages against e-skimming attacks.

Communicating with acquirers and payment brands

A PFI investigation doesn’t happen in isolation.

The merchant, acquirer, payment brands, PFI and relevant service providers may participate in status calls and reporting activities. The acquirer may request regular updates on:

  • Current containment status.
  • The suspected source and cause.
  • Systems under investigation.
  • The at-risk timeframe.
  • Potentially compromised payment accounts.
  • Remediation progress.
  • Any changes to the investigation scope.

The PFI prepares formal reports using the required reporting templates and provides findings to the appropriate stakeholders. In most cases, expect a preliminary report within a week and the final, full incident report within a month. This can be a period of intense activity – which is exactly why a breach is best avoided in the first place with the appropriate level of security controls.

Don’t wait for the final report before acting on urgent containment recommendations. A PFI may identify actions that need to be implemented immediately to prevent continued exposure. Final reporting follows the investigation, but risk reduction starts as soon as the problem is understood.

Also remember that a PFI investigation is not a complete PCI DSS assessment. It may identify control deficiencies observed during the investigation, but those findings do not replace a formal QSA assessment.

Can I use my PCI DSS QSA as my PFI?

Yes, but there are independence rules to navigate. If your existing QSA also acts as your PFI, they can’t continue as your QSA afterward, since they’d effectively be assessing their own prior work. So, we recommend you engage a different firm as your PFI instead. If you’d like to change QSAs after the incident, the PFI firm can go on to become your QSA once the investigation concludes.

How to respond to a cardholder data breach: the first 72-hour checklist

If you suspect a payment card breach:

  • Activate your incident response plan.
  • Contact your acquirer or payment processor promptly.
  • Promptly engage an approved PFI when required. Consider engaging a retained PFI. You’ll not only ensure there’s someone ready to go in case of an emergency. A retained PFI can also provide threat intelligence and control reviews that help ensure no breach happens in the first place.
  • Isolate affected systems without destroying evidence.
  • Don’t reboot, wipe or modify systems without forensic direction.
  • Preserve logs, memory, disk images and relevant records.
  • Document every action, decision and timestamp.
  • Allow the PFI to determine the investigation scope.
  • Begin legal, regulatory and contractual notification analysis. If your organisation is covered by the OAIC’s Notifiable Data Breach Scheme, ensure you report it as soon as practicable.
  • Prepare for regular, continuing communication with the acquirer and card brands.

The final two steps can be coordinated by your PFI, who’ll understand the process and how it applies to your organisation.

Respond well: and prevent the next breach attempt

A breach investigation is an opportunity to understand exactly where your security controls went wrong, what data was exposed and what needs to change to ensure it doesn’t happen again.

Stratica helps businesses respond to card data incidents through our PCI forensic investigation services. Following the breach, our QSA services can validate the recommended remediation and strengthen your payment security controls.

Our dual certification as a QSA and PFI is unique. It means that, whether we’re engaged as a QSA or PFI, you get the benefit of both: controls that satisfy PCI DSS requirements – that work as intended when an attacker is actively trying to defeat them.

If the unthinkable happens, preparation and clear escalation paths and can save valuable time when the first 72 hours begin. If you want to test your readiness before an incident occurs, contact us for a security review. We’ll ensure your security controls provide the strongest possible defence against breach attempts.

Before the first 72 hours: put a PFI retainer in place

The simplest way to ensure you’re prepared to respond to a data breach is also the most useful: a PFI retainer. It removes the scramble to find an accredited investigator, agree scope and negotiate commercial terms while cardholder data is still exposed.

Stratica offers two options.

Option 1: PFI retainer agreement, at no cost

Our no-cost retained PFI service gives you access to a PFI, at a pre-agreed rate and service agreement. You won’t have to pay if you don’t need us.

What it gives you:

  • A signed agreement with an accredited PFI, ready to activate the moment you need it.
  • Fees, services and response times agreed in advance.
  • A commitment that we will respond to you ahead of any request from an organisation that does not hold a retainer agreement with us.

Option 2: Annual PFI retainer with services

if you’d like your cyber incident readiness tested and verified, we offer an annual PFI retainer that includes an allocation of three to five days of services each year.

You can use those days for:

  • Observing and reviewing your incident response test.
  • Testing your preparedness against a realistic card data compromise scenario.
  • Reviewing your logging, evidence retention and forensic readiness.
  • Reviewing your acquirer and payment brand escalation contacts and procedures.

These are the PFI engagements we prefer, because it means we can work with you to ensure you never actually need us in a breach scenario.

We retain our independence throughout. A retainer doesn’t change our obligations as your PFI, nor is it substitute for a QSA assessment.

Talk to us about a PFI retainer.