What is included in automated onboarding for MSP SAT?
Automated onboarding for MSP SAT should cover client setup, user lifecycle, assignments, reminders, reporting, exceptions, and offboarding.

DefendWise
DefendWise
TL;DR
Automated onboarding for MSP SAT is the workflow that turns a new client and its users into an active, reportable training program without rebuilding the process by hand.
It should include:
- client tenant setup;
- MSP branding;
- user import, Microsoft 365 sync, SCIM, CSV, or self-enrolment path;
- group and role mapping;
- baseline training assignment;
- reminder and escalation rules;
- manager or client notification path;
- exception queue;
- client-ready reporting;
- offboarding hygiene.
User sync matters, but it is not the whole job.
For MSPs, the real test is operational: can you add a client, keep users current, assign the right training, chase fewer completions, and produce evidence without turning every client launch into a technician project?
What automated onboarding means in MSP SAT
In ordinary SaaS, onboarding often means getting one customer into one account.
MSP security awareness training is different.
The MSP may need to onboard 1 client today, 4 next month, and 20 more across the year. Each client has its own users, domains, managers, policies, reporting expectations, and audit pressure. The platform has to support that operating model.
Automated onboarding means the recurring setup work is governed by reusable rules instead of memory.
It should answer 5 questions:
- Who belongs in this client tenant?
- What training should they receive?
- When should reminders happen?
- What proof will the client receive?
- What changes when someone joins, moves, or leaves?
That last point is easy to miss.
Microsoft describes identity lifecycle workflows around joiner, mover, and leaver stages, where tasks run automatically as users enter, move through, or leave an organization. That is useful language for MSP SAT too. Training onboarding should not only add new users. It should keep the training record accurate as the client changes.
SCIM also matters here. Microsoft's SCIM guidance explains that SCIM standardizes automatic user and group provisioning between identity providers and cloud apps. RFC 7644 defines the protocol layer behind that kind of user and group management. MSPs do not need to become SCIM experts to buy SAT, but they should understand the outcome: fewer manual user-management paths and cleaner lifecycle data.
Why MSP SAT onboarding is different
Most SAT tools can get one organization started.
That is not enough for an MSP.
The MSP has to package training as a managed service across clients. That creates 4 extra pressures.
First, the MSP needs tenant separation. A client report cannot leak another client's users, groups, or completion records.
Second, the MSP needs repeatability. If every launch needs a custom checklist, the first few clients may work, then delivery slows down.
Third, the MSP needs evidence. NIST SP 800-12 frames awareness and training as a way to improve behaviour, support accountability, and make policies usable. ISO 27001 awareness guidance points in the same direction: people need to understand relevant security policies, their role, and the consequences of not following requirements. For the MSP, that means onboarding has to create records, not just send lessons.
Fourth, the MSP needs margin control. Every manual enrolment, reminder, report, exception, and CSV cleanup is service cost.
This is why automated onboarding is a zero-admin topic, not a feature checklist.
What should be included in automated onboarding for MSP SAT?
Use this table as the buying checklist.
| Onboarding layer | What it should include | Why it matters for MSPs |
|---|---|---|
| Client tenant setup | Client name, domain checks, tenant separation, admin roles, template settings | Prevents wrong-client setup and keeps evidence separated |
| White-label setup | MSP logo, sender identity where available, portal branding, branded reports | Makes training feel like part of the MSP service, not a vendor detour |
| User source | Microsoft 365 sync, SCIM, CSV import, self-enrolment, or manual fallback | Keeps the roster closer to the source of truth |
| Group and role mapping | Baseline users, privileged users, managers, high-risk roles, exclusions | Avoids sending the same generic path to everyone |
| Baseline assignment | Starter module, policy acknowledgement where used, phishing/social engineering baseline, due dates | Turns setup into live training, not an empty tenant |
| Reminder rules | Automatic nudges before due dates, overdue reminders, manager/client visibility | Reduces technician chasing |
| Exception handling | Leavers, contractors, shared mailboxes, leave of absence, test users, duplicate records | Keeps reports honest |
| Reporting and evidence | Completion status, overdue users, assignment history, topics, report exports, client-ready summaries | Gives the MSP proof for QBRs, audits, and insurance requests |
| Offboarding hygiene | Remove or deactivate leavers, preserve history where required, stop future assignments | Protects report quality and access hygiene |
| QA before handoff | Test user, branded email check, report preview, admin access check, client-safe names | Catches small setup errors before the client sees them |
That is the minimum useful version.
The details can vary by platform. The shape should not.
1. Client tenant setup
Automated onboarding starts before the first learner receives training.
The MSP needs a clean client container.
That means:
- the right client name;
- the right domains;
- the right admin users;
- the right logo or brand settings;
- the right training template;
- the right report scope;
- the right data separation.
This is where multi-tenancy matters.
A multi-tenant SAT platform should let the MSP manage clients from one operating layer while keeping each client's users, branding, reporting, and evidence separate. If the platform treats every client like a separate login with separate manual setup, the MSP inherits the admin cost.
The safest onboarding workflow uses a template.
A template does not mean every client gets identical training forever. It means the MSP has a known starting point: default settings, baseline campaign, reminder rules, reporting rhythm, and evidence expectations.
From there, client-specific changes can be deliberate.
2. User source and lifecycle mapping
The user list is the heart of onboarding.
If the roster is wrong, everything downstream is suspect: assignments, reminders, completion rates, reports, exceptions, and evidence.
An MSP should ask where users come from.
Common options include:
- Microsoft 365 or directory sync;
- SCIM provisioning;
- CSV import;
- self-enrolment links;
- manual admin entry as a fallback.
Each has a place.
Microsoft 365 sync is often the practical path for MSPs already managing client identity. SCIM can help when the client has a stronger identity governance layer or needs standards-based provisioning. CSV can work for small clients or one-time imports. Self-enrolment can help with edge cases, but it needs controls so the tenant does not fill with bad records.
The important point is not the acronym.
The important point is that onboarding should map the user lifecycle.
Microsoft's lifecycle workflow model is useful because it names the joiner, mover, and leaver states. A new starter should enter training. A user who changes role may need a different path. A leaver should stop receiving new assignments while the record history stays usable for reporting.
For MSP SAT, that lifecycle map should include:
- new users;
- departed users;
- role changes;
- manager changes;
- group changes;
- contractors;
- shared mailboxes;
- dormant accounts;
- duplicate users.
If those cases are not handled, the MSP will handle them manually later.
3. Training assignment rules
Onboarding should not stop at adding users.
It should assign the right first training.
NIST SP 800-12 separates awareness, training, and education. Awareness helps users recognize security issues and understand why security matters. Training teaches people what to do and how to do it. It also says training is most effective when targeted to the audience.
That should shape MSP onboarding.
A baseline path might include phishing, credential handling, MFA fatigue, password hygiene, suspicious links, QR phishing, social engineering, and incident reporting. High-risk roles may need extra depth. Managers may need a different path from frontline employees. Finance may need BEC and invoice-fraud scenarios. Administrators may need privileged-access expectations.
CIS Control 14 also frames security awareness and skills training as a standing control area, not a one-off event.
So the onboarding question is:
What does this user need now, and what does the MSP need to prove later?
That question is stronger than "which module should we send first?"
4. Reminder and escalation rules
Training that nobody completes is not a program.
Reminder rules should be part of onboarding from the start.
A useful SAT onboarding workflow should define:
- first due date;
- reminder timing;
- overdue timing;
- who gets notified;
- what managers see;
- when the MSP steps in;
- when an exception is recorded instead of chased.
KnowBe4's guidance on successful security awareness training includes making the course mandatory with a clear deadline, making it part of new-employee onboarding, and keeping awareness active over time. The exact cadence is up to the MSP and client, but the pattern is right: onboarding needs deadlines and follow-up.
For MSPs, the danger is manual chasing.
One client with 10 overdue users is manageable. Fifty clients with overdue users is a quiet service drain.
Automated reminders do not remove human judgment. They reserve human judgment for the cases that need it.
5. Client-ready reporting and evidence
Automated onboarding should create a reportable trail from day 1.
That trail should show:
- who was in scope;
- who was assigned training;
- what was assigned;
- when it was assigned;
- who completed it;
- who is overdue;
- what reminders happened;
- what exceptions exist;
- when the report was produced.
This is where automated reports are more than a dashboard convenience.
MSPs need reports for QBRs, client leadership updates, cyber insurance questionnaires, ISO 27001 awareness evidence, NIST-aligned program discussions, and internal service reviews. A report that has to be rebuilt manually each month is not really part of the service. It is a recurring task.
ISO 27001 Annex A 6.3 guidance points to information security awareness, education, and training tied to policies, responsibilities, risk, and regular refreshers. Clause 7.3 guidance focuses on people understanding the information security policy, their contribution, and consequences. MSPs should not overclaim that SAT alone satisfies ISO 27001. It does not. But SAT can support the awareness evidence layer when records are clean.
The onboarding workflow should make that evidence easier to collect later.
6. Exceptions and client-safe support
Every client has exceptions.
Someone is on leave. Someone is a contractor. Someone is in a shared mailbox. Someone left last week but still appears in the directory. Someone used a personal email in an import. Someone is a senior executive who should receive training but needs a different communication path.
Weak onboarding hides those exceptions.
Good onboarding records them.
An exception log should answer:
- who is excluded;
- why they are excluded;
- who approved it;
- when it should be reviewed;
- whether the exclusion affects reporting;
- whether the MSP or client owns the next action.
This matters because client reports can otherwise look cleaner than reality.
It also protects the MSP. If the client asks why 6 users did not complete training, the answer should not live in a technician's memory.
7. Offboarding and stale-user hygiene
Offboarding belongs inside onboarding.
That sounds odd until a report is polluted by stale users.
A departed employee can make completion rates look worse. A stale account can keep receiving reminders. A wrong-client user can create privacy risk. A duplicate user can make reporting harder to explain. A contractor who should have been excluded can become an audit question.
Microsoft's lifecycle workflow framing includes leavers for a reason: access and workflow do not end at account creation.
For MSP SAT, offboarding should cover:
- removing departed users from future assignments;
- preserving training history where required;
- stopping reminders to leavers;
- flagging stale users before report export;
- keeping exceptions visible;
- confirming who owns roster cleanup.
That is not glamorous work.
It is the work that keeps reports believable.
8. A practical trial checklist for MSP buyers
If you are comparing SAT platforms, do not only watch the demo.
Test the onboarding workflow.
Use one real or realistic client and ask:
- Can we create a tenant without custom setup work?
- Can we apply our MSP branding to the client experience?
- Can we sync or import users without cleaning the same list twice?
- Can we map groups, roles, or exclusions?
- Can we assign a baseline training path with a clear due date?
- Can reminders run without a technician chasing every user?
- Can we see overdue users and exceptions clearly?
- Can we export a client-ready report?
- Can we add a new starter after launch?
- Can we remove or deactivate a leaver without breaking history?
- Can we repeat the process for the next client?
- Does pricing still make sense when the client adds users?
That last question matters.
A platform can have useful automation and still create a commercial problem if every new learner changes the bill. Flat pricing does not replace onboarding quality, but it does make broader coverage easier to package.
Flat-fee SAT pricing helps MSPs avoid rationing training coverage by seat. White-label delivery helps the client experience feel like part of the MSP service. Automation and reporting help keep the work repeatable.
The buying question is simple:
Will this still work when 10 more clients are live?
What Defendwise includes
Defendwise is built around the MSP delivery model: flat-rate SAT, unlimited users, white-label delivery, multi-tenant management, automated onboarding, Microsoft 365 sync, Zapier integration, AI-generated training content, and automated monthly branded compliance reports.
For this topic, the relevant pieces are:
- multi-tenant management, so client environments stay separated;
- automation, so onboarding, reminders, and training workflows do not rely on manual chasing;
- automated reports, so client proof is easier to repeat;
- white-label delivery, so the experience sits under the MSP brand;
- flat-fee pricing, so adding users does not create a new seat-count conversation every month.
The safest way to evaluate it is to test one client.
Set up the tenant. Apply the brand. Check the user path. Assign the baseline training. Preview the report. Then decide whether the workflow is fit for a wider rollout.
FAQ
What is included in automated onboarding for MSP SAT?
Automated onboarding should include client tenant setup, branding, user source connection, user and group mapping, training assignment, reminders, manager or client notifications, exception handling, reporting, offboarding hygiene, and QA before handoff.
Is user sync enough for MSP SAT onboarding?
No. User sync keeps the roster current, but onboarding also needs training rules, reminders, reporting, evidence, exception handling, and offboarding. Sync is the input. The program is the output.
How should MSPs handle new starters in SAT?
New starters should be added through the chosen user source, mapped to the right client tenant and group, assigned baseline training, given a due date, included in reminders, and visible in reporting.
How should MSPs handle leavers in SAT?
Leavers should stop receiving new assignments and reminders, but their historical training record should remain usable where reporting or audit evidence requires it. The exact retention handling should follow the client's policy and platform controls.
Does automated onboarding help with compliance evidence?
It can support the evidence layer by keeping scope, assignments, completions, reminders, reports, and exceptions cleaner. It does not replace the client's broader compliance program or technical control evidence.
What is the best way to test automated onboarding?
Use one realistic client. Create the tenant, apply branding, sync or import users, assign training, trigger reminders where possible, review exceptions, export a report, then add a new starter and remove a leaver.
Source notes
- https://csrc.nist.gov/pubs/sp/800/12/r1/final
- https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-50.pdf
- https://www.cisecurity.org/controls/security-awareness-and-skills-training
- https://learn.microsoft.com/en-us/entra/id-governance/what-are-lifecycle-workflows
- https://learn.microsoft.com/en-us/entra/identity/app-provisioning/use-scim-to-provision-users-and-groups
- https://www.rfc-editor.org/rfc/rfc7644
- https://www.isms.online/iso-27001/annex-a-2022/6-3-information-security-awareness-education-training-2022/
- https://www.isms.online/iso-27001/requirements-2022/7-3-awareness-2022/
- https://www.knowbe4.com/resources/six-steps-to-successful-security-awareness-training/
- https://hoxhunt.com/guide/security-awareness-training
- https://www.huntress.com/cybersecurity-insights/how-to-integrate-sat-with-hr-lms-systems
- https://www.huntress.com/resources/security-awareness-training-getting-started
- https://www.huntress.com/pricing/sat