Incident Response Procedure¶
| Distribution | Personnel (Employees and Contractors); Clients and system users upon request |
| Version | 1.0 |
| Approved | 2026-04-21 |
| Approved by | Leadership |
Overview¶
See the related Information Security Policy for background regarding incident definition.
The scope of this document is information security incidents, which are unexpected events impacting confidentiality, integrity and/or availability of information.
Preparation¶
- Contact methods are configured to direct security notifications to the Incident Response Team: operations manager and business owners.
- Personnel and users in scope are provided with training which includes sharing of contact methods to use in case of a potential or actual security incident.
- Appropriate systems are configured to log relevant security data and provide alert notifications to the security management team when certain parameters are met.
- Required client, law enforcement and insurance contacts are maintained in Capsule CRM and the Key Contacts Spreadsheet.
Incident Reporting Contacts¶
If you suspect a possible or actual security incident, please use the contact details below:
| Name | Contact Method(s) |
|---|---|
| Incident Response Team | security@fooengine.com |
Procedure Definition¶
1. Detection¶
- Incident Response Team receive notification via configured contact methods (from human or automated origin).
- An incident ticket is opened, with the following fields available:
- Origin (Internal, External, etc.)
- Criticality (Minor, Major, Critical)
- Status (Open, In Progress, Closed)
2. Triage and Escalation¶
- Incident is triaged with a criticality according to the Incident Triage Tool by the incident responder.
- Incident ticket must be updated with timestamped notes upon any notable changes for the purposes of evidence collection and incident handling records.
- At any time, incident criticality can be increased due to an evolving situation. The Incident Triage Flowchart should be referred to in case of material changes to the incident profile.
3. Response and Notification¶
- Situation is assessed and measures are taken to contain and mitigate the incident.
- Depending on the criticality, appropriate parties will be notified. See below for Escalation and Notification table.
- Evidence relating to the incident continues to be preserved and collected by the Incident Response Team members.
- An investigation is conducted into the incident to understand the situation.
- A plan is developed to address the incident as necessary, including restoring systems, services, and any necessary fixes, making use of Business Continuity Procedures as necessary.
- When the incident has been contained, status of incident is set to Contained.
Escalation and Notification Table¶
| Incident Criticality | Incident Responsibility | Notified Parties |
|---|---|---|
| Minor | Security Management Team | Impacted clients / users |
| Major | Security Management Team | Impacted clients / users; relevant data protection authorities (e.g. ICO) if PII exposed |
| Critical | Security Management Team | Law enforcement (e.g. FBI, NCA); insurers; impacted clients / users; relevant data protection authorities (e.g. ICO) if PII exposed; consider public announcements / crisis communications |
4. Reporting, Metrics and Corrective Action¶
- Reports are generated including findings, action taken and impact assessments.
- Exploited vulnerabilities are identified and recorded.
- Root cause analysis is performed, lessons learnt are documented, and countermeasures are developed to prevent similar incidents.
- Incident ticket ID to be referred to in related documentation.
- When incident follow up has been completed, the incident ticket is marked as Closed.
Appendix A: DDOS / Ransomware Response Plans¶
DDOS Response Plan¶
DDOS response would be handled as per any other incident; only weaknesses would be website and externally exposed endpoints. Use would be made of cloud provider tools e.g. AWS Shield / GCP Cloud Armor to reject and work around unauthorised traffic load. Alternative endpoints could be exposed and programmed into Orkes/related tools as applicable.
Ransomware Response Plan¶
Ransomware response would be handled as per any other incident; we do not expect the outcome to be disabling as we do not run internal Active Directory, or have subnets with significant numbers of user computers.
In addition, BitDefender on remote user devices and server hosts, and the filtering / firewalling, isolated subnets and code/image scans in cloud environments before publishing limit exposure to traditional ransomware attacks.
Key machines will be backed up with snapshots so can be recovered as per after any disabling incident; central configuration will be loaded in from MDM.