What matters in the first hour
The first 60 minutes often determine how completely an incident can later be reconstructed. The goal isn’t a full cleanup — that needs a structured review — but controlled containment that preserves evidence instead of destroying it.
Before you delete anything
Suspicious files, database entries, or logs are often the only trace that lets you later reconstruct the entry path and possible data-exfiltration indicators. Cleaning up too quickly usually makes that reconstruction impossible.
Safe first steps
- Save screenshots of warnings (Google, hosting provider, browser)
- Do NOT overwrite existing backups — even old ones
- Export access and error logs from your host if you can reach them
- Note unfamiliar administrator accounts, but don’t delete them yet
- Flag any customer or payment data risk internally right away
- Request a structured initial assessment before attempting a DIY fix
What puts recovery at risk
- deleting suspicious files too quickly
- resetting the whole site before making a backup
- installing another cleaner plugin without knowing the cause
- sending credentials unencrypted via email or messenger
- overwriting backups before the scope of the incident is clear
Finding, indicator, and limit
A missing log entry doesn’t prove there was no access — it only shows that nothing was recorded at that point. That distinction matters for an honest assessment.
A full review for data-exfiltration indicators is a separate step that goes beyond the cleanup itself.
What is a practical 60-minute incident sequence?
A fixed sequence keeps urgency from turning into contradictory changes. The times are a guide, not a service guarantee. If the site is currently redirecting visitors, altering payments, or exposing customer data, containment takes priority.
Minutes 0–10: establish scope and ownership
Record who noticed the incident, when the symptom was first observed, and which systems may be involved. Determine whether the site only publishes content or also handles forms, accounts, orders, or payments. Assign one person to coordinate changes. Multiple administrators simultaneously deleting plugins, resetting passwords, and restoring backups make the timeline much harder to understand.
Avoid repeatedly opening malicious-looking URLs on production workstations. Preserve the exact URL, timestamp, timezone, screenshot, and wording of browser, search-engine, or hosting warnings. Keep provider notices and support-ticket histories.
Minutes 10–30: preserve evidence that may disappear
Export available web-server, PHP, WAF, CDN, SFTP, and authentication logs before retention or rotation removes them. If it can be done safely, take unchanged copies of the files and database. These copies are incident snapshots, not proof that the content is clean enough to restore.
Record current administrators, application passwords, sessions, scheduled tasks, and unexpected redirects. Preserve timestamps, but do not treat them as conclusive on their own: an attacker, deployment, or copy process can alter them.
Minutes 30–60: contain deliberately and prepare the handoff
Choose the narrowest action that reliably limits ongoing harm. Depending on the incident, that might be a maintenance response, a WAF rule, suspension of a compromised identity, or temporary shutdown of an affected feature. Deleting the entire installation is rarely the safest first move.
Prepare a short handoff: affected domains and systems, timeline, observed symptoms, actions already taken, available backups, preserved logs, and provider or privacy contacts. A structured initial assessment can then begin with evidence rather than assumptions.
Should the site be taken offline immediately?
Immediate suspension is appropriate when the site is actively distributing malware, redirecting visitors, manipulating payments, or exposing data and a targeted control cannot stop the effect quickly enough. It is not automatically appropriate for an old warning or when shutdown would destroy the only available evidence.
Use four questions:
| Question | Why it matters |
|---|---|
| Is the harmful behaviour still active? | Ongoing harm raises containment urgency. |
| Could user or payment data be reachable? | Potential exposure needs early internal escalation. |
| Can a narrower control stop the effect? | Targeted controls preserve more evidence and availability. |
| Has available evidence been copied? | Major changes should follow preservation where practical. |
Taking a site offline does not remove database changes, stolen credentials, scheduled jobs, or server-level persistence. Offline is not the same as clean.
When should passwords and secrets be rotated?
Compromised credentials must be revoked, but order matters. Resetting a WordPress password while an unknown administrator, stolen hosting account, or webshell remains active can expose the replacement credential as well.
Start with trusted administrative identities outside the affected environment: hosting, DNS, CDN, email, and the credential portal. Then rotate WordPress administrators, database accounts, application passwords, API keys, payment and delivery integrations, and WordPress salts. Terminate old sessions. The dedicated guide explains the full secret and session rotation sequence.
Secure transfer
Never place credentials in the public assessment form. Use the agreed secure-transfer channel, and prefer temporary or narrowly scoped access where the platform supports it.
What information makes an initial assessment useful?
A good handoff separates an observation from an interpretation. “Requests to /offer/ began redirecting at 14:20 CET” can be checked. “Plugin X stole every customer record” is a conclusion that requires evidence.
Useful inputs include:
- exact symptoms, URLs, timestamps, and timezone;
- hosting, CDN, WAF, and WordPress access through a secure channel;
- changes shortly before the event, including deployments and new users;
- the kinds of personal or payment data the site processes;
- backup timestamps and storage locations;
- every repair or credential action already performed.
The sample incident report shows how findings and limitations are separated in the final record. The methodology page also explains why triage, remediation, and evidence-preserving forensic work have different scopes.
What follows after the first hour?
The next stages are root-cause assessment, replacement from trusted sources, controlled credential rotation, functional verification, and minimum hardening. Documented indicators are searched again, while unverified components and missing evidence remain explicit limitations.
If personal data may have been reachable, run a parallel indicator-based data-exfiltration assessment. It can identify evidence and gaps, but it cannot promise a conclusion that the available logs do not support or replace legal advice.