Security awareness training for MSPs needs an operating plan that connects the lesson to the client's reporting and response process. If a vendor presents completed modules as proof that the client is protected, ask what those completions actually measured. A finished lesson doesn't tell you whether a suspicious message reached someone able to investigate it.
Awareness training belongs in every managed plan. I'd make the included service explicit, then agree with the client how its staff will practice the actions you want them to take. Keep the program tied to their work rather than treating an available course catalog as an assignment list.
I'd design the practice like a fire drill: name the action people should rehearse and check what happens when they try it. The useful result is a process you can examine, including the part your MSP owns.
Give the Included Program an Owner
Start with the client sponsor and your delivery lead. Agree on the people covered by the program and how joiners will enter it. Give the sponsor responsibility for correcting the staff list and resolving participation issues; give your team a named owner for the service work it promises.
Write those responsibilities alongside the included training scope. If a supplier operates part of the program, identify which tasks your MSP still performs. A supplier account is a place to configure the service, not the person accountable for it.
| Decision | What I Would Record With the Client |
|---|---|
| Learning objective | The job situation and the action the person should be able to take. |
| Delivery responsibility | Who assigns the activity, handles access problems, and follows up incomplete work. |
| Reporting route | Where a suspicious-message report goes and who acknowledges it. |
| Review responsibility | Who examines the results with the client and authorizes a program change. |
Set the schedule with the client after considering its work patterns and any requirements it has identified. Don't present a chosen session length or simulation interval as a universal standard. The agreement needs an achievable schedule and someone responsible for maintaining it.
Choose the Lesson Around the Job
Conor Swalm favors short, recurring security-awareness sessions matched to the person's actual work. In his vendor training view, automatically assigning healthcare or payment-related material deserves scrutiny when the learner doesn't do that work; he also asks whether an actual requirement applies. That's a preference to assess against the client's roles, not proof of a particular training outcome.
Take a hypothetical finance employee who receives a request to change a supplier's payment details. I'd build the exercise around the client's approved verification procedure and the route for reporting a suspicious request. The learning objective should describe what the employee is expected to do before the payment instruction changes.
Use a synthetic example approved by the client. Ask the employee to explain or rehearse the verification step without making a real payment, changing a supplier record, or collecting a real password. That keeps the exercise bounded to the action you meant to examine.
Then check whether the lesson and the client's procedure agree. If the lesson says to call a manager but the procedure names a finance approver, resolve the difference before assigning it. The person doing the exercise shouldn't have to choose which set of instructions the MSP meant.
Test the Report All the Way to Its Recipient
The first failure I'd test is a report that arrives while its usual recipient is away. In the hypothetical finance exercise, have the employee use the agreed reporting route and ask the receiving team to acknowledge it. Check the alternative contact and the information needed to decide what happens next.
I'd record the expected handoff before running that exercise. If the MSP receives the report, say who reviews it and how the client receives an update. If the client handles it internally, agree on the conditions under which it asks your team for help.
A report marked received hasn't necessarily been investigated. Keep those statuses separate in the operating record so the service lead can see which work remains. Where the test stops at an acknowledgment, describe that limit instead of calling the whole response complete.
Gaidar Magdanurov describes MSPs using other MSPs for complementary services and bringing those partners into training together. He says they seek a common language and shared procedures for approaching the customer. If your delivery uses such a partner, I'd include it in this handoff exercise rather than assume that its procedure matches yours.
Separate Completion From Observed Actions
Keep a completion record, but describe it as completion. Record the particular action observed in an exercise separately, together with what the test asked the person to do. Neither entry, by itself, establishes that the client's risk has fallen.
| Record | What It Can Establish | What to Check Next |
|---|---|---|
| Training completion | The assigned activity is recorded as finished. | Whether the person can follow the relevant client procedure. |
| A suspicious-message report | A report reached the recorded destination. | Whether the intended recipient acknowledged and handled it. |
| A simulation click event | The platform recorded the event under its own definition. | Whether the event reflects likely human activity and how that definition applies. |
| An exercise handoff | The agreed steps were observed in that test. | Which conditions or participants the test did not cover. |
In Microsoft's Attack simulation training, automated inspection of a payload URL can produce false-positive clicks. Its reporting documentation identifies security services, non-Microsoft filtering services, and email forwarding as possible contributors. Microsoft advises checking the click IP address, browser, device, and event timestamp to help distinguish likely user activity from automated inspection.
Before assigning follow-up to a person from that report, have the program owner examine those signals. Keep any uncertain result marked as uncertain while it is checked. For another platform, check that platform's documentation and event definitions rather than importing Microsoft's interpretation.
Change the Program From a Specific Finding
Bring the client a finding it can act on. In the finance example, a learner might know where to report the request but be unable to find the approved verification contact. I'd treat that hypothetical result as a procedure-access problem to correct and retest, without deciding that another generic module is automatically the answer.
It depends on what the exercise exposed: a missing instruction calls for a different change from an inaccessible reporting route. Assign the correction to the team able to make it, then agree how you will check that particular change. Keep the original observation so the next review has something concrete to compare.
Before accepting the next training report, choose an included client workflow and trace its evidence from assignment through the receiving team's action. Take the unresolved step to the client sponsor with a named owner. That's the decision I would want beside the completion chart.
mspoutpost.com/articles/security-awareness-training-for-msps-run-the-program
Written by Dana Kowalski
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.
