What to take away
Training helps people recognize and report suspicious messages. It does not establish whether a mailbox rule, app grant, public file link, or sensitive AI submission was created after an incident. Pair people metrics with a dated, owner-led check of the relevant SaaS state. The exact checks depend on what happened; a click alone is not proof that any of these paths was used.
1. Keep the training; change the closure test
Awareness training and phishing simulations are useful practice. A completed lesson or lower click rate, however, cannot remove an unauthorized inbox rule, revoke an OAuth grant, or narrow a public file link. Keep those measures as participation and behavior signals, not evidence that technical exposure has ended.
A reported click is a triage trigger. First establish whether credentials were submitted, a session was used, a file was shared, or sensitive content was sent. Then inspect the paths relevant to that evidence. Record who checked each source and when; leave unknowns open instead of declaring the incident closed from a training dashboard.
2. Map the possible paths after a click
A suspected compromise may leave a persistent rule, consent, or link even after the original message is gone. Use this table as a bounded checklist, not an assumption that every path was exercised.
| Path | Source check | When it matters |
|---|---|---|
| Mailbox rules and forwarding | Review current rules and relevant audit events | Credentials or an active mail session may have been exposed |
| OAuth and connected apps | Review recent and broad grants by client ID and scope | A consent prompt or session may have added app access |
| Drive and SharePoint links | Open current item permissions and link audience | A file was shared or opened during the incident |
| AI prompts or uploads | Ask about work content sent to an assistant and check supported evidence | The user used AI while handling the event or related data |
3. Verify mailbox rules and connected apps
For Gmail, review Filters and blocked addresses, Forwarding and POP/IMAP, plus available audit events for the relevant window. For Microsoft 365, review Outlook inbox rules, forwarding settings, and the admin or Defender views included in your license. Remove an unauthorized rule and verify the mailbox state afterward; a password reset alone does not delete an inbox rule.
Review Google API controls and Entra enterprise-app permissions for suspicious or over-broad consent. Scope and client ID matter more than a familiar display name. Password changes and suspension can invalidate tokens in source-specific ways, but do not replace a check of application policy, tenant-wide consent, or other affected accounts. Revoke only after identifying the grant, and verify in the source.
References: Microsoft Defender — Suspicious inbox-forwarding rules · Google Workspace — Control third-party app access
4. Check file links and sensitive AI use when indicated
For a file touched in the incident, inspect current General access in Drive or Manage access in SharePoint or OneDrive. A historical sharing event is a lead, not proof of today’s audience. Narrow an unnecessary Anyone link to named people or remove it, then confirm required collaborators still have access.
If work content may have been pasted or uploaded to an AI assistant, ask one specific question about the tool, account context, and data category. A browser observation alone does not prove a submission; silence in an uninstrumented browser does not prove none occurred. Use supported Browser Security evidence and your incident process without collecting raw sensitive content unnecessarily.
References: Google Workspace — Drive log events
5. Report people metrics and verified control outcomes together
Keep campaign participation, reporting, and simulation results. Alongside them, count post-click mailbox checks, grants reviewed and revoked with source verification, links narrowed, and open follow-ups with owners. These numbers answer different questions; a good click rate is not a proxy for current permissions.
Make the checklist proportional to the incident. A harmless simulation click may call for a lesson and reporting follow-up; a real credential submission needs the relevant account and SaaS checks. A monthly sample can reveal recurring gaps without treating every training event as a breach.
How Elba supports the workflow
Elba supports security awareness training and phishing simulations. With the appropriate separate connections, Data Protection surfaces supported Drive, SharePoint, and OneDrive sharing exposures; Third-Party Apps shows connector-confirmed grants alongside distinct observations; and Browser Security Playbooks can act on supported sensitive prompts or uploads.
Elba does not replace an incident response process or claim that a simulation click scans a mailbox. Coverage and remediation depend on each deployed connection and supported action. Validate representative findings and fixes before relying on them as a closure signal.
References: Elba — Security awareness · Elba — Data Protection
Post-click SaaS control checklist
Your checks stay on this page and reset when you reload it.
Common questions
Should we stop phishing simulations?
No. Keep useful practice and reporting. Just do not treat a completion or click metric as proof that SaaS permissions, mailbox rules, and links have been checked.
Is a password reset enough after a credential submission?
Follow the incident process for sessions and MFA, then inspect the SaaS paths relevant to the event. A password reset does not remove an unauthorized inbox rule or public file link.
Does a browser observation prove someone pasted data into AI?
No. It shows observed use. Confirm any submission from supported evidence or a focused written follow-up, and preserve the distinction in reporting.
Sources & further reading
Primary documentation used to review this guide. Product settings and edition requirements can change; check the linked documentation before making changes.