Overview
Response runs in the order that protects you: preserve evidence before it ages out, contain without destroying the artefacts needed to understand what happened, then investigate to a defensible scope determination. Acting in the wrong order is the most common and most costly mistake, rebuilding the compromised machine first destroys the only record of how they got in.
The investigation reconstructs a timeline from disk, memory, application and cloud artefacts: initial access, what was executed, which identities were used, what was accessed, and whether data left. That timeline is what your legal, regulatory and communications decisions rest on, so it is written to survive external scrutiny.
Engagement at a glance
- Response
- Engagement can begin the same day for an active incident
- Evidence
- Disk imaging, memory capture, log and cloud artefact preservation
- Standards
- NIST SP 800-61 response lifecycle; forensically sound chain of custody
- Scope question
- What was accessed, what was exfiltrated, whether access persists
- Deliverable
- Timeline, scope determination, root cause and a regulator-ready report
- Aftercare
- Remediation validation and hardening recommendations
What is covered
Every item below is tested and recorded, so the report shows what held as clearly as what failed.
- Incident triage and containment guidance
- Forensically sound disk imaging
- Memory acquisition and analysis
- Log preservation and normalisation
- Cloud and SaaS audit artefact collection
- Timeline reconstruction
- Initial access and root cause determination
- Lateral movement and blast-radius mapping
- Data access and exfiltration assessment
- Persistence identification and eviction validation
- Deleted file and artefact recovery
- Regulator and insurer-ready reporting
Test matrix
What is attempted in each class, and what it means when it works.
| Class | What is attempted | Typical impact |
|---|---|---|
| Initial access | Entry vector established from artefacts rather than assumed | Root cause you can fix instead of guess at |
| Timeline | Disk, memory, application and identity artefacts correlated into one sequence | A defensible account of what happened and when |
| Blast radius | Every system and identity the adversary touched, including those that raised nothing | Scope determination that holds up under regulatory review |
| Data exposure | What was accessed versus what was transferred out | The evidence your notification decision depends on |
| Persistence | All mechanisms established, validated as removed after remediation | Confidence that eviction is complete |
| Chain of custody | Evidence handled to a standard that survives challenge | Findings usable in regulatory, insurance or legal proceedings |
What we commonly find
Access older than anyone thought
The intrusion routinely predates the alert by weeks or months. The alert was the adversary getting careless, not the adversary arriving.
Accessed is not exfiltrated
The distinction drives the notification decision and the cost that follows it, and it can only be settled by evidence.
Evidence destroyed by the response
Machines rebuilt and logs rotated before capture, because containment ran ahead of preservation. This is the single most common avoidable problem.
Eviction that missed one path
Remediation that removed the implant but left a scheduled task, a cloud role or an OAuth grant that reinstates access.
How the engagement runs
Scoping and threat modelling
Map the asset, the attacker profile, and what “compromised” actually means for this business. Rules of engagement, testing windows, excluded techniques and an escalation contact are agreed in writing before anything is sent.
Reconnaissance and surface mapping
Enumerate everything reachable: subdomains from multiple passive sources, every endpoint referenced in JavaScript bundles, exposed services, third-party integrations, and the assets nobody remembers deploying. Coverage is recorded per host, so what was not tested is as visible as what was.
Manual exploitation
Authenticated testing from every role, with at least two accounts per role. Business logic, authorisation boundaries, injection, race conditions and state transitions, with each candidate reproduced live before it is written down. Automated tooling contributes coverage; it never contributes findings.
Verification and impact
Every finding is reproduced in a fresh session, isolated to the single parameter that causes it, and pushed to its maximum realistic impact. A finding that cannot survive a clean-room reproduction does not appear in the report.
Reporting and retest
The report is written twice over: once for the engineer who has to fix it, once for the auditor who has to file it. A walkthrough session follows, then a retest of every finding, closed only when re-exploitation fails.
What you receive
Executive summary
One page for the people who approve budget: what was tested, what was found, what it means in business terms.
Technical findings
Each finding with severity, CVSS, affected component, full request and response, reproduction steps and a working proof of concept.
Attack chains
Where findings combine, the chain is written out end to end, from first request to demonstrated impact.
Remediation guidance
A specific fix for your stack and framework, with the corrected pattern, not a link to a generic reference page.
Audit mapping
Findings mapped to SOC 2, ISO 27001, PCI DSS, HIPAA and OWASP ASVS as applicable, so the report drops straight into an audit pack.
Retest and attestation
Every finding retested in a clean session after remediation, with a signed attestation letter for customers and auditors.
When to run it
- Immediately, when an incident is suspected before rebuilding anything.
- When an insurer or regulator requires an independent investigation.
- After containment, to confirm that eviction was complete.
- Retrospectively, when a previously closed incident shows signs of recurring.
Questions
How fast can you start?
For an active incident, the same day. The first call covers immediate containment guidance and, most importantly, what not to do, because the most common way evidence is lost is a well-intentioned rebuild in the first hour.
Should we shut the affected systems down?
Usually not before memory is captured. Powering off destroys memory-resident evidence that frequently holds the encryption keys, the C2 configuration and the running process tree. Isolate from the network instead, and call before you rebuild anything.
Will the report satisfy our regulator or insurer?
It is written for that audience: methodology, evidence handling, timeline, scope determination and root cause, with the reasoning shown so a third party can follow it. We also state clearly where evidence was unavailable and what that means for confidence, a report that claims certainty it cannot support is worse than useless in a regulatory process.
Can you tell us whether data was stolen?
Where the evidence supports an answer, yes, and it is given with a confidence level. Where telemetry did not exist to record it, we say that plainly rather than inferring. That honesty is what makes the rest of the report defensible.
How much does incident response cost?
Active incidents are scoped fast and priced on the evidence volume and the systems involved. The first call, covering immediate containment guidance and what not to do, happens before commercial terms are settled, because evidence is lost in the first hour and not in the first invoice.
Do you offer an incident response retainer?
Yes. A retainer buys a guaranteed response time and, more usefully, a team that already knows your estate. The most expensive hours of any incident are the ones spent explaining your architecture to someone who has never seen it.
Is your evidence handling forensically sound?
Yes. Acquisition follows documented chain of custody, images are hashed on acquisition and verified before analysis, and the report records every step so the findings survive scrutiny from a regulator, an insurer or a court.
Can you support a cyber insurance claim?
Yes. Insurers ask for scope of compromise, initial access vector, dwell time, data affected and remediation performed. The report is structured to answer all five with evidence, which is what turns a claim into a settlement rather than a dispute.
Do you handle insider incidents and employee investigations?
Yes, with the handling that kind of matter requires. Scope, authorisation and confidentiality are agreed in writing with counsel or HR before work starts, and findings are reported to the named recipients only.