Incident Response Plan

Purpose

This Incident Response Plan (IRP) defines the process LGCIT follows when responding to security incidents affecting our own infrastructure or client systems under our management.

The plan is designed to:

• Minimise the impact of incidents on client operations
• Protect client data from unauthorised access, loss, or destruction
• Ensure legal and regulatory obligations are met
• Provide a clear, repeatable process that all technicians can follow under pressure
• Capture lessons learned to improve our security posture over time

Scope

This plan covers all incidents affecting:

• LGCIT’s own IT infrastructure (servers, workstations, network equipment, management tools)
• Client IT systems under LGCIT management, where we act as data processor
• Client data stored or processed on systems we manage
• Third-party services used in the delivery of our services (sub-processors)

Incident definition

An incident is an event that compromises, or is reasonably likely to compromise, the confidentiality, integrity, or availability of data or systems.

This includes, but is not limited to:

• Unauthorised access to systems or accounts
• Malware or ransomware infections
• Denial of service attacks
• Phishing attacks resulting in compromised credentials
• Loss or theft of company-managed devices
• Accidental disclosure of client data
• Successful social engineering against LGCIT staff
• Breach of a sub-processor affecting client data
• Any event triggering a legal or regulatory notification obligation

Not every fault is an incident. A failed hard drive or a power outage is an operational issue, not a security incident, unless it reveals or compromises data.

Incident classification

Incidents are classified by severity to determine the appropriate response level.

Roles and responsibilities

In practice for a small organisation, one person may hold multiple roles. The Lead Technician and Data Protection Lead may be the same person. The principle is that each function is assigned, not that each is a separate individual.

Response phases

Phase 1: Preparation

Done before any incident occurs.

• Maintain an up-to-date asset inventory of all managed systems
• Ensure backups are configured, tested, and restorable
• Keep contact details for all client nominated representatives
• Maintain access to incident response tools (RMM, EDR console, backup console)
• Train staff on incident recognition and reporting procedures
• Keep this plan under version control and review it at least annually
• Make sure all relevant staff have a copy of this plan and know where to find it under pressure

Phase 2: Detection and analysis

When a potential incident is detected:

1. Identify — confirm whether the event meets the incident definition. Gather initial evidence: screenshots, logs, timestamps.
2. Classify — assign a severity level using the table above. If unsure, classify higher and escalate.
3. Log — create an incident record. At minimum record: date and time detected, who reported it, what happened, systems involved, initial classification.
4. Preserve evidence — do not reboot affected systems unless necessary for containment. Take memory captures, disk images, or forensic copies where practical. Record every action taken with a timestamp.
5. Notify — inform the Data Protection Lead and, for High severity incidents, the Client Contact.

Sources of detection include:

• EDR alerts from Bitdefender GravityZone
• RMM alerts (NinjaRMM)
• Microsoft 365 security alerts (Azure AD Identity Protection, Defender for Office 365)
• Client reports of unusual activity
• Automated monitoring alerts

Phase 3: Containment, eradication and recovery

The priority is to stop the incident from worsening.

1. Short-term containment — isolate affected systems from the network. Disable compromised accounts. Block malicious IPs at the firewall. Take affected systems offline if necessary.
2. Eradication — remove the root cause. This may involve rebuilding affected systems from known-good backups, removing malware, rotating all affected credentials, revoking session tokens, and applying missing patches.
3. Recovery — restore systems to normal operation. Restore data from clean backups. Verify system integrity before returning to production. Monitor restored systems closely for signs of recurrence.

For ransomware specifically:

• Do not pay the ransom. There is no guarantee data will be restored.
• Isolate affected systems immediately.
• Determine the strain of ransomware from the ransom note or file extensions.
• Restore from the most recent clean backup.
• If no clean backup exists, engage a data recovery specialist.

Phase 4: Post-incident activity

After the incident is resolved:

1. Root cause analysis — determine how the incident occurred. Identify the initial compromise vector, any security controls that failed, and any controls that should have prevented it.
2. Lessons learned — document what went well, what went wrong, and what would be done differently. This is not about blame.
3. Remediation — implement changes to prevent recurrence. This may include policy changes, additional security tools, staff retraining, or configuration changes.
4. Report — produce an incident report for the client. Include a timeline, data affected, actions taken, and remediation steps.
5. Close — formally close the incident record. Update this plan if any procedural gaps were identified.

Communication plan

All client-facing communications must be factual, avoid speculation, and be approved by the Data Protection Lead before sending.

Data breach notification (ICO)

Where a personal data breach is likely to result in a risk to the rights and freedoms of individuals, we will notify the ICO within 72 hours of becoming aware of the breach.

The notification will include:

• A description of the nature of the breach
• The categories and approximate number of data subjects and records concerned
• The name and contact details of the Data Protection Lead
• A description of the likely consequences of the breach
• A description of the measures taken or proposed to address the breach

Where notification is not provided within 72 hours, we will record our reasons for the delay.

Plan testing

This plan is tested:

• Tabletop exercise — annually. The team walks through a realistic incident scenario to validate the plan.
• Live drill — every 2 years. A simulated incident is run to test practical response capabilities.
• After any real incident — the plan is reviewed and updated based on lessons learned.

Each test is documented, and any gaps or improvements are tracked to resolution.

Plan maintenance

Contact information

Maintained separately to this document to allow updates without changing the plan itself. All staff have access to the current contact list.

Internal contacts:

External contacts:

For client nominated representatives, refer to the client contact list maintained in our service management system.