Incident Response & Breach Policy

• Applies to our people, systems, and client environments we manage.
• Goals: fast detection, containment, recovery, and honest communication.
• Personal data breaches follow UK data protection law and our DPA.

• Security incident: any event that harms confidentiality, integrity, or availability.
• Personal data breach: accidental or unlawful loss, alteration, or unauthorised access to personal data.

• Security Lead (Director): leads response, decides severity, handles regulators.
• Incident Manager: runs the plan, logs actions, coordinates the team.
• Technical Lead: investigates, contains, and fixes.
• Comms Lead: drafts client and internal updates.
• All staff: report suspected incidents immediately.

Times align with our SLA for supported systems.

• Sources: monitoring alerts, access anomaly alerts, user reports, vendor advisories.
• Report immediately by email or phone to the Security Lead and your project channel.
• Do not delete evidence or reboot affected hosts unless told to by the Incident Manager.

• Confirm the incident, set severity, assign roles, open an incident log.
• Identify systems, data types, and time window. Preserve logs and snapshots.
• Decide if personal data is involved and which clients are affected.

• Rotate tokens and passwords; revoke suspicious sessions.
• Isolate hosts, disable webhooks, or pause workflows where needed.
• Apply vendor patches or configuration blocks.

• Remove malware or backdoors; clean configs and dependencies.
• Restore from known-good backups; validate integrity and access logs.
• Return services to normal; monitor closely for recurrence.

• Clients: notify affected clients promptly with facts, scope, and actions.
• Personal data: if there is likely risk to people, notify the UK ICO within 72 hours of awareness and affected clients/users as required. We support controllers per the DPA.
• Records: keep time-stamped notes, decisions, and evidence.

Client update template

• Subject: Incident notice – [system], [date/time UTC]
• Summary: what happened, when detected, and current status.
• Impact: systems/data affected; who is impacted.
• Actions taken: containment and recovery steps.
• Next steps: monitoring, fixes, and any client actions.
• Contact: name and phone for follow-up.

• Export logs, configs, and hashes to a secure folder with restricted access.
• Record who accessed evidence and when.
• Keep copies for at least 12 months or longer if required by contract or law.

• Within 10 business days, complete a short root cause analysis.
• Agree actions: fixes, tests, docs, training, or supplier changes.
• Share a summary with affected clients (P1/P2).

• Run an incident drill at least yearly.
• Test backup restores twice a year for hosted components.
• Verify alerting works after major platform changes.

• Track vendor advisories (e.g., n8n, WordPress, Stripe, Twilio, OpenAI).
• If the cause is a third-party outage, keep clients updated and provide workarounds where possible.
• For client-owned environments, follow their runbooks plus this policy as a minimum.

Report incidents immediately:

Technophobia Ltd · Company No. 14898332 · VAT GB 495 7043 58
13B Devonshire Road Industrial Estate, Millom, LA18 4JS, United Kingdom
hello@technophobia.uk · +44 1229 774591