Proactive engagement / 02

Cybersecurity Incident Readiness.

What an organization needs to do the right things when an incident hits: contain fast, put resources where they matter, and avoid the costly missteps.

Readiness is not a document. It is whether the people who will be woken at three in the morning know what to do, have the authority to do it, and have practiced it. A plan that satisfies an auditor and a plan that works under pressure are rarely the same plan.

This service builds the response framework and then puts it under load. Plans and handling guides are written against your actual threat landscape and your existing documentation, not fitted to a template. Exercises follow, because a procedure nobody has run is an assumption rather than a capability.

All of it is shaped by hundreds of real incidents. The scenarios apply the pressure you will actually face, not the pressure a template imagines.

REQUEST AN ENGAGEMENT → See all solutions

4 weeks Incident response plan, kick-off to final

4-5 weeks Incident handling guides, kick-off to final

2-3 weeks Table-top exercise, kick-off to report

2-4 weeks DFIR functional exercise, kick-off to report

Those weeks are elapsed time from kick-off to the final deliverable, including your own review cycles, and they assume a scope agreed at kick-off. They are not the effort billed, which is a smaller number and is quoted separately.

[ WHAT READINESS ACTUALLY REQUIRES ]

Three things, and a document is only one of them.

An organization responds well when three conditions hold at once, at three in the morning, under pressure, with incomplete information. Most incident response programs satisfy the first, assume the second, and have never tested the third. The gap between them is where a response goes wrong, and it is not a gap a plan can close on its own.

A

They know what to do

A plan that covers identification, containment, eradication and recovery, and handling guides for the specific incident types you are most likely to face. Written so a responder follows a known path under pressure rather than improvising the basics.

How it fails

The plan exists, is current, and is written at a level of generality nobody can act on at two in the morning.

B

They have the authority

Who can take a production system offline, who talks to the regulator, who signs off on paying or not paying. Named, agreed in advance, and written down with the escalation path that reaches them out of hours.

How it fails

The responder knows exactly what needs doing and spends four hours finding someone willing to approve it.

C

They have practiced it

A table-top exercise for decision-making and coordination, or a DFIR functional exercise that puts the team against real technical work. Either one turns the plan from a document into something the team has actually done once before.

How it fails

The first time the plan is executed is during the incident it was written for, which is the most expensive possible rehearsal.

What gets built

Four components, every one available on its own.

Any one of them can be commissioned alone, and any combination of them together. Engagements are assembled around the question in front of you rather than sold as a package, which is the point: you buy the part you actually need.

01

Incident response plan

The overarching document. It governs how the organization mobilizes, prioritizes and collaborates during a major incident, so business processes come back quickly and in a coordinated way rather than through parallel improvisation. It covers containment, analysis that will hold up if legal proceedings follow, and the interfaces to recovery teams and the rest of the business.

Built on what you already have: your SLAs, what the tools in place can actually do, the external services under contract, and the teams and responsibilities as they really are. It also settles what not to mobilize, because an incident that pulls in every team at once burns the people you will need in week three.

02

Incident handling guides

Written so the SOC can handle the attacks that would hurt most, and so a first responder can take the right actions in the first minutes. For the SOC that means playbooks for threats against critical identity infrastructure and the business applications that matter.

Where the first responders are not dedicated security staff, the guides get them to collect the right logs, reach and coordinate with the right people, and avoid the mistakes that tip off an adversary or destroy evidence you will need later. Personalized to the skills, tools and processes actually in place, and the number of guides is a scoping decision rather than a fixed package.

03

Table-top exercise

A test of how the team actually works with the plan. An IR plan is a guide rather than a recipe, so the exercise hunts for the gaps and loose ends that would produce a late or wrong action at the moments where it costs most.

The session is only part of it. Preparation reviews your full IR documentation, including use case coverage of the threats that matter and how past incidents were really handled, so the findings rest on the whole process and not on two or three hours in a room. Technical teams and executives are exercised separately, because they fail in different ways.

04

DFIR functional exercise

An assessment that raises the team's skill level rather than only recording it. Scoped from your current threat landscape, your past incidents and what the team is struggling with now, then aimed at the SOC L3 or IR team, with scenarios covering how threat actors really operate and what traces they leave behind.

You keep more than a performance report and a list of gaps. The team also gets guidelines and cheatsheets for recognising attack patterns faster and for choosing log sources knowingly, by their verbosity, reliability and limitations. A table-top tells you whether the team would decide well; this tells you whether they can do the work.

How an engagement runs

Four tracks, not one sequence.

Read each row left to right. All four tracks are independent, so an engagement can be any one of them, or a document followed by an exercise once there is something worth exercising.

Every component can be commissioned on its own. The plan and the guides follow the same four steps, so they run well together, but neither depends on the other. An exercise can be run against a plan you already have, and whether that plan is solid enough to be worth exercising is established before you spend money on the exercise.

What you receive

Written to be used at three in the morning.

Not one of them is written to be filed. Every deliverable is walked through with the team that will own it, because documentation nobody has been talked through is documentation nobody uses.

Incident response plan From the plan engagement. A single controlling document: severity definitions, roles and escalation paths, decision points, and the interfaces to recovery and the wider business.

Incident handling guides From the guides engagement. One guide per incident type in scope, each a step-by-step path from detection through containment, eradication and recovery.

Exercise report and action plan From either exercise. Objectives, scenario, participants, key observations and findings, with an actionable plan for the gaps exposed. The gaps are the product, so they are not softened.

Performance analysis From either exercise. How the team responded, where its strengths are, and which skills and processes to develop next. Written about the team, for the team, and not as a scorecard for anyone else.

Guidelines and cheatsheets From the DFIR functional exercise. Reference material the team keeps: how to recognize attack patterns faster, and how to choose log sources knowingly, by their verbosity, reliability and limitations.

Who this is for

Where the call usually comes from.

Untested plan Organizations with a response plan nobody has tested, or with none at all.

Changed organization Teams that have grown or reorganized since the plan was written, so the names in it no longer hold.

Board assurance Boards that need to know the organization can respond, not just that a document exists.

Regulatory expectation Security functions facing regulatory expectations on incident response capability.

What is needed to scope it

Five answers and the work is priced.

Size The size of the organization, as a number of employees.

Playbooks Whether handling guides are in scope, and roughly how many.

Type of exercise Table-top or DFIR functional, and whether the audience is technical or management.

Participants How many people will take part, and in which roles.

Objectives The three most important things you want the exercise to establish.

Readiness is easiest to judge from the outside. Send the plan you have today and the review states where it would break.

REQUEST AN ENGAGEMENT → Two-page brief (PDF)

The method, in the open

What a functional exercise actually tests.

Evidence of execution Proving a program ran on Windows, source by source. In a functional exercise this is the work the team has to do under time pressure, and it is where the gap between knowing and doing shows.

Anti-forensics What file timestamps mean, and where a tool that wrote them leaves a mark the file system would not. Scenarios include an adversary who tried to clean up.

Linux estates Reading Linux timestamps, because an exercise that only covers Windows rehearses half the estate.

NEXT / WHEN IT IS REAL

Digital Forensics and Incident Response

The plan you rehearsed, executed by the people who wrote the exercise.

NEXT / SCOPING

Engage

Describe the situation. The call is with the consultant who would run the assessment, not a salesperson.