When something happens · 4.6

What changes afterwards, and what should

What changes afterwards, and what should. What it costs, who decides, and what usually goes wrong.

For an independent reference point, see CISA StopRansomware guidance.

The review

Blameless, and within a fortnight

While people remember, and before the account has settled into a story. The purpose is to find what made the event possible and what delayed the response, not to identify who clicked.

Where the review produces a person rather than a process, it has usually stopped early. The person clicked because the message was convincing, or transferred the file because the compliant route was slower, and those are the findings that can be acted on.

What usually changes

Process more often than technology

The recurring outcomes are unglamorous: the contact list was wrong, the decision-maker was unreachable, logs from one system were not retained, nobody had the certificate, the machine was reimaged before anybody thought about evidence.

Each is fixed with an afternoon and none is fixed by a purchase, which is worth stating on a vendor's website.

Feeding it back

The incident is evidence

The standard requires an incident response capability, and an assessor may ask how you know yours works. A documented incident, with a timeline, a decision record, a report and a review, is the strongest possible answer.

Which means the paperwork produced during a bad week has value afterwards, provided it was kept.

Rests on

The incident response family of the NIST publication, which requires an operational capability including preparation, detection, analysis, containment, recovery and user response activities, and testing of it.

How a given organisation demonstrates that capability is a matter for it and its assessor.

Over-correction

The control that makes work impossible

The strongest impulse after an incident is to prevent that exact thing forever, and the resulting control is frequently disproportionate: a route blocked entirely with nothing put in its place.

Within a month somebody has found another way and the organisation is worse off than before, because the new way is undocumented. The entry on the operator's view sets out the alternative.

Telling the board

Once, properly

What happened, what it cost, what has changed, and what remains open with a date. One page, at the next meeting, not a standing item that runs for six months.

A standing item invites monthly reassurance-seeking and prevents the matter being closed, which is bad for the programme and for the person running it.

What to keep

The file

The timeline, the decision record, the report submitted, the correspondence with the customer, the forensic output, the review and the actions with their completion dates.

Retained for the period the clause requires at minimum, and in practice longer, because the questions arrive later than the retention period assumes.

The last point

Most incidents are not attacks

Across this sector the majority of reportable events involve error, misdirection and loss rather than a sophisticated intrusion. That is not a reason to relax; it is a reason to put effort where the events actually are, which is in ordinary processes used by ordinary people under time pressure.

Which is where most of this blog has been pointing.

Also

Elsewhere in when something happens