Ecommerce Data Breach Response Plan: Complete Guide
Every ecommerce store should have a data breach response plan. Not because a data breach ecommerce stores face is inevitable, but because the quality of your store breach response - how quickly you contain it, how accurately you assess the damage, how clearly you communicate with customers and regulators - has a direct bearing on how much damage a breach actually causes.
The difference between a contained, well-managed incident and an extended, chaotic one is not usually the technical sophistication of the attack. It is whether the people who need to respond know what to do and can act immediately. A team that has a written response plan and has talked through it in advance compresses the critical early hours of a breach response dramatically. A team working out the process from scratch under pressure makes worse decisions, takes longer, and causes more secondary damage.
This guide is the playbook. Read it, adapt it to your store's specific setup, share it with the people who would be involved in a real incident, and keep it somewhere you can find when the adrenaline is running.
See it in action
Want to automate this for your store?
VortexIQ's AI agents can audit, fix, and monitor your ecommerce store automatically.
Prevention, monitoring, and fraud detection are covered alongside this breach response guide in the Ecommerce Security & Compliance Complete Guide.
In This Guide
Why You Need a Plan Before You Need It
The average time from a data breach to discovery is much shorter in ecommerce than in enterprise (where it can take months), because fraud generates customer complaints relatively quickly. But "shorter" in ecommerce still often means 24-72 hours of a breach being active before anyone notices - and that window is when most of the damage occurs.
More importantly: the actions taken in the first hour after a breach is confirmed are the ones that determine the outcome. Preserve evidence or destroy it while scrambling to fix things. Contain the breach immediately or let it continue while you work out who to call. Notify your data protection authority within 72 hours, or miss the GDPR deadline and create a compliance failure on top of the breach itself.
These decisions require a clear head and a prepared process. Neither is reliably available in the moment of discovering that your customer database has been compromised. The plan exists to substitute process for improvisation when improvisation is most likely to go wrong.
The First Hour: Confirm and Contain
The first thing to do when you suspect a breach is to confirm it is real.
Confirming the Breach
Not every unusual event is a data breach. Suspicious login activity might be a customer who forgot their password and tried multiple times from a new device. An unusual export might be a team member who ran a report they do not normally run. Before triggering your full breach response, take the time to verify.
Signs that indicate an actual breach rather than a false alarm:
- Customer reports of fraudulent charges after shopping at your store (indicates card data exposure)
- Evidence in access logs of data being exported or accessed by an account that should not have that access
- A third-party security notification from your platform, payment processor, or a security researcher
- Unexplained changes to admin settings, payment destinations, or admin account list
- Evidence of malicious code in your checkout page or theme files
- Your store's data appearing on dark web markets or in security research disclosures
If the evidence points to a real breach, activate your response immediately.
Contain First, Investigate Second
The instinct in a breach situation is often to immediately investigate and fix what went wrong. Resist this instinct in the first minutes. Containment - stopping the ongoing damage - comes before root cause analysis.
Containment actions depend on the breach type:
Compromised admin account: Revoke all active sessions for the affected account, change the password, disable the account if necessary, review any actions taken during the compromised session.
Active data exfiltration: If a process or integration is actively pulling data, disable the integration or API key. If a malicious script on your checkout page is actively harvesting card data, take the affected page offline immediately.
Active intrusion via application vulnerability: Take the affected system offline if possible. If it is your entire store, the decision is harder - weigh the revenue cost of going offline against the ongoing data exposure from remaining live.
Ransomware or data destruction: Isolate affected systems from the network immediately. Do not pay the ransom until you have assessed your backup position (see Section 8).
Preserve Evidence Before You Change Anything
This is the most commonly violated principle in breach response. Under pressure to fix things, teams modify files, delete logs, restore systems, and inadvertently destroy the forensic evidence needed to understand what happened, for how long, and what was accessed.
Before making any changes:
- Take screenshots of the relevant admin interface, access logs, and anything unusual you have observed
- Export current access logs from your platform, hosting environment, and relevant third-party services
- Note the current state of all admin accounts (who exists, last login times, recent activity)
- Screenshot any evidence of the breach itself (malicious code, unusual exports, unauthorised account activity)
This evidence is needed for your own investigation, for regulatory disclosure, and potentially for any legal proceedings.
The Breach Response Playbook
Step 1: Activate Your Response Team
Your breach response team should be defined before an incident occurs. For most ecommerce stores, this is a small group:
- Technical lead: The person who understands your platform, integrations, and hosting well enough to investigate and remediate
- Legal/compliance point of contact: In-house or external - the person who can advise on notification obligations and liability
- Communications lead: The person who drafts customer and public communications
- Senior decision-maker: The business owner or most senior person available - some decisions (taking the store offline, public disclosure timing) require senior authority
Establish out-of-band contact methods for this team. If your communication platform itself is potentially compromised, or if the breach occurred via email phishing, do not use the same channels to coordinate your response. A phone tree with direct mobile numbers is sufficient.
Step 2: Preserve Evidence
As described above - take this step before any remediation action.
Log sources to capture immediately:
- Ecommerce platform access logs (admin activity, account logins)
- Web server access logs (if self-hosted)
- Third-party integration logs (API access records)
- Payment processor activity logs
- Email platform access logs
- Any custom application logs
Set these log sources to extended retention if possible - if logs rotate automatically, the evidence may be deleted before you need it.
Step 3: Assess the Scope
Before notifying anyone outside your team, you need to understand what actually happened:
What data was accessed or exfiltrated?
- Customer personal data (names, addresses, emails, phone numbers)
- Payment card data (though if using hosted checkout, card data should not be in your systems)
- Order history
- Account login credentials (hashed passwords)
- Admin credentials
Which customers are affected?
- All customers, or a specific subset?
- A specific date range of orders or registrations?
- Customers from a specific platform, region, or product category?
What was the attack vector?
- Compromised admin account
- Third-party app or integration
- Code injection via outdated plugin or theme
- Credential stuffing against customer accounts
- Social engineering / phishing of a team member
How long was the breach active?
The first and last dates the attacker had access, or the script was running, or the data was being exfiltrated. This determines how many customers are potentially affected and is required for your regulatory disclosure.
Step 4: Contain and Remediate
Once the scope is understood, close the attack vector:
- Change all admin passwords and revoke all active admin sessions
- Revoke and regenerate any API keys that may have been exposed
- Remove malicious code from theme files (if applicable)
- Update or remove the compromised plugin or app (if applicable)
- Block the IP addresses or access paths used in the attack (with appropriate caveats - sophisticated attackers rotate IPs)
- Audit all admin accounts for any that were created during the breach period
- Review your third-party app list for any apps installed or modified during the breach window
Do not bring systems back online until you are confident the attack vector is closed. A partially remediated system brought back online can immediately be re-compromised through the same vulnerability.
Step 5: Notify Regulators
Regulatory notification timing is legally mandated and non-negotiable.
Under GDPR (UK and EU):
If the breach is likely to result in risk to the rights and freedoms of individuals, you must notify your data protection authority within 72 hours of becoming aware of the breach. In the UK, this is the ICO (Information Commissioner's Office). In EU member states, it is the relevant national Data Protection Authority.
The 72-hour clock starts when you become aware that a breach has occurred, not when you have completed your investigation. You can submit an initial notification with the information available at the time and supplement it later as you complete your investigation.
What the notification must include (Article 33, GDPR):
- Nature of the breach
- Categories and approximate number of data subjects affected
- Categories and approximate number of records affected
- Name and contact details of your data protection point of contact
- Likely consequences of the breach
- Measures taken or proposed to address the breach
Under PCI DSS:
Contact your acquiring bank and payment processor as soon as possible if payment card data may have been involved. They have their own notification and forensic investigation requirements.
Under CCPA (if applicable):
California CCPA requires notification to affected California residents "in the most expedient time possible and without unreasonable delay". There is no fixed 72-hour window, but unreasonable delay creates liability.
Step 6: Notify Affected Customers
Customer notification should happen as soon as you have sufficient understanding of the breach to communicate accurately. Notifying customers before you understand the scope risks creating confusion and fear that you will need to walk back. Waiting too long damages trust and may cause you to miss your regulatory notification deadline.
What to include in customer notification:
- What happened (in plain language - not "a security incident occurred" but "unauthorised access to our customer database")
- What data was affected (specifically what types of data - names, addresses, email, order history - and what was NOT affected - card numbers if using hosted checkout, for example)
- What we are doing about it (remediation steps taken, enhanced security measures implemented)
- What customers should do (monitor their accounts, change their password if credentials were exposed, be alert to phishing using their personal details)
- How to get more information (a dedicated contact point - email address, phone number)
See the customer notification template below.
What not to do:
- Minimise or obscure the breach. Customers will find out regardless and will remember how you communicated.
- Over-promise on what data was or was not affected until you are certain
- Blame third parties in your initial communication, even if accurate. This looks like deflection.
- Include excessive legal disclaimers that make the notification feel like a liability document rather than a communication
Step 7: Recover and Restore
Once the breach is contained and notifications are in progress, restore normal operations:
Restore from clean backup: If your store's data or code has been corrupted, modified, or encrypted, restore from a clean backup taken before the compromise. Vortex Apps provides encrypted, automated point-in-time backups for Shopify and BigCommerce stores - restoring to a specific date means you can get back to your pre-breach state without manual reconstruction.
Verify clean state before going live: Before bringing your store back to full production operation, run a thorough verification: check all theme files for injected code, verify all admin accounts are legitimate, confirm all integrations are using known-good API keys, test the checkout flow end-to-end.
Implement monitoring: If you did not have anomaly monitoring in place before the breach, this is the moment to implement it. Nerve Centre provides real-time monitoring that can detect re-exploitation attempts and confirms that the remediated environment is behaving normally.
Step 8: Post-Incident Review
Within two weeks of the incident being resolved, conduct a documented review:
- What happened, and how?
- What security controls should have prevented or detected it earlier?
- What made the response slower or harder than it needed to be?
- What changes are needed to prevent recurrence?
- What changes are needed to improve the response to a future incident?
The post-incident review is the mechanism for turning a costly experience into an organisational improvement. It should result in a specific list of actions, assigned to named individuals, with timelines.
Breach Response Checklist
Phase Action Owner Time Target Complete? Confirm Verify breach is real (not false positive) Technical lead Within 30 mins of initial indication Preserve Capture logs and screenshots before any changes Technical lead Before any remediation Contain Revoke compromised credentials / disable attack vector Technical lead Within 1-2 hours of confirmation Assess Determine scope: data affected, customers affected, timeframe Technical lead + legal Within 4-6 hours Activate Brief full response team Senior decision-maker Within 1 hour of confirmation Remediate Close attack vector, verify clean state Technical lead Before going live Notify regulators Submit GDPR notification to ICO/DPA Legal/compliance lead Within 72 hours of awareness (GDPR) Notify customers Send customer breach notification Communications lead As soon as scope is understood Restore Restore from clean backup, verify, return to production Technical lead As soon as safe Monitor Confirm environment is stable post-restoration Technical lead Ongoing for 2 weeks post-incident Review Post-incident review and action plan All response team Within 2 weeks of resolution
Customer Notification Template
Below is a template for the initial customer breach notification. Adapt it to reflect the specific details of your incident.
Subject: Important notice about your [Store Name] account
Dear [Customer Name],
We are writing to let you know about a security incident that affected [Store Name] and may have involved your account information.
What happened:
On [date], we discovered that [brief, plain-language description of what occurred - e.g. "an unauthorised third party gained access to our customer database"]. We identified the issue on [date of discovery] and took immediate action to secure our systems.
What information was involved:
The information that may have been accessed includes: [specific data types - e.g. your name, email address, delivery address, and order history]. [If applicable: Your payment card details were not affected - card information is processed through [Payment Provider] and is not stored in our systems.]
What we have done:
We have [specific actions taken - e.g. secured the vulnerability, revoked all affected access credentials, engaged external security experts to review our systems, and implemented enhanced monitoring]. We are also notifying the [relevant authority] as required.
What you should do:
- Change your [Store Name] account password if you have one
- Be alert to any phishing emails that may use your personal information - we will never ask for your password or payment details by email
- If you notice any suspicious activity on accounts where you have used the same email address and password, update those passwords too
If you have questions or concerns, please contact us at [dedicated breach contact email/phone].
We are sorry this happened. Protecting your data is a responsibility we take seriously, and we are committed to learning from this incident.
[Name and title]
[Store Name]
How Backups Change Your Recovery Timeline
The operational difference between recovering from a breach with a clean backup and without one is significant.
With a clean, recent backup:
- Restore to the pre-breach state in hours
- Known-good code, data, and configuration
- Confidence that the restored environment does not contain residual malicious code
- Reduced investigation time (compare current state to backup to identify exactly what changed)
Without a backup:
- Manual identification of every change the attacker made
- Uncertainty about whether all malicious code has been found and removed
- Risk of re-infection from residual malicious code that was missed
- Potential data loss if the attacker deleted or modified records
- Days or weeks of remediation rather than hours
Vortex Apps automated backup provides encrypted point-in-time backups for Shopify and BigCommerce stores. The security use case is one of the clearest: a backup from before the breach date is not just business continuity insurance - it is a forensic baseline and a clean recovery state.
If you do not currently have automated backup in place, setting it up is a high-priority action - ideally before an incident, but doing it now is still vastly better than not having it when you need it.
Frequently Asked Questions
How do I know if my store has been breached?
Common indicators include: customers reporting fraudulent card charges after shopping with you (the most reliable signal of a payment data breach), unusual entries in your admin access logs, unexpected admin accounts or setting changes, your payment processor contacting you about unusual transaction patterns, a security researcher notifying you of an exposure, or your store data appearing in public breach disclosures. Proactive monitoring via Nerve Centre can surface many of these signals before customers start reporting fraud.
Do I have to notify all customers, or only those affected?
GDPR requires you to notify data subjects when a breach is likely to result in a high risk to their rights and freedoms. If not all customers were affected, you should notify only those in scope. However, defining the scope precisely is often difficult in the immediate aftermath of a breach. If the breach affected a large portion of your customer database or the scope is unclear, notifying all customers is typically the right decision - it is better to over-notify than to miss affected individuals. Consult your legal adviser on the threshold for your specific incident.
What happens if I miss the 72-hour GDPR notification deadline?
Missing the 72-hour notification deadline is a GDPR compliance failure in itself, separate from the breach. Regulators take the notification deadline seriously - it exists precisely to ensure timely action. If you miss it, submit the notification as soon as possible and document the reasons for the delay (some delays have legitimate justifications). Regulators consider the circumstances of the delay when determining enforcement action. A brief delay due to genuine operational complexity is treated differently from a prolonged delay that appears to reflect deliberate avoidance.
Should I pay a ransomware demand?
This is a decision that requires legal and law enforcement input specific to your situation, and this guide does not provide a universal recommendation. The general advice from law enforcement agencies (including the UK's NCSC and the US's CISA) is not to pay, for two reasons: payment does not guarantee you will recover your data, and it funds criminal operations that will target other businesses. If you have a clean backup, payment is rarely necessary. Restore from backup rather than paying for decryption. If you do not have a backup, the calculus is harder. In either case, contact law enforcement before making any payment decision.
How long does breach recovery typically take?
For a contained breach affecting a limited scope of data, with clean backups available and a pre-prepared response plan, recovery to normal operations can be achieved in 24-72 hours. For a complex breach with widespread system compromise, no backups, and an unclear attack vector, recovery can take weeks. The variables with the biggest impact on recovery time are: whether you have clean backups, whether you have a documented response plan, and whether you know your attack vector. The last point determines whether you can confidently restore without immediate re-infection.
Related Articles
- Ecommerce Security & Compliance: Complete Guide
- Ecommerce Security 101: Threats Every Store Faces
- GDPR Compliance for Ecommerce: What You Must Know
- Ecommerce Data Security Best Practices
- How AI Agents Protect Your Store 24/7
- Ecommerce Backup & Data Protection: Complete Guide
- Ecommerce Monitoring & Anomaly Detection: Complete Guide
Ready to take action?
Run a Free AI Audit on Your Store
VortexIQ scans your ecommerce store across 85+ checks — SEO, performance, analytics, ads — and gives you a prioritised fix plan in under 30 seconds.