Incident response plan

Effective 18 October 2026 · Version 1.0

1. What counts

A security incident is anything that puts the confidentiality, integrity or availability of client information at risk: someone gaining access they should not have, a lost or exposed key or token, malware, a leaked or mis-sent message, a stolen device with a signed-in session, or a service outage caused by an attack. A suspected incident is handled as a real one until shown otherwise.

Severity: High if client information may have been seen or taken by someone unauthorised, or the service is down; Medium if access was attempted or a control failed but no information is known to be affected; Low for anything else.

2. Who does what

The Security Officer (Dante Nwokeocha) leads every incident, decides on containment and notification, and keeps the incident record. If an incident involves a practice's own staff or devices, that practice's owner is brought in at the start.

3. How we find out

• Reports from practices, staff, clients or researchers (see below).
• The activity record: repeated failed sign-ins, lockouts, sign-ins from unfamiliar places, unexpected exports or erasures.
• Server checks: the monthly security check and the alerts from the firewall and the login-blocking service.
• Notices from DigitalOcean, Meta, TikTok, Acuity or other suppliers.

4. What we do

1. Record. Open an incident record with the time, who reported it, what is known, and keep adding to it.
2. Contain. Stop it getting worse: switch off the affected account, end its sessions by resetting its password, lock or disconnect the affected connection, block the source address in the firewall, or take the application offline if needed. Preserve logs and evidence first where that is quick.
3. Assess. Work out what was reached, whose information it was, and for how long, using the activity record, server logs and database backups.
4. Remove the cause. Replace every key, token and secret that may have been exposed (session key, encryption keys, platform tokens and client secrets, API keys), patch the weakness, and remove any access that should not exist.
5. Recover. Restore from the last good encrypted backup if data or the server was damaged, confirm the application answers and the controls are working, and watch closely for repeat activity.

5. Who we tell, and when

• Practices affected: without undue delay and no later than 72 hours after we confirm that their information was or may have been affected, with what happened, what information was involved, what we have done, and what we recommend they do. The practice decides, with us, whether the people affected must be told, and what the law requires of it.
• Meta, TikTok and other platforms: where an incident involves data received through their services, or tokens issued by them, we notify them as their terms and developer policies require, and no later than 72 hours after confirmation, and we revoke and reissue affected tokens.
• Authorities and affected people: where the law requires it, we help the practice do so, and we do so ourselves when the law puts the duty on us.
• We tell the truth about what we know and do not know, and update as we learn more.

6. Afterwards

Within 14 days of closing an incident, the Security Officer writes a short review: the timeline, the cause, what worked, what did not, and the changes made, then updates this plan or the other policies if needed. Incident records and reviews are kept for at least three years. The plan is read through at least once a year, including a rehearsal of how to rotate every key and restore from backup.

7. Reporting an incident

Write to support@theswitchboardinbox.com with the subject "Security incident". Say what you saw, when, and how to reach you. We reply within one business day for anything marked as an incident and sooner for anything that is clearly urgent. Please do not include passwords or clients' private details in the email.