The incidents that do not make the papers

The Incident Response Pan-Europe board at CREST is the unglamorous cousin of the penetration testing accreditation work. The penetration testing world has marketing departments. The incident response world has tired people on conference calls at three in the morning. The board exists to make sure that, when a customer picks up the phone in the middle of an incident, the firm on the other end is one they should still be willing to work with at six in the morning. That is roughly the whole brief.

I have sat on the board since 2023. This is what the work has taught me about the things that do not make it into the published press releases.

The shape of a real incident

Most published case studies of cyber incidents are written for an audience that needs the story to make sense. They have a beginning (the initial access), a middle (the dwell time), and an end (containment, eradication, recovery, lessons learnt). They have a villain — usually a named threat actor — and a hero, who is either the responding firm or the customer's own team.

Real incidents almost never look like that on the inside. They start with someone noticing something off — a service running that should not be, a logon at a strange hour, a finance team query that the finance team did not raise — and they continue, for hours or days, in a fog of partial information. The middle of a real incident is not investigation. It is the slow, frustrating process of working out what you actually have evidence for and what you have been assuming. The end is rarely an end. It is a handover to someone whose job is to live with the consequences for the next twelve months.

A good incident response firm knows the difference between the published story and the lived one. A poor incident response firm sells the lived one as the published one. The board work is, in large part, about being able to tell them apart.

The thing the methodology cannot do

The CREST IR methodology — the documents the accreditation process assesses firms against — is good. It is the result of careful, iterative work by people who have lived through real incidents and have tried, properly, to turn what they have learnt into something teachable. I have contributed to revisions of it. I am happy with where it sits.

The thing it cannot do is encode judgement. The methodology will tell a responder how to triage a compromised endpoint. It will not tell them whether the compromised endpoint is the most important thing in the room, or whether the actual most important thing is the person sitting two desks down from it, whose week is about to be very difficult. That judgement is a property of practitioners. It is built through cases, supervision, peer review, and time.

The board's job, more than anything else, is to make sure the accreditation process is not encouraging firms to optimise for the parts of the work the methodology can encode, at the cost of the parts it cannot. That sounds abstract. In practice it means asking, at every revision, what does this change pressure a firm to do, and is that the thing we want them to do?

What customers should actually want

If you are a board director and your firm has, or is about to have, an incident response retainer, there is a shorter list of questions worth asking your responder than the list the vendor will offer you.

Who picks up the phone when we call out of hours? The answer should be a person, with a name, who has worked at least one real incident in the past quarter. Not a triage line. Not an automated ticket. A person.

When was the last time your team handled an incident in a sector like ours? The answer should be specific. We have done a lot of work in financial services is not specific. We led the response on three cases in the last twelve months for firms in your asset-management bracket, two of which involved business email compromise and one of which was ransomware is specific.

If we ask for the lead responder to be in our office within four hours, can you commit to that? The answer should be either yes, in writing or no, but we can have someone in your office within six and an experienced remote lead within one. Anything vaguer than that is not an answer.

What is your firm's policy on attending the post-incident review with our regulator? The answer should be that the firm will attend, will speak honestly about what happened, and will accept that some of what they say may be uncomfortable for them as well as for the customer. A firm that hedges this is a firm that has not yet sat in a room with the ICO or a sectoral regulator after a serious breach. They will, eventually, and the customer they are sitting next to will discover the hedge at the worst possible time.

Why this is harder than it looks

Incident response is one of the few areas of cyber work where the customer cannot tell whether they are being served well, because they have nothing to compare it to. Most customers will deal with, at most, one or two serious incidents in a decade. By the time they have built the experience to judge whether their responder is good, the relationship is over or no longer relevant.

The accreditation, and the board work behind it, is one of the only mechanisms the customer has to make that judgement on someone else's behalf. That is the whole point of it. It is also why the board work is unfashionable: there is no public glory in making sure the firms you have never heard of are doing the work you cannot see. There is, however, a downstream effect: when the call comes, the customer is served by a profession that has been quietly looked after by people they will never meet.

That is the work. It is unglamorous and slow and matters considerably more than the published version of itself.

One sentence

If you are a customer choosing an IR firm, choose the one whose senior people would still be willing to work with you at six in the morning. That is the test. The board work exists so that the answer to the test is most of them.