Website Security Incident Readiness

Define what should activate the plan

Write down the signals that should trigger an incident response: unexpected administrator accounts, unauthorised page changes, browser security warnings, unexplained redirects, a hosting alert, loss of domain or DNS control, exposed services, or credible notice from a supplier or customer.

A signal is not automatically proof of compromise. Record what was observed, when it appeared and who noticed it, then use the plan to decide who verifies the event and how urgently it should be escalated.

Assign roles and keep contact details offline

Name one decision owner and backups for the technical, business and communications roles. Record current contact details for the website developer, hosting provider, registrar, DNS provider, email provider, payment provider, insurer and an external incident-response specialist if the business has one.

Keep an offline copy that remains available if email, cloud storage or the website account is unavailable. Include account identifiers and support channels, but never store passwords or recovery codes inside the response plan.

• Decision owner: authorises high-impact containment and recovery actions.
• Technical lead: gathers evidence and coordinates hosting, website and DNS changes.
• Communications lead: records decisions, timestamps, contacts and customer-facing updates.
• External contacts: provider escalation paths, insurer and specialist assistance.

Know which assets and access paths matter

List the domain, registrar, DNS zone, hosting environment, website platform, database, content delivery network, analytics, forms, payment integrations and administrator accounts involved in running the site. Note who owns each service and where audit logs can be obtained.

Protect the recovery paths before an incident. Use multi-factor authentication, individual administrator accounts and controlled recovery contacts, and remove former staff or supplier access promptly.

Preserve evidence before making broad changes

Capture timestamps, screenshots, alert messages, relevant URLs, unfamiliar accounts and available provider logs. Keep an incident log showing who took each action and why. Good records help a specialist establish scope and prevent the same evidence from being lost during rushed changes.

Do not delete files, rebuild the server or rotate every credential blindly before qualified advice when a serious compromise is suspected. Those actions can destroy useful evidence or lock responders out. Prioritise safety and containment while preserving what can reasonably be preserved.

Plan safe containment and escalation

Containment should be proportionate to the event. A provider may recommend disabling a compromised account, restricting an administrator path, placing the site in maintenance mode, isolating an affected service or restoring trusted DNS. Pre-authorise who can make those decisions and how suppliers will be contacted.

Call specialist help when the business cannot establish what changed, sensitive data or payments may be affected, the attacker appears to retain access, or evidence may be needed for insurance, legal or regulatory purposes. ScoutLab does not provide an incident response service or digital forensics.

Prepare recovery and verification

Document the trusted backup locations and the steps for rebuilding the website, database and configuration. Record dependencies such as DNS, certificates, email delivery, forms and payment callbacks so recovery checks the whole customer journey rather than the homepage alone.

After recovery, verify administrator access, software versions, integrations, redirects, certificates, DNS and externally visible services before reopening normal operation. Continue monitoring for recurrence and retain the incident record for the business's review.

Plan communications and reporting

Decide who communicates with staff, suppliers and customers and which channels remain available during an outage. Keep messages factual: what is known, what is not yet known, what action recipients should take and when the next update will come.

Australian reporting and data breach obligations depend on the event and the organisation. The cyber.gov.au reporting service provides the current national starting point. This guide is not legal advice, does not determine whether a data breach is notifiable and does not provide compliance certification.

Exercise the plan and use external signals carefully

Run a short exercise using a realistic scenario, such as an unauthorised administrator or changed DNS record. Confirm that roles, contacts, decisions, evidence capture and recovery steps work, then update the plan after supplier, staffing, hosting or platform changes.

External scans can establish a before-and-after view of publicly visible configuration and exposure. ScoutLab's Free Scan, Deep Scan and Monitoring can observe those signals, but they do not confirm or contain a compromise, do not inspect internal logs, do not provide digital forensics or a full incident response, and cannot guarantee recovery or security.