Internal phishing campaign: an MSP guide for client-ready training
Internal phishing campaign planning for MSPs: run safe simulations, improve reporting, and keep client-ready evidence.
DefendWise
DefendWise
TL;DR
An internal phishing campaign is only useful if it teaches the next safe action. For MSPs, the goal is not to catch employees. The goal is to help client teams pause, verify, report, and recover faster when a real phishing attempt arrives.
A good campaign has permission, clear scope, ethical lures, role-aware scenarios, instant coaching, and clean evidence for the client. The reporting pack matters as much as the simulation itself, because MSPs need to show what was tested, who was in scope, what was learned, and what changes next.
What is an internal phishing campaign?
An internal phishing campaign is a controlled exercise that sends safe phishing-style messages to a known group of users. The messages mimic real attacker techniques without exposing the business to live attacker infrastructure. The campaign tests whether users notice risk, use the approved reporting path, avoid unsafe actions, and learn from the exercise.
For an MSP, the word "internal" can be misleading. The campaign may be internal to one client, but the service is delivered by the MSP across many client tenants. That means the MSP has to think about tenant separation, client permission, user scope, reporting, evidence, and repeatability from the start.
CISA, NSA, FBI, and MS-ISAC describe phishing as social engineering that tricks people into visiting malicious sites, giving up credentials, opening harmful links or attachments, or taking unsafe actions. That framing is useful because it moves the training conversation away from "bad emails" and toward business actions: entering credentials, approving payments, opening files, scanning QR codes, or sharing sensitive information.
A campaign should therefore answer a practical question for the client: when a risky request appears, what should our people do next?
Why internal phishing campaigns matter for MSPs
Phishing is not only an email problem. It touches identity, endpoint response, helpdesk workflow, finance controls, user reporting, and client communication.
A single client click can create work across several MSP functions:
- resetting passwords and revoking sessions;
- checking mailbox rules and forwarding;
- reviewing MFA prompts or session activity;
- searching for similar messages across the tenant;
- warning users without creating panic;
- documenting the timeline for the client;
- adjusting the next training cycle.
That is why an internal phishing campaign should be treated as an operating workflow, not a novelty test. The campaign is one controlled rehearsal for a messy real event.
NIST SP 800-50 Revision 1 frames cybersecurity and privacy learning as a lifecycle program that includes planning, role-based learning, practical exercises, metrics, evaluation, and continuous improvement. Phishing campaigns fit inside that lifecycle when they are connected to learning goals and behavior change. They do not fit when they are one-off "gotcha" emails that produce a leaderboard and no follow-up.
For MSPs, the service value is in the loop:
- choose a client-relevant risk;
- run a controlled exercise;
- coach the risky moment;
- improve the process;
- report the evidence back to the client.
What MSPs actually need before launching a campaign
Before sending the first simulated phish, the MSP should lock the operating rules. This is the difference between a useful managed service and a support mess.
| Decision | What to define | Why it matters |
|---|---|---|
| Client permission | Who approved the campaign, what audience is in scope, and when it can run | Prevents surprise, backlash, and accidental testing of excluded users |
| Scenario goal | The risky behavior being rehearsed: reporting, credential protection, payment verification, attachment handling, QR code caution | Keeps the campaign tied to one learning outcome |
| Reporting path | How users should report the message and what the MSP will monitor | Makes reporting the desired behavior, not an afterthought |
| Fail method | Link click, attachment open, credential entry, reply, QR scan, or business-process action | Helps match the training to the actual risk |
| Coaching response | What users see immediately after an unsafe action | Turns the moment into learning instead of shame |
| Evidence pack | What records will be kept for the client | Supports QBRs, cyber insurance questions, audits, and next-cycle planning |
| Exceptions | Executives, new starters, leave periods, sensitive business windows, legal or HR constraints | Protects trust and avoids avoidable noise |
Do not skip the boring setup. A campaign with weak scope can create a client-management issue even if the phishing template is clever.
Step-by-step: how to run an internal phishing campaign
1. Pick one behavior to improve
Start with the behavior, not the template. A campaign about credential harvesting is different from a campaign about invoice fraud, QR phishing, fake document sharing, or helpdesk MFA requests.
For most MSP clients, the first campaign should test a simple reporting habit. Can users recognize enough risk to report through the approved channel? If the reporting path is unclear, a more advanced scenario will only create confusing data.
2. Confirm scope and permission with the client
Get written approval for the audience, timing, scenario category, data captured, and reporting format. Confirm whether leaders, finance users, executives, contractors, shared mailboxes, and new starters are included.
This is also where the MSP should confirm the no-blame posture. If users believe the exercise exists to embarrass them, they may hide mistakes during the real event. Fast reporting is more valuable than perfect test performance.
3. Build a realistic but ethical lure
The lure should resemble the business requests employees actually see. Finance users may need invoice or bank-detail-change scenarios. Managers may need access approval or payroll prompts. Helpdesk users may need credential and MFA-code coaching. Field teams may need QR or mobile-first examples.
Avoid panic lures built around layoffs, medical results, personal finances, disasters, or other sensitive life events. The point is to teach risk recognition and safe workflow, not to abuse trust.
4. Prepare the reporting and triage path
Decide what happens when a user reports the simulated message. Who receives the report? How is it identified as campaign traffic? What does the MSP do if a real phish arrives during the same window? What response does the user get?
CISA's anti-phishing program support description includes employee awareness, simulated attacks, results analysis, dashboards, and reporting. That structure is a good reminder: the reporting and analysis layer is not optional.
5. Send in a controlled window
Run the campaign in a window the MSP can monitor. Avoid high-noise periods such as major client outages, payroll cutoffs, layoffs, holiday shutdowns, or executive travel surges unless the client has explicitly approved that risk.
For smaller clients, a single send may be enough. For larger clients, stagger by department or role so the MSP can handle reports and questions without flooding the helpdesk.
6. Coach immediately and specifically
If a user clicks, submits a test credential, opens a simulated attachment, or takes another unsafe action, show a short coaching page. It should explain the cues, the safer action, and the reporting path.
Do not write the coaching page like a scolding notice. Use the moment to make the next real action easier: "If a sign-in link arrives from a message, navigate to the known app directly" is better than "You failed to identify a phishing email."
7. Turn results into client evidence
After the campaign, produce a short client-ready summary. Include the scenario, audience, timing, reporting results, coaching actions, exceptions, and next step. Separate each client tenant cleanly.
The evidence should help the client answer: what did we practise, who was covered, what did people do, what changed, and what should we do next?
What good looks like
A good internal phishing campaign is calm, specific, and repeatable. It improves the client workflow around suspicious messages instead of chasing a dramatic failure rate.
Look for these maturity signals:
- Users know the approved reporting path.
- Reports arrive quickly enough for the MSP to triage.
- The campaign tests one clear risk, not five ideas at once.
- Follow-up coaching is short and role-relevant.
- Client managers receive a summary they can understand without reading raw campaign exports.
- Repeat-risk users get help, not public shaming.
- The next campaign is based on what the MSP learned.
NIST's Phish Scale is useful here because it gives practitioners a way to think about the difficulty of a phishing email. Not every simulated message is equally easy to detect. If one campaign uses a crude message and another uses a polished, context-rich lure, the results should not be compared as if the difficulty were the same.
Mistakes to avoid
Measuring only clicks
Click rate is easy to explain, but it is not enough. A user can click and report quickly. Another user can ignore the message, never report it, and leave the MSP blind. The second behavior may be more dangerous in a real incident.
Measure reporting rate, time to report, credential-submission attempts, repeat-risk patterns, coaching completion, and whether the client process improved.
Running surprise tests without client alignment
A surprise campaign may feel more realistic, but the MSP still needs client permission and boundaries. That includes legal, HR, executive, and support expectations. The client should not learn about the campaign because employees are angry or the helpdesk is flooded.
Using cruel or manipulative lures
Fear can make people click. That does not make it good training. Avoid lures that exploit personal hardship or create needless panic. Professional realism is enough.
Treating the campaign as proof of safety
A phishing campaign does not prove the client is secure. It gives one view of user behavior under one scenario at one moment. It should sit alongside identity controls, phishing-resistant MFA where appropriate, email security, endpoint controls, incident response, and process checks for payments or access changes.
Blending client evidence
MSPs should not mix client data, screenshots, or reports across tenants. Each client needs its own scope, results, exceptions, and next step. Blended fleet reporting can help the MSP manage service quality, but client-facing evidence must stay client-specific.
A simple MSP framework for campaign planning
Use this sequence when building a repeatable managed service:
- Risk: choose the real business risk, such as credential theft, invoice fraud, or fake document sharing.
- Audience: define the client, group, roles, exclusions, and timing.
- Scenario: write one realistic lure tied to the risk.
- Safe action: define the behavior users should take: report, verify, stop, or ask.
- Control link: connect the training to MFA, reporting, finance approval, helpdesk, or incident response.
- Evidence: record scope, send, reports, coaching, exceptions, and next action.
- Review: adjust the next cycle based on what the campaign showed.
This is also the structure MSPs can use in QBRs. It shows the client that training is not a compliance checkbox. It is part of how the MSP helps reduce human-risk exposure over time.
Metrics worth reporting to clients
The best report is short enough for a business owner but specific enough for a vCISO or security lead.
Include:
- users in scope and users reached;
- reports received and time to first report;
- unsafe actions by category, such as click, data entry, reply, or attachment open;
- users who completed coaching;
- high-risk departments or roles, if the sample size is fair;
- exceptions, such as users excluded or mailboxes out of scope;
- one operational change for the next cycle.
Be careful with small groups. If a 7-person finance team has 2 risky actions, the percentage can sound dramatic while telling a thin story. In small samples, explain the behavior and next step rather than overselling the statistic.
How a flat-rate MSP SAT platform helps
Internal phishing campaigns are easier to run as a managed service when the MSP does not have to ration training by seat count or rebuild reports by hand for every client.
DefendWise is built for MSPs with flat-fee pricing, unlimited users and client organisations, white-label delivery, multi-tenant management, automated onboarding, Microsoft 365 sync, Zapier integration, AI-native training content, and branded reporting. That combination lets MSPs make phishing awareness part of a standard client service instead of a one-off project that only some clients receive.
Start with the workflow: cover every user who should be covered, keep each tenant separate, coach the risky moment, and give the client evidence they can use.
Frequently asked questions
What is an internal phishing campaign?
An internal phishing campaign is a controlled training exercise that uses safe phishing-style messages to test and teach user behavior. It helps employees practise spotting, reporting, and responding to risky requests before a real attacker creates pressure.
For MSPs, the campaign also creates client evidence. The report should show who was in scope, what scenario was used, how users responded, what coaching happened, and what changes next.
Is an internal phishing campaign the same as phishing awareness training?
No. A campaign is one exercise inside a broader awareness program. Phishing awareness training teaches concepts and safe actions. A simulated campaign lets users practise those actions in a realistic moment.
NIST SP 800-50 Revision 1 is useful framing here: learning programs include planning, training, practical exercises, metrics, evaluation, and improvement. A phishing campaign should feed that loop.
Should internal phishing campaigns be announced?
The client leadership should always approve the campaign. Whether end users receive a broad pre-announcement depends on the client culture, risk, and maturity.
Many MSPs use a general training-policy notice that phishing simulations are part of the program, without announcing each exact send. That keeps the exercise useful while avoiding the trust problem of completely unexplained surprise testing.
What should a phishing campaign landing page say after someone clicks?
Keep it short and specific. Explain that it was a training exercise, show the cues that mattered, and tell the user what to do next time.
Avoid shaming language. A good coaching page makes the next safe action easier: report the message, navigate to known apps directly, verify sensitive requests outside the original channel, and ask the MSP or internal contact when unsure.
How should MSPs report phishing campaign results to clients?
Use a business-readable summary. Include scope, scenario, dates, users reached, reports, unsafe actions, coaching completion, exceptions, and the next recommendation.
Do not hand the client a raw export without interpretation. The MSP should explain what the result means for the client's process, not only what the platform counted.
What are the biggest risks in running internal phishing campaigns?
The biggest risks are poor permissioning, cruel lures, overreliance on click rates, weak reporting paths, and bad evidence hygiene. A campaign can damage trust if employees feel tricked or punished.
The fix is to run campaigns as no-blame learning exercises with clear client approval, ethical realism, immediate coaching, and tenant-specific reporting.
Can DefendWise support internal phishing campaign workflows for MSPs?
DefendWise supports MSP security awareness delivery with flat-fee pricing, unlimited users and clients, white-label delivery, multi-tenant management, automated onboarding, AI-native content, Microsoft 365 sync, Zapier integration, and branded reporting.
For an MSP, that matters because phishing training should be available to every relevant user across the client base, not rationed to the few seats that fit a per-user bill.
Header image brief for Picasso
- Source TL;DR: An internal phishing campaign should rehearse the safe action, not shame the click. For MSPs, the useful workflow is permissioned scope, ethical lure, fast reporting, short coaching, and tenant-specific evidence the client can use.
- Primary pillar: zero admin
- Infographic thesis: Show the MSP phishing-campaign loop from scenario to report as a calm operating workflow, not a trap.
- Suggested layout: flow
- Short on-image text candidates: "Scope", "Send", "Report", "Coach", "Evidence", "Next cycle"
- Key objects: MSP dashboard, client tenant cards, phishing email mockup, report button, coaching page, evidence pack PDF
- Avoid: hoodies, padlocks, matrix code, fake metrics, vendor logos, shaming/failure imagery, unreadable UI labels
- Crop needs: 1200x628 blog/OG, plus social-safe 1200x627
Sources and further reading
External sources:
- CISA, NSA, FBI, and MS-ISAC: Phishing Guidance: Stopping the Attack Cycle at Phase One
- CISA: Anti-Phishing Training Program Support
- NIST: NIST Phish Scale User Guide
- NIST: Building a Cybersecurity and Privacy Learning Program, SP 800-50r1
- Hoxhunt: Phishing Simulation Best Practices
- TitanHQ: What MSPs and their clients need to know about phishing simulations
- IRONSCALES: Phishing Simulation
- Axcient: MSP-friendly resources to combat phishing attacks
Internal DefendWise links: