About this program
Phishing is the entry vector for most ransomware and breaches. This 15-question check covers your email security stack, your people, and your monitoring. After each answer, expand the “Auditor’s view” for how to test the control, what evidence to collect, and the ideal response.
Controls (15)
-
Are SPF, DKIM and DMARC configured for your sending domains, with DMARC at p=reject?
MediumAre SPF, DKIM and DMARC configured for your sending domains, with DMARC at p=reject?
How to test + evidence
Risk: Spoofers can send "from" your domain whenever DMARC is below p=reject. Most organisations stall at quarantine — finishing the move to reject is the highest-leverage email control.
Testing procedure: Run dig / mxtoolbox lookups on every sending domain. Verify SPF + DKIM + DMARC records exist and DMARC policy is at p=reject. Inspect DMARC aggregate reports for the last 30 days.
Evidence to collect: DNS records (SPF, DKIM, DMARC) for every sending domain DMARC aggregate report sample (e.g. dmarcian, Postmark) Subdomain policy alignment Failure rate showing legitimate senders pass
-
What kind of email security gateway do you use beyond default Microsoft / Google filtering?
MediumWhat kind of email security gateway do you use beyond default Microsoft / Google filtering?
How to test + evidence
Risk: Default tier filtering misses targeted phishing. Modern gateways (or premium-tier native) catch impersonation + post-delivery threats.
Testing procedure: Inspect the email security tooling configuration. Verify attachment sandboxing + URL detonation are enabled. Sample 10 quarantined / blocked emails from the period.
Evidence to collect: Email security tooling configuration export Sample of quarantined emails with verdict Sandbox detonation reports Anti-phishing policy showing impersonation protection
-
Do inbound emails from outside your organisation get flagged with a clear external sender warning banner?
MediumDo inbound emails from outside your organisation get flagged with a clear external sender warning banner?
How to test + evidence
Risk: A one-line config change with measured 10–20% click reduction. Subtle banners get tuned out — make them distinct.
Testing procedure: Send a test email from an external address. Confirm the banner appears, is visible, and clearly states "external sender".
Evidence to collect: Screenshot of received external email with banner Mail flow rule / transport rule configuration Documentation in user awareness training referencing the banner
-
Are attachments and links detonated in a sandbox before delivery?
MediumAre attachments and links detonated in a sandbox before delivery?
How to test + evidence
Risk: Static AV misses zero-day payloads. Sandboxing actually executes the attachment in isolation and observes behaviour.
Testing procedure: Inspect the email security tool config: Safe Attachments + Safe Links policy or equivalent. Send a test EICAR attachment to confirm sandbox behaviour.
Evidence to collect: Safe Attachments / Safe Links policy export Sandbox detonation report sample URL rewriting evidence in delivered emails
-
Do you monitor for lookalike (typosquat / homoglyph) domains that could impersonate your brand?
MediumDo you monitor for lookalike (typosquat / homoglyph) domains that could impersonate your brand?
How to test + evidence
Risk: Lookalike domains are pre-positioned attack infrastructure. Automated monitoring catches them at registration; reactive discovery is too late.
Testing procedure: Inspect the lookalike domain monitoring tooling. Verify recent identifications + takedown actions during the audit period.
Evidence to collect: Lookalike domain monitoring service contract / output List of identified lookalike domains Takedown request / response logs DMARC reports highlighting spoofing attempts
-
Is MFA enforced on email accounts — including any legacy mail clients / IMAP / SMTP auth?
MediumIs MFA enforced on email accounts — including any legacy mail clients / IMAP / SMTP auth?
How to test + evidence
Risk: Legacy auth bypasses MFA. The most common compromise vector is an account that has MFA but a legacy auth path open.
Testing procedure: Inspect IDP conditional access for email apps. Verify legacy auth (POP, IMAP, SMTP basic, EWS basic) is blocked at tenant level. Sample admin/exec login records to confirm MFA challenges.
Evidence to collect: CA policy showing MFA on email apps Configuration showing legacy auth blocked Sample login audit entries showing MFA Exception list for shared mailboxes (if any) with mitigations
-
How often do users receive phishing-specific awareness training?
MediumHow often do users receive phishing-specific awareness training?
How to test + evidence
Risk: Annual training has measurably-decaying effect within months. Continuous reinforcement is what changes behaviour — and what auditors look for.
Testing procedure: Pull training + simulated phishing reports for the audit period. Calculate completion rate, click rate, report rate trends.
Evidence to collect: Training completion report Simulated phishing campaign list with results Click + report rate trends over time Remedial training records for clickers
-
Can users one-click report a suspicious email to the security team?
MediumCan users one-click report a suspicious email to the security team?
How to test + evidence
Risk: A one-click button with automated triage closes the gap from receipt to security awareness — minutes not hours.
Testing procedure: Send a test email with a known-phishing-like subject. Confirm the Report Phish button is visible in mail clients (Outlook, OWA, mobile). Verify a sample of reports has been triaged with timestamps.
Evidence to collect: Screenshot of Report Phish button in Outlook Reported email sample + triage record Triage SLA + actual median time-to-triage User-facing communication explaining how to report
-
Do high-risk roles (finance, HR, exec assistants, IT admins) receive role-specific anti-phishing training?
MediumDo high-risk roles (finance, HR, exec assistants, IT admins) receive role-specific anti-phishing training?
How to test + evidence
Risk: High-risk roles attract targeted attacks. Generic training doesn't cover BEC wire-fraud patterns or admin consent phishing.
Testing procedure: Inspect training catalogue. Verify role-specific modules for finance (BEC), exec assistants (impersonation), IT admins (consent phishing), HR (CV malware).
Evidence to collect: Training catalogue with role mapping Completion records per high-risk role Role-specific simulated phishing scenarios
-
Do you have a written process to verify wire transfer / payment-change requests out-of-band (e.g. callback to known number)?
MediumDo you have a written process to verify wire transfer / payment-change requests out-of-band (e.g. callback to known number)?
How to test + evidence
Risk: BEC is the highest-loss category for SMBs and mid-market. The callback rule is cheap, simple, and consistently saves the money.
Testing procedure: Inspect the procedure document. Sample 10 wire transfers / supplier-change events in the period; verify each has documented out-of-band verification (callback to a known-good number, not the one in the email).
Evidence to collect: Wire / payment-change verification procedure Sample of completed verification records Training records for finance / AP team Lessons learned from any near-miss BEC attempts
-
Do you have visibility into who clicked a phishing link or entered credentials on a phishing site?
MediumDo you have visibility into who clicked a phishing link or entered credentials on a phishing site?
How to test + evidence
Risk: Without click telemetry you don't know who got phished. URL rewriting + identity-aware detection gives you the closed loop.
Testing procedure: Inspect the URL-rewriting tooling output. For a known phishing campaign in the period, identify users who clicked + the response actions taken.
Evidence to collect: URL click logs from email security tool Web proxy / DNS logs correlating with email events Identity-aware detection alerts (post-MFA hijack, unusual session)
-
Do you alert on suspicious sign-ins (impossible travel, new device, post-MFA hijack)?
MediumDo you alert on suspicious sign-ins (impossible travel, new device, post-MFA hijack)?
How to test + evidence
Risk: Auto-response collapses the time between credential theft and damage. Manual triage at scale is impossible.
Testing procedure: Inspect IDP risk policies + SIEM detection rules for impossible travel / new device / unusual session. Sample alerts from the period and verify response actions.
Evidence to collect: CA policies / risk-based authentication config Sample alerts with auto-response (token revocation, password reset) Mean time to respond to high-risk sign-in alerts
-
Do you detect malicious mailbox rules (auto-forward / delete) that attackers create after compromise?
MediumDo you detect malicious mailbox rules (auto-forward / delete) that attackers create after compromise?
How to test + evidence
Risk: Attackers who get into a mailbox immediately set up auto-forward of legal/finance threads. Real-time alerting catches it before they exfiltrate.
Testing procedure: Inspect the SIEM rule set. Verify alerts on mailbox rule creation (especially auto-forward to external + auto-delete patterns). Sample real alerts triaged in the period.
Evidence to collect: Detection rule for mailbox rule creation Sample alerts with disposition Periodic audit of all mailbox rules
-
Do you control which third-party OAuth apps users can grant access to (consent phishing defence)?
MediumDo you control which third-party OAuth apps users can grant access to (consent phishing defence)?
How to test + evidence
Risk: Consent phishing tricks users into authorising apps that gain persistent access without ever needing the password. Admin consent stops this.
Testing procedure: Inspect tenant OAuth consent policy (M365: User consent settings; Google Workspace: app access controls). Verify admin consent workflow is in place.
Evidence to collect: OAuth consent policy export Admin consent workflow + sample request/approvals List of allow-listed publishers / verified apps Audit log of consent grants in the period
-
Do you have a written runbook for "user clicked / entered credentials on a phish"?
MediumDo you have a written runbook for "user clicked / entered credentials on a phish"?
How to test + evidence
Risk: Speed matters — every minute between credential theft and revocation is exposure. Automated playbooks shrink that to seconds.
Testing procedure: Inspect the runbook. Verify it covers password reset + session/token revocation + mailbox rule audit + threat hunt scope. Sample an incident handled with the runbook in the period.
Evidence to collect: Phishing IR runbook (current version) Sample incident record showing runbook followed SOAR / automation playbook config if applicable Mean-time-to-resolution for credential compromise