The first 24 hours after an incident

When do the 24 hours actually start?

From the moment the incident is detected, not from when the company understands what happened. That is the whole problem with this deadline. The moment someone tells you “I can’t log in to the warehouse system and the files on the shared drive have been renamed”, the clock starts, even though nobody yet knows whether it is an attack, a backup failure or an administrator’s mistake.

The initial report does not call for an investigation. It contains the organisation’s identification details and basic information about the incident, in other words what you know at that point. Which further deadlines then apply, and which incidents have to be reported at all, is covered in the article on the Cyber Security Act, because the scope of the obligation differs by regime.

What has to be decided in advance?

Five things, and none of them can be worked out on the day they are needed. They are decided while things are calm, because otherwise the first hour is spent improvising over who has the authority to do what:

• Who sends the report, and who sends it when that person is on holiday.
• Where they get the details of the affected system from, in other words whether an asset map exists.
• Who may decide to disconnect a system from the network, even if that stops operations.
• Who talks to customers and the media, and what is said while the facts are still unknown.
• Where the timeline is recorded, because both the authority and the insurer will want to see it.

This is also the answer to the question of why security cannot be bought as a product. Most of these decisions are organisational, not technical, and they have to be made by management, not by a supplier.

Why is detection harder than reporting?

Because the deadline runs from detection, but nowhere does it say that detection will be quick. A company without monitoring usually learns of an incident when something stops working, or when someone from outside gets in touch. Until then the attacker is in the environment, nobody knows about it, and formally the deadline is not yet running.

The practical consequence is uncomfortable: a company that monitors nothing can formally meet the deadlines and still be in a worse position than one that discovered the incident on the second day and reported it late. That is why it makes sense to sort out monitoring before the report template.

What should you do in the first hours, and what should you not do?

Stop the spread, preserve the evidence and write down what happened when. Isolating the affected machine is usually the right first step, but switching it off and reinstalling it is the most common expensive mistake: it also wipes out what could have shown how the attacker got in and everywhere they reached.

The second mistake is silence inside the company. People who do not know there is an incident carry on as normal: they forward files, restore from backup and change passwords in places the attacker is watching. Informing them therefore comes before writing a press release.

What do you only find out about backups on a bad day?

That existing is not enough. With ransomware, what matters is whether the backup dates from before the compromise, whether it was out of the attacker’s reach with the same access as the rest of the network, and how long it takes to restore the whole operation, not a single file. The answer to the last question is usually the uncomfortable one: restores are tested on one document, whereas in a crisis it is dozens of systems at once.

That is why business continuity and recovery plans are documents written in advance and tested from time to time. Without a test they are a wish list: they say that operations will be restored, but nobody knows how long it will take or in what order, and it is the order that decides whether, after two days, the company is shipping goods or just reading emails.

Who does all this if you don’t have a security role?

Either one of your own people, or an external role agreed in advance. Part of the ICT services offering is setting up a procedure for an attack, so there is no improvising when it happens, and an IT check establishes beforehand whether the company is ready for an attack. Securent adds incident investigation, communication with NÚKIB (the Czech national cyber security authority) and business continuity and recovery plans.

Whoever does it, one thing holds: the obligation to report lies with the organisation. A supplier can prepare the material and lead or support the communication, but the obligation remains yours. This also gives you the one test of whether your procedure is really ready: walk through it as a dry run on a day when nothing is happening.