What it is
Round-the-clock incident response for organisations hit by a security breach, or suspecting one.
I take the incident off your hands: contain it so it stops spreading, guide remediation and recovery so the business gets back to normal quickly, collect and preserve forensic evidence properly, hunt through your environment for anything still hiding in it, and report clearly on the scope of the damage.
The first hours decide how bad an incident becomes. Moving fast limits the damage. Moving carelessly destroys the evidence you will need later, for your insurer, your regulator, your customers, or a court.
Approach: steady hands, clear language
Methodical and evidence-driven, never rigid. Real incidents rarely follow a playbook, so these four steps are a guide, not a script.
Listen first
A short conversation to understand what happened, what you are worried about, and what a good outcome looks like for your business.
Stabilise
If there is an active incident, the priority is containment and preserving evidence. If there is not, we agree on scope, timeline, and cost before any work starts.
Investigate and deliver
Methodical, evidence-based work with regular plain-language updates, so you always know where things stand.
Strengthen
Every engagement ends with practical recommendations you can actually implement, prioritised by impact, not by fear.
Who it's for
Any organisation facing an incident, or a suspicion of one. The usual reasons people call:
- Your app, website or database. Access you don't recognise, or an alert nobody can explain
- Ransomware. Files encrypted, systems locked, a ransom note
- Compromised email. A mailbox behaving strangely, invoices redirected, a payment sent to the wrong account
- Data leakage. Company data turning up where it shouldn't, or someone claiming to hold it
- An unexplained security alert. An EDR or SIEM detection nobody can confidently close
- A suspected insider. An employee taking data with them on the way out
- Unusual access. Logins from unfamiliar countries, new MFA devices, mail-forwarding rules nobody created
What you get
- Incident timeline. What happened, in order, with the evidence behind each step
- Scope of the damage. Which accounts, mailboxes, endpoints and data were touched
- Root cause. How the attacker got in, and whether the way in is still open
- Indicators of compromise. To deploy on your security tools, to prevent a repeat
- Prioritised action plan. What to contain, remove and rebuild, in what order
- Executive summary. Written so a non-technical board can decide and act
How it works
Incident response runs as a cycle, not a straight line. Each new finding can send the work back a step, and that is by design, not a delay.
Most businesses reach me somewhere in the middle of the cycle, when something has been found, the incident is spreading, or they realize they were not prepared for it. That is often where the real work begins. I join the cycle where you are and help move the response forward.
| Phase | What happens |
|---|---|
| 1 · Preparation & first response | An immediate triage call: what we know, what to stop touching, what to preserve. You get containment advice on that first call, before any paperwork is finished. |
| 2 · Detection & analysis | Evidence is collected (logs, forensic images, cloud and email audit data) and reconstructed into a timeline. This answers the three questions that matter: what happened, how far it reached, and whether it is still live. |
| 3 · Containment | The attacker loses access. Actions are prioritised and agreed with you first, so nothing takes the business down unnecessarily. |
| 4 · Eradication | Persistence, malicious rules, backdoors and rogue accounts are removed, and the original way in is closed. |
| 5 · Recovery | A controlled return to normal operations, with monitoring in place to confirm the attacker has not come back. |
| 6 · Lessons learned | The final report, plus a walkthrough for both your technical team and your management, with the gaps the incident exposed, ranked by what to fix first. |
What I need from you
It varies from case to case, but in practice it comes down to two things:
- Access to the systems under investigation. The accounts, mailboxes, endpoints or servers in scope, read-only wherever that is enough
- One technical or security person on your side. To carry out preventive actions and to widen my access as the investigation moves
Nothing else is needed to begin. The first call happens before any of this is arranged.
Who does the work
I run the investigation myself. You deal with one person, from the first call to the final report. When an incident needs extra hands or a specific specialism, I bring in professionals I have worked with before, under the same confidentiality terms, and you always know who is touching your systems.
Confidentiality
What you tell me, and what I find, stays between us. Full confidentiality is guaranteed during the engagement and after it, and an NDA can be signed before we discuss any detail of the incident.
Standards the work follows
- NIST SP 800-61r3. Incident response process
- NIST SP 800-86. Forensic techniques within incident response
- ISO/IEC 27037. Identification, collection and preservation of digital evidence
- MITRE ATT&CK. Describing attacker behaviour
After the incident
Most engagements end with a short list of gaps the incident exposed. Closing them, whether hardening, a compromise assessment across the rest of the environment, ongoing threat hunting, or training for the team, is available as follow-on work, never as a condition of the investigation.