First identify the symptom and who can act
Record the exact address, what appeared, when it happened and the time zone. Useful symptoms include an unexpected redirect, unfamiliar account, changed content, an external security warning or a payment destination you did not authorize. Slow responses or an error page can also be a technical fault. Distinguish what you observed from an assumption about its cause.
Choose an authorized coordinator who can reach hosting, the developer, domain administrator and other relevant suppliers. Do not keep repeating a suspicious journey just to reproduce it, and do not ask customers to bypass browser warnings. If money or payment details may be involved, use an independently verified contact channel for the payment provider or financial institution rather than relying on a message received during the incident.
Create a short incident record before cleanup
The record should include the observation, affected function, relevant timestamps, recent changes and any actions already taken. Keep screenshots and logs where an authorized person can access them, with unnecessary personal information removed from working summaries. Ask the responsible supplier which evidence can be preserved before logs rotate or changes are applied.
WordPress recommends documentation as a first step after a compromise. Preservation is not permission to collect everything indefinitely or to distribute a customer database to everyone helping. Decide who holds the original evidence, who needs a redacted view and what legal or contractual advice is needed for the circumstances.
| Field | Useful entry | Avoid |
|---|---|---|
| Observation | Exact URL, screenshot and what changed | A diagnosis based only on a scan score |
| Timing | First seen, last known good and time zone | Treating first discovery as the first intrusion |
| Business impact | Checkout, enquiries, content or account access | Assuming every system is affected |
| Actions so far | Who changed what and when | Unrecorded cleanup attempts |
| Owners | Authorized coordinator and supplier contacts | Posting passwords in a group chat |
Containment depends on the affected function
A change to the public site, a stolen administrator account and a suspected payment alteration may need different immediate controls. The authorized owner and suppliers should decide whether to restrict access, pause an affected function or isolate a component. The objective is to reduce further harm while preserving a usable recovery path and evidence.
Do not disable protections globally or remove arbitrary files as a general first-aid rule. A temporary block can also interrupt callbacks, staff access or legitimate orders. Record why a control was chosen, who approved it, which function it affects and what will be checked before it is removed. If the needed action is outside your authority or competence, stop and involve the right provider.
Investigate persistence and access, not just the visible page
Removing a redirect or replacing one file does not establish that unauthorized access has ended. The scope may need to include component versions, accounts, hosting access, connected applications, scheduled tasks and other relevant changes. A scan finding is a lead to validate, while a clean scan is limited by its coverage and access.
Credentials may need rotation or revocation through a trusted administrative route, but sequencing matters. A compromised device or retained application grant can defeat a simplistic password-only response. Avoid detailed cleanup experiments on production without an agreed scope, evidence plan and recovery route. This guide is not a substitute for a forensic investigation.
Choose a recovery copy and protect new business records
Identify the point represented by each backup, what it contains and whether its state is suitable for recovery. A copy taken after the intrusion may contain the same unwanted changes. Where possible, test recovery separately and verify the functions the business needs. Restoring files is not the same as establishing trustworthy operation.
For a live store, compare orders, payments, inventory and connected systems created after the selected point. Restoring an old database does not reverse an external charge or recreate a missing order correctly. Agree reconciliation and authorization before resuming fulfilment. Never replay charges, notifications or shipping actions simply to see whether the integration works.
Define acceptance before reopening the affected workflow
Document what needs to be true before service resumes: intended content and destinations, appropriate access, supported repaired components and agreed business checks. Record which symptoms or routes were tested, which evidence supports the result and what could not be examined. Keep unresolved questions visible with an owner.
Use an appropriate test environment and controlled external integrations. WooCommerce test orders can affect other systems, so a test label alone is not isolation. A confirmed homepage load does not demonstrate that checkout, forms or account restrictions work. Monitoring after recovery should have a defined recipient and response process rather than an unattended stream of alerts.
Reporting, follow-up and professional help
Notification and reporting duties depend on the information, jurisdiction and agreements involved. A technical symptom does not settle those duties, and this guide provides no universal reporting deadline. The coordinator should involve the appropriate legal, privacy or contractual adviser when needed and keep a clear record of facts and uncertainty.
CyberFixCrew is an Israeli cybersecurity company focused on websites and digital infrastructure, with remote service for worldwide businesses. If you contact us, provide the site address, symptom, timing and business impact without secrets. We clarify scope and availability before work. No immediate response, complete recovery or around-the-clock coverage is implied by an enquiry.
