Every organisation will, at some point, face some sort of cyber security incident. Not every organisation will face a breach that makes the news, but it should be stated that the once-held assumption of “we’re too small to be a target” has been disproven countless times.
Attackers automate their scanning, phishing and access brokering, which means smaller organisations with weaker controls are targeted as readily as large enterprises.
This is why the question of What Is Incident Response In Cyber Security? And as an implemented procedure and plan, is a vital aspect of cyber security that should be considered no matter the size of your company.
Incident Response in cyber security is the discipline of triaging, containing, investigating and recovering from these events. That definition is straight-forward. What separates organisations that recover quickly from those that suffer weeks of disruption is not always the definition. It is preparation, and what happens in the first hour.
Incident Response is the centre of security, not an afterthought
There is a useful test for any IT or security activity: ask why you are doing it. Almost every answer resolves to one of two things. You are either improving a service, or you are preventing an incident.
- Patching fixes vulnerabilities in your systems to prevent exploitation.
- Classifying documents can give control over your information and can prevent a leak of confidential data.
- Access controls limit what an attacker, or a careless insider, can reach.
- Backups exist so an incident does not become a prolonged outage.
Viewed this way, Incident Response is not a bolt-on process that sits in a drawer until something goes wrong. It is the organising principle that most of your security policies should be built around. If a control does not make an incident less likely or less damaging, it is worth asking what it is for.
Prevention deserves investment, but it should not absorb all of it. Assume that despite good controls, an incident will still occur and put comparable effort into how you will act when it does.
The first hour: who, what, where, when
Responders often talk about the ‘golden hour’. The decisions made in the first sixty minutes of an incident shape everything that follows: whether the attacker retains access, whether evidence survives, whether recovery takes days or months.
The immediate priority is information. You don’t want to turn a false positive or less severe incident into something that affects your whole business. So, before anyone starts pulling cables or wiping machines, the responder needs answers to a short set of questions:
- Who discovered the issue, and who has been affected?
- What systems, accounts or data are involved?
- Where is the activity occurring, on premises, in cloud services, or both?
- When did it start, and how do you know?
Aviation has used a similar discipline for nearly a century: aviate, navigate, communicate. Keep the aircraft flying, work out where you are, then tell people what is happening, in that order. The parallel for a cyber incident is direct. Stabilise the situation so it cannot get worse, establish the facts, then communicate to stakeholders, regulators and insurers with accurate information rather than guesses.
There are also a few practical rules that consistently save incidents from getting worse:
- Presume the attacker may be able to see your communications. If your email, phone system or collaboration tools sit in the environment under attack, do not use them to coordinate the response or to contact your Incident Response provider. It is common for attackers to monitor a victim’s inboxes and calls to follow the progress of the response. Call from a mobile, not the company switchboard, and avoid emailing responders from the affected domain. Here at Prism Infosec, we will work with you to setup OOB (Out Of Bounds) contact methods.
- Isolate, do not destroy. Disconnect affected machines from the network rather than powering them off or rebuilding them. Memory and disk contents are evidence, and wiping a machine can erase the only record of how the attacker got in.
- Write everything down. A simple timeline of what was seen, when, and what actions were taken becomes invaluable to responders, regulators and insurers alike.
None of this needs to be complex. A plan that fits on one page that everyone can find and follow under pressure, beats a fifty-page document nobody has read.
Prism Infosec’s retainer clients receive a battle card for exactly this reason: a concise reference that tells whoever picks up the phone at 2am what to gather, who to call, and how to call them safely.
Preparation: the worst time to write a plan is during an incident
If your organisation does not have a Cyber Incident Response plan or a Disaster Recovery plan, consider this your reminder. The most difficult moment to start writing an IR plan is when systems are down and senior stakeholders are expecting answers.
Several areas consistently determine how well a response goes:
- Backups, verified. It is not enough to run backups; their integrity must be tested by restoring to a real system. Responders regularly encounter backups that look healthy but do not boot, or processes that have depended on one individual and one set of credentials for a decade. If that person leaves, so does your recovery capability.
- Log retention. Many organisations discover mid-incident that they hold only 30 days of logs, while the initial access occurred 60 days earlier. Centralised logging with adequate retention is one of the cheapest investments you can make in future investigations.
- Playbooks for likely scenarios. Think through what could realistically happen, then think about what you have not thought of. You do not have to imagine every scenario from scratch. The best-prepared organisations learn from other people’s incidents, using published breach analyses and guidance from organisations such as the National Cyber Security Centre (NCSC) to test their own assumptions.
Regulators and insurers: know the rules before you need them
Two external parties shape a serious incident, and both reward preparation.
If personal data is involved, UK GDPR requires notifiable breaches to be reported to the Information Commissioner’s Office within 72 hours of becoming aware. That deadline arrives quickly during an incident, so the process for assessing and reporting should be defined in advance, including who makes the call.
Many organisations also hold cyber insurance, and fewer have read the Incident Response conditions in their policy. Insurers frequently specify approved responders, notification windows and evidence requirements. Acting outside those terms, however well-intentioned, can put a claim at risk. Know what your insurer expects before an incident, and build it into your plan.
Evidence handling and why NCSC assurance matters
Everything above eventually converges on evidence. The ICO will want to know what data was affected and how you established that. Your insurer will want a defensible account of the incident before settling a claim. If law enforcement becomes involved, the integrity of that evidence matters even more. An investigation built on assumptions, or on systems that were wiped during hurried remediation, satisfies none of them.
Proper evidence handling means capturing forensic data before remediation destroys it, maintaining a chain of custody, and documenting findings in a way that withstands scrutiny months later. It is a discipline in its own right, and it is one of the main reasons the National Cyber Security Centre recommends that UK organisations of every size use an assured provider when responding to an incident.
Prism Infosec is an NCSC Assured Provider under the Cyber Incident Response (CIR) scheme, which independently verifies that our investigation quality, evidence handling and governance meet the NCSC’s standards. For clients, that assurance means findings that stand up to regulators, insurers and, where necessary, the courts, rather than findings that cannot be relied upon.
Speed comes from readiness
The organisations that handle incidents well are rarely the ones with the biggest budgets. They are the ones that prepared: a tested plan, verified backups, adequate logging, and a trusted responder already familiar with their environment.
An incident response retainer with a 24/7 emergency line removes the single biggest delay in most incidents, which is finding qualified help. It also allows responders to invest in readiness before anything goes wrong. At Prism Infosec, that includes internal tooling built by our own responders to accelerate the first hour, cross-referencing affected users and systems against known-good baselines and surfacing indicators of compromise in minutes rather than hours. Technology does not replace responders, but it should let them make good decisions faster.
Conclusion
In answer to What Is Incident Response In Cyber Security?
Simply put, Incident response is not a document, a product or a compliance exercise. It is the ability to act with confidence and composure when something goes wrong, and that ability is built long before the incident starts.
If you are dealing with an incident right now, contact Prism Infosec’s incident response team directly, and do so from a device outside the affected environment, such as a mobile phone rather than your switchboard or company email. Our responders will help you stabilise the situation, preserve evidence and recover safely.
If you are not, this is the best time to act. Prism Infosec supports organisations in preparing for, responding to and recovering from cyber incidents, through NCSC-assured incident response, retainers with a 24/7 emergency line, penetration testing and readiness exercising. If you would like an informed view of how prepared your organisation is, we would be glad to talk.
Image Source: Envato