Information Security Incident Response and Ransomware Recovery
Incident Response in Brief
- Detect, contain, eradicate, recover and learn from incidents
- ICO notification within 72 hours for personal data breaches under UK GDPR
- Ransomware decisions made calmly under pre-prepared plans
Information Security Incidents and Ransomware
An information security incident is any event that compromises the confidentiality, integrity or availability of information. Most incidents are minor - a misdirected email, a lost USB stick, a phishing attempt that nobody fell for - but the same process needs to handle them as the rare serious events: a successful ransomware attack, a confirmed data breach, an insider stealing customer records.
The point of a documented incident response process is that decisions get made calmly under pressure, and that the lessons get fed back into the wider information security management system. Without a process, organisations tend to either over-react to small events or fail to spot serious ones until they are already out of hand.
What Counts as an Information Security Incident
The definition needs to be broad enough to capture genuine concerns without flooding the process with false alarms. A useful working definition is anything that has, or could have, compromised the security of information the organisation holds. That includes the obvious - phishing emails, malware infections, lost devices, suspected hacks - but also less obvious events such as a colleague accidentally seeing information they should not have, a supplier raising a concern about how data was handled, or an unexplained system outage that turns out to be an attack rather than a fault.
Near misses are worth capturing as well. A phishing email that nobody clicked, a backup that failed but happened not to be needed, an access account that was not disabled when someone left - these are all incidents in the management system sense, even if the harm did not crystallise. They tell you where the controls are working, where they are weak, and where to focus next.
Responding to an Information Security Incident
The standard response sequence is: identify, contain, eradicate, recover, learn. Identify means recognising that an incident is happening or has happened. Contain means stopping it from getting worse - disconnecting an infected device, locking a compromised account, isolating affected systems. Eradicate means removing the cause - cleaning malware, revoking access, closing the vulnerability. Recover means restoring normal operations from backup or other clean sources. Learn means going back through the incident, working out what happened and why, and updating the controls so the same thing is less likely next time.
For most organisations the early stages of response need to be fast and decisive. The instinct to find out exactly what happened before taking action can be the worst response - the time spent investigating is time the attacker is using to spread further. A good rule is that containment comes first, investigation second.
Ransomware Specifically
Ransomware deserves a section of its own because it is the incident that has caused the most disruption to UK businesses in recent years and because the response has some specific features. Ransomware encrypts files on the affected systems and presents a demand for payment - usually in cryptocurrency - in exchange for the decryption key. Many variants now also exfiltrate data first, threatening to publish it if the ransom is not paid. This double-extortion model has become the norm.
The official UK position from the National Cyber Security Centre is that paying a ransom is strongly discouraged. Payment funds the criminal ecosystem, does not guarantee data recovery, and may breach sanctions if the recipient is a designated entity. The practical position for most organisations is that working backups are what makes refusal viable - without them, the pressure to pay becomes very hard to resist.
Ransomware response includes immediate containment by disconnecting affected systems from the network, preserving evidence for any later investigation or insurance claim, notifying the Information Commissioner's Office if personal data is involved, notifying any cyber insurance provider, and beginning recovery from backups once the affected systems have been cleaned. The decision on whether to pay is one that should be made at board level, with legal advice, and almost never under the time pressure imposed by the attacker.
Reporting Information Security Incidents
Personal data breaches that are likely to result in a risk to the rights and freedoms of individuals must be reported to the Information Commissioner's Office within 72 hours of the organisation becoming aware of them. The threshold is low - it does not have to be a confirmed breach with confirmed harm, just a likely risk - and the 72-hour clock starts when the organisation becomes aware, not when it has finished investigating.
Other reporting obligations apply in specific sectors. Financial services firms have separate obligations to the FCA and PRA. Operators of essential services and relevant digital service providers under the Network and Information Systems Regulations 2018 have obligations to their competent authority. Cyber incidents affecting national security are reported to the NCSC. Most organisations also have contractual reporting obligations to customers, and to insurers under the terms of cyber insurance policies.
Internal reporting matters too. Workers need to know how to report a suspected incident - usually a single email address or phone number that is well-publicised - and they need to know that reporting is encouraged rather than punished. A culture where workers hide problems is a culture in which serious incidents go undetected.
Learning from Information Security Incidents
The point of recording and reviewing incidents is to feed the learning back into the management system. Each incident should generate at least one of: an improvement to a control, a change to a policy or procedure, a training need, or an update to the risk register. If an incident leaves the management system unchanged, the learning has been lost.
Incident trends matter as much as individual events. A pattern of phishing reports from a particular team might indicate a training gap. Repeated near misses with backups suggest the backup process needs attention. A growing number of supplier-related incidents points to gaps in supplier security management. The incident log is one of the most useful inputs into management review for these reasons.
The biggest mistake organisations make with incident management is treating it as a technical IT process. The legal, contractual and reputational consequences of a serious incident are at least as significant as the technical recovery, and they need to be handled in parallel rather than after the fact.
When I audit incident management I look at the log, the evidence that incidents have been investigated, and the evidence that the management system has actually changed as a result. An organisation with no incidents recorded is more concerning to me than one with twenty - it usually means incidents are happening but not being captured. I also look for evidence that the 72-hour ICO reporting clock is understood by the people who would need to act on it, because that is the timescale that catches people out.
We had a real ransomware scare two years ago. Anti-malware caught it before it spread, but the half-hour while we worked out what was happening was enough to make us rewrite our incident response plan. The new version is much shorter, focused on the first thirty minutes, and pinned to the wall in the IT office where you can actually find it when something happens.
The other change we made was running an annual exercise where we walk through a fictional incident from start to finish. The first one was painful - it found gaps everywhere - but two years on it has made a real difference to how the team handles real events.
Practical Compliance Guidance
The IMS1 manual covers information security incident management as part of the wider issues, actions and improvements process. The same incident log and improvement workflow that handle quality, environmental and health and safety incidents also handle information security incidents, with additional steps where personal data is involved.
The following alphaZ documents support a practical approach to managing information security incidents.
| alphaZ document | How to use it |
|---|---|
| ISO 27001 Toolkit | Full document set for setting up an information security management system, including the incident management policy and supporting forms. |
| P-88 Information Security Incident Management Policy | Policy covering incident definitions, the response sequence, reporting obligations and roles. Used as the reference for how incidents are handled. |
| F-Q10 Significant Problem, Incident, Complaint Form | Form used to log incidents, document containment and investigation steps, and capture the actions taken in response. |
| F-Q16 Improvement Request | Form used to capture the corrective actions and improvements that come out of incident reviews. Links incidents back to changes in the management system. |
| PP-8-100 Information Security Policy Procedure | The master policy that sets out the controls referenced from incident response, including backup, access control and supplier security. |
| ER15 Information Security Risks Register | Register where the risks identified or revised through incident review are recorded and tracked over time. |
Note - all the above files can be downloaded with an alphaZ subscription.
Frequently Asked Questions
UK Legislation
The following UK legislation is directly relevant to information security incident management. Organisations outside the UK should identify the equivalent legislation applicable in their jurisdiction.
