Phishing
A phishing attack is an attempt to impersonate a trusted entity to trick users into revealing credentials, clicking malicious links, or downloading malware. Phishing doesn't require sophisticated exploits. It requires one convincing email, one distracted moment, and one click. And when your product serves thousands of users whose financial data sits behind the login screen you built, that reality hits differently.
A successful phishing attack can lead to attackers harvest credentials through fake login pages, abuse OAuth token grants, create email forwarding rules to maintain persistence. So when I worked on a structured phishing incident response playbook recently, a lot of it resonated in ways I didn't expect. Here's what stood out through the lens of someone who builds the products these attacks target.
Incident response is an engineering discipline
Responding to a phishing attack has phases, targets, roles, and metrics. The four response phases: Detection, Containment, Eradication, and Recovery, map to a logical sequence that any engineer would recognize: identify the problem, stop it spreading, remove it completely, and restore normal operations. The rigor involved isn't softer than engineering. It's comparable, and in some ways stricter.
Phase 1
Detection is the phase that determines everything else, the target is under one hour from first report. That window sounds aggressive until you understand that every additional hour is an hour an attacker could be active in your environment, reading emails, exfiltrating data, creating backdoors, and escalating privileges. Detection isn't just tooling, it's culture. Users who don't report suspicious emails because they're embarrassed, unsure, or just busy are a detection gap no SIEM can close.
Phase 2
Containment is where technical precision matters most, quarantine the phishing email from all mailboxes. Block malicious domains at firewall and DNS level. Isolate affected devices from the network, but do not power them off, because you need forensic evidence. Force password resets, revoke session tokens, and enable MFA. Every one of these steps has a reason, an order, and a failure mode if done wrong.
Phase 3
Eradication is not deletion. wiping files isn't eradication. Forensic analysis on compromised devices, revoking OAuth tokens the attacker may have granted themselves, removing attacker-created scheduled tasks or startup programs, and verifying all backdoors are closed. Eradication is only complete when a forensic review confirms no attacker presence remains. The standard is confirmation, not assumption.
Phase 4
Recovery has legal dimensions engineers don't usually think about, rebuilding from clean backups, monitoring closely for 48–72 hours post-reconnection, and if customer data was exposed, mandatory breach notification to NITDA within 72 hours under Nigeria's NDPR. That's not a best practice, it's a legal requirement. Understanding the compliance layer of incident response is part of operating in this field.
The Part That Reframed How I Think About Cyber Security Work
The playbook has an entire section on communication strategy, who talks to whom, when, through which channel, and with what content. And reading it shifted something for me.
From the outside, one would think cyber security is a deeply technical, largely internal discipline. What I found is that a live incident creates simultaneous pressure across technical, organisational, and legal dimensions at the same time. Poor communication during an incident isn't a soft failure, it's a measurable one. Users who don't get clear instructions amplify the attack, management without accurate information makes escalation decisions on bad data, premature external statements create legal exposure.
The communication framework is structured the way good engineering is structured: defined roles, defined outputs, defined timelines. Affected users within one hour, all staff within two to four hours, senior leadership immediately for serious incidents, customers and regulators within 72 hours if data was compromised.
One rule: never speculate, only communicate confirmed facts.
Metrics: The Part That Felt Most Familiar
Engineers are measurement-native. We track performance budgets, error rates, deployment frequency, time to first byte. Security incident response has its own equivalent set of numbers.
Mean Time to Detect: target under 1 hour
Mean Time to Respond: under 2 hours
Mean Time to Contain: under 24 hours
Mean Time to Recover: under 72 hours
These four metrics define response quality in the same way performance metrics define product quality. You measure them after every incident, you act on what they reveal, and you improve.
There's also the phishing click rate and report rate across your organisation. A low click rate and high report rate means your security culture is working. Those numbers don't improve by accident, they improve through training, tooling, and communication. At gomoney, I built internal tools used by customer support and operational teams, the usability of those tools affects how fast people act when something goes wrong. Security outcomes have a UX dependency. That's a bridge I understand how to cross.
Conclusion
In conclusion, understanding how security incidents are detected, contained, and recovered from makes you a better engineer, not because you'll be running the forensics, but because you'll build with that reality in mind. I look forward to working on other playbooks and exploring how other forms of cyber attacks are detected, contained, eradicated, and recovered.
Here is the link to the phishing playbook see you on the next one.
