Practical guides

Prepare a response to a website incident

An outage, a silent contact form and an incorrect page do not have the same impact. A short plan helps a team establish facts, reduce disruption and verify recovery under pressure.

Go to the method

Team preparing checks for recovery after a website incident

Classify incidents by observable impact

List essential journeys: read an offer, make an enquiry, book, pay or obtain service information. For each, describe a recognisable failure and its effect on visitors. A slow page differs in urgency from a purchase confirmed but not recorded.

Name who can detect, assess and decide on action. An alert, customer report or manual check can all reveal a problem. Record the time, URL, symptom and recent changes before guessing the cause.

  • Critical journeys known.
  • Severity tied to real impact.
  • Time and symptoms recorded.

Plan the first actions

Assign a coordinator and backup technical contact. Point to deployment history, backups, provider documentation and external status pages without placing secrets in the plan. Avoid simultaneous undocumented edits that make diagnosis harder.

For a security or personal-data event, follow the organisation’s specialist procedure and seek the relevant expert help. This guide covers coordination at the website level; it cannot replace an incident-specific technical or legal assessment.

  • Coordinator and deputy named.
  • One action and decision log.
  • Escalation route understood.

Communicate without inventing a deadline

Prepare a factual message: affected function, consequence for the visitor, workaround where available and time of the next update. Publish it through a channel that still works and offer another contact route if the website form is affected. Do not present a technical hypothesis as a confirmed cause.

Tailor the notice to the people affected. If public information was wrong, identify pages and messages to correct. Keep the same facts across the languages actually published.

  • Alternative channel identified.
  • Dated, understandable message.
  • Next update stated without a made-up restoration time.

Verify recovery and learn

After a fix, complete affected journeys on the live site: forms, payments, emails, redirects, content and mobile access as relevant. Check whether enquiries arriving during the incident were found or handled. An alert clearing does not show that the journey is fixed.

Write a brief note with timeline, impact, cause established or still uncertain, useful actions and a preventive change. Test the recovery plan and update contacts and procedures before the next incident.

  • Real production journeys retested.
  • Missed enquiries sought.
  • Plan and responsibilities updated after review.