Incident Response Plan

Purpose and Scope

This plan defines how Turtlestack Automation Ltd. prepares for and responds to security incidents across IT and OT environments. It is based on the company risk assessment and is proportionate to our size and business needs.

Risk Context

• Maintains a risk register covering internal systems, supply‑chain and customer connections.
• An asset register links the data, personnel, software, devices, systems and facilities that support essential functions.
• High‑impact systems receive annual assurance and are prioritised during response.

Governance

• The plan is sponsored and approved by senior management.
• The security lead has authority and resources to execute it.
• Limitations of in‑house capability are documented; external specialists may be engaged when required.

Communication and Review

• The plan is shared with all relevant business areas and forms part of onboarding.
• Reviewed annually or when significant threats emerge.
• Integrated with business continuity and supply‑chain plans.

External Support

• Contacts for legal counsel, law enforcement and a retained incident‑response partner are listed in the appendix.
• Ransomware payments will not be made without advice from law enforcement and legal counsel.

Preparedness

• CIRT members receive annual training and participate in exercises that cover preparation, identification, containment, eradication, recovery and lessons learned.
• Monitoring staff roles and required skills are defined; at least one team member is on call for alert analysis.

Detection and Analysis

• Threat intelligence feeds are reviewed monthly to refine alerting rules.
• Devices unable to generate logs are documented with compensating controls.
• Each incident is classified by severity to guide escalation and resourcing.
• An initial handler is appointed for every incident, with additional responders assigned as needed.
• Network diagrams are maintained to support investigation.

Response

• Major incident types are listed in the classification document
• Forensic data is preserved and external specialists can be engaged under pre-agreed terms.
• Critical systems have procedures to restore them to a known good state, and vendor SLAs are maintained where third‑party systems are involved.

Reporting and Post‑Incident Activity

• Reporting requirements to regulators or customers are tracked by the security lead.
• After every incident a review captures lessons learned; distribution of findings is limited to those with a business need to know.