Describe what happened without turning suspicion into a conclusion
Record the affected page or function, first observed time and timezone, screenshots without sensitive customer details, and recent changes. Symptoms may include unexpected payment destinations, unfamiliar administrators, injected code, unusual redirects or alerts. A failed checkout or slow site also has nonmalicious explanations that need to remain in the investigation.
WordPress’s hacked-site guidance starts with documentation of symptoms and timing. For a store, extend that initial record to the business routes potentially affected: whether customers can reach checkout, whether orders are arriving and whether payment or fulfillment behavior looks unusual. Keep observed facts separate from assumptions about the entry point or attacker.
Name the person authorized to make decisions and the relevant technical contacts. The host, store developer, payment-provider account owner and business operator may each control a different part of containment. Use an established trusted contact route rather than following instructions displayed on a potentially altered page.
Coordinate containment across the affected business lanes
Choose actions based on the observed risk and dependencies. A shop may need to restrict a specific function, pause an external route or take broader measures, but those decisions should be made by the responsible owner with technical support. A maintenance screen can hide a page without disabling background jobs, API routes or access to hosting.
Use this original lane-based handover to assign work. It is not an instruction to disable every system or a substitute for incident-specific judgment. Preserve relevant evidence before it is overwritten where feasible, while responding appropriately to active harm.
| Lane | Owner and initial question | Evidence before normal activity resumes |
|---|---|---|
| Website and hosting | Technical owner: what is affected and still reachable? | Scoped containment, investigated changes and agreed checks |
| Accounts and access | Account owner: which identities and recovery routes matter? | Authorized changes and verification of relevant access paths |
| Payments | Provider-account owner: are destinations or transactions affected? | Provider-coordinated findings and supported payment checks |
| Orders and inventory | Business operator: which events need reconciliation? | Known cutoff, current records and unresolved exceptions |
| Integrations and jobs | Destination owner: what continues in the background? | Controlled queues, tokens, destinations and duplicate handling |
| Communication and release | Authorized decision-maker: who needs what information? | Accurate status, documented conditions and next owners |
Compare orders with payment evidence before financial actions
If checkout or payment handling may be affected, involve the payment provider through its trusted support route and follow the relevant incident process. Avoid sending card details or full customer exports through an informal channel. Potential payment-data exposure or notification duties need the appropriate parties and circumstances assessed separately.
Identify the gateway and transaction references through authorized records. A thank-you page, local status or customer message can be useful evidence but does not settle every payment state. WooCommerce’s troubleshooting documentation shows why provider behavior, order notes and transaction records matter when an apparent mismatch is investigated.
Do not issue refunds, retry charges or bulk-change orders simply to make one dashboard look correct. Establish what actually happened, who can authorize the next financial action and how duplicates will be avoided. Keep normal business-process defects and confirmed unauthorized changes distinct in the record.
Review connections that can outlive the visible website problem
Inventory relevant API identities, webhook destinations, scheduled jobs, plugins and third-party account access. A restored homepage does not revoke an exposed secret or close a separate integration route. Coordinate credential or permission changes with the owner so necessary business systems are not interrupted without a plan.
WooCommerce webhooks can notify external systems about store events, and delivery records help trace those handoffs. Review the intended destinations and what the receiving systems did. Pausing one source does not necessarily clear events already queued or actions already accepted elsewhere.
Keep a timeline of authorized changes during the response. Otherwise a legitimate containment step may later look like an unexplained modification. Record what was changed, why, by whom and what evidence showed the intended result, while keeping secrets out of ordinary notes and screenshots.
Treat recovery and business reconciliation as separate checks
Select candidate backups with an understanding of their timestamp, scope and uncertainty about cleanliness. Preserve the material needed for investigation and examine a controlled recovery environment before overwriting active data. New orders, captures, refunds, stock movements and shipments can require distinct reconciliation.
Use synthetic records and isolated external connections for acceptance. Do not “test” recovery by making a live purchase or reprocessing a production queue. An operationally recovered store may still need an explicit hold on a business route whose results have not been verified.
Agree on return-to-service conditions and a factual handover
The release decision should cover the affected functions, relevant access changes, investigated components, payment route, order reconciliation and external actions. Define what is verified, what is excluded and which exceptions remain. A scan showing no current finding is one observation, not proof that every historical consequence has been resolved.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide. Our practical Israeli website and digital-infrastructure knowledge supports scoped incident and recovery work with the actual system owners. Start with the shop address, symptoms and timing. Do not send credentials, database exports or payment data in the initial message, and do not assume response hours or a fixed recovery time before agreement.
After stabilization, record the known cause or remaining uncertainty, changes made, results checked and preventive follow-up. Keep customer communications accurate and coordinate any legal, insurance or payment-provider requirements with the appropriate advisers. A useful report describes what evidence supports; it does not invent a complete forensic conclusion from a repaired page.
