Many organizations discover phishing simulations the same way they discover DLP or device management: it’s already “included” in something they pay for. Email security suites and productivity platforms increasingly ship a built-in phishing simulation feature. On paper, this sounds perfect—one vendor, one portal, one invoice.

In practice, bundled simulation tools can be a great starting point, but they’re not always the best long-term choice. Security engineers and CISOs eventually run into constraints around guardrails, reporting evidence, privacy expectations, and the operational reality of running frequent campaigns.

This article explains how to evaluate **phishing simulation tools bundled into an email platform** versus dedicated platforms, so you can make a decision you’ll still be happy with after the first quarter of “let’s do this properly.”

## What counts as “bundled” vs “dedicated”?

**Bundled** usually means phishing simulation is a feature inside a broader suite (email security, productivity, endpoint, or security platform). You manage simulations in the same ecosystem as mail protection and user administration.

**Dedicated** means phishing simulations and awareness workflows are the core product. The platform is built for recurring campaigns, targeted follow-ups, privacy controls, and reporting as a first-class output.

Some suites are more capable than others. For example, Microsoft documents its approach as “Attack simulation training” in Defender for Office 365: [Get started using Attack simulation training](https://learn.microsoft.com/en-us/defender-office-365/attack-simulation-training-get-started).

## The decision framework: 6 questions that reveal the right answer

### 1) What is your real goal: “run a test” or “change behavior at scale”?
If your goal is a one-off baseline, bundled can be enough.

If your goal is continuous improvement—measurable reporting habits, reduced repeat susceptibility, and audit-friendly evidence—dedicated platforms tend to win because they’re designed for frequency, segmentation, and consistent reporting.

If you’re still deciding how automated you want your program to be, this overview can help: [Automated phishing testing vs. manual campaigns](https://autophish.io/blog/automated-phishing-testing-vs-manual-campaigns-which-is-best-for-your-business).

### 2) Can you measure the outcomes that matter (not just clicks)?
Click rate is easy to produce and easy to misinterpret.

A platform is only useful for risk reduction if it helps you track:

- **Report rate** (do users report suspicious messages?)
- **Time-to-report** (how quickly do they escalate?)
- **Repeat susceptibility** (who needs targeted coaching?)
- **Trends over time** (rolling improvements, not one month’s noise) 

> [See how AutoPhish does reporting here](https://help.autophish.io/en/article/phishing-campaign-reports-analytics-ymehoj/)

If you want a concrete checklist for what reporting should look like in practice, use: [Phishing simulation reporting: 12 features security teams should compare](https://autophish.io/blog/phishing-simulation-reporting-12-features-security-teams-should-compare-dashboards-metrics-and-audit-evidence).

### 3) Do you have guardrails that keep simulations ethical and safe?
The most expensive awareness program is the one that creates internal backlash.

Bundled tools sometimes optimize for “quick launch” rather than program governance. Evaluate whether the platform supports guardrails such as:

- Avoiding sensitive themes that can trigger HR escalation
- Limiting data collection to what you actually need
- Clear training moments (without humiliation)
- Controls for cohort targeting and difficulty ramping

Guardrails aren’t just culture. They’re also risk management.

### 4) How hard is it to operate monthly (or quarterly) campaigns?
The tool you choose determines whether your program becomes routine or a recurring fire drill.

Ask:

- Can you schedule recurring simulations?
- Can you target cohorts by role/business unit and rotate scenarios?
- Can you export consistent reports for leadership and audit evidence?
- How much manual work is required per campaign?

Bundled tools often work well for “run a campaign now.” Dedicated platforms are often better at “run a program continuously.”

### 5) Can you meet privacy expectations (GDPR accountability, works councils, and internal policy)?
Avoid claiming that a tool “makes you compliant.” It doesn’t.

What matters is whether you can run a program aligned to your organization’s privacy expectations:

- Minimal personal data collection
- Clear retention periods
- Role-based access for administrators
- Options to anonymize or aggregate reporting when appropriate

If privacy governance is a core constraint, start with: [Privacy-Friendly Phishing Training: Works Councils, Consent, and GDPR Essentials](https://autophish.io/blog/privacy-friendly-phishing-training-works-councils-consent-and-gdpr-essentials).

### 6) What happens if you change your email platform or security stack?
Bundled tooling can create hidden lock-in:

- Metrics and historical baselines live inside the suite
- Export formats may not be designed for long-term trending
- You may be forced to re-baseline after a platform change

Dedicated platforms can make the awareness program more portable and stable across infrastructure changes.

## Common scenarios (and which choice usually fits)

### “We already have a suite. We just need something quickly.”
Start bundled. Run a safe baseline and validate your internal comms, reporting workflow, and escalation paths.

### “We need audit-friendly evidence and trend reporting every month.”
Lean dedicated. Reporting consistency, segmentation, and repeatable workflows matter more than “included licensing.”

### “We have strict privacy expectations (works council / employee monitoring concerns).”
Choose the product that gives you the most control over data minimization, retention, and reporting granularity. In many orgs, that pushes toward dedicated platforms. See how [AutoPhish handles Anonymization and Privacy](https://autophish.io/anonymization)

## FAQ

### Is a bundled phishing simulation tool ‘good enough’?
It can be—especially for a pilot or a baseline. The gap appears when you need higher-frequency campaigns, cohort targeting, and evidence-grade reporting over time.

### Will a dedicated platform reduce risk more than a bundled tool?
Not automatically. Risk reduction comes from program design: frequency, guardrails, measurement, and follow-up. Dedicated platforms often make those practices easier to sustain.

### Can we use both?
Yes. Some teams start bundled to prove the program internally, then standardize on a dedicated platform for consistent reporting and broader coverage.

## Next step

If you want phishing simulations that are designed as a repeatable program—segmented, automated, and measurable with reporting your stakeholders can trust—AutoPhish is built for that operational reality.

[Sign Up](https://autophish.io/register)

Security teams search for a “GoPhish alternative” for a good reason: GoPhish is well-known, easy to find, and (for many orgs) tempting as a quick way to start phishing simulations.

But most teams don’t actually want “a phishing toolkit.” They want a repeatable awareness program that runs with **minimal operational overhead**: predictable scheduling, deliverability visibility, clean reporting, and governance that doesn’t depend on a single hero admin.

This article breaks down what to evaluate when you’re replacing (or choosing not to run) GoPhish—so you can deliver measurable awareness outcomes **and** make day‑2 operations boring (in the best way).

## When an “open-source phishing tool” is the wrong fit

Open-source phishing simulation tools can be useful in a lab or for a very narrowly scoped awareness exercise. The problem is not that they’re “bad”; it’s that most organizations need the *program* around the tool.

If you run a self-hosted phishing framework, you’re taking responsibility for:

- **Infrastructure and deliverability:** domains, mail routing, reputation, and troubleshooting.
- **Access control and auditability:** who can launch what, who can see results, and how changes are tracked.
- **Data handling:** what user data is stored, for how long, and how it’s anonymized or minimized.
- **Governance:** approvals, guardrails, and documented “what we do / what we don’t do.”

That’s why many teams move from “tooling” to a managed simulation and awareness platform.

If you want a deeper technical/business comparison of open-source vs managed approaches, start with this guide: [Open-source phishing simulation tools vs managed solutions](https://autophish.io/blog/open-source-phishing-simulation-tools-vs-managed-solutions-a-technical-and-business-comparison).

## What a strong GoPhish alternative should deliver

A good alternative isn’t just a UI with templates. It’s a system that makes safe, repeatable training the easiest path.

### 1) Operational simplicity (the real reason most teams move on from GoPhish)

GoPhish is easy to spin up. What’s hard is everything after that: deliverability issues, domain reputation problems, template drift, inconsistent reporting, and knowledge that lives in one person’s head.

A strong GoPhish alternative should make the *program* easy to run over months and years:

- **Automations:** recurring campaigns, reminders, and follow‑up training.
- **Template management:** consistent branding and localization without fragile copy‑paste workflows.
- **Multi‑tenant / multi‑company support:** for MSPs, groups, or subsidiaries.
- **Clear change management:** audit logs and predictable configuration.

If your awareness program relies on heroics, it won’t scale.

### 2) Reporting that security engineers actually trust

Awareness metrics are notoriously easy to game. The goal isn’t perfect numbers; it’s reliable signals that help you decide what to do next.

A strong platform should provide:

- **Cohort-based analysis:** departments, roles, locations, and risk groups—without turning the program into a blame machine.
- **Trend visibility:** outcomes over time, so you can tell whether changes are real.
- **Actionable breakdowns:** which scenarios, cues, and channels (email vs mobile) are driving outcomes.
- **Exportable evidence:** reports you can share with leadership and auditors.

If you’re building an internal risk narrative, tie your program to recognized guidance on training and awareness. For example, [NIST SP 800-50](https://csrc.nist.gov/publications/detail/sp/800-50/final) is a longstanding reference on building a security awareness and training program.

### 3) Privacy and data minimization (especially in the EU)

Simulations involve employee data. Even if your intent is defensive, you still need to handle personal data responsibly.

Evaluate:

- **Data minimization:** can you run useful campaigns without storing more than you need?
- **Retention controls:** can you automatically delete or anonymize historical data on a schedule?
- **Aggregated views:** can you coach teams without unnecessarily exposing individual-level data?
- **Transparency support:** does the platform help you communicate what’s being measured and why?

If privacy is a key requirement for your organization, you may also want to review AutoPhish’s approach to privacy-preserving training: [Privacy-friendly phishing training](https://autophish.io/blog/privacy-friendly-phishing-training-works-councils-consent-and-gdpr-essentials).

### 4) Guardrails (important, but they shouldn’t be your whole story)

You still want a platform that prevents obvious foot‑guns: reckless lure categories, accidental credential harvesting, or overly broad access to individual results.

Look for:

- **Policy-friendly defaults:** training-first outcomes instead of “gotcha” culture.
- **Role-based access control:** separation between campaign creators, approvers, and report viewers.
- **Scenario constraints:** the ability to block sensitive themes (payroll, layoffs, medical, legal threats) if your policy requires it.

The practical vendor question: *“Can we enforce our policy by default, or do we have to rely on trust and tribal knowledge?”*

## A pragmatic evaluation checklist (use this in vendor calls)

Use these questions to quickly determine whether a “GoPhish alternative” is actually built for awareness training (not just campaign sending):

1. **What’s your default stance on credential prompts?** (And can we enforce a policy, not just “trust admins”?)
2. **Can we require approvals before a campaign goes live?**
3. **How do you prevent sensitive lure categories?** (Payroll, layoffs, medical, legal threats.)
4. **Do you support mobile-first scenarios?** 
5. **Can we segment results without overexposing personal data?**
6. **What evidence can we export for internal governance?**
7. **How do you handle data retention and deletion?**
8. **How do you measure learning—not just clicks?**

This is also where an awareness platform can align with broader security and compliance efforts. You’re not “becoming compliant” by buying tooling—but you *can* build defensible, repeatable processes and records that support your security management system.

## How AutoPhish approaches phishing simulations (operationally simple by default)

AutoPhish is designed for teams that want the outcome of phishing simulations—measurable learning—without inheriting the day‑2 operational load of running a toolkit.

The core idea is simple: make the safe, repeatable program the path of least resistance.

- **Automation-first:** recurring campaigns and follow-up training without constant manual work.
- **Clear reporting:** evidence and trend visibility you can share with stakeholders.
- **Policy support:** guardrails exist, but they’re not the headline—they’re there so the program stays within boundaries.

Learn more about how the platform is structured here: [AutoPhish Features](https://autophish.io/about).

If you’re currently comparing approaches, it can help to start from the strategic question: do you want to own infrastructure and risk, or do you want to own outcomes? Many teams begin with an open-source tool and later migrate once they feel the operational and governance weight.

## Implementation tips (safe, non-technical)

You don’t need a “clever” simulation to get better outcomes. Consistency and clarity beat novelty.

- **Start with transparent guardrails:** define what scenarios are allowed, what’s off-limits, and how results are used.
- **Run small, frequent exercises:** shorter cycles produce faster learning and cleaner trend data.
- **Coach managers, not just individuals:** team-level patterns are usually where process fixes live.
- **Close the loop:** each campaign should lead to a concrete action (training module, process fix, comms update).

Two paragraphs of policy can save you months of internal friction.

## FAQ

### Will a managed platform make simulations less realistic?
Not necessarily. The point of realism is to teach recognition and safe behavior, not to demonstrate how far an attacker could go. The best programs balance realism with clear ethical and operational boundaries.

### What should we measure besides click rate?
Click rate is a weak proxy. Consider report ratio, completion of follow-up training, repeated exposure improvements, and scenario-specific outcomes. The best metric is the one that changes your next decision.

### Can phishing simulations help with ISO 27001, NIS2, or GDPR accountability?
Training and awareness programs often support security governance expectations, but they’re not a shortcut to compliance. Focus on building a documented process: roles, approvals, retention, reporting, and continuous improvement. That’s what makes the program defensible.

## Ready to run safer phishing simulations?

If you’re evaluating a GoPhish alternative because you want *less overhead and more measurable learning*, AutoPhish is built for that.

[Sign Up](https://autophish.io/register) to start your first controlled, automation-driven phishing simulation.

Image Credit: Stomchak, CC BY-SA 3.0, source: [Wikimedia Commons – File:Phishing.JPG](https://commons.wikimedia.org/wiki/File:Phishing.JPG)

Phishing simulations live or die on **reporting**.

Not “pretty charts”—but reporting that helps you:

- prove improvement over time (without blaming individuals),
- identify where training needs to change,
- and produce evidence that stands up in security reviews and audits.

If you’re evaluating a phishing simulation / awareness training solution, this guide breaks down the **phishing simulation reporting features** that matter most to security engineers, IT admins, CISOs, and compliance teams.

You’ll also see what “good” looks like for each feature—so you can compare tools consistently.

## What phishing simulation reporting is for (and what it’s not)

A mature phishing simulation program uses reporting to answer three questions:

1. **Risk & behavior:** Are users recognizing and reporting suspicious messages faster?
2. **Program quality:** Are we training the right things (by role, region, and threat pattern)?
3. **Governance & evidence:** Can we show what we ran, why we ran it, and what we changed based on results?

What reporting should *not* become:

- A “gotcha” leaderboard
- A punishment mechanism
- A vanity metric (e.g., obsessing over click rate without looking at reporting rate or follow-up training)

When reporting is used correctly, it becomes the link between security, IT operations, and compliance.

> Click here if you want to see how AutoPhish does Reporting: [AutoPhish Reporting](https://help.autophish.io/en/article/phishing-campaign-reports-analytics-ymehoj/)

## The 12 phishing simulation reporting features to compare

### 1) Clear campaign-level KPIs (not just user-level events)

At minimum, your reporting should make it easy to see—per campaign:

- delivery rate (sent vs delivered vs bounced)
- open rate (optional, depending on mail clients and privacy limitations)
- click rate
- report rate (how many users reported the simulation as suspicious)
- completion rate for follow-up training

Why it matters: campaign-level KPIs let you compare **like-for-like** runs (e.g., “invoice theme” in Q1 vs Q3) and avoid chasing noise.

### 2) Segmentation by role, department, and location (with guardrails)

Security teams need segmentation to tailor training:

- finance vs HR vs IT vs executives
- regions/languages
- office vs remote workers

But segmentation also creates privacy risk. Look for:

- configurable visibility (who can see what)
- aggregated views by default
- the ability to minimize or anonymize individual results where appropriate

If privacy is a priority in your org, review AutoPhish’s approach here: https://autophish.io/anonymization

### 3) Deliverability and email health reporting

Many programs “fail silently” due to deliverability:

- messages land in spam/quarantine
- domains or sending infrastructure get blocked
- tracking gets stripped

Strong reporting includes:

- bounce classification and trends
- domain/sender reputation signals (where available)
- per-recipient-domain results (e.g., Microsoft 365 vs Google Workspace)

Tip: before you blame users or templates, validate your DNS and alignment. AutoPhish provides a quick pre-check: https://autophish.io/dns-check

### 4) Evidence-friendly exports (PDF) with consistent definitions

Compliance and leadership reporting often requires offline artifacts.

Look for:

- PDF exports for board / audit packs
- consistent metric definitions across time (e.g., what exactly counts as a “click”)
- stable identifiers for campaigns and templates

If you can’t export consistently, you can’t show improvement credibly.

### 5) Trend views that support continuous improvement

A single campaign is a snapshot. Good reporting shows trends across:

- quarters and years
- role-based cohorts
- template themes (credential lure vs delivery notice vs document share)

Look for:

- rolling averages
- cohort comparisons
- seasonality-aware views (avoid comparing holiday periods to normal operations)

### 7) Training workflow reporting (what happens *after* the event)

A phishing simulation shouldn’t end at “clicked.”

Better programs track what happens next:

- auto-assigned micro-training
- completion monitoring
- repeated patterns (e.g., users repeatedly missing the same red flags)

If your platform includes a training experience, it should be reportable end-to-end. See: https://autophish.io/training-platform

### 8) Scoring and risk signals (careful, but useful)

Some tools create a “risk score.” This can be useful if:

- it’s transparent (how the score is calculated)
- it’s not used punitively
- it’s supported by behavior improvements and training completion

Avoid black-box scoring that can’t be explained to leadership or works councils.

### 9) Integration signals (ticketing, SIEM/SOAR, identity)

Even if you don’t integrate on day one, reporting should make integration plausible:

- webhook / API availability (for pulling campaign results)
- identity mapping (so you can segment accurately)
- evidence that the platform can fit your incident reporting workflow

Reporting that can’t leave the tool becomes a dead-end. Contact us to get API access for AutoPhish!

### 10) Privacy controls and retention reporting

Security awareness data can be sensitive.

Look for features that support responsible handling:

- configurable retention periods
- role-based access control
- aggregated-by-default reporting
- anonymization or data minimization options

If you need a privacy-first baseline, start here: https://autophish.io/anonymization

### 11) “Explainability” for non-security stakeholders

CISOs and compliance leaders often need to answer:

- What did we do?
- What changed?
- Is the program improving risk?

Reporting should include a narrative-ready view:

- campaign summary
- key changes since last campaign
- recommended next steps driven by results

This is one of the biggest gaps in DIY and early-stage programs.

### 12) Benchmarking (internal > external)

External benchmarks can be misleading because organizations differ in:

- industry threat profile
- mail security posture
- workforce composition

Prefer internal benchmarking:

- “Our reporting rate improved from X% to Y% after policy + training changes”
- “Time-to-report p90 dropped by Z days”

That’s defensible and actually actionable.

## A practical scoring checklist (copy/paste)

Score each item 0–2 (0 = missing, 1 = partial, 2 = strong):

- Campaign KPIs include report rate + time-to-report
- Segmentation exists with access controls
- Deliverability reporting is usable (bounces, trends)
- Export formats support audits (CSV/PDF)
- Audit trail exists (changes + approvals)
- Trend views support comparisons over time
- Follow-up training reporting exists
- Risk/scoring is explainable (or absent by choice)
- Integration path exists (API/webhooks)
- Privacy + retention controls are configurable
- Executive summary view exists
- Internal benchmarking is easy

A tool with a lower click rate but a higher report rate, better governance, and better evidence is often the better real-world choice.

## FAQ

### What is the most important metric in phishing simulation reporting?
There isn’t a single metric, but **report rate** and **time-to-report** often correlate better with organizational resilience than click rate alone.

### Should we track open rates?
Open rates can be unreliable due to mail client privacy protections and image blocking. Use them cautiously; focus on delivery, clicks (where measurable), reporting behavior, and training completion.

### Can phishing simulation reporting help with ISO 27001, NIS2, or GDPR accountability?
Reporting can support evidence collection and continuous improvement, but it does not “make you compliant.” Compliance depends on your policies, governance, lawful basis, access controls, and how you operate the program.

### How do we keep reporting from becoming a blame tool?
Default to aggregated reporting, keep access limited, focus on training outcomes, and avoid individual public rankings.

## Next step

If you’re comparing platforms and want reporting that’s operationally useful, privacy-aware, and easy to turn into audit-ready evidence, AutoPhish is built for security teams that need a repeatable program.

- Explore the platform: https://autophish.io/about
- See pricing: https://autophish.io/pricing
- **Sign up:** [Sign Up](https://autophish.io/register)

This post explains the **risks and theory** behind **SPF**, **DKIM**, and **DMARC**, and why **domain permutations (look-alike domains)** are the silent amplifier that turns “one spoofed email” into a brand, finance, and credential-theft disaster.

## The core problem: email was built for delivery, not identity

SMTP (the protocol that moves email around) was designed in an era where *trust* was implicit. By default:

- The **“From:”** header is just text.
- Anyone can attempt to send mail claiming to be `ceo@yourcompany.com`.
- Many mail systems historically accepted messages as long as they could be delivered.

Modern defenses add **domain-level authentication** on top of SMTP. That’s what SPF, DKIM, and DMARC do.

---

## SPF: “Which servers are allowed to send mail for my domain?”

**SPF (Sender Policy Framework)** is a DNS record that lists the mail servers (or sending services) allowed to send email *using your domain in the envelope-from / return-path*.

### How SPF works (theory)
When a receiving mail server gets a message, it checks:

1. What domain is used in the **envelope sender** (Return-Path).
2. Does that domain publish an SPF record in DNS?
3. Is the **connecting IP** allowed by that SPF record?

If yes → SPF passes. If not → SPF fails (or softfails/neutral depending on policy).

### Example SPF record
```txt
example.com. TXT "v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all"
```

### Common SPF failure modes (where attackers win)
- **Too permissive**: `v=spf1 +all` (basically “anyone can send”).
- **Softfail forever**: `~all` without DMARC enforcement, leading to “shrug” handling.
- **Missing includes**: your CRM, ticketing system, newsletter tool not listed → legitimate mail fails.
- **DNS lookup limit**: SPF has a **10 DNS-lookup limit**; complex `include:` chains can break delivery.
- **SPF only protects the envelope domain**: attackers can still make the *visible* From look like you unless DMARC is enforcing alignment.

**Bottom line:** SPF is necessary, but **not sufficient** for stopping spoofing.

---

## DKIM: “Was this email really sent by someone with the domain’s private key?”

**DKIM (DomainKeys Identified Mail)** adds a cryptographic signature to outgoing messages. The sender signs selected headers (and sometimes body) with a **private key**. The receiver fetches the **public key** from DNS and verifies the signature.

### How DKIM works (theory)
- Outbound mail server adds a header like:
  - `DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...`
- Receiver queries DNS:
  - `selector1._domainkey.example.com` → public key
- If signature matches → DKIM passes.

### Example DKIM DNS record
```txt
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
```

### DKIM failure modes (where attackers win)
- **No DKIM at all**: lots of domains still don’t sign mail consistently.
- **Selective signing**: only some systems sign (e.g., Microsoft 365 does, your marketing tool doesn’t).
- **Broken signatures**: forwarders/mailing lists can modify content/headers and break DKIM.
- **Weak/old keys**: short keys or long-lived keys increase risk (if compromised, impersonation becomes trivial).
- **Misaligned domain**: DKIM passes for a different domain than what users see in “From”.

**Bottom line:** DKIM is powerful because it’s cryptographic, but it needs **alignment and policy**—that’s DMARC’s job.

---

## DMARC: “What should receivers do if SPF/DKIM fails—and does it match my visible From?”

**DMARC (Domain-based Message Authentication, Reporting & Conformance)** ties everything together:

1. It requires that **SPF and/or DKIM pass**, and
2. They must be **aligned** with the **From:** domain users actually see.

Then it tells receivers what to do if authentication fails:  
- `p=none` (monitor only)  
- `p=quarantine` (send suspicious mail to spam/junk)  
- `p=reject` (block outright)

### DMARC alignment (the key concept)
Attackers love this gap:

- SPF passes for `random-sender.com`
- “From:” shows `ceo@yourcompany.com`

Without DMARC alignment, a message can look like it’s from you even if the authenticated domain is unrelated.

DMARC says: **the authenticated identity must match the visible From**, not just “something passed somewhere”.

### Example DMARC record (monitoring)
```txt
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"
```

### Example DMARC record (enforced)
```txt
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-fail@example.com; fo=1; adkim=s; aspf=s"
```

### DMARC failure modes (where attackers win)
- **Stuck at `p=none` forever**: you get reports, but spoofing still lands.
- **No reporting address / ignored reports**: you’re blind to who’s abusing your domain.
- **Misconfigured alignment**: legitimate services fail and you roll back enforcement.
- **Subdomain gaps**: without a subdomain policy, attackers spoof `anything.yourcompany.com`.
- **No external monitoring**: DMARC is not “set and forget” when tooling changes.

**Bottom line:** DMARC is the enforcement layer that turns SPF/DKIM from “signals” into “protection.”

---

## What attackers actually do with weak email authentication

Here are the high-impact abuse paths SPF/DKIM/DMARC help prevent:

### 1) CEO fraud / invoice redirection (BEC)
Attackers send emails that appear to be from leadership or finance to change IBANs, approve payments, or request gift cards. Even one successful spoof can cost more than a year of security tooling.

### 2) Credential harvesting
A perfect-looking email “from IT” pushes a fake Microsoft 365 login page. The moment credentials are captured, the attacker can pivot to real internal mailboxes and send *legitimate* phishing from inside your tenant.

### 3) Brand impersonation against customers/partners
Even if your internal team is trained, your customers aren’t. Spoofed messages can damage your reputation, trigger fraud, and create support nightmares.

---

## Domain permutations: the “look-alike domain” multiplier

Even with perfect DMARC enforcement, attackers can simply register **a different domain that looks like yours** and send from that.

Examples:
- `examp1e.com` (1 instead of l)
- `exarnple.com` (rn instead of m)
- `example-support.com`
- `example.com-security.net`
- `exämple.com` (IDN / homograph tricks)
- Different TLD: `example.co`, `example.net`, `example.io`

This is called **domain permutation / typosquatting** (and includes homograph attacks, combo-squatting, bitsquatting, and more).

### Why permutations are dangerous
- **Users read “shapes,” not strings**: a quick glance at a sender address is unreliable.
- **Mobile clients hide details**: many interfaces collapse or truncate sender info.
- **SPF/DKIM/DMARC won’t help**: those protect *your domain*, not look-alikes.
- **Attackers can build “legit-looking” infrastructure**: TLS certs, branded landing pages, realistic reply flows.

### Typical attack flow with a look-alike domain
1. Register a domain close to yours.
2. Set up SPF/DKIM/DMARC correctly (yes, attackers do this).
3. Send “urgent” messages to finance, HR, customers, or vendors.
4. Harvest credentials or redirect payments.
5. If a reply happens, keep the conversation going (thread hijacking style).

**Takeaway:** you need **both** authentication monitoring **and** look-alike detection.

---

## What “good” looks like: a practical baseline

If you want a clean, modern posture:

### SPF
- Exactly **one** SPF TXT record per domain.
- Only include the senders you actually use.
- End with `-all` once you’ve validated all sources.

### DKIM
- Ensure **every** sending platform signs mail.
- Rotate keys periodically.
- Use sufficiently strong keys (and don’t reuse keys forever).

### DMARC
- Start with `p=none` briefly to observe legitimate senders.
- Move to `p=quarantine`, then `p=reject`.
- Use strict alignment where possible (`aspf=s; adkim=s`).
- Consider subdomain policy (`sp=`) so subdomains aren’t a loophole.

### Domain permutations
- Monitor for look-alikes across common TLDs and obvious typo patterns.
- Prioritize ones that:
  - have MX records (can send/receive email),
  - host phishing pages,
  - are newly registered,
  - resemble brand + “billing / login / support”.

---

## Why continuous monitoring matters (even if you “set it up once”)

DNS changes for boring reasons—migrations, vendor switches, “quick fixes,” expired domains—and those boring changes can quietly break authentication.

Continuous monitoring catches:
- SPF lookup blowups after someone adds a new tool
- DKIM selectors removed or rotated incorrectly
- DMARC downgraded to `p=none`
- A suddenly-appearing look-alike domain that starts emailing your staff

That’s why AutoPhish now includes an **Email Security / DNS Scanner** for quick checks, and **continuous monitoring with alerts** for logged-in orgs.

---

## Quick checklist you can copy into your internal runbook

- [ ] SPF exists, is unique, and ends in `-all` (after validation)
- [ ] All mail sources are accounted for (M365/Google + marketing + support + transactional)
- [ ] DKIM enabled across all sources, keys not stale
- [ ] DMARC exists with reporting enabled
- [ ] DMARC enforced (`quarantine` or `reject`) with alignment configured
- [ ] Subdomains covered (`sp=` or explicit DMARC on subdomains)
- [ ] Look-alike domain monitoring enabled (typos + TLD swaps + combos)
- [ ] Alerting hooked to a real channel (email/Slack/Teams/ticketing)

---

## Check your domain in seconds (free)

Want a quick sanity check right now? Use the **AutoPhish DNS Checker** to instantly analyze your **SPF, DKIM, and DMARC** records:

- AutoPhish DNS Checker: https://autophish.io/dns-check

If you want ongoing protection, you can also set up **continuous monitoring** with an AutoPhish subscription—so you’ll get alerts when DNS records change or when look-alike domains are detected.


## Final thoughts

Email authentication (SPF/DKIM/DMARC) is one of the rare security moves that improves **both** protection **and** deliverability. Add look-alike monitoring, and you cover the two biggest impersonation vectors: **spoofing your domain** and **spoofing your brand**.


**Why mobile phishing matters in 2025**

*   **Smishing (SMS phishing) surged** and is a top vector for fraud in Europe; QR-based “quishing” is **rising fast**. [ENISA](https://www.enisa.europa.eu/sites/default/files/2025-02/Finance%20TL%202024_Final.pdf)
*   **WhatsApp/linked-device abuse:** state-aligned actors have shifted from email to messenger takeovers, often by tricking targets into scanning **WhatsApp Web QR codes**. Treat scans like passwords. [Microsoft+1](https://www.microsoft.com/en-us/security/blog/2025/01/16/new-star-blizzard-spear-phishing-campaign-targets-whatsapp-accounts/)
*   **MFA fatigue** forced a rethink of push approvals; Microsoft moved tenants to **number-matching** to blunt push-spam approvals. [Microsoft Learn+1](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-default-enablement)
*   **FBI/IC3** warn of QR-based fraud—including scams where unsolicited packages contain a QR that leads to credential theft or malware. [Internet Crime Complaint Center+1](https://www.ic3.gov/PSA/2025/PSA250731)

For incident color and “what went wrong”, skim our **[10 Wild Phishing Stories (2024–2025)](https://autophish.io/blog/10-wild-phishing-and-phish-adjacent-stories-from-2024-2025-including-important-lessons-learned)**—we highlight QR-assisted account takeovers and messaging-app pivots with concrete guardrails.

* * *

**The mobile-first phishing playbook (how attacks work)**

1.  **Smishing & messaging lures**  
    Short messages spoof delivery firms, toll fees, or IT resets. Links open credential pages, payment forms, or drive users to install rogue apps.
2.  **QR codes as login tokens**  
    WhatsApp/other apps use **QR to link devices**. A coerced scan = session takeover—even without a password. Policy should treat **“Scan to link” = sensitive auth step**.
3.  **MFA push abuse**  
    Attackers spam prompts until a tired user taps “Approve”. **Number-matching** (enter the on-screen code) and **geolocation/tenant context** reduce these approvals.
4.  **Malware on mobile**  
    Links typically **steal credentials**, but can also push malicious installs—more feasible on Android via sideloaded APKs; iOS is harder (App Store gate) but **risky profiles/0-click vulns** exist. Mobile protections like **Play Protect** reduce but don’t erase risk.

* * *

**What policies SMEs actually need (ready to adapt)**

Below are concise clauses you can drop into your **Acceptable Use**, **BYOD**, and **Messaging** policies. Each includes a control and a short “why”.

**1) BYOD: minimum security baseline**

*   **OS & patch level:** Personal devices used for work must run a **vendor-supported OS** and auto-update enabled. (Android, iOS, iPadOS).
*   **Device security controls:** Screen lock, encrypted storage, and the ability to **remote wipe work data** via MDM/Work Profile (COPE/COSU or Android Work Profile/iOS User Enrollment).
*   **App sources:** **No sideloaded apps** for work use; business apps must come from managed stores. (Android unknown-sources increase risk; Play Protect mitigates but isn’t a policy substitute.) [NCSC+2NCSC+2](https://www.ncsc.gov.uk/collection/device-security-guidance)

**Why:** NCSC’s device guidance stresses balancing usability with controls in BYOD; you want managed data separation and revocation. [NCSC+1](https://www.ncsc.gov.uk/collection/device-security-guidance/bring-your-own-device)

**2) Messaging & social apps (WhatsApp, Signal, iMessage, etc.)**

*   **Business use boundaries:** If messaging apps are used for business, restrict to **managed devices**; **no linking via QR** on unmanaged desktops.
*   **Linked devices monitoring:** Alert on **new linked devices**; require re-verification every 30 days.
*   **No sensitive approvals over chat:** Payments, bank detail changes, or SSO resets **must use ticket + callback** to a number from the directory.

**Why:** Threat actors are actively abusing messenger **linking** and QR. Treat a QR scan like an SSO login. [Microsoft](https://www.microsoft.com/en-us/security/blog/2025/01/16/new-star-blizzard-spear-phishing-campaign-targets-whatsapp-accounts/)

**3) QR code handling**

*   **Treat QR as credentials:** Scanning QR for login or device-linking equals entering a password; only scan **from trusted sources** on **managed devices**.
*   **Preview before open:** Staff must **preview the URL** (mobile browser/app supports this) and verify domain before opening.
*   **Block risky shorteners:** Filter common shorteners (except allowlisted business uses).

**Why:** FBI/IC3 documented QR fraud; attackers hide destinations and piggyback trust. [Internet Crime Complaint Center](https://www.ic3.gov/PSA/2025/PSA250731)

**4) MFA hardening (stop push fatigue)**

*   **Enforce number-matching** for push approvals across the tenant.
*   **Prefer phishing-resistant methods** (FIDO2/passkeys) and **disable SMS fallback** after enrollment. [Microsoft Learn+1](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-default-enablement)

**Why:** Push spam works; number-matching and passkeys meaningfully reduce abuse.

**5) Mobile browser & app controls**

*   **Safe browsing & app vetting:** Keep **Play Protect** on; block app installs from unknown sources; require managed app stores. [Google Help](https://support.google.com/android/answer/2812853?hl=en&utm_source=chatgpt.com)
*   **Profiles/configs:** Ban installation of **unapproved configuration profiles** on iOS; profiles can alter trust roots, VPN/DNS, or MDM—serious risk. [TechTarget](https://www.techtarget.com/searchmobilecomputing/tip/How-to-ensure-iPhone-configuration-profiles-are-safe)

**6) Payments & approvals over mobile**

*   **Dual-control + callback:** Any payment, supplier bank change, or gift card purchase requires **two approvers + callback** using a **known** number (not from the message).
*   **No “approve via link in SMS”** for finance/HR workflows.

**Why:** Classic BEC remains costly; process guardrails beat human judgment under time pressure.

**7) Reporting & response (fast lane)**

*   **Single tap to report:** Add a **Report SMS/Message** action in MDM help app; route to SecOps + vendor for takedown.
*   **Preserve evidence:** Staff should keep the message, screenshot the **full URL**, and note the time before deleting.
*   **Automated blocks:** Add sender and destination domains/hosts to mobile and email gateways; watch for newly linked devices.

* * *

**Rollout checklist**

1.  **Turn on number-matching** (Microsoft Entra ID) and review MFA methods; **prefer passkeys/FIDO2**.
2.  **Update BYOD policy** with the clauses above; require **managed app stores** & **no QR-linking on unmanaged desktops**.
3.  **Set MDM rules**: block unknown sources on Android, block unapproved **iOS profiles**, alert on new WhatsApp/Signal **linked devices**.
4.  **Run a bite-size training** using AutoPhish. For a Works-Council-friendly approach, use anonymized metrics—our [guide](https://autophish.io/blog/privacy-friendly-phishing-training-works-councils-consent-and-gdpr-essentials) explains how.

* * *

**FAQ**

**Q1) Can phishing be done by phone?**

Yes. **Smishing** (SMS) and **messenger DMs** are common phishing channels. Messages link to fake login pages, payment sites, or app installs; they may also attempt **voice phishing (vishing)** callbacks. CISA defines smishing as SMS-based social engineering and details how links can trigger actions on mobile. [CISA](https://www.cisa.gov/news-events/news/avoiding-social-engineering-and-phishing-attacks)

**Q2) Can phishing be used for identity theft?**

Absolutely. The goal is often **credential theft** (email, bank, cloud apps) or collection of personal data that enables account takeover and financial fraud. FBI/IC3 PSAs have repeatedly warned that QR/smishing campaigns harvest personal and financial data for fraud. [Internet Crime Complaint Center](https://www.ic3.gov/PSA/2025/PSA250731)

**Q3) Can a phishing link install malware on my phone?**  


Sometimes—**but** it usually needs extra steps.

*   On **Android**, a site might try to get you to **sideload an APK**; Play Protect reduces risk but allowlisting sources in policy is key. [Google Help](https://support.google.com/android/answer/2812853?hl=en&utm_source=chatgpt.com)
*   On **iOS**, direct installs are restricted; attackers may push **malicious configuration profiles** or exploit rare **zero-click** vulnerabilities. (Recent WhatsApp advisories highlight targeted zero-click issues that were patched; keep apps updated.) [TechTarget+1](https://www.techtarget.com/searchmobilecomputing/tip/How-to-ensure-iPhone-configuration-profiles-are-safe)Most of the time, the **bigger risk is credential harvesting and session theft**—which leads to identity fraud even without malware. [CISA](https://www.cisa.gov/news-events/news/avoiding-social-engineering-and-phishing-attacks)

**Q4) Are QR codes safe to scan?**

Treat QR codes like a **link**: only scan from trusted sources, prefer managed devices, and **preview the URL** before opening. FBI/IC3 specifically warned about QR-based schemes (including unsolicited items with embedded QR). [Internet Crime Complaint Center](https://www.ic3.gov/PSA/2025/PSA250731)

**Q5) Is WhatsApp phishing real if I have 2FA?**


Yes. Attackers can trick users into **linking a new device via QR**, bypassing passwords by stealing **session access**. Enable WhatsApp’s **two-step verification PIN**, monitor **linked devices**, and never link from an untrusted desktop. [Microsoft](https://www.microsoft.com/en-us/security/blog/2025/01/16/new-star-blizzard-spear-phishing-campaign-targets-whatsapp-accounts/)

**Q6) What should finance/HR do differently on mobile?**  


No approvals or bank changes via links or chat. Use **ticket + dual-control + callback** to a known number, every time. Our [incident recap](https://autophish.io/blog/10-wild-phishing-and-phish-adjacent-stories-from-2024-2025-including-important-lessons-learned) explains why this stops even slick deepfake/DM stunts.

* * *

**Further reading & resources**

*   **CISA mobile best practices** and why **FIDO/phishing-resistant MFA** beats SMS/app codes. [CISA](https://www.cisa.gov/sites/default/files/2024-12/joint-guidance-mobile-communications-best-practices_v2.pdf)
*   **NCSC BYOD guidance** to structure a sane, workable personal-device policy. [NCSC+1](https://www.ncsc.gov.uk/collection/device-security-guidance/bring-your-own-device)
*   **Microsoft on evolving identity attacks** (push fatigue → number-matching → passkeys). [Microsoft Learn+1](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-default-enablement)
*   **IC3 PSA on QR fraud** (current scams, reporting). [Internet Crime Complaint Center](https://www.ic3.gov/PSA)

* * *

**How AutoPhish can help**

*   **Mobile-aware simulations:** Safe **smishing**, **QR**, and **messenger-style** scenarios with instant coaching (coming soon)
*   **Policy-driven training:** Our [privacy-friendly training approach](https://autophish.io/blog/privacy-friendly-phishing-training-works-councils-consent-and-gdpr-essentials) keeps Works Councils onside while changing behavior.

## Why Role-Based Training Matters

Phishing is still the number one entry point for cyberattacks. According to [Verizon’s 2024 Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/dbir/), over 68% of breaches involve the human element, with phishing and stolen credentials leading the charge.  

The problem? Not all employees face the same risks. A finance controller has very different exposure compared to an HR manager or an IT helpdesk agent. This is why **role-based phishing simulations** are now considered best practice for any serious security awareness program.  

Instead of sending the same generic “password reset” email to everyone, role-based simulations:  

- Target specific job functions with realistic but safe scenarios.  
- Train employees on the threats they’re most likely to face.  
- Provide actionable metrics to improve defenses where they matter most.  

This blog post will walk you through **scenarios, guardrails, and KPIs** for the four most at-risk groups: Finance, HR, IT, and Executives. 

---

## Finance: Wire Transfers and Invoice Fraud

If you’re in finance, you’re on the front line of **Business Email Compromise (BEC)** attacks. Criminals impersonate suppliers, executives, or even regulators to trick employees into approving fraudulent payments. Losses from BEC scams exceeded [55 billion over the last 10 years](https://www.tripwire.com/state-of-security/bec-cost-citizens-worldwide-over-55bn-last-10-years).  

### Example Scenarios
- **Invoice Fraud:** Fake invoice request from a “supplier.”  
- **CEO Wire Request:** Spoofed executive email asking for urgent payment.  
- **Bank Verification:** Request to “confirm account details” via a link.  

### Guardrails for Simulations
- Don’t use personal/emotional triggers (“bonus payment” or “layoff list”).  
- Keep simulations clearly professional and finance-related.  

### Metrics to Track
- % of users who click the link.  
- % who attempt to initiate payment.  
- % who report the email via the phishing button.  

---

## HR: Payroll & Sensitive Data

HR departments are gold mines for attackers: payroll data, PII, and access to employee portals. Attackers often pose as staff requesting urgent changes.  

### Example Scenarios
- **Payroll Diversion:** Request to change direct deposit details.  
- **Resume Malware:** “Candidate” attaches a poisoned CV.  
- **Policy Update:** Fake HR portal login for compliance documents.  

### Guardrails for Simulations
- Never simulate life events like pregnancies, medical issues, or layoffs.  
- Avoid emotional manipulation — focus on administrative risks.  

### Metrics to Track
- % who download attachments.  
- % who enter credentials.  
- % who report the email via the phishing button.  

---

## IT: MFA Fatigue & Account Resets

IT staff are bombarded with requests — a perfect target for attackers abusing MFA fatigue or password reset flows.  

### Example Scenarios
- **MFA Push Flood:** Repeated login requests from “new device.”  
- **System Update:** Spoofed IT alert with a login link.  
- **Ticket Escalation:** Fake service desk message with embedded URL.  

### Guardrails for Simulations
- Make it clear this is *not* a test of job performance.  
- Avoid highly technical jargon that could confuse non-IT staff if simulations spill over.  

### Metrics to Track
- % of MFA prompts accepted without verification.  
- % who click malicious IT links.  

---

## Executives: High-Value Targets

Executives are prime targets for **whaling** (CEO fraud) and **contract scams**. Attackers know they’re busy, trust assistants, and often bypass standard processes.  

### Example Scenarios
- **Contract Signature:** Urgent DocuSign link for a new deal.  
- **M&A Leak:** Confidential acquisition “details” requiring login.  
- **Board Communication:** Fake message from a board member.  

### Guardrails for Simulations
- Don’t embarrass executives with trivial lures.  
- Keep tone professional; focus on decision-making risks.  

### Metrics to Track
- % of executives who click without verification.  
- Response time to report suspicious emails.  
- Cross-check with assistants/EA reporting behavior.  

---

## Cross-Department Simulation Guardrails

While each department has its nuances, there are common rules that keep simulations safe and constructive:  

1. **No “gotcha” emails.** Training should build trust, not resentment.  
2. **Stay professional.** Avoid personal or sensitive themes.  
3. **Be transparent.** Communicate to staff that simulations are ongoing and for their protection.  
4. **Respect works councils and privacy.** Tools like [AutoPhish](https://autophish.io/anonymization) anonymize results and support GDPR compliance.  

---

## Building a Simulation Roadmap

Here’s how to scale role-based training:  

1. **Phase 1:** Start broad — generic phishing for all staff.  
2. **Phase 2:** Introduce role-based simulations by department. This can easily be done by using AutoPhish's campaign feature, setting up role-based campaigns.
3. **Phase 3:** Cross-department scenarios (e.g., fake invoice sent to both Finance and Execs).  
4. **Phase 4:** Adaptive campaigns.  

This phased approach avoids overwhelming staff and shows measurable improvement.  

---

## Final Thoughts

Role-based phishing simulations are no longer a “nice to have.” They’re the difference between a generic awareness program and one that actually reduces risk where it matters most.  

By focusing on **scenarios, guardrails, and metrics**, you can train Finance, HR, IT, and Executives in the threats that target them directly — and build a culture of resilience.  

Ready to see it in action? Try [AutoPhish](https://autophish.io/) today and make your next simulation smarter, safer, and role-aware.  



## TL;DR

- **Lure** → **Capture** → **Session/Token theft** → **Lateral movement** → **Impact**  
- Identity + **session** protection is everything—and the fastest path to durable resilience is frequent, realistic practice that builds instinct.

## Intro

If you’re wondering **how phishing works** in 2025, here’s the honest answer: attackers rarely stop at passwords — they want your **session**. And if they can’t get you by email, they’ll try a QR code on your phone, a slick SaaS consent screen, or even a deepfaked video call with your “CFO.” Fun (for them).

Below is the modern kill chain most incidents follow—plus where **AutoPhish** makes you much harder to fool.

## 1) The Lure: email, QR, and scarily convincing “humans”

Phishing still arrives by **email**, but URLs are the star. Proofpoint’s latest **Human Factor 2025** research shows URLs are used _around four times_ more than attachments in malicious emails—and **4.2 million QR-code (quishing) threats** were flagged in just the first half of 2025 ([blog overview](https://www.proofpoint.com/us/blog/email-and-cloud-threats/human-factor-vol-2-offers-new-insights-phishing), [Vol. 2 report page](https://www.proofpoint.com/us/resources/threat-reports/human-factor-url-phishing)).

Then there’s the human layer: **deepfake video/voice**. The Arup case—~$25M lost after a deepfaked group call—shows how social engineering now looks like a perfectly normal meeting invite ([Guardian](https://www.theguardian.com/technology/article/2024/may/17/uk-engineering-arup-deepfake-scam-hong-kong-ai-video), [World Economic Forum](https://www.weforum.org/stories/2025/02/deepfake-ai-cybercrime-arup/)). Policies that require secondary verification beat “vibes” every time.

Want a field guide to spot the tricks inside a single message? Start with **[The Anatomy of a Modern Phishing Email](https://autophish.io/blog/the-anatomy-of-a-modern-phishing-email-what-your-employees-miss-every-day)** on our blog.

---

## 2) Capture: credentials _or_ consent—both open the door

Attackers don’t always ask for your password. Increasingly, they present a legit-looking **SaaS/OAuth consent screen** (“Allow this app to read your mail?”). If you click **Allow**, they gain durable API access—**no password needed**. Microsoft’s guidance on **illicit consent grants** explains detection and remediation ([Microsoft Learn](https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent) [Microsoft Learn 2](https://microsoft.com/en-us/defender-office-365/detect-and-remediate-illicit-consent-grants); also see the [app-consent incident response playbook](https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent)).

Old-school **credential harvesters** still work, often hosted behind reputable services (forms/storage/view-only files) to dodge filters. Proofpoint’s *Human Factor* series and Microsoft’s threat posts highlight the shift toward URL-centric delivery ([Proofpoint](https://www.proofpoint.com/us/resources/threat-reports/human-factor-url-phishingng), [Microsoft](https://www.microsoft.com/en-us/security/blog/2024/10/08/file-hosting-services-misused-for-identity-phishing/)).

---

## 3) Session/Token theft: bypassing MFA with a tiny man-in-the-middle

Here’s the 2025 twist: **Adversary-in-the-Middle (AiTM)** toolkits sit between you and Microsoft/Google, **proxy the login**, and **steal your session cookie** after you successfully pass MFA. The attacker then **replays** that cookie and walks right in—**no password, no second factor**. See Microsoft’s analyses and playbooks, plus Proofpoint and Talos reporting ([MSFT Security Blog](https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/); see also:
- [Cisco Talos IR:](https://blog.talosintelligence.com/ir-trends-q2-2025/)ry-point-to-further-financial-fraud/), 
- [Multi‑stage AiTM](https://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/), 
- [Session‑cookie theft alert playbook](https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent)
- [Proofpoint on AiTM](https://www.proofpoint.com/us/blog/email-and-cloud-threats/aitm-phishing-attacks-evolving-threat-microsoft-365)
- [Talos IR Q2 2025](https://blog.talosintelligence.com/ir-trends-q2-2025/).

---

## 4) Lateral movement: once inside, attackers get comfy

With mailbox or token access, attackers set **inbox rules**, register **malicious OAuth apps**, and pivot to perform **BEC**—sometimes for weeks before anyone notices (see Microsoft’s guidance on session-cookie theft alerts: [learn.microsoft.com](https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent)). For real-world color (and quick guardrails), see **[10 Wild Phishing (and Phish-Adjacent) Stories from 2024–2025](https://autophish.io/blog/10-wild-phishing-and-phish-adjacent-stories-from-2024-2025-including-important-lessons-learned from-2024-2025-including-important-lessons-learned)**.

---

## 5) What actually stops this? (Practical controls)

- **Phishing-resistant MFA (passkeys/FIDO2)** and limiting weak fallbacks (SMS/voice codes). CISA and NIST‑aligned guidance: [CISA success story (USDA)](https://www.cisa.gov/news-events/alerts/2024/11/20/usda-releases-success-story-detailing-implementation-phishing-resistant-multifactor-authentication), [CISA HISG on passkeys](https://www.cisa.gov/resources-tools/services/hybrid-identity-solutions-guidance-hisg), and the **Phishing‑Resistant Authenticator Playbook** ([IDManagement.gov](https://www.idmanagement.gov/playbooks/altauthn/)). For a plain‑English explainer, see WIRED’s overview of [how passkeys work](https://www.wired.com/story/what-is-a-passkey-and-how-to-use-them/).
- **Consent governance:** block risky OAuth app consent, require admin approval, and educate users about **what an app is asking for** ([Microsoft Learn](https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent).
- **Anti‑AiTM controls:** conditional access with **token binding** where possible, vigilant revocation of sessions, and alerts on unusual inbox rules ([MSFT Token Theft Playbook](https://learn.microsoft.com/en-us/security/operations/incident-response-playbook-app-consent)icrosoft.com/en-us/security/operations/token-theft-playbook)).
- **User behavior:** treat **QR codes** like links; don’t scan from unsolicited messages. Proofpoint’s 2025 data shows quishing is mainstream now ([Proofpoint blog](https://www.proofpoint.com/us/blog/email-and-cloud-threats/human-factor-vol-2-offers-new-insights-phishing)).

---

## Where AutoPhish makes a measurable difference

AutoPhish is designed around those exact failure points (and it’s EU/GDPR‑friendly by design):

- **Role‑aware realism.** We generate **ever‑fresh lures** per role and industry (finance, HR, execs)—covering **emails**, **QR campaigns**, and **SaaS‑consent** prompts. That builds instinct against the attacks people actually face. Learn how we do it in **[Phishing Simulations‑as‑a‑Service Explained](https://autophish.io/blog/phishing-simulations-as-a-service-explained-smarter-employee-training-with-autophish)**.
- **Kill‑chain‑aware simulations.** We don’t stop at a click—we teach what a **consent screen** looks like, why it’s risky, and how to respond (see also our **[Anatomy of a Modern Phishing Email](https://autophish.io/blog/the-anatomy-of-a-modern-phishing-email-what-your-employees-miss-every-day)** guide).
- **Just‑in‑time training + clear reports** you can take to audits (NIS2/ISO‑friendly). If you’re weighing formats, compare **[Automated vs. Manual Campaigns](https://autophish.io/blog/automated-phishing-testing-vs-manual-campaigns-which-is-best-for-your-business)**.
- **Employee‑friendly & GDPR‑smart.** Options for **anonymization/pseudonymization**, short retention, and works‑council‑compatible guardrails—because culture and compliance matter. Details: **[Privacy‑Friendly Phishing Training](https://autophish.io/blog/privacy-friendly-phishing-training-works-councils-consent-and-gdpr-essentials)**.

Curious about open-source vs. SaaS trade‑offs? We’ve compared them in **[Open‑Source Tools vs. Managed Solutions](https://autophish.io/blog/open-source-phishing-simulation-tools-vs-managed-solutions-a-technical-and-business-comparison)**.


## FAQ: How phishing works

**Can a phishing link install malware?**  
Yes. A link can trigger a **drive‑by download** or lead to a site that drops malware—or it can simply steal your credentials. Keep software patched, use reputable endpoint protection, and avoid opening links/attachments from unknowns ([Emsisoft explainer](https://www.emsisoft.com/en/blog/38301/drive-by-downloads-can-you-get-malware-just-from-visiting-a-website/), [Kaspersky](https://usa.kaspersky.com/resource-center/definitions/drive-by-download)).

**Can phishing be done by phone?**  
Absolutely. **Vishing** (voice) and **smishing** (SMS) are mainstream—often augmented with AI voice cloning. Verify through a known channel before acting (definitions from the [FBI](https://www.fbi.gov/how-we-can-help-you/scams-and-safety/common-frauds-and-scams/spoofing-and-phishing) and [FCC](https://www.fcc.gov/avoid-temptation-smishing-scams)).

**What is “quishing”?**  
**QR‑code phishing**: a message/poster contains a QR code that sends you to a malicious site—often on your **phone**, away from enterprise protections. Treat QR codes like links; don’t scan from unsolicited messages (see Proofpoint’s 2025 data on QR threats: [overview](https://www.proofpoint.com/us/blog/email-and-cloud-threats/human-factor-vol-2-offers-new-insights-phishing)).

**Does MFA stop all phishing?**  
MFA is essential, but **AiTM** can steal the **session cookie after MFA**. Prefer **phishing‑resistant MFA (passkeys/FIDO2)** and disable weak fallbacks (SMS/voice) where you can ([MSFT on AiTM](https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/; see also https://www.microsoft.com/en-us/security/blog/2023/06/08/detecting-and-mitigating-a-multi-stage-aitm-phishing-and-bec-campaign/; Cisco Talos IR: https://blog.talosintelligence.com/ir-trends-q2-2025/)); [CISA playbooks](https://www.idmanagement.gov/playbooks/altauthn/).

**What’s OAuth consent phishing, in one sentence?**  
A malicious app asks for permission to your data; if you click **Allow**, it keeps API access **until consent is revoked**—even without your password ([Microsoft Learn](https://learn.microsoft.com/en-us/defender-office-365/detect-and-remediate-illicit-consent-grants)).


> Want this explained to your whole team—with hands‑on practice? Launch a monthly, role‑aware program in minutes with **AutoPhish**. Make your people the firewall.

QR codes turned into logins. AI impersonated your CFO on Zoom. “Internal” emails arrived from the great beyond. The past two years were a nonstop parade of inventive cons – equal parts brazen and brilliant. Below, we tour ten real incidents that defined the era and, more importantly, translate each one into plain-English guardrails you can put in place. Sources are linked throughout so you can go deeper whenever you like.

**1) Change Healthcare: one portal, no MFA, and a very expensive lesson (Feb 2024)**

In February 2024, attackers walked through the digital front door at Change Healthcare using **stolen credentials**—no alarms, no second factor, just a remote portal without MFA. The breach eventually spiraled into ALPHV/BlackCat ransomware and nationwide disruption in healthcare billing. Executives later testified that the compromised entry point **did not** have MFA enabled—an omission that reads like a plot twist you can see coming a mile away ([Reuters](https://www.reuters.com/world/us/unitedhealth-ceo-testifies-before-us-senate-house-hack-2024-05-01/); context via [Cybersecurity Dive](https://www.cybersecuritydive.com/news/change-healthcare-compromised-credentials-no-mfa/714792/); sector wrap-ups from the [AHA](https://www.aha.org/system/files/media/file/2025/02/Change-Healthcare-Cyberattack-Underscores-Urgent-Need-to-Strengthen-Cyber-Preparedness.pdf) and [HHS OCR](https://www.hhs.gov/hipaa/for-professionals/special-topics/change-healthcare-cybersecurity-incident-frequently-asked-questions/index.html)).

Why did it work? Because one non-MFA’d app is a skeleton key in a world drenched in infostealer logs and password reuse. The countermeasure is gloriously unsexy: **phishing-resistant MFA (FIDO2)** everywhere the public can see you, ideally behind **SSO + conditional access**, with legacy protocols turned off. Add basic anomaly alerts—impossible travel, odd ASNs, strange hours—and you at least get a fighting chance to catch the first footsteps.

**2) Pepco Group: classic BEC, polished like a diamond (Feb 2024)**

Pepco’s Hungarian business lost about **€15.5 million** to what reads like a textbook—but extremely well executed—**business email compromise**. No malware extravaganza; just convincing messages, authority, urgency, and a payment process that trusted the inbox too much ([company notice](https://www.pepcogroup.eu/media-news/pepco-group-n-v-notice-regarding-hungarian-business/) / [PDF](https://www.pepcogroup.eu/wp-content/uploads/2024/02/Pepco-Group-Notice-regarding-Hungarian-business-vF.pdf); coverage via [Reuters](https://www.reuters.com/technology/cybersecurity/retailer-pepco-loses-about-15-mln-euros-hungarian-phishing-attack-2024-02-27/) and [Help Net Security](https://www.helpnetsecurity.com/2024/02/28/pepco-phishing-bec-attack/)).

The fix is cultural as much as technical: treat money movement like a cockpit checklist. **Dual approvals**, **callback verification to known numbers**, supplier portals with **2FA**, and a **hold period** for first-time bank-detail changes transform “please pay this urgently” into “sure—after we follow the process.”

**3) The Arup deepfake boardroom: when faces lie (Jan–May 2024)**

A finance employee at **Arup** joined a video call with the “CFO” and colleagues. They looked right, sounded right, moved right—and were **AI deepfakes**. Roughly **$25 million** left the building before reality caught up ([Financial Times](https://www.ft.com/content/b977e8d4-664c-4ae4-8a8e-eb93bdf785ea); [CFO Dive](https://www.cfodive.com/news/scammers-siphon-25m-engineering-firm-arup-deepfake-cfo-ai/716501/); background via [CNN/Yahoo](https://finance.yahoo.com/news/british-engineering-giant-arup-revealed-030558740.html)).

We’ve trained people to “trust the face.” Deepfakes torch that instinct. The pragmatic fix is policy, not paranoia: **no funds released on live calls alone**. Require a **ticketed approval** plus a **verbal callback** to a number pulled from an internal directory—never from the email or the meeting invite. Teach teams to spot telltales (lip-sync drift, odd latencies) and to use backchannels when something feels off.

**4) Paris 2024: the Olympics of fake ticketing (mid-2024)**

Hype, scarcity, and immaculate branding make for superb phishing weather. Heading into Paris 2024, law enforcement and researchers flagged **hundreds of fraudulent sites** hawking tickets, hospitality, and “priority access.” At one point the French gendarmerie counted **338** suspect domains. The playbook was simple: SEO-poisoning, cloned logos, and urgency that makes even savvy buyers forget their rules ([Proofpoint](https://www.proofpoint.com/us/blog/threat-insight/security-brief-scammers-create-fraudulent-olympics-ticketing-websites); consumer warnings via [CBS News](https://www.cbsnews.com/news/paris-olympics-ticket-scams/); official notices at [Olympics.com](https://www.olympics.com/en/news/free-ticket-scam-for-the-opening-ceremony-of-the-paris-2024-paralympic-games)).

If your staff travel or buy event access, front-load the safety briefing: **type, don’t click**, and only on **official URLs**. On the backend, watch for **typosquats** and block **brand-new domains** in high-risk categories for a cooling-off period. A little friction beats expensive FOMO.

**5) Snowflake-linked breaches: one password to rule them all (spring–summer 2024)**

Ticketmaster, Santander, and others reported data accessed via **customer Snowflake environments**, with a familiar villain: **stolen credentials** and **missing MFA**. Snowflake itself said its platform wasn’t breached; rather, attackers rode in on real keys to customer instances and got to querying ([Dark Reading](https://www.darkreading.com/threat-intelligence/snowflake-account-attacks-driven-by-exposed-legitimate-credentials); [The Verge](https://www.theverge.com/2024/6/11/24176080/snowflake-cloud-storage-data-breach-ticketmaster-santander); [Google Threat Intelligence](https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion); [Push Security](https://pushsecurity.com/blog/2024-identity-breaches/)).

If your data lives in SaaS, treat identity like your new network perimeter. Put **SSO/SAML + MFA** in front, add **IP allowlists/VPN**, and instrument for **unusual query volumes** or sudden **role changes**. Keys and tokens should rotate the way you change the batteries in a smoke alarm: regularly, before the fire.

**6) Star Blizzard’s WhatsApp pivot: your QR code is a session token (late 2024–Jan 2025)**

FSB-linked **Star Blizzard** started corralling diplomats and policy folks into scanning **WhatsApp QR codes**, turning a simple handoff into account takeover. The move cleverly sidestepped email controls and shifted the conversation to a compromised app where trust is high and scrutiny is low ([Microsoft](https://www.microsoft.com/en-us/security/blog/2025/01/16/new-star-blizzard-spear-phishing-campaign-targets-whatsapp-accounts/); [BleepingComputer](https://www.bleepingcomputer.com/news/security/star-blizzard-hackers-abuse-whatsapp-to-target-high-value-diplomats/); [The Guardian](https://www.theguardian.com/technology/2025/jan/17/russian-hackers-star-blizzard-whatsapp-accounts-ministers-officials)).

The mindset shift is crucial: **QR codes often _are_ authentication**. Train people to treat scans like passwords, restrict linking on unmanaged devices via MDM, and require **number-matching MFA** where available. Also, watch for **new linked devices** and suspicious location jumps—both are early smoke.

**7) Quishing at scale: Microsoft Sway as a lure factory (Aug 2024)**

Attackers leaned on **Microsoft Sway** to host slick, **QR-code phishing** pages that slipped past filters thanks to first-party halo effects. The QR image concealed the true destination, and scanners not built to decode images saw only a nice, clean file hosted by a trusted brand ([BleepingComputer](https://www.bleepingcomputer.com/news/security/microsoft-sway-abused-in-massive-qr-code-phishing-campaign/"%20\t%20"_new); original research from [Netskope](https://www.netskope.com/blog/phishing-in-style-microsoft-sway-abused-to-deliver-quishing-attacks)).

Defenders can answer in kind: add **QR decoding** to email/web security, scrutinize **new Sway/Forms/Sites** links, and lock identity down with **passwordless MFA**, **conditional access**, and **continuous access evaluation**. On mobile, teach people how to preview URLs before opening them—tiny skill, huge payoff.

**8) Trezor: when your support desk becomes the social engineer (Jan 2024 & Jun 2025)**

In **January 2024**, a **third-party support portal** tied to **Trezor** exposed contact details for ~66,000 users—jet fuel for follow-on phishing. By **June 2025**, adversaries went a step further, **abusing Trezor’s support form** to send convincing auto-replies that looked official enough to make even veterans blink ([BleepingComputer](https://www.bleepingcomputer.com/news/security/trezor-support-site-breach-exposes-personal-data-of-66-000-customers/"%20\t%20"_new); [BleepingComputer](https://www.bleepingcomputer.com/news/security/trezors-support-platform-abused-in-crypto-theft-phishing-attacks/)).

Your support stack is part of your security perimeter. Treat it accordingly: **rate-limit auto-replies**, enforce strict **DKIM/DMARC alignment**, scan templated responses for risky language (especially around “recovery” and crypto), and publish **clear safety PSAs** so customers know what you’ll never ask them to do.

**9) “Internal” without compromise: M365 Direct Send gets cheeky (Jun–Aug 2025)**

Campaigns abusing **Microsoft 365’s Direct Send** made it possible to **spoof internal users** without actually taking over an account. That little detail matters, because “from IT@yourcompany” still carries psychological weight—even when the authentication story is mushy ([Varonis](https://www.varonis.com/blog/direct-send-exploit); summaries via [Dark Reading](https://www.darkreading.com/cyber-risk/phishers-abuse-m365-direct-send-to-spoof-internal-users) and [Arctic Wolf](https://arcticwolf.com/resources/blog/arctic-wolf-observes-microsoft-direct-send-abuse/)).

Tighten your **connector rules**, limit the scope of Direct Send, and prefer **authenticated SMTP** where you can. Teach people that “internal” isn’t a magic word; if an email tries to move money or credentials, the verification should happen in a portal or via a known backchannel—not a convenient blue link.

**10) AI site builders drafted into the phish factory: Lovable at scale (2025)**

Finally, a very 2025 plot line: attackers using AI website builders—**Lovable** in particular—to crank out **tens of thousands** of phishing and malware pages with on-brand design and near-instant turnaround. Fresh domains plus pretty templates equals a steady drip of clicks before reputation systems catch up ([Proofpoint](https://www.proofpoint.com/us/blog/threat-insight/cybercriminals-abuse-ai-website-creation-app-phishing); coverage via [BleepingComputer](https://www.bleepingcomputer.com/news/security/ai-website-builder-lovable-increasingly-abused-for-malicious-activity/) and [TechRadar](https://www.techradar.com/pro/security/top-ai-website-builder-lovable-hit-in-worrying-cyberattack-heres-what-we-know)).

Defensively, expand your URL intelligence to include **time-since-registration** and **builder/hosting reputation**, and don’t reflexively whitelist shiny new domains just because they look professional. Criminals can look professional now, too—it’s kind of their thing.

**The pattern you can’t ignore**

Across all ten stories, the same threads keep showing up. **Credentials and session tokens are gold.** **MFA gaps are fatal.** **“Internal” is a feeling, not a control.** And **AI is both accelerant and firehose**—it speeds up attackers and overwhelms defenders, but it also gives us better training and detection if we choose to use it.

If you only do a few things this quarter, make them these: roll out **phishing-resistant MFA** and retire legacy auth; add **QR decoding** to your email/web stack; stage realistic **BEC and deepfake drills** for finance and execs (with mandatory callbacks); and put **support, marketing, and event workflows** squarely in your threat model with rate limits, DMARC alignment, and pre-emptive warnings.

And if you want to practice safely, that’s our jam. AutoPhish can recreate the trends you’ve just read about—**quishing**, **AI-style lures**, **“internal” spoofing**, and meticulous **BEC**—then follow up with bite-sized training that actually sticks. Because seeing the trick once, in a safe environment, is how you stop it when it really counts.

> ⚖️ This article is general information - for specific decisions about your organisation, consult a qualified lawyer in your jurisdiction.

---

## TL;DR
You can run impactful phishing simulations in the EU without alienating staff or risking non-compliance by: 
1. using **legitimate interests** (not consent) as your primary legal basis and documenting a balancing test; 
2. engaging **works councils** early and codifying guardrails in a works agreement where required; 
3. prioritising **anonymization/pseudonymization**, **short retention**, and **transparent notices**; and 
4. running a DPIA if your context points to **high risk** (e.g., systematic monitoring).

---

## 1) Lawful basis: why **legitimate interests** usually beats consent
In the employment context, consent is **rarely freely given** because of the employer–employee power imbalance. The European Data Protection Board’s *Guidelines 05/2020 on Consent* underline that employee consent is valid only in **exceptional** circumstances without adverse consequences for refusal. For phishing simulations, a better fit is **Article 6(1)(f) legitimate interests**, documented with a **Legitimate Interests Assessment (LIA)** that weighs your security needs against employees’ rights and expectations.

**Good practice for the LIA**  
- Define the interest (security awareness; fraud prevention).  
- Map reasonable employee expectations (training is normal; covert profiling is not).  
- List mitigations (see Sections 3–5).  
- Record why consent would be inappropriate in your context.

References: EDPB *Guidelines 05/2020 on Consent*; GDPR Recital 47 (reasonable expectations).

---

## 2) Works councils: Germany & Austria in focus
If you operate in countries with strong co-determination, involve the works council before rollout.

- **Germany (BetrVG §87(1) No. 6):** the works council co-determines the *“introduction and use of technical devices designed to monitor employee behaviour or performance.”* Even simple dashboards can trigger this, so a **Betriebsvereinbarung** (works agreement) that sets scope, data handling, and safeguards is common practice.  
- **Austria (ArbVG §96(1) No. 3):** monitoring measures and technical systems that may affect human dignity require **works council consent** (or **individual consent** if no works council).

**What to include in the agreement/works policy**  
Purpose & scope, lawful basis, minimal data collected, **no disciplinary use** of metrics alone, who sees what, retention & anonymization schedule, vendor list (processors/sub-processors), employee rights, and an annual review clause.

Sources: Germany—BetrVG §87(1) no. 6 (official English text); analysis by Luther Law. Austria—Eurofound summary of ArbVG §96(1) no. 3; Schoenherr explainer.

---

## 3) Anonymization vs. Pseudonymization (and what it means for reports)
- **Anonymization** (GDPR Recital 26): once data is truly anonymous, GDPR no longer applies.  
- **Pseudonymization** (GDPR Art. 4(5)): data is still personal if it can be re-linked via separate keys; treat it accordingly.

**Privacy-centric reporting model**  
- Default to **aggregates by team/location**.  
- Use **stable random IDs** for trend analysis instead of names; keep the key separate with strict access control.  
- Show **individual results only to a small, need-to-know group** (e.g., security awareness lead + HR) and only when necessary for targeted coaching.  
- Never collect real passwords; if a user attempts to submit credentials, show a training page and **discard any entry**.

For a practical example of how a platform implements these concepts, see **AutoPhish’s anonymization** overview: https://autophish.io/anonymization

---

## 4) Retention: shorter is safer (and required by principle)
GDPR’s **storage limitation** principle requires keeping personal data in identifiable form **no longer than necessary** for the stated purpose. For phishing programs, many SMEs adopt a two-tier window:  
- **Operational window (e.g., 30–90 days):** identifiable data available for coaching and remediation.  
- **Post-campaign analytics:** thereafter **aggregate/anonymize**, keeping only non-identifiable trends for long-term KPI tracking.

Document this in your **Article 30 records of processing** and in your employee privacy notice.

---

## 5) Notices: be transparent and plain-language (Art. 13)
Before your first campaign, provide a short internal notice (or update your employee privacy policy) that explains: the **purpose** (security awareness), **lawful basis** (legitimate interests), what data you collect (e.g., email, department, click/report events), **retention**, who can access individual-level data (limited roles), **no disciplinary use** of single events, **employee rights** (access/objection), and a **contact** (DPO or privacy lead).

**Copy-paste starter (adapt to your context)**  
> We run periodic phishing simulations to build security awareness and reduce fraud risk. We process your name, work email, department, and simulation interactions (e.g., opened/reported/submitted). Our lawful basis is legitimate interests (GDPR Art. 6(1)(f)). Individual-level data is visible only to the security awareness team (and HR where necessary for targeted coaching). We keep identifiable data for **[X days]** and then aggregate/anonymize. We never store real passwords. You can exercise your data rights (access/objection, etc.) via **[contact]**. See **[link to your full employee privacy notice]**.

---

## 6) Do you need a DPIA?
A **Data Protection Impact Assessment (DPIA)** is required when processing is **likely to result in high risk** to individuals (Art. 35). Regulators and the EDPB note that **employee monitoring** may trigger a DPIA—especially where processing is systematic or involves vulnerable data subjects. If your programme introduces new tooling, large-scale metrics, or cross-border transfers, err on the side of conducting a DPIA.

**What to cover**: purpose/necessity, alternatives (less intrusive options), data flows, risks, mitigations (anonymization, minimization, role-based access, short retention, no-blame coaching), and a plan for periodic review.

---

## 7) Vendors & international transfers
If you use a platform provider, you’re the **controller** and they’re a **processor**; sign a **Data Processing Agreement** that meets **Article 28** requirements (security, sub-processor controls, assistance with data rights, deletion at end of service). If the provider or its sub-processors are outside the EEA, implement the **Standard Contractual Clauses** and perform a transfer risk assessment.

---

## 8) NIS2: if you’re in scope, training is no longer optional
For entities covered by the **NIS2 Directive**, management must oversee cybersecurity risk-management measures (Art. 20) and ensure appropriate training and incident processes (Art. 21). Even if you’re not in scope, the bar NIS2 sets is a useful benchmark for SMEs.

---

## 9) A practical, privacy-first architecture (that still works)
- **Data in:** name, email, team, and manager (optional). No personal emails; no special categories.  
- **During campaign:** collect only **event data** (delivered, clicked, reported, submitted). If a user tries to enter credentials, show training and capture **no secrets**.  
- **Access control:** the awareness team can see cohorts and anonymized IDs
- **Retention:** 30–90 days for identified data → auto-anonymize; keep aggregates for year-over-year trends.  
- **Outputs:** exec report shows **rates and trends**, not names.  
- **Governance:** LIA + (if needed) DPIA on file; Article 30 register updated; works agreement approved.

---

## Final thoughts
Privacy-friendly phishing training is not a contradiction. With the right lawful basis, genuine worker representation, and technical guardrails like anonymization and short retention, your programme can **protect people and their data** while measurably reducing risk. When in doubt, get legal advice tailored to your facts.

## Legal references (Germany & Austria)

*   **Germany — Works Constitution Act (BetrVG) §87(1) no. 6 (official English text)**  
    [Gesetze im Internet – Works Constitution Act (Betriebsverfassungsgesetz – BetrVG), English translation](https://www.gesetze-im-internet.de/englisch_betrvg/englisch_betrvg.html)
    
*   **Analysis by Luther Law**  
    [“Perennial issue: software vs. co-determination (Section 87 (1) No. 6 BetrVG)” — Luther Law](https://www.luther-lawfirm.com/en/newsroom/blog/detail/dauerbrenner-software-vs-mitbestimmung-87-abs-1-nr-6-betrvg)
    
*   **Austria — Eurofound summary of ArbVG §96(1) no. 3**  
    [Eurofound: Employee monitoring and surveillance — Austria](https://apps.eurofound.europa.eu/legislationdb/employee-monitoring-and-surveillance/austria)
    
*   **Schoenherr explainer (ArbVG §96(1) no. 3)**  
    [“Whistleblowing Hotline – Implementation Only with Employee Consent?” — Schoenherr](https://www.schoenherr.eu/content/whistleblowing-hotline-implementation-only-with-employee-consent)
    

---

## Further reading

*   **EDPB _Guidelines 05/2020 on Consent_**  
    [https://www.edpb.europa.eu/sites/default/files/files/file1/edpb\_guidelines\_202005\_consent\_en.pdf](https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_202005_consent_en.pdf)
    
*   **GDPR Recital 26 (anonymous data)**  
    [https://gdpr-info.eu/recitals/no-26/](https://gdpr-info.eu/recitals/no-26/)
    
*   **GDPR Article 4(5) (pseudonymization)**  
    [https://gdpr-info.eu/art-4-gdpr/](https://gdpr-info.eu/art-4-gdpr/)
    
*   **GDPR Article 5 (principles)**  
    https://gdpr-info.eu/art-5-gdpr/
    
*   **GDPR Article 13 (information to be provided)**  
    https://gdpr-info.eu/art-13-gdpr/
    
*   **GDPR Article 28 (processors)**  
    https://gdpr-info.eu/art-28-gdpr/
    
*   **GDPR Article 30 (records of processing activities)**  
    https://gdpr-info.eu/art-30-gdpr/
    
*   **GDPR Article 35 (Data Protection Impact Assessment)**  
    https://gdpr-info.eu/art-35-gdpr/
    
*   **NIS2 Directive (Articles 20–21)**  
    EUR-Lex — Directive (EU) 2022/2555 (NIS2)
    
*   **AutoPhish — Anonymization overview (product-side controls)**  
    [https://autophish.io/anonymization](https://autophish.io/anonymization)

Blog

Strumenti di simulazione di phishing in bundle vs piattaforme dedicate: cosa dovrebbero scegliere i team di sicurezza

L'alternativa a GoPhish nel 2026: simulazioni di phishing più sicure senza dover utilizzare un toolkit di attacco

Reportistica sulla simulazione di phishing: 12 caratteristiche che i team di sicurezza dovrebbero confrontare (dashboard, metriche e prove di audit)

SPF, DKIM, DMARC e permutazioni di dominio: le basi della sicurezza e-mail che gli hacker sfruttano

Tendenze del phishing nel 2026: cosa sta davvero cambiando (e cosa no)

Phishing su dispositivi mobili: SMS, WhatsApp e QR - Di quali politiche hanno effettivamente bisogno le PMI

Simulazioni di phishing basate sui ruoli: Finanza, Risorse umane, IT e Dirigenti — Scenari, linee guida e metriche

Come funziona il phishing nel 2025: la moderna catena di attacco (e-mail, QR, deepfake e SaaS)

10 storie incredibili di phishing (e simili) dal 2024 al 2025 – comprese importanti lezioni apprese

Formazione sul phishing rispettosa della privacy: comitati aziendali, consenso e nozioni fondamentali sul GDPR

Avvia il tuo primo test di phishing in 10 minuti.