1. Purpose
This playbook defines the process for identifying, reporting, investigating, containing, and recovering from phishing attacks.
The objectives are to:
- Detect phishing attempts quickly.
- Prevent users from interacting with malicious content.
- Contain compromised accounts and devices.
- Determine whether credentials were disclosed.
- Determine whether malware was executed.
- Assess whether information was accessed or exfiltrated.
- Preserve relevant evidence.
- Remove attacker persistence.
- Restore affected accounts and systems securely.
- Identify the root cause.
- Improve email, identity, endpoint, and security-awareness controls.
This playbook should be used together with the organization’s Information Security Incident Management Policy and Incident Response Procedure.
2. Scope
This playbook applies to phishing involving:
- Corporate email
- Personal email used for business activities
- Microsoft 365/Google Workspace or equivalent
- SSO and identity providers
- SaaS applications
- Cloud environments
- Customer-support platforms
- Finance systems
- HR systems
- Developer platforms
- Source-code repositories
- CI/CD systems
- Mobile devices
- Employee laptops and desktops
- Suppliers and third parties
- Business Email Compromise (BEC)
- Credential phishing
- Malware delivery
- Phishing leading to data breach
3. What Is Phishing?
Phishing is a social-engineering technique in which an attacker attempts to deceive a person into:
- Revealing credentials
- Approving an authentication request
- Opening a malicious attachment
- Clicking a malicious link
- Installing malicious software
- Transferring money
- Sharing confidential information
- Changing account or payment information
- Providing access to systems or data
Phishing may occur through:
- SMS
- Messaging applications
- Social media
- Voice calls
- Collaboration platforms
- Fake login pages
- QR codes
- Calendar invitations
- Supplier impersonation
- Executive impersonation
4. Phishing Response Lifecycle
Detect → Report → Validate → Classify → Contain → Preserve Evidence → Investigate → Remove Threat → Secure Identity → Recover → Assess Impact → Monitor → Learn → Improve
5. Phishing Trigger Conditions
Activate this playbook when:
- An employee reports a suspicious email.
- A malicious link is clicked.
- Credentials are entered into a suspicious website.
- An unexpected MFA request is approved.
- A suspicious attachment is opened.
- Malware is detected after opening an attachment.
- A mailbox shows suspicious activity.
- A user reports an unusual password-reset message.
- An attacker impersonates an executive.
- A supplier appears to send a suspicious request.
- A finance employee receives an unusual payment request.
- An identity provider reports suspicious authentication activity.
- Security monitoring detects a suspicious login following a phishing event.
6. Phishing Incident Categories
Category 1 – Phishing Attempt
A malicious message was received but no interaction occurred.
Example:
Employee receives a fake Microsoft 365 login email but reports it without clicking.
Category 2 – Link Clicked
The user clicked a malicious link but there is no evidence that credentials or information were submitted.
Category 3 – Credential Disclosure
The user entered credentials into a phishing page.
Category 4 – MFA Compromise
The user approved a fraudulent authentication request or attacker obtained an authentication token/session.
Category 5 – Malware Execution
A malicious attachment or download was executed.
Category 6 – Account Compromise
The attacker successfully obtained access to the user’s account.
Category 7 – Data Breach
The compromised account was used to access or disclose sensitive information.
Category 8 – Business Email Compromise
The attacker uses a compromised or impersonated account to conduct fraudulent or unauthorized business activity.
One phishing incident may move between categories as the investigation develops.
7. Immediate Response – First 15 Minutes
The immediate objective is to determine whether the phishing attempt resulted in compromise.
7.1 Create Incident Record
Record:
- Incident ID
- Date/time reported
- Reporter
- Affected user
- Email/message source
- Sender
- Subject
- Link/attachment information
- Initial classification
- Initial severity
- Incident Manager
7.2 Preserve the Message
Where possible, retain:
- Original email
- Message headers
- Sender information
- URLs
- Attachments
- Screenshots
- Email security alerts
- Authentication alerts
Do not forward suspicious attachments to other employees merely for investigation.
8. Initial Validation
Determine:
- Was the message malicious?
- Was the sender spoofed or compromised?
- Did the user click the link?
- Did the user open an attachment?
- Were credentials entered?
- Was MFA approved?
- Was a file downloaded?
- Was software executed?
- Did the user provide confidential information?
- Did the attacker gain access?
- Did the same message reach other employees?
9. Immediate User Guidance
If the user is currently interacting with the suspicious content:
- Stop interacting with the message.
- Do not enter additional credentials.
- Do not approve unexpected MFA requests.
- Do not download additional files.
- Do not communicate with the attacker.
- Report the incident immediately.
- Keep the original message where possible.
- Follow IT/Security instructions.
If credentials may have been entered, tell the user to use an approved clean device or approved recovery process for credential reset where appropriate.
10. Containment – Credential Phishing
If credentials were entered:
- Create/confirm the incident record.
- Disable or restrict the affected account where appropriate.
- Revoke active sessions.
- Reset the password.
- Revoke suspicious authentication tokens.
- Review MFA methods.
- Remove unauthorized MFA methods.
- Review OAuth applications.
- Review mailbox forwarding rules.
- Review delegated access.
- Review recent sign-ins.
- Review privilege changes.
- Investigate connected applications.
A password reset alone may not be sufficient if an attacker obtained a session token, OAuth authorization, API credential, or other persistence mechanism.
11. MFA Phishing / MFA Fatigue
Phishing may attempt to trick a user into approving an unexpected MFA request.
Investigate:
- MFA prompts
- Number of authentication attempts
- Authentication source
- Device
- Location
- Time
- Authentication method
- Successful/failed attempts
- New MFA methods
- Session/token activity
If compromise is suspected:
- Revoke active sessions.
- Revoke suspicious tokens.
- Re-register MFA where required.
- Remove unauthorized authentication methods.
- Review account activity.
- Review connected applications.
12. Investigate Account Compromise
Review:
- Successful logins
- Failed logins
- Unusual locations
- Unusual devices
- New sessions
- MFA changes
- Password changes
- Account recovery changes
- OAuth applications
- Mailbox rules
- Email forwarding
- Delegated access
- File-sharing activity
- Cloud access
- SaaS access
- Administrative actions
Look for:
- Data downloads
- Email forwarding
- New inbox rules
- External communication
- Credential harvesting
- Privilege escalation
- Persistence mechanisms
13. Mailbox Investigation
For a compromised email account, review:
- Inbox
- Sent items
- Deleted items
- Forwarding rules
- Inbox rules
- Delegates
- Shared mailboxes
- Email searches
- Attachments
- External recipients
- Recently accessed files
- Calendar
- Contacts
- OAuth applications
Determine whether the attacker:
- Sent phishing emails internally.
- Sent phishing emails externally.
- Read confidential emails.
- Obtained invoices.
- Obtained customer information.
- Obtained credentials.
- Created forwarding rules.
- Deleted evidence.
- Used the mailbox for impersonation.
14. Phishing Attachment / Malware Scenario
If a malicious attachment was opened:
Determine:
- Filename
- File type
- Source
- Time opened
- Device
- User
- Whether macros/scripts executed
- Whether software was installed
- Endpoint security alerts
- Network connections
- Processes executed
- Persistence mechanisms
The endpoint may need to be isolated.
Do not assume that closing the document or deleting the attachment has removed the threat.
15. Endpoint Containment
Where malware execution is suspected:
- Isolate the endpoint according to the organization’s endpoint-response procedure.
- Preserve relevant evidence.
- Review EDR/antivirus alerts.
- Identify suspicious processes.
- Identify persistence mechanisms.
- Review network connections.
- Check credential exposure.
- Assess lateral movement.
- Determine whether other systems were contacted.
Where required, rebuild the system from a trusted source rather than relying only on malware removal.
16. Investigate Lateral Movement
If an account or endpoint was compromised, investigate whether the attacker accessed:
- File servers
- Cloud systems
- SaaS applications
- Production systems
- Databases
- Source-code repositories
- CI/CD
- VPN
- Remote administration systems
- Other employee accounts
Create a relationship:
Phishing Message → User → Account → Device → Application → Privilege → Data → Other Systems
17. Assess Data Exposure
Determine whether the phishing incident resulted in access to:
- Customer information
- Employee information
- Personal data
- Financial information
- Confidential business information
- Source code
- Credentials
- Security information
- Contracts
- Internal communications
Check:
- Email access
- File access
- Cloud storage
- SaaS applications
- Database access
- Data exports
- External transfers
If unauthorized information access is confirmed or reasonably suspected, activate the organization’s Data Breach Playbook where appropriate.
18. AWS / Cloud Scenario
Phishing may be the initial step in compromising an employee or developer identity that can access AWS.
Example:
A developer receives a fake cloud-login email and enters credentials into a phishing page. The attacker subsequently uses the compromised identity to access AWS resources.
Investigate:
- Identity provider logs
- IAM Identity Center
- IAM roles
- CloudTrail
- CloudWatch
- GuardDuty
- S3 access
- Secrets Manager
- KMS
- EC2/ECS/EKS
- CI/CD systems
- Source-code repositories
Determine:
- Which identity was compromised.
- Which AWS roles were accessed.
- What permissions were available.
- What resources were accessed.
- Whether data was accessed.
- Whether configuration was changed.
- Whether new credentials were created.
- Whether persistence was established.
19. Business Email Compromise
If phishing results in business email compromise, investigate:
- Unauthorized payment requests
- Bank-detail changes
- Invoice changes
- Supplier impersonation
- Customer impersonation
- Executive impersonation
- Payroll changes
- Confidential information requests
Immediately involve the appropriate:
- Finance
- Management
- Security
- Legal/Compliance
- Supplier/Customer Owner
If money has been transferred, the organization should follow its financial-fraud response process immediately and contact relevant financial institutions through approved channels.
20. Supplier / Customer Phishing
If a supplier or customer is impersonated:
Verify independently using a trusted communication channel.
Do not rely solely on:
- Email replies
- Contact details contained in the suspicious message
- New bank details provided in the message
- Urgent requests
- Documents attached to the message
For sensitive transactions, apply the organization’s established verification and approval process.
21. Investigate Phishing Campaign Scope
Determine whether the same campaign targeted other people.
Search for:
- Sender address
- Sender domain
- Subject
- URLs
- Attachment hashes
- Attachment names
- Message identifiers
- Similar wording
- Similar domains
- Similar recipients
Take appropriate action such as:
- Search mailboxes.
- Remove malicious messages.
- Block malicious domains.
- Block malicious URLs.
- Block malicious attachments.
- Alert potentially affected users.
- Review accounts of users who interacted with the campaign.
22. Evidence Preservation
Potential evidence includes:
- Original email
- Email headers
- URL
- Attachment
- Attachment hash
- Mail-server logs
- Email security gateway logs
- Identity logs
- MFA logs
- SSO logs
- EDR records
- Browser history where appropriate
- DNS logs
- Proxy logs
- Firewall logs
- Cloud logs
- SaaS audit logs
- OAuth records
- Mailbox audit logs
- User report
- Screenshots
- Timeline
- Investigation notes
Evidence should be protected against unauthorized modification or deletion.
23. Root Cause Analysis
Determine why the phishing incident succeeded or nearly succeeded.
Potential causes include:
- User interaction
- Lack of phishing awareness
- Weak email filtering
- Domain spoofing
- Look-alike domain
- Lack of MFA
- Weak authentication
- MFA fatigue
- Inadequate conditional access
- Malicious OAuth application
- Insufficient endpoint protection
- Excessive privileges
- Inadequate monitoring
- Lack of reporting mechanisms
Avoid treating user error as the only root cause. Assess the technical and organizational controls that could prevent or reduce impact.
24. Remediation
Potential corrective actions include:
Identity
- Enforce MFA.
- Strengthen authentication.
- Implement phishing-resistant authentication where appropriate.
- Remove unnecessary privileges.
- Review privileged access.
- Improve session controls.
- Improve spam/phishing filtering.
- Implement attachment protection.
- Implement malicious URL protection.
- Configure domain authentication controls.
- Monitor suspicious forwarding rules.
Endpoint
- Improve EDR coverage.
- Restrict malicious file execution.
- Patch systems.
- Restrict macros/scripts where appropriate.
Cloud
- Apply least privilege.
- Monitor privileged activity.
- Review cloud authentication.
- Improve conditional access.
- Monitor suspicious role assumptions.
People
- Improve security awareness.
- Provide phishing reporting mechanisms.
- Conduct targeted training.
- Perform controlled phishing simulations where appropriate.
25. Recovery
After containment:
- Restore affected accounts.
- Reset credentials.
- Revoke sessions/tokens.
- Re-register MFA where required.
- Remove unauthorized MFA methods.
- Remove malicious OAuth applications.
- Remove mailbox forwarding rules.
- Validate endpoint security.
- Rebuild compromised endpoints where required.
- Verify cloud access.
- Validate application access.
- Increase monitoring temporarily.
26. Recovery Verification
Confirm:
- Account is controlled by the legitimate user.
- Password/credentials are secure.
- MFA is correctly configured.
- Sessions/tokens are revoked.
- Unauthorized applications are removed.
- Mailbox rules are clean.
- No unauthorized forwarding exists.
- No suspicious access continues.
- Endpoint is clean or rebuilt.
- Cloud access is authorized.
- No persistence remains.
- No unauthorized data access continues.
27. Notification Assessment
If phishing resulted in:
- Credential compromise
- Customer-data access
- Personal-data exposure
- Financial fraud
- Confidential-data disclosure
- Supplier compromise
- Material business impact
assess applicable:
- Privacy requirements
- Regulatory obligations
- Customer contracts
- Supplier agreements
- Insurance requirements
- Legal obligations
Where appropriate, involve Legal/Privacy/Compliance before external notification.
28. Phishing Incident Severity
Severity examples:
Low
Phishing received and reported without user interaction.
Medium
User clicked a malicious link, but investigation finds no evidence of credential disclosure or compromise.
High
Credentials were disclosed, MFA was compromised, malware executed, or an account was compromised.
Critical
Phishing resulted in:
- Privileged account compromise
- Production/cloud compromise
- Significant customer-data exposure
- Major financial fraud
- Widespread organizational compromise
- Major business disruption
Severity should ultimately follow the organization’s approved incident-classification methodology.
29. Lessons Learned
After the incident, review:
- How was phishing detected?
- How quickly was it reported?
- Did email controls detect it?
- Did the user report it?
- Were credentials disclosed?
- Was MFA compromised?
- Was malware executed?
- Was the account compromised?
- Was data accessed?
- Was lateral movement possible?
- Were logs sufficient?
- Were response actions fast enough?
- What technical controls should improve?
- What awareness improvements are required?
30. Corrective Action Register
| Finding | Risk | Corrective Action | Owner | Due Date | Evidence | Status |
|---|---|---|---|---|---|---|
| User entered credentials into phishing page | High | Strengthen phishing-resistant authentication | IAM Owner | Date | Authentication configuration | Open |
| Malicious email bypassed filtering | Medium | Improve email security controls | IT/Security | Date | Email security report | Open |
| Excessive user privileges | High | Implement least privilege | IT Owner | Date | Access review | Open |
| Suspicious forwarding not detected | Medium | Enable mailbox monitoring | Security | Date | Alert configuration | Open |
31. Phishing Readiness Checklist
Preparation
- Phishing reporting mechanism available
- Email security controls configured
- MFA enabled
- Privileged accounts protected
- Endpoint protection deployed
- Identity monitoring enabled
- Cloud authentication monitored
- Incident response contacts maintained
- Phishing playbook approved
- Security-awareness training provided
- Backup/incident procedures available
During Incident
- Suspicious message preserved
- Incident record created
- Message validated
- User interaction determined
- Credential disclosure assessed
- MFA activity assessed
- Account activity reviewed
- Endpoint assessed
- Sessions/tokens revoked where required
- OAuth applications reviewed
- Mailbox rules reviewed
- Data access assessed
- Campaign scope assessed
- Other affected users identified
Recovery
- Credentials secured
- MFA secured
- Sessions/tokens revoked
- Unauthorized applications removed
- Mailbox rules validated
- Endpoint secured
- Cloud access reviewed
- Monitoring increased
- Recovery verified
Closure
- Root cause documented
- Data breach assessment completed where applicable
- Financial-fraud assessment completed where applicable
- Required notifications assessed
- Corrective actions assigned
- Residual risk assessed
- Lessons learned completed
- Management review completed
- Incident closed
32. Relationship With Other ISMS Documents
This playbook should connect with:
- Information Security Incident Management Policy
- Incident Response Procedure
- Account Compromise Playbook
- Data Breach Playbook
- Malware Infection Playbook
- Business Email Compromise Playbook
- Access Control Policy
- Authentication Policy
- Privileged Access Management
- Security Awareness Policy
- Email Security Standard
- Cloud Security Policy
- Cloud Access Review
- Vulnerability Management Procedure
- Supplier Security Requirements
- Supplier Incident Response Procedure
- Data Classification Policy
- Risk Assessment
- Risk Register
- Corrective Action Register
- Evidence/Records Management Procedure
A phishing incident may transition into another playbook.
For example:
Phishing → Credential Compromise → Account Compromise → Data Breach
or:
Phishing → Malicious Attachment → Malware → Ransomware
The incident should be escalated to the relevant specialized playbook when the investigation confirms the additional impact.
33. ISO 27001 Connection
Phishing response supports the organization’s information-security management arrangements in areas such as:
- Information-security incident management
- Event reporting
- Incident assessment and response
- Learning from incidents
- Access control
- Identity management
- Authentication
- Privileged access
- Malware protection
- Security awareness
- Logging and monitoring
- Cloud security
- Data leakage prevention
- Supplier security
- Evidence collection
The exact controls applicable to the organization should be determined through the ISMS scope, risk assessment, Statement of Applicability, legal requirements, contractual requirements, and business needs.
This playbook is not itself proof that the controls are operating. Actual evidence may include phishing reports, investigation records, email-security logs, authentication logs, access reviews, training records, incident exercises, corrective actions, and management reviews.
34. Internal Audit Checklist
An auditor can verify:
- Is phishing included in the organization’s information-security risk assessment?
- Is a phishing response process documented?
- Can employees report suspicious messages?
- Are phishing incidents investigated?
- Are email security controls implemented?
- Is MFA implemented?
- Are privileged accounts protected?
- Are suspicious authentication events monitored?
- Are mailbox audit logs available?
- Are OAuth applications reviewed where relevant?
- Are endpoint controls implemented?
- Are phishing-related incidents recorded?
- Is evidence preserved?
- Are compromised accounts investigated?
- Is data exposure assessed?
- Are supplier/customer impacts considered?
- Are corrective actions tracked?
- Are lessons learned documented?
- Are security-awareness activities reviewed?
- Is management involved in significant incidents?
35. Final Phishing Audit Trail
A complete phishing response should create an evidence chain:
Phishing Detected → Message Reported → Message Preserved → Threat Validated → User Interaction Determined → Incident Classified → Account/Endpoint Contained → Evidence Preserved → Credentials/Sessions Secured → Mailbox/Identity Investigated → Campaign Scope Assessed → Data Access Assessed → Malware/Lateral Movement Checked → Root Cause Identified → Remediation Completed → Recovery Verified → Increased Monitoring → Corrective Actions Assigned → Residual Risk Assessed → Lessons Learned → Management Review → Incident Closed
Where the phishing event results in another security incident, extend the trail:
Phishing → Account Compromise → Data Breach / Malware / Ransomware / Financial Fraud → Specialized Response → Recovery → Closure
36. Final Principle
Phishing Response = Report Quickly + Validate the Threat + Secure the Identity + Contain the Endpoint + Investigate Access + Assess Data Exposure + Remove Persistence + Verify Recovery.
The objective is not simply to delete the phishing email.
The organization should be able to demonstrate:
What was received → Who interacted with it → What was disclosed or executed → Whether an account or device was compromised → What systems/data were accessed → How the threat was contained → What evidence supports the investigation → What was remediated → What was improved.