Turn a phishing simulation's click-rate data into training, not a shame list

After a phishing simulation runs, the report that comes out the other end is usually a list: who clicked, who reported it, click-rate by department. Handed straight to an AI tool with "summarise this," you get a tidier version of the same list - which is exactly the version that turns a training opportunity into a naming exercise nobody learns from.

Ask for the pattern in what got clicked, not the list of who clicked it. The useful question isn't "who fell for it" - it's "what about this specific simulation made it convincing, and does that expose something about our real inbox that a genuine attacker would also exploit." A simulation that impersonated a real supplier your finance team actually uses is a different finding than one that impersonated a made-up prize draw - the first tells you something about a real, exploitable trust relationship; the second mostly tells you people click things sometimes.

Feed it the simulation's actual content and the aggregate numbers, not named individuals, and ask specifically: what made this pretext plausible, which teams' click rate suggests the pretext matched something they genuinely deal with day to day, and what one thing about the real inbox environment (a supplier relationship, an internal process, a tool people are used to logging into) would make training stick better than a generic "spot the phish" reminder.

Next debrief, drop the department league table and lead with the pretext analysis instead. It's the difference between a report people quietly resent and one that actually changes what someone does the next time a convincing email lands.