Service 03
Incident
response
Support when something has already gone wrong — and the preparation beforehand that decides how badly it goes.
If you are dealing with a live incident right now: isolate affected systems from the network rather than powering them off, stop deleting or rebuilding anything, preserve logs before they rotate, and email [email protected] with what you are seeing. Powering off a host destroys memory evidence; rebuilding it destroys the record of how far the attacker got.
In short
Incident response is the coordinated process of detecting, containing, eradicating and recovering from a security incident while preserving the evidence needed to understand it. The decisions taken in the first few hours — particularly around containment and evidence preservation — usually determine both the total damage and whether you can later prove what did and did not happen.
Responding to a live incident
We work to the lifecycle set out in NIST SP 800-61: preparation, detection and analysis, containment, eradication and recovery, and post-incident activity. In practice an engagement moves through the following.
Triage and scoping
Establishing what is actually happening, which systems are affected, whether the attacker still has access, and what data may be involved. This is also where the regulatory clock is assessed — under UK and EU GDPR, a notifiable personal data breach must reach the supervisory authority within 72 hours of becoming aware of it, and that clock does not wait for you to finish investigating.
Containment
Cutting off attacker access without destroying the evidence needed to understand the intrusion, and without taking down more of the business than the incident itself would. Containment is a business decision as much as a technical one, so it is made with you, explicitly, and recorded.
Eradication and recovery
Removing persistence, closing the entry route, rotating credentials and secrets that may have been exposed, and restoring service in a controlled order. Recovery before eradication is the classic way to be compromised twice by the same attacker in the same month.
Post-incident review
A written account of what happened, how, over what timeline, and what would have prevented or shortened it. Written to be useful rather than to assign blame — an incident review that people are afraid of is an incident review that gets sanitised.
Readiness — the part that actually decides the outcome
Most of the difference between a contained incident and a catastrophic one is decided before it starts. Readiness work covers:
- Incident response plans and playbooks for the scenarios you are realistically exposed to — ransomware, business email compromise, credential theft, third-party breach, insider misuse.
- Logging and forensic readiness: confirming that the sources an investigation needs are being collected, retained long enough to be useful, and stored somewhere an attacker with domain access cannot simply delete.
- Tabletop exercises that put your actual decision-makers through a realistic scenario, including the awkward questions — who talks to customers, who can authorise taking a revenue system offline, who calls the insurer.
- Backup and recovery validation: proving that backups restore, that they are isolated from the network they protect, and that recovery time matches what the business assumes.
- Retainer arrangements so that when something happens, the contract, the scoping and the authorisation are already in place instead of being negotiated during the worst week of your year.
Our incident response playbook guide sets out the first-hour checklist, severity definitions and containment decision points in full.
What you receive
What an incident response engagement delivers depends on what happened and how far it got. A typical engagement produces the following.
- Direct response support working alongside your team, with a clear split of who is doing what.
- An incident timeline reconstructing what happened and when, based on evidence rather than assumption.
- An impact assessment covering systems, accounts and data — the input your legal and privacy advisers need for notification decisions.
- Containment and recovery guidance issued as the incident develops, not after it.
- A post-incident report with root cause and prioritised recommendations, suitable for sharing with a board, an insurer or a regulator.
We provide technical incident response. We are not a law firm and do not give legal advice: decisions about regulatory notification, contractual disclosure and law-enforcement engagement should be taken with your legal advisers, and we will give them the technical facts they need to make those decisions properly.
Coordinating with your SOC before we test
Any engagement that involves simulated attack activity — ransomware-protection validation on a storage cluster, endpoint detection efficacy testing, Active Directory attack-path assessment — is pre-notified to your security operations team under a written coordination protocol. We disclose the tooling, the benign test files and the source ranges in advance, and agree a channel for the duration of testing.
The purpose is twofold. Your detection team can distinguish the exercise from a real event, so the test does not trigger an incident it was not meant to. And the record of what was detected, what was blocked and what passed silently becomes a direct input to your incident response plan: a list of techniques your monitoring saw, and a list it did not. Both are reported, with the evidence to act on either.
Questions we are asked
What should we do in the first hour of a suspected breach?
Six things, in this order. Assign one person to coordinate so decisions are not made in parallel by three people. Isolate affected systems from the network — disconnect or block at the switch or firewall rather than powering off, which destroys memory evidence. Preserve logs immediately, before rotation deletes them. Do not rebuild, reimage or wipe anything. Move incident communications to a channel the attacker cannot read, since email and chat may be compromised. Then start a written timeline, recording what you observe and every action you take, with timestamps.
Should we pay a ransomware demand?
That decision belongs to you with your legal advisers and, where relevant, your insurer and law enforcement — it carries legal and sanctions implications that vary by jurisdiction and by who the attacker is. What we can tell you is technical: whether viable backups exist, whether restoration is realistic in the time available, what the attacker actually accessed, and whether paying would even resolve the situation. UK law enforcement guidance is consistently against payment, and payment does not reliably result in usable decryption or in stolen data being deleted.
How quickly can you respond?
For organisations on a retainer, response begins within the response time written into the retainer, because the contract, authorisation and scoping are already agreed. Without a retainer we can still help, but the first hours go into paperwork rather than investigation, which is exactly the time you cannot afford to spend that way. If you are considering a retainer, the point of one is to remove that delay.
Do we have to report the incident?
Possibly, and quickly. Under UK and EU GDPR, a personal data breach likely to result in a risk to individuals must be reported to the supervisory authority — the ICO in the UK — within 72 hours of becoming aware of it, with notification to affected individuals required where the risk is high. Sector rules may impose their own obligations, and contracts frequently require customer notification on shorter timescales than the law does. The legal determination is for your advisers; our role is to establish the technical facts fast enough for that determination to be made inside the deadline.
Can you work with our existing IT provider or MSP?
Yes, and usually we should. Your provider knows the estate and holds the access needed to act quickly; we bring the investigative work and an independent view of what happened. The one thing worth being explicit about up front is that where the provider's own systems or processes may be part of the incident, the investigation needs to remain independent of them — which is a reason to have an outside responder rather than an obstacle to using one.
Next step
Talk to a security consultant
Tell us what you are building, defending or certifying. We will tell you plainly what we would test first, what it takes, and whether you need us at all.