Managed service provider security training: define the service before you sell it

TL;DR

Managed service provider security training should be sold as a defined recurring service, not a bundle of videos. Write down the audience, owners, onboarding triggers, monthly work, escalation rules, evidence, and exclusions before the first client launches. Then run the same operating rhythm across clients, with controlled exceptions where a client genuinely needs them. Training can support better decisions and useful evidence, but it should never be presented as a guarantee of compliance or incident prevention.

What is managed service provider security training?

Managed service provider security training is a recurring service in which an MSP coordinates workforce cybersecurity learning for client organizations. The work can include audience setup, onboarding, reminders, recurring training, reporting, exceptions, and client reviews.

The platform is only one part of the service. The managed layer is the operating model around it.

A client does not just need access to training content. It needs answers to practical questions:

• Who is included?
• What happens when someone joins or leaves?
• Which behaviors should the program reinforce?
• Where should an employee report a suspicious request?
• Who follows up when assignments are overdue?
• What evidence will the MSP provide?
• What happens after the first campaign?

NIST SP 800-50 Rev. 1 describes a lifecycle approach to cybersecurity and privacy learning. It emphasizes needs, roles, delivery, metrics, evaluation, and continuous improvement. The publication is not an MSP service template, but its lifecycle model is a sound foundation for defining one.

CIS Control 14 also frames awareness as a program that should be established and maintained. That is a stronger operating standard than sending one annual course and calling the work complete.

Why define the service before choosing the content?

The service promise controls the workload

If the sales promise is vague, operations inherit every client request as an exception. One client expects monthly reports. Another expects the MSP to chase every overdue user. A third assumes phishing reports go directly to the service desk, even though no route was agreed.

A short service definition keeps those expectations visible. It tells sales what can be promised, operations what must be delivered, and the client what it still owns.

Client responsibility cannot be silently outsourced

CISA's Cyber Guidance for Small Businesses separates responsibilities across the CEO, a security program manager, and IT. Its central point is useful for an MSP: culture and leadership support are not just IT tasks.

The MSP can coordinate delivery. The client still needs a business owner who can approve the audience, communicate expectations, support participation, and make decisions when people do not complete assigned work.

Training must connect to technical and response processes

Security awareness should reinforce actions employees can take, such as verifying an unusual payment request, reporting a suspicious message, using multifactor authentication, or escalating a possible incident.

CISA advises businesses to teach employees to avoid phishing, keep employees informed between formal training, and make the reporting path clear. CISA also recommends multifactor authentication as a technical control. Training should explain the behavior; technical controls should enforce what they can.

The minimum viable service definition

Use a one-page service schedule or statement of work before launch. It does not need legal theater. It needs enough precision to prevent operational confusion.

Service element	Define before launch	Evidence to retain
Audience	Included workers, contractors, locations, roles, and exclusions	Approved audience list or source
Ownership	MSP service owner, client business owner, and backups	Named contacts and responsibilities
User lifecycle	New-starter, role-change, and leaver triggers	Sync or exception record
Learning cadence	Baseline, reinforcement, role-specific content, and refresh rules	Campaign calendar
Reporting path	Button, mailbox, phone, or service desk route	Published instructions and test result
Reminders	Timing, sender, manager involvement, and stopping rule	Reminder schedule
Escalation	What becomes an exception and who acts	Exception log and owner
Client review	Frequency, attendees, inputs, and decisions	Review note and action list
Evidence	Fields, format, recipient, retention, and permitted use	Report package
Exclusions	Legal advice, incident response, guarantees, custom content, or other out-of-scope work	Written exclusions

The table should match the actual offer. Do not add a deliverable because it looks good in a proposal if nobody owns the recurring work.

A practical shared-responsibility model

The clearest model has two named owners: one at the MSP and one at the client.

