Website hacked? A calm checklist for the first 60 minutes

Minutes 0–10: confirm and take control

1. Record who reported the issue, what they saw, the time, affected URL and any screenshots or alerts.
2. Nominate one incident lead. Keep technical changes and customer communication coordinated through that person.
3. Check from a safe, separate device. Do not log into a suspicious admin page from the computer that first observed the issue.
4. Open a written incident timeline. Record every action, account change and decision from this point.

A browser warning, strange redirect, unknown admin, modified page, outgoing spam or hosting alert is enough to begin triage. It is not yet proof of the incident’s full extent.

Minutes 10–20: preserve before you clean

• Preserve available web-server, application, authentication, DNS, WAF and hosting control-panel logs.
• Capture the current DNS records, admin-user list, recent deployment history and relevant timestamps.
• Ask the host or responder whether a snapshot or forensic copy should be taken before files are deleted or the server is rebuilt.
• Do not blindly install “cleanup” tools, delete suspicious files or overwrite the site. Those actions can destroy evidence and leave persistence elsewhere.

CISA’s incident-response material emphasises preserving volatile or short-retention evidence and coordinating containment with analysis. See the official CISA response guide.

Minutes 20–40: contain deliberately

The correct containment action depends on the incident. A temporary maintenance page, origin restriction, WAF rule, revoked session or host-level isolation may reduce harm while preserving more evidence than immediately destroying the server.

• Revoke unknown sessions, API tokens and users with the responder’s guidance.
• Reset privileged credentials from a known-clean device, starting with domain registrar, DNS, hosting, deployment and website administrators.
• Enable MFA where it is missing. Do not reuse passwords across those systems.
• Check whether email accounts, forwarding rules, payment credentials or connected APIs share access with the compromised website.
• If malicious traffic is ongoing, apply narrowly targeted controls and test that legitimate customers are not locked out.

Minutes 40–60: scope recovery and communication

1. Identify the earliest known suspicious event and decide what systems may share the same credentials, code or infrastructure.
2. Find candidate backups from before that time. Verify them in isolation; do not assume the newest backup is clean.
3. Write the recovery plan: rebuild or clean, patch the entry point, rotate secrets, restore, test and monitor.
4. Decide who needs to be informed now: leadership, hosting provider, insurer, legal adviser, Information Officer, payment provider or customers.
5. Prepare factual holding language. State what is known, what is not yet known and what customers should do—without guessing.

NIST recommends verifying backup integrity before returning assets to service. Its cybersecurity recovery guidance also stresses realistic recovery planning and improvement after incidents.

South African reporting considerations

If personal information was compromised, POPIA obligations may apply. The Information Regulator states that responsible parties should notify the Regulator and affected data subjects as soon as reasonably possible, and that all security compromises must be reported irrespective of deemed risk. Reporting is now handled through its eServices portal.

Read the Regulator’s current security-compromise fact sheet and obtain appropriate legal advice. Cybersecurity incidents can also be reported to South Africa’s National Cybersecurity Hub.

What happens after the first hour?

Containment is not the finish line. Establish the root cause, remove persistence, patch the exploited weakness, rotate every affected secret, validate clean backups, test the restored website and monitor for repeat indicators. Record what failed in the prevention and response process.

Do not publish “all clear” until the people responsible for technical recovery, business risk and required notifications agree on what that statement means.