MODULE 6 ยท LESSON 3
Free โ no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolThe First Hour
Here is the most important fact in this module, and possibly in the course.
The single largest factor determining how bad an incident becomes is how long the person who first noticed waited before telling somebody. Not the sophistication of the attack, not the security budget, not the tooling. The delay between suspicion and reporting.
People wait because they are embarrassed. They hope it was nothing. They want to check first, or fix it quietly. Attackers depend on that hour, and use it to establish persistence, read mail, and reach further.
If you think you clicked something
In this order, and the order matters.
1. Disconnect the device from the network. Turn off Wi-Fi or unplug the cable. Do not power the machine off, because shutting down can destroy evidence in memory that would help establish what happened.
2. Report it immediately, from a different device. Say what you clicked, roughly when, and what you entered. Use a phone or another machine, since the affected one may be compromised. Nobody competent will blame you, and if they do, that is a problem with your organisation rather than with you.
3. Change the password from a clean device. Not from the affected machine, which may be recording what you type.
4. Revoke all active sessions. The step people miss. Look for "sign out of all devices" or "revoke active sessions" in account security settings. Without this, a stolen session token keeps the attacker signed in regardless of your new password, exactly as Module 3 described.
5. Check the quiet places. This is where persistence lives, and almost nobody looks.
- Mail forwarding rules, including ones that forward and then archive
- Inbox filters that move security alerts or messages mentioning invoices out of sight
- Recovery email addresses and phone numbers you did not add
- Registered authentication devices or passkeys
- Application specific passwords and connected third party applications
Attackers set these up within minutes, precisely so a later password change does not remove them.
Do not delete the suspicious message, because it is evidence. Do not investigate the link yourself on any device. Do not wait to see whether anything bad happens.
If money has moved
Speed changes the outcome here in a way it does not elsewhere, because there are recall mechanisms that work for hours and are useless within days.
Telephone the bank immediately and use the specific words "fraudulent wire, please attempt recall". The phrasing matters because it routes you to the right process faster than describing the situation in general terms.
Report to your national cybercrime or fraud body in parallel, not afterwards. In several jurisdictions rapid reporting materially improves the chance of freezing funds downstream.
Do not wait for internal confirmation that the transaction was fraudulent. A recall attempt on a genuine payment is an inconvenience that can be reversed. A recall attempt made two days late is nothing at all.
Recall that in the Arup case the money was deliberately split across five accounts, which is done specifically to slow this process. None of it was recovered.
The cultural point, which is not soft
Whether your people report quickly is decided long before any incident, by whether they believe they will be punished.
If the last time somebody clicked a phishing link they were named in a meeting, or made an example of in a training session, you have taught every other employee that the safe move is to stay quiet and hope. You have extended the response time of every future incident, and response time is the variable that most determines cost.
So: thank the person who reports. Every time. Including when they were careless, including when it turns out to be nothing, and especially when they are senior enough that admitting it is awkward.
This is not a matter of being pleasant. It is the cheapest available control on incident cost, it requires no budget, and it is undermined by a single badly handled reaction in front of colleagues.
The same principle appeared in Module 2. A plan that requires people never to make mistakes has already failed. Mistakes are certain, so the thing you can actually optimise is how fast you hear about them.
Most of the value in incident response is created before any incident, because under pressure people do what is already easy.
Everyone knows where to report, without looking it up. One address, one number, saved in phones. If finding the reporting route takes ten minutes, you have added ten minutes to every incident.
Someone owns it out of hours. Attacks are deliberately timed for Friday evenings and holidays. A process that only functions on weekday mornings is a process with known gaps that attackers actively exploit.
The five steps are written down somewhere reachable without the network. A printed card or a note in a phone. If your response plan lives only on the file server that ransomware just encrypted, you do not have a plan.
Backups have been restored from, in a test, recently. An untested backup is a belief. The test is the control, and the number of organisations that discover their backups do not restore during an actual ransomware event is not small.
Rehearse once a year, briefly. Walk a plausible scenario through with the people who would actually be involved, including someone from finance and someone who can speak to customers. The purpose is not to produce a document. It is to discover that nobody knows who authorises taking a system offline, which is exactly the question you do not want to resolve for the first time at two in the morning.
Know your reporting obligations in advance. Many jurisdictions impose notification deadlines measured in hours or days for certain categories of breach. Establishing which apply to you while an incident is running is a poor use of the time available.
None of this is expensive. All of it is much cheaper before than during.
An employee realises they entered credentials on a phishing page an hour ago. They have changed their password. What is the most important remaining action?
Time to report
Click to flipThe gap between first suspicion and telling someone. The largest single determinant of how expensive an incident becomes.
Click to flip backThe delay between noticing and reporting is the largest single factor in how expensive an incident becomes, and people delay because they are embarrassed. Disconnect from the network without powering down, report from a clean device, change the password, then revoke every active session and audit the quiet places where persistence lives: forwarding rules, recovery addresses and registered devices. If money has moved, telephone the bank immediately and ask explicitly for a fraudulent wire recall, because that mechanism expires in days. Then thank whoever reported it, every time, because a culture that punishes disclosure has already lengthened its own response to every future incident.