Work item	MSP service owner	Client business owner
Confirm initial scope	Proposes service pattern and data requirements	Approves audience and exclusions
Maintain user data	Runs the agreed sync or intake process	Supplies accurate workforce changes
Schedule training	Operates the documented cadence	Approves client-specific constraints
Communicate launch	Supplies clear delivery details	Sponsors the program internally
Handle delivery issues	Resolves platform, data, and access exceptions	Helps resolve internal contact or policy issues
Follow up overdue work	Sends agreed reminders and reports exceptions	Directs managers and employees to act
Maintain reporting path	Documents and tests the route with the client	Confirms the route fits internal response plans
Review evidence	Prepares the agreed report	Accepts actions, owners, and dates
Change the service	Documents impact and effort	Approves business changes and any added scope

This is not a legal RACI for every possible event. It is an operating map. The aim is to make stalled work visible before it becomes an argument about who was supposed to act.

Build a recurring operating cadence

A managed service needs a repeatable calendar. The exact frequency can vary, but the work should not depend on someone remembering it.

At onboarding

Confirm the audience source, client owner, reporting route, launch communication, baseline content, and exception process. Test the learner experience and the reporting path before enrolling the full client.

The onboarding output should be a completed service record, not just an active tenant.

Weekly or automated checks

Review delivery failures, stale identities, access problems, new starters, leavers, and unresolved exceptions. Separate technical delivery issues from employee non-completion because they need different actions.

A bounced message is not the same as an ignored assignment. An inaccessible module is not the same as a manager who has not followed up.

Monthly service work

A simple monthly cycle can include:

1. Reconcile the audience and exceptions.
2. Deliver the planned learning or reinforcement.
3. Check whether the reporting route still works.
4. Review completions and overdue items.
5. Summarize support themes and repeated confusion.
6. Prepare client actions with owners and dates.

CISA says once-a-year phishing training is not enough and recommends ongoing reinforcement. The monthly service does not need a long new course every time. It can use short reminders, role-specific scenarios, policy prompts, or lessons from real support themes.

Quarterly or scheduled client review

Use the review to make decisions, not just display charts. Ask:

• Is the agreed audience still correct?
• Are onboarding and removal triggers working?
• Do employees know how to report suspicious activity?
• Which delivery exceptions keep recurring?
• Which roles need different examples or reinforcement?
• Are client-side follow-up actions being completed?
• What will change in the next cycle?

CISA's Tabletop Exercise Packages can help clients discuss incident roles and response decisions. A tabletop is not the same as an awareness module, but it can reveal whether the behaviors taught in training connect to the client's response plan.

What the client report should prove

A useful report proves that the service operated as agreed. It does not need to pretend it can prove an incident that never happened was prevented.

Audience and delivery evidence

Show the approved audience, enrollment coverage, delivery failures, removed accounts, and open data exceptions. This tells the client whether the program reached the people it intended to reach.

Participation evidence

Show assigned work, completions, overdue items, reminders, and agreed escalation. Keep the reporting period and population clear so the numbers are not misleading.

Reporting-path evidence

Record the route employees were taught to use, whether it was tested, and any confusion found. CISA's current guidance emphasizes that employees should know how and to whom they report suspicious messages.

Operating and learning evidence

Show review dates, unresolved actions, repeated support themes, and service exceptions. Use knowledge checks, role-specific exercises, or reviewed support themes to decide what to reinforce. NIST includes metrics and evaluation methods, but it does not support reducing the whole program to one unexplained score.

The FTC Cybersecurity for Small Business library provides plain-language material on common attacks, the NIST Cybersecurity Framework, remote access, vendor security, and other safeguards. It can help clients place training inside a wider security program.

Define exclusions without weakening the offer

Clear exclusions protect the client as much as the MSP. They stop training evidence from being mistaken for something it is not.

Common exclusions include:

• legal, regulatory, or insurance advice;
• a guarantee of compliance, lower premiums, or audit acceptance;
• a guarantee that an incident or loss will not occur;
• incident response, forensics, or breach notification unless separately contracted;
• custom content or translations outside an agreed allowance;
• manager discipline or HR action;
• remediation of unrelated technical controls;
• unlimited manual cleanup of inaccurate client data;
• client-specific reporting outside the agreed template and cadence.

An exclusion does not mean the MSP ignores the issue. It means the next action follows the right service, owner, and commercial path.

