Picture the scene: an email lands in your inbox, and it looks exactly like a Docusign notification. An important document is waiting for you, just click to sign it. You click. You enter your credentials. And then something's off — the page stops responding normally. Within seconds, you realize you just handed your credentials to a cybercriminal.
This scenario isn't fictional. It's one of the most common attack vectors in 2025, responsible for over 90% of cyberattacks worldwide according to CISA. It's also the starting point of an exercise I recently carried out: building a Phishing Incident Response Playbook from scratch — a structured document that walks a security team through, step by step, when such an attack happens.
Here's the full methodology, the key concepts, and the deliverables produced.
Why a playbook?
When a security incident happens, stress and urgency eat up precious time. Without a defined procedure, everyone improvises, actions overlap, and meanwhile the attacker keeps exploiting the breach.
A playbook solves this by delivering three essential things:
- Speed — the steps are predefined, no need to think under pressure
- Coordination — every team member knows exactly what to do
- Traceability — every action gets documented, which is essential for post-incident analysis and legal obligations
The playbook I built follows the PICERL model (Preparation → Identification → Containment → Eradication → Recovery → Lessons Learned), aligned with the MITRE ATT&CK framework and NIST SP 800-61 recommendations.
Step 1 — Understanding how the attacker operated (TTPs)
Before figuring out how to respond, you need to understand how the attack works. In cybersecurity, this is called TTPs — Tactics, Techniques and Procedures — the way an attacker operates.
The go-to reference here is the MITRE ATT&CK framework, a collaborative database that catalogues every technique observed in real attacks. For our Docusign scenario, the identified TTPs are:
| MITRE ID | Technique | What happened |
|---|---|---|
T1566.002 |
Spearphishing Link | The email contained a link to the fake site |
T1056.003 |
Web Portal Capture | The fake form captured the credentials |
T1539 |
Steal Web Session Cookie | Potential theft of the session cookie |
T1036 |
Masquerading | The site visually mimicked Docusign |
T1583.001 |
Acquire Infrastructure | The attacker had registered a typosquatted domain |
This mapping work is fundamental: it lets you build precise response procedures instead of generic ones. You don't respond "to a phishing attack" in general, you respond to specific techniques, each with actions tailored to it.
Step 2 — Structuring the playbook
A good playbook starts with a clear structure. Four elements are essential.
Roles and responsibilities — who does what during the incident: the Incident Commander who coordinates, the SOC Analyst who detects and analyzes, the System Administrator who disables accounts, the DPO who handles legal obligations...
Communication channels — a golden rule that's often forgotten: never use potentially compromised systems to communicate about the incident. A dedicated, secure channel is defined ahead of time.
Severity levels — our scenario falls under the High level (compromised user credentials), with a response SLA under one hour. An incident involving administrator credentials would be Critical, with a 15-minute SLA.
The target timeline — from T+0 (report) to T+48h (ticket closure), each step has a defined timing that lets you measure the response's effectiveness.
Step 3 — IOCs: knowing what to look for
Indicators of Compromise (IOCs) are the traces left behind by the attacker. Identifying them ahead of time makes it possible to detect them quickly when an incident occurs.
For a credential-harvesting phishing attack, four categories are monitored:
Network — typosquatted domains (docusign-secure[.]net),
SSL certificates recently issued on unknown domains, POST requests to
unlisted servers.
User account — logins from unusual locations, authentications outside normal hours, sudden password changes, new sessions on unrecognized devices.
Email — a sender whose domain fails SPF/DKIM/DMARC checks,
shortened URLs in the message body, .html attachments simulating a
login form.
Endpoint — unknown processes launched after visiting the fraudulent site, modifications to the hosts file, browser extensions installed silently.
A useful concept for prioritizing: the Pyramid of Pain. IPs and file hashes sit at the bottom of the pyramid — the attacker changes them within hours. TTPs sit at the top — they stay stable for years. That's where monitoring effort should be concentrated.
Step 4 — The concrete procedures
This is the operational heart of the playbook. For each identified TTP, a procedure details the actions to carry out phase by phase.
For the most critical case — credentials entered on the fake portal (T1056.003) — the procedure unfolds like this:
- Identification: confirm the submission via proxy logs (a POST request to an unknown domain)
- Containment: immediately disable the account in Active Directory or the IAM
- Eradication: reset the password, invalidate all active sessions, revoke OAuth tokens
- Recovery: recreate the account with a strong password (16+ characters) and enable phishing-resistant MFA (FIDO2 preferably, not plain SMS)
The ideal timeline: account disabled at T+30 min, full investigation at T+1h, account restored with MFA at T+2h.
Step 5 — The toolbox
A playbook without tools is a recipe without ingredients. Tools are organized by phase:
- Detection: SIEM (Splunk, Microsoft Sentinel), EDR (CrowdStrike, Defender), Email Gateway (Proofpoint)
- Investigation: VirusTotal, URLScan.io, DNSTwist for typosquatted domains, MXToolbox for email checks
- Forensics: Autopsy for disk, Volatility for RAM, Wireshark for network traffic
- Containment: Active Directory, IAM (Okta), Firewall, DNS Filtering
Step 6 — Recovery and legal obligations
Recovery isn't just about putting the account back into service. Before any restoration, the damage needs assessing: was data exfiltrated? Were email forwarding rules created? Were any third-party apps authorized during the compromise?
For backups, the 3-2-1 rule applies: 3 copies of the data, on 2 different media, with 1 kept offline (air-gapped). Whenever there's doubt about the affected machine: reimage it. A potentially compromised system never goes back into production without absolute certainty.
On the legal side, if personal data was exposed, GDPR requires notifying the supervisory authority within 72 hours (Article 33, the CNIL in France). It's an obligation that's often underestimated but can carry heavy consequences if missed.
The deliverables produced
The exercise didn't stop at theory. Three concrete deliverables were produced:
An interactive flowchart (a standalone HTML file) that visually maps out the entire response process, from detection to closure, with decision branches and a clickable detail panel on each node.
An interactive web app, also a standalone HTML file, featuring a dashboard with overall progress, a checkable 25-task PICERL checklist (with local saving), an IOC table filterable by category, a toolbox organized by phase, and a detailed timeline. It all runs offline, with no installation, just a double-click.
An 8-page methodology PDF report, documenting the whole approach with all the tables, procedures, and references — usable as course material or a presentation aid.
Key takeaways
Building an incident response playbook is, above all, an exercise in structured thinking under constraint. It teaches you to:
- Map real attacker behavior onto a reference framework (MITRE ATT&CK)
- Turn theoretical knowledge into actionable operational procedures
- Anticipate legal obligations that are often forgotten in the heat of the moment
- Produce deliverables a real security team can actually use
Phishing remains, in 2025, the number-one entry vector for cyberattacks. Having a structured playbook is no longer optional — it's a necessity for any organization that takes its security seriously.
This article is part of a series on cybersecurity and incident response.
Sources: MITRE ATT&CK (attack.mitre.org), CISA Advisories, NIST SP 800-61, Verizon DBIR 2025