How to standardize the service across clients

Start with one default service pattern. Standardization makes quality easier to manage and client exceptions easier to see.

Keep these elements consistent where possible:

• onboarding checklist;
• owner and audience fields;
• default learning cadence;
• reminder schedule;
• exception categories;
• report format;
• client review agenda;
• action log;
• offboarding process.

Allow controlled exceptions for real differences, such as workforce language, high-risk roles, client policy, contractual obligations, or an industry-specific threat. Record why the exception exists, who approved it, and whether it adds recurring work.

Do not make every client unique by default. That turns a managed service into a collection of projects.

Commercial checks before putting the service on the price list

The platform price is not the whole cost of delivery. Review the operating work before setting the client price or deciding to bundle the service.

Ask:

• How many manual steps are required per client each month?
• Which events can be triggered from a reliable user source?
• Who handles data and access exceptions?
• How much client-specific content is included?
• Which reports are standard, and which are custom?
• What is the escalation path when the client does not act?
• Does the vendor cost change when the client adds users?
• Can one team manage all client organizations without separate logins?
• Are client-facing emails, portals, and reports delivered under the MSP's brand?

The answer should fit the service promise. If sales promises unlimited customization while operations are built around a standard monthly cycle, the margin problem is already present.

Where an MSP-focused platform fits

A platform designed for multi-client delivery can remove friction from the operating model. DefendWise is built for MSPs and provides flat $399/month pricing, unlimited users and client organizations, multi-tenant management, white-label delivery, and automated onboarding and reporting.

Those capabilities support delivery. They do not replace the MSP's service definition, the client's business owner, or the need to review exceptions and actions.

If the service model is ready, start a free 7-day trial and test it against one documented client workflow before rolling it out more widely.

Frequently asked questions

What is managed service provider security training?

It is a recurring client service in which an MSP coordinates workforce security learning, audience changes, delivery, reminders, exceptions, reporting, and review. The client keeps responsibility for leadership support, employee participation, and business decisions.

What should an MSP include in the service?

Include the audience, owners, user-lifecycle triggers, cadence, reporting route, reminders, escalation, client review, evidence package, and exclusions. If a recurring task is not owned or priced, do not hide it in vague service language.

Who owns the program?

Use shared ownership. Name one MSP service owner and one client business owner. The MSP coordinates the service. The client owner approves scope, supports participation, handles client-side follow-up, and accepts business actions.

How often should managed security training run?

There is no universal cadence for every client. Combine onboarding, recurring reinforcement, role-specific learning, threat-triggered updates, periodic exercises, and scheduled reviews. Document the schedule so the service does not depend on memory.

What should the client report contain?

Report the agreed audience, delivery exceptions, completions, overdue items, reporting-path readiness, support themes, open actions, owners, and dates. Keep service-operation evidence separate from claims about risk reduction or incident prevention.

Does managed security training make a client compliant?

No. Training can support a wider security or compliance program, but it does not create compliance by itself. Any specific framework, legal, contractual, or insurance claim needs qualified review against the client's actual obligations.

How should an MSP handle custom client requests?

Compare the request with the written service definition. If it adds recurring work or a new responsibility, document the change, owner, delivery impact, and commercial treatment. Do not let silent exceptions become the default service.

Can DefendWise support the service?

Yes. DefendWise is built for MSPs with flat $399/month pricing, unlimited users and client organizations, white-label delivery, multi-tenant management, and automated onboarding and reporting. MSPs can start a free 7-day trial.

Sources

• NIST SP 800-50 Rev. 1: Building a Cybersecurity and Privacy Learning Program
• NIST SP 800-50 Rev. 1 PDF
• CIS Control 14: Security Awareness and Skills Training
• CISA: Cyber Guidance for Small Businesses
• CISA: Teach Employees to Avoid Phishing
• CISA: Require Multifactor Authentication
• CISA Tabletop Exercise Packages
• CISA: Secure Our World
• FTC: Cybersecurity for Small Business
• FTC: Talking Cybersecurity With Your Employees
• CanIPhish: MSP Buyers Guide for Security Awareness